Vulnogram 0.0.5 is now available on Vulnogram github site. "Making the world safer one CVE ID at a time" - Vulnogram project aims to make it easier for product vendors and security researchers to accurately record security vulnerability information for inclusion in the CVE List. Version 0.0.5 includes bug fixes, improvements and major code refactoring.
Mar 22, 2019
Feb 19, 2019
Software Bill of Materials and Software Lifecycle
How does one go about generating SBoMs?
Software products start as ideas and concepts. Software development vendors (aka suppliers) transform these ideas by adding or removing "material" until a final desired product is created. Consumers obtain these products and may further transform them to suit their needs. As a product is being used, users and suppliers find problems or get ideas for improvements. Products are then improved through the iterative cycle called software lifecycle.
|Software Bill of Materials and Software Lifecycle|
Information that goes into SBoMs can be best obtained from the tools and processes used in each stage of a the software lifecycle. One may have to leverage or enhance existing tools and processes to generate SBoMs. Such tools include intellectual property review, procurement review and license management workflow tools, code scanners, pre-processors, code generators, source code management systems, version control systems, compilers, build tools, continuous integration systems, packagers, compliance test suites, package distribution repositories and app stores.
Many of the currently available tools may not have the capability to generate SBoMs as a byproduct as they handle material that goes into making a product. Suppliers should consider enhancing or retrofitting existing tools and processes to generate and maintain SBoMs. It may be impractical to retroactively generate complete SBoMs for older or existing products. SBoM can be considered incomplete if some information about the materials added or removed through the stages of software lifecycle is missing or was never recorded. If the SBoMs are incomplete, suppliers should make it clear so that consumers can make informed use of SBoMs based on the available data.
Jan 26, 2019
Content of Cybersecurity Bill of Materials (CBOM) or Software Bill of Materials (SBoM)
US Food and Drug Administration (FDA) is conducting a two day workshop on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices on January 29th and 30th.
US National Telecommunications and Information Administration has been facilitating a discussion on Software Bill of Materials as a part of its Software Component Transparency policy development effort.
A question on the table for both of these efforts is what exactly should a Bill of Materials
The basic presumption here is that when you get a blackbox which could be a medical device, or some app, or a software, or a cloud service, or a hi-tech gadget, having a list of technical ingredients that went into making that blackbox may help make it transparent, trustable, and mange its cyber security or privacy risks. The list of ingredients is called a Bill of Materials or a BoM or SBoM (Software BoM) or CBoM (Cybersecurity BoM).
What is a "material" in a Bill of Materials?
A material is anything that would affect the content, properties and functionality of the blackbox in question. In other words anything that "matters" to the risks associated with a blackbox. A risky material (such as tainted license, insecure code, patent infringement, privacy violation) is likely to make the end product risky to consumers. The risk may not always be transitive.
As a simple example, suppose there is a software application helloworld.exe. It was made using source code helloworld.c, a Makefile that tells how to build the software and make 3.4 command and GCC compiler 1.2.3. The Bill of Materials for helloworld.exe would look like:
GCC Compiler 1.2.3
How does such a bill of material (BoM) allow us to identify cybersecurity risks?
Let us assume that the GCC compiler 1.2.3 was infected with a malware that added a backdoor to every executable it created. Now by knowing that helloworld.exe was compiled with this infected compiler one can identify it as a backdoor risk in our IT assets.
What other information should a Bill of Material contain?
At the minimum a bill of material should contain some way to identify every material that is being listed. This may be also known as key, locator or ID information. Since there are multiple identifying schemes (also known as domains, namespaces) in the real world, we need one field to encode the namespace, and one field to encode the name (id, key, locator) that is valid within the namespace.
1) Namespace: "commonly known as", Name: "OpenSSL 1.1.1a"
2) Namespace: "cpe", Name: "cpe:2.3:a:openssl:openssl:1.1.1a:*:*:*:*:*:*:*"
3) Namespace: "purl", Name: "pkg:email@example.com"
4) Namespace: "sha-1", Name: "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15"
5) Namespace: "iTunes", Name: "us/app/vlc-for-mobile/id650377962#?platform=ipad"
6) Namespace: "GooglePlay", Name: "org.videolan.vlc"
6) Namespace: "github", Name: "openssl/openssl/releases/tag/OpenSSL_1_1_1a"
7) Namespace: "uspto", Name: "US7046802B2"
8) Namespace: "spdxid", Name: "SPDXID-12345678"
9) Namespace: "ietf", Name: "RFC8446"
A single software entity may have multiple namespace-name tuples associated with it.
Different use cases need different metadata or SBoM content associated with the software entity as illustrated below:
|SBoM/CBoM Content Analysis based on use cases.|
For eg., if the use case is to block software from suppliers that US government thinks are national security threats you would need the names of suppliers of every software entity in the product, but may not care about other fields.
If the use case is to check licenses to answer "am I entitled to use this for commercial purposes?", one needs to know the name or type of licenses included with the software, but may not care about the version numbers.
The things in dotted line bubbles are vaporware (may or may not exist).
For eg., if there was a precise and complete mapping of software entity identifiers to vulnerabilities, we would not need any other fields in the SBoM at all for vulnerability analysis cyber security risk management use case.
Almost all use cases of SBoMs follow a pattern of checking against a "no-fly-list" or a database that maps different risk types to software.
Jan 20, 2019
Vulnerability Disclosure Tiers
Vulnerability disclosure often happens in a cascading manner - from one person who discovers it to the public Internet. While everyone agrees that vulnerabilities need to be eventually disclosed in some form, (1) content (2) audience and (3) timing (C A T) of disclosure is often a topic of contention and discontent. There is a hope that if we take out subjectivity from disclosure C A T, vulnerability disclosures can be less painful, especially for critical vulnerabilities.
Audience should be selected based on their role, and if they play by the rules of disclosure. It may not matter if they work for the same organization or not. Same individuals/teams may perform two or three roles. An incident responder may identify the audience and facilitate the flow the contents between tiers.
Tier 0 - incident responders, vulnerability researcher
Content: Nothing → vulnerability report, PoC (Proof of Concept)
Tier 1 - inventors, architects and designersContent: vulnerability report, PoC → well defined problem statement, root cause, solutions, PoC
Tier 2 - implementors, developersContent: problem, root cause, solutions, PoC → problem, root cause, solutions, PoC, fix
Tier 3 - replicators, validators, pentestersContent: problem, root cause, solution, PoC, fix → problem, solution, fix, recurrence prevention, conformance tests, workarounds, attack vectors
Tier 4 - integrators, large could/service operators, managed products, managed on premises deploymentsContent: problem, risk, solution, fix, workarounds → feedback
Tier 5 - defenders, mitigatorsContent: problem, attack vectors → problem, attack vectors, detection, prevention
Tier 6 - administrators, operatorsContent: problem, risk, solution, fix, workarounds → feedback
Tier 7 - public, anyone who would not play by the rules.Content: problem, attack vectors, risk, solution, fix, workarounds, detection, prevention.
Jan 3, 2019
Vulnogram - Making the world safer one CVE ID at a time, since 2017.
More than a year ago I published a tool named Vulnogram for creating and editing CVE information in JSON format. JSON is one of the preferred format for exchanging CVE ID assignment information for vulnerabilities.
The name Vulnogram is inspired from Greek origin suffix '-gram' which is used for denoting something written or recorded especially in a certain way. Vulnerability related information when recorded in a standard format can help in aggregation, curation, dissemination, analysis and remediation. This enables automation and efficiency in response activities.
Vulnogram project aims to make it easier for vendors and security researchers to accurately record vulnerability information for inclusion in the CVE List. In other words sharing vulnerability related information should be as easy posting on Instagram!
Vulnogram online edition is accessible at https://vulnogram.github.io/
The code for Vulnogram is hosted on github https://github.com/Vulnogram/Vulnogram
Subscribe to: Posts (Atom)