NIS2 and Software Engineering

Last week I watched a presentation about the new European directive about Network and Information Security 2 (NIS2). The essence of this presentation was that current regulations are still not sufficient enough to make companies resilient against cyber security threats.

The current trend is that cyber security criminals (e.g. mostly ransomware groups) are professionalizing rapidly, and are able to more efficiently abuse security problems in their business practices to extract money from European businesses. The European Union aims to solve this problem, by enforcing NIS2 in more (vital) branches, with bigger fines and more oversight.

Cyber security for a company consists of many different (but equally important) facets, such as:

• Awareness campaigns of phishing, fraud etc.
• Account management (2FA, on boarding, off boarding etc.).
• Knowing which hardware & software you run.
• Data management & privacy regulations.
• Insights in threats and intrusions.

When you look at this list, you can see a mix of organizational, regulatory and technical aspects which need to be covered. Especially knowing what software you run (and does it have any known vulnerabilities, does it comply with privacy regulations?) is a question which often ends up unanswered or with a wrong conclusion.

One of the key takeaways from the ONE Cyber-conference [1] this year was that there is a big disconnect between the regulatory side of a business, and the technical side. A company can implement new business processes (such as 2FA or e-mail forwarding monitoring) to improve security, but they often have no clue about the software they are running (or if its compliant or vulnerable).

Below I will deep dive in one of those things which can help: how software engineering can help aid cyber security efforts with the use of SBOM's.

Software Bill of Materials (SBOM)

To help both the organizational and regulatory parties, software engineering can help cyber security efforts, with the following concept: SBOM's.

Every product in the supermarket has a list of ingredients what it is made of. To identify security vulnerabilities in software engineering, we can use the same concept, which is called a Software Bill of Material (SBOM). Software is often made of various third party libraries. These libraries often contain security fixes which are reported through the Common Vulnerabilities and Exposures (CVE) database.

Currently its very difficult for customers of software products to determine the security impact of all these CVE's. Is this product affected? Does it even contain the library in question? This is where a SBOM can help IT Auditors / SOC's and Cyber security officers to identify problems before they are exploited. Using a common format for SBOM's can also help to automate this work in a SOC, to alert staff before its too late. By providing an SBOM with your software product, you will provide transparency and insight on third party library vulnerabilities.

As a side note: SBOM's will not fix all security problems; vulnerabilities such as zero-days or vulnerable code that was written in-house might not be reported in the CVE database, thus might not be identified. SBOM's will help greatly to identify publicly known security vulnerabilities in libraries (and thus the software that you are using).

Using Trivy to identify third party security risks

Various open-source tools already exist to scan your software projects for known security vulnerabilities (using the CVE database). Tools such as OWASP Dependency Check [2], Trivy [3], Snyk [4] all work with the same principle:

1. Extract SBOM from the source code.
2. Match third party dependencies with reported CVE issues.
3. Generate report with security issues.

My favorite tool (as someone working mainly with Java, NPM and Docker) is Trivy. Trivy is as simple as installing it, pointing it at the source code and the results are generated:

maikel:~/git/music-indexer$ trivy fs .
2022-10-29T12:30:42.098+0200	INFO	Vulnerability scanning is enabled
2022-10-29T12:30:42.098+0200	INFO	Secret scanning is enabled
pom.xml (pom)

Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 1, CRITICAL: 0)

┌───────────────────────┬────────────────┬──────────┬───────────────────┬───────────────┬──────────────────┐
│Library                │ Vulnerability  │ Severity │ Installed Version │ Fixed Version │ Title            │
├───────────────────────┼────────────────┼──────────┼───────────────────┼───────────────┼───----───────────┤
│ com.fa:woodstox-core  │ CVE-2022-40151 │ HIGH     │ 6.2.3             │ 5.4.0, 6.4.0  │ Xstream to seria.│
│                       │                │          │                   │               │                  │
....

Trivy has wide support for many package managers (Maven, docker, NPM, Ruby, Python, Go [5]).

Note that when a CVE is reported, it does not automatically mean that your software is vulnerable. Often there are specific scenarios which need to be used before the security issue can be abused. But other times, a CVE can have a very low attack complexity (Log4Shell for example, hence it was quite a big deal).

I also experimented with Dependency Check from OWASP, but found it quite cumbersome to setup and did not suffice my needs. OWASP Dependency Check can only scan source code, and not docker containers. Identifying security issues in the OS (docker container) can be just as important, because of things like OpenSSL.

Using Trivy to generate SBOM's

There also exist various tools to generate SBOM's for your software project. Trivy has it built in, and OWASP has released another tool called Dependency Track [6].

The NIS2 directive will probably cause a lot more questions from your customers about which third party libraries your software product is using. In order to standardize this process, OWASP has created the CycloneDX [7] standard.

Generating an SBOM with the CycloneDX standard is as simple as:

maikel:~/git/music-indexer$ trivy fs --format cyclonedx .

This generates a JSON file, where a dependency to spring-boot looks like:

{
      "bom-ref": "pkg:maven/org.springframework.boot/spring-boot@2.7.5",
      "type": "library",
      "name": "org.springframework.boot:spring-boot",
      "version": "2.7.5",
      "purl": "pkg:maven/org.springframework.boot/spring-boot@2.7.5",
      "properties": [
        {
          "name": "aquasecurity:trivy:PkgType",
          "value": "pom"
        }
      ]
    },

This SBOM can be used by the customer (or our ourselves) to match this to reported CVE's in these libraries.

Incorporating the generation of the SBOM should become part of your release pipeline. This would help both the customer with NIS2, and yourself to identify future security problems.

Some final thoughts

As more and more security issues are getting disclosed, it becomes more important to identify and resolve these security issues during the software development lifecycle. The further down the road, the more expensive it gets to resolve these kind of issues.

Tools to generate SBOM's and identify third party library security risks are vital in creating a secure software product & environment. But introducing SBOM's, is only one of the things we need to do to help in cyber security.

• On a software engineering level it is also important to realize security vulnerabilities might exist in your in-house created source code.
• On a company level, there are many other aspects that are also relevant to become cyber resilient.

I have been using Trivy extensively for about a year now, and has helped with identifying various security issues in Java as well as in the infrastructure. In combination with a custom notifier, we are the first ones to know of a new CVE in a library what we use.

[1] https://one-conference.nl/
[2] https://owasp.org/www-project-dependency-check/
[3] https://aquasecurity.github.io/trivy/
[4] https://snyk.io/
[5] https://aquasecurity.github.io/trivy/v0.20.2/vulnerability/detection/language/
[6] https://owasp.org/www-project-dependency-track/
[7] https://cyclonedx.org/