Cyber activity by groups associated with Iran and their affiliated ecosystems have begun to surface. Much of the visible activity currently appears to have limited immediate operational impact as it consists primarily of website defacements, distributed denial-of-service (DDoS) attacks, coordinated messaging campaigns, phishing attempts, and reconnaissance against exposed digital infrastructure. While these incidents may appear opportunistic or symbolic, historical patterns of such behavior suggest that this activity can represent early-stage signaling, pressure, and preparatory shaping operations rather than isolated disruption.

Iran’s cyber ecosystem operates through a layered structure that includes state-linked advanced persistent threat (APT) groups, proxy actors, hacktivist personas, and sympathetic foreign collectives. Even when not centrally coordinated, these actors often converge on the same narratives and target sets during geopolitical crises, enabling simultaneous visible disruption and covert intelligence-driven intrusion activity. As the conflict evolves, this ecosystem provides a scalable and deniable tool for retaliation that can gradually intensify.

It is very likely that the cyber risk will widen accordingly as the current conflict continues. Governments and organizations located in regions hosting U.S. military infrastructure or closely aligned with U.S. and Israeli positions may face increased exposure, particularly across sectors such as logistics, critical infrastructure, public administration, energy, and telecommunications.

Strategic context and operational trends

Iran does not operate according to a single publicly articulated cyberwarfare doctrine. Instead, its cyber strategy has evolved pragmatically as part of the country’s broader asymmetric security model. Since 2010, there has been an expansion of its cyber capabilities as instruments for intelligence gathering, internal control, retaliation, coercive messaging, and regional influence. Cyber operations are therefore best understood not as a separate military domain with a fully transparent doctrine, but as an adaptable component of the regime’s survival and strategic competition against outsiders.

Broadly speaking, Iranian cyber activity tends to serve three overlapping strategic objectives. The first is regime security and domestic control, in which cyber tools support surveillance, information control, and disruption of dissident or opposition networks. The second is strategic intelligence collection, in which state-linked actors target governments, defense organizations, technology providers, telecommunications firms, and critical infrastructure to gather political, military, and economic intelligence. The third is coercive signaling and regional influence, in which cyber operations impose costs on adversaries, shape perceptions, and demonstrate retaliatory capability while remaining below the threshold of overt interstate war.

A key feature of this regime’s approach is the development of long-term access. Iranian APT groups often conduct sustained intrusion campaigns focused not only on immediate collection but also on access persistence, credential harvesting, and network familiarity. In a crisis environment, these pre-existing footholds can become strategically important, supporting either intelligence collection or later disruptive operations. This is one reason current low-visibility intrusions deserve as much analytical attention as public hacktivist claims. The visible DDoS or defacement campaign may dominate headlines, but the more significant strategic risk often lies in covert access established inside other targets. 

Another defining feature of Iran’s cyber strategy is its layered operational model. State-linked APT groups frequently operate alongside contractors, proxies, persona-driven influence actors, and hacktivist collectives. This structure offers several advantages: it creates deniability, increases operational tempo; broadens the range of possible targets; and allows Iran-aligned ecosystems to combine disruptive spectacle with intelligence-driven depth. During periods of heightened tension, this blended model enables visible pressure operations to coexist with quieter espionage or pre-positioning campaigns. Current reporting on the conflict strongly supports this interpretation, with activist and proxy campaigns surging in parallel to concern over state-linked phishing, malware, wipers, and infrastructure-focused targeting.

Iran’s threat actor landscape

State sponsored 

Iran’s cyber capabilities are distributed across a hybrid ecosystem of state institutions, intelligence services, military structures, and semi-official operators. Rather than relying on a single centralized cyber command, Tehran appears to allocate responsibilities across different organs, primarily the Islamic Revolutionary Guard Corps and the Ministry of Intelligence and Security, with support from contractors, front entities, and affiliated personas. Strategic coordination of the cyber domain is overseen by the Supreme Council of Cyberspace, while operational activities are carried out through a mix of official and semi-official channels.

IRGC-linked actors

The Islamic Revolution Guard Corp (IRGC) maintains one of Iran’s most visible offensive cyber capabilities and has been associated with cyber espionage, influence operations, credential theft, and politically aligned disruptive activity. Among the principal IRGC-linked actors are APT35 (also known as Charming Kitten or Mint Sandstorm), which has long conducted spear-phishing and credential-harvesting operations against diplomats, journalists, researchers, and policy communities; APT42 is an actor particularly associated with surveillance and social engineering targeting dissidents, activists, journalists, and policy experts. Cotton Sandstorm (also known as Holy Souls and Emennet Pasargad), meanwhile, has been linked to both espionage and influence-oriented operations targeting regional adversaries and Western institutions. Recent reporting also highlights continued concern around malware associated with this broader actor set, including infostealing and espionage tooling used in phishing-led operations.

MOIS-linked actors

The Ministry of Intelligence and Security (MOIS) operates parallel cyber capabilities that tend to emphasize intelligence collection, long-term access, and strategic espionage. The most prominent groups in this cluster include MuddyWater and OilRig (also known as APT34). CISA has previously described MuddyWater as an Iranian government-sponsored actor conducting cyber espionage and malicious cyber operations across multiple sectors, while current reporting continues to place the group among the most operationally relevant Iranian state-linked threats in the present crisis environment. OilRig remains a longstanding espionage actor focused on governments, financial institutions, energy entities, and other strategic organizations.

These actors illustrate Iran’s distributed cyber-operational model: Intelligence-driven access development, influence, psychological pressure, and opportunistic disruptive action are not separate lines of effort but parts of a broader strategic continuum.

Parallel hacktivist and proxies

Beginning in June 2025, a noticeable surge in hacktivist and proxy cyber activity accompanied the broader escalation of tensions in the Middle East. This reflects a recurring pattern observed during previous geopolitical crises, in which ideologically aligned non-state cyber actors mobilize alongside, or in parallel with, state-linked cyber operations. In the current confrontation, this dynamic has again expanded the cyber landscape beyond traditional state-directed espionage or sabotage.

By early March 2026, several dozen hacktivists or proxy collectives emerged related to the conflict. These groups vary significantly in capability and reliability. Some focus on distributed denial-of-service (DDoS) attacks, while others conduct website defacements or hack-and-leak campaigns. Some primarily amplify claims of compromise that are exaggerated or only partially verifiable. Their significance, therefore, lies less in technical sophistication than in the cumulative pressure they place on defenders and the broader information environment.

In crisis situations, this activity can produce strategic effects. Numerous low-impact incidents can consume defensive resources, complicate attribution, and obscure more sophisticated intrusions occurring simultaneously. Hacktivist campaigns may therefore function as distractions, signals, or psychological pressure while more capable actors pursue quieter access to high-value networks. For this reason, the analytical distinction between advanced persistent threat (APT) activity and hacktivism can become blurred during periods of geopolitical confrontation.

Several collectives active in the current environment publicly position themselves as ideologically aligned with Iran or with members of the so-called “Axis of Resistance.” Among the more visible groups are Handala Hack Team, Dienet, FAD Team, APT IRAN, Cyber Islamic Resistance, and Fatimion cyber team. These actors frequently frame their operations as retaliatory cyber campaigns targeting Israeli, Western, or allied regional entities, claiming responsibility for activities such as website defacements, DDoS attacks, and hack-and-leak operations targeting mainly government, telecommunications, energy, and financial entities. Although many claims remain difficult to verify independently, their messaging strategy often emphasizes their psychological and reputational impact.

In parallel, several pro-Russia hacktivist groups have also engaged in operations linked to the confrontation, including NoName057(16), Sever Killer, and Russian Legion. These groups typically conduct large-scale DDoS campaigns targeting government portals, financial services, and transportation or telecommunications infrastructure in states perceived as supporting Israel or broader Western policy positions. Their participation illustrates how regional conflicts can attract cyber actors from outside the immediate theater when ideological alignment or strategic narratives converge.

Cyber activities linked to the ongoing conflict

Iranian APT group operations 

Beyond the highly visible hacktivist activity circulating on social media, defacement platforms, and Telegram channels, a quieter but more strategically significant layer of cyber operations is unfolding through Iranian state-linked APT groups. These operations appear ongoing and aligned with broader geopolitical objectives tied to the current conflict environment.

Recent threat reporting indicates continued operations by the Iranian APT group, MuddyWater, which is widely assessed to be linked to MOIS. Since at least early February 2026, reporting has suggested potential compromises or attempted intrusions targeting organizations associated with the United States and allied interests. 

According to public reporting, activity linked to the group was reportedly observed within the networks of a United States–based bank, a United States airport, a nonprofit organization operating across the United States and Canada, and a software company with operations in Israel. In several of these incidents, threat actors reportedly deployed a previously undocumented backdoor known as Dindoor, suggesting a coordinated, ongoing campaign rather than isolated compromise events.

Hacktivist and proxy disruption activities

The most visible form of cyber activity so far remains hacktivist and proxy-led disruption.

DDoS attacks are among the most common tactics employed by hacktivist groups. Pro-Russia groups such as NoName057(16) and Server Killers, along with other pro-Iran collectives affiliated with them, have been linked to waves of coordinated DDoS attacks against Israel, Qatar, Bahrain, and other politically symbolic targets. These attacks are generally inexpensive and cause only short-term technical damage, but they remain strategically useful because they disrupt public services, tie up defense resources, generate media coverage, and fuel the narrative of a sustained cyber response.

⠀

Website defacement also remains a common tactic. Groups such as FAD Team, 313, and Cyber Islamic Resistance have been associated with claims of attacks on several websites. Although defacements are technically simple to execute, they remain analytically significant: They are highly visible, rapidly disseminated, and psychologically impactful, often creating an exaggerated perception of widespread systemic compromise.

Data breaches represent a far more significant dimension of cyber operations. The Iranian-aligned group Handala, in particular, continues to blend political messaging with claims of data theft and the selective release of allegedly compromised information. The group recently asserted that it had infiltrated a Saudi energy company and exfiltrated internal documents, framing the operation as a combination of data exfiltration, coercive pressure, and psychological warfare targeting the energy sector. Even when the full authenticity of released datasets cannot be independently verified, the publication of partially credible material can still generate substantial reputational damage and potential operational disruption for affected organizations.

Targeting critical infrastructure has emerged as one of the most concerning aspects of the current cyber activity by pro-Iran hacktivists and proxy collectives. Groups operating in this ecosystem, including Iranian APTs, Handala, and networks associated with the Cyber Islamic Resistance umbrella, have publicly claimed operations targeting infrastructure across the region. Recent Telegram posts indicate that an Iranian APT group claimed responsibility for attempts to sabotage Jordanian critical infrastructure, while other Iran-aligned hacktivist personas have asserted access to sectors including fuel systems, water utilities, and other operational technology environments.

In a separate case, the Handala Hack Team has alleged that it compromised both Oil and gas companies in the United Arab Emirates and Israel, claiming to have exfiltrated more than 1.3 TB of sensitive data from oil and gas sector networks. These claims, which would represent a significant intrusion into Middle Eastern energy infrastructure if confirmed, have circulated primarily through hacktivist communication channels and social media reporting and have not been independently verified.

⠀

Although many of these claims remain difficult to independently verify, the recurring focus on industrial control systems and essential services is analytically significant. Hacktivist collectives aligned with Iranian geopolitical narratives frequently leverage infrastructure-related claims as part of information operations designed to amplify perceived impact, generate psychological pressure, and signal the potential for escalation into operational technology environments. Even when technical disruption is limited or exaggerated, the persistent narrative around infrastructure compromise can shape defensive priorities and highlight potential escalation pathways within the broader cyber conflict.

Sectoral exposure and risk landscape

In the current geopolitical context, cyberattacks extend far beyond military networks and defense institutions. Modern cyber operations increasingly aim to affect the broader ecosystem that supports government activity, economic stability, and public trust. Consequently, adversaries seek not only technically vulnerable targets but also organizations whose compromise or disruption can increase visibility, influence public perception, or create cascading effects across interconnected systems.

A successful intrusion into a widely used service provider, a major infrastructure operator, or a publicly accessible institution can quickly produce consequences that extend far beyond the initial target, affecting supply chains, service availability, and public confidence. In this context, cyber operations often serve multiple purposes simultaneously: intelligence gathering, strategic positioning within critical networks, and generating disruption or exerting influence during periods of heightened geopolitical tension.

At present, several sectors appear particularly exposed:

• Government institutions and public administration

• Defense and aerospace industry

• Energy sector, including oil, gas, and electricity

• Telecommunications providers

• Financial services

• Transportation systems

However, the risk landscape extends beyond these sectors themselves. Organizations that form part of the broader digital supply chain supporting these industries may also represent attractive entry points. This includes cloud service providers, managed service providers, technology vendors, and other third-party platforms that maintain privileged access to client environments. Compromising such intermediaries can allow adversaries to reach high-value targets indirectly. By gaining access to a supplier or service provider, attackers may obtain pathways into multiple networks simultaneously, access sensitive information, or move laterally across interconnected operational systems. Supply chain compromise, therefore, offers both scale and stealth, making it an increasingly common tactic in sophisticated cyber campaigns.

Geopolitical alignment can also influence targeting decisions. Organizations based in countries that host United States military assets or are publicly aligned with United States or Israeli policy positions may attract additional attention from adversaries. In these cases, targeting can carry symbolic, political, or strategic value beyond the immediate technical impact of the intrusion. Within this environment, cyber exposure can generally be understood through three overlapping targeting dynamics.

Symbolic targets include municipalities, universities, media outlets, and public institutions. These organizations may be targeted primarily for visibility, messaging, or propaganda purposes. Even limited disruption or data exposure can generate headlines and amplify the perceived reach of the attackers.

Operational targets include sectors that support everyday economic and social activity, such as telecommunications providers, transportation systems, payment networks, and fuel distribution infrastructure. Disruptions in these areas can quickly affect daily life, creating public anxiety and increasing pressure on authorities to respond.

Strategic targets consist of entities whose compromise offers long-term intelligence or operational value. This category includes defense contractors, major financial institutions, government networks, and operators of critical infrastructure. In these cases, adversaries may prioritize persistence and stealth to collect intelligence, monitor decision-making processes, or maintain access that could be leveraged during future crises.

Taken together, these targeting patterns illustrate a broader shift in cyber operations: Attackers are increasingly selecting targets not only for their intrinsic value, but for the broader political, economic, and societal effects that disruption or compromise can produce.

What should organizations monitor?

In the current phase of the conflict, organizations should continue to monitor for indicators that activity is shifting from opportunistic disruption toward deliberate intrusion or access preparation.

Internet-facing infrastructure is often the initial entry point. Elevated scanning or probing of public websites, VPN gateways, remote access portals, cloud services, and email authentication infrastructure may indicate early reconnaissance. While some scanning is routine, sudden increases in probing activity or authentication attempts should be treated as potential precursors to intrusion.

Phishing and social engineering campaigns are also likely to intensify. Threat actors may exploit developments in the conflict by using lures that reference civil defense alerts, battlefield updates, humanitarian messaging, or urgent requests that appear to originate from leadership or trusted partners. In some cases, malicious applications or replicas of legitimate services may be used to harvest credentials or deploy malware.

Credential misuse remains a primary access vector. Security teams should monitor for abnormal authentication patterns, including logins from unusual geographic locations, access at unexpected hours, repeated failed logins followed by success, changes to multi-factor authentication settings, or the creation of new privileged accounts.

Organizations operating critical infrastructure should closely monitor activities within their operational environments. Suspicious access to remote management platforms, unusual connectivity between IT and OT networks, or unexpected activity involving engineering workstations or vendor access channels may signal reconnaissance within sensitive systems.

Finally, monitoring the broader information environment can provide early warning and signal the need to increase monitoring. Hacktivist groups frequently use platforms such as Telegram and X to circulate target lists, claim attacks, or release fragments of allegedly stolen data tied to geopolitical events. Tracking these channels can help organizations identify potential targets and strengthen their defensive posture before malicious activity reaches their networks.

Additional reading from Rapid7 Labs, for Rapid7 customers: Rapid7 Detection Coverage for Iran-Linked Cyber Activity

In this episode of Experts on Experts: Commanding Perspectives, Craig Adams chats with Sabeen Malik, VP of Public Policy & Government Affairs at Rapid7, about what’s broken (and what’s promising) in today’s regulatory landscape.

Sabeen pulls from her experience across diplomacy, operations, and government relations to highlight where policy too often fails to account for how risk actually works. From insider threats to government shutdowns, it’s a sharp, timely look at how security leaders should approach strategy, structure, and compliance going into 2026.

Key themes:

• The growing trust gap between public, private, and institutional actors

• Why insider threats are a cultural problem, not just a controls one

• Where UK and US guidance is falling short on resilience

• What small and midsized businesses are still missing

• Why AI, exposure, and threat governance need to be connected

Whether you're thinking about AI use cases or modern regulation fatigue, this episode offers a much-needed reset.

Watch the full video below:

⠀

For federal, state, and local agencies, the Salt Typhoon campaign underscores an uncomfortable truth: Persistent nation-state threats are no longer limited to federal intelligence targets. They are probing every layer of U.S. governance – from military networks to state communications systems and the vendors that support them.

Why Salt Typhoon matters to the public sector

Salt Typhoon isn’t just another advanced persistent threat. It represents a deliberate, long-term effort to establish access across networks that form the backbone of U.S. government operations. According to the report, the group has compromised at least eight major U.S. telecom carriers and a state Army National Guard network. As much as espionage, this type of activity suggests pre-positioning for disruption.

This “sleeper agent” approach means the adversary is already inside and quietly gathering intelligence, mapping networks, and waiting for the right moment to act. The lesson for the public sector is clear: Protecting sensitive data and systems can’t stop at the perimeter. Defenders must assume compromise and proactively design systems for containment, resilience, and recovery.

Key takeaways from the threat report

The Salt Typhoon threat report highlights several themes with direct implications for public sector security teams:

• Espionage with operational intent: While data theft is the primary goal, the group’s sustained presence in military and telecom environments points to potential for sabotage in a crisis scenario.

• Supply chain and partner risk: Many intrusions began not with direct government access but through compromised service providers, contractors, and telecom vendors.

• Deep persistence and stealth: The actor’s toolkit – including the Demodex rootkit and backdoors such as SparrowDoor and GhostSpider – allows it to maintain hidden access for years.

• Global reach, local impact: Though Salt Typhoon targets critical infrastructure worldwide, the U.S. remains its primary focus. Federal, state, and local entities must consider themselves part of that target set.

Top 5 defensive priorities for agencies

Adopt a zero trust mindset

Assume compromise. Every connection, device, and user must be continuously verified. Critical systems such as emergency communications, intelligence databases, or public safety platforms should be isolated so that no single intrusion can grant broad access. Network segmentation and strict identity controls are essential, even for internal traffic.

Tighten patch and vulnerability management

Salt Typhoon frequently exploits known vulnerabilities in VPNs, firewalls, and email servers. Agencies should prioritize high-impact systems for accelerated patching and adopt continuous vulnerability scanning. Rapid7 research found that even short delays in patch cycles can leave agencies exposed to exploitation windows measured in days, not weeks.

Strengthen identity and credential hygiene

Nearly every Salt Typhoon campaign leveraged stolen credentials. Federal and state agencies should enforce multi-factor authentication (MFA) universally, deploy privileged access management (PAM) tools, and routinely audit accounts for privilege creep. Temporary credentials, monitored admin sessions, and “no standing privileges” policies help prevent escalation.

Enhance detection with extended visibility

The group’s hallmark is stealth. Agencies should deploy endpoint detection and response (EDR) or extended detection and response (XDR) solutions that can flag subtle behaviors such as lateral movement through tools like PsExec and WMIC. Continuous monitoring of outbound traffic – particularly encrypted HTTPS and DNS channels – is vital to spotting command-and-control (C2) communications.

Build resilience through collaboration

No single organization can manage this threat alone. Information sharing between agencies and trusted partners remains critical. Early sharing of indicators and tactics can expose coordinated campaigns faster and improve sector-wide readiness.

What this means for the public sector

Salt Typhoon’s long-term infiltration strategy is a reminder that modern cyber defense is as much about proactive endurance as innovation. For every exploit patched and alert investigated, these adversaries persist. However, the cost of a breach could be astronomical compared to the cost of a solution like Rapid7’s vulnerability management (VM) capabilities that can help quickly prioritize the vulnerabilities most critical for remediation.

This means federal workers can more effectively meet the demanding requirements of mandates like those in the new executive order. Both Rapid7's VM and cloud security capabilities provide the continuous monitoring required for maintaining a strong security posture.

Both federal and state defenders should emphasize proactive threat hunting and cross-sector coordination. Those working specifically in the state, local, and educational (SLED) sector as well as non-criminal justice agencies (NCJAs), however, are becoming more frequent targets due to compliance-related issues. This can be attributed to several factors:

• Government agencies are considered an easy target by malicious actors.

• Small local agencies may inadvertently provide malicious actors with a portal into sensitive data in Criminal Justice Information Services (CJIS) databases.

• Law enforcement and public safety agencies – as well as their third-party vendors – are increasingly using unauthorized mobile devices to transmit and store CJIS data.

To underscore all of the above, state and local governments are typically less secure and less funded than their federal counterparts. However, a solution like Rapid7’s automated workflow capabilities can provide the AI-powered automation needed to streamline security operations and enforce compliance standards across hybrid cloud environments.  

The message is simple-yet-urgent: Long before conflict begins, sophisticated espionage campaigns attempt to shape the digital battlefield to the advantage of threat actors. Whether you manage a state network, a fusion center, or a federal communications platform, the same principles apply: visibility, verification, and vigilance.

Stay ahead of adversaries who plan years ahead. Read the full Rapid7 Threat Focus: Salt Typhoon report to understand how your agency can safeguard and strengthen the defenses of critical systems that keep the United States running.

SharePoint remains a widely deployed collaboration platform in federal, state, and local agencies, resulting in the need for urgent attention among public sector organizations. The combination of its ubiquity and sensitive data handling makes it a prime target. Recent reporting shows attackers are moving fast to take advantage of this flaw, and many agencies faced tight deadlines this summer to apply mitigations under federal directives.

This isn’t the first time SharePoint has been targeted. Earlier this year, we analyzed this exploitation in depth in a previous blog. The September threat report now confirms that nefarious activity has accelerated, with attackers demonstrating a high level of interest in leveraging this vector against both commercial and government entities.

Why public sector agencies should pay close attention

Government systems are uniquely attractive targets. Agencies hold sensitive citizen data, manage critical infrastructure, and often operate under resource constraints that slow down patching cycles. SharePoint’s integration across agencies makes it a high-value target: Compromise of a single system can quickly escalate into broader access.

According to reporting, agencies had to scramble this summer to meet remediation deadlines set by the Cybersecurity and Infrastructure Security Agency (CISA). For state and local organizations without the same centralized directives, the challenge is even greater as many remain vulnerable while attackers continue to scan and exploit exposed SharePoint servers globally. Cumulatively, we know that:

• Exploitation is ongoing. Threat actors continue to weaponize the vulnerability, with automated scanning campaigns followed by hands-on-keyboard activity once they gain access.

• Targets are broad. Government, education, and healthcare organizations are among those most at risk due to widespread SharePoint use.

• Post-exploitation tactics are consistent. Attackers are using the foothold to deploy web shells, move laterally, and harvest credentials, setting the stage for ransomware or data theft.

These key takeaways reinforce the urgency for public sector defenders to validate their exposure and strengthen monitoring.

Steps agencies can take now

To reduce risk and build resilience against SharePoint exploitation, public sector security teams should prioritize the following.

1. Patch or mitigate immediately. If you haven’t yet applied Microsoft’s security update for CVE-2025-53770, this is your top priority. For systems that cannot be patched quickly, apply CISA’s published workarounds.

2. Validate exposure. Use exposure management practices to confirm which systems are internet-facing and whether compensating controls are in place – visibility into your true attack surface is absolutely critical.

3. Hunt for signs of compromise. Review logs for unusual authentication attempts, web shell activity, or anomalous SharePoint process behavior. Rapid7 managed detection and response (MDR) customers benefit from proactive threat hunts that specifically look for exploitation indicators in environments like SharePoint.

4. Strengthen detection and response. Public sector agencies often lack 24/7 monitoring resources. MDR services can act as a force multiplier, helping agencies contain threats before they escalate.

Looking ahead

Attackers are opportunistic – as long as SharePoint remains essential to public sector collaboration, it will remain a target. By applying patches quickly, validating exposures, and investing in continuous detection, agencies can reduce the likelihood that a SharePoint compromise becomes a larger breach.

The threat report provides a deeper dive into the tactics we’re observing and recommendations for defense. For public sector leaders, this is a chance to take stock of current defenses, pressure-test monitoring, and ensure that your agency is positioned to withstand active exploitation campaigns.

Stay ahead of these threats. Read the full Rapid7 September 2025 Threat Report for a complete analysis and practical guidance.

But what does this really mean for your agency? Let’s dig deeper.

Understanding FedRAMP authorization and why it matters

FedRAMP (Federal Risk and Authorization Management Program) is the gold standard for assessing and authorizing cloud service providers that work with the U.S. government. Receiving this designation means Rapid7 has met the federal government’s most rigorous security, compliance, and risk management standards.

Rapid7’s FedRAMP Moderate Authorization means agencies can:

• Accelerate ATO timelines using an authorized, vetted platform

• Align with NIST 800-53, CMMC, and TIC 3.0 with built-in compliance support

• Operate confidently in hybrid, cloud, or containerized environments with a platform that meets federal security requirements out of the box

From procurement to deployment, InsightGovCloud reduces friction, increases trust, and enables teams to act faster.

InsightGovCloud: a unified platform purpose-built for the public sector

The InsightGovCloud Platform brings together multiple capabilities within a unified FedRAMP-authorized environment:

• InsightVM: A comprehensive vulnerability management tool offering deep asset visibility, risk-based prioritization, and automated remediation workflows.

• InsightCloudSec: Enables continuous posture management, real-time visibility, and misconfiguration detection across multi-cloud and Kubernetes environments.

• InsightConnect: A security orchestration, automation, and response (SOAR) platform that speeds up detection and response across hybrid cloud and on-prem systems.

And with the Insight Agent now running in FIPS-compliant mode and hosted in a U.S.-based cloud, federal teams can ensure end-to-end compliance with confidence.

Solving real-world challenges for federal agencies

Modern federal networks are a mix of legacy infrastructure, sprawling cloud assets, and sensitive data. 

Here’s how Rapid7 helps to address this complex reality:

• Vulnerability management for legacy & cloud: Unify vulnerability detection and remediation across physical, virtual, and cloud assets. Whether agentless or agent-based, no asset is left unmonitored.
• Risk-aware prioritization that scales: InsightVM goes beyond CVE counts. Active Risk scoring factors in exploitability, real-world intel, and business context — empowering security teams to focus on what matters most.
• Cloud-native posture & exposure management: InsightCloudSec offers unparalleled support for multi-cloud and containerized environments. Gain instant visibility, enforce policies, and drive compliance in real time.
• Automated detection & response: With InsightConnect, you can automate response across your toolchain — reducing investigation time and improving coordination across SOC, IT, and DevOps teams.
• Compliance with confidence: Support for frameworks including FedRAMP, NIST 800-53, CMMC, CIS Benchmarks, DISA STIGs, and more. Automate evidence collection, track progress, and simplify audits.

Why now?

Threat actors are becoming more sophisticated, and the attack surface is growing faster than most teams can manage. The 2024 Rapid7 Attack Intelligence Report found that 43% of exploited CVEs were zero-day vulnerabilities, and over half were exploited within a week of disclosure.

Federal agencies can’t afford slow, siloed security tools. Whether you're modernizing for EO 14028 compliance, preparing for CMMC assessments, or tackling TIC 3.0 mandates, Rapid7 delivers the capability and clarity to move faster than your adversaries.

Looking ahead

Achieving FedRAMP Authorization is not just a badge, it’s a commitment to working with the public sector as a true partner. We look forward to building deeper collaborations with federal security teams, delivering the visibility, automation, and intelligence needed to protect government systems and the people they serve.

To learn more about Rapid7’s solutions for the public sector, visit our Government Solutions page; for more FedRAMP specific information & resources, explore our FedRAMP compliance hub page.

Rapid7 has successfully completed an Information Security Registered Assessors Program (IRAP) assessment to PROTECTED Level for several of our Insight Platform solutions.

What is IRAP?

An IRAP assessment is an independent assessment of the implementation, appropriateness, and effectiveness of a system’s security controls. Achieving IRAP PROTECTED status means Australian Government agencies requiring PROTECTED level controls can access our industry-leading, practitioner-first security solutions. Meeting this status further strengthens our position as a trusted partner for Australian government organizations seeking to enhance their cybersecurity posture.

Rapid7 is one of the only vendors to be IRAP-assessed across what we consider a consolidated cybersecurity operation. This places us in a unique position to supply services across federal, state, and local government in Australia. It provides our government customers with the confidence that we have the right governance and controls in place for our own business in order to deliver that service effectively for our customers, specifically covering:

• Vulnerability management on traditional infrastructure
• Endpoints
• The secure implementation of web applications
• Detection and response to alerts or threats
• The ability to securely automate workflows

Why is being IRAP PROTECTED important?

Being IRAP-assessed demonstrates our commitment to providing secure and reliable information security services for Government Systems, Cloud Service Providers, Cloud Services, and Information and Communications Technology (ICT) Systems, and more widely to our Australian customers.

Importantly, it highlights how we take the shared responsibility model extremely seriously. It also shows we’re protecting our customers’ information and data across their traditional infrastructure and in the cloud.

Which solutions are approved?

Solutions assessed and approved for PROTECTED Level include InsightIDR (detection and response), InsightVM (vulnerability management), InsightAppSec (application security), and InsightConnect (orchestration and automation). These solutions provide a comprehensive security platform to help government agencies tackle the challenges of today's evolving cybersecurity landscape.

The successful completion of the IRAP assessment at the PROTECTED level demonstrates our commitment to supporting Australian government customers. It means they have access to a comprehensive security platform necessary to tackle the ever-evolving challenges of today's cybersecurity landscape.

As more government agencies migrate to hybrid cloud environments, we can help them better manage the growing complexity of identifying and securing the attack surface.

As attackers become increasingly sophisticated, better armed, and faster, the IRAP assessment is yet another string in our cybersecurity bow, showcasing our potential to support Australian Government agencies and more widely, our customers.

NSTAC’s mission is to to provide the best possible technical information and policy advice to assist the President and other stakeholders responsible for critical national security and emergency preparedness (NS/EP) services. The committee advises the White House on the reliability, security, and preparedness of vital communications and information infrastructure. It is focused on five key themes:

• Strengthening national security
• Enhancing cybersecurity
• Maintaining the global communications infrastructure
• Assuring communications for disaster response
• Addressing critical infrastructure interdependencies and dependencies

Thomas joins a talented group of telecommunications and security executives from companies such as AT&T, Microsoft, Cisco, Lockheed Martin, T-Mobile, and Verizon. These executives bring diverse perspectives backed by years of unique industry experience.

“It is an extreme honor and privilege to be named to the President’s National Security Telecommunications Advisory Committee,” said Thomas. “I look forward to the remarkable opportunity to provide cybersecurity guidance to the President’s administration and to work alongside and learn from  this talented group of individuals, many of whom I’ve admired throughout my career.”

“Rapid7’s Insight platform goes beyond threat detection by enabling organizations to quickly respond to attacks with intelligent automation,” said Alex Whitworth, Sales Director who leads the Rapid7 Team at Carahsoft.

“We are thrilled to work with Rapid7 and our reseller partners to deliver these advanced cloud risk management and threat detection solutions to NASPO members to further protect IT environments across the SLED space.”

NASPO ValuePoint is a cooperative purchasing program facilitating public procurement solicitations and agreements using a lead-state model. The program provides the highest standard of excellence in public cooperative contracting. By leveraging the leadership and expertise of all states and the purchasing power of their public entities, NASPO ValuePoint delivers the highest valued, reliable and competitively sourced contracts, offering public entities outstanding prices.

“In partnership with Carahsoft and their reseller partners, we look forward to providing broader availability of the Insight platform to help security teams better protect their organizations from an increasingly complex and volatile threat landscape,” said Damon Cabanillas, Vice President of Public Sector Sales at Rapid7.

The Rapid7 Insight platform is available through Carahsoft’s NASPO ValuePoint Master Agreement #AR2472. For more information, visit https://www.carahsoft.com/rapid7/contracts.

“With the ever-evolving threat landscape, it is important that the public sector has the resources to defend against sophisticated cyber attacks and vulnerabilities,” said Alex Whitworth, Sales Director who leads the Rapid7 Team at Carahsoft.

“The addition of Rapid7’s cloud risk management and threat detection solutions to our GSA Schedule gives Government customers and our reseller partners expansive access to the tools necessary to protect their critical infrastructure.”

With the GSA contract award, Rapid7 is able to significantly expand its availability to Federal, State, Local, and Government markets. In addition to GSA, Rapid7 was recently added to the Department of Homeland Security (DHS) Continuous Diagnostics Mitigation’s Approved Products List.

“As the attack surface continues to increase in size and complexity, it’s imperative that all organizations have access to the tools and services they need to monitor risk across their environments,” said Damon Cabanillas, Vice President of Public Sector Sales at Rapid7.

“This contract award is a massive step forward for Rapid7 as we work to further serve the public sector.”

Rapid7 is available through Carahsoft’s GSA Schedule No. 47QSWA18D008F. For more information on Rapid7’s products and services, contact the Rapid7 team at Carahsoft at Rapid7@carahsoft.com.

This chart is intended as an educational tool to enhance the security community’s awareness of upcoming public policy actions, and provide a big picture look at how the incident reporting regulatory environment is unfolding. Please note, this chart is not comprehensive (there are even more incident reporting regulations out there!) and is only current as of August 8, 2022. Many of the regulations are subject to change.

This summary is for educational purposes only and nothing in this summary is intended as, or constitutes, legal advice.

Peter Woolverton led the research and initial drafting of this chart.

Additional reading:

• Avoiding Smash and Grab Under the SEC’s Proposed Cyber Rule
• Navigating the Evolving Patchwork of Incident Reporting Requirements
• New US Law to Require Cyber Incident Reports
• How Ransomware Is Changing US Federal Policy
  
  

In 2018, the Cybersecurity and Infrastructure Security Agency (CISA) established the Information and Communications Technology (ICT) Supply Chain Risk Management (SCRM) Task Force as a public-private joint effort to build partnerships and enhance ICT supply chain resilience. To date, the Task Force has worked on 7 Executive Orders from the White House that underscore the importance of supply chain resilience in critical infrastructure.

Background

The ICT-SCRM Task Force is made up of members from the following sectors:

• Information Technology (IT) – Over 40 IT companies, including service providers, hardware, software, and cloud have provided input.
• Communications – Nearly 25 communications associations and companies are included, with representation from the wireline, wireless, broadband, and broadcast areas.
• Government – More than 30 government organizations and agencies are represented on the Task Force.

These three sector groups touch nearly every facet of critical infrastructure that businesses and government require. The Task Force is dedicated to identifying threats and developing solutions to enhance resilience by reducing the attack surface of critical infrastructure. This diverse group is poised perfectly to evaluate existing practices and elevate them to new heights by enhancing existing standards and frameworks with up-to-date practical advice.

Working groups

The core of the task force is the working groups. These groups are created and disbanded as needed to address core areas of the cyber supply chain. Some of the working groups have been concentrating on areas like:

• The legal risks of information sharing
• Evaluating supply chain threats
• Identifying criteria for building Qualified Bidder Lists and Qualified Manufacturer Lists
• The impacts of the COVID-19 pandemic on supply chains
• Creating a vendor supply chain risk management template

Ongoing efforts

After two years of producing some great resources and rather large reports, the ICT-SCRM Task Force recognized the need to ensure organizations of all sizes can take advantage of the group’s resources, even if they don’t have a dedicated risk management professional at their disposal. This led to the creation of both a Small and Medium Business (SMB) working group, as well as one dedicated to Product Marketing.

The SMB working group chose to review and adapt the Vendor SCRM template for use by small and medium businesses, which shows the template can be a great resource for companies and organizations of all sizes.  

Out of this template, the group described three cyber supply chain scenarios that an SMB (or any size organization, really) could encounter. From that, the group further simplified the process by creating an Excel spreadsheet that provides a document that is easy for SMBs to share with their prospective vendors and partners as a tool to evaluate their cybersecurity posture. Most importantly, the document does not promote a checkbox approach to cybersecurity — it allows for partial compliance, with room provided for explanations. It also allows many of the questions to be removed if the prospective partner possesses a SOC1/2 certification, thereby eliminating duplication in questions.

What the future holds

At the time of this writing, the Product Marketing and SMB working groups are hard at work making sure everyone, including the smallest businesses, are using the ICT-SCRM Task Force Resources to their fullest potential. Additional workstreams are being developed and will be announced soon, and these will likely include expansion with international partners and additional critical-infrastructure sectors.

For more information, you can visit the CISA ICT-SCRM Task Force website.

Additional reading:

• Open-Source Security: Getting to the Root of the Problem
• 2022 Planning: Designing Effective Strategies to Manage Supply Chain Risk
• Security at Scale in the Open-Source Supply Chain
• The Ransomware Task Force: A New Approach to Fighting Ransomware

Rapid7 supports efforts to increase transparency and information sharing in order to strengthen awareness of the cybersecurity threat landscape and prepare for cyberattacks. We applaud passage of the Cyber Incident Reporting for Critical Infrastructure Act.

What’s this law about?

The Cyber Incident Reporting for Critical Infrastructure Act will require critical infrastructure owners and operators — such as water and energy utilities, health care organizations, some IT providers, etc. — to submit reports to the Cybersecurity and Infrastructure Security Agency (CISA) for cybersecurity incidents and ransomware payments. The law will provide liability protections for submitting reports to encourage compliance, but noncompliance can result in a civil lawsuit. The law will also require the government to analyze, anonymize, and share information from the reports to provide agencies, Congress, companies, and the public with a better view of the cyber threat landscape.

An important note about the timeline: The requirements do not take effect until CISA issues a clarifying regulation. The law will require CISA to issue this regulation within 42 months (though CISA may take less time), so the requirements may not be imminent. In the meantime, the Cyber Incident Reporting for Critical Infrastructure Act provides information on what CISA’s future rule must address.

We detail these items from the law below.

Requiring reporting of cyber incidents and ransom payments

• Report requirement. Critical infrastructure owners and operators must report substantial cybersecurity incidents to CISA, as well as any ransom payments. (However, as described below, this requirement does not come into effect until CISA issues a regulation.)
  
• Type of incident. The types of cyber incidents that must be reported shall include actual breaches of sensitive information and attacks that disrupt business or operations. Mere threats or failed attacks do not need to be reported.
  
• Report timeline. For a cyber incident, the report must be submitted within 72 hours after the affected organization determines the incident is substantial enough that it must be reported. For ransom payments, the report must be submitted within 24 hours after the payment is made.
  
• Report contents. The reports must include a list of information, including attacker tactics and techniques. Information related to the incident must be preserved until the incident is fully resolved.
  
• Enforcement. If an entity does not comply with reporting requirements, CISA may issue a subpoena to compel entities to produce the required information. The Justice Department may initiate a civil lawsuit to enforce the subpoena. Entities that do not comply with the subpoena may be found in contempt of court.
  

CISA rule to fill in details

• Rule requirement. CISA is required to issue a regulation that will establish details on the reporting requirements. The reporting requirements do not take effect until this regulation is final.
  
• Rule timeline. CISA has up to 42 months to finalize the rule (but the agency can choose to take less time).
  

• Rule contents. The rule will establish the types of cyber incidents that must be reported, the types of critical infrastructure entities that must report, the content to be included in the reports, the mechanism for submitting the reports, and the details for preserving data related to the reports.
  

Protections for submitting reports

• Not used for regulation. Reports submitted to CISA cannot be used to regulate the activities of the entity that submitted the report.
  
• Privileges preserved. The covered entity may designate the reports as commercial and proprietary information. Submission of a report shall not be considered a waiver of any privilege or legal protection.
  
• No liability for submitting. No court may maintain a cause of action against any person or entity on the sole basis of submitting a report in compliance with this law.
  
• Cannot be used as evidence. Reports, and material used to prepare the reports, cannot be received as evidence or used in discovery proceedings in any federal or state court or regulatory body.
  

What the government will do with the report information

• Authorized purposes. The federal government may use the information in the reports cybersecurity purposes, responding to safety or serious economic threats, and preventing child exploitation.
  
• Rapid response. For reports on ongoing threats, CISA must rapidly disseminate cyber threat indicators and defensive measures with stakeholders.
  
• Information sharing. CISA must analyze reports and share information with other federal agencies, Congress, private sector stakeholders, and the public. CISA’s information sharing must include assessment of the effectiveness of security controls, adversary tactics and techniques, and the national cyber threat landscape.
  

What’s Rapid7’s view of the law?

Rapid7 views the Cyber Incident Reporting for Critical Infrastructure Act as a positive step. Cybersecurity is essential to ensure critical infrastructure is safe, and this law would give federal agencies more insight into attack trends, and would potentially help provide early warnings of major vulnerabilities or attacks in progress before they spread. The law carefully avoids requiring reports too early in the incident response process and provides protections to encourage companies to be open and transparent in their reports.

Still, the Cyber Incident Reporting for Critical Infrastructure Act does little to ensure critical infrastructure has safeguards that prevent cyber incidents from occurring in the first place. This law is unlikely to change the fact that many critical infrastructure entities are under-resourced and, in some cases, have security maturity that is not commensurate with the risks they face. The law’s enforcement mechanism (a potential contempt of court penalty) is not especially strong, and the final reporting rules may not be implemented for another 3.5 years. Ultimately, the law’s effect may be similar to state breach notification laws, which raised awareness but did not prompt widespread adoption of security safeguards for personal information until states implemented data security laws.

So, the Cyber Incident Reporting for Critical Infrastructure Act is a needed and helpful improvement — but, as always, there is more to be done.

Several of these changes go into effect in November 2022, to provide organizations time to prepare for compliance. Below, we’ll detail the changes in comparison to the previous rule.

Background on the Safeguards Rule

GLBA requires, among other things, a wide range of “financial institutions” to protect customer information. Enforcement for GLBA is split up among several different federal agencies, with FTC jurisdiction covering non-banking financial institutions in the Safeguards Rule. Previously, the Safeguards Rule left the implementation details of several aspects of the information security program up to the financial institution, based on its risk assessment.

The Safeguards Rule broad definition of “financial institutions” includes non-bank businesses that offer financial products or services — such as retailers, automobile dealers, mortgage brokers, non-bank lenders, property appraisers, tax preparers, and others. The definition of “customer information” is also broad, to include any record containing non-public personally identifiable information about a customer that is handled or maintained by or on behalf of a financial institution.

Updates to the Safeguards Rule

Many of the other updates concern strengthened requirements on how financial institutions must implement aspects of their security programs. Below is a short summary of the changes. Where applicable, we include citations to both the updated rule (starting at page 123) and the previous rule (at 16 CFR 314) for easy comparison.

Overall security program

• Current rule: Financial institutions must maintain a comprehensive, written information security program with administrative, technical, and physical safeguards to ensure the security, confidentiality, and integrity of customer information. 16 CFR 314.3(a)-(b).
• Updated rule: The updated rule now requires the information security program to include the processes and safeguards listed below (i.e., risk assessment, security safeguards, etc.). 16 CFR 314.3(a).
• Approx. effective date: November 2022

Risk assessment

• Current rule: Financial institutions are required to identify internal and external risks to security, confidentiality, and integrity of customer information. The risk assessment must include employee training, risks to information systems, and detecting and responding to security incidents and events. 16 CFR 314.4(b).
• Updated rule: The update includes more specific criteria for what the risk assessment must include. This includes criteria for evaluating and categorizing of security risks and threats, and criteria for assessing the adequacy of security safeguards. The risk assessment must describe how identified risks will be mitigated or accepted. The risk assessment must be in writing. 16 CFR 314.4(b).
• Approx. effective date: November 2022

Security safeguards

• Current rule: Financial institutions must implement safeguards to control the risks identified through the risk assessment. 16 CFR 314.4(c). Financial institutions must require service providers to maintain safeguards to protect customer information. 16 CFR 314.4(d).
• Updated rule: The updated rule requires that the safeguards must include
  - Access controls, including providing the least privilege;
  - Inventory and classification of data, devices, and systems;
  - Encryption of customer information at rest and in transit over internal networks;
  - Secure development practices for in-house software and applications;
  - Multi-factor authentication;
  - Secure data disposal;
  - Change management procedures; and
  - Monitoring activity of unauthorized users and detecting unauthorized access or use of customer information. 16 CFR 314.4(c)(1)-(8).
• Approx. effective date: November 2022

Testing and evaluation

• Current rule: Financial institutions must regularly test or monitor the effectiveness of the security safeguards, and make adjustments based on the testing. 16 CFR 314.4(c), (e).
• Updated rule: Regular testing of safeguards must now include either continuous monitoring or periodic penetration testing (annually) and vulnerability assessments (semi-annually). 16 CFR 314.4(d).
• Approx. effective date: November 2022

Incident response

• Current rule: Financial institutions must include cybersecurity incident detection and response in their risk assessments, and have safeguards to address those risks. 16 CFR 314.4(b)(3)-(c).
• Updated rule: Financial institutions are required to establish a written plan for responding to any security event materially affecting confidentiality, integrity, or availability of customer information. 16 CFR 314.4(h).
• Approx. effective date: November 2022

Workforce and personnel

• Current rule: Financial institutions must designate an employee to coordinate the information security program. 16 CFR 314.4(a). Financial institutions must select service providers that can maintain security and require service providers to implement the safeguards. 16 CFR 314.4(d).
• Updated rule: The rule now requires designation of a single “qualified individual” to be responsible for the security program. This can be a third-party contractor. 16 CFR 314.4(a). Financial institutions must now provide security awareness training and updates to personnel. 16 CFR 314.4(e). The rule now also requires periodic reports to a Board of Directors or governing body regarding all material matters related to the information security program. 16 CFR 314.4(i).
• Approx. effective date: November 2022

Scope of coverage

• Updated rule: The FTC update expands on the definition of “financial institution” to require “finders” — companies that bring together buyers and sellers — to follow the Safeguards Rule. 16 CFR 314.2(h)(1). However, financial institutions that maintain customer information on fewer than 5,000 consumers are exempt from the requirements of a written risk assessment, continuous monitoring or periodic pentesting and/or vulnerability scans, incident response plan, and annual reporting to the Board. 16 CFR 314.6.
• Approx. effective date: November 2021 (unlike many of the other updates, this item is not delayed for a year)

Incident reporting next?

In addition to the above, the FTC is also considering requirements that financial institutions report cybersecurity incidents and events to the FTC. Similar requirements are in place under the Cybersecurity Regulation at the New York Department of Financial Services. If the FTC moves forward with these incident reporting requirements, financial institutions could expect the requirements to be implemented later in 2022 or early 2023.

Financial institutions with robust security programs will already be performing many of these practices. For them, the updated Safeguards Rule will not represent a sea change in internal security operations. However, by making these security practices a formal regulatory requirement, the updated Safeguards will make accountability and compliance even more important.

(Check out our joint letter calling for cybersecurity in infrastructure legislation here.)

Cybersecurity is a priority — that’s progress

Cybersecurity is essential to ensure modern infrastructure is safe, and Rapid7 commends Congress and the Administration for including cybersecurity in the Infrastructure Investment and Jobs Act. Rapid7 led industry calls to include cybersecurity in the bill, and we are encouraged that several priorities identified by industry are reflected in the text, such as cybersecurity-specific funding for state and local governments and the electrical grid.

On the other hand, cybersecurity will be competing with natural disasters and extreme weather for funding in many (not all) grants created under the bill. In addition, not all critical infrastructure sectors receive cybersecurity resources through the legislation, with healthcare being a notable exclusion. Congress should address these gaps in the upcoming budget reconciliation package.

What’s in the bill for infrastructure cybersecurity

Below is a brief-ish summary of cybersecurity-related items in the bill. The infrastructure sectors with the most allocations appear to be energy, water, transportation, and state and local governments. Many of these funding opportunities take the form of federal grants for infrastructure resilience, which includes cybersecurity as well as natural hazards. Other funds are dedicated solely to cybersecurity.

Please note that this list aims to include major infrastructure cybersecurity funding items, but is not comprehensive. (For example, the bill also provides funding for the National Cyber Director.) Citations to the Senate-passed legislation are included.

1. State and local governments: $1B over 4 years for the State, Local, Tribal, and Territorial (SLTT) Grant Program. This new grant program will help SLTT governments to develop or implement cybersecurity plans. FEMA will administer the program. This is also known as The State and Local Cybersecurity Improvement Act. [Sec. 70611]

2. Energy: $250M over five years for the Rural and Municipal Utility Advanced Cybersecurity Grant and Technological Assistance Program. The Department of Energy (DOE) must create a new program to provide grants and technical assistance to improve electric utilities’ ability to detect, respond to, and recover from cybersecurity threats. [Sec. 40124]

3. Energy: Enhanced grid security. The DOE must create a program to develop advanced cybersecurity applications and technologies for the energy sector, among other things. Over a period of five years, this section authorizes $250M for the Cybersecurity for the Energy Sector RD&D program, $50M for the Energy Sector Operational Support for Cyberresilience Program, and $50M for Modeling and Assessing Energy Infrastructure Risk. [Sec. 40125]

4. Energy: State energy security plans. This creates federal financial and technical assistance for states to develop or implement an energy security plan that secures state energy infrastructure against cybersecurity threats, among other things. [Sec. 40108]

5. Water: $250M over 5 years for the Midsize and Large Drinking Water System Infrastructure Resilience and Sustainability Program. This creates a new grant program to assist midsize and large drinking water systems with increasing resilience to cybersecurity vulnerabilities, as well as natural hazards. [Sec. 50107]

6. Water: $175M over five years for technical assistance and grants for emergencies affecting public water systems. This extends an expired fund to help mitigate threats and emergencies to drinking water. This includes, among other things, emergency situations caused by a cybersecurity incident. [Sec. 50101]

7. Water: $25M over five years for the Clean Water Infrastructure Resiliency and Sustainability Program. This creates a new program providing grants to owners/operators of publicly owned treatment works to increase the resiliency of water systems against cybersecurity vulnerabilities, as well as natural hazards. [Sec. 50205]

8. Transportation: Cybersecurity eligible for National Highway Performance Program (NHPP). This expands on the existing NHPP grant program to allow states to use funds for resiliency of the National Highway System. "Resiliency" includes cybersecurity, as well as natural hazards. [Sec. 11105]

9. Transportation: Cybersecurity eligible for Surface Transportation Block Grant Program. This expands the existing grant program to allow funding measures to protect transportation facilities from cybersecurity threats, among other things. [Sec. 11109]

10. General: $100M over five years for the Cyber Response and Recovery Fund. This creates a fund for CISA to provide direct support to public or private entities that respond and recover from cyberattacks and breaches designated as a “significant incident.” The support can include technical assistance and response activities, such as vulnerability assessment, threat detection, network protection, and more. The program ends in 2028. [Sec. 70602, Div. J]

Other sectors next?

These cybersecurity items are significant down payments to safeguard the nation’s investment in infrastructure modernization. Combined with the recent Executive Order and memorandum on industrial control systems security, the Biden Administration is demonstrating that cybersecurity is a high priority.

However, more work must be done to address cybersecurity weaknesses in critical infrastructure. While the Infrastructure Investment and Jobs Act provides cybersecurity resources for some sectors, most of the 16 critical infrastructure sectors are excluded. Healthcare is an especially notable example, as the sector faces a serious ransomware problem in the middle of a deadly pandemic.

Congress is now preparing a larger budget reconciliation bill, to be advanced at roughly the same time as the infrastructure legislation. We encourage Congress and the Administration to take this opportunity to boost cybersecurity for other sectors, especially healthcare. As with the infrastructure bill, we suggest providing grants dedicated to cybersecurity, and requiring that grant funds be used to adopt or implement standards-based security safeguards and risk management practices.

Congress' activity during the COVID-19 crisis continues to be punctuated by large, ambitious bills. To secure the modern economy and essential services, we hope the Infrastructure Investment and Jobs Act sets a precedent that sound cybersecurity policies will be integrated into transformative legislation to come.

While we believe the bill would be harmful and do not support the bill in any way, we do acknowledge that at least this legislation is attempting to address how hack back could work in practice and identifying the potential risks. This gets at the heart of one of the main issues with policy proposals for hack back — they rarely address how it would actually work in reality, and how opportunities for abuse or unintended harms would be handled.

Rapid7 does not believe it’s possible to provide sufficient oversight or accountability to make private-sector hack back viable without negative consequences. Further, the very fact that we're once again discussing private-sector hack back as a possibility is extremely troubling.

Here, we’ll outline why Rapid7 is against the authorization of private-sector hack back.

What is hack back?

When we say “hack back,” we’re referring to non-government organizations taking intrusive action against a cyber attacker on technical assets or systems not owned or leased by the person taking action or their client. This is generally illegal in countries that have anti-hacking laws.

The appeal of hack back is easy to understand. Organizations are subject to more frequent, varied, and costly attacks, often from cybercriminals who have no fear of reprisal or prosecution due to the existence of safe-haven nations that either can’t or won’t crack down on their activities. The scales feel firmly stacked in the favor of these cybercriminals, and it’s understandable that organizations want to shift that balance and give attackers reason to think again before targeting them.

Along these lines, arguments for hack back justify it in a number of ways, citing a desire to recapture lost data, better understand the nature of the attacks, neutralize threats, or use the method as a tit for tat. Hack back activities may be conflated with threat hunting, threat intelligence, or detection and response activities. Confusingly, some proponents for these activities are quick to decry hack back while simultaneously advocating for authority to take intrusive action on third-party assets without consent from their owners.

Hack back is also sometimes referred to as Active Defense or Active Cyber Defense. This can cause confusion, as these terms can also refer to other defensive measures that are not intrusive or conducted without consent from the technology owner. For example, active defense can also describe intrusion prevention systems or deception technologies designed to confuse attackers and gain greater intelligence on them, such as honeypots. Rapid7 encourages organizations to employ active defense techniques within their own environments.

Rapid7’s criticisms of hack back

While the reasons for advocating for private-sector hack back are easy to understand and empathize with, that doesn’t make the idea workable in practice. There’s a wealth of reasons why hack back is a bad idea.

Impracticalities of attribution and application

One of the most widely stated and agreed-upon tenets in security is that attribution is hard. In fact, in many cases, it’s essentially impossible to know for certain that we’ve accurately attributed an attack. Even when we find indications that point in a certain direction, it’s very difficult to ensure they’re not red herrings intentionally planted by the attacker, either to throw suspicion off themselves or specifically to incriminate another party.

We like to talk about digital fingerprints, but the reality is that there's no such thing: In the digital world, pretty much anything can be spoofed or obfuscated with enough time, patience, skill, and resources. Attackers are constantly evolving their techniques to stay one step ahead of defenders and law enforcement, and the emergence of deception capabilities is just one example of this. So being certain we have the right actor before we take action is extremely difficult.

In addition, where do we draw the line in determining whether an actor or computing entity could be considered a viable target? For example, if someone is under attack from devices that are being controlled as part of a botnet, those devices – and their owners – are as much victims of the attacker as the target of the attack.

Rapid7’s Project Lorelei observes exactly this phenomenon: The honeypots often pick up traffic from legitimate organizations whose systems have been compromised and leveraged in malicious activity. Should one of these compromised systems be used to attack an organization, and that organization then take action against those affected systems to neutralize the threat against themselves, that would mean the organization defending itself was revictimizing the entity whose systems were already compromised. Depending on the action taken, this could end up being catastrophic and costly for both organizations.  

We must also take motivations into account, even though they’re often unclear or easy to misunderstand. For example, research projects that scan ports on the public-facing internet do so in order to help others understand the attack surface and reduce exposure and opportunities for attackers. This activity is benign and often results in security disclosures that have helped security professionals reduce their organization’s risk. However, it’s not unusual for these scans to encounter a perimeter monitoring tool, throwing up an alert to the security team. If an organization saw the alerts and, in their urgency to defend themselves, took a “shoot first, ask questions later” approach, they could end up attacking the researcher.

Impracticalities of limiting reach and impact

Many people have likened hack back to homeowners defending their property against intruders. They evoke images of malicious, armed criminals breaking into your home to do you and your loved ones harm. They call to you to arm yourself and stand bravely in defense, refusing to be a victim in your own home.

It’s an appealing idea — however, the reality is more akin to standing by your fence and spraying bullets out into the street, hoping to get lucky and stop an attacker as they flee the scene of the crime. With such an approach, even if you do manage to reach your attacker, you’re risking terrible collateral damage, too.

This is because the internet doesn’t operate in neatly defined and clearly demarcated boundaries. If we take action targeted at a specific actor or group of actors, it would be extremely challenging to ensure that action won’t unintentionally negatively impact innocent others. Not only should this concern lawmakers, it should also disincentivize participation. The potential negative consequences of a hack back gone awry could be far-reaching. We frequently discuss damage to equipment or systems, or loss of data, but in the age of the Internet of Things, negative consequences could include physical harm to individuals. And let’s not forget that cyberattacks can be considered acts of war.

Organizations that believe they can avoid negative outcomes in the majority of cases need to understand that even just one or two errors could be extremely costly. Imagine, for example, that a high-value target organization, such as a bank, undertakes 100 hack backs per year and makes a negatively impactful error on two occasions. A 2% fail rate may not seem that terrible — but if either or both of those errors resulted in compromise of another company or harm to a group of individuals, the hack-backer could see themselves tied up in expensive legal proceedings, reputational damage, and loss of trust. Attempts to make organizations exempt from this kind of legal action are problematic, as they raise the question of how we can spot and stop abuses.

Impracticalities of providing appropriate oversight

To date, proposals to legalize hack back have been overly broad and non-specific about how such activities should be managed, and what oversight would be required to ensure there are no abuses of the system. The Daines/Whitehouse bill tries to address this and alludes to a framework for oversight that would determine “which entities would be allowed to take such actions and under what circumstances.”

This seems to refer to an approach commonly advocated by proponents of hack back whereby a license or special authorization to conduct hack back activities is granted to vetted and approved entities. Some advocates have pointed to the example of how privateers were issued Letters of Marque to capture enemy ships — and their associated spoils. Putting aside fundamental concerns about taking as our standard a 200-year-old law passed during a time of prolonged kinetic war and effectively legalizing piracy, there are a number of pragmatic issues with how this would work in practice.  

Indeed, creating a framework and system for such oversight is highly impractical and costly, raising many issues. The government would need to determine basic administrative issues, such as who would run it and how it would be funded. It would also need to identify a path to address far more complex issues around accountability and oversight to avoid abuses. For example, who will determine which activities are acceptable and where the line should be drawn? How would an authorizing agent ensure standards are met and maintained within approved organizations? Existing cybersecurity certification and accreditation schemes have long raised concerns, and these will only worsen when certification results in increased authorities for activities that can result in harm and escalation of aggressions on the internet.

When a government entity itself takes action against attackers, it does so with a high degree of oversight and accountability. They must meet evidentiary standards to prove the action is appropriate, and even then, there are parameters determining the types of targets they can pursue and the kinds of actions they can take. Applying the same level of oversight to the private sector is impractical. At the same time, authorizing the private sector to participate in these activities without this same level of oversight would undermine the checks and balances in place for the government and likely lead to unintended harms.

An authorizing agent cannot have eyes everywhere and at all times, so it would be highly impractical to create a system for oversight that would enable the governing authority to spot and stop accidental or intentional abuses of the system in real time. If the Daines/Whitehouse bill does pass (and we have no indication of that at present), I very much hope that DHS’s resulting report will reflect these issues or, if possible, provide adequate responses to address these concerns.

Impracticalities of legal liability and jurisdiction

These issues of practical execution also raise questions around who will bear the responsibility and liability if something goes wrong. For example, if a company hacks back and accidentally harms another organization or individual, the entity that undertook the hacking may incur expensive legal proceedings, reputational damage, and loss of trust. They could become embroiled in complicated and expensive multi-jurisdiction legal action, even if the company has a license to hack back in its home jurisdiction. In scenarios where hack back activities are undertaken by an organization or individual on behalf of a third party, both the agent and their client may bear these negative consequences. There may also be an argument that any licensing authority could also bear some of the liability.  

Making organizations exempt from legal action around unintended consequences would be problematic and likely to result in more recklessness, as well as infringing on the rights of the victim organization. While the internet is a borderless space accessed from every country in the world, each of those countries has its own legal system and expects its citizens to abide by it. It would be very risky for companies and individuals who hack back to avoid running afoul of the laws of other countries or international bodies. When national governments take this kind of action, it tends to occur within existing international legal frameworks and under some regulatory oversight, but this may not apply in the private sector, again begging the question of where the liability rests.

It’s also worth noting that once one major power authorizes private-sector hack back, other governments will likely follow, and legal expectations or boundaries may vary. This raises questions of how governments will respond when their citizens are being attacked as part of a private-sector hack back gone wrong, and whether it will likely lead to escalation of political tensions.

Inequalities of applicability

Should a viable system be developed and hack back authorized, effective participation would likely be costly, as it would require specialist skills. Not every organization would be able to participate. If the authorization framework isn't stringent, many organizations might try to participate with insufficient expertise, which would likely be ineffective, damaging, or both. At the same time, other organizations won’t have the maturity or budget to participate even in this way.

These are the same organizations that sit below the “cybersecurity poverty line” and can’t afford a great deal of in-house security expertise and technologies to protect themselves – in other words, these organizations are already highly vulnerable. As organizations that do have sufficient resources start to hack back, the cost of attacking these organizations will increase. Profit-motivated attackers will eventually shift toward targeting the less-resourced organizations that reside below the security poverty line. Rather than authorizing a measure as fraught with risk as hack back, we should instead be thinking about how to better protect these vulnerable organizations — for example, by subsidizing or incentivizing security hygiene.

The line between legitimate research and hack back

Those who follow Rapid7’s policy work will know that we’re big proponents of security research and have worked for many years to see greater recognition of its value and importance in public policy. It may come as a surprise to see us advocate so enthusiastically against hack back as, from a brief look, they have some things in common. In both cases, we’re talking about activity undertaken in the name of cybersecurity, which may be intrusive in nature and involve third-party assets without consent of the owner.

While independent, good-faith security research and threat intelligence investigations are both very valuable for security, they're not the same thing, and we don’t believe we should view related legal restrictions in the same way for both.

Good-faith security research is typically performed independently of manufacturers and operators in order to identify flaws or exposures in systems that provide opportunities for attackers. The goal is to remediate or mitigate these issues so we can reduce opportunities for attackers and thus decrease the risk for technology users. This kind of research is generally about protecting the safety and privacy of the many, and while researchers may take actions without authorization, they only perform those actions on the technology of those ultimately responsible for both creating and mitigating the exposure. Without becoming aware of the issue, the technology provider and their users would continue to be exposed to risk.

Research may bypass authorization to sidestep issues arising from manufacturers and operators prioritizing their reputation or profit above the security of their customers. In contrast, threat intel investigations or operations that involve interrogating or interacting with third-party assets prioritize the interests of the specific entity undertaking or commissioning the activity, rather than other potential victims whose compromised assets may have been leveraged in the attack.

While threat intelligence can help us understand attacker behavior and identify or prepare for attacks, data gathering and operations should be limited only to assessing risks and threats to assets that are owned or operated by the entity authorizing the work, or to non-invasive activities such as port scanning. Because cyber attacks are criminal activity, if more investigation is needed, it should be undertaken with appropriate law enforcement involvement and oversight.

The path forward

It seems likely that the hack back debate will continue to come up as organizations strive to find new ways to repel attacks. I could make a snarky comment here about how organizations should perhaps focus instead on user awareness training, reducing their attack exposure, managing supply chain risk, proper segmentation, patching, Identity Access Management (IAM), and all the other things that make up a robust defense-in-depth program and that we frequently see fail, but I shall refrain. Cough cough.

We shall wait to see what happens with Senators Daines’ and Whitehouse’s “Study on Cyber-Attack Response Options Act’’ bill and hope that, if it passes, DHS will consider the concerns raised in this blog. The same is true for other policymakers as cybercrime is an international blight and governments around the world are subject to lobbying from entities looking to take a more active role in their defense. While we understand and sympathize with the desire to do more, take more control, and fight back, we urge policymakers to be mindful of the potential for catastrophe.

Last week, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the FBI published a joint alert to warn users that APT threat actors were likely exploiting unpatched Fortinet FortiOS devices to gain initial access to government, commercial, technology, and other organizations’ networks. The alert highlighted three FortiOS vulnerabilities, all of which were previously known, and at least one of which (CVE-2018-13379) has been broadly exploited for more than 18 months. This week, CISA published an additional alert amplifying a threat report from security firm Onapsis, which describes ongoing attacks against SAP applications.

Rapid7 has previously analyzed a number of the highest-severity vulnerabilities enumerated in this latest set of alerts. The CVEs included in these reports have been detailed below, along with recommendations for organizations seeking to defend themselves against ongoing exploitation. Notably, none of these vulnerabilities are new—many of them are a year or more old, which underscores the need for a regular patch cycle, as well as a defined patch cycle exception process.

FortiOS vulnerabilities

Fortinet devices are what we call network pivots—that is, the position they occupy in organizations’ networks gives external attackers the ability to access internal networks if exploited successfully, which in turn allows for a range of secondary attacks and other nefarious activities. If at all possible, defenders should strongly consider implementing a “zero-day” patch cycle for internet-exposed and other network pivot products, including (but not only) Fortinet and other VPNs. InsightVM and Nexpose customers can assess their exposure to all three FortiOS CVEs below with vulnerability checks.

• CVE-2018-13379 is a pre-authentication information disclosure vulnerability that arises from a path traversal flaw in the web portal component of FortiOS SSL VPNs. The vulnerability allows external attackers to download FortiOS system files through specially crafted HTTP resource requests and has been exploited in the wild since 2019. Read our full analysis of CVE-2018-13379 and its history here.
• CVE-2019-5591 is a default configuration vulnerability in FortiOS that allows an unauthenticated attacker on the same subnet to intercept sensitive information by impersonating the LDAP server.
• CVE-2020-12812 is an improper authentication vulnerability in SSL VPN in FortiOS 6.4.0, 6.2.0 to 6.2.3, 6.0.9 and below that gives a user the ability to log in successfully without being prompted for the second factor of authentication (FortiToken) if that user changes the case of their username.

Since the beginning of March, Rapid7 Labs' Heisenberg Honeypot fleet has seen nearly 60 IP addresses attempting common, known single GET request exploits against Fortinet devices (we’ve grouped the IP addresses up to the hosting provider/ISP level):

Unfortunately, our fleet does not emulate Fortinet devices. Since these devices are fairly easy to distinguish on the internet (nearly 1 million of them in the image, below)—due to the common, vendor SSL certificate they use—it is surprising to see opportunistic exploit attempts versus just inventory/discovery scans.

That last sentence should help organizations underscore why CISA and the FBI raised the Fortinet exploitation campaign to the level of a joint alert: Attackers can easily identify legitimate Fortinet endpoints on the internet, and it takes virtually no time from discovery to exploit if a target system is not patched and configured properly.

As Fortinet notes in that post, these weaknesses have had patches available for quite some time, so if you’re just getting around to fixing them, you may need to dedicate some further cycles to some forensic activity, as it is very likely one or more attackers have already taken advantage of these vulnerabilities.

To learn more about other vulnerabilities that functioned as network pivots for attackers, read Rapid7’s 2020 Vulnerability Intelligence Report.

Actively exploited SAP vulnerabilities

The two most recent SAP vulnerabilities detailed in Onapsis’ threat report are CVE-2020-6287, a CVSS-10 vulnerability in the SAP NetWeaver Application Server (AS) Java component LM Configuration Wizard that has been actively exploited in the wild since July 2020, and SAP Solution Manager CVE-2020-6207. Both of these vulnerabilities allow broad compromise of SAP applications and environments.

• CVE-2020-6287 is present by default in SAP applications running on top of SAP NetWeaver AS Java 7.3 and any newer versions (up to SAP NetWeaver 7.5). It allows remote, unauthenticated attackers to exploit and fully compromise vulnerable SAP installations. Exploitation of CVE-2020-6287 through the HTTP interface allows for modification or extraction of highly sensitive information and disruption of critical business processes. For a list of affected applications and additional guidance, read Rapid7’s full analysis here.
• CVE-2020-6207 arises from a missing authentication check in version 7.2 of SAP’s Solution Manager product, allowing attackers to completely compromise all SMDAgents connected to the Solution Manager.
  
  SAP customers should pay close attention to their access logs and monitor for unauthorized user account creation; they should also ensure that web services in general do not run using privileged accounts. InsightVM and Nexpose customers can assess their risk to CVE-2020-6287 with a remote vulnerability check. A check for CVE-2020-6207 is currently under development.

Other SAP vulnerabilities noted as being exploited in the wild include:

• CVE-2018-2380 affects SAP CRM versions 7.01, 7.02, 7.30, 7.31, 7.33, and 7.54. The vulnerability allows an attacker to exploit insufficient validation of path information provided by users, letting characters representing "traverse to parent directory" pass through to the file APIs.
• CVE-2016-9563 is a vulnerability in SAP NetWeaver Application Server (AS) Java 7.5 that allows remote authenticated users to conduct XML External Entity (XXE) attacks via the sap.com~tc~bpem~him~uwlconn~provider~web/bpemuwlconn URI.
• CVE-2016-3976 is a directory traversal vulnerability in SAP NetWeaver AS Java 7.1 through 7.5 that allows remote attackers to read arbitrary files via a ..\ (dot dot backslash) in the fileName parameter to CrashFileDownloadServlet.
• CVE-2010-5326 is a CVSS-10 vulnerability in the Invoker Servlet on SAP NetWeaver Application Server Java platforms that arises from a lack of authentication and allows remote attackers to execute arbitrary code via an HTTP or HTTPS request. It was used in attacks from 2013 to 2016.

The US Senate unanimously passed the IoT Cybersecurity Improvement Act (H.R.1668) yesterday. The US House passed the bill in September, so it is highly likely to become law, barring a Presidential veto.  

This is arguably the most significant US IoT-specific cybersecurity law to date, as well as the most significant law promoting private sector adoption of coordinated vulnerability disclosure. IoT security is widely acknowledged as a global priority, and vulnerability disclosure processes are fundamental security practices, so passage of the bill should be seen as a very positive step forward for cybersecurity and the security community.

Rapid7 applauds passage of the IoT Cybersecurity Improvement Act and looks forward to working with NIST and other stakeholders on its implementation. The bill's lead sponsors - Senators Warner and Gardner, and Representatives Kelly and Hurd - deserve great credit for years of work on this important issue, and for guiding the bill over the finish line through an election, a global pandemic, and a divided Congress. As longtime supporters of the bill, Rapid7 led group letters to Congress urging passage, testified before the Senate favorably on the legislation, and blogged extensively on the bill’s progress.  

[For more detailed analysis of the bill, please check out this post.]

The unanimous passage (in both House and Senate) of the IoT Cybersecurity Improvement Act demonstrates bipartisan recognition of the importance of IoT security, and the need for action. Through the Act, the federal government can lead by example in implementing basic IoT security standards and best practices for devices it buys and manages, and drive contractors’ adoption of standards-based coordinated vulnerability disclosure processes. We also note the bill’s careful alignment with existing standards and best practices [Sec. 4(a)(3)], which will aid coordination and efficiency.

There is a lot more work ahead, and more opportunities for the security community to get involved. The Act directs NIST to issue standards-based guidelines for minimum security of IoT devices owned or controlled by the federal government [Sec. 4(a)], and federal acquisition rules and agency information security policies must be updated to be consistent with the NIST guidelines. [Sec. 4(b)-(d)] Similarly, NIST must develop coordinated vulnerability disclosure guidelines for agencies and contractors, who must then integrate the guidelines into their security practices. [Sec. 5-6] Many of these steps, rolling out in 2021, will include partnership and comments from security experts and practitioners.

In addition to raising the bar for federal security, we hope the bill signals strengthened commitment from the US federal government to work on IoT security. US states (such as California and Oregon), and non-US countries (such as the UK, Australia, Singapore, and more) are making bold strides in establishing IoT security norms and mandates. While we support strong IoT security, we believe it is best implemented in a coordinated manner, avoiding a patchwork between US states or internationally. This will take sustained engagement from both the public and private sectors, but the passage of the IoT Cybersecurity Improvement Act and the lessons to be learned in its implementation will be invaluable to this process.

On Tuesday September 15th, the US House unanimously passed the IoT Cybersecurity Improvement Act [H.R. 1668]. The bill, sponsored by Reps. Kelly and Hurd, would require federal procurement and use of IoT devices to conform to basic security requirements. The version passed by the House makes several improvements compared to previous versions and the Senate companion, which we blogged about in detail a long time ago in the parallel dimension that was 2019. Although the chances of Senate passage are unclear, the bill’s resounding approval in the House is a big step closer to a meaningful IoT security framework across federal agencies.

Bill summary

The House-passed version of the IoT Cybersecurity Improvement Act retains its basic formula:

• NIST must issue standards-based guidelines for minimum security of IoT devices owned or controlled by the federal government. [Sec. 4(a).]
• The Office of Management and Budget (OMB) must issue rules requiring federal civilian agencies to have information security policies that are consistent with NIST’s guidelines. [Sec. 4(b).]
• Federal acquisition rules must be updated to reflect the IoT security standards and guidelines. [Sec. 4(d).]
• Federal agencies must implement a vulnerability disclosure policy, as well as contractors providing information systems to agencies. [Sec. 5-6.]
• Federal agencies cannot procure, obtain, or renew contracts for IoT devices that cannot meet the security guidelines. [Sec. 7.]
  

Broadly speaking, this is pretty thoughtful and should have a meaningful impact on federal IoT security. Let’s zoom in on a few details: 1) The definition of IoT; 2) The waiver process; and 3) The contract amount threshold.

IoT Definition

We note the bill’s definition of IoT leverages NIST’s definition of IoT from NISTIR 8259. Here is that definition:

Devices that have at least one transducer (sensor or actuator) for interacting directly with the physical world, have at least one network interface, and are not conventional Information Technology devices, such as smartphones and laptops, for which the identification and implementation of cybersecurity features is already well understood; and (B) can function on their own and are not only able to function when acting as a component of another device, such as a processor. [Sec. 4(a)(1).]

This workable definition of IoT avoids some of the problems we flagged with the original bill, in which items like Programmable Logic Controllers were categorized as general computing devices. This is positive, as is the definition’s alignment with NISTIR 8259. Consistency is always A+. Although the definition would not cover disassembled components of an IoT device - such as commodity processors, actuators, sensors, etc. - this is understandable since it is literally a definition of “IoT device.” And while the components alone may not be covered by the proposed security rules for Iot devices, such as those established under Sec. 4(a)-4(b), they would be covered once they are assembled into a device and controlled or used by the agency.

Waiver process

In another positive development, this House-passed version of the bill improves upon the problematic waiver process we flagged in our previous blog post. The most recent Senate bill provides a waiver from the security requirements when the use of the IoT device is “appropriate to the function of the [device],” which blows a giant loophole into the bill by exempting (for example) smart light bulbs that are used as smart light bulbs. The House-passed version changes this up by allowing the waiver if the IoT “device is secured using alternative and effective methods appropriate to the function of [the] device.” [Sec. 7(b)(1)(C)] This approach is far more appropriate for the goals of the bill, and we hope the Senate makes a similar modification at the next available opportunity.

Contract amount threshold

Alas, not all is wine and roses. The bill includes a confusing provision that seems to limit the security requirements for IoT procurement to small-ish contracts. Specifically, Section 7(a)(2) states that the prohibition on procurement and use of IoT devices that do not meet the NIST security guidelines applies to contracts that are not greater than the “simplified acquisition threshold” - which is $750,000.

At first glance, and also second glance, this looks like the procurement security requirements do not apply to IoT contracts over $750,000, which would be consequential considering the large size of many government purchases. However, staff close to the bill inform us that their intent is the opposite: The procurement security requirements do apply to contracts both above and below $750,000, and the “simplified acquisition threshold” needed to be called out separately to ensure that coverage. Fair enough, but the provision would benefit from a clarification on this point.

More federal leadership to come?

Let’s take a look at the bigger picture. By now, numerous assessments from Very Smart People conclude that the exploitability of IoT devices is a pressing global cybersecurity problem. To focus on the federal government’s own findings, behold the Cyberspace Solarium Commission report, the report on automated threats from the Departments of Commerce and DHS, and the Commission to Enhance the National Cybersecurity report of yesteryear. Rapid7’s analysis of the security landscape concurs with such assessments, and - combined with our concern that basic IoT security best practices are well-known but still not broadly adopted - has led to our stated position that some regulation encouraging the adoption of baseline security measures is appropriate.

Some federal agencies (notably the FDA) have taken action to demand basic security of the devices in their jurisdiction, and NIST is doing pretty fine work in establishing a voluntary minimum IoT security baseline. However, in general, the more cross-cutting and bold regulatory action on IoT security is being led by individual states (specifically California and Oregon) and non-US countries (such as the UK), which are requiring devices to include a small subset of basic security protections. But at the federal level, Congress is at risk of being late to the game on the issue of IoT security, despite studying it a great deal.

Passage of the IoT Cybersecurity Improvement Act in the House takes us a step closer to changing that, and enactment into law would go a long way to putting the US into a leadership position on this issue. Though the bill is narrowly focused on government use and procurement, it makes sense for the federal government to take the lead in raising the bar for devices it buys and manages. Leading by example may also jumpstart Congress’ process of exploring an appropriate IoT security regulatory framework for the private sector - one that is effectively consistent with industry best practices and heads off a patchwork of state laws.

One step at a time

Representatives Kelly and Hurd deserve hearty elbow-bumps for getting this over the finish line in the House. Senators Gardner and Warner, to their great credit, are also pushing to fast-track this bill in the Senate. Unfortunately, the legislative calendar is not too favorable as the election-pandemic-wildfire-recession year draws to a close, and failure to pass the bill would mean both the House and Senate must start over in 2021.

Nonetheless, the progress in the House this week boosts the chances for advancement in the Senate (in 2020 in 2021), which would be good news for federal agency security, cybersecurity writ large, and federal leadership on IoT security.

In advance of ShmooCon, Rapid7 co-organized the Hackers On The Hill event with the omnipresent Beau Woods of I Am The Cavalry. The event aims to help give security pros an opportunity to learn about engaging in public policy relating to cybersecurity. The event brought around 70 hackers to Capitol Hill to engage in meetings with Congressional offices, discuss cybersecurity policy issues of interest to the security research community, and provide resources and education on how to make policy advocacy more effective. It was a great event! A good turnout from the research community (in town for Shmoo), a beautiful room on the Hill secured with the help of Congressional staff, and lots of positive engagement in the meetings with Congressional offices towards the latter half of the day. Check out the website and Twitter handle for more - here’s looking forward to doing it again in 2021.

As part of that event, I gave a presentation on the state of cybersecurity policy, and produced a brief guide for visiting Congressional offices. Since then, I’ve received positive feedback and several requests to post the guide and the slides. So here we go.

The Unofficial Guide to Meeting With Congressional Offices was a resource to participating hackers preparing for their first Hill meetings. We created a version specially for the event, but here is an updated version for you to use if you are interested in briefing Congress.

The Hacking Policy presentation is available here. The presentation gave an overview of the volume and themes of cybersecurity policy activity at the federal and state levels, then focused on several specific cybersecurity topics - lovingly handpicked as possibly of interest to the hacker audience. Finally the presentation gave some resources for policy research and a few tips on effective advocacy. The slide graphics themselves are based on public domain government posters that I Photoshopped to be more cyber(TM) .

Here is a brief summary of some takeaways from the Hacking Policy presentation:

When looking at the cybersecurity policy landscape, it’s important not just to look at Congress (which often gets the most attention), but also Executive Branch agencies and the states. For many issues, agencies and states are more active.

Reviewing the past year, there is a lot of cybersecurity activity in Congress, executive agencies, and the states - hundreds of bills, regulations, and other actions that touch on cybersecurity in some way. Policymakers know that cybersecurity is an important issue - which was not necessarily the case five to ten years ago - the conversation has evolved to debate on what to do about cybersecurity.

While there is good diversity in the categories of cybersecurity policy issues under consideration, there are also common tensions holding back progress, such as fears of harming innovation with liability.

Taking a closer look at specific cybersecurity policy issues of interest to the security research community -

• Internet of Things: In the current Congress, much of the action on IoT security relates to federal procurement (the IoT Cybersecurity Improvement Act), smart cities, and reports and commissions on how to approach IoT security. However, there are already many reports, best practices, and guidance about IoT security circulating - some of which comes from executive branch agencies. NIST is finishing its voluntary IoT security baseline, and sectoral regulators have released voluntary guidance on IoT within their jurisdiction (i.e., FDA for medical devices, NHTSA for cars, etc.). The states have galloped ahead with laws and legislation that would require baseline security requirements for IoT.
  
  
• Privacy: The cybersecurity issues we watch out for here are 1) security requirements for personal information, 2) exemptions for cybersecurity activity from privacy requirements, and 3) the effect of preemption on state cybersecurity laws. Dozens of privacy bills in Congress have data security, but wrangling over enforcement and preemption are seriously stalling progress. Numerous states are also considering privacy legislation at varying stages of advancement, with California (again) and Washington likely to take action this year.
  
  
• Coordinated vulnerability disclosure: In Congress, only a couple bills include CVD - the IoT Cybersecurity Improvement Act would require it for government IoT vendors, and several bills would require specific federal agencies to incorporate bug bounties. The real action here is the executive agencies: OMB and CISA joined forces with a draft rule that would require all federal civilian agencies to have a vulnerability disclosure policy. Sectoral regulators, like FDA and NHTSA, are including CVD in voluntary guidance.
  
  
• Encryption: Discussion about requiring government access to encrypted communications is beginning to surge again, with public statements from the Attorney General, the President, and senior Members of Congress. In December, Senate Judiciary hearings examined this question, with the Chairman and Ranking Member favorably inclined to restricting strong encryption. There is little current legislation on the subject, with the ENCRYPT Act protecting encryption and the draft EARN IT Act that could undermine it via a Commission report.
  
  
• Supply Chain: This issue is tied to, but not exclusively based on, concerns about 5G security and Chinese espionage. Congress is focused on the government’s own activity - such as making sure its procurement and subsidies have supply chain security requirements. Meanwhile, the Dept. of Commerce (tasked by Executive Order) is drafting a regulation restricting transactions with countries designated as adversaries, and the Dept. of Homeland Security is coordinating a task force on supply chain security that (among other things) is developing a framework for public-private information sharing on supply chain risk.
  
  
• CFAA / Computer crime: Most legislation in this area would expand the reach of the Computer Fraud and Abuse Act and state equivalents, and there is very little movement on legal protection for security researchers. In particular, the International Cybercrime Prevention Act in Congress, and several computer crime laws proposed in states. Congress is also considering legislation requiring bug bounties for individual agencies, and modifying the CFAA to permit “hack back” by planting beacons in stolen data.
  
  
• DMCA Sec. 1201: Some of the most productive conversations on legal protection for security research happen in this arena. Protection for security research under DMCA Sec. 1201 has made significant progress since the Librarian of Congress’ 2015 rulemaking. The rule is up for renewal every three years, with 2021 on schedule next. Agencies like DOJ and NTIA have weighed in positively with the Copyright Office on this issue. The Copyright Office issued a study in 2017 calling on Congress to change DMCA Sec. 1201 to give security researchers more flexibility. Congress has yet to take this up, but has begun a series of hearings on DMCA that may examine this issue in context of broader reform.
  
  

That’s a lotta cyber policy! But the status of cyber policy issues, legislation, and regulation is evolving all the time. Here are some additional resources if you want to track them: For federal legislation, check out <https://www.congress.gov>. For federal regulation, check out <https://www.regulations.gov>. For state legislation, check out <https://www.ncsl.org>.

As you go forth to advocate on issues that matter to you, remember that it is easy to just point out problems. The most valuable approach is to propose solutions that don’t create other big problems, articulate it to the right officials, and navigate the politics and processes to make progress on the solution. It’s not easy and takes practice, but I believe in the security community’s ability to make real change if we work together.

* * *

Thanks again to everyone who came out to Hackers On The Hill 2020, and much gratitude to the participants and co-organizers. Hopefully we’ll run it back in 2021, and no doubt cyber policy will be even more cyber by then. Until that time, any feedback is welcome, and especially your experiences in advocating on cybersecurity policy since the event.

A couple top-level highlights:

1. The China Phase One Agreement takes some steps to improve intellectual property enforcement and prohibit tech transfer requirements. This may reduce some risks of IP theft for businesses operating in China. However, it remains to be seen how stringently China will enforce the agreement.
2. The USMCA includes the first chapter dedicated to digital trade in a US trade agreement. It includes cybersecurity provisions encouraging Mexico and Canada to implement and promote a risk-based approach to cybersecurity that encompasses the principles of the NIST Cybersecurity Framework (without mentioning the NIST Framework by name). This can help cybersecurity products and services companies refer to a common set of practices and controls when building cybersecurity programs and assessing needs.

US-China Phase One Agreement

Status: The US-China Phase One Agreement was signed on Jan. 15, 2020. A partial rollback of tariffs has also been announced. The US-China Phase One Agreement will not require Congressional approval to enter into force.

Phase One Highlights: Most of the agreement focuses on commodities rather than tech issues. However, there are provisions on IP, tech transfer, and purchase of services.

Intellectual Property (Chapter 1):

• Expands the scope of liability for trade secret misappropriation to cover all persons, such as former employees, or "cyberhackers."
• China's legal system must prohibit electronic intrusions and breach of confidentiality as part of trade secret misappropriation.
• Government requests for confidential business information must be limited to no more than what is necessary to exercise regulatory or investigative authority, and to prohibit unauthorized disclosures of that information.
• Requires stronger penalties and injunctive relief for IP theft.
• China must release an Action Plan within 30 days on how this chapter will be implemented.

Tech Transfer (Chapter 2):

• Prohibits tech transfer as a requirement for market access, licensing, administrative approvals, or other special advantages. All tech transfers and licensing must be voluntary and by mutual agreement.
• All administrative and licensing requirements must be transparent, and sensitive technical information must be protected in any administrative, regulatory, or review processes.
• "Tech transfer" is not defined in the agreement. There are questions regarding whether these provisions apply to security assessments.

Purchases (Chapter 6):

• China commits to dedicate $37.9bn to purchase of services, which may include "cloud and related services."

Phase Two and cybersecurity: US officials have stated that Phase Two will focus more on technology, IP, and cybersecurity issues - potentially including Huawei and rollback of additional tariffs. There is no public timetable yet, though President Trump noted that Phase Two would begin "very shortly."

US-Mexico-Canada Agreement (USMCA)

Status: The USMCA was approved by the US Congress and entered into force on Jan. 16, 2020. Much of the content was borrowed from the now-defunct Trans-Pacific Partnership. Unlike the China Phase One Agreement, USMCA is comprehensive and addresses several economic sectors, including a detailed chapter on digital trade (Chapter 19). This is the first digital trade chapter in a US trade agreement.  

USMCA Digital Trade highlights:

• Cyber risk management: The Parties “shall endeavor to” employ and encourage enterprises to use risk-based approaches to cybersecurity, based on standards and best practices, to identify and protect against cybersecurity risks and to detect, respond to, and recover from cybersecurity events. Rapid7 fought for inclusion of this provision in USMCA based on feedback that a common NIST-like framework would be helpful for communicating about cybersecurity in international markets.
• Cybersecurity collaboration: The Parties “shall endeavor to” strengthen collaboration mechanisms for cooperating to identify and mitigate cyberattacks and cybersecurity incidents.
• No data localization: The Parties shall not require enterprises to locate or use computing facilities in that Party’s territory as a condition for conducting business there. The Parties may not restrict cross-border flow of information unless necessary to achieve specific purposes and in proportion to the risks.
• Source code protection: The Parties shall not require access to or transfer of source code as a condition for market access.
• No favorable treatment: The Parties shall not accord less favorable treatment to a digital product produced in another country.
• No custom duties or fees: The Parties shall not impose custom duties or fees for digital products transferred electronically.
• Safe harbor for platforms: “Interactive Computer Services” (that provide electronic access by multiple users to a computer server) shall not be held liable for harms caused by user-generated content.
• No weakening encryption: With some caveats for financial instruments, the Parties shall not require local design elements (i.e., intentionally weakening) in commercial cryptography as a condition of market access.

US-Japan Digital Trade Agreement

Status: The US-Japan Trade Agreement was signed by both countries on Oct. 7, 2019. This deal is more limited than USMCA, focusing largely on tariffs and digital trade. Because it is limited, the US-Japan Agreement does not require congressional approval to move forward. The digital trade chapter was broken out into a separate agreement - the US-Japan Digital Trade Agreement - and will be enacted in the US as an Executive Agreement. However, the Japanese Diet must still approve the Agreement.

US-Japan Digital Trade Agreement highlights: The text is almost identical to the USMCA digital trade chapter. We should expect this to be the base negotiating text for digital provisions US trade agreements moving forward - including the upcoming US-UK, US-EU, and China Phase Two agreements.  

   * * *

We welcome the inclusion of issues like information flows, IP protection, and cybersecurity into new trade instruments. Inclusion of these digital trade issues better reflect the technological environment of global businesses. As cybersecurity continues to grow in importance to industry, and as an industry itself, we hope future trade agreements and other instruments incorporate additional priorities related to cybersecurity.