Tag Archives: Rapid7 Perspective

Navigating the Evolving Patchwork of Incident Reporting Requirements

Post Syndicated from Peter Woolverton original https://blog.rapid7.com/2022/08/10/navigating-the-evolving-patchwork-of-incident-reporting-requirements/

Navigating the Evolving Patchwork of Incident Reporting Requirements

In March 2022, President Biden signed into law the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA), a bipartisan initiative that empowers CISA to require cyber incident reporting from critical infrastructure owners and operators. Rapid7 is supportive of CIRCIA and cyber incident reporting in general, but we also encourage regulators to ensure reporting rules are streamlined and do not impose unnecessary burdens on companies that are actively recovering from cyber intrusions.

Although a landmark legislative change, CIRCIA is just one highly visible example of a broader trend. Incident reporting has emerged as a predominant cybersecurity regulatory strategy across government. Numerous federal and state agencies are implementing their own cyber incident reporting requirements under their respective rulemaking authorities – such as SEC, FTC, the Federal Reserve, OCC, NCUA, NERC, TSA, NYDFS, and others. Several such rules are already in force in US law, with at least three more likely to become effective within the next year.

The trend is not limited to the US. Several international governing bodies have proposed similar cyber incident reporting rules, such as the European Union’s (EU) NIS-2 Directive.

Raising the bar for security transparency through incident reporting is a productive step in a positive direction. Incident reporting requirements can help the government to manage sectoral risk, encourage a higher level of private-sector cyber hygiene, and enhance intrusion remediation and prevention capabilities. But the rapid embrace of this new legal paradigm may have created too much of a good thing, with the emerging regulatory environment risks becoming unmanageable.

Current state

Cyber incident reporting rules that enforce overlapping or contradictory requirements can impose undue compliance burdens on organizations that are actively responding to cyberattacks. To illustrate the problem, consider the potential experience of a hypothetical company – let’s call it Energy1. Energy1 is a US-based, publicly traded utility company that owns and operates energy generation plants, electrical transmission systems, and natural gas distribution lines. If Energy1 experiences a significant cyber attack, it may be required to submit the following reports:

  • Within one hour, provide to NERC – under NERC CIP rules – a report with preliminary details about the incident and its functional impact on operations.
  • Within 24 hours, provide to TSA – under the pipeline security directive – a report with a complete description of the incident, its functional impact on business operations, and the details of remediation steps.
  • Within 72 hours, provide to CISA – under CIRCIA – a complete description of the incident, details of remediation steps, and threat intelligence information that may identify the perpetrator.
  • Within 96 hours, provide to SEC – under the SEC’s proposed rule – a complete description of the incident and its impact, including whether customer data was compromised.

In our hypothetical scenario, Energy1 may need to rapidly compile the necessary information to comply with each different reporting rule or statute, all while balancing the urgent need to remediate and recover from a cyber intrusion. Furthermore, if Energy1 operates in non-US markets as well, it may be subject to several more reporting requirements, such as those proposed under the draft NIS-2 Directive in the EU or the CERT-IN rule in India. Many of these regulations would also require subsequent status updates after the initial report.

The example above demonstrates the complexity of the emerging patchwork of incident reporting requirements. Legal compliance in this new environment creates a number of challenges for the private sector and the government. For example:

  • Redundant requirements: Unnecessarily duplicative compliance requirements imposed in the wake of a cyber incident can draw critical resources away from incident remediation, potentially leading to lower-quality data submitted in the reports.
  • Public vs. private disclosure: Most reports are held privately by regulators, but the SEC’s proposed rule would require companies to file public reports within 96 hours of determining that an incident is significant. Public disclosure before the incident is contained or mitigated may expose the affected company to further risk of cyberattack. In addition, premature public reporting of incidents prior to mitigation may not provide an accurate reflection of the affected company’s cyber incident response capabilities.
  • Inconsistent requirements: The definition of what is reportable is not consistent across agency rules. For example, the SEC requires reporting of cyber incidents that are “material” to a reasonable investor, whereas NERC requires reporting of almost any cyber incident, including failed “attempts” at cyber intrusion. The lack of a uniform definition of reportability adds another layer of complexity to the compliance process.
  • Process inconsistencies: As demonstrated in the Energy1 example, all incident reporting rules and proposed rules have different deadlines. In addition, each rule and proposed rule has different required reporting formats and methods of submission. These process inconsistencies add friction to the compliance process.

Recommendations

The key issues outlined above may be addressed by the Cyber Incident Reporting Council (CIRC), an interagency working group led by the Department of Homeland Security (DHS). This Council was established under CIRCIA and is tasked with harmonizing existing incident reporting requirements into a more unified regulatory regime. A readout of the Council’s first meeting, convened on July 25, stated CIRC’s intent to “reduce [the] burden on industry by advancing common standards for incident reporting.”

In addition to DHS, CIRC includes representatives from across government, including from the Departments of Justice, Commerce, Treasury, and Energy among others. It is not yet clear from the Council’s initial meeting how exactly CIRC will reshape cyber incident reporting regulations, or whether such changes will be achievable through executive action or whether new legislation will be needed. The Council will release a report with recommendations by the end of 2022.

Rapid7 urges CIRC to consider several harmonization strategies intended to streamline compliance while maintaining the benefits of cyber incident reporting, such as:

  • Unified process: When practically possible, develop a single intake point for all incident reporting submissions with a universal format accepted by multiple agencies. This would help eliminate the need for organizations to submit several reports to different agencies with different formats and on different timetables.
  • Deconflicted requirements: Agree on a more unified definition of what constitutes a reportable cyber incident, and build toward more consistent reporting requirements that satisfy the needs of multiple agency rules.
  • Public disclosure delay: Releasing incident reports publicly before affected organizations have time to contain the breach may put the security of the company and its customers at unnecessary risk. Requirements that involve public disclosure, such as proposed rules from the SEC and FTC, should consider delaying and coordinating disclosure timing with the affected company.

Some agencies in the Federal government are already designing incident reporting rules with harmonization in mind. The Federal Reserve, FDIC, and OCC, rather than building out three separate rules for each agency, designed a single universal incident reporting requirement for all three agencies. The rule requires only one report be submitted to whichever of the three agencies is the affected company’s “primary regulator.” The sharing of reports between agencies is handled internally, removing from companies the burden of submitting multiple reports to multiple agencies. Rapid7 supports this approach and would encourage the CIRC to pursue a similarly streamlined strategy in its harmonization efforts where possible.

Striking the right balance

Rapid7 supports the growing adoption of cyber incident reporting. Greater cybersecurity transparency between government and industry can deliver considerable benefits. However, unnecessarily overlapping or contradictory reporting requirements may cause harm by detracting from the critical work of incident response and recovery. We encourage regulators to streamline and simplify the process in order to capture the full benefits of incident reporting without exposing organizations to unnecessary burden or risk in the process.

Additional reading:

NEVER MISS A BLOG

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

[VIDEO] An Inside Look at the RSA 2022 Experience From the Rapid7 Team​

Post Syndicated from Jesse Mack original https://blog.rapid7.com/2022/06/10/video-an-inside-look-at-the-rsa-2022-experience-from-the-rapid7-team/

[VIDEO] An Inside Look at the RSA 2022 Experience From the Rapid7 Team​

The two years since the last RSA Conference have been pretty uneventful. Sure, COVID-19 sent us all to work from home for a little while, but it’s not as though we’ve seen any supply-chain-shattering breaches, headline-grabbing ransomware attacks, internet-inferno vulnerabilities, or anything like that. We’ve mostly just been baking sourdough bread and doing woodworking in between Zoom meetings.

OK, just kidding on basically all of that (although I, for one, have continued to hone my sourdough game). ​

The reality has been quite the opposite. Whether it’s because an unprecedented number of crazy things have happened since March 2020 or because pandemic-era uncertainty has made all of our experiences feel a little more heightened, the past 24 months have been a lot. And now that restrictions on gatherings are largely lifted in most places, many of us are feeling like we need a chance to get together and debrief on what we’ve all been through.

Given that context, what better timing could there have been for RSAC 2022? This past week, a crew of Rapid7 team members gathered in San Francisco to sync up with the greater cybersecurity community and take stock of how we can all stay ahead of attackers and ready for the future in the months to come. We asked four of them — Jeffrey Gardner, Practice Advisor – Detection & Response; Tod Beardsley, Director of Research; Kelly Allen, Social Media Manager; and Erick Galinkin, Principal Artificial Intelligence Researcher — to tell us a little bit about their RSAC 2022 experience. Here’s a look at what they had to say — and a glimpse into the excitement and energy of this year’s RSA Conference.

What’s it been like returning to full-scale in-person events after 2 years?



[VIDEO] An Inside Look at the RSA 2022 Experience From the Rapid7 Team​

What was your favorite session or speaker of the week? What made them stand out?



[VIDEO] An Inside Look at the RSA 2022 Experience From the Rapid7 Team​

What was your biggest takeaway from the conference? How will it shape the way you think about and practice cybersecurity in the months to come?



[VIDEO] An Inside Look at the RSA 2022 Experience From the Rapid7 Team​

Want to relive the RSA experience for yourself? Check out our replays of Rapid7 speakers’ sessions from the week.

Additional reading:

NEVER MISS A BLOG

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

The Hidden Harm of Silent Patches

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2022/06/06/the-hidden-harm-of-silent-patches/

The Hidden Harm of Silent Patches

Hey all. I’m about to head off to RSAC 2022, but I wanted to jot down some thoughts I’ve had lately on a particularly squirrelly issue that comes up occasionally in coordinated vulnerability disclosure (CVD) — the issue of silent patches, and how they tend to help focused attackers and harm IT protectors.

In the bad old days, most major software vendors were rather notorious for sweeping vulnerability reports under the rug. They made it difficult for legitimate researchers to report vulnerabilities, often by accident, occasionally on purpose. Researchers would report bugs, and those reports would fester in unobserved space, then suddenly the proof-of-concept exploit wouldn’t work any more. This was (and is) the standard silent patching model. No credit, no explanation, no CVE ID, nothing.

The justification for this approach seems pretty sensible, though. Why would a vendor go out of their way to explain what a security fix does? After all, if you know how the patch works, then you have a pretty good guess at the root cause of the vulnerability and, therefore, how the exploit works. So, by publicizing these patch details, you’re effectively leading attackers to the goods, based on your own documentation. Not cool, right?

So, the natural conclusion is that by limiting the technical details of a given vulnerability to merely the patch contents, and by withholding those details explained in plan languages and proof-of-concept exploit code and screenshots and videos and all the rest, you are limiting the general knowledge pool of people who actually understand the vulnerability and how to exploit it.

Unpacking the silent patch

This sounds like a great plan, but there’s a catch. When a software company releases a patch for software, in nearly all cases, they’re not using exotic packers, they’re not employing anti-forensics, and even if the patch data is encrypted and obfuscated, at some point it’s got to modify the code on the running software — which means that it’s all available to anyone who has a running instance of the patched software and knows how to use a debugger and a disassembler. And who uses debuggers to inspect the effects of patches? Exploit developers, pretty much exclusively.

Knowing this, let’s modify the expectations of the silent patch strategy: When you silently patch, you are intending to limit knowledge of the patched vulnerability to skilled exploit devs.

It’s still true that you’re excluding the casual attacker (or “script kiddie,” in the common parlance), and that’s great and desirable. However, you’re also excluding a huge population of IT protectors: penetration testers who are paid to write and run exploits to test defenses leap to mind, in addition to the folks who write and deploy defensive technologies like vulnerability management, intrusion detection and prevention, incident detection, and all the rest. You also exclude tech journalists, academics, and policy makers who want to understand and communicate the nature of software vulnerabilities, but who aren’t likely to bust out a disassembler.

Most significantly, you’re excluding the most important audience for your patch: the regular IT administrators and managers who need to sort out the incoming flow of patches based on some risk and severity criteria and make the call for downtime and update scheduling based on that criteria. Not all vulnerabilities are equal, and while protectors want to get around to all of them, they need to figure out which ones to apply today and which ones can wait for the next maintenance cycle.

By the way, it’s true that some of these IT professionals also have the capability to reverse-engineer your patch. In practice, people who are only interested in keeping IT humming never, ever reverse patches to see if they’re worth applying. It’s way too complicated and time-consuming. I’ve never seen a case where this is part of the decision-making process to patch now or later.

Don’t leave defenders in the dark

So now, let’s reexamine the case for silent patching yet again: When you silently patch, you are communicating vulnerability details, exclusively, to skilled, criminal attackers who are specifically targeting your product, while leaving your customers in the dark. You are intentionally withholding information from casual attackers, secondary defenders, and your customers and users who are desperate to make informed security engineering decisions involving your product or project. Oh, and let’s not forget, you’re also limiting knowledge about these fixed vulnerabilities from future employees and contributors, who very well might re-introduce the same or similar bugs in your product down the road. After all, the details are secret, even from future-you.

All this is to say, silent patching is tantamount to full disclosure to a very small audience who mostly want to hurt you and your users. Fully documented patches reach the much, much larger audience of people, present and future, who want to help you and your users. While it’s true that you are also offering educational opportunities to casual attackers along the way, I believe the global population of casual attackers is much, much smaller than your legitimate users and all the secondary and tertiary defenders who are on your side.

So, next time a vulnerability researcher states their intention of publishing details about their reported (and now patched) vulnerability, try to examine your urge to keep those details under wraps, and maybe even encourage them to be honest and transparent with their findings. The alternative is to build up the operational capabilities of the true criminal and espionage enterprises while degrading the decision-making power of IT protectors.

Additional reading:

NEVER MISS A BLOG

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

A Year on from the Ransomware Task Force Report

Post Syndicated from Jen Ellis original https://blog.rapid7.com/2022/05/24/a-year-on-from-the-ransomware-task-force-report/

A Year on from the Ransomware Task Force Report

If you follow cybersecurity, you’ve likely seen one of the many articles written recently on the one-year anniversary of the Colonial Pipeline ransomware attack, which saw fuel delivery suspended for six days, disrupting air and road travel across the southeastern states of the US. The Colonial attack was the biggest cyberattack against US critical infrastructure, making it something of a game-changer in the realm of ransomware, so it is absolutely worth noting the passage of time and investigating what’s changed since.

This blog will do that, but I’ll take a slightly different tack, as I’m also marking the anniversary of the Ransomware Task Force’s (RTF) report, which offered 48 recommendations for policymakers wanting to deter, disrupt, prepare, and respond to ransomware attacks. The report was issued a week prior to the Colonial attack.

Last week, I participated in an excellent event to mark the one-year anniversary of the RTF report. During the session, various ransomware experts discussed how the ransomware landscape has evolved over the past year, how government action has shaped this, and what more needs to be done. The Institute for Security and Technology (IST), which convenes and runs the RTF, has issued a paper capturing the points above. This blog offers my own thoughts on the matter, but it’s not at all exhaustive, and I recommend giving the official paper a read.

High-profile attacks raised the stakes

Looking back over the past year, in many ways, the Colonial attack – along with ransomware attacks on the Irish Health Service Executive (HSE) and JBS, the largest meat processing company in the world, all of which occurred during May 2021 – highlighted the exact concerns outlined in the RTF report. Specifically, the RTF had been convened based on the view that the high level of attacks against healthcare and other critical services through the pandemic made ransomware a matter of national security for those countries that are highly targeted.

In light of this, one of the most fundamental recommendations of the report was that this be acknowledged and met with a senior leadership and cross-governmental response. The Colonial attack resulted in President Biden addressing the issue of ransomware on national television. Subsequently, we have seen a huge cross-governmental focus on ransomware, with measures announced from departments including Homeland Security, Treasury, Justice, and State. We’ve also seen both Congress and the White House working on the issue. And while the US government has been the most vocal in its response, we have seen other governments also focusing on this issue as a priority and working together to amplify the impact of their action.

In June 2021, the Group of Seven (G7) governments of the world’s wealthiest democracies addressed ransomware at its annual summit. The resulting Communique capturing the group’s commitments includes pledges to work together to address the threat. In October 2021, the White House hosted the governments of 30 nations to discuss ransomware. The event launched the Counter Ransomware Initiative (CRI), committing to collaborate together to find solutions to reduce the ransomware threat. The CRI has identified key themes for further exploration and action, with a similar focus on deterring and disrupting attacks and driving adoption of greater cyber resilience.

Status of the RTF recommendations

This is all heartening to see and strongly aligns with the ethos and recommendations of the RTF recommendations. Drilling down into more of the details, there are many further areas of alignment, including the launch of coordinated awareness programs, introduction of sanctions, scrutiny of cryptocurrency regulations, and a focus on incident reporting regulations. The RTF paper provides a great deal more detail on these areas of alignment and the progress that has been made, as well as the areas that need more focus.

This, I believe, is the key point: A great deal of progress has been made, both in terms of building understanding of the problem and in developing alignment and collaboration among stakeholders, yet there is a great deal more work to be done. The partnerships between multiple governments — and between the public and private sectors — are hugely important for improving our odds against the attackers, but progress will not happen overnight. It will take time to see the real impact of the measures already taken, and there are yet measures to be determined, developed, and implemented.

Uncertain times

We must keep our eye on the ball and stay engaged, which is not easy when there are so many other demands on governments’ and business leaders’ limited time and resources. The Russia/Ukraine conflict has undoubtedly been a very time-consuming area of focus, though expectations that offensive cyber operations would be a key element of the Russian action have perhaps helped increase awareness of the need for cyber resilience. The economic downturn is another huge pressure and will almost certainly reduce critical infrastructure providers’ investments in cybersecurity as the cost of business increases in other areas, resulting in budget cuts. While both of these developments may distract governments and business leaders from ransomware, they may also increase ransomware activity as economic deprivation and job scarcity encourage more people to turn to cybercrime to make a living.

According to law enforcement and other government agencies, as well as the cyber insurance sector, the reports of ransomware incidents are slowing down or declining. Due to a long-standing lack of consistent incident reporting, it’s hard to contextualize this, and while we very much hope it points to a reduction in attacks, we can’t say that that’s the case. Security researchers report that activity on the dark web seems to be continuing at pace with 2021, a record year for ransomware attacks. It’s possible that the shift in view from law enforcement could be due to fears that involving them will result in regulatory repercussions; reports to insurers could be down due to the introduction of more stringent requirements for claims.

The point is that it’s too early to tell, which is why we need to maintain a focus on the issue and seek out data points and anecdotal evidence to help us understand the impact of the government action taken so far, so we can continue to explore and adjust our approach. An ongoing focus, continued collaboration, and more data will help ensure we put as much pressure as possible on ransomware actors and the governments and systems that allow them to flourish. Over time, this is how we will make progress to reduce the ransomware threat.

Additional reading:

NEVER MISS A BLOG

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

The Forecast Is Flipped: Flipping L&D in New Hire Training

Post Syndicated from Megan Yawor original https://blog.rapid7.com/2022/04/06/the-forecast-is-flipped-flipping-l-d-in-new-hire-training/

The Forecast Is Flipped: Flipping L&D in New Hire Training

Rapid7’s onboarding program, Making the Band, first came to the stage in the fall of 2017 when the original 2-week, video-based program evolved into a dynamic 90-day experience. The updated program delivered learnings to new hires through digital self-paced content and a 2-day live training focused on tactical elements, as well as foundational company knowledge.

However, in the spirit of Never Done, the Rapid7 People Development team challenged convention and recently evolved the onboarding program to address the needs of our evolving business and the future of work.

After analyzing the current state of the program, People Development realized that what was needed was a streamlined experience that supported and connected a growing, hybrid company, as well as one that aligned and prepared employees for role-specific success, regardless of their location or position.

The goal of this work was to reimagine the current onboarding process in a way that sustained the essence of the original 2017 experience, but also adapted and scaled as we onboarded a global new hire population. This would be achieved by keeping ALL Moose in mind, curating opportunities that built connections in this new normal, emphasizing the importance and impact of our culture, and seamlessly guiding new Moose through the fundamentals in order to shorten their time to impact.

Flipped learning: Delivering a vision for evolution

A primary focus for Rapid7’s People Strategy team is to help our Moose build the best career experience. Onboarding is the first step to building this experience. Denee D’Andrea, Sr. People Development Specialist and visionary behind the evolved program, recognized this and wanted to ensure that the program delivered the right content at the right time. This resulted in a new global onboarding experience that extended beyond one-and-done live sessions and self-paced content to a full, multifaceted experience, using blended learning and flipped-classroom approaches.

D’Andrea’s new onboarding vision focused on 3 key phases grounded in our Core Values: Connection, Impact in Your Role, and Embodiment of Bring You.

Rapid7 recognized creating connections was a key element of success while working in a hybrid environment. Because of that, D’Andrea partnered with organizations across the business to ensure opportunities for connection were threaded throughout the entire program. The Connection piece was fostered using the flipped approach – meaning the majority of “classroom time” was spent teaching through discussions led by Rapid7 Culture Ambassadors (our own Moose!) and subject matter experts.

Additionally, to stay true to the Challenge Convention mindset, I created a fully virtual, interactive multi-phase challenge with the goal of further encouraging connections. By navigating animations, digital games, and customized puzzles and codes, new hires were introduced to the security landscape, customer challenges, and Rapid7’s portfolio. The intentional design of the challenge provided the space and activities to encourage discussion and collaboration towards a common goal. New Moose would not only connect with each other (regardless of their location) but also feel like they were connecting with Rapid7’s history, culture, and Core Values.

Next, Impact in your Role focused on encouraging the Never Done mindset and highlighted the connection between individual growth and the success of our teams, customers, and the company as a whole. This mindset was woven throughout the entire 90 days, both within “classroom time” and in the on-demand, self-paced digital content. To create the most impactful learning environment, the team again utilized the flipped classroom. Live sessions provided collaborative learning and discussion opportunities, and then digital flipped-learning materials further fleshed out the learnings. This design ensured New Moose not only benefited from social learning but also fostered accountability to their development both during and beyond the onboarding experience.

And finally, Embodiment of Bring You. At Rapid7, we truly want our people to bring their authentic selves to their work because we believe that these unique perspectives, ideas, and values enable us to Challenge Convention and enhance the work we do. The final piece of the program, an experiential learning challenge, encouraged New Moose to embrace the value Bring You while collaborating with their cohort and Culture Ambassadors to build their cross-functional network.

The New New Moose

On January 3, 2022, this new program launched, for the first time, with a cohort of 43 New Moose. Since then, over 370 Moose, globally, have engaged with the program.

And how has it been? EPIC.

Making the Band is where our New Moose start building the career experience of a lifetime.This program not only motivates and empowers employees to embody our Core Values but also helps them to understand that we are #onemoose, and when we Impact Together, we accelerate together.

Check out what some of our New Moose are saying!

The program

  • “AWESOME… Onboarding has been an incredible experience so far… One of the best onboarding experiences I have had in my professional career… I believe Rapid7 has an amazing and talented team facilitating the onboarding experience.”

Virtual, interactive challenge (“Insuring” the Security of MiracleMoose Insurance)

  • “That was fun and engaging… The group roles/participation were great…it was a fun way to collaborate with my fellow new Moose… and the content was highly engaging which provided a meaningful intro to Rapid7’s portfolio and the customer while also fostering communication and critical thinking skills.”

Stay tuned over the next several months to dive deeper into how People Development will be introducing flipped content and other innovative practices into all of their programs for 2022 and beyond in our blog series, “The Forecast Is Flipped.”

Additional reading:

NEVER MISS A BLOG

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

Security for All: How the Rapid7 Cybersecurity Foundation Will Expand Access and Inclusion

Post Syndicated from Peter Kaes original https://blog.rapid7.com/2022/04/05/security-for-all-how-the-rapid7-cybersecurity-foundation-will-expand-access-and-inclusion/

Security for All: How the Rapid7 Cybersecurity Foundation Will Expand Access and Inclusion

Rapid7’s mission is to advance cybersecurity for all — and an essential part of that effort is making the field and its best resources easier to access. That’s why we deliver solutions that meet the needs of large enterprises but can also be deployed and operated by more resource-constrained teams. It’s also why we’ve put so much time, effort, and capital into creating open-source tools and research that help democratize security knowledge.

In keeping with this focus, access and inclusion have also been at the core of our philanthropic and community engagement efforts. Over the years, we’ve launched and supported numerous initiatives to expand diversity by ensuring greater access to careers in cybersecurity. This includes supporting STEM programs that provide opportunities for experiential learning with industry professionals, as well as programs like Hack.Diversity that ensure we’re accessing the full talent landscape as we hire our next thousand employees.

Introducing the Rapid7 Cybersecurity Foundation

As we address the challenges in cybersecurity, we must also remain focused on ensuring the underserved and underrepresented have access to careers and solutions in the field. Over the past 10 years, we’ve allocated millions of dollars in support of organizations that help support this goal. In 2020, Rapid7 established and funded a Donor-Advised Fund with the Tides Foundation, and in 2021, we donated over $300,000 to numerous organizations from our Fund. But we were far from done. A few months ago, we formed the Rapid7 Cybersecurity Foundation and seeded it with $1 million.

The Foundation’s mission is to democratize cybersecurity by focusing on access for the underrepresented and underserved. We do this by promoting a diverse and inclusive cybersecurity workforce, supporting free and open security solutions, and advocating for those who often lack a voice in advancing security.

The Foundation will partner with organizations that work in the following areas in pursuit of creating a secure and prosperous digital future for all:

  • STEM education, diversity and inclusion in technology, and efforts by organizations to expand opportunities to historically underrepresented groups and make careers in cybersecurity more accessible for all
  • Open-source tools and volunteering to help make effective cybersecurity solutions available to under-resourced organizations, including nonprofits and municipalities
  • Research and policy advocacy to strengthen cybersecurity for vulnerable communities, improve cybersecurity awareness, and make achieving effective security outcomes more available to all

Putting purpose into practice

After more than 8 years of having the privilege of being Rapid7’s General Counsel, I’m ecstatic to have the opportunity to serve as Executive Director of the Rapid7 Cybersecurity Foundation and to head up our growing ESG (Environmental, Social & Governance) program. In preparing for this transition, I recently read the excellent 2022 Letter to CEOs written by Larry Fink, CEO and Chairman of Black Rock. In it, he writes that a clear sense of purpose, consistent values, and engaging with and delivering for key stakeholders is what distinguishes truly great companies.

Accelerating digital transformation continues to create new challenges and opportunities for cybersecurity practitioners and the industry. It is also redefining the relationship between a company, its employees, and society. Fink writes:

Putting your company’s purpose at the foundation of your relationships with your stakeholders is critical to long-term success. Employees need to understand and connect with your purpose; and when they do, they can be your staunchest advocates. Customers want to see and hear what you stand for as they increasingly look to do business with companies that share their values. And shareholders need to understand the guiding principle driving your vision and mission.

The Rapid7 Cybersecurity Foundation, with its focus on helping advance cybersecurity for the underserved and underrepresented, is a natural extension of Rapid7’s mission to advance cybersecurity for all. It’s part of our effort to put that guiding purpose at the center of our relationship with our customers, employees, and shareholders.

Later this week, we will be unveiling our first Social Good Report, which highlights our broader work advancing social good, for which the Foundation will be an important complementary vehicle. We are eager to get started and look forward to engaging with members of our community and organizations globally to help build a secure and prosperous digital future for everyone. Please reach out [email protected] to partner with us.

NEVER MISS A BLOG

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

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.

Prudent Cybersecurity Preparation for the Potential Russia-Ukraine Conflict

Post Syndicated from boB Rudis original https://blog.rapid7.com/2022/02/15/prudent-cybersecurity-preparation-for-the-potential-russia-ukraine-conflict/

Prudent Cybersecurity Preparation for the Potential Russia-Ukraine Conflict

Tensions between Russia and Ukraine remain elevated, with a high degree of uncertainty surrounding the likelihood of military conflict and its aftermath. As the US Cybersecurity and Infrastructure Agency (CISA) noted in a recent statement on these circumstances, while “​​there are not currently any specific credible threats to the US homeland,” there is the “potential for the Russian government to consider escalating its destabilizing actions in ways that may impact others outside of Ukraine.”

Heightened risk

There are reports that Russia is leveraging offensive cyber capabilities as the situation between Russia and Ukraine escalates. If the situation draws closer to conflict, these actions may also extend to potential retaliatory cyberattacks, or cyberattack campaigns, against critical physical and cyber infrastructure within countries that provide support to Ukraine. This may seem alarmist, but US and other Western entities have been under considerable attack from Russian-affiliated hacking groups for years. Government officials have long reported that such activities are supported or, at best, overlooked by the Russian government, and commentators and researchers have suggested this helps advance Russia’s political agenda. In June 2021, the sustained high level of these attacks against US critical infrastructure resulted in the US President Biden addressing the matter directly with Russia’s President Putin.

Moreover, events like NotPetya and Conficker have shown us that targeting in cyberspace is rarely precise, and collateral damage from cyberattacks can spread far beyond the original target.

Given the increased risk of damage from cyberattacks — whether a direct attack against Ukraine and its supporters or an indirect effect from an attack — it is prudent, as CISA notes, that “all organizations — regardless of size — adopt a heightened posture when it comes to cybersecurity and protecting their most critical assets” and business processes.

The following actions are highly recommended for all organizations. These practices should be taken even in the absence of a geopolitical conflict — threats to organizational cybersecurity were present before the recent Ukraine-Russian tensions and will be present afterwards.

Preparation for direct cyberattack

Fending off an attack from a well-resourced nation state is a nightmare scenario for most cybersecurity teams. However, there are some fundamental steps your organization can take to reduce both the likelihood of becoming a target, the severity of the damage, and the chances of success for an attacker.

CISA’s Shields Up advisory itemizes many steps that are sound practices to defend against any potential cyberattack, and we encourage all organizations to review each of them as part of their preparation plans.

Fundamentally, the guidance comes down to ensuring you have:

  • Safe and resilient configurations in your external internet and cloud asset and application deployments
  • Visibility into processes and network activity across all components of critical business functions
  • A well-tested incident response process in place to respond quickly and effectively to all cyber incursions

If your organization currently works with Ukrainian organizations, we echo CISA’s guidance to take extra care to monitor, inspect, and isolate traffic from those organizations and closely review access controls for that traffic.

US organizations should also keep CISA’s contact information (located at the end of their report) handy in both digital and physical form (in the event you cannot access digital assets) so you can engage them or the FBI in the event you are the victim of a direct cyberattack.

Preparation for cyber critical infrastructure attack

As noted, Russia is a very capable cyber adversary, but they cannot attack every asset/organization individually, all at once. There is a greater likelihood for larger-scale disruption or damage through the targeting of digital resources and Internet services that many people and organizations rely on.

Such attacks could take many forms, such as:

  • Denial of Service (DoS) attacks against central/large DNS and other “internet plumbing services” providers (remember the DynDNS DoS attack that brought down Twitter and many other sites back in 2016), which could result in loss of access to both your web- and app-based client-facing resources and your access to any Sofware-as-a-Service (SaaS) offerings, such as Salesforce, Concur, Zendesk, DocuSign, and other widely-used services.
  • DoS attacks against cloud business suite providers, such as Google Workspace or Microsoft 365, which could disrupt critical business communications for a period of time.
  • Extended DoS and targeted ”destructionware” attacks, which could prevent the operation of services and execution of key business processes. Like NotPetya and Olympic Destroyer, destructionware aims to — via encryption or deletion — destroy the capabilities of the machines it infects.
  • Large-scale DoS attacks against critical network routing segments, and mass BGP hijacking campaigns.

Now would be a good time to itemize all the third-party dependencies in your critical business processes and to draft a plan for ensuring continuity of these processes if each of those services became unavailable for some period of time. It would also be prudent to start identifying alternate providers for each service component and drafting rapid migration plans for each.

For the network-level attacks mentioned above, there isn’t much you can do when it comes to centralized network point DoS, but you can help increase your resilience to BGP hijacking by implementing safe BGP practices and encouraging your business partners and ISPs to do the same.

If tensions become seriously strained, there is a non-zero (but likely very low) chance of direct cyberattacks aimed at causing damage to US and allied physical infrastructure. The US alone has a large number of critical infrastructure facilities — many of which are privately owned — that are still in the process of strengthening their cybersecurity defenses and capabilities. This includes entities that all businesses rely on, such as electricity providers, emergency health services, transportation, and financial institutions.

Acknowledging the relatively low likelihood but high impact of a crippling cyberattack, now would be a good time to review and update (as necessary) your business continuity and disaster recovery (BC/DR) plans and playbooks, and perhaps run an exercise (or two!) that involves loss of one or more critical infrastructure components.

Don’t panic

While there is cause for concern and preparation, there is no cause for panic or overreaction. It is, however, very appropriate to take some time to review your security posture, understand this heightened threat level, and engage stakeholders in an assessment of if — and how — you should proceed to shore up any areas that have gaps.

NEVER MISS A BLOG

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

Additional reading:

Evolving How We Share Rapid7 Research Data

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/02/10/evolving-how-we-share-rapid7-research-data-2/

Evolving How We Share Rapid7 Research Data

In the spring of 2018, we launched the Open Data initiative to provide security teams and researchers with access to research data generated from Project Sonar and Project Heisenberg. Our goal for those projects is to understand how the attack surface is evolving, what exposures are most common or impactful, and how attackers are taking advantage of these opportunities. Ultimately, we want to be able to advocate for necessary remediation actions that will reduce opportunities for attackers and advance security. This is also why we publish extensive research reports highlighting key security learnings and mitigation recommendations.

Our goal for Open Data has been to enable others to participate in these efforts, increasing the positive impact across the community. Open Data was an evolution of our participation in the scans.io project, hosted by the University of Michigan. Our hope was that security professionals would apply the research data to their own environments to reduce their exposure and researchers would use the data to uncover insights to help educate the community on security best practices.

Changing times

Since we first launched Open Data, we’ve been mindful that sharing large amounts of raw data may not maximize value for recipients and lead to the best security outcomes. It is efficient for us, as it can be automated, but we have constantly sought more impactful and productive ways to share the data. Where possible, we’ve developed partnerships with key nonprofit organizations and government entities that share our goals and values around advancing security and reducing exposure. We’ve looked for ways to make the information more accessible for internal security teams.

Fast forward to 2021, and wow, what a few years we’ve had. We’ve faced a global pandemic, which has really brought home our increased reliance on connected technologies, and amplified the need for privacy protections and understanding of digital threats. During the past few years, we have also seen an evolving regulatory environment for data protection. Back in 2018, GDPR was just coming into effect, and everyone was trying to figure out its implications. In 2020, we saw California join the party with the introduction of CCPA. It seems likely we will see more privacy regulations follow.

The surprising thing is not this focus on privacy, which we wholeheartedly support, but rather the inclusion and control of IP addresses as personal data or information. We believe security research supports better security outcomes, which in turn enables better privacy. It’s fundamentally challenging to maintain privacy without understanding and addressing security challenges.

Yet IP addresses make up a significant portion of the data being shared in our security research data. While we believe there is absolutely a legitimate interest in processing this kind of data to advance cybersecurity, we also recognize the need to take appropriate balancing controls to protect privacy and ensure that the processing is “necessary and proportionate” — per the language of Recital 49.

Evolving data sharing

So what does this mean? To date, Open Data included two elements:

  • A free sign-up service that was subject to light vetting and terms of service, and provides access to current and historical research data
  • Free access (no account required) to a one-month window of recent data from Project Sonar shared on the Rapid7 website

Beginning today, the latter will no longer be available. For the former, we still want to be able to provide data to help security teams and researchers identify and mitigate exposures. Our goals and values on this have not changed in any way since the inception of Open Data. What has evolved — apart from the regulatory landscape — is our thinking on the best ways to do this.

For Rapid7 customers, we launched Project Doppler, a free tool that provides insight into an organization’s external exposures and attack surface. Digging their own specific information out of our mountain of internet-wide scan data is the use case most Rapid7 customers want, so Doppler makes that much, much easier.

We are working on how we might practically extend Project Doppler more broadly to be available for other internal infosec teams, while still protecting privacy in line with regulatory requirements.

For governments, ISACs, and other nonprofits working on security advocacy to reduce opportunities for attackers, please contact us; we believe we share a mission to advance security and want to continue to support you in this. We will continue to provide free access to the data with appropriate balancing controls (such as geo-filtering) and legal agreements (such as for data retention) in place.

For legitimate public research projects, we have a new submission process so you can request access to the Project Sonar data sets for a limited time and subject to conditions for sharing your findings to advance the public good. Please email [email protected] for more information or to make a submission.

While it was not the primary goal or intention behind the Open Data initiative, we recognize that there are also entities using the data for commercial projects. We are not intentionally trying to hinder this, but per privacy regulations, we need to ensure we have more vetting and controls in place. If you are interested in discussing options for incorporating Project Sonar data into a commercial offering, please contact [email protected].

If you have a use case for Project Sonar data that does not fit into one of the categories above, please contact us. We welcome any opportunity to better understand how our data may be useful, and we want to continue to advance security and support the security community as best we can.

More advocacy, better outcomes

While these changes are being triggered by the evolving regulatory landscape, we believe that ultimately they will lead to more productive data sharing and better security outcomes. We’re still not sold on the view that IP addresses should be viewed as personal dataI, but we recognize the value of a more thoughtful and tailored approach to data sharing that both supports data protection values and also promotes more security advocacy and remediation action.

NEVER MISS A BLOG

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

Ransomware: Is Critical Infrastructure in the Clear?

Post Syndicated from Jen Ellis original https://blog.rapid7.com/2021/09/24/ransomware-is-critical-infrastructure-in-the-clear/

Ransomware: Is Critical Infrastructure in the Clear?

Recently I’ve been getting asked whether I believe ransomware is on the decline, particularly for critical infrastructure. Part of the reason for this question seems to be a recent security briefing from White House deputy national security adviser Anne Neuberger, suggesting that language on the site of a new-but-already-high-profile ransomware gang, BlackMatter, could indicate that President Biden’s comments to President Putin regarding consequences for attacks against US critical infrastructure may have hit their mark. Yet just this week, this same gang demanded a ransom of $5.9 million for an attack on Iowa-based feed and grain cooperative, NEW Cooperative.

So the question remains: Is critical infrastructure in the clear, is it a specific target of ransomware attackers, or is it simply on the same footing as any other organization? As we’ll see — and as current developments confirm — it’s clear that critical infrastructure is indeed at risk from ransomware attacks.

Before I get into the nuances of this, I want to quickly note upfront that much of this is going to be opinion or theories based on discussion with — and anecdotal evidence from — various security experts, ransomware victims, and news stories. I’m not a ransomware attacker, nor am I directly in touch with any, so I can only speculate on their motivations, interests, and plans. Where possible, I provide reference to further reading to provide context, but in general, it’s important to note that broad under-reporting and inconsistent handling of ransomware incident data means that any predictions, projections, or summaries of ransom activity (on this blog or elsewhere) are likely somewhat incomplete.

The BlackMatter at hand

The BlackMatter website indicates that the group is somewhat selective in which organizations it will target for attacks. According to The Record, BlackMatter is particularly interested in organizations with a revenue of over $100 million a year, with networks of 500 to 1,500 hosts located in the US, the UK, Canada, or Australia. They state they are specifically not planning to attack organizations in the following sectors and would in fact decrypt data for free should they infect any organizations in them:

  • Hospitals
  • Critical infrastructure facilities (nuclear power plants, power plants, water treatment facilities)
  • Oil and gas industry (pipelines, oil refineries)
  • Defense industry
  • Nonprofit companies
  • Government sector

Interestingly, they do not include the food and agriculture sector in this list, though it is included in the US government’s list of 16 critical infrastructure sectors. When NEW Cooperative’s representatives pointed this out to BlackMatter, the ransomware group’s response was:

You do not fall under the rules, everyone will only incur losses, everything is tied to the commerce, the critical ones mean the vital needs of a person.

On the surface, it’s funny to think they are saying food isn’t a vital need for people. The JBS attack at the start of June highlighted the importance of the food supply chain. The cost of basic meat food staples is still higher in the US as a result of the attack, which can make a huge difference to those living on or under the poverty line. BlackMatter explains the distinction in terms of the impact — it views loss of money for the company itself as the only real impact of the NEW Cooperative attack.

This may be because NEW Cooperative is a fairly small, regional entity, nowhere near the scale of JBS, and therefore disruption for them is not going to create anywhere close to the same level of impact on the US food supply chain. This leads to the question of whether these types of organizations really count as critical infrastructure on an individual level. That’s a question for the US government to answer as they determine whether to respond to this attack and others like it. If you want to get into this more, Joseph Marks has a great write-up on the different aspects in his coverage for the The Washington Post’s Cybersecurity 202.

In the meantime, it is interesting to see BlackMatter communicate so proactively on the topic of critical infrastructure and what they consider to be in scope. This could, as Anne Neuberger suggested, reflect a heeding of the President’s warning. It could also be somewhat influenced by the lessons learned from DarkSide’s experiences following the Colonial Pipeline attack back in May. BlackMatter states, “The project has incorporated in itself the best features of DarkSide, REvil, and LockBit,” so it’s entirely possible their communications strategy is informed by the blowback DarkSide experienced in the wake of Colonial.

After coming under intense scrutiny and focus following the Colonial Pipeline attack, the DarkSide group published a statement describing themselves as “apolitical” and asserting, “Our goal is to make money and not creating problems for society.” When its infrastructure was then compromised and their bitcoin drained, the group decided it was time to shut up shop and lay low. This prompted a great deal of speculation from security commentators over whether they would reappear under a different name after sufficient time had passed. It didn’t take long after the appearance of BlackMatter for security researchers to start pointing to indicators that the new ransomware group may be the phoenix rising from DarkSide’s ashes.

Hackers with hearts of gold?

DarkSide and BlackMatter are not the only ransomware gangs to draw a line around healthcare and other targets that can impact public safety.

In March 2020, as the pandemic ramped up in ferocity, Bleeping Computer reached out to a number of high-profile ransomware groups and asked if they would lay off healthcare organizations in light of COVID-19. The group behind the CLOP ransomware stated that they have “never attacked hospitals, orphanages, nursing homes, charitable foundations, and we won’t.” They went on to state, “We are not enemies of humanity… our goal is money, not harm,” and they indicated that if a healthcare organization was encrypted by accident, they would provide the decryptor for free.

Four other ransomware groups responded to Bleeping Computer with similar assertions that hospitals are never targets or would not be during the duration of the pandemic. Some even sounded offended by the suggestion that hospitals could ever be considered fair game for attacks.

Critical infrastructure attacks abound

Yet, despite this, attacks against the healthcare sector were prolific throughout 2020. According to the 2021 Unit 42 Ransomware Threat Report, “the healthcare sector… was the most targeted vertical for ransomware in 2020. Ransomware operators were brazen in their attacks in an attempt to make as much money as possible, knowing that healthcare organizations – which needed to continue operating to treat COVID-19 patients and help save lives – couldn’t afford to have their systems locked out and would be more likely to pay a ransom.”

We see the same trend continuing in 2021. The fantastic Black Fog site tracks publicly disclosed ransomware attacks on The State of Ransomware in 2021. Their stats highlight that 2021 continues to be a busy year for ransomware attackers and their victims, with more attacks in every month of 2021 than during their 2020 counterpart. They break down the attacks they track by industry sector, and the top 9 are all covered within the US government’s description of its 16 sectors of critical infrastructure. Healthcare is the fourth most impacted sector according to their analysis, with government and education taking the first and second spots.

So does this mean that these sectors are in fact being highly targeted for attack? The answer is complicated, and there are a number of factors at play.

It’s worth calling out again that ransomware and other cybercrime remains terribly under-reported. It’s possible that one of the reasons we “see” most attacks in the sectors mentioned earlier is because they are very public-facing in nature. Thus, disruptive attacks against their systems may be more visible to the public — and hence more easily tracked and reported. Other sectors may be better able to avoid public disclosure, possibly in the hopes of avoiding a loss of customer confidence or regulatory or legal implications.

This does not mean that these sectors are not also appealing targets for some cybercriminals. Healthcare, government, and educational organizations are often highly vulnerable to attack due to a number of factors including a deficit of resources, reliance on legacy systems, complexity of technical ecosystems and user behavior models, and lack of tolerance for downtime due to the consequences to the public of a halt in operations. This latter point may also mean these sectors are more likely to pay a ransom demand: If an entity can’t tolerate downtime enough to patch their systems, an attacker may speculate that they will also likely want to resolve a ransomware incident as quickly as possible, resulting in a paid ransom.

So, the question comes down to whether attackers think this way and specifically target these sectors.

Targets locked and loaded?

One of the things that most caught my attention about the DarkMatter website information, the responses to Bleeping Computer, and Unit 42’s research was that they all seem to reflect the notion that ransom attacks are targeted. Indeed, in its response to Bleeping Computer, the Nefilim Ransomware group stated, “We work very diligently in choosing our targets.”

Yet the BlackMatter site and a couple of the other responses also alluded to organizations being infected by accident. In its response to Bleeping Computer, the Netwalker group stated:

Hospitals and medical facilities? do you think someone has a goal to attack hospitals? we don’t have that goal -it never was. it coincidence. no one will purposefully hack into the hospital. [sic]

But they then went on to add:

If someone is encrypted, then he must pay for the decryption.

The implication here is that while they may not go out of their way to target hospitals or any other organization, their attacks are opportunistic and whoever is hit is fair game and expected to pay.

So how do these things relate to each other? How can an attack be both targeted and run the risk of accidentally infecting unintended organizations?

First, consider the nature of profit-motivated attacks of this type. While there are profit-driven attacks that are extremely targeted —for example corporate espionage attacks — in the case of ransomware attacks, it is more likely that groups of organized cybercriminals are going to try to maximize their potential profits by orchestrating attacks at scale. By casting their nets wide, they are able to get more bang for their buck/ruble, making the most of their upfront investment to increase the odds of hitting organizations that are willing to pay. They may have an ideal target profile as indicated on BlackMatter’s site, but that doesn’t mean they won’t take a spray-and-pray approach to see what they can hit. Even with a focus on a specific demographic, they are still likely to take a fairly broad approach to maximize the potential for profit.

This is consistent with the most common attack methodologies for extortion-based attacks. According to Digital Defense, phishing, RDP, and vulnerable systems are the top three attack vectors for ransomware attacks. While any of these can be leveraged in highly targeted attacks, it’s more common for them to be used at scale. Phishing emails are sent out to vast lists of potential recipients, and malware to exploit RDP or other exposed systems is automated and set loose on the internet. With this in mind, it’s not surprising that organizations that weren’t being directly targeted will be impacted.

While it’s important to note that the opportunistic nature of these attack methodologies means any organization can fall victim to a ransomware attack, that does not mean that specific sectors or geographies are not more likely to be hit. The majority of profit-motivated attackers may not be targeting specific organizations (unless there is another motivation at play), but that doesn’t mean they can’t target groups or classes of organization, as we see with BlackMatter’s website. The sheer volume of attacks hitting the US indicates that whatever the chosen attack vector, it is often pointed towards specific geographical regions. Likewise, it’s possible or in some cases, likely, that attackers develop phishing target lists with data specific to certain sectors that they believe will be more easily compromised or likely to pay. As already noted, critical infrastructure is viewed by many as sitting firmly in this category.

Critical infrastructure not in the clear

So what does all this mean? The incomplete data we have clearly shows that ransomware attacks are not in decline and critical infrastructure is certainly not in the clear.

We need more consistent reporting of ransom incidents to get a clearer picture of what’s really happening, but we can confidently say healthcare providers, governments, and education are regularly being hit and need greater support to help them tackle the security issues I mentioned earlier.

The good news is that this is a problem that many are scrutinizing, and we’re starting to see more resources and assistance for critical infrastructure. If you work in one of the US critical infrastructure sectors, check out the free tools and services CISA provides to help you protect yourself. If you are working for a government entity (including public education and healthcare providers), you may also qualify for free services from the MS-ISAC.

In addition, the US Senate recently passed infrastructure legislation that would provide federal grants and funding to several critical infrastructure sectors — such as state and local governments, energy, and water — to help them strengthen their cybersecurity postures. We hope this may be extending and that, as Congress considers large spending bills, the healthcare sector should be provided access to federal funding and other resources dedicated to cybersecurity.

The US government has also announced a number of other measures both to address ransomware and to shore up cybersecurity in critical infrastructure. We hope that, over time, we will see these efforts bearing fruit in the form of less successful attacks against critical infrastructure.

The Ransomware Task Force also identified a number of recommendations for governments to better support critical infrastructure, from grant funding (pages 40 and 41) to mandated adoption of cyber hygiene measures (page 39) and provision of emergency response authorities in the event of a successful attack (page 42). The US government is already taking action on some of these priorities, such as requiring greater cyber hygiene for federal agencies and contractors, and including a response and recovery fund for victims of cyberattack in the pending infrastructure legislation.

Although all public data sources agree that far more ransomware attacks are being reported in the US than in any other country, this is not only a US issue. Many other countries are impacted, and we see critical infrastructure being hit around the world. Governments in other affected countries are likely taking or investigating similar measures, though to date, they have mostly been less vocal on it in public.

In an ideal world, governments will work together to amplify the impact of their actions and proactively deter and disrupt the global ransomware market. To that end, I look forward to seeing what will come from the Extraordinary Senior Officials Forum on ransomware that the G7 has committed to holding before the end of 2021.

NEVER MISS A BLOG

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

Rapid7 Statement on the New Standard Contractual Clauses for International Transfers of Personal Data

Post Syndicated from Chelsea Portney original https://blog.rapid7.com/2021/09/21/rapid7-statement-on-the-new-standard-contractual-clauses-for-international-transfers-of-personal-data/

Rapid7 Statement on the New Standard Contractual Clauses for International Transfers of Personal Data

Context: On June 4, 2021, the European Commission published new standard contractual clauses (“New SCCs”). Under the General Data Protection Regulation (“GDPR”), transfers of personal data to countries outside of the European Economic Area (EEA) must meet certain conditions. The New SCCs are an approved mechanism to enable companies transferring personal data outside of the EEA to meet those conditions, and they replace the previous set of standard contractual clauses (“Old SCCs”), which were deemed inadequate by the Court of Justice of the European Union (“CJEU”). The New SCCs made a number of improvements to the previous version, including but not limited to (i) a modular design which allows parties to choose the module applicable to the personal data being transferred, (ii) use by non-EEA data exporters, and (iii) strengthened data subjects rights and protections.

Rapid7 Action: In light of the European Commission’s adoption of the New SCCs, Rapid7 performed a thorough assessment of its personal data transfers which involved reviewing the technical, contractual, and organizational measures we have in place, evaluating local laws where the personal data will be transferred, and analyzing the necessity for the transfers in accordance with the type and scope of the personal data being transferred. Rapid7 will be updating our Data Processing Addendum on September 27, 2021, to incorporate the New SCCs, where required, for the transfer of personal data outside of the EEA. Rapid7’s adoption of the New SCCs helps ensure we are able to continue to serve all our clients in compliance with GDPR data transfer rules.

Ongoing Commitments: Rapid7 is committed to upholding high standards of privacy and security for our customers, and we are pleased to be able to offer the New SCCs which provide enhanced protections that better take account of the rapidly evolving data environment. We will continue to monitor ongoing changes in order to comply with applicable law and will regularly assess our technical, contractual, and organizational measures in an effort to improve our data protection safeguards. For information on how Rapid7 collects, uses, and discloses personal data, as well as the choices available regarding personal data collected by Rapid7, please see the Rapid7 Privacy Policy. Additionally, Rapid7 remains dedicated to maintaining and enhancing our robust security and privacy program which is outlined in detail on our Trust page.

For more information about our security and privacy program, please email [email protected].

NEVER MISS A BLOG

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

Reforming the UK’s Computer Misuse Act

Post Syndicated from Jen Ellis original https://blog.rapid7.com/2021/08/12/reforming-the-uks-computer-misuse-act/

Reforming the UK’s Computer Misuse Act

The UK Home Office recently ran a Call for Information to investigate the Computer Misuse Act 1990 (CMA). The CMA is the UK’s anti-hacking law, and as Rapid7 is active in the UK and highly engaged in public policy efforts to advance security, we provided feedback on the issues we see with the legislation.

We have some concerns with the CMA in its current form, as well as recommendations for how to address them. Additionally, because Rapid7 has addressed similar issues relating to U.S. laws — particularly as relates to the U.S. equivalent of the CMA, the Computer Fraud and Abuse Act (CFAA) — for each section below, we’ve included a short comparison with U.S. law for those who are interested.

Restrictions on security testing tools and proof-of-concept code

One of the most concerning issues with the CMA is that it imperils dual-use open-source security testing tools and the sharing of proof-of-concept code.

Section 3A(2) of the CMA states:

(2) A person is guilty of an offence if he supplies or offers to supply any article believing that it is likely to be used to commit, or to assist in the commission of, an offence under section 1, 3 or 3ZA.

Security professionals rely on open source and other widely available security testing tools that let them emulate the activity of attackers, and exploiting proof-of-concept code helps organizations test whether their assets are vulnerable. These highly valued parts of robust security testing enable organizations to build defenses and understand the impacts of attacks.

Making these products open source helps keep them up-to-date with the latest attacker methodologies and ensures a broad range of organizations (not just well-resourced organizations) have access to tools to defend themselves. However, because they’re open source and widely available, these defensive tools could still be used by malicious actors for nefarious purposes.

The same issue applies to proof-of-concept exploit code. While the intent of the development and sharing of the code is defensive, there’s always a risk that malicious actors could access exploit code. But this makes the wide availability of testing tools all the more important, so organizations can identify and mitigate their exposure.

Rapid7’s recommendation

Interestingly, this is not an unknown issue — the Crown Prosecution Service (CPS) acknowledges it on their website. We’ve drawn from their guidance, as well as their Fraud Act guidelines, in drafting our recommended response, proposing that the Home Office consider modifying section 3A(2) of the CMA to exempt “articles” that are:

  • Capable of being used for legitimate purposes; and
  • Intended by the creator or supplier of the article to be used for a legitimate purpose; and
  • Widely available; unless
  • The article is deliberately developed or supplied for the sole purpose of committing a CMA offense.

If you’re concerned about creating a loophole in the law that can be exploited by malicious actors, rest assured the CMA would still retain 3A(1) as a means to prosecute those who supply articles with intent to commit CMA offenses.

Comparison with the CFAA

This issue doesn’t arise in the CFAA; however, the U.S. is subject to various export control rules that also restrict the sharing of dual-use security testing tools and proof-of-concept code.

Chilling security research

This is a topic Rapid7 has commented on many times in reference to the CFAA and the Digital Millennium Copyright Act, which is the U.S. equivalent of the UK’s Copyright, Designs and Patents Act 1988.

Independent security research aims to reveal vulnerabilities in technical systems so organizations can deploy better defenses and mitigations. This offers a significant benefit to society, but the CMA makes no provision for legitimate, good-faith testing. While Section 1(1) acknowledges that you must have intent to access the computer without authorization, it doesn’t mention that the motive to do so must be malicious, only that the actor intended to gain access without authorization. The CMA states:

(1) A person is guilty of an offence if—

a) he causes a computer to perform any function with intent to secure access to any program or data held in any computer, or to enable any such access to be secured;

b) the access he intends to secure, or to enable to be secured, is unauthorised; and

c) he knows at the time when he causes the computer to perform the function that that is the case.

Many types of independent security research, including port scanning and vulnerability investigations, could meet that description. As frequently noted in the context of the CFAA, it’s often not clear what qualifies as authorization to access assets connected to the internet, and independent security researchers often aren’t given explicit authorization to access a system.

It’s worth noting that neither the National Crime Agency (NCA) or the CPS seem to be recklessly pursuing frivolous investigations or prosecutions of good-faith security research. Nonetheless, the current legal language does expose researchers to legal risk and uncertainty, and it would be good to see some clarity on the topic.

Rapid7’s recommendation

Creating effective legal protections for good-faith, legitimate security research is challenging. We must avoid inadvertently creating a backdoor in the law that provides a defense for malicious actors or permits activities that can create unintended harm. As legislators consider options on this, we strongly recommend considering the following questions:

  • How do you determine whether research is legitimate and justified? Some considerations include whether sensitive information was accessed, and if so, how much – is there a threshold for what might be acceptable? Was any damage or disruption caused by the action? Did the researcher demand financial compensation from the technology manufacturer or operator?

For example, in our work on the CFAA, Rapid7 has proposed the following legal language to indicate what is understood by “good-faith security research.”

The term “good faith security research” means good faith testing or investigation to detect one or more security flaws or vulnerabilities in software, hardware, or firmware of a protected computer for the purpose of promoting the security or safety of the software, hardware, or firmware.

(A) The person carrying out such activity shall

(i) carry out such activity in a manner reasonably designed to minimize and avoid unnecessary damage or loss to property or persons;

(ii)  take reasonable steps, with regard to any information obtained without authorization, to minimize the information the person obtains, retains, and discloses to only that information which the person reasonably believes is directly necessary to test, investigate, or mitigate a security flaw or vulnerability;

(iii) take reasonable steps to disclose any security vulnerability derived from such activity to the owner of the protected computer or the Cybersecurity and Infrastructure Security Agency prior to disclosure to any other party

(iv) wait a reasonable amount of time before publicly disclosing any security flaw or vulnerability derived from such activity, taking into consideration the following:

(I) the severity of the vulnerability,

(II) the difficulty of mitigating the vulnerability,

(III) industry best practices, and

(IV) the willingness and ability of the owner of the protected computer to mitigate the vulnerability;

(v) not publicly disclose information obtained without authorization that is

(I) a trade secret without the permission of the owner of the trade secret; or

(II) the personally identifiable information of another individual, without the permission of that individual; and

(vi) does not use a nonpublic security flaw or vulnerability derived from such activity for any primarily commercial purpose prior to disclosing the flaw or vulnerability to the owner of the protected computer or the [government vulnerability coordination body].

(B) For purposes of subsection (A), it is not a public disclosure to disclose a vulnerability or other information derived from good faith security research to the [government vulnerability coordination body].

  • What happens if a researcher does not find anything to report? Some proposals for reforming the CMA  have suggested requiring coordinated disclosure as a predicate for a research carve out. This only works if the researcher actually finds something worth reporting. What happens if they do not? Is the research then not defensible?
  • Are we balancing the rights and safety of others with the need for security? For example, easing restrictions for threat intel investigators and security researchers may create a misalignment with existing privacy legislation. This may require balancing controls to protect the rights and safety of others.

The line between legitimate research and hack back

In discussions on CMA reform, we often hear the chilling effect on security research being lumped in with arguments for expanding authorities for threat intelligence gathering and operations. The latter sound alarmingly like requests for private-sector hack back (despite assertions otherwise). We believe it is critical that policymakers understand the distinction between acknowledging the importance of good-faith security research on the one hand and authorizing private-sector hack back on the other.

We understand private-sector hack back to mean an organization taking intrusive action against a cyber-attacker on technical assets or systems not owned or leased by the entity taking action or their client. While threat intel campaigners may disclaim hack back, in asking for authorization to take intrusive action on third-party systems — whether to better understand attacks, disrupt them, or even recapture lost data — they’re certainly satisfying the description of hack back and raising a number of concerns.

Rapid7 is strongly opposed to private-sector hack back. While we view both independent, good-faith security research and threat intelligence investigations as critical for security, we believe the two categories of activity need separate and distinct legal restrictions.

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 that we reduce opportunities for attackers and decrease the risk for technology users. These activities often need to be undertaken without authorization to avoid blowback from manufacturers or operators that prioritize their reputation or profit above the security of their customers.

This activity is about protecting the safety and privacy of the many, and while researchers may take actions without authorization, they only do so 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.

In contrast, threat intel activities that involve interrogating or interacting with third-party assets prioritize the interests of a specific entity over those of other potential victims, whose compromised assets may have been leveraged in the attack. While threat intelligence can be very valuable in helping us understand how attackers behave — which can help others identify or prepare for attacks — data gathering and operations should be limited to assessing threats to assets that are owned or operated by the authorizing entity, or to non-invasive activities such as port scanning. More invasive activities can result in unintended consequences, including escalation of aggression, disruption or destruction for innocent third parties, and a quagmire of legal liability.

Because cyber attacks are criminal activity, if more investigation is needed, it should be undertaken with appropriate law enforcement involvement and oversight. We see no practical way to provide appropriate oversight or standards for the private sector to engage in this kind of activity.

Comparison to the CFAA

This issue also arises in the CFAA. In fact, it’s exacerbated by the CFAA enabling private entities to pursue civil causes of action, which mean technology manufacturers and operators can seek to apply the CFAA in private cases against researchers. This is often done to protect corporate reputations, likely at the expense of technology users who are being exposed to risk. These private civil actions chill security research and account for the vast majority of CFAA cases and lawsuit threats focused on research. One of Rapid7’s recommendations to the UK Home Office was that the CMA should not be updated to include civil liability.

Washington State has helped protect good-faith security research in its Cybercrime Act (Chapter 9A.90 RCW), which both addresses the issue of defining authorization and exempts white-hat security research.

It’s also worth noting that the U.S. has an exemption for security research in Section 1201 of the Digital Millennium Copyright Act (DMCA). It would be good to see the UK government consider something similar for the Copyright, Designs and Patents Act 1988.

Clarifying authorization

At its core, the CMA effectively operates as a law prohibiting digital trespass and hinges on the concept of authorization. Four of the five classes of offenses laid out in the CMA involve “unauthorized” activities:

1. Unauthorised access to computer material.

2. Unauthorised access with intent to commit or facilitate commission of further offences.

3. Unauthorised acts with intent to impair, or with recklessness as to impairing, operation of computer, etc.

3ZA.Unauthorised acts causing, or creating risk of, serious damage

Unfortunately, the CMA does not define authorization (or the lack thereof), nor detail what authorization should look like. As a result, it can be hard to know with certainty where the legal line is truly being drawn in the context of the internet, where many users don’t read or understand lengthy terms of service, and data and services are often publicly accessible for a wide variety of novel uses.

Many people take the view that if something is accessible in public spaces on the internet, authorization to access it is inherently granted. In this view, the responsibility lies with the owner or operator to ensure that if they don’t want to grant access to something, they don’t make it publicly available.

That being the case, the question becomes how systems owners and operators can indicate a lack of authorization for accessing systems or information in a way that scales, while still enabling broad access and innovative use of online services. In the physical world, we have an expectation that both public and private spaces exist. If a space is private and the owners don’t want others to access it, they can indicate this through signage or physical barriers (walls, fences, or gates). Currently, there is no accepted, standard way for owners and operators to set out a “No Trespassing” sign for publicly accessible data or systems on the internet that truly serves the intended purpose.

Rapid7’s recommendation

While a website’s Terms of Service (TOS) can be legally enforceable in some contexts, in our opinion the Home Office should not take the position that violations of TOS alone qualify as “unauthorized acts.” TOS are almost always ignored by the vast majority of internet users, and ordinary internet behavior may routinely violate TOS (such as using a pseudonym where a real name is required).

Reading TOS also does not scale for internet-wide scanning, as in the case of automated port scanning and other services that analyze the status of millions of publicly accessible websites and online assets. In addition, if TOS is “authorization” for the purposes of the CMA, it gives the author of the TOS the power to define what is and isn’t a hacking crime under CMA section 1.

To address this lack of clarity, the CMA needs a clearer explanation of what constitutes authorization for accessing technical systems or information through the internet and other forms of connected communications.

Comparison with the CFAA

This issue absolutely exists with the CFAA and is at the core of many of the criticisms of the law. Multiple U.S. cases have rejected the notion that TOS violations alone qualify as “exceeding authorization” under the CFAA, creating a split in the courts. The U.S. Supreme Court’s recent decision on Van Buren v. United States confirmed TOS is an insufficient standard, noting that if TOS violations alone qualify as unauthorized act for computer crime purposes, “then millions of otherwise law-abiding citizens are criminals.”

Next steps

We hope the Home Office will take these concerns into consideration, both in terms of ensuring the necessary support for security testing tools and security research, and also in being cautious not to go so far with authorities that we open the door to abuses. We’ll continue to engage on these topics wherever possible to help policymakers navigate the nuances and keep advancing security.

You can read Rapid7’s full response to the Home Office’s CFI or our detailed CMA position.

NEVER MISS A BLOG

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

Rapid7 Acquires Leading Kubernetes Security Provider, Alcide

Post Syndicated from Brian Johnson original https://blog.rapid7.com/2021/02/01/rapid7-acquires-leading-kubernetes-security-provider-alcide/

Rapid7 Acquires Leading Kubernetes Security Provider, Alcide

Organizations around the globe continue to embrace the flexibility, speed, and agility of the cloud. Those that have adopted it are able to accelerate innovation and deliver real value to their customers faster than ever before. However, while the cloud can bring a tremendous amount of benefits to a company, it is not without its risks. Organizations need comprehensive visibility into their cloud and container environments to help mitigate risk, potential threats, and misconfigurations.

At Rapid7, we strive to help our customers establish and implement strategies that enable them to rapidly adopt and secure cloud environments. Looking only at cloud infrastructure or containers in a silo provides limited ability to understand the impact of a possible vulnerability or breach.

To help our customers gain a more comprehensive view of their cloud environments, I am happy to announce that we have acquired Alcide, a leader in Kubernetes security based in Tel Aviv, Israel. Alcide provides seamless Kubernetes security fully integrated into the DevOps lifecycle and processes so that business applications can be rapidly deployed while also protecting cloud environments from malicious attacks.

Alcide’s industry-leading cloud workload protection platform (CWPP) provides broad, real-time visibility and governance, container runtime and network monitoring, as well as the ability to detect, audit, and investigate known and unknown security threats. By bringing together Alcide’s CWPP capabilities with our existing posture management (CSPM) and infrastructure entitlements (CIEM) capabilities, we will be able to provide our customers with a cloud-native security platform that enables them to manage risk and compliance across their entire cloud environment.

This is an exciting time in cloud security, as we’re witnessing a shift in perception. Cloud security teams are no longer viewed as a cost center or operational roadblock and have earned their seat at the table as a critical investment essential to driving business forward. With Alcide, we’re excited to further increase that competitive advantage for our customers.

We look forward to joining forces with Alcide’s talented team as we work together to provide our customers comprehensive, unified visibility across their entire cloud infrastructure and cloud-native applications.

Welcome to the herd, Alcide!