Vigilant Ops Wins Cybersecurity Challenge

Category

Blog

Prioritizing Cybersecurity in Supply Chain Operations

| vigilantops | , ,

It’s a rare day if you don’t see a headline about a data breach or ransomware crippling a business or the supply chain. Websites are defaced, personal and financial information stolen, and even medical information is at risk for theft and improper sharing. Software once thought secure is now at risk more than ever as malicious insiders and state sponsored hacking have taken the forefront of electronic espionage and harmful data dumps. It’s become so prevalent the US government is working with Microsoft and Google to secure free software. To secure financial and confidential contract information, the US government is also enacting new standards that will cost federal suppliers and their secondary suppliers millions of dollars to implement.

The threats are that bad and are getting worse. In 2020, the number of reported spam phishing attacks was at 1.5 million. In 2021, there were over 10 million, a +573% growth, and this number is expected to increase. It’s no wonder that cybersecurity personnel are in such high demand. So much so that colleges and universities are tailoring their cybersecurity degree curriculums to simulate the latest security threats. Using virtual labs, those training to be on the front line in infrastructure security are able to get real world experience. This focus on training is clearly working as the field is expected to grow more than 30% in the next decade. For companies who work in the supply chain this increase can’t come soon enough.

Why Invest in Supply Chain Cybersecurity?

Investing in good cybersecurity practices prevents headaches down the line and is great for customer confidence, but knowing what to safeguard is a must. Focusing on supply chain security lessens the possibility of external attacks through supplier portals, supplier fraud, and data leaks. If you have employees that work from home, chances are their home network is not as secure as your commercial one. Electronic criminals have increasingly targeted home office workers since the pandemic because of the lighter consumer security used. With social engineering and phishing attacks on the rise, cybersecurity education is a solid investment, especially if they are contingent workers. Supplier fraud, or vendor fraud, is another risk a cybersecurity program mitigates. If supplier gateways aren’t secure, or if the supplier has weak cybersecurity practices, your company risks being attacked through the connection to the supplier’s systems. Once a malicious actor has access to your systems, your data is at risk if file protections and access control are not a priority.

How to prioritize cybersecurity in supply chain operations

So, how do you implement supply chain security? A major program of your information security plan should be training and education. Implement phishing tests for your employees that evaluate their ability to recognize suspicious emails and social engineering calls. Your employees are your first line of defense against these types of threats, invest in them. Make sure insider threat is a part of this training and give examples of malicious behavior. Conduct background checks on employees that have access to sensitive or proprietary information, and make sure that they only have access to the information they need to do their jobs. Access control is central to good cybersecurity hygiene; if employees don’t have a business reason to access information, they shouldn’t be able to get to it. VPNs and end to end encryption will provide an added layer of security for those working remotely. Add two factor authentication to that to harden your systems even more.

Prioritize supply chain security holes

Another thing you need to know is where the holes are in your security fabric: where are the vulnerabilities and what is affected? In our article on using a software bill of materials, we outline a way of finding vulnerabilities and automating the search in your deployed devices. Third party vendors may not be timely in their notifications of vulnerabilities, and this is one way to mitigate that threat. Keep suppliers sequestered to only the data they need to conduct business. Suppliers should never have access to your internal data, and if they can’t get to it, they can’t leak it.

In today’s digital centric society the supply chain needs to be a top cybersecurity priority. To not do so will cause mass disruption to companies and their customers.

Submitted by Danielle Gregory for vigilant-ops.com

Using SBOM to Identify Vulnerabilities and Impacted Devices

| vigilantops | , ,

Last week, CISA (the U.S. Cybersecurity and Infrastructure Security Agency) issued an advisory about critical vulnerabilities in embedded software that opens the door to possible security breaches. No breaches have been reported to date, but the potential impact spans multiple industries, including healthcare. This short summary discusses how SBOM can help manufacturers respond and take action.

SBOM Can Help with Vulnerability Discovery

The Software Bill of Materials (SBOM) has been getting a lot of publicity as of late, and it is a critical piece of the cybersecurity puzzle. Generating an SBOM for a specific device is the first step in deployment. Next, those discovered components in the SBOM must be researched and all associated vulnerabilities found. This process of discovery must be continuous so that the SBOM remains updated and evergreen. One of the benefits of a continuously maintained SBOM is the ability to find newly released vulnerabilities more quickly, such as CVE-2021-31886 relating to this current vulnerability in embedded software.

SBOM Can Help Identify Impacted Devices

Organizations with the ability to generate SBOMs for their fielded products have a decided advantage because they can immediately identify impacted systems and deploy critical security patches targeted at only those systems that are impacted. This saves a tremendous amount of time spent sifting through customer records or calling customers trying to determine fielded system profiles.

SBOM Automation is Effective and Efficient

While SBOM is a critical security document, organizations should not make the common mistake of assuming the effort involved to generate and maintain is similar to existing security documentation, such as the Manufacturer Disclosure Statement for Medical Device Security (MDS2). The SBOM is much more involved, and if the manufacturer is responsible for multiple versions of multiple systems, the effort involved to generate and maintain SBOMs could easily require a full-time engineering resource, or substantial effort from several resources. Small manufacturers simply can’t afford it, while larger manufacturers are discovering that the opportunity cost of dedicating development resources to a maintenance task is just too high.

Summary

If you have not started to dig into the SBOM yet, you should.  You can start with a search on SBOM or Executive Order 14028 or National Telecommunications and Information Administration (NTIA) Software Transparency. There are lots of great resources and good information is readily available.

If you have started down the SBOM path and are concluding that your effort won’t scale, check out automated SBOM solutions. Be on the lookout for SBOM generation functionality and continuous vulnerability monitoring. Automated alerts and sharing with authorized end users are also helpful features.

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: inquiries@vigilant-ops.com

Matt Lentine
matt.lentine@vigilant-ops.com
412-704-4602

U.S. House Passes Supply Chain Security Bill

| vigilantops | , ,

As part of the response to recent hacks, the United States House of Representatives voted on and passed the DHS Software Supply Chain Risk Management Act of 2021 on October 20, 2021, by a vote of 412-2. The Act covers both new and existing contracts with the Department of Homeland Security (DHS).

As a Condition on the Award of Contracts

Contractors must submit a bill of materials, defined in this Act as “a list of the parts and components (whether new or reused) of an end product or service, including, with respect to each part and component, information relating to the origin, composition, integrity, and any other information as determined appropriate by the Under Secretary.”

Continuous SBOM Updates Required

As information in the SBOM changes, contractors are required to submit updates to SBOMs. “…in the case of a change to the information included in a bill of materials…each contractor shall submit…the update to such bill of materials, in a timely manner.”

SBOMs Certified Using the National Vulnerability Database (NVD)

Items listed on the bill of materials must be “…free from all known vulnerabilities or defects affecting the security of the end product or service identified in the National Institute of Standards and Technology National Vulnerability Database…”. In other words, product risk analysis must include investigation into component vulnerabilities and their potential impact on the security of the product and software supply chain risk.

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: inquiries@vigilant-ops.com

Matt Lentine
matt.lentine@vigilant-ops.com
412-704-4602

FDA Seeking Additional Legislative Authorities

| vigilantops | , ,
FDA is seeking “legislative authorities” to enable the office to require medical device manufacturers to adhere to strict cybersecurity policies, including the development of a Software Bill of Materials (SBOM).

The Minimum Elements for a Software Bill of Materials (SBOM)

Yesterday, the United States Department of Commerce released The Minimum Elements for a Software Bill of Materials (SBOM), in accordance with President Biden Executive Order 14028 on Improving the Nation’s Cybersecurity. For those who have been following the National Telecommunications and Information Administration (NTIA) SBOM work, you won’t find any surprises in the release. The document thoroughly describes the SBOM, provides motivation for the SBOM as a standard security document, and makes the point that the SBOM is only one piece of an effective security ecosystem. 

Data Fields

The suggested baseline data fields of the SBOM should provide sufficient information about the components of the SBOM to enable further investigation into associated information about the components, including vulnerabilities. The document suggests the following minimum elements:

Supplier Name – the name of the entity that creates, defines, and identifies components, for example, Microsoft

Component Name – designation assigned to a unit of software defined by the original supplier, for example, Windows 10

Version of the Component – identifier used by the supplier to specify a change in software from a previously identified version, for example, version 1607

Other Unique Identifiers – other identifiers that are used to identify a component, or serve as a look-up key for relevant databases, including the Common Platform Enumeration (CPE) that can be used to find vulnerabilities for the component in the National Vulnerability Database (NVD), for example, cpe:2.3:o:Microsoft:windows_10:1607:*:*:*:*:*:x64:*

Dependency Relationship – characterizing the relationship that an upstream component X is included in software Y, for example Notepad is included in Windows 10 version 1607

Author of SBOM data – the name of the entity that creates the SBOM data for this component, for example, Vigilant Ops

Timestamp – record of the date and time of the SBOM data assembly, for example, 7-JUL-21 09:15

Data Fields Comments and Key Points

Given that a function of the baseline information contained in the data fields of a component is to enable discovery of additional sources of information about that component, such as vulnerabilities, the document acknowledges some inherent gaps and issues.

The supplier name and component name may or may not be leveraged to uniquely identify a component, as there are likely multiple versions in use. For example, Microsoft Windows 10 could also be referred to as MS Win 10. This is not a shortcoming of the SBOM, but rather a longstanding problem in the world of software. The document recommends that the naming task be left up to “A decentralized model, where suppliers identify and manage their own software namespace…”. The negative consequences of this approach are illustrated in the monumental effort needed to manually search and match component information with Common Platform Enumeration (CPE) information.

In addition, the document acknowledges that the dependency relationship information will be challenging to collect and include, due to “…existing requirements with subcomponent suppliers.” Eventually, as SBOM becomes integrated into the software supply chain, subcomponent information will be available. At the outset, however, depth beyond the top-level components is not likely. In this case, the document recommends that the SBOM identify these “known unknowns” to differentiate between components for which no dependencies exist and those for which the dependencies are unknown.

Automation Support

There are three data formats suggested as standards to support the generation and consumption of the SBOM:

  • Software Package Data eXchange (SPDX)
  • CycloneDX
  • Software Identification (SWID) tags

According to the document, “The SBOM must be conveyed across organizational boundaries in one of these formats.”

Practices and Processes

To integrate the SBOM into a secure software development lifecycle, the document calls out a number of elements that organizations will need to address.

Frequency – at a minimum, new software builds, or releases require that a new SBOM be created. In addition, new information about components or errors in existing SBOMs can also trigger the creation of a new SBOM.

Depth – an SBOM should contain all primary (top-level) components with their dependent components, but an SBOM must contain primary (top-level) components with enough detail to “…seek out the transitive dependencies recursively.” This statement is another acknowledgement of the problem of including dependency relationship as a baseline data field.

Known Unknowns – the SBOM author must explicitly include information in the dependency relationship field to indicate that either there are no further dependencies for the given component or the dependencies for the given component are unknown. IMPORTANT NOTE – “To avoid erroneous assumptions, the default interpretation of the data should be that the data is incomplete…”

Distribution and Delivery – the SBOM should be made available in a timely fashion, and appropriate access permissions must be in place to protect the contents of the SBOM. The document suggests that the distribution and delivery of the SBOM will not be a “one-size-fits-all” approach but acknowledges that SBOM producers must have a way to make them available to SBOM consumers.

Access Control – in the cases where access control is desired by the producers of the SBOM, the terms must be specified, however the details of this specification are “…outside the scope of this document”.

Accommodation of Mistakes – the document allows that the initial implementation of the SBOM will not be perfect, so consumers of the SBOM should be “…tolerant of the occasional incidental error.” SBOM producers should be encouraged to share updates and corrections to SBOMs “…without penalty when offered in good faith.” These updates or corrections should trigger the creation of a new SBOM, as mentioned in the Frequency discussion above.

Beyond Minimum Elements

The document addresses additional inclusions that “…expand transparency in the software supply chain…”, however we will not detail those in this summary, except for the section on Vulnerabilities. It is recommended that the actual document be reviewed for additional details about the other sections.

Vulnerabilities and SBOM

The document acknowledges that the primary use case for SBOM is “…to identify known vulnerabilities and risks in the software supply chain.” The document then goes on to describe that the data contained in an SBOM is primarily static, while vulnerability information related to the SBOM data is dynamic. This seeming conflict, however, “…does not limit the value of providing vulnerability, software weaknesses, and risk information to the consumer of the software…”

Vulnerability and Exploitability in Dependencies

While it is true that not all sub-component vulnerabilities create risk in the component, as the document points out, this determination requires analysis by the SBOM producer to reach a reliable conclusion regarding vulnerability impact. To avoid unnecessary concern from the SBOM consumer, the SBOM producer should have an efficient way to communicate the vulnerability impact. The document refers to the term Vulnerability Exploitability eXchange (VEX) as the “…communication of whether or not a given piece of software is affected by a given vulnerability.” The document recommends including this VEX information in the SBOM analysis.

Summary

“Ultimately, SBOM should not be seen as a unique security phenomenon, but yet another practice that can support the broader effort to secure the supply chain.”  In keeping with Executive Order 14028, The Minimum Elements for a Software Bill of Materials (SBOM) provides input to the next step of developing specific SBOM guidance. It is recommended that the “…Federal Government should encourage or develop resources on how to implement SBOMs, potentially involving sector-specific or technology-specific details.”

Clearly, the SBOM ecosystem is continuing to evolve, but it is encouraging that the Federal Government decided to act now versus waiting to get it perfected.

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: inquiries@vigilant-ops.com

Ken Zalevsky
ken.zalevsky@vigilant-ops.com
412-704-4600

NIST Workshop on Supply Chain Security

On May 12, 2021 President Biden signed the Executive Order on Improving the Nation’s Cybersecurity, which we previewed in a recent post, into law. The fifteen-page document includes various cybersecurity enhancement recommendations such as the Software Bill of Materials (SBOM) and review and revision of governmental procedures, such as the Federal Acquisition Regulation (FAR), all with associated timelines for completion.