All posts by Harley Geiger

Incident Reporting Regulations Summary and Chart

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2022/08/26/incident-reporting-regulations-summary-and-chart/

Incident Reporting Regulations Summary and Chart

A growing number of regulations require organizations to report significant cybersecurity incidents. We’ve created a chart that summarizes 11 proposed and current cyber incident reporting regulations and breaks down their common elements, such as who must report, what cyber incidents must be reported, the deadline for reporting, and more.

Incident Reporting Regulations Summary and Chart
Download the chart now

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.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Additional reading:

Avoiding Smash and Grab Under the SEC’s Proposed Cyber Rule

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2022/08/23/avoiding-smash-and-grab-under-the-secs-proposed-cyber-rule/

Avoiding Smash and Grab Under the SEC’s Proposed Cyber Rule

The SEC recently proposed a regulation to require all public companies to report cybersecurity incidents within four days of determining that the incident is material. While Rapid7 generally supports the proposed rule, we are concerned that the rule requires companies to publicly disclose a cyber incident before the incident has been contained or mitigated. This post explains why this is a problem and suggests a solution that still enables the SEC to drive companies toward disclosure.

(Terminology note: “Public companies” refers to companies that have stock traded on public US exchanges, and “material” means information that “there is a substantial likelihood that a reasonable shareholder would consider it important.” “Containment” aims to prevent a cyber incident from spreading. Containment is part of “mitigation,” which includes actions to reduce the severity of an event or the likelihood of a vulnerability being exploited, though may fall short of full remediation.)

In sum: The public disclosure of material cybersecurity incidents prior to containment or mitigation may cause greater harm to investors than a delay in public disclosure. We propose that the SEC provide an exemption to the proposed reporting requirements, enabling a company to delay public disclosure of an uncontained or unmitigated incident if certain conditions are met. Additionally, we explain why we believe other proposed solutions may not meet the SEC’s goals of transparency and avoidance of harm to investors.

Distinguished by default public disclosure

The purpose of the SEC’s proposed rule is to help enable investors to make informed investment decisions. This is a reflection of the growing importance of cybersecurity to corporate governance, risk assessment, and other key factors that stockholders weigh when investing. With the exception of reporting unmitigated incidents, Rapid7 largely supports this perspective.

The SEC’s proposed rule would (among other things) require companies to disclose material cyber incidents on Form 8-K, which are publicly available via the EDGAR system. Crucially, the SEC’s proposed rule makes no distinction between public disclosure of incidents that are contained or mitigated and incidents that are not yet contained or mitigated. While the public-by-default nature of the disclosure creates new problems, it also aligns with the SEC’s purpose in proposing the rule.

In contrast to the SEC’s proposed rule, the purpose of most other incident reporting regulations is to strengthen cybersecurity – a top global policy priority. As such, most other cyber incident reporting regulators (such as CISA, NERC, FDIC, Fed. Reserve, OCC, NYDFS, etc.) do not typically make incident reports public in a way that identifies the affected organization. In fact, some regulations (such as CIRCIA and the 2021 TSA pipeline security directive) classify company incident reports as sensitive information exempt from FOIA.

Beyond regulations, established cyber incident response protocol is to avoid tipping off an attacker until the incident is contained and the risk of further damage has been mitigated. See, for example, CISA’s Incident Response Playbook (especially sections on opsec) and NIST’s Computer Security Incident Handling Guide (especially Section 2.3.4). For similar reasons, it is commonly the goal of coordinated vulnerability disclosure practices to avoid, when possible, public disclosure of a vulnerability until the vulnerability has been mitigated. See, for example, the CERT Guide to Coordinated Disclosure.

While it may be reasonable to require disclosure of a contained or mitigated incident within four days of determining its materiality, a strict requirement for public disclosure of an unmitigated or ongoing incident is likely to expose companies and investors to additional danger. Investors are not the only group that may act on a cyber incident report, and such information may be misused.

Smash and grab harms investors and misprices securities

Cybercriminals often aim to embed themselves in corporate networks without the company knowing. Maintaining a low profile lets attackers steal data over time, quietly moving laterally across networks, steadily gaining greater access – sometimes over a period of years. But when the cover is blown and the company knows about its attacker? Forget secrecy, it’s smash and grab time.

Public disclosure of an unmitigated or uncontained cyber incident will likely lead to attacker behaviors that cause additional harm to investors. Note that such acts would be in reaction to the public disclosure of an unmitigated incident, and not a natural result of the original attack. For example:

  • Smash and grab: A discovered attacker may forgo stealth and accelerate data theft or extortion activities, causing more harm to the company (and therefore its investors). Consider this passage from the MS-ISAC’s 2020 Ransomware Guide: “Be sure [to] avoid tipping off actors that they have been discovered and that mitigation actions are being undertaken. Not doing so could cause actors to move laterally to preserve their access [or] deploy ransomware widely prior to networks being taken offline.”
  • Scorched earth: A discovered attacker may engage in anti-forensic activity (such as deleting logs), hindering post-incident investigations and intelligence sharing that could prevent future attacks that harm investors. From CISA’s Playbook: “Some adversaries may actively monitor defensive response measures and shift their methods to evade detection and containment.”
  • Pile-on: Announcing that a company has an incident may cause other attackers to probe the company and discover the vulnerability or attack vector from the original incident. If the incident is not yet mitigated, the copycat attackers can cause further harm to the company (and therefore its investors). From the CERT Guide to CVD: “​​Mere knowledge of a vulnerability’s existence in a feature of some product is sufficient for a skillful person to discover it for themselves. Rumor of a vulnerability draws attention from knowledgeable people with vulnerability finding skills — and there’s no guarantee that all those people will have users’ best interests in mind.”
  • Supply chain: Public disclosure of an unmitigated cybersecurity incident may alert attackers to a vulnerability that is present in other companies, the exploitation of which can harm investors in those other companies. Publicly disclosing “the nature and scope” of material incidents within four business days risks exposing enough detail of an otherwise unique zero-day to encourage rediscovery and reimplementation by other criminal and espionage groups against other organizations. For example, fewer than 100 organizations were actually exploited through the Solarwinds supply chain attack, but up to 18,000 organizations were at risk.

In addition, requiring public disclosure of uncontained or unmitigated cyber incidents may result in mispricing the stock of the affected company. By contradicting best practices for cyber incident response and inviting new attacks, the premature public disclosure of an uncontained or unmitigated incident may provide investors with an inaccurate measure of the company’s true ability to respond to cybersecurity incidents. Moreover, a premature disclosure during the incident response process may result in investors receiving inaccurate information about the scope or impact of the incident.

Rapid7 is not opposed to public disclosure of unmitigated vulnerabilities or incidents in all circumstances, and our security researchers publicly disclose vulnerabilities when necessary. However, public disclosure of unmitigated vulnerabilities typically occurs after failure to mitigate (such as due to inability to engage the affected organization), or when users should take defensive measures before mitigation because ongoing exploitation of the vulnerability “in the wild” is actively harming users. By contrast, the SEC’s proposed rule would rely on a public disclosure requirement on a restrictive timeline in nearly all cases, creating the risk of additional harm to investors that can outweigh the benefits of public disclosure.

Proposed solution

Below, we suggest a solution that we believe achieves the SEC’s ultimate goal of investor protection by requiring timely disclosure of cyber incidents and simultaneously avoiding the unnecessary additional harm to investors that may result with premature public disclosure.

Specifically, we suggest that the proposed rule remains largely the same — i.e., the SEC continues to require that companies determine whether the incident is material as soon as practicable after discovery of the cyber incident, and file a report on Form 8-K four days after the materiality determination under normal circumstances. However, we propose that the rule be revised to also provide companies with a temporary exemption from public disclosure if each of the below conditions are met:

  • The incident is not yet contained or otherwise mitigated to prevent additional harm to the company and its investors;
  • The company reasonably believes that public disclosure of the uncontained or unmitigated incident may cause substantial additional harm to the company, its investors, or other public companies or their investors;
  • The company reasonably believes the incident can be contained or mitigated in a timely manner; and
  • The company is actively engaged in containing or mitigating the incident in a timely manner.

The determination of the applicability of the aforementioned exception may be made simultaneously to the determination of materiality. If the exception applies, the company may delay public disclosure until such time that any of the conditions are no longer occurring, at which point, they must publicly disclose the cyber incident via Form 8-K, no later than four days after the date on which the exemption is no longer applicable. The 8-K disclosure could note that, prior to filing the 8-K, the company relied on the exemption from disclosure. Existing insider trading restrictions would, of course, continue to apply during the public disclosure delay.

If an open-ended delay in public disclosure for containment or mitigation is unacceptable to the SEC, then we suggest that the exemption only be available for 30 days after the determination of materiality. In our experience, the vast majority of incidents can be contained and mitigated within that time frame. However, cybersecurity incidents can vary greatly, and there may nonetheless be rare outliers where the mitigation process exceeds 30 days.

Drawbacks of other solutions

Rapid7 is aware of other solutions being floated to address the problem of public disclosure of unmitigated cyber incidents. However, these carry drawbacks that do not align with the purpose of the SEC rule or potentially don’t make sense for cybersecurity. For example:

  • AG delay: The SEC’s proposed rule considers allowing a delay in reporting the incident when the Attorney General (AG) determines the delay is in the interest of national security. This is an appropriate delay, but insufficient on its own. This AG delay would apply to a very small fraction of major cyber incidents and not prevent the potential harms described above in the vast majority of cases.
  • Law enforcement delay: The SEC’s proposed rule considers, and then rejects, a delay when incident reporting would hinder a law enforcement investigation. We believe this too would be an appropriate delay, to ensure law enforcement can help prevent future cyber incidents that would harm investors. However, it is unclear if this delay would be triggered in many cases. First, the SEC’s proposed timeframe (four days after concluding the incident is material) poses a tight turnaround for law enforcement to start a new investigation or add to an existing investigation, determine how disclosure might impact the investigation, and then request delay from the SEC. Second, law enforcement agencies already have investigations opened against many cybercriminal groups, so public disclosure of another incident may not make a significant difference in the investigation, even if public disclosure of the incident would cause harm. Although a law enforcement delay would be used more than the AG delay, we still anticipate it would apply to only a fraction of incidents.
  • Vague disclosures: Another potential solution is to continue to require public companies to disclose unmitigated cyber incidents on the proposed timeline, but to allow the disclosures to be so vague that it is unclear whether the incident has been mitigated. Yet an attacker embedded in a company network is unlikely to be fooled by a vague incident report from the same company, and even a vague report could encourage new attackers to try to get a foothold in. In addition, very vague disclosures are unlikely to be useful for investor decision-making.
  • Materiality after mitigation: Another potential solution is to require a materiality determination only after the incident has been mitigated. However, this risks unnecessary delays in mitigation to avoid triggering the deadline for disclosure, even for incidents that could be mitigated within the SEC’s proposed timeline. Although containment or mitigation of an incident is important prior to public disclosure of the incident, completion of mitigation is not necessarily a prerequisite to determining the seriousness (i.e., materiality) of an incident.

Balancing risks and benefits of transparency

The SEC has an extensive list of material information that it requires companies to disclose publicly on 8-Ks – everything from bankruptcies to mine safety. However, public disclosure of any of these other items is not likely to prompt new criminal actions that bring additional harm to investors. Public disclosure of unmitigated cyber incidents poses unique risks compared with other disclosures and should be considered in that light.

The SEC has long been among the most forward-looking regulators on cybersecurity issues. We thank them for the acknowledgement of the significance of cybersecurity to corporate management, and for taking the time to listen to feedback from the community. Rapid7’s feedback is that we agree on the usefulness of disclosure of material cybersecurity incidents, but we encourage SEC to ensure its public reporting requirement avoids undermining its own goals and providing more opportunities for attackers.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Additional reading:

New US Law to Require Cyber Incident Reports

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2022/03/10/new-us-laws-to-require-cyber-incident-reports/

New US Law to Require Cyber Incident Reports

On March 9, 2022, the US Congress passed the Cyber Incident Reporting for Critical Infrastructure Act of 2022. Once signed by the President, it will become law. The law will require critical infrastructure owners and operators to report cyber incidents and ransomware payments. The legislation was developed in the wake of the SolarWinds supply chain attack and recently gained additional momentum from the Russia-Ukraine conflict. This post will walk through highlights from the law.

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.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

How Ransomware Is Changing US Federal Policy

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2022/01/26/how-ransomware-is-changing-us-federal-policy/

How Ransomware Is Changing US Federal Policy

In past decades, attackers breaching systems and stealing sensitive information prompted a wave of regulations focused on consumer privacy and breach notification. The current surge in ransomware attacks is prompting a new wave of action from policymakers. Unlike the more abstract harms threatened by breaches of personal information, ransomware will grind systems to a halt, suspending business and government operations and potentially threatening health and safety. One indication of the shift in awareness of this form of cybercrime is that President Biden addressed the ransomware threat multiple times in 2021.

The increased stakes of the ransomware threat are pushing regulators to take a harder look at whether regulatory requirements for cybersecurity safeguards are effective or if new requirements are needed to help combat the threat. The federal agencies are also stepping up their coordination on information sharing and incident reporting, and the Administration is growing its collaboration with international partners and the private sector. Let’s look at a few recent and ongoing initiatives.

Cybersecurity requirements for critical infrastructure

In March 2021, Secretary of Homeland Security Mayorkas announced a series of initiatives to strengthen cybersecurity for critical infrastructure, citing ransomware as a national security threat driving the effort. Less than two months later, the Colonial Pipeline ransomware event disrupted the East Coast fuel supply.

Not long after the Colonial attack, the Transportation Security Administration (TSA) exercised its authority to impose security regulations on the pipeline sector. Through two separate rules, TSA required pipeline operators to establish incident response and recovery plans, implement mitigation measures to protect against ransomware attacks, and undergo annual cybersecurity audits and architecture reviews, among other things.

In December 2021, TSA also issued new security regulations for the aviation, freight rail, and passenger rail sectors. The regulations require (among other things) reporting ransomware incidents to CISA and maintaining an incident response plan to detect, mitigate, and recover from ransomware attacks.

Ransomware is a key motivating factor in the sudden tightening of cybersecurity requirements. Previously, the cybersecurity regulations for pipelines were voluntary, with an accommodative relationship between pipeline operators and their regulators. Policymakers are increasingly voicing concern that other critical infrastructure sectors are in a similar position. With basic societal needs at risk when ransomware successfully disrupts critical infrastructure operations, some lawmakers are signaling openness to creating additional cybersecurity regulations for critical sectors.

OFAC sanctions

The federal government is also using its sanctions authority to head off ransomware payments. According to a recent FinCEN report, the average amount of reported ransomware transactions was approximately $100 million per month in 2021. These payments encourage more ransom-based attacks and fund other criminal activities.

The Office of Foreign Assets Control (OFAC) issued guidance warning that paying ransoms to sanctioned persons and organizations is in violation of sanctions regulations. Liability for these violations, OFAC notes, applies even if the person did not know that the ransomware payment was sent to a sanctioned entity.

Critics of this approach warn that applying sanctions to specific attacker groups is ineffective as the groups can simply rebrand or partner with other criminal elements to take payments. They add that sanctions imposed on payments does nothing but further victimize those organizations or individuals being attacked and remove their choices for recovery or force them underground. Ransomware is already grossly under-reported, and critics of sanctions warn that sanctions will likely encourage a lack of transparency.

More recently, OFAC also issued virtual currency guidance — aimed at currency companies, miners, exchanges, and users — emphasizing that the facilitation of ransomware payments to sanctioned entities is illegal. The guidance also describes best practices for assessing the risk of violating sanctions during transactions. In addition, OFAC imposed sanctions on a Russia-based cryptocurrency exchange for allegedly facilitating financial transactions for ransomware actors — the first sanctions of this kind.

OFAC followed up with an advisory on sanctions guidance for the virtual currency industry and applied sanctions on a cryptocurrency firm that was not doing its due diligence in preventing the facilitation of payments to ransomware criminal gangs.

Ransomware reporting

Requirements to report ransomware payments and ransomware-related incidents to federal authorities is another area to watch. Incident reporting requirements are in place for federal agencies and contractors via a Biden Administration Executive Order, but Congress is taking steps to expand these requirements to other private-sector entities.

Both the House of Representatives and the Senate have advanced legislation that would require businesses to report ransomware payments within 24 hours. The report would need to include the method of payment, instructions for making the payment, and other details to help federal investigators follow the payment flows and identify ransomware trends over time. The legislation would also require owners and operators of critical infrastructure to report substantial cybersecurity incidents (including a disruptive ransomware attack) within 72 hours. Interestingly, the legislation’s definition of “ransomware” encompasses all extortion-based attacks (such as the threat of DDoS), not just malware that locks system operations until a ransom is paid.

Although the House and Senate legislation cleared several hurdles, it did not pass Congress in 2021. However, we expect a renewed push for incident reporting, or other legislation to address ransomware, in 2022 and beyond.

A more collaborative, whole-of-government approach

The Biden Administration characterized ransomware as an economic and national security concern relatively early on and has detailed numerous federal efforts to counter it. We have also seen a marked increase in both international government and law enforcement cooperation, and public-private collaboration to identify, prosecute, and disrupt ransomware criminals, and address their safe harbors. In addition to the above, recent efforts have included:

  • In April 2021, the Department of Justice (DOJ) created a Digital Extortion Task Force, and in June elevated ransomware to be a priority on par with terrorism.
  • In June 2021, the US government attended the G7 Summit and discussed ransomware, making a commitment “to work together to urgently address the escalating shared threat from criminal ransomware networks.” They went on to “call on all states to urgently identify and disrupt ransomware criminal networks operating from within their borders, and hold those networks accountable for their actions.”
  • Also in June 2021, ransomware was discussed during the EU-US Justice and Home Affairs Ministerial Meeting, with commitments made to work together to combat “ransomware including through law enforcement action, raising public awareness on how to protect networks as well as the risk of paying the criminals responsible, and to encourage those states that turn a blind eye to this crime to arrest and extradite or effectively prosecute criminals on their territory.”
  • In August 2021, the Cybersecurity and Infrastructure Security Agency (CISA) announced the formation of the Joint Cyber Defense Collaborative (JCDC) to “integrate unique cyber capabilities across multiple federal agencies, many state and local governments, and countless private sector entities.”
  • In August 2021, the White House announced the voluntary Industrial Control System Cybersecurity Initiative to strengthen the resilience of critical infrastructure against ransomware.
  • In September 2021, NIST issued a ransomware risk management profile for its Cybersecurity Framework.
  • In October 2021, the White House hosted a Counter Ransomware Initiative Meeting, bringing together governments from 30 nations around the world “to discuss the escalating global security threat from ransomware” and identify potential solutions.
  • Also in October 2021, a group of international law enforcement agencies and private sector experts collaborated to force ransomware group REvil offline.
  • In November 2021, the US Department of Justice announced the arrest of three ransomware actors, charges against a fourth, and the “seizure of $6.1 million in funds traceable to alleged ransom payments.” It attributed these successes to “the culmination of close collaboration with our international, US government, and especially our private-sector partners.”
  • Collaboration by multiple federal agencies to produce the StopRansomware site, which provides basic resources on what ransomware is, how to reduce risks, and how to report an incident or request assistance.
  • Ongoing work of senior policymakers such as Deputy Attorney General Lisa Monaco, as well as federal agencies such as CISA and the FBI, to keep up a steady flow of timely alerts about the threat of ransomware and the need for public and private-sector collaboration to fight it.

Ransomware brings security center-stage

For years, it was arguable that most policymakers did not “get” the need for cybersecurity. Now the landscape has changed significantly, with ransomware and nation-state competition driving the renewed sense of urgency. Given the seriousness, persistence, and widespread nature of the ransomware threat, Rapid7 supports new measures to detect and mitigate these attacks. These trends do not seem likely to abate soon, and we expect regulatory activity and information sharing on cybersecurity to be driven by ransomware for some time to come.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

2022 Planning: Simplifying Complex Cybersecurity Regulations

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2021/12/09/2022-planning-simplifying-complex-cybersecurity-regulations/

2022 Planning: Simplifying Complex Cybersecurity Regulations

Compliance does not equal security, but it’s also true that a strong cybersecurity program meets many compliance obligations. How can we communicate industry regulatory requirements in a more straightforward way that enhances understanding while saving time and effort? How can we more easily demonstrate that a robust cybersecurity program will typically meet many compliance requirements?

Rapid7’s latest white paper, “Simplifying the Complex: Common Practices Across Cybersecurity Regulations,” is an educational resource aimed at breaking down complicated regulatory text into a set of consistent cybersecurity practices. The paper analyzes 10 major cybersecurity regulations, identifies common practices across the regulations, and provides insight on how to operationalize these practices.

Read the full white paper

Get it here

You can also reserve your spot for the upcoming webinar, “Common Cybersecurity Compliance Requirements.” Register now at our 2022 Planning webinar series page. This talk is designed to help you apply simplification practices across regulations and help your team plan for the year ahead.  

Different regulations, common practices

Cybersecurity regulations are complex. They target a patchwork of industry sectors and are enforced by disparate federal, state, and international government agencies. However, there are patterns: Cybersecurity regulations often require similar baseline security practices, even though the legislation may structure compliance requirements differently.

Identifying these common elements can help regulated entities, regulators, and cybersecurity practitioners communicate how compliance obligations translate to operational practices. For example, an organization’s security leader(s) could use this approach to drive executive support and investment prioritization by demonstrating how a robust security program addresses an array of compliance obligations facing the organization.

This white paper organizes common regulatory requirements into 6 core components of organizational security programs:

  1. Security program: Maintain a comprehensive security program.
  2. Risk assessment: Assess internal and external cybersecurity risks and threats.
  3. Security safeguards: Implement safeguards to control the risks identified in the risk assessment.
  4. Testing and evaluation: Assess the effectiveness of policies, procedures, and safeguards to control risks.
  5. Workforce and personnel: Establish security roles and responsibilities for personnel.
  6. Incident response: Detect, investigate, document, and respond to cybersecurity incidents and events.

Learn additional background information on each regulation and how these 6 practices are incorporated into many of them. The white paper also provides extensive citations for each requirement so that readers can locate the official text directly.  

Rapid7 solutions help support compliance

Your organization is different from any other — that’s a fact. You’ll operationalize security practices based on individual risk profile, technology, and structure. Rapid7 helps you approach implementation with the context for each of the cybersecurity practices we outline, including:

  1. Operational overview: See how the cybersecurity practice generally operates within an organization’s security program.
  2. Organizational structure: This stipulates which teams or functions within an organization implement the cybersecurity practice.
  3. Successful approaches: These provide approaches to successfully implementing the cybersecurity practice.
  4. Common challenges: These spell out common issues that hinder consistently successful implementation.

Rapid7’s portfolio of solutions can help meet and exceed the cybersecurity practices commonly required by regulations. To illustrate this, the white paper provides extensive product and service mapping intended to help every unique organization achieve its compliance goals. We discuss the key, go-to products and services that help fulfill each practice, as well as those that provide additional support.

For example, when it comes to maintaining a comprehensive security program, it might help to measure the effectiveness of your program’s current state with a cybersecurity maturity assessment. Or, if you’re trying to stay compliant with safeguards to control risk, InsightCloudSec can help govern Identity and Access Management (IAM) and adopt a unified zero-trust security model across your cloud and container environments. And what about testing? From pentesting to managed application security services, simulate real-world attacks at different stages of the software development lifecycle (SDLC) to understand your state of risk and know if your end product is customer-ready.  

Which regulations are discussed in the white paper?

Sector-based

  1. HIPAA (health)
  2. GLBA (financial)
  3. NYDFS Cybersecurity Regulation (financial)
  4. PCI DSS (retail)
  5. COPPA (retail)
  6. NERC CIP (electrical)

Broadly applicable

  1. State Data Security Laws (CA, FL, MA, NY, TX)
  2. SOX

International

  1. GDPR
  2. NIS Directive

When it comes to compliance, it’s not just about running afoul of a regulating body you may not have been aware of when entering a new market. Customer trust is difficult to get back once you lose it.    

A comprehensive cybersecurity program from a trusted and vetted provider will help ensure you’re well-protected from threats and in compliance with regulations wherever your company does business. Whether it’s monitoring and testing services, risk assessments, or certification and training for personnel, your provider should deliver tailored solutions and products that help you meet your unique compliance goals — and protect your users — now and well into the future.

Learn more at our webinar on Monday, December 13

Sign up today

Note: The white paper discussed should not be used as a compliance guide and is not legal advice.

Thawing Out the Chilling Effect Of DMCA Section 1201

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2021/11/15/thawing-out-the-chilling-effect-of-dmca-section-1201/

Thawing Out the Chilling Effect Of DMCA Section 1201

The Copyright Office has issued the latest rules on exemptions to Section 1201 of the Digital Millennium Copyright Act (DMCA). Great news: Legal protections for independent security research have once again been meaningfully strengthened. On the whole, these protections are now significantly greater than they were just a few years ago.

Some quick background: DMCA Section 1201 restricts security research on software without authorization of the owner of the copyright of the software, even for software on devices the researcher owns. This has long been criticized as having an adverse chilling effect on legitimate security research that would otherwise benefit consumers. However, the Librarian of Congress (acting through the Copyright Office) can establish exceptions to DMCA Section 1201, which must be renewed every three years. A three-year cycle has just concluded, with the Copyright Office issuing an updated exception for security research.

[For additional background information on why DMCA is important for security research, please see this earlier post.]

Most recent change: “All other laws” requirement removed

Prior to this most recent update, the security researcher exception provided legal protection from Section 1201 only if the researcher was compliant with every other law or regulation in the world, no matter how obscure. If that sounds ridiculous and burdensome, that’s because it is.

We made this “obey all other laws” issue the focus of our advocacy on Section 1201 throughout 2020 and 2021. As we argued extensively before the Copyright Office, the “all other laws” limitation meant security researchers could lose liability protection under Section 1201 for inadvertently violating laws with significant gray area (like CFAA), minor laws unrelated to security (like the electrical code), or sweepingly restrictive foreign laws (such as China’s rules on vulnerability disclosure).

Rapid7 proposed specific language to address this problem. And thankfully, the Department of Justice (DOJ) formally weighed in with the Copyright Office and supported our proposed language. Without the DOJ’s action to support good-faith security researchers, this effort would likely not have succeeded. Then the Dept. of Commerce joined in support of the language as well.

In October 2021, the Copyright Office handed down an updated exception for security research that adopted our proposed language and removed the “all other laws” requirement. This effectively killed the most harmful aspect of the previous rule, representing major progress in legal protection for security researchers under DMCA Section 1201. The DOJ, NTIA, and Copyright Office were united in expanding  protection — a sign of the growing consensus on the importance of this activity.

The change to the language essentially turns the requirement of compliance with all other laws into a helpful reminder that other laws may still apply. The language looks like this:

Striking:  “and does not violate any applicable law, including without limitation the Computer Fraud and Abuse Act of 1986, as amended and codified in title 18, United States Code.”

Inserting: Good-faith security research that qualifies for the exemption under paragraph (b)(16)(i) of this section may nevertheless incur liability under other applicable laws, including without limitation the Computer Fraud and Abuse Act of 1986, as amended and codified in title 18, United States Code, and eligibility for that exemption is not a safe harbor from, or defense to, liability under other applicable laws.”

Long-haul advocacy

Many hands — too many to adequately thank here — worked tirelessly to ensure security researchers were protected from DMCA Section 1201. It has truly been a community effort.

For our part, Rapid7 has been engaged in advocacy to protect security research under DMCA Section 1201 for the better part of a decade. Testimony from Rapid7 researchers helped establish the first security research exemption in 2015. But this 2015 exemption was limited, and in 2016 we repeatedly pressed the Copyright Office to support expanded protections and reform the rulemaking process, and the Copyright Office implemented many of our recommendations. During the Copyright Office’s 2018 exemption cycle, we argued against holding security researchers liable for what third parties do with research results, to which the Copyright Office agreed. And now, in 2021, we worked with DOJ to convince the Copyright Office to remove the “any other law” restriction.

Taken together, this is a lot of progress. Rapid7 has put real time and effort into living up to its values in support of independent cybersecurity research, and it has borne fruit.

Though improved, Section 1201 remains flawed

These gains are significant and welcome. Still, it is astonishing just how much time and effort were required to wade through the sea of FUD and bureaucracy to achieve this progress. It is a testament to the danger of regulatory inertia.

And there is still more to be done on DMCA. While the security researcher protections are now greatly strengthened under DMCA Section 1201, which helps address its chilling effect on research, the law still has many flaws. As Rapid7 has noted, DMCA Section 1201 continues to be a legal risk for the use of security tools — something the researcher exemption does not address. And outside of security, DMCA continues to affect the right to repair, accessibility for the disabled, education, and much more. This is a law in acute need of a ruthless overhaul.

As far as US computer crime laws go, DMCA Section 1201 is surely among the most unsound and anachronistic. If DMCA Section 1201 were introduced in Congress today, it would be derided as toxic and never advance far enough to receive a vote. DMCA Section 1201’s most beneficial use now is as a smoldering example of how a sweeping restriction on widely used technology can become an absurd burden as technology matures. Other than that, the law is at best a waste of everyone’s time, and we should celebrate its erosion even as we lament that this erosion is gradual.

Our respect and gratitude go to all the advocates who spent their time and resources working with the Copyright Office to drive this progress.

Update to GLBA Security Requirements for Financial Institutions

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2021/11/10/update-to-glba-security-requirements-for-financial-institutions/

Update to GLBA Security Requirements for Financial Institutions

Heads up financial institutions: the Federal Trade Commission (FTC) announced the first cybersecurity updates to the Gramm Leach-Bliley Act (GLBA) Safeguards Rule since 2003. The new rule strengthens the required security safeguards for customer information. This includes formal risk assessments, access controls, regular penetration testing and vulnerability scanning, and incident response capabilities, among other things.

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 changes. Where applicable, we include citations to both the updated rule (starting at page 123) and the previous rule (at 16 USC 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 USC 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 USC 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 USC 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 USC 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 USC 314.4(c). Financial institutions must require service providers to maintain safeguards to protect customer information. 16 USC 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 USC 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 USC 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 USC 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 USC 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 USC 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 USC 314.4(a). Financial institutions must select service providers that can maintain security and require service providers to implement the safeguards. 16 USC 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 USC 314.4(a). Financial institutions must now provide security awareness training and updates to personnel. 16 USC 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 USC 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 USC 314.2(h)(1). However, financial institutions that maintain 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 USC 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.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Cybersecurity in the Infrastructure Bill

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2021/08/31/cybersecurity-in-the-infrastructure-bill/

Cybersecurity in the Infrastructure Bill

On August 10, 2021, the U.S. Senate passed the Infrastructure Investment and Jobs Act of 2021 (H.R.3684). The bill comes in at 2,700+ pages, provides for $1.2T in spending, and includes several cybersecurity items. We expect this legislation to become law around late September and do not expect significant changes to the content. This post provides highlights on cybersecurity from the legislation.

(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.

Rapid7 Joins Statement On DMCA Lawsuits Against Security Tools

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2021/06/23/rapid7-joins-statement/

Rapid7 Joins Statement On DMCA Lawsuits Against Security Tools

Rapid7 has joined a statement from members of the cybersecurity community cautioning against using Section 1201 of the Digital Millennium Copyright Act (DMCA) to suppress beneficial security tools.

In the past, Rapid7 has written extensively about DMCA Sec. 1201’s impact on performing independent research to improve the security and transparency of devices and systems that consumers and businesses rely on. We have called for better protections for good faith security researchers from DMCA Sec. 1201’s prohibition on circumventing technological protection measures (such as encryption, authentication) to software. While there is still work to be done in this area, protections for security testing under DMCA have improved since 2015 as policymakers have increasingly recognized researchers’ helpful role in strengthening security.

However, DMCA Sec. 1201 also gives software owners the ability to file lawsuits against organizations and individuals that provide the technologies and tools that security researchers and practitioners use. See 17 USC 1201(a)(2) and 1201(b). This is separate from the act of performing security testing, and the law affords fewer protections for providing security technologies than for testing. Yet, as the joint statement notes, security practitioners often must depend on third party tools to test software security, both for research and as part of an organizational security program. It would be risky and burdensome to require researchers and practitioners to create their own testing tools, and limiting the use of security tools to those approved by the software owner would undermine effectiveness of testing and introduce conflicts of interest.

With that in mind, the below statement urges prosecutors and private entities to refrain from using DMCA Sec. 1201 to unnecessarily target security testing tools and technologies. A pdf copy of the statement is also available here.

————

We the undersigned write to caution against use of Section 1201 of the Digital Millennium Copyright Act (DMCA) to suppress software and tools used for good faith cybersecurity research. Security and encryption researchers help build a safer future for all of us by identifying vulnerabilities in digital technologies and raising awareness so those vulnerabilities can be mitigated. Indeed, some of the most critical cybersecurity flaws of the last decade, like Heartbleed, Shellshock, and DROWN, have been discovered by independent security researchers.

However, too many legitimate researchers face serious legal challenges that prevent or inhibit their work. One of these critical legal challenges comes from provisions of the DMCA that prohibit providing technologies, tools, or services to the public that circumvent technological protection measures (such as bypassing shared default credentials, weak encryption, etc.) to access copyrighted software without the permission of the software owner. 17 USC 1201(a)(2), (b). This creates a risk of private lawsuits and criminal penalties for independent organizations that provide technologies to  researchers that can help strengthen software security and protect users. Security research on devices, which is vital to increasing the safety and security of people around the world, often requires these technologies to be effective.

Good faith security researchers depend on these tools to test security flaws and vulnerabilities in software, not to infringe on copyright. While Sec. 1201(j) purports to provide an exemption for good faith security testing, including using technological means, the exemption is both too narrow and too vague. Most critically, 1201(j)’s accommodation for using, developing or sharing security testing tools is similarly confined; the tool must be for the “sole purpose” of security testing, and not otherwise violate the DMCA’s prohibition against providing circumvention tools.

If security researchers must obtain permission from the software vendor to use third-party security tools, this significantly hinders the independence and ability of researchers to test the security of software without any conflict of interest. In addition, it would be unrealistic, burdensome, and risky to require each security researcher to create their own bespoke security testing technologies.

We, the undersigned, believe that legal threats against the creation of tools that let people conduct security research actively harm our cybersecurity. DMCA Section 1201 should be used in such circumstances with great caution and in consideration of broader security concerns, not just for competitive economic advantage. We urge policymakers and legislators to reform Section 1201 to allow security research tools to be provided and used for good faith security research In addition, we urge companies and prosecutors to refrain from using Section 1201 to unnecessarily target tools used for security research.

Bishop Fox
Bitwatcher
Black Hills Information Security
Bugcrowd
Cybereason
Cybersecurity Coalition
disclose.io
Electronic Frontier Foundation
GRIMM
HackerOne
Hex-Rays
iFixIt
Luta Security
McAfee
NCC Group
NowSecure
Rapid7
Red Siege
SANS Technology Institute
SCYTHE
Social Exploits LLC

Principles for personal information security legislation

Post Syndicated from Harley Geiger original https://blog.rapid7.com/2021/01/21/principles-for-personal-information-security-legislation/

Principles for personal information security legislation

It goes without saying that the 117th US Congress has a lot to get done and many legitimate priorities are competing for finite legislative attention. Cybersecurity will be in this mix. In the wake of the SolarWinds attack, President-elect Biden issued a statement emphasizing that his Administration will make cybersecurity “a top priority at every level of government.” Vice President-elect Harris was a leader on consumer privacy protection during her time as California’s Attorney General. Given the Democrat-controlled Congress, the multiple privacy/security bills filed in many past legislative sessions, and continued action by states such as California and Washington, businesses should anticipate another push for federal private sector privacy and security legislation in the upcoming Congress. (Whether such legislation actually passes, given the mix of other priorities, is another matter!)

[Check out our past blog post on updating state data security laws.]

Rapid7 welcomes this effort. Congress should pass legislation requiring security of personal information nationwide, independent of breach notification, either as a standalone or as part of comprehensive privacy legislation. We believe consumers and businesses will benefit from uniform rules on data protection, rather than the growing patchwork of state and international privacy regulations. Although security of personal information is only one slice of the broader issue of cybersecurity, it is one that directly affects many individuals, and the ripple effect of requirements to secure personal information will help raise the overall bar on the security of other systems and entities.

Principles for personal information security legislation
A simple model of the overlap. (See also NIST Privacy Framework, pg. 3.)

While any federal privacy and security legislation must accommodate a broad diversity of organizations, it must also be effective and not take a significant step back from protections consumers have today. To that end, as we aim to strike that balance, we suggest the below high level principles on personal information security legislation.  

What we look for in personal information security legislation

1. Effective security requirements.
Require private sector entities to implement reasonable security processes for personal information they collect, store, maintain, or transmit (AKA “personal information security”) to protect the security of personal information against unauthorized acquisition and access. The requirements should be:

  • Flexible. To avoid a disproportionate burden, the security program should be flexible to accommodate a diverse range of organizations. These considerations can include the size and complexity of the covered entity, the sensitivity of the personal information, the state of the art in security protection, and material cybersecurity risks and threats.

  • Built around key security program elements. To keep pace with evolving threats for a diversity of organizations, required security elements should be risk-based. However, legislation should specify that the security program must include high level elements based on standards, best practices, and existing regulations such as GLBA and HIPAA. We believe those elements should include:

    • Designate staff. Designate employees to coordinate the security program, ensure they have adequate resources and training.
    • Risk assessment. Assess material internal and external risks, threats, and vulnerabilities to security of personal information. Periodically reassess.
    • Security controls. Implement physical, technical, and administrative safeguards reasonably designed to control risks identified through the risk assessment. Inclusion of “reasonably” is helpful to ensure the controls are objectively commensurate with the risks.
    • Monitoring and testing. Regularly test and monitor the effectiveness of safeguards.
    • Service providers. Oversee service providers’ implementation of security safeguards.
    • Incident detection and response. Develop and implement written plans to detect, respond to, and recover from cybersecurity intrusions, events, and incidents.

  • Not limited to financial harm. Security requirements should not be limited to protecting against financial, physical, or “substantial” harm. This common loophole would be severely limiting and out of step with user expectations, the wide array of threats organizations face, and many state laws (see, e.g., CA, FL, NY, TX).

2. Security exemption from privacy restrictions.
Privacy law and legislation tend to include a series of exemptions for publicly beneficial purposes, such as public safety (see, e.g., GDPR) If security is folded into privacy legislation, it is important to avoid impeding cybersecurity by exempting activities necessary for security from privacy restrictions. For example, a privacy requirement to obtain consent to share personal information should not apply in a situation where a covered entity detects a phishing attempt and shares the phishing email with other companies or an ISAC to help prevent successful phishing.

  • Scope. The security exemption should cover activities for prevention, detection, and response of cybersecurity incidents and threats. Security should be exempt from a broad range of privacy requirements, rather than just a limited subset, to be most effective.

3. Preemption without undermining cybersecurity.
The issue of whether federal rules should preempt state laws is hotly contested, and a major challenge to the progress of past privacy and security legislation. (Rapid7 supports preemption of state security laws with a strong national standard to provide consistent protections to consumers and because complexity hinders compliance.) For purposes of these principles, we are focusing here only on ensuring that any federal preemption avoids undermining other cybersecurity laws, rules, and standards that are not directly related to personal information security. Examples of state rules that should not be preempted by a federal personal information security law include system security requirements, IoT and critical infrastructure security standards, government procurement requirements, computer crime and wiretapping laws, etc.

  • Scope. Rapid7’s recommendation is to preempt state laws, regulations, and rules having the force of law (not standards without the force of law) that require covered entities (as defined in the legislation) to secure personal information (as defined in the legislation). An example of legislation with an overly broad preemption provision that does not meet this framework, and may undermine cybersecurity, is the SAFE DATA Act of 2020 (S.4626, Sec. 405).

In an effort to be relatively brief, we won’t attempt to cover all the nuance and context for information security legislation (like the much-contested definition of “personal information”). Instead, the above focuses on a few security-specific sticking points that we believe are worth emphasizing based on our experience in working on past legislative efforts.

Worth consistent protections

Federal personal information security legislation is past due, as every year of delay tends to see uncoordinated growth in state and international privacy and data security regulations. Nonetheless, we should temper our expectations about the chances of federal privacy or security legislation crossing the Congressional finish line in the next two years amid competing priorities. Still, we are confident personal information security requirements will be revisited and worked on again during the 117th Congress, and the above principles will help guide Rapid7’s response.