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.

What’s New in NIST’s Cybersecurity Framework (CSF) 2.0

Posted on
NIST, NIST CSF, NIST CSF 2.0, NIST CSF 2.0 changes, CSF compliance, CSF 2.0 compliance, small business CSF
NIST, NIST CSF, NIST CSF 2.0, NIST CSF 2.0 changes, CSF compliance, CSF 2.0 compliance, small business CSF

Since 2022, the National Institute of Standards and Technology (NIST) has been working on major updates to its Cybersecurity Framework (CSF), a set of guidelines and best practices for cybersecurity which enjoys wide adoption among federal organizations and private businesses of every size.

Now that update has finally arrived in the form of a draft issued on August 8th, 2023, and not a moment too soon. With five years elapsing since CSF 1.1 was released in 2018, experts agree that the framework is long overdue for an update reflecting changes in the global threat landscape, and the evolving needs of organizations in both the public and private sector.

To that end, the CSF 2.0 draft largely conforms to proposals outlined by NIST in a concept paper earlier this year. Among other things, it adopts a broader focus extending the scope of CSF beyond its original audience of critical infrastructure operators. It also incorporates a new security function, extended guidance for supply chain security, and more.

In this article we’ll explain how NIST CSF works, how things are changing with CSF 2.0, and why your business should become CSF 2.0 compliant.

What is NIST CSF?

The earliest version of NIST CSF (1.0) was released in 2014, with the now largely forgotten title ‘Framework for Improving Critical Infrastructure Cybersecurity’. But despite its critical infrastructure focus, the framework outlined by CSF is conceptually simple, with wide application to a variety of organizations.

NIST CSF is comprised of three high-level components, a fact which has not changed with the release of CSF 2.0:

  • Core functions – CSF core functions correspond to basic cybersecurity practices and outcomes. The basic functions – “Identify”, “Protect”, “Detect”, “Respond”, and “Recover” – are further broken down into categories and subcategories.
  • Implementation tiers – CSF tiers objectively measure how closely an organization’s existing cybersecurity program conforms with the practices described by the core framework.
  • Framework profiles – CSF profiles help organizations to align their organizational requirements, objectives, risk tolerance and resource against desired outcomes of the framework.

NIST, NIST CSF, NIST CSF 2.0, NIST CSF 2.0 changes, CSF compliance, CSF 2.0 compliance, small business CSF

Unlike other NIST standards – such as 800-171 and 800-53 – NIST CSF does not describe regulations imposed by federal agencies by their partners and contractors. In most cases, CSF compliance is not mandatory, but voluntarily adopted. Even so, the general nature of its guidance has made it a leading cybersecurity standard in both the U.S. and abroad.

Big Changes in CSF 2.0

While many changes in CSF 2.0 have been anticipated since January 2023, the draft document fleshes out details of their implementation, including the announcement of forthcoming tools and resources which will aid organizations towards CSF 2.0 compliance.

1. A Broader Scope

In CSF 2.0, NIST is embracing the reality of CSF adoption, expanding its scope from a standard focused on cybersecurity for critical infrastructure to one with much broader application. This is reflected both by a change of title – from ‘Framework for Improving Critical Infrastructure’ to ‘The Cybersecurity Framework’ – and in language changes throughout the document.

More importantly, CSF 2.0 provides increased guidance to help organizations adapt the framework to their unique mission needs, and examples to illustrate the purpose of profiles. As Microsoft argued in feedback to the CSF 2.0 concept paper, profiles are an underutilized aspect of CSF which will hopefully see wider adoption going forward.

2. The ‘Govern’ Function 

While none of the core functions in the CSF have been removed, one has been added. ‘Govern’ is a special function that intersects the original five, emphasizing cybersecurity as a source of enterprise risk, and providing guidance for how an organization can make internal decisions that support cybersecurity strategy.

NIST illustrates the overlap between ‘Govern’ and other CSF core functions with an updated graphic depicting ‘Govern’ as a circle on which the other functions are supported.

NIST, NIST CSF, NIST CSF 2.0, NIST CSF 2.0 changes, CSF compliance, CSF 2.0 compliance, small business CSF

3. Focus on Supply Chain Security 

In recent years, the rise of software supply chain incidents – including the SolarWinds attack and Log4j zero day – have made supply chain security a central concern for federal agencies. It is a major focus of 2021’s ‘Executive Order on Improving the Nation’s Cybersecurity’, for instance.

It is no surprise then that CSF 2.0 emphasizes supply chain risk management practices under the ‘Govern’ function, drawing on other resources, such as NIST special publication (SP) 800-161r1, ‘Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations’. It also directs readers to use the CSF itself as a standard for vetting suppliers and choosing secure partners.

4. Better Guidance 

While the general nature of CSF guidance has contributed to its success as a cybersecurity standard, some have felt that guidance is too general at times, making it difficult for some organizations to apply. Fortunately, in addition to providing increased CSF profile guidance, CSF 2.0 also includes specific examples of security processes that help achieve core functions.

This guidance has evidently been written with small to medium businesses (SMBs) in mind, as the summary of changes states: “the draft now includes implementation examples for each function’s subcategories to help organizations, especially smaller firms, to use the framework effectively”.

5. Incorporating Other NIST Resources 

Since the release of CSF 1.1, NIST has been hard at work drafting new standards that supplement the framework well. In CSF 2.0, readers are directed to many of those standards – including the NIST Privacy Framework and Secure Software Development Framework among others – for further guidance.

Furthermore, in the coming weeks, NIST will release a CSF 2.0 reference tool which will help organizations to better understand the relationship between CSF 2.0 and other NIST standards included in its Informative References.

CSF 2.0 is a Stepping Stone to Compliance

With NIST stating that it does not intend to release further drafts of CSF 2.0 before the framework is finalized in 2024, it is safe to assume that there will not be any major changes between the draft and the final version.

Although it will not be a requirement for most federal contractors, CSF 2.0 will help businesses to form a solid cybersecurity foundation essential for compliance with NIST 800-171, 800-53 and CMMC while clarifying the risks that matter most to their business, and their ideal security position. Following NIST guidelines can also help businesses to prepare for future regulations, as state and federal governments use NIST standards to shape cybersecurity laws and guidance.

Securicon helps your business to comply with cybersecurity standards like NIST CSF 2.0 through tailored program and risk assessments. With a team comprised of veterans from the U.S. security community – including DoD, DHS, and the U.S. Cyber Commands – we are equipped to provide organizations with gap analysis, compliance consulting, assessment support, and audit preparation. To learn more, contact us today.

Why AI-Driven Tools Will Fail Cyber Defenders

Posted on
AI cybersecurity, AI-driven cybersecurity, AI-powered tools, SOAR, UEBA, XDR, ChatGPT, ChatGPT and cybersecurity
AI cybersecurity, AI-driven cybersecurity, AI-powered tools, SOAR, UEBA, XDR, ChatGPT, ChatGPT and cybersecurity

Every few decades, the world goes through an “AI spring,” and we are in the middle of one right now. With accelerating progress in AI research and the arrival of emerging capabilities exemplified by tools like ChatGPT, hopes are surging that AI applications will soon help organizations to detect threats in their IT environment, prevent data breaches, and block incoming attacks with a much higher success rate.

But nothing is ever that simple. First, AI tools are part of the future for cyber defenders and malicious actors alike. As long as that is true, human expertise will always be the deciding factor in who wins and loses. Second, with IT environments increasing in complexity, expertise is needed to determine where AI can make a real difference, and where it is more of a liability than an asset.

In a previous article, we explained how VPNs can give organizations a false sense of security – not because they are not useful, but because their role in a larger perimeter security strategy is misunderstood. In this article, we will explain why the same is true for nearly any tool or set of tools, however “smart” they may be. But first let us set the scene.

Why AI-Driven Security is Desirable

In today’s cyber landscape, the allure of AI-powered tools is not hard to understand. In Q1 of 2023, cyberattacks rose by 7% over Q1 2022, with organizations facing an average of 2,057 attacks per week. At the same time, organizations are struggling to find help: today, the global cybersecurity workforce gap stands at 3.4 million, with nearly 700,000 unfilled cyber positions in the U.S. alone.

Worst of all, global cyber actors – who are always opportunistic in their pursuit of new vulnerabilities and attack vectors – are already leveraging AI for social engineering and targeted attacks. According to a study by the Cloud Security Alliance, free tools like ChatGPT can be used to find attack points, gain unauthorized access to target networks, conduct reconnaissance and develop malicious code. That does not even count specialized AI-powered toolkits passing around on the Dark Web.

AI-Driven Cybersecurity is Already Here

Clearly, organizations need all the help they can get. But none of these issues are entirely new, and AI-powered solutions are already being employed across many organizations to address them. These include:

  • Security Orchestration, Automation and Response (SOAR) –  SOAR platforms bring together data about security threats from multiple systems, offering automation for repetitive security operations center (SOC) processes, including vulnerability scanning, auditing and log analysis. SOAR platforms increasingly offer AI features to analyze information, prioritize threats, and suggest – or even execute – remedial actions.
  • User and Entity Behavior Analytics (UEBA) – UEBA tools focus on user and entity behavior, using algorithms to establish a baseline for normal activities and identify anomalous ones. Like SOAR, UEBA is often augmented with AI to generate better risk scores and flag potential threats more reliably.
  • Extended Detection and Response (XDR) – as an evolution of endpoint detection and response (EDR) systems, XDR brings threat detection and response functions to systems throughout your organization, providing a clearer picture of your IT environment and developing attacks. Like SOAR and UEBA, XDR tools are increasingly integrating AI-driven functionality.

But despite widespread deployment of SOAR, UEBA, XDR and other emerging cybersecurity products, cyber incidents have not decreased, and the need for human talent has not diminished. This picture is unlikely to change any time soon for many reasons. Here are just a few:

1. Much Assembly Required 

It is often taken for granted that AI will reduce the need for reliance on human talent – but the contrary is just as likely. The more tools organizations introduce, the more talent is needed to configure them safely, monitor their performance, and delineate their role in the midst of changing trends and priorities.

Cyber defenders already rely on a plethora of tools – but just as often as they solve problems, they cause more when they are deployed improperly. This is true in the context of cloud, endpoint detection, VPNs, IoT, and more. There is every reason to believe the same will be true for AI-driven tools, however smart they may be. At a minimum, the wrong rules will lead to overfitting (too many false flags) or underfitting (too many threats ignored).

2. AI Has Limitations 

Recent progress in AI has given many the impression that there’s no upper limit on what AI applications can achieve. But until the arrival of artificial general intelligence (AGI) (at which point organizations will have bigger problems on their hand than cyber actors) AI solutions are necessarily narrow in scope, which limits their effectiveness against human targets.

For now, any AI-driven solution can only integrate with software if the proper APIs are in place. It can only detect and respond to threats it has been trained to anticipate. It can only navigate within a realm of generally defined problems and responses.

With cyber actors innovating new attack strategies around the clock and adopting AI as rapidly as cyber defenders, the measure of a cybersecurity program will never be technology alone: it will be creativity, expertise, and an understanding of factors ranging from organization-specific issues to the way hackers think.

3. Cybersecurity is a Human Issue 

While cyber actors often aim at system intrusion and penetration of network defenses, digital exploits are nearly always downstream from human exploits. According to Deloitte, more than 90% of attacks begin with a phishing email. This is just one of many ways that malicious actors manipulate and deceive your employees into providing them with a foothold – whether that takes the form of credentials, malicious downloads, or sensitive data.

Even now, AI’s role as a hacking tool is primarily confined to the creation of personalized phishing campaigns and social media messages. While AI can potentially help organizations to identify and flag malicious messages, it will not replace cyber training and awareness to help your employees avoid the mistakes that imperil your sensitive data and assets.

Beware of False Promises

As with every new trend, vendors have been quick to jump on the AI bandwagon, offering AI features and promising the moon with it. Often, they exploit the ambiguity of the term “AI”, with products that do not leverage ML models, or any other breakthrough technologies associated with the current AI spring.

But even when they do, organizations must be wary of believing these tools provide a level of unsupervised protection beyond what their existing toolsets provide. They must resist complacency and situate any new acquisitions within a larger strategy guided by human expertise, and an awareness of their unique needs.

Securicon provides tailored cybersecurity assessments with planning and implementation for secure AI-driven capabilities. We are comprised of veterans from the U.S. security community, including DoD, DHS and the U.S. Cyber Command. In addition to providing gap analysis, compliance consulting, assessment support and more, we have the expertise to evaluate emerging cybersecurity solutions and apply them within your IT environment. To learn how we can help you, contact us today.

 

A False Sense of Security: Why VPNs Are Not a Silver Bullet

Posted on
virtual private network security, VPN safety, VPN risks, cybersecurity strategies, VPN breaches, VPN security measures
virtual private network security, VPN safety, VPN risks, cybersecurity strategies, VPN breaches, VPN security measures

In a world of hybrid organizations and a rising number of remote employees, virtual private networks (VPNs) are rapidly growing as a solution for secure access between enterprise networks and external endpoints. In 2022, the global VPN market was valued at $44.6 billion, with experts projecting a $93.1 billion increase by 2030.

But while VPNs play an important role in today’s enterprise security stack, the growth in adoption may represent overconfidence in a technology with distinct risks and limitations. Misconceptions surrounding VPNs abound and with VPN-directed attacks on the rise, those who depend on them as a silver bullet for cybersecurity are in for a rude awakening.

VPN Breaches

In June, cybersecurity researchers reported that 360 million user data records were leaked in a breach affecting SuperVPN, a free VPN service operating in China.

While users of the application had expected it to protect their personal data and identities, instead it exposed both of them – including email addresses, location and online activities – to the open Web.

This story would be less concerning if security flaws were limited to free and consumer-facing VPN services. Unfortunately, they are not – they affect VPN products used by major companies, including federal agencies, local governments, and critical infrastructure operators.

To protect themselves from these risks, organizations must understand the limited role that VPNs play in a comprehensive cybersecurity strategy, the risks they can introduce to an IT ecosystem, and best practices for utilizing them effectively.

What VPNs Really Do

According to a study from the University of Maryland, VPN ads directed at consumers through social media include “overpromises and exaggerations that could negatively influence viewers’ mental models of internet safety”. But overpromising and exaggerations only work because viewers don’t know what a VPN really does.

In an enterprise configuration, a VPN creates an encrypted connection between a VPN client installed on a device outside your organization, and a VPN server hosted on-site or at an off-site data center. Once there, traffic is directed either to the open Web, to cloud services, or to internal resources.

When a VPN works properly, the encrypted connection between client and server forms a secure “tunnel” that provides protection against snooping from attackers: it masks the identity of remote endpoints connecting to your organization, their external destinations, and any data sent between them.

What VPNs Don’t Do

Unfortunately, VPNs do not always work properly. And even when they do, there are many risks they don’t protect against. For instance:

  • VPNs do not protect software as a service (SaaS) apps which reside outside your organization. While employees can use your VPN to connect with them, they will often choose not to since VPNs can be slow and cumbersome. This compounds the growing risk of Shadow IT that organizations already suffer from, with data scattered across unmanaged and poorly protected external services.
  • While a VPN can prevent attackers from intercepting or decrypting traffic as it travels through the VPN tunnel, it does not protect data at ingress or egress. If attackers have already compromised devices inside or outside your network – which they can do through malware, phishing or social engineering attacks – they can still spy on data sent both ways.
  • VPNs do not always prevent devices from broadcasting their real IP addresses or the destination of their traffic. Weaknesses in the VPN client – or non-VPN software – can tip watchful adversaries off to the identity of protected endpoints.

VPN-Associated Risks

Aside from the fact that VPNs do not protect against all cyber risks, they often introduce new ones, including:

  • Keys to the Kingdom – enterprise VPNs are typically deployed without layered controls, network segmentation or principles of least access to ensure that users are limited to certain resources. In this case, all a cyber actor needs is one set of VPN credentials or one trusted device to access everything on your network, making VPN-connected devices a valuable target.
  • Expanded Attack Surface – according to a report by Cybersecurity Insiders and Zscaler, 61% of organizations have three or more VPN gateways – with public IP addresses – and many have more than five. Together with the countless devices connected to your company via those gateways, this represents a significant increase in the attack surface for cyber actors.
  • Vulnerabilities – vulnerabilities affecting VPN servers or clients are often discovered, requiring patches to prevent exploitation. In 2020, one vulnerability affecting the SonicWall VPN rendered nearly 800,000 devices vulnerable to denial of service attacks and remote code execution exploits.
  • Weak Encryption – while decrypting traffic between a VPN client and server is usually an unrealistic attack vector, servers will sometimes default to weaker encryption standards in an effort to communicate with obsolete clients. In this case, interception and decryption of traffic is a genuine risk.

Best Practices for Enterprise VPNs

As with enterprise cloud solutions, some of the risks associated with business VPNs are attributable to misconfiguration or poor maintenance by the customer. There are key practices to help organizations enhance VPN security and protect against attacks. In 2020, the National Security Agency (NSA) published a few:

  1. Reduce VPN gateway attack surfaces – this means minimizing the number of VPN gateways, and also implementing traffic rules to “limit the ports, protocols and IP addresses of network traffic to VPN devices.” In general, arbitrary devices should not be able to connect with a VPN gateway.
  2. Verify that cryptographic algorithms are CNSSP 15-compliant – the Committee on National Security Systems Policy (CNSSP) 15 specifies safe encryption standards. At a minimum, the NSA recommends VPN configurations that include the Internet Security Association and Key Management Internet Key Exchange (IKE) policy and the IPsec policy.
  3. Avoid using default VPN settings – sticking with default VPN settings may enable weaker cryptographic standards. As a best practice, the NSA recommends that all settings for VPNs are manually configured.
  4. Apply vendor-provided updates/patches – as with any business-critical software, organizations should apply patches to their server-side software and devices as soon as they are issued, and enforce patches to VPN clients.

But while these recommendations will make your enterprise VPN configurations safer, they will not protect against complacency in other domains, such as a lack of multifactor authentication (MFA) or regular password updates – an absence of network segmentation or zero trust policies for internal resources – or a lack of cyber training to prevent phishing/social engineering attacks or improper handling of trusted devices.

Secure VPNs Are Downstream from Secure Organizations

While many businesses are planning to move away from VPNs to alternative solutions for remote access (such as SASE and ZTN), realistically they will still have a place in hybrid work environments for many years to come. This won’t be a problem for organizations who understand that VPNs play a small part in a larger cybersecurity strategy, and work with the right partners to eliminate security gaps that affect VPN safety.

With a team comprised of veterans from the U.S security community – including DoD, DHS and the U.S Cyber Command – Securicon is equipped protect remote access solutions (including VPNs) and harden your security position with gap analysis, compliance consulting, assessment support, audit preparation and more. To learn how we can help you, contact us today.