Tag: CISA

How a Zero-Day Flaw in MOVEit Led to a Global Ransomware Attack

In an era where our lives are ever more intertwined with technology, the security of digital platforms is a matter of national concern. A recent large-scale cyberattack affecting several U.S. federal agencies and numerous other commercial organizations emphasizes the criticality of robust cybersecurity measures.

The Intrusion

On June 7, 2023, the Cybersecurity and Infrastructure Security Agency (CISA) identified an exploit by “Threat Actor 505” (TA505), namely, a previously unidentified (zero-day) vulnerability in a data transfer software called MOVEit. MOVEit is a file transfer software used by a broad range of companies to securely transfer files between organizations. Darin Bielby, the managing director at Cypfer, explained that the number of affected companies could be in the thousands: “The Cl0p ransomware group has become adept at compromising file transfer tools. The latest being MOVEit on the heels of past incidents at GoAnywhere. Upwards of 3000 companies could be affected. Cypfer has already been engaged by many companies to assist with threat actor negotiations and recovery.”

CISA, along with the FBI, advised that “[d]ue to the speed and ease TA505 has exploited this vulnerability, and based on their past campaigns, FBI and CISA expect to see widespread exploitation of unpatched software services in both private and public networks.”

Although CISA did not comment on the perpetrator behind the attack, there are suspicions about a Russian-speaking ransomware group known as Cl0p. Much like in the SolarWinds case, they ingeniously exploited vulnerabilities in widely utilized software, managing to infiltrate an array of networks.

Wider Implications

The Department of Energy was among the many federal agencies compromised, with records from two of its entities being affected. A spokesperson for the department confirmed they “took immediate steps” to alleviate the impact and notified Congress, law enforcement, CISA, and the affected entities.

This attack has ramifications beyond federal agencies. Johns Hopkins University’s health system reported a possible breach of sensitive personal and financial information, including health billing records. Georgia’s statewide university system is investigating the scope and severity of the hack affecting them.

Internationally, the likes of BBC, British Airways, and Shell have also been victims of this hacking campaign. This highlights the global nature of cyber threats and the necessity of international collaboration in cybersecurity.

The group claimed credit for some of the hacks in a hacking campaign that began two weeks ago. Interestingly, Cl0p took an unusual step, stating that they erased the data from government entities and have “no interest in exposing such information.” Instead, their primary focus remains extorting victims for financial gains.

Still, although every file transfer service based on MOVEit could have been affected, that does not mean that every file transfer service based on MOVEit was affected. Threat actors exploiting the vulnerability would likely have had to independently target each file transfer service that employs the MOVEit platform. Thus, companies should determine whether their secure file transfer services rely on the MOVEit platform and whether any indicators exist that a threat actor exploited the vulnerability.

A Flaw Too Many

The attackers exploited a zero-day vulnerability that likely exposed the data that companies uploaded to MOVEit servers for seemingly secure transfers. This highlights how a single software vulnerability can have far-reaching consequences if manipulated by adept criminals. Progress, the U.S. firm that owns MOVEit, has urged users to update their software and issued security advice.

Notification Requirements

This exploitation likely creates notification requirements for the myriad affected companies under the various state data breach notification laws and some industry-specific regulations. Companies that own consumer data and share that data with service providers are not absolved of notification requirements merely because the breach occurred in the service provider’s environment. Organizations should engage counsel to determine whether their notification requirements are triggered.

A Call to Action

This cyberattack serves as a reminder of the sophistication and evolution of cyber threats. Organizations using the MOVEit software should analyze whether this vulnerability has affected any of their or their vendors’ operations.

With the increasing dependency on digital platforms, cybersecurity is no longer an option but a necessity in a world where the next cyberattack is not a matter of “if” but “when;” it’s time for a proactive approach to securing our digital realms. Organizations across sectors must prioritize cybersecurity. This involves staying updated with the latest security patches and ensuring adequate protective measures and response plans are in place.

© 2023 Bradley Arant Boult Cummings LLP

For cybersecurity legal news, click here to visit the National Law Review.

Secure Software Regulations and Self-Attestation Required for Federal Contractors

US Policy and Regulatory Alert

Government contractors providing software across the federal government’s supply chain will be required later this year to comply with a new Secure Software Design Framework (SSDF). The SSDF requires software vendors to attest to new security controls in the design of code used by the federal government.

Cybersecurity Compromises of Government Software on the Rise

In the aftermath of the cybersecurity compromises of significant enterprise software systems embedded in government supply chains, the federal government has increasingly prioritized reducing the vulnerability of software used within agency networks. Recognizing that most of the enterprise software that is used by the federal government is provided by a wide range of private sector contractors, the White House has been moving to impose a range of new software security regulations on both prime and subcontractors. One priority area is an effort to require government contractors to ensure that software used by federal agencies incorporates security by design. As a result, federal contractors supplying software to the government now face a new set of requirements to supply secure software code. That is, to provide software that is developed with security in mind so that flaws and vulnerabilities can be mitigated before the government buys and deploys the software.

The SSDF as A Government Response

In response, the White House issued Executive Order 14028, “Executive Order on Improving the Nation’s Cybersecurity” (EO 14028), on 12 May 2021. EO 14028 requires the National Institute of Standards and Technology (NIST) to develop standards, tools, and best practices to enhance the security of the software supply chain. NIST subsequently promulgated the SSDF in special publication NIST SP 800-218. EO 14028 also mandates that the director of the Office of Management and Budget (OMB) take appropriate steps to ensure that federal agencies comply with NIST guidance and standards regarding the SSDF. This resulted in OMB Memorandum M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices” (M-22-18). The OMB memo provides that a federal agency may use software subject to M-22-18’s requirements only if the producer of that software has first attested to compliance with federal government-specified secure software development practices drawn from the SSDF. Meaning, if the producer of the software cannot attest to meeting the NIST requirements, it will not be able to supply software to the federal government. There are some exceptions and processes for software to gradually enter into compliance under various milestones for improvements, all of which are highly technical and subjective.

In accordance with these regulations, the Cybersecurity and Infrastructure Security Agency (CISA) of the Department of Homeland Security issued a draft form for collecting the relevant attestations and associated information. CISA released the draft form on 27 April 2023 and is accepting comments until 26 June 2023.1

SSDF Implementation Deadline and Requirements for Government Suppliers

CISA initially set a deadline of 11 June 2023 for critical software and 13 September 2023 for non-critical software to comply with SSDF. Press reports indicate that these deadlines will be extended due to both the complexity of the SSDF requirements and the fact that the comment period remains open until 26 June  2023. However, CISA has not yet confirmed an extension of the deadline.

Attestation and Compliance with the SSDF

Based on what we know now, the attestation form generally requires software producers to confirm that:

  • The software was developed and built in secure environments.
  • The software producer has made a good-faith effort to maintain trusted source code supply chains.
  • The software producer maintains provenance data for internal and third-party code incorporated into the software.
  • The software producer employed automated tools or comparable processes that check for security vulnerabilities.

Software producers that must comply with SSDF should move quickly and begin reviewing their approach to software security. The SSDF requirements are complex and likely will take time to review, implement, and document. In particular, many of the requirements call for subjective analysis rather than objective evaluation against a set of quantifiable criteria, as is usually the case with such regulations. The SSDF also includes numerous ambiguities. For example, the SSDF requires versioning changes in software to have certain impacts in the security assessment, although the term “versioning” does not have a standard definition in the software sector.

Next Steps and Ricks of Noncompliance

Critically, the attestations on the new form carry risk under the civil False Claims Act for government contractors and subcontractors. Given the fact that many of the attestations require subjective analysis, contractors must take exceptional care in completing the attestation form. Contractors should carefully document their assessment that the software they produce is compliant. In particular, contractors and other interested parties should use this opportunity to share feedback and insights with CISA through the public comment process.

K&L Gates lawyers in our National Security Practice are closely tracking the implementation of these new requirements.

1 88 Fed. Reg. 25,670.

Copyright 2023 K & L Gates

Cyber Incident Reporting for Critical Infrastructure Act

On September 12, 2022, the Cybersecurity and Infrastructure Security Agency (“CISA”) released a Request for Information (“RFI”) seeking public input regarding the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (“CIRCIA”). The public comment period will close on November 14th, 2022. The RFI provides a “non-exhaustive” list of topics on which CISA seeks public input, including:

  • Definitions and criteria of various terms, such as “covered entity,” “covered cyber incident,” “substantial cyber incident,” “ransom payment,” “ransom attack,” “supply chain compromise” and “reasonable belief;”
  • Content of reports on covered cyber incidents and the submission process (e.g., how entities should submit reports, report timing requirements, and which federal entities should receive reports;
  • Any conflict with existing or proposed federal or state cyber incident reporting requirements;
  • The expected time and costs associated with reporting requirements; and
  • Common best practices governing the sharing of information related to security vulnerabilities in the U.S. and internationally.

In March 2022, President Biden signed CIRCIA into law. CIRCIA creates legal protections and provides guidance to companies that operate in critical infrastructure sectors, including a requirement to report cyber incidents within 72 hours, and report ransom payments within 24 hours. The CISA website features more information about the law, the RFI, and a list of public listening sessions with CISA to provide input.

Article By Privacy and Cybersecurity Practice Group at Hunton Andrews Kurth

For more privacy and cybersecurity legal news, click here to visit the National Law Review.

Copyright © 2022, Hunton Andrews Kurth LLP. All Rights Reserved.

Small Businesses Don’t Recognize Risk of Cyberattack Despite Repeated Warnings

CNBC surveys over 2,000 small businesses each quarter to get their thoughts on the overall business environment and their small business’ health. According to the latest CNBC/SurveyMonkey Small Business Survey, despite repeated warnings by the Cybersecurity and Infrastructure Security Agency and the FBI that U.S.- based businesses are at an increased risk of a cyber-attack following Russia’s invasion of Ukraine, small business owners do not believe that it is an actual risk that will affect them, and they are not prepared for an attack. The latest survey shows that only five percent of small business owners reported cybersecurity to be the biggest risk to their company.

What is unfortunate, but not surprising, is the fact that this is the same percentage of small business owners who recognized a cyber attack as the biggest risk a year ago. There has been no change in the perception among business owners, even though there are repeated, dire warnings from the government. Also unfortunate is the statistic that only 33 percent of business owners with one to four employees are concerned about a cyber attack this year. In contrast, 61 percent of business owners with more than 50 employees have the same concern.

According to CNBC, “this general lack of concern among small business owners diverges from the sentiment among the general public….In SurveyMonkey’s polling, 55% of people in the U.S. say they would be less likely to continue to do business with brands who are victims of a cyber attack.” CNBC’s conclusion is that there is a disconnect between business owners’ appreciation of how much customers care about data security and that “[s]mall businesses that fail to take the cyber threat seriously risk losing customers, or much more, if a real threat emerges.” Statistics show that threat actors are targeting small to medium-sized businesses to stay under the law enforcement radar. With such a large target on their backs, business owners may wish to make cybersecurity a priority. It’s important to keep customers.

Article By Linn F. Freedman of Robinson & Cole LLP

For more cybersecurity legal news, click here to visit the National Law Review.

Copyright © 2022 Robinson & Cole LLP. All rights reserved.

Patch Up – Log4j and How to Avoid a Cybercrime Christmas

A vulnerability so dangerous that Cybersecurity and Infrastructure (CISA) Director Jen Easterly called it “one of the most serious [she’s] seen in [her] entire career, if not the most serious” arrived just in time for the holidays. On December 10, 2021, CISA and the director of cybersecurity at the National Security Agency (NSA) began alerting the public of a critical vulnerability within the Apache Log4j Java logging framework. Civilian government agencies have been instructed to mitigate against the vulnerability by Christmas Eve, and companies should follow suit.

The Log4j vulnerability allows threat actors to remotely execute code both on-premises and within cloud-based application servers, thereby obtaining control of the impacted servers. CISA expects the vulnerability to affect hundreds of millions of devices. This is a widespread critical vulnerability and companies should quickly assess whether, and to what extent, they or their service providers are using Log4j.

Immediate Recommendations

  • Immediately upgrade all versions of Apache Log4j to 2.15.0.
  • Ask your service providers whether their products or environment use Log4j, and if so, whether they have patched to the latest version. Helpfully, CISA sponsors a community-sourced GitHub repository with a list of software related to the vulnerability as a reference guide.
  • Confirm your security operations are monitoring internet-facing systems for indicators of compromise.
  • Review your incident response plan and ensure all response team information is up to date.
  • If your company is involved in an acquisition, discuss the security steps taken within the target company to address the Log4j vulnerability.

The versatility of this vulnerability has already attracted the attention of malicious nation-state actors. For example, government-affiliated cybercriminals in Iran and China have a “wish list” (no holiday pun intended) of entities that they are aggressively targeting with the Log4j vulnerability. Due to this malicious nation-state activity, if your company experiences a ransomware attack related to the Log4j vulnerability, it is particularly important to pay attention to potential sanctions-related issues.

Companies with additional questions about the Log4j vulnerability and its potential impact on technical threats and potential regulatory scrutiny or commercial liability are encouraged to contact counsel.

Article By Philip J. Bezanson, Brittney E. Justice, Claire E. Cahoon, and Seth D. DuCharme of Bracewell LLP

For more cybersecurity legal news, click here to visit the National Law Review.

© 2021 Bracewell LLP