On Friday evening, SonicWall announced that it “identified a coordinated attack on its internal systems by highly sophisticated threat actors exploiting probable zero-day vulnerabilities on certain SonicWall secure remote access products.” The network security company said that several of its products are impacted, but the day after let everyone know that some of those were not affected, after all. Affected devices “We believe it is extremely important to be transparent with our customers, our partners … More
The post SonicWall hit by attackers leveraging zero-day vulnerabilities in its own products? appeared first on Help Net Security.
Last month, I discussed the FedRAMP program’s basics and why it’s such a big deal for the federal government. In short, the program protects the data of U.S. citizens in the cloud and promotes the adoption of secure cloud services across the government with a standardized approach.
But within the FedRAMP program, there are different authorizations. We’re pleased that McAfee MVISION for Endpoint Access recently achieved FedRAMP Moderate Authorization, which allows users from federal agencies, state and local government, and other industries in regulated environments to manage Controlled Unclassified Information (CUI) such as personally identifiable information (PII) and routine covered defense information (CDI).
As organizations across the country continue to adapt to a remote workforce, the U.S. government is “in a race to modernize its IT infrastructure to support ever more complicated missions, growing workloads and increasingly distributed teams—and do so facing a constantly evolving threat landscape,” Alex Chapin, our VP of DoD and Intelligence notes.
And he’s right – with the 2021 federal fiscal year in full focus, federal agencies are continuing to push cloud computing as the COVID-19 pandemic continues, creating a real need for security in these applications.
The FedRAMP Moderate designation allows MVISION to provide the command and control cyber defense capabilities government environments need to enable on-premises and remote security teams, allowing them to maximize time and resources, enhance security efficiency and boost resiliency.
This is a massive win for the federal government as it continues to build out its remote workforce capabilities at a time when the GAO is continuing to release best practices for telework, highlighting how remote work is here to stay in the federal government.
MVISION Cloud is currently in use by ten federal agencies, including the Department of Energy (DOE), Department of Health and Human Services (HHS), Department of Homeland Security (DHS), Food and Drug Administration (FDA) and National Aeronautics and Space Administration (NASA).
At McAfee, we are dedicated to ensuring our cloud services are compliant with FedRAMP standards to help the federal government secure its digital infrastructure and prepare for an increasingly digital operation. We look forward to working closely with the FedRAMP program and other cloud providers dedicated to authorizing cloud service offerings with FedRAMP.
The post McAfee MVISION for Endpoint is FedRAMP Moderate As Federal Cloud Usage Continues to Rise appeared first on McAfee Blogs.
Organizations across the country – from the private sector to the federal government – have become more digital, especially following the shift to remote work this year. It’s no surprise that cybercriminals around the world have taken notice. According to a new report by McAfee and the Center for Strategic and International Studies (CSIS), cybercrime is now a nearly trillion-dollar industry, and the government sector is not immune.
Across the board, the issue continues to rise – increasing the cost of cybercrime by nearly 50% since our last report in 2018. The threats to the government from cybercriminals are even greater, leading to potential national security risks as dark actors look to steal U.S. secrets and intellectual property.
All levels of government – from state and local to the federal government here in Washington – are taking steps to mitigate the issues, but they must do so differently than their private sector counterparts. Government respondents to the survey reported the highest number of malicious attacks, highlighting the high-stakes environment in which governments operate.
Unfortunately, the report also found that while government organizations face more attacks than their private-sector counterparts, they also take longer to remediate them, leaving our government services, infrastructure, and other critical aspects of society at risk for longer than they need.
A Discussion With CSIS
Earlier this week, McAfee’s CTO Steve Grobman joined CSIS for a conversation on the report and how we can continue to prepare for and mitigate the risk of cybercrime and its hidden costs with CSIS’ Jim Lewis and Zhanna Malekos Smith, former Federal CISO Grant Schneider and the FBI’s Jonathan Holmes.
Kicking off the discussion, Schneider highlighted the importance of the workforce and the need to take care of them so organizations can quickly rebound from an incident. Schneider noted that if an office were robbed, no one would blame the team, but with cybercrime, victims are often seen as the issue – leading to reduced employee morale and more issues later down the line.
Instead, Schneider argued on the importance of preparing the workforce and that preparation can take several forms, including risk management through NIST’s risk management framework. He also called for organizations to develop a recovery plan, engaging different departments, leadership and the public to be ready for when an incident occurs.
In his discussion of the report’s findings, McAfee CTO Steve Grobman noted they weren’t shocking. Grobman said that as we adopt new technologies, adversaries will continue to find new attack vectors.
This year was particularly notable as much of the federal government transitioned to a remote work environment overnight. As the workforce went remote – critical government information was accessed from home internet routers that lacked the same level of security as government office networks, increasing adversaries’ ability to successfully launch attacks.
Luckily, as Grobman noted, there are ways lawmakers can mitigate the threat of ransomware against government and the private sector.
What’s the solution?
Across the country, governments are facing ransomware attacks at an alarming rate, and every one of them – at every level – needs to have a plan in place. There needs to be a data-based discussion with leadership to decide how to balance the daily blocking and tackling of threats with limited complication to the continuation of operations and preparation for big intrusions like we’ve seen happen this year.
There are also policy solutions – many of these criminal groups operate in countries that allow them to do so. When negotiating trade deals with countries, the level of cybercrime and the government’s cooperation with or against those groups must be considered.
The cost of cybercrime is now nearly 1% of the global GDP, and it will only continue to rise, impacting companies and governments around the world unless we come together to stop it through basic cyber hygiene, preparation and policy solutions.
Government and Private Sector organizations are transforming their businesses by embracing DevOps principles, microservice design patterns, and container technologies across on-premises, cloud, and hybrid environments. Container adoption is becoming mainstream to drive digital transformation and business growth and to accelerate product and feature velocity. Companies have moved quickly to embrace cloud native applications and infrastructure to take advantage of cloud provider systems and to align their design decisions with cloud properties of scalability, resilience, and security first architectures. The declarative nature of these systems enables numerous advantages in application development and deployment, like faster development and deployment cycles, quicker bug fixes and patches, and consistent build and monitoring workflows. These streamlined and well controlled design principles in automation pipelines lead to faster feature delivery and drive competitive differentiation.
As more enterprises adapt to cloud-native architectures and embark on multi-cloud strategies, demands are changing usage patterns, processes, and organizational structures. However, the unique methods by which application containers are created, deployed, networked, and operated present unique challenges when designing, implementing, and operating security systems for these environments. They are ephemeral, often too numerous to count, talk to each other across nodes and clusters more than they communicate with the outside endpoints, and they are typically part of fast-moving continuous integration/continuous deployment (CI/CD) pipelines. Additionally, development toolchains and operations ecosystems continue to present new ways to develop and package code, secrets, and environment variables. Unfortunately, this also compounds supply chain risks and presents an ever-increasing attack surface.
Lack of a comprehensive container security strategy or often not knowing where to start can be a challenge to effectively address risks presented in these unique ecosystems. While teams have recognized the need to evolve their security toolchains and processes to embrace automation, it is imperative for them to integrate specific security and compliance checks early into their respective DevOps processes. There are legitimate concerns that persist about misconfigurations and runtime risks in cloud native applications, and still too few organizations have a robust security plan in place.
These complex problem definitions have led to the development of a special publication from National Institute of Standards and Technology (NIST) – NIST SP 800-190 Application Security Container Guide. It provides guidelines for securing container applications and infrastructure components, including sectional review of the fundamentals of containers, key risks presented by core components of application container technologies, countermeasures, threat scenario examples, and actionable information for planning, implementing, operating, and maintaining container technologies.
MVISION Cloud Native Application Protection Platform (CNAPP) is a comprehensive device-to-cloud security platform for visibility and control across SaaS, PaaS, & IaaS platforms. It provides deep coverage on cloud native security controls that can be implemented throughout the entire application lifecycle. By mapping all the applicable risk elements and countermeasures from Sections 3 and 4 of NIST SP 800-190 to capabilities within the platform, we want to provide an architectural point of reference to help customers and industry partners automate compliance and implement security best practices for containerized application workloads. This mapping and a detailed review of platform capabilities aligned with key countermeasures can be referenced here.
As outlined in one of the supporting charts in the whitepaper, CNAPP has capabilities that effectively address all the risk elements described in the NIST special publication guidance.
While the breadth of coverage is critical, it is worth noting that the most effective way to secure containerized applications requires embedding security controls into each phase of the container lifecycle. If we leverage Department of Defense’s Enterprise DevSecOps Reference Design guidance as a point of reference, it describes the DevSecOps lifecycle in terms of nine transition stages comprising of plan, develop, build, test, release, deliver, deploy, operate, and monitor.
The foundational principle of DevSecOps implementations is that the software development lifecycle is not a monolithic linear process. The “big bang” style delivery of the Waterfall SDLC process is replaced with small but more frequent deliveries, so that it is easier to change course as necessary. Each small delivery is accomplished through a fully automated process or semi-automated process with minimal human intervention to accelerate continuous integration and delivery. The DevSecOps lifecycle is adaptable and has many feedback loops for continuous improvement.
Specific to containerized applications and workloads, a more abstract view of a container’s lifecycle spans across three high-level phases of Build, Deploy, and Run.
The “Build” phase centers on what ends up inside the container images in terms of the components and layers that make up an application. Usually created by the developers, security efforts are typically focused on reducing business risk later in the container lifecycle by applying best practices and identifying and eliminating known vulnerabilities early. These assessments can be conducted in an “inner” loop iteratively as developers perform incremental builds and add security linting and automated tests or can be driven via an “outer” feedback loop that’s driven by operational security reviews and penetration testing efforts.
In the “Deploy” phase, developers configure containerized applications for deployment into production. Context grows beyond information about images to include details about configuration options available for orchestrated services. Security efforts in this phase often center around complying with operational best practices, applying least-privilege principles, and identifying misconfigurations to reduce the likelihood and impact of potential compromises.
“Runtime” is broadly classified as a separate phase wherein containers go into production with live data, live users, and exposure to networks that could be internal or external in nature. The primary purpose of implementing security during the runtime phase is to protect running applications as well as the underlying container infrastructure by finding and stopping malicious actors in real time.
By applying this understanding of container lifecycle stages to respective countermeasures that can be implemented and audited upon within MVISION Cloud, CNAPP customers can establish an optimal security posture and achieve synergies of shift left and runtime security models. Security assessments are critically important early in planning and design, where important decisions are made about architecture approach, development tooling and technology platforms and where mistakes or misunderstandings can be dangerous and expensive. As DevOps teams move their workloads into the cloud, security teams will need to implement best practices that apply operations, monitoring and runtime security controls across public, private, and hybrid cloud consumption models.
CNAPP first discovers all the cloud-native components mapped to an application, including hosts, IaaS/PaaS services, containers, and the orchestration context that a container operates within. With the use of native tagging and network flow log analysis, customers can visualize cloud infrastructure interactions including across compute, network, and storage components. Additionally, the platform scans cloud native object and file stores to assess presence of any sensitive data or malware. Depending on the configuration compliance of the underlying resources and data sensitivity, an aggregate risk score is computed per application which provides detailed context for an application owner to understand risks and prioritize mitigation efforts.
As a cloud security posture management platform, CNAPP provides a set of capabilities that ensure that assets comply with industry regulations, best practices, and security policies. This includes proactive scanning for vulnerabilities in container images and VMs and ensuring secure container runtime configurations to prevent non-compliant builds from being pushed to production. The same principles apply to orchestrator configurations to help secure how containers get deployed using CI/CD tools. These baseline checks can be augmented with other policy types to ensure file integrity monitoring and configuration hardening of hosts (e.g., no insecure ports or unnecessary services), which help apply defense-in-depth by minimizing the overall attack surface.
Finally, the platform enforces policy-based immutability on running container instances (and hosts) to help identify process-, service-, and application-level whitelists. By leveraging the declarative nature of containerized workloads, threats can be detected during the runtime phase, including any exposure created as a result of misconfigurations, application package vulnerabilities, and runtime anomalies such as execution of reverse shell or other remote access tools. While segmentation of workloads can be achieved in the build and deploy phases of a workload using posture checks for constructs like namespaces, network policies, and container runtime configurations to limit system calls, the same should also be enforced in the runtime phase to detect and respond to malicious activity in an automated and scalable way. The platform defines baselines and behavioral models that can specially be effective to investigate attempts at network reconnaissance, remote code execution due to zero-day application library and package vulnerabilities, and malware callbacks. Additionally, by mapping these threats and incidents to the MITRE ATT&CK tactics and techniques, it provides a common taxonomy to cloud security teams regardless of the underlying cloud application or an individual component. This helps them extend their processes and security incident runbooks to the cloud, including their ability to remediate security misconfigurations and preemptively address all the container risk categories outlined in NIST 800-190.
The post Securing Containers with NIST 800-190 and MVISION CNAPP appeared first on McAfee Blogs.
Today’s U.S. government is in a race to modernize its IT infrastructure to support ever more complicated missions, growing workloads and increasingly distributed teams—and do so facing a constantly evolving threat landscape. To support these efforts, McAfee has pursued and received a Federal Risk and Authorization Management Program (FedRAMP) Authorization designation for McAfee MVISION for Endpoint at the moderate security impact level.
This FedRAMP Moderate designation is equivalent to DoD Impact Level 2 (IL2) and certifies that the McAfee solution has passed rigorous security requirements for the increasingly complex and expanding cloud environments of the U.S. government. The FedRAMP Moderate authorization validates the McAfee solution’s implementation of the baseline 325 NIST 800-53 controls, allowing users from federal agencies, state and local government, and other industries in regulated environments to manage Controlled Unclassified Information (CUI) such as personally identifiable information (PII) and routine covered defense information (CDI).
By achieving FedRAMP Moderate Authorization for MVISION for Endpoint, McAfee can provide the command and control cyber defense capabilities government environments need to enable on-premise and remote security teams, allowing them to maximize time and resources, enhance security efficiency and boost resiliency.
McAfee MVISION for Endpoint consists of three primary components: McAfee MVISION Endpoint Detection and Response (EDR), McAfee MVISION ePolicy Orchestrator (ePO) and McAfee Endpoint Security Adaptive Threat Protection with Real Protect (ENS ATP):
- McAfee MVISION EDR simplifies investigation and response to sophisticated threat campaigns with unified detection and response (EDR) capabilities that include continuous monitoring, multi-sensor telemetry, AI-guided investigations, MITRE ATT&CK mapping and real-time hunting.
- McAfee MVISION ePO provides a cloud-native single-pane-of-glass console to manage both McAfee and other security controls, automating workflows and prioritizing risk assessment to reduce the time and tasks required to triage, investigate and respond to security incidents.
- McAfee ENS ATP prevents advanced malware from infecting the endpoint with integrated next-gen AV capabilities that include behavioral blocking, exploit prevention, machine learning and file-less threat defense. ENS can also diminish the impact of an attack with enhanced remediation capabilities, which, for example, can roll back the destructive effect of a ransomware attack by restoring affected files and negating the need for system reimaging.
Together, these solutions provide today’s U.S. government agencies the AI-guided endpoint threat detection, investigation and response capabilities they need to confront today’s ever evolving threats across a wide variety of devices. This important FedRAMP milestone is the latest affirmation of McAfee’s long-standing commitment to providing U.S. government agencies advanced, cloud-based cyber defenses to help them meet whatever mission they may confront today and in the future.
Other recent McAfee public sector achievements include:
- McAfee MVISION Cloud became the first Cloud Access Security Broker (CASB) platform to be granted a FedRAMP High Impact Provisional Authority to Operate (P-ATO) from the U.S. Government’s Joint Authorization Board (JAB). This designation certified that chief information officers from the DoD, the General Services Administration (GSA) and the Department of Homeland Security (DHS) have evaluated and approved MVISION Cloud for their increasingly complex cloud environments.
- The DoD’s Defense Innovation Unit (DIU) selected McAfee to develop a Secure Cloud Management platform around McAfee MVISION Unified Cloud Edge (UCE), which integrates its Next-Generation Secure Web Gateway, CASB and data loss prevention capabilities into one cloud-native platform.
- McAfee is working with the DoD’s Defense Information Systems Agency (DISA) to achieve DoD compliance at Impact Levels 4 and 5 to simplify how DoD agencies can procure secure systems with confidence.
Please see the following for more information on McAfee’s efforts in the FedRAMP mission:
- FedRAMP – What’s the Big Deal?
- Why FedRAMP is Essential to Enhanced Cloud Security
- Multi-Cloud Environment Challenges for Government Agencies
- McAfee MVISION Cloud Industry Recognition
- FedRAMP Marketplace
The post McAfee MVISION Solutions Meet FedRAMP Cloud Security Requirements appeared first on McAfee Blogs.
Malicious actors are increasingly taking advantage of the burgeoning at-home workforce and expanding use of cloud services to deliver malware and gain access to sensitive data. According to an Analysis Report (AR20-268A) from the Cybersecurity and Infrastructure Security Agency (CISA), this new normal work environment has put federal agencies at risk of falling victim to cyber-attacks that exploit their use of Microsoft Office 365 (O365) and misuse their VPN remote access services.
McAfee’s global network of over a billion threat sensors affords its threat researchers the unique advantage of being able to thoroughly analyze dozens of cyber-attacks of this kind. Based on this analysis, McAfee supports CISA’s recommendations to help prevent adversaries from successfully establishing persistence in agencies’ networks, executing malware, and exfiltrating data. However, McAfee also asserts that the nature of this environment demands that additional countermeasures be implemented to quickly detect, block and respond to exploits originating from authorized cloud services.
Read on to learn from McAfee’s analysis of these attacks and understand how federal agencies can use cloud access security broker (CASB) and endpoint threat detection and response (EDR) solutions to detect and mitigate such attacks before they have a chance to inflict serious damage upon their organizations.
The Anatomy of a Cloud Services Attack
McAfee’s analysis supports CISA’s findings that adversaries frequently attempt to gain access to organizations’ networks by obtaining valid access credentials for multiple users’ O365 accounts and domain administrator accounts, often via vulnerabilities in unpatched VPN servers. The threat actor will then use the credentials to log into a user’s O365 account from an anomalous IP address, browse pages on SharePoint sites, and then attempt to download content. Next, the cyberthreat actor would connect multiple times from a different IP address to the agency’s Virtual Private Network (VPN) server, and eventually connect successfully.
Once inside the network, the attacker could:
- Begin performing discovery and enumerating the network
- Establish persistence in the network
- Execute local command line processes and multi-stage malware on a file server
- Exfiltrate data
Basic SOC Best Practices
McAfee’s comprehensive analysis of these attacks supports CISA’s proposed best practices to prevent or mitigate such cyber-attacks. These recommendations include:
- Hardening account credentials with multi-factor authentication,
- Implementing the principle of “least privilege” for data access,
- Monitoring network traffic for unusual activity,
- Patching early and often.
While these recommendations provide a solid foundation for a strong cybersecurity program, these controls by themselves may not go far enough to prevent more sophisticated adversaries from exploiting and weaponizing cloud services to gain a foothold within an enterprise.
Why Best Practices Should Include CASB and EDR
Organizations will gain a running start to identifying and thwarting the attacks in question by implementing a full-featured CASB such as McAfee MVISION Cloud, and an advanced EDR solution, such as McAfee MVISION Endpoint Threat Detection and Response.
Deploying MVISION Cloud for Office 365 enables agencies’ SOC analysts to assert greater control over their data and user activity in Office 365—control that can hasten identification of compromised accounts and resolution of threats. MVISION Cloud takes note of all user and administrative activity occurring within cloud services and compares it to a threshold based either on the user’s specific behavior or the norm for the entire organization. If an activity exceeds the threshold, it generates an anomaly notification. For instance, using geo-location analytics to visualize global access patterns, MVISION Cloud can immediately alert agency analysts to anomalies such as instances of Office 365 access originating from IP addresses located in atypical geographic areas.
When specific anomalies appear concurrently—e.g., a Brute Force anomaly and an unusual Data Access event—MVISION Cloud automatically generates a Threat. In the attacks McAfee analyzed, Threats would have been generated early on since the CASB’s user behavior analytics would have identified the cyber actor’s various activities as suspicious. Using MVISION Cloud’s activity monitoring dashboard and built-in audit trail of all user and administrator activities, SOC analysts can detect and analyze anomalous behaviors across multiple dimensions to more rapidly understand what exactly is occurring when and to what systems—and whether an incident concerns a compromised account, insider threat, privileged user threat, and/or malware—to shrink the gap to remediation.
In addition, with MVISION Cloud, an agency security analyst can clearly see how each cloud security incident maps to MITRE ATT&CK tactics and techniques, which not only accelerates the entire forensics process but also allows security managers to defend against similar attacks with greater precision in the future.
Furthermore, using MVISION Cloud for Office 365, agencies can create and enforce policies that prevent the uploading of sensitive data to Office 365 or downloading of sensitive data to unmanaged devices. With such policies in place, an attacker’s attempt to exfiltrate sensitive data will be mitigated.
In addition to deploying a CASB, implementing an EDR solution like McAfee MVISION EDR to monitor endpoints centrally and continuously—including remote devices—helps organizations defend themselves from such attacks. With MVISION EDR, agency SOC analysts have at their fingertips advanced analytics and visualizations that broaden detection of unusual behavior and anomalies on the endpoint. They are also able to grasp the implications of alerts more quickly since the information is presented in a format that reduces noise and simplifies investigation—so much so that even novice analysts can analyze at a higher level. AI-guided investigations within the solution can also provide further insights into attacks.
With a threat landscape that is constantly evolving and attack surfaces that continue to expand with increased use of the cloud, it is now more important than ever to embrace CASB and EDR solutions. They have become critical tools to actively defend today’s government agencies and other large enterprises.
The post How CASB and EDR Protect Federal Agencies in the Age of Work from Home appeared first on McAfee Blogs.
Over the last few months, Zero Trust Architecture (ZTA) conversations have been top-of-mind across the DoD. We have been hearing the chatter during industry events all while sharing conflicting interpretations and using various definitions. In a sense, there is an uncertainty around how the security model can and should work. From the chatter, one thing is clear – we need more time. Time to settle in on just how quickly mission owners can classify a comprehensive and all-inclusive, acceptable definition of Zero Trust Architecture.
Today, most entities utilize a multi-phased security approach. Most commonly, the foundation (or first step) in the approach is to implement secure access to confidential resources. Coupled with the shift to remote and distance work, the question arises, “are my resources and data safe, and are they safe in the cloud?”
Thankfully, the DoD is in the process of developing a long-term strategy for ZTA. Industry partners, like McAfee, have been briefed along the way. It has been refreshing to see the DoD take the initial steps to clearly define what ZTA is, what security objectives it must meet, and the best approach for implementation in the real-world. A recent DoD briefing states “ZTA is a data-centric security model that eliminates the idea of trusted or untrusted networks, devices, personas, or processes and shifts to a multi-attribute based confidence levels that enable authentication and authorization policies under the concept of least privilege access”.
What stands out to me is the data-centric approach to ZTA. Let us explore this concept a bit further. Conditional access to resources (such as network and data) is a well-recognized challenge. In fact, there are several approaches to solving it, whether the end goal is to limit access or simply segment access. The tougher question we need to ask (and ultimately answer) is how to do we limit contextual access to cloud assets? What data security models should we consider when our traditional security tools and methods do not provide adequate monitoring? And is securing data, or at least watching user behavior, enough when the data stays within multiple cloud infrastructures or transfers from one cloud environment to another?
Increased usage of collaboration tools like Microsoft 365 and Teams, SLACK and WebEx are easily relatable examples of data moving from one cloud environment to another. The challenge with this type of data exchange is that the data flows stay within the cloud using an East-West traffic model. Similarly, would you know if sensitive information created directly in Office 365 is uploaded to a different cloud service? Collaboration tools by design encourage sharing data in real-time between trusted internal users and more recently with telework, even external or guest users. Take for example a supply chain partner collaborating with an end user. Trust and conditional access potentially create a risk to both parties, inside and outside of their respective organizational boundaries. A data breach whether intentional or not can easily occur because of the pre-established trust and access. There are few to no limited default protection capabilities preventing this situation from occurring without intentional design. Data loss protection, activity monitoring and rights management all come into question. Clearly new data governance models, tools and policy enforcement capabilities for this simple collaboration example are required to meet the full objectives of ZTA.
So, as the communities of interest continue to refine the definitions of Zero Trust Architecture based upon deployment, usage, and experience, I believe we will find ourselves shifting from a Zero Trust model to an Advanced Adaptive Trust model. Our experience with multi-attribute-based confidence levels will evolve and so will our thinking around trust and data-centric security models in the cloud.
The post Data-Centric Security for the Cloud, Zero Trust or Advanced Adaptive Trust? appeared first on McAfee Blogs.
If you are someone who works for a cloud service provider in the business of federal contracting, you probably already have a good understanding of FedRAMP. It is also likely that our regular blog readers know the ins and outs of this program.
For those who are not involved in these areas, however, this acronym may be more unfamiliar. Perhaps you have only heard of it in passing conversation with a few of your expert cybersecurity colleagues, or you are just curious to learn what all of the hype is about. If you fall into this category – read on! This blog is for you.
At first glance, FedRAMP may seem like a type of onramp to an interstate headed for the federal government – and in a way, it is.
FedRAMP stands for the Federal Risk and Authorization Management Program, which provides a standard security assessment, authorization and continuous monitoring for cloud products and services to be used by federal agencies. The program’s overall mission is to protect the data of U.S. citizens in the cloud and promote the adoption of secure cloud services across the government with a standardized approach.
Once a cloud service has successfully made it onto the interstate – or achieved FedRAMP authorization – it’s allowed to be used by an agency and listed in the FedRAMP Marketplace. The FedRAMP Marketplace is a one-stop-shop for agencies to find cloud services that have been tested and approved as safe to use, making it much easier to determine if an offering meets security requirements.
In the fourth year of the program, FedRAMP had 20 authorized cloud service offerings. Now, eight years into the program, FedRAMP has over 200 authorized offerings, reflecting its commitment to help the government shift to the cloud and leverage new technologies.
Who should be FedRAMP authorized?
Any cloud service provider that has a contract with a federal agency or wants to work with an agency in the future must have FedRAMP authorization. Compliance with FedRAMP can also benefit providers who don’t have plans to partner with government, as it signals to the private sector they are committed to cloud security.
Using a cloud service that complies with FedRAMP standards is mandatory for federal agencies. It has also become popular with organizations in the private industry, which are more often looking to FedRAMP standards as a security benchmark for the cloud services they use.
How can a cloud service obtain authorization?
There are two ways for a cloud service to obtain FedRAMP authorization. One is with a Joint Authorization Board (JAB) provisional authorization (P-ATO) and the other is through an individual agency Authority to Operate (ATO).
A P-ATO is an initial approval of the cloud service provider by the JAB, which is made up of the Chief Information Officers (CIOs) from the Department of Defense (DoD), Department of Homeland Security (DHS) and General Services Administration (GSA). This designation means that the JAB has provided a provisional approval for agencies to leverage when granting an ATO to a cloud system.
The head of an agency grants an ATO as part of the agency authorization process. An ATO may be granted after an agency sponsor reviews the cloud service offering and completes a security assessment.
Why seek FedRAMP approval?
Achieving FedRAMP authorization for a cloud service is a very long and rigorous process, but it has received high praise from security officials and industry experts alike for its standardized approach to evaluate whether a cloud service offering meets some of the strongest cybersecurity requirements.
There are several benefits for cloud providers who authorize their service with FedRAMP. The program allows an authorized cloud service to be reused continuously across the federal government – saving time, money and effort for both cloud service providers and agencies. Authorization of a cloud service also gives service providers increased visibility of their product across government with a listing in the FedRAMP Marketplace.
By electing to comply with FedRAMP, cloud providers can demonstrate dedication to the highest data security standards. Though the process for achieving FedRAMP approval is complex, it is worthwhile for providers, as it signals a commitment to security to government and non-government customers.
McAfee’s Commitment to FedRAMP
At McAfee, we are dedicated to ensuring our cloud services are compliant with FedRAMP standards. We are proud that McAfee’s MVISION Cloud is the first Cloud Access Security Broker (CASB) platform to be granted a FedRAMP High Impact Provisional Authority to Operate (P-ATO) from the U.S. Government’s Joint Authorization Board (JAB).
Currently, MVISION Cloud is in use by ten federal agencies, including the Department of Energy (DOE), Department of Health and Human Services (HHS), Department of Homeland Security (DHS), Food and Drug Administration (FDA) and National Aeronautics and Space Administration (NASA).
MVISION Cloud allows federal organizations to have total visibility and control of their infrastructure to protect their data and applications in the cloud. The FedRAMP High JAB P-ATO designation is the highest compliance level available under FedRAMP, meaning that MVISION Cloud is authorized to manage highly sensitive government data.
We look forward to continuing to work closely with the FedRAMP program and other cloud providers dedicated to authorizing cloud service offerings with FedRAMP.
In January 2020, McAfee released the results of a survey establishing the extent of the use of .GOV validation and HTTPS encryption among county government websites in 13 states projected to be critical in the 2020 U.S. Presidential Election. The research was a result of my concern that the lack of .GOV and HTTPS among county government websites and election-specific websites could allow foreign or domestic malicious actors to potentially create fake websites and use them to spread disinformation in the final weeks and days leading up to Election Day 2020.
Subsequently, reports emerged in August that the U.S. Federal Bureau of Investigations, between March and June, had identified dozens of suspicious websites made to look like official U.S. state and federal election domains, some of them referencing voting in states like Pennsylvania, Georgia, Tennessee, Florida and others.
Just last week, the FBI and Department of Homeland Security released another warning about fake websites taking advantage of the lack of .GOV on election websites.
These revelations compelled us to conduct a follow-up survey of county election websites in all 50 U.S. states.
Why .GOV and HTTPS Matter
Using a .GOV web domain reinforces the legitimacy of the site. Government entities that purchase .GOV web domains have submitted evidence to the U.S. government that they truly are the legitimate local, county, or state governments they claimed to be. Websites using .COM, .NET, .ORG, and .US domain names can be purchased without such validation, meaning that there is no governing authority preventing malicious parties from using these names to set up and promote any number of fraudulent web domains mimicking legitimate county government domains.
An adversary could use fake election websites for disinformation and voter suppression by targeting specific citizens in swing states with misleading information on candidates or inaccurate information on the voting process such as poll location and times. In this way, a malicious actor could impact election results without ever physically or digitally interacting with voting machines or systems.
The HTTPS encryption measure assures citizens that any voter registration information shared with the site is encrypted, providing greater confidence in the entity with which they are sharing that information. Websites lacking the combination of .GOV and HTTPS cannot provide 100% assurance that voters seeking election information are visiting legitimate county and county election websites. This leaves an opening for malicious actors to steal information or set up disinformation schemes.
I recently demonstrated how such a fake website would be created by mimicking a genuine county election website and then inserting misleading information that could influence voter behavior. This was done in an isolated lab environment that was not accessible to the internet as to not create any confusion for legitimate voters.
In many cases, election websites have been set up to provide a strong user experience versus a focus on mitigating concerns that they could be spoofed to exploit the communities they serve. Malicious actors can pass off fake election websites and mislead large numbers of voters before detection by government organizations. A campaign close to election day could confuse voters and prevent votes from being cast, resulting in missing votes or overall loss of confidence in the democratic system.
September 2020 Survey Findings
McAfee’s September survey of county election administration websites in all 50 U.S. states (3089 counties) found that 80.2% of election administration websites or webpages lack the .GOV validation that confirms they are the websites they claim to be.
Nearly 45% of election administration websites or webpages lack the necessary HTTPS encryption to prevent third-parties from re-directing voters to fake websites or stealing voter’s personal information.
Only 16.4% of U.S. county election websites implement U.S. government .GOV validation and HTTPS encryption.
|States||# Counties||# .GOV||% .GOV||# HTTPS||% HTTPS||# BOTH||%BOTH|
We found that the battleground states were largely in a bad position when it came to .GOV and HTTPS.
Only 29% of election websites used both .GOV and HTTPS in North Carolina, 22% in Georgia, 15.3% in Wisconsin, 10.8% in Michigan, 10.4% in Pennsylvania, and 2.4% in Texas.
While 95.5% of Florida’s county election websites and webpages use HTTPS encryption, only 6% percent validate their authenticity with .GOV.
During the January 2020 survey, only 11 Iowa counties protected their election administration pages and domains with .GOV validation and HTTPS encryption. By September 2020, that number rose to 25 as 14 counties added .GOV validation. But 72.7% of the state’s county election sites and pages still lack official U.S. government validation of their authenticity.
Alternatively, Ohio led the survey pool with 87.5% of election webpages and domains validated by .GOV and protected by HTTPS encryption. Four of Five (80%) Hawaii counties protect their main county and election webpages with both .GOV validation and encryption and 73.3% of Arizona county election websites do the same.
What’s not working
Separate Election Sites. As many as 166 counties set up websites that were completely separate from their main county web domain. Separate election sites may have easy-to-remember, user-friendly domain names to make them more accessible for the broadest possible audience of citizens. Examples include my own county’s www.votedenton.com as well as www.votestanlycounty.com, www.carrollcountyohioelections.gov, www.voteseminole.org, and www.worthelections.com.
The problem with these election-specific domains is that while 89.1% of these sites have HTTPS, 92.2% lack .GOV validation to guarantee that they belong to the county governments they claim. Furthermore, only 7.2% of these domains have both .GOV and HTTPS implemented. This suggests that malicious parties could easily set up numerous websites with similarly named domains to spoof these legitimate sites.
Not on OUR website. Some smaller counties with few resources often reason that they can inform and protect voters simply by linking from their county websites to their states’ official election sites. Other smaller counties have suggested that social media platforms such as Facebook are preferable to election websites to reach Internet-savvy voters.
Unfortunately, neither of these approaches prevents malicious actors from spoofing their county government web properties. Such actors could still set up fake websites regardless of whether the genuine websites link to a .GOV validated state election website or whether counties set up amazing Facebook election pages.
For that matter, Facebook is not a government entity focused on validating that organizational or group pages are owned by the entities they claim to be. The platform could just as easily be used by malicious parties to create fake pages spreading disinformation about where and how to vote during elections.
It’s not OUR job. McAfee found that some states’ voters could be susceptible to fake county election websites even though their counties have little if any role at all in administering elections. States such as Connecticut, Delaware, Maine, Massachusetts, New Hampshire, Rhode Island and Vermont administer their elections through their local governments, meaning that any election information is only available at the states’ websites and those websites belonging to major cities and towns. While this arrangement makes county-level website comparisons with other states difficult for the purpose of our survey, it doesn’t make voters in these states any less susceptible to fake versions of their county website.
There should be one recipe for the security and integrity of government websites such as election websites and that recipe should be .GOV and HTTPS.
What IS working: The Carrot & The Stick
Ohio’s leadership position in our survey appears to be the result of a state-led initiative to transition county election-related content to .GOV validated web properties. Ohio’s Secretary of State used “the stick” approach by demanding by official order that counties implement .GOV and HTTPS on their election web properties. If counties couldn’t move their existing websites to .GOV, he offered “the carrot” of allowing them to leverage the state’s domain.
A majority of counties have subsequently transitioned their main county websites to .GOV domains, their election-specific websites to .GOV domains, or their election-specific webpages to Ohio’s own .GOV-validated https://ohio.gov/ domain.
While Ohio’s main county websites still largely lack .GOV validation, Ohio does provide a mechanism for voters to quickly assess if the main election website is real or potentially fake. Other states should consider such interim strategies until all county and local websites with election functions can be fully transitioned to .GOV.
Ultimately, the end goal success should be that we are able to tell voters that if they don’t see .GOV and HTTPS, they shouldn’t believe that a website is legitimate or safe. What we tell voters must be that simple, because the general public lacks a technical background to determine real sites from fake sites.
For more information on our .GOV-HTTPS county website research, potential disinformation campaigns, other threats to our elections, and voter safety tips, please visit our Elections 2020 page: https://www.mcafee.com/enterprise/en-us/2020-elections.html
The post US County Election Websites (Still) Fail to Fulfill Basic Security Measures appeared first on McAfee Blogs.
As Congress prepares to return to Washington in the coming weeks, finalizing the FY2021 National Defense Authorization Act (NDAA) will be a top priority. The massive defense bill features several important cybersecurity provisions, from strengthening CISA and promoting interoperability to creating a National Cyber Director position in the White House and codifying FedRAMP.
These are vital components of the legislation that conferees should work together to include in the final version of the bill, including:
One of the main recommendations of the Cyberspace Solarium Commission’s report this spring was to further strengthen CISA, an agency that has already made great strides in protecting our country from cyberattacks. An amendment to the House version of the NDAA would do just that, by giving CISA additional authority it needs to effectively hunt for threats and vulnerabilities on the federal network.
Bad actors, criminal organizations and even nation-states are continually looking to launch opportunistic attacks. Giving CISA additional tools, resources and funding needed to secure the nation’s digital infrastructure and secure our intelligence and information is a no-brainer and Congress should ensure the agency gets the resources it needs in the final version of the NDAA.
Perhaps now more than ever before, interoperability is key to a robust security program. As telework among the federal workforce continues and expands, an increased variety of communication tools, devices and networks put federal networks at risk. Security tools that work together and are interoperable better provide a full range of protection across these environments.
The House version of the NDAA includes several provisions to promote interoperability within the National Guard, military and across the Federal government. The Senate NDAA likewise includes language that requires the DoD craft regulations to facilitate DoD’s access to and utilization of system, major subsystem, and major component software-defined interfaces to advance DoD’s efforts to generate diverse and effective kill chains. The regulations and guidance would also apply to purely software systems, including business systems and cybersecurity systems. These regulations would also require acquisition plans and solicitations to incorporate mandates for the delivery of system, major subsystem, and major component software defined interfaces.
For too long, agencies have leveraged a grab bag of tools that each served a specific purpose, but didn’t offer broad, effective coverage. Congress has a valuable opportunity to change that and encourage more interoperable solutions that provide the security needed in today’s constantly evolving threat landscape.
Creating a National Cyber Director Position
The House version of the NDAA would establish a Senate-confirmed National Cyber Director within the White House, in charge of overseeing digital operations across the federal government. This role, a recommendation of the Cyberspace Solarium Commission, would give the federal government a single point person for all things cyber.
As former Rep. Mike Rodgers argued in an op-ed published in The Hill last month, “the cyber challenge that we face as a country is daunting and complex.” We face new threats every day. Coordinating cyber strategy across the federal government, rather than the agency by agency approach we have today, is critical to ensuring we stay on top of threats and effectively protect the nation’s critical infrastructure, intellectual property and data from an attack.
The FedRAMP Authorization Act, included in the House version of the NDAA, would codify the FedRAMP program and give it a formal standing for Congressional review, a critical step towards making the program more efficient and useful for agencies across the government. Providing this program more oversight will further validate the FedRAMP approved products from across the industry as safe and secure for federal use. The FedRAMP authorization bill also includes language that will help focus the Administration’s attention on the need to secure the vulnerable spaces between and among cloud services and applications. Agencies need to focus on securing these vulnerabilities between and among clouds since sophisticated hackers target these seams that too often are left unprotected.
Additionally, the Pentagon has already committed to FedRAMP reciprocity. FedRAMP works – and codifying it to bring the rest of the Federal government into the program would offer an excellent opportunity for wide-scale cloud adoption, something the federal government would benefit greatly from.
We hope that NDAA conferees will consider these important cyber provisions and include them in the final version of the bill and look forward to continuing our work with government partners on important cyber issues like these.
The post NDAA Conference: Opportunity to Improve the Nation’s Cybersecurity Posture appeared first on McAfee Blogs.