Articles

Software supply chain security fixes gain prominence at RSA

Attendees are urged to improve asset management, use SBOMs, and collaborate with government cybersecurity agencies to better ensure software integrity.

Given the significant cybersecurity problems that the SolarWinds, Log4j and other software supply chain infections created over the past two years, it’s no surprise that software security emerged as a hot topic at this year’s RSA conference. Ahead of the event, ReversingLabs released a survey it commissioned of over 300 senior software employees on the struggles their firms face in detecting supply chain attacks

Despite the recent spate of high-profile software supply chain security incidents, the ReversingLabs study found that fewer than four in ten companies say they can detect tampering with developed code. In addition, less than 10% of companies are reviewing software at each product lifecycle stage for evidence of tampering or compromises.

SBOM usage is sparse but expected to grow rapidly

When it comes to one crucial emerging tool that can better ensure software security, a software bill of materials (SBOM), ReversingLabs survey found that only 27% of the IT professionals surveyed said their employer generates and reviews SBOMs before releasing software. Of those respondents who do not develop SBOMs, 44% cited a lack of expertise and staffing needed to do so, while 32% cited a lack of budget for implementing SBOM. Only 7% of respondents at companies that don’t produce SBOMs said the reason was that an SBOM wasn’t needed.

The sparse usage of SBOMs is quickly becoming a thing of the past for two primary reasons, Allan Friedman, senior advisor and strategist at the U.S. Cybersecurity and Infrastructure Security Agency (CISA), told RSA attendees. First, because of events like SolarWinds, organizations are starting to demand SBOMs for the software they use as a security measure to identify problematic code.

This article appeared in CSO Online. To read the rest of the article please visit here.

 

Articles

NIST releases software, IoT, and consumer cybersecurity labeling guidance

The new guidance aims to tighten security requirements for federally purchased software and give consumers better insight into the security of software and devices they buy.

On February 4, the National Institute of Standards and Technology (NIST) issued several documents and updates that spell out software security guidance and recommended consumer labeling practices for software and IoT devices. NIST also laid out its approach to consumer cybersecurity labeling projects.

These initiatives were mandated under President Biden’s wide-ranging executive order (EO) issued last May. They aim to tighten the federal government’s security requirements for the software products it purchases, hoping that the benefits will also flow to the private sector. The labeling initiatives aim to provide consumers greater insight into the security of the software and devices they purchase and spur greater transparency by consumer software and IoT device makers.

This article appeared in CSO Online. To read the rest of the article please visit here.

 

 

Articles

NIST gears up for software security and IoT labeling…

Intended to help consumers make more secure software and IoT device purchases, the labeling guidelines are voluntary and self-policing at this time.

President Biden’s wide-ranging cybersecurity executive order issued last May directs the National Institute of Standards and Technology (NIST) to create pilot labeling programs to educate the public on the security of the internet-of-things (IoT) devices and software products they buy. The order requires NIST to produce by February 6, 2022, IoT cybersecurity criteria for a consumer labeling program and, separately, identify secure software development practices or criteria for a software labeling program.

To those ends, NIST held a workshop in September and solicited comments from stakeholders and experts. Based on the input received in these efforts and after issuing preliminary draft papers that outline various approaches, NIST issued draft Baseline Criteria for Consumer Software Cybersecurity Labeling on November 1 and a discussion draft on Consumer Cybersecurity Labeling for IoT Products on December 3.

After NIST produces both the IoT and software criteria in February, it will begin a labeling pilot testing phase. That phase will consist of NIST engaging with organizations that currently offer consumer labeling options. NIST says it may also decide to establish measures to demonstrate further proof of concept based on the criteria it publishes.

This article appeared in CSO Online. To read the rest of the article please visit here.

Articles

NIST workshop provides clues to upcoming software supply chain…

Experts at a NIST-sponsored workshop weigh in on what might be in the final version of the Biden executive-order-mandated supply chain security guidelines.

President Biden’s wide-ranging cybersecurity executive order (EO) issued in May aims to improve software security through a series of guidelines. As the EO directed, the National Institute of Standards and Technology (NIST) has produced a definition of what constitutes “critical software,” published guidance on security measures for EO-critical software use, and released guidelines on vendors’ source-code testing. On November 8,  NIST published preliminary guidelines for enhancing software supply chain security.

NIST recently held a workshop to discuss the guidelines’ provisions, which are due in final form by February 6, 2022. The EO asks NIST to produce its software supply chain security guidelines according to ten criteria, including secure software development environments; the generation of “artifacts,” which can contain a host of information about how the software was developed; the provenance or origin of software code and components; software bills of materials (SBOMs); vulnerability disclosure programs; and attestation to conformity with secure software development practices.

The workshop gathered experts to share their insights on some of the components currently contemplated for the final supply chain security guidelines.

This article appeared in CSO Online. To read the rest of the article please visit here.

Articles

Software cybersecurity labels face practical, cost challenges

The federal government wants consumer software to have cybersecurity labels; experts question the feasibility of the mandate.

As part of his extensive cybersecurity executive order issued in May, President Biden directed the National Institute of Standards and Technology (NIST) to develop two pilot labeling programs on the cybersecurity capabilities of internet-of-things (IoT) consumer devices and software development practices. Although these pilot programs won’t be mandatory for device or software sellers, they could likely raise market expectations. In addition, whatever labels come out of these programs would also carry with them some sense of government authority and might ultimately become part of the government contracting process.

Last week NIST held a two-day workshop on these topics. Of the two pilot programs, the consumer software labeling initiative is the trickier one given the ever-changing nature of software and the absence of any similar existing consumer software labeling initiative.

To help it grasp the more complex task of developing labels for software, NIST solicited one- to two-page labeling position papers from interested parties. In calling for these papers, NIST cited “the challenges and practical approaches to consumer software labeling,” asking` for feedback on the “technical criteria needed to support validation of consumer software security assertions that reflect a baseline level of secure practices.”

This article appeared in CSO Online. To read the rest of the article please visit here.

Photo by Jon Tyson on Unsplash

Articles

NIST’s EO-mandated software security guidelines could be a game-changer

While experts applaud the new security guidance, it’s unclear whether software vendors will completely embrace and implement the needed security practices.

Following a string of high-profile supply chain hacks, President Biden’s wide-ranging executive order on cybersecurity (EO) issued on May 12 directed the National Institute of Standards and Technology (NIST) to produce guidance on a series of software security matters. First, the EO asked NIST to produce a definition of critical software, which it released at the end of June. Second, the EO directed NIST to publish guidance on security measures for EO-critical software use, which NIST released last Friday.

To tackle the complex issue of keeping software secure, NIST solicited papers from interested parties and held a two-day workshop to gain insight from industry and other experts.  NIST defined five objectives for the operational-only (not covering development and acquisition matters) security measures:

  1. Protect EO-critical software and EO-critical software platforms (the platforms on which EO-critical software runs, such as endpoints, servers, and cloud resources) from unauthorized access and usage. Measures here include use of multi-factor authentication, following privileged access management principles, and employing boundary protection techniques.
  2. Protect the confidentiality, integrity, and availability of data used by EO-critical software and EO-critical software platforms. Measures here include maintaining a data inventory, protecting data at rest and in transit, and back up data with a tested recovery plan.
  3. Identify and maintain EO-critical software platforms and the software deployed to those platforms to protect the EO-critical software from exploitation. Measures here include maintaining a software inventory, have a patch management plan, and use configuration management practices.
  4. Quickly detect, respond to, and recover from threats and incidents involving EO-critical software and EO-critical software platforms. Measures here include recording necessary logging information, continuous security monitoring, and using endpoint and network security protection.
  5. Strengthen the understanding and performance of humans’ actions that foster the security of EO-critical software and EO-critical software platforms. Measures here include training all users and administrators of EO-critical software and conducting frequent awareness activities.

This article appeared in CSO Online. To read the rest of the article please visit here.

Photo by Fotis Fotopoulos on Unsplash

 

Articles

NIST defines “critical software” with a broad range of…

The goal is to enable stronger security practices for government-purchased software mandated by President Biden’s cybersecurity executive order.

A significant part of the Biden administration’s wide-ranging cybersecurity executive order (EO) mandates that the National Institute of Standards and Technology (NIST) define what constitutes “critical software,” a deliverable that is central to the wider effort of securing software supply chains. Last week NIST made good on this assignment when it released a preliminary list of software categories within the scope of this definition.

The EO stipulates that NIST’s definition “shall reflect the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.” Thus, the goal of the definition is to drive several additional activities required under the EO to shape how the federal government purchases and manages deployed critical software.

One driving principle behind the critical software definition is that when combined with other aspects of the EO, software acquisition by the federal government would tilt over time toward only those products that have met reasonable security measures. The hope is that the federal government’s “power of the purse” would spill over to the private sector because most major software suppliers sell to both public and private sector customers and would find it more efficient to create a single secure product for both sectors.

This article appeared in CSO Online. To read the rest of the article please visit here.

 

Articles

Government-mandated SBOMs to throw light on software supply chain…

The US government will soon require vendors to provide a software bill of materials to help ensure integrity of an application’s components.

President Biden’s executive order (EO) on cybersecurity, released on May 12, is a sprawling and comprehensive document that aims to redress weaknesses in the digital security ecosystem. It is peppered with nearly 50 actions that the federal government must take within extraordinarily tight timeframes, signaling the urgency of the cybersecurity crisis the country faces.

Several parts of the EO seek to shore up software security. This long-overlooked and arcane topic has taken on new urgency following the SolarWinds and Microsoft Exchange software supply chain hacks.

The first software security deadline in the EO, assigned primarily to the Commerce Department’s National Institute of Standards and Technology (NIST), is to publish a definition of what constitutes “critical software,” which in turn will trigger actions by other government agencies. NIST’s deadline for producing this definition is June 26, which is why the agency held a quickly organized workshop on June 2 and 3 attended by around a thousand interested parties.

Fifteen days after the release of NIST’s definition of critical software, another arm of the Commerce Department, the National Telecommunications and Information Administration (NTIA), will publish “minimum elements” of something that has been evolving over the past several years in the cybersecurity realm, a software bill of materials, or SBOM.

This article appeared in CSO Online. To read the rest of the article please visit here.