Tag: NIST

How to Develop an Effective Cybersecurity Incident Response Plan for Businesses

Data breaches have become more frequent and costly than ever. In 2021, the average data breach cost companies more than $4 million. Threat actors are increasingly likely to be sophisticated. The emergence of ransomware-as-a-service (RaaS) has allowed even unsophisticated, inexperienced parties to execute harmful, disruptive, costly attacks. In this atmosphere, what can businesses do to best prepare for a cybersecurity incident?

One fundamental aspect of preparation is to develop a cyber incident response plan (IRP). The National Institute of Standards and Technology (NIST) identified five basic cybersecurity functions to manage cybersecurity risk:

  • Identify
  • Protect
  • Detect
  • Respond
  • Recover

In the NIST framework, anticipatory response planning is considered part of the “respond” function, indicating how integral proper planning is to an effective response. Indeed, NIST notes that “investments in planning and exercises support timely response and recovery actions, resulting in reduced impact to the delivery of services.”

But what makes an effective IRP? And what else goes into quality response planning?

A proper IRP requires several considerations. The primary elements include:

  • Assigning accountability: identify an incident response team
  • Securing assistance: identify key external vendors including forensic, legal and insurance
  • Introducing predictability: standardize crucial response, remediation and recovery steps
  • Creating readiness: identify legal obligations and information to facilitate the company’s fulfillment of those obligations
  • Mandating experience: develop periodic training, testing and review requirements

After developing an IRP, a business must ensure it remains current and effective through regular reviews at least annually or anytime the business undergoes a material change that could alter either the IRP’s operation or the cohesion of the incident response team leading those operations.

An effective IRP is one of several integrated tools that can strengthen your business’s data security prior to an attack, facilitate an effective response to any attack, speed your company’s recovery from an attack and help shield it from legal exposure in the event of follow-on litigation.

© 2024 Varnum LLP
For more on Cybersecurity, visit the NLR Communications Media Internet section.

NIST Releases Risk ‘Profile’ for Generative AI

A year ago, we highlighted the National Institute of Standards and Technology’s (“NIST”) release of a framework designed to address AI risks (the “AI RMF”). We noted how it is abstract, like its central subject, and is expected to evolve and change substantially over time, and how NIST frameworks have a relatively short but significant history that shapes industry standards.

As support for the AI RMF, last month NIST released in draft form the Generative Artificial Intelligence Profile (the “Profile”).The Profile identifies twelve risks posed by Generative AI (“GAI”) including several that are novel or expected to be exacerbated by GAI. Some of the risks are exotic and new, such as confabulation, toxicity, and homogenization.

The Profile also identifies risks that are familiar, such as those for data privacy and cybersecurity. For the latter, the Profile details two types of cybersecurity risks: (1) those with the potential to discover or enable the lowering of barriers for offensive capabilities, and (2) those that can expand the overall attack surface by exploiting vulnerabilities as novel attacks.

For offensive capabilities and novel attack risks, the Profile includes these examples:

  • Large language models (a subset of GAI) that discover vulnerabilities in data and write code to exploit them.
  • GAI-powered co-pilots that proactively inform threat actors on how to evade detection.
  • Prompt-injections that steal data and run code remotely on a machine.
  • Compromised datasets that have been ‘poisoned’ to undermine the integrity of outputs.

In the past, the Federal Trade Commission (“FTC”) has referred to NIST when investigating companies’ data breaches. In settlement agreements, the FTC has required organizations to implement security measures through the NIST Cybersecurity Framework. It is reasonable to assume then, that NIST guidance on GAI will also be recommended or eventually required.

But it’s not all bad news – despite the risks when in the wrong hands, GAI will also improve cybersecurity defenses. As recently noted by Microsoft’s recent report on the GDPR & GAI, GAI can already: (1) support cybersecurity teams and protect organizations from threats, (2) train models to review applications and code for weaknesses, and (3) review and deploy new code more quickly by automating vulnerability detection.

Before ‘using AI to fight AI’ becomes legally required, just as multi-factor authentication, encryption, and training have become legally required for cybersecurity, the Profile should be considered to mitigate GAI risks. From pages 11-52, the Profile examines four hundred ways to use the Profile for GAI risks. Grouping them together, some of the recommendations include:

  • Refine existing incident response plans and risk assessments if acquiring, embedding, incorporating, or using open-source or proprietary GAI systems.
  • Implement regular adversary testing of the GAI, along with regular tabletop exercises with stakeholders and the incident response team to better inform improvements.
  • Carefully review and revise contracts and service level agreements to identify who is liable for a breach and responsible for handling an incident in case one is identified.
  • Document everything throughout the GAI lifecycle, including changes to any third parties’ GAI systems, and where audited data is stored.

“Cybersecurity is the mother of all problems. If you don’t solve it, all the other technology stuff just doesn’t happen” said Charlie Bell, Microsoft’s Chief of Security, in 2022. To that end, the AM RMF and now the Profile provide useful and early guidance on how to manage GAI Risks. The Profile is open for public comment until June 2, 2024.

© Polsinelli PC, Polsinelli LLP in California
For more on Generative AI, visit the NLR Communications, Media & Internet section.

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

NIST Releases New Framework for Managing AI and Promoting Trustworthy and Responsible Use and Development

On January 26, 2023, the National Institute of Standards and Technology (“NIST”) released the Artificial Intelligence Risk Management Framework (“AI RMF 1.0”), which provides a set of guidelines for organizations that design, develop, deploy or use AI to manage its many risks and promote trustworthy and responsible use and development of AI systems.

The AI RMF 1.0 provides guidance as to how organizations may evaluate AI risks (e.g., intellectual property, bias, privacy and cybersecurity) and trustworthiness. The AI RMF 1.0 outlines the characteristics of trustworthy AI systems, which are valid, reliable, safe, secure, resilient, accountable, transparent, explainable, interpretable, privacy enhanced and fair with their harmful biases managed. It also describes four high-level functions, with associated actions and outcomes to help organizations better understand and manage AI:

  • The Govern function addresses evaluation of AI technologies’ policies, processes and procedures, including their compliance with legal and regulatory requirements and transparent and trustworthy implementation.
  • The Map function provides context for organizations to frame risks relating to AI systems, including AI system impacts and interdependencies.
  • The Measure function uses quantitative, qualitative or mixed-method tools, techniques and methodologies to analyze, benchmark and monitor AI risk and related impacts, including tracking metrics to determine trustworthy characteristics, social impact and human-AI configurations.
  • The Manage function entails allocating risk resources to mapped and measured risks consistent with the Govern function. The Manage function includes determining how to treat risks and develop plans to respond to, recover from and communicate about incidents and events.

NIST released a draft AI Risk Management Framework Playbook to accompany the AI RMF 1.0. NIST plans to release an updated version of the Playbook in the Spring of 2023 and launch a new Trustworthy and Responsible AI Resource Center to help organizations put AI RMF 1.0 into practice. NIST has also provided a Roadmap of its priorities to advance the AI RMF.

Copyright © 2023, Hunton Andrews Kurth LLP. All Rights Reserved.
For more Technology Legal News, click here to visit the National Law Review.

2020 In Review: An AI Roundup

There has been much scrutiny of artificial intelligence tools this year. From NIST to the FTC to the EU Parliament, many have recommendations and requirements for companies that want to use AI tools. Key concerns including being transparent about the use of the tools, ensuring accuracy, and not discriminating against individuals when using AI technologies, and not using the technologies in situations where it may not give reliable results (i.e., for things for which it was not designed). Additional requirements for use of these tools exist under GDPR as well.

Legal counsel may feel uncomfortable with business teams who are moving forward in deploying AI tools. It’s not likely, however, that lawyers will be able to slow down the inevitable and widespread use of AI. We anticipate more developments in this area into 2021.

Putting It Into Practice: Companies can use “privacy by design” principles to help them get a handle on business team’s AI efforts. Taking time to fully understand the ways in which the AI tool will be used (both immediately in any future phases of a project) can be critical to ensuring that regulator concerns and legal requirements are addressed.

Copyright © 2020, Sheppard Mullin Richter & Hampton LLP.
For more, visit the NLR Communications, Media & Internet section.

NIST Releases Updated Draft of Cybersecurity Framework

On December 5, 2017, the National Institute of Standards and Technology (“NIST”) announced the publication of a second draft of a proposed update to the Framework for Improving Critical Infrastructure Cybersecurity (“Cybersecurity Framework”), Version 1.1, Draft 2. NIST has also published an updated draft Roadmap to the Cybersecurity Framework, which “details public and private sector efforts related to and supportive of [the] Framework.”

Updates to the Cybersecurity Framework

The second draft of Version 1.1 is largely consistent with Version 1.0. Indeed, the second draft was explicitly designed to maintain compatibility with Version 1.0 so that current users of the Cybersecurity Framework are able to implement the Version 1.1 “with minimal or no disruption.” Nevertheless, there are notable changes between the second draft of Version 1.1 and Version 1.0, which include:

Increased emphasis that the Cybersecurity Framework is intended for broad application across all industry sectors and types of organizations. Although the Cybersecurity Framework was originally developed to improve cybersecurity risk management in critical infrastructure sectors, the revisions note that the Cybersecurity Framework “can be used by organizations in any sector or community” and is intended to be useful to companies, government agencies, and nonprofits, “regardless of their focus or size.” As with Version 1.0, users of the Cybersecurity Framework Version 1.1 are “encouraged to customize the Framework to maximize individual organizational value.” This update is consistent with previous updatesto NIST’s other publications, which indicate that NIST is attempting to broaden the focus and encourage use of its cybersecurity guidelines by state, local, and tribal governments, as well as private sector organizations.

An explicit acknowledgement of a broader range of cybersecurity threats. As with Version 1.0, NIST intended the Cybersecurity Framework to be technology-neutral. This revision explicitly notes that the Cybersecurity Framework can be used by all organizations, “whether their cybersecurity focus is primarily on information technology (“IT”), cyber-physical systems (“CPS”) or connected devices more generally, including the Internet of Things (“IoT”). This change is also consistent with previous updates to NIST’s other publications, which have recently been amended to recognize that cybersecurity risk impacts many different types of systems.

Augmented focus on cybersecurity management of the supply chain. The revised draft expanded section 3.3 to emphasize the importance of assessing the cybersecurity risks up and down supply chains. NIST explains that cyber supply chain risk management (“SCRM”) should address both “the cybersecurity effect an organization has on external parties and the cybersecurity effect external parties have on an organization.” The revised draft incorporates these activities into the Cybersecurity Framework Implementation Tiers, which generally categorize organizations based on the maturity of their cybersecurity programs and awareness. For example, organizations in Tier 1, with the least mature or “partial” awareness, are “generally unaware” of the cyber supply chain risks of products and services, while organizations in Tier 4 use “real-time or near real-time information to understand and consistently act upon” cyber supply chain risks and communicate proactively “to develop and maintain strong supply chain relationships.” The revised draft emphasizes that all organizations should consider cyber SCRM when managing cybersecurity risks.

Increased emphasis on cybersecurity measures and metrics. NIST added a new section 4.0 to the Cybersecurity Framework that highlights the benefits of self-assessing cybersecurity risk based on meaningful measurement criteria, and emphasizes “the correlation of business results to cybersecurity risk management.” According to the draft, “metrics” can “facilitate decision making and improve performance and accountability.” For example, an organization can have standards for system availability and this measurement can be used at a metric for developing appropriate safeguards to evaluate delivery of services under the Framework’s Protect Function. This revision is consistent with the recently-released NIST Special Publication 800-171A, discussed in a previous blog post, which explains the types of cybersecurity assessments that can be used to evaluate compliance with the security controls of NIST Special Publication 800-171.

Future Developments to the Cybersecurity Framework

NIST is soliciting public comments on the draft Cybersecurity Framework and Roadmap no later than Friday, January 19, 2018. Comments can be emailed to cyberframework@nist.gov.

NIST intends to publish a final Cybersecurity Framework Version 1.1 in early calendar year 2018.

 

© 2017 Covington & Burling LLP
This post was written by Susan B. Cassidy and Moriah Daugherty of Covington & Burling LLP.
 

White House Will Unveil Cyber Executive Actions At A Summit This Week

Squire Patton Boggs (US) LLP law firm

Legislative Activity

This Week’s Hearings:

  • Wednesday, February 11: The Senate Commerce, Science and Transportation Committee will hold a hearing titled “The Connected World: Examining the Internet of Things.”

  • Thursday, February 12: The House Homeland Security Subcommittee on Cybersecurity, Infrastructure Protection and Security Technologies will host a hearing titled “Emerging Threats and Technologies to Protect the Homeland.”

  • Thursday, February 12: The House Education and the Workforce Subcommittee on Early Childhood, Elementary and Secondary Education will hold a hearing titled “How Emerging Technology Affects Student Privacy.”

  • Thursday, February 12: The House Science, Space and Technology Subcommittee on Research and Technology and Subcommittee on Oversight will hold a joint hearing titled “Can Americans Trust the Privacy and Security of their Information on HealthCare.gov?”

Regulatory Activity

White House Will Unveil Cyber Executive Actions at a Summit this Week

On Friday, February 13, the White House will hold its Summit on Cybersecurity and Consumer Protection at Stanford University. President Obama will be speaking at the Summit and plans to issue a new Executive Order focusing on ways to increase cybersecurity information sharing between the private sector and the U.S. Department of Homeland Security (DHS).

The executive action will likely expand the current work that DHS’s National Cybersecurity and Communications Integration Center (NCCIC) does to include a new concept of Information Sharing and Analysis Organizations (ISAO), which was briefly previewed by the President last month. As currently discussed, ISAOs would be designed to share information across multiple industry sectors to supplement the work of the current network of Information Sharing and Analysis Centers (ISACs).  According to press reports from government officials, the executive action is expected to create a network of ISAOs that would be managed by DHS in the beginning and eventually would become a privately-run entity. Several government officials and industry representatives have said that the President’s action will represent a step forward to improving the current information sharing platforms but they also recognize that information sharing legislation is still needed.

In addition to the Summit on Friday, the National Institute of Standards and Technology (NIST) will hold a half-day workshop on Thursday focused on the technical aspects of consumer security. The Office of Science and Technology Policy will also host a meeting leading up to the Summit on Thursday focused on cybersecurity workforce development.

White House Blog Highlights Future Action on Cyber Risk Management

Last week, White House Cybersecurity Coordinator Michael Daniel wrote a blog post on how companies can strengthen their cyber risk management and the role of the federal government in incentivizing stronger cybersecurity practices in the private sector. He notes in the post that the White House believes “the market offers the most effective incentives for the private sector to adopt strong cybersecurity practices,” but also stated that the Obama Administration will continue to work in a variety of areas to support these efforts by streamlining regulations, investing in cybersecurity research and development, and updating federal procurement policies and practice. Daniel wrote that the White House is working with federal agencies and critical infrastructure to identify regulations that are excessively burdensome, conflicting, or ineffective and will release a report on the findings no later than February 2016. Additionally, the White House plans to release a report this spring on the key priorities for cybersecurity research and development over the next three to five years.

The blog post also noted that the White House will not pursue public recognition as a means of incentivizing the private sector to adopt cybersecurity best practices or the NIST Cybersecurity Framework given that this could take away from the voluntary nature of the Framework. While Daniel did not mention liability protection as an incentive for greater information sharing in the blog post, it is still a possible incentive that the White House would support given that it was also included in the information sharing legislative proposal that the President released last month.

ARTICLE BY

Amy F. Davenport
Norma M. Krayem
OF
Squire Patton Boggs (US) LLP