Tag: NIST

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