What GovCons Should Know About Software Bills of Material (SBOMs)

Posted on

In May of 2021 – following the Log4Shell vulnerability and other software supply chain incidents – the White House directed government agencies to adopt software bills of material (SBOMs) in executive order (EO) 14028. Two years later, the federal security community is still debating how to implement them.

There’s a long road ahead for SBOM adoption: even so, SBOMs will undoubtedly impact government contractors who make and distribute software in the not-too-distant future. Moreover, the ability to utilize SBOMs in a supply chain risk management strategy will likely be required by future cybersecurity regulations.

Opinions on this development are split. While SBOMs are sure to help organizations anticipate software supply chain incidents and respond rapidly, they also represent a new and rapidly developing toolset with many unanswered questions. So how are agencies tackling the directive set forth in 2021, and what do contractors need to know in the meanwhile? In this article, we’ll tackle both questions.

Software Supply Chain Challenges

Government agencies, contractors, and businesses in the private sector share one thing in common: they all depend on technology that incorporates third-party software components, including APIs, SDKs, and open-source frameworks. The sheer number of these dependencies is hard to keep track of, making them ideal targets for cyber actors seeking vulnerabilities to exploit.
Between 2019 and 2022, software supply chain attacks leveraging software flaws to infiltrate global businesses increased by an alarming 742%, giving rise to some of the largest cyberattacks ever seen by number of businesses affected. More recently – as many government and industry leaders foresaw – software supply chain vulnerabilities have played a key role in attacks against federal agencies by foreign actors.

How SBOMs Help

To help organizations keep track of third-party components in their software products, SBOMs were introduced in 2018 by the National Telecommunications and Information Administration (NTIA), which remains active in their ongoing development.
According to the Cybersecurity and Infrastructure Security Agency (CISA), an SBOM is – at its most basic – “a nested inventory, a list of ingredients that make up software components,” complete with component names and versions, and other unique identifiers.
Software developers can provide customers with SBOMs to disclose which third-party and open-source components are included in their product, preventing situations like the scramble to identify which software packages included Log4j in the aftermath of the Log4Shell incident.
Following EO 14028, SBOMs have seen rapid adoption in the private sector, with Sonatype reporting that 92% of enterprises currently maintain SBOMs or plan to implement them within the next year. In the face of mounting cybersecurity challenges, the healthcare industry in particular has embraced SBOMs as a way to ensure the security of medical devices.

Progress Towards SBOM Adoption

Following EO 14028, the NTIA released simplified guidelines surrounding SBOMs, and introduced a new standard – Vulnerability Exploitability Exchanges (VEXes) – to supplement the component inventory in SBOMs with information about component vulnerabilities.
Early the following year, NIST released the first version of its Secure Software Development Framework (SSDF), which directs software developers to collect provenance data for the creation of SBOMs. Several months later, the Office of Management and Budget (OMB) issued a memorandum encouraging all federal agencies to require SSDF compliance by their vendors.

SBOMs Are the Future

More recently, CISA has held exploratory sessions and public events to further establish SBOM standards. These events have tended to show that SBOMs are currently not well-defined enough to achieve widespread implementation as soon as some might hope.
Nevertheless, EO 14028 requires agencies to make progress in that direction, and many are trying. Eventually, they will ask for SBOMs and likely VEXes as well from their software suppliers. It’s also probable that contractors who don’t produce software will be required to make use of SBOMs for cybersecurity purposes. The road ahead is long, but its destination is sure.

Preparing for SBOMs

With mandatory SBOMs on the horizon, government contractors who want to stay abreast of government regulations and implement cybersecurity best practices should start preparing now. Here’s a few things that software developers and suppliers should know:

    1. Minimum requirements for an SBOM
      NIST’s guidance directs organizations to follow the minimum SBOM elements described by NTIA. SBOMs must include data fields that document baseline information about each software component, including supplier, component name, version of component, dependency relationship, author of data, timestamp, and other unique identifiers. SBOMs must be machine-readable, as their purpose is to be integrated with other security tools and used to continually monitor/identify risks.
    2. The function of VEXes
      While SBOMs include an inventory of components in a software product, VEXes disclose or attest to any vulnerabilities present in those components, whether they are exploitable, and any recommended actions for the customer. VEXes are not the same thing as an SBOM and may be provided separately from an SBOM – but they are both machine-readable standards that provide critical information for rapidly assessing software security issues.
    3. Types of SBOMs
      CISA currently defines six SBOM types, with benefits and limitations for each type, although this list may be expanded. SBOMs can be created at any stage of the software development cycle, including the planning, development, compilation, and post-compilation stages. SBOMs can also be created for software that is already deployed on a customer’s system.
    4. SBOM creation
      The SBOM creation process has been one of its most controversial aspects due to the time and effort required to manually create an inventory of software components. Even with automation, SBOM creation can be cumbersome. However, many tools and varieties of tools already exist. CISA recommends using a software composition analysis (SCA) tool during the development process, and third-party tools for the post-build stage.
      OWASP maintains a list of component analysis tools which organizations may want to consider. Until SBOMs are further standardized – and beyond the minimal criteria set forth by NTIA – there is wide latitude for the exact format of SBOMs, and the information they include.
    5. For Non-Software Developers
      Government contractors who do not develop or distribute software should still understand how to consume information from SBOMs and use them for supply chain risk management. The data provided both by SBOMs and VEXes are incredibly useful, enabling rapid response in the event of a supply chain security incident, and proactive measures to prevent them from occurring.

Organizations who would like to get a head start on implementing SBOMs into their ongoing security efforts should implement NIST CSF (which now includes the SSDF in its informative references) and review materials from CISA’s SBOM site.

Getting a Head Start

It remains to be seen what shape federal adoption of SBOMs will take, but it’s clear that the standard will eventually be crucial both for government contractors and organizations in the private sector.

With Gartner predicting that nearly half of global businesses will experience a software supply chain attack by 2025, now is the time to take ownership of your software assets and resolve vulnerabilities before they are exploited.
Securicon helps your business to stay ahead of government regulations and navigate emerging standards like SBOMs and VEXes. With a team comprised of veterans from the U.S security community – including DoD, DHS, and the U.S Cyber Command – we are equipped to provide organizations with gap analysis, compliance consulting, assessment support, audit preparation and risk assessment. To learn more, contact us todayContact.

Microsoft is Changing How it Authenticates Email: Explaining CISA’s Announcement

Posted on
CISA
CISA

Back at RSA 2020, in the days before the pandemic drove most companies to adopt remote work, Microsoft explained that about half of 1% of the enterprise accounts in their system were compromised per month. The reason? 99.9% didn’t use multi-factor authentication (MFA).

Two years later, security professionals still promote MFA as fundamental to cyberattack risk mitigation. The Deputy National Security Advisor for Cyber and Emerging Technologies, Anne Neuberger, said that MFA can prevent 80-90% of cyberattacks. Neuberger stressed the importance of implementing MFA for key personnel and IT staff. With so many MFA technologies available, it would seem like something all organizations could implement quickly.

However, research found that 65% of IT and security professionals believe that their company’s authentication is not secure. Further, if the recent CISA Guidance on Switching to Modern Auth in Exchange Online Before October 1 (CISA Guidance) is any indication, the outlook isn’t good.

The catch is that the CISA Guidance isn’t about getting people to use MFA. Moving to Modern Auth doesn’t mean just getting end-users on board. It means changing configurations for your systems and applications too. For example, your Exchange server so that all email clients and apps use it, too.

In this article, we’ll explain what the CISA guidance says, how Modern Auth helps you meet Executive Order 14028 MFA requirements, and how to overcome challenges when moving away from legacy protocols.

What’s in the CISA Guidance?

The CISA Guidance is short, just two paragraphs with many links. It reminds companies that Microsoft will begin permanently disabling Basic Auth on October 1, 2022. Then, CISA reminds Federal Civilian Executive Branch (FCEB) agencies that Basic Auth doesn’t support MFA.

CISA requires FCEB agencies and recommends that all organizations prioritize moving to Modern Auth.

“Legacy” or Basic Authentication

Legacy, or Basic, authentication means that an application only sends a username and password with its requests. Often, the device stores or saves the credentials. Traditionally, most servers or services enable Basic Auth by default.

With Basic Auth, the email application sends the username and password to Exchange Online. In turn, Exchange Online forwards the credentials to the identity provider on behalf of the app.

Examples of protocols that use Basic Auth are:

      • MAPI
      • RPC
      • Offline Address Book (OAB)
      • Exchange Web Services (EWS)
      • POP
      • IMAP
      • Exchange ActiveSync (EAS)
      • Remote PowerShell
      • Outlook for Windows and Mac

    As explained in Microsoft’s update, they will randomly select tenants, send a 7-day warning notice, then turn off Basic Auth in the Exchange Online tenant. As soon as Microsoft disables Basic Auth in your tenant, clients still using it won’t be able to connect.

    They also made it crystal clear: no exceptions and no asking to be at the end of the line.

    Problems with Basic Auth

    During his 2020 RSA talk, Alex Weinert, Microsoft’s Director of Identity Security, pointed out legacy authentication protocols led to 99% of successful password spray and replay attacks. Since then, attacks targeting credentials have only increased. In late 2021, Microsoft Threat Intelligence Center (MTIC) released research that threat actor DEV-0343 targeted password spraying attacks against the defense sector.

    With password spraying attacks, threat actors take a collection of usernames and try commonly used passwords, hoping to gain access. Meanwhile, replay attacks use credentials stolen during a data breach, then use that list against another system. If someone reuses a personal password for their job, the attackers might get a “hit.”

    When you use Basic Auth for applications and devices, you expand your risk. Someone, somewhere is setting the password for these, possibly one that attackers already know. If your authentication server still uses Basic Auth, then you don’t have the additional verification at the machine level that you would with people using MFA.

    Modern Authentication

    What makes Modern Auth different? Microsoft uses this broader term to describe a combination of authentication and authorization methods between a client, like a laptop, and a server.

    It gives you a way to incorporate the security measures that rely on access policies, including:

        • Authentication: MFA, smartcard authentication, client certificate-based authentication
        • Authorization: Open Authorization (OAuth)
        • Conditional access policies: Mobile Application Management (MAM), Azure Active Directory (AAD) Conditional Access

      With modern authentication, you can create the identity and access building blocks of a zero trust architecture (ZTA). Further, you can put in place MFA so that you meet the Executive Order’s requirements.

      What You Need to Do Right Now

      In the middle of summer, October seems like a long way off. The reality is that you’ve got two months to prepare and make the necessary changes to keep these changes from impacting your operations.

      Locate Basic Auth Protocols

      Most organizations haven’t moved to Modern Auth because solutioning and changing to Modern Auth is time-consuming. However, start reviewing applications and services now for Basic Auth use.

      If you’re using AAD, you can review sign-in logs to identify applications and users authenticating with Basic Auth.

      Create a Plan

      If moving to Modern Auth was as easy as a click of the mouse, most companies would have done it already.

      To keep all your services up, you should:

          • Double check and enable modern authentication on your Exchange Server
          • Double check and enable modern authentication on your email clients and apps
          • Connect all Exchange-related PowerShell environments

      Create and Apply Authentication Policies

      Now that you’ve reviewed and updated everything, you can create new policies that block Basic Auth. Then, you assign the policy to users.

      If you’re using Conditional Access policies, you want to make sure that you run them in report-only mode before pushing them live. This way, you can double-check to ensure you caught all legacy authentication usage before blocking access.

      Confirm Changes

      After your changes are live, you want to confirm that they worked as intended. When the authentication policy blocks Basic Auth requests in Exchange Online, you’ll see a “401 Unauthorized” response.

      Prepare for Microsoft’s Changes with Securicon

      Agencies face several challenges when adopting MFA. The old saying, “an ounce of prevention is worth a pound of cure” is never more applicable than now. Since no one knows how Microsoft is going to randomly roll out its Basic Auth deprecation, you want to have a plan in place that won’t lead to a service outage. Plus, it gets you one step closer to meeting the MFA requirements outlined in the Executive Order.

      Securicon goes beyond providing information technology solutions. We help define, deliver, implement, and manage information security programs for U.S. Cyber Command and the Department of Homeland Security. Our experienced, knowledgeable staff uses sound, proven methodologies, and comprehensive strategies so that you can get the business and functional outcomes your organization needs. Contact us to learn more!