DEV Community: Víctor Jiménez Cerrada

5 Reasons Why IT Security Tools Fall Short To Secure the Industry

Víctor Jiménez Cerrada — Tue, 29 Oct 2024 13:43:17 +0000

Operational Technology (OT) is often treated as a subset of IT. After all, the devices that control an industrial facility are just different flavors of computers, but computers, after all. However, in practice, they present some specific challenges that separate them from regular IT deployments.

Using regular IT tools in OT environments leaves teams poorly equipped. They will take longer to perform some maintenance tasks or be unable to identify some security threats.

We’ll explore four factors that differentiate OT from IT, and discuss why OT Security needs specific tools.

OT is Mission-Critical

While stopping any IT infrastructure will considerably impact any business, as the Crowdstrike incident recently reminded us, in OT the impact is bigger by several orders of magnitude.

If a part of a factory stops it will affect the whole production line, dozens of workers will become idle, and it may take several hours to get back online.

While in IT it is relatively cheap to set up a high-availability system or spin up a mirror infrastructure, setting up a backup production line for OT takes too long (up to several months) and is too expensive to have it sitting idle just in case.

Security tools for OT must be especially accurate when alerting. A false positive that would cause you to shut down a facility is a very expensive luxury.

OT has a Physical Plane

Critical equipment inside an office is mostly gathered and locked in a single server room. In comparison, critical equipment in an industrial facility, like PLCs, is widely distributed across the plant.

Knowing the physical location of a device becomes essential in OT to speed up maintenance tasks.

We live in a post-industry digitalization era, ours is the industry 4.0. As a result, there is a myriad of devices and sensors across a production line. All those devices are gathering critical data that must be secured on the devices, and in transit to the central servers to ensure compliance.

OT security tools must support engineers and technicians beyond their control rooms, and into the factory floor.

Management of OT devices is different

Although PLCs are way simpler than regular computers, they have little in common when securing them.

PLC firmware, although simple, has vulnerabilities too, and needs to be kept up to date. We are used to computers upgrading automatically at a given time window, but for PLCs, you need a separate computer to perform a firmware update. You’ll also want to carefully plan the upgrade process across a whole facility to ensure everything keeps working smoothly.

The software running inside a PLC also needs special treatment. Let’s take the Stuxnet worm as an example. It targeted PLCs, changing their programs to destroy the industrial equipment connected to them. To protect against this kind of threat you need, besides a strong real-time detection, a registry of the changes made to your PLCs software, as well as keeping a backup copy of the software.

Finally, there are differences in who performs equipment maintenance. While in an IT environment, the IT team is responsible for all the maintenance tasks, it’s quite common that manufacturers perform some level of maintenance in industrial equipment. Nowadays some of this maintenance is performed remotely, adding yet another entry point to secure.

A security tool specially crafted for OT will bake these idiosyncrasies into its core, offering relevant help instead of “just being there”.

OT has Specific Relevant Context

IT security is designed for computers with full operating systems, where you can install a probe and gather all kinds of data. However, PLCs are too simple for Host-based Intrusion Detection Systems (HIDS).

Instead, with PLCs you follow a black-box approach, observing from the outside and relying on diagnostics information. A security tool for OT must be able to speak the equipment language, across several brands, to retrieve this relevant diagnostics data across all your devices.

You must also consider the device’s status. Is the device offline? Are you running a test in that production line? A vulnerability doesn’t have the same impact if it affects a production device as a mostly offline one. Some alerts that would be critical during production are to be expected while running some tests.

Finally, inventory is vital. Compared to a tight-sealed environment, it’s easier to deploy a malicious device that goes unnoticed in an industrial environment. You cannot trust manual inventories, you need automatic discovery.

Industry has its own regulations

Many general purpose security applies to industry environments, like ISO 27001, the European NIS 2, or the Spanish ENS.

In addition, the industry has its own security models like Purdue, or standards like TISAX.

Supporting these standards and regulations is a must for OT security tools.

Using the Right Tools Gives You Superpowers

When you start using a security tool specifically crafted for OT in your industrial environment, you soon realize everything is easier.

You have the information you need right away, so you perform maintenance tasks faster.

You detect more relevant threats while getting less noise.

You’ll be able to investigate security incidents with more detail, as you’ll be able to correlate relevant insights.

It will feel like you just lifted the handbrake.

Automating Vulnerability Detection for Your Assets

Víctor Jiménez Cerrada — Tue, 15 Oct 2024 15:48:55 +0000

Discover how to automate vulnerability detection of your assets, so you can shift left security and protect your infrastructure before a vulnerability becomes a security incident.

In this article, we’ll cover how to query the NIST vulnerability database, create a CPE Name for a resource, and automate the fetching of vulnerabilities with a script.

Vulnerabilities as an Attack Vector

Software developers aren’t perfect; sometimes their code misses an edge case that makes your infrastructure vulnerable.

Let’s take the Apple goto fail vulnerability in 2016, a single duplicated line enabled man-in-the-middle attacks on SSL communications involving Apple devices:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail; // This executes outside the if

These errors are common and silly, but still dangerous; moreover, as code gets more complex, and as more resources you have, the bigger your surface attack. That’s why it’s so important to install security updates.

Vulnerabilities are your backdoor and can provide access in many ways. Allowing attackers to disrupt your service, obtain information about your infrastructure (so they can exploit other vulnerabilities), and in the worst cases, execute code that ends on a remote control. Once they are in, attackers can move laterally to other resources, accessing or encrypting your business data, using your resources for crypto mining, or altering your production line ever so slightly so you don’t notice but enough so production fails.

Nowadays attacks tend to start as automated processes executed by botnets that look for vulnerable services and automatically hack them.

We often aren’t aware of how much information our services share, like a web server that shares its version number. It didn’t take long for me to find a public web server like that:

$ curl -I https://▋▋▋.▋▋▋▋▋▋▋▋▋.net
HTTP/2 301
server: nginx/1.18.0 (Ubuntu) ← ⚠️
date: Fri, 04 Oct 2024 08:57:20 GMT
content-type: text/html
content-length: 178
location: https://▋▋▋.▋▋▋▋▋▋▋▋▋.net/home/

We know this server is using server: nginx/1.18.0 (Ubuntu), we can look for vulnerabilities affecting this software and launch an attack.

Querying for Vulnerabilities in Your Device

Where can you search for the vulnerabilities in a given software? In a vulnerability database (ba dum tss).

When a vulnerability is found, it is classified under the Common Vulnerabilities and Exposures (CVE) system. This system standardizes naming vulnerabilities (CVE-YEAR-ID) and presenting relative information (description, metrics, etc.).

Some organizations such as NIST NVD maintain CVE databases, where people can learn how to mitigate them.

This database has a search tool that allows you to search by software and version. You only need to format it in a CPE (Common Platform Enumeration), a structured naming scheme for information technology systems, software, and packages.

When in doubt about what is the correct CPE for your resource, you can always ask Google:

For the nginx service from the example earlier, the CPE would be cpe:2.3:a:f5:nginx:1.18.0:*:*:*:*:*:*:*.

Entering this string on the search tool:

Throws three high-severity vulnerabilities that could be used to impact that web server:

Getting closer to an industrial setup, we’ll take a Siemens ‘SIMATIC S7-1500’ PLC as an example:

This concrete PLC has a 0.5.1 firmware version, so its CPE would be cpe:2.3:o:siemens:simatic_s7-1500_cpu_firmware:0.5.1:*:*:*:*:*:*:*.

Querying the NIST database, we see 13 vulnerabilities:

Nice! Now we can go through this list and apply mitigation actions where needed.

Querying the NIST NVD API

However, repeating this process for each resource at a time is time-wasting, and directly not feasible when we have hundreds of devices.

Luckily, NIST offers an API to query this database and automate this vulnerability discovery process.

Using the API is incredibly simple. We could perform the same queries we did before in the command line with a program like curl:

$ curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:f5:nginx:1.18.0" > nginx-1-18-0.json
$ curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:o:siemens:simatic_s7-1500_cpu_firmware:0.5.1" > simatic_s7-1500.json

The response is a rather intuitive and comprehensive JSON payload:

$ cat "nginx-1-18-0.json" | jq .
{
  "resultsPerPage": 3,
  "startIndex": 0,
  "totalResults": 3,
  "format": "NVD_CVE",
  "version": "2.0",
  "timestamp": "2024-10-07T10:47:05.540",
  "vulnerabilities": [
    {
      "cve": {
        "id": "CVE-2021-23017",
        "sourceIdentifier": "f5sirt@f5.com",
        "published": "2021-06-01T13:15:07.853",
        "lastModified": "2023-11-07T03:30:29.880",
        "vulnStatus": "Modified",
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "A security issue in nginx resolver was identified, which might allow an attacker who is able to forge UDP packets from the DNS server to cause 1-byte memory overwrite, resulting in worker process crash or potential other impact."
          },
…

You can code these HTTP calls and response processing with the language of your choice, and integrate them with whatever tools integrates best with your workflow. We’ll see a couple of examples in a bit.

Only a final piece of the puzzle is missing, obtaining an API Key.

NIST limits the number of requests that unregistered users can perform. If you are going to use this API in any serious way, you should request an API Key to lift these restrictions. The process is straightforward, you only need to fill out and submit a simple form, and click a link from an email you’ll receive.

Once you obtain your API Key, you can provide it via an apiKey HTTP header. In curl, this is done with the -H param:

$ curl -H "apiKey: YOUR-API-KEY-HERE" "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:f5:nginx:1.18.0"

Automating Vulnerability Detection on a Spreadsheet

Many people keep their asset inventory on a spreadsheet. So let’s see how to integrate the NIST NVD API inside Google Sheets.

[!NOTE]
This approach is not recommended, we are displaying it only for educational purposes and because it is fun. Main disadvantages are: You cannot include an apiKey, it is taxing on the API backend, and it doesn’t provide a good user experience. We provide a proper option on the next section.

We start with a simple spreadsheet that contains all the basic information from our assets:

The plan will be to:

Generate the CPE for each device.
Call the API for each resource.
Extract the CVE numbers from the payload.

Let’s get started!

1. Generating CPEs

The first step is to generate the CPE for each device, which can be easily done by concatenating the already available information:

="cpe:2.3:" & F2 & ":" & B2 & ":" & C2 & ":" & D2

We added the text cpe:2.3 and the CPE part at the beginning. The CEP part describes the type of resource: a for applications, h for Hardware, and o for Operating Systems.

2. Calling the API

Google Sheets has functions to import and process several types of data such as XML or CSV. However, it lacks support for the JSON that the NIST API returns. There are third-party solutions for that, but keeping things simple, we’ll get creative and use only the default functions.

The IMPORTDATA(url, delimiter, locale) function can load data from a url, separating data rows by new lines, and columns by the delimiter character. Would this work for us?

We could use this function to load the whole payload in a single cell, and then extract the data. Keep in mind that the API returns a minified JSON, that is without extra spaces or line breaks, we used jq earlier to prettify the output.

=IMPORTDATA("[https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=](https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=)" & Inventory!E2,"Ç")

In this example, Inventory!E2 is the CPE we calculated earlier, and we are using a strange character as a delimiter (“Ç” ) so the data is not split in columns and stays in the same cell.

The output? Error: Result too large. It looks like the payload is too big for a single cell, we’ll have to look for a way to split it into smaller chunks.

Looking closer at the JSON payload from the API we can identify some useful patterns:

…
  "vulnerabilities": [
    {
      "cve": {
        "id": "CVE-2021-23017",
        "sourceIdentifier": "f5sirt@f5.com",
…

Every CVE number is preceded by the string "cve": { "id": "CVE . We could:

Split the payload in columns by the { character.
Keep only those that start with "id": "CVE-.

This would be the formula:

=TRANSPOSE(
    QUERY(
      TRANSPOSE(
        IMPORTDATA("https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=" & Inventory!E2,"{")
      ), 'HELPER - Query'!$A$1))

Where:

QUERY Allow us to run SQL queries on a dataset.
TRANSPOSE Is used to turn rows into columns so we can evaluate the query for each value. After the query, it is used again to turn the result into a single row afterward.
'HELPER - Query'!$A$1 is a reference to the cell containing the query: SELECT * WHERE Col1 contains ':"CVE-'. Google Sheets doesn’t like the " inside the query, but it seems fine if we move the query to a different cell ¯\(ツ)/¯.

Will this work?

Let’s drop this formula on a separate sheet of our inventory spreadsheet and see:

Indeed! It works!

3. Extracting the CVE number

We are close, we have each CVE number on a separate cell and we only need to extract it.

My first thought was to tweak the SELECT * on the SQL query, trying to return only a substring instead of the whole field. That way all the processing would be contained in one place. However, the SQL language in Google Sheets has a very limited function set and this approach is a no-go.

We’ll keep the current results as they are on a separate sheet HELPER - RAW_CVEs, acting as a helper to display the clean CVE numbers in another place.

We can leverage the function REGEXEXTRACT to extract only the CVE number using regular expressions:

=REGEXEXTRACT('HELPER - RAW_CVEs'!A1,"CVE-\d*-\d*")

We could clean up things a bit, using HYPERLINK to drive the user to the NIST website for that CVE, and other functions to filter out errors.>

=IF(
  NOT(ISBLANK('HELPER - RAW_CVEs'!A1)),
  HYPERLINK(
    "https://nvd.nist.gov/vuln/detail/" & REGEXEXTRACT('HELPER - RAW_CVEs'!A1,"CVE-\d*-\d*"),
    REGEXEXTRACT('HELPER - RAW_CVEs'!A1,"CVE-\d*-\d*")
  ),
  ""
)

The result is gorgeous!

Our example spreadsheet is available if you want to see it in action.

[!NOTE]
This approach is not recommended, we are displaying it only for educational purposes and because it is fun. Main disadvantages are: You cannot include an apiKey, it is taxing on the API backend, and it doesn’t provide a good user experience. Check out a proper option on the next section.

Automating Vulnerability Detection With Python {#python}

Let’s see how to do something similar with a proper programming language like Python.

Although our example is gonna be radically simple, this solution has huge potential for improvement. For example, you could expand it to integrate with your tools, program it to run periodically or send notifications via email.

Our example will cover:

Receive a .cvslist of resources. (i.e. Exported from a spreadsheet).
Call the API to fetch vulnerabilities.
Output a list of vulnerabilities in JSON format.

Let’s take a look at the code in our vuln_finder.pyscript. You can also find the whole code and example data files in our GitHub repository.

1. Reading the resource list

We’ll use a few modules on our script:

argparseto read command line options.
requeststo perform the API calls.
csvto read the resource list.
jsonto write our output.

The first step will be to read the user options:

import argparse
import requests
import csv
import json

#
# Parsing arguments
parser = argparse.ArgumentParser()
parser.add_argument("-d", "--devices", default = "inventory.csv", help = "Devices file in csv format. Default: inventory.csv.")
parser.add_argument("-o", "--output",  default = "output.json", help = "Output file where to store the json response. Default: output.json.")
parser.add_argument("-k", "--apikey", required=True, help = "NIST NVD API Key.")
args = parser.parse_args()
#
devices_csv = args.devices
output_file = args.output
apikey = args.apikey

And then, we’ll read the device list csv, and generate the CPE name from there:

#
# Reading devices file
inventory = []
with open(devices_csv, newline='') as csvfile:
    inventoryreader = csv.reader(csvfile, delimiter=',', quotechar='"')
    for row in inventoryreader:
        device = {}
        device['name'] = row[0]
        device['vendor'] = row[1]
        device['software'] = row[2]
        device['version'] = row[3]
        device['part'] = row[4]
        device['cpe'] = "cpe:2.3:" + device['part'] + ":" + device['vendor'] + ":" + device['software'] + ":" + device['version']
        device["cves"] = []
        inventory.append(device)

2. Calling the API

Now, for every device in our inventory, we call the API. The response module makes it really simple to send this request with the apiKey header.

We use request.get(url, headers) to make the API call.
We use response.json() to get a dictionary with the JSON Payload.
We fetch the data we want from that dictionary.

#
# Calling JSON API for each device
data = []
for device in inventory:
    # The API endpoint
    url = "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=" + device['cpe']

    # Send a GET request to the API
    response = requests.get(url, headers={"apiKey": apikey})
    # Process the response
    vulnerabilities = response.json()["vulnerabilities"]
    for vulnerability in vulnerabilities:
        cve = {}
        cve["id"] = vulnerability["cve"]["id"]
        cve["url"] = "url: https://nvd.nist.gov/vuln/detail/" + cve["id"]
        # Try to grab CVSS Score v3.1
        if "metrics" in vulnerability["cve"] and "cvssMetricV31" in vulnerability["cve"]["metrics"]:
            cve["baseScore"] = vulnerability["cve"]["metrics"]["cvssMetricV31"][0]["cvssData"]["baseScore"]
            cve["baseSeverity"] = vulnerability["cve"]["metrics"]["cvssMetricV31"][0]["cvssData"]["baseSeverity"]
        device["cves"].append(cve)
    #
    data.append(device)

We have to dig into several dictionaries to reach the data we want:

vulnerability["cve"]["id"]
vulnerability["cve"]["metrics"]["cvssMetricV31"][0]["cvssData"]["baseScore"]
vulnerability["cve"]["metrics"]["cvssMetricV31"][0]["cvssData"]["baseSeverity"]

We kept things simple for this example, but keep in mind that the NIST NVD payload is quite comprehensive, so there’s lots of insightful information you could fetch here.

3. Outputting the data

Finally, we write the data into a JSON file:

#
# Output the result
with open(output_file, 'w') as f:
    json.dump(data, f)

Here is where we could cache the data, send notifications, and in general, do some kind of intelligence with the data we fetched.

Testing the script

Let’s take our script for a ride.

Here is the inventory.cvs we’ll provide:

Nginx Web Server,f5,nginx,1.18.0,a
SIMATIC S7-1500,siemens,simatic_s7-1500_cpu_firmware,0.5.1,o

We’ll run the script like:

$ python vuln_finder.py -d inventory.csv -o output.json -k THE-API-KEY

And we obtain an output file like:

$ cat output.json | jq .
[
  {
    "name": "Nginx Web Server",
    "vendor": "f5",
    "software": "nginx",
    "version": "1.18.0",
    "part": "a",
    "cpe": "cpe:2.3:a:f5:nginx:1.18.0",
    "cves": [
      {
        "id": "CVE-2021-23017",
        "url": "url: https://nvd.nist.gov/vuln/detail/CVE-2021-23017",
        "baseScore": 7.7,
        "baseSeverity": "HIGH"
      },
      {
        "id": "CVE-2021-3618",
        "url": "url: https://nvd.nist.gov/vuln/detail/CVE-2021-3618",
        "baseScore": 7.4,
        "baseSeverity": "HIGH"
      },
      {
        "id": "CVE-2023-44487",
        "url": "url: https://nvd.nist.gov/vuln/detail/CVE-2023-44487",
        "baseScore": 7.5,
        "baseSeverity": "HIGH"
      }
    ]
  },
  {
    "name": "SIMATIC S7-1500",
    "vendor": "siemens",
    "software": "simatic_s7-1500_cpu_firmware",
    "version": "0.5.1",
    "part": "o",
    "cpe": "cpe:2.3:o:siemens:simatic_s7-1500_cpu_firmware:0.5.1",
    "cves": [
      {
…

Great! It Works!

[!NOTE]
If you want to learn more, or try this yourself, check the whole code in our GitHub repository.

Next Steps: Automation and Correlation, the base for OTSPM

We’ve seen how easy it is to automate vulnerability discovery by querying vulnerability databases’ APIs. Where to go next from here?

The trends in cybersecurity are:

Automation of all manual tasks to avoid human errors, and provide always up-to-date information.
Correlation of data gathered from several sources to detect more threats.

Let’s take automating inventory as an example.

Keeping an inventory in a spreadsheet seems easy. However, what happens if a malicious device or service is added? How long it will take you to detect it?

If you continuously scan your infrastructure to keep an updated picture of your infrastructure, you can perform some nice correlations:

New resources over real-time security alerts: “Someone accessed a suspicious URL at the same time this new device was added.”
State of the resources over vulnerability discovery: “This device has a critical vulnerability, but it’s a test machine that is off. We can prioritize other alerts over this one.”
State of the resources over compliance: “A recent configuration change in this server has made it fall out of compliance.”

Keep this in mind whether you build your own security solutions or use a vendor product, security has proved to be more effective when treated as a single solution, where any information may be useful at any given stage.

Conclusion

Vulnerability databases help you discover where are you vulnerable and take mitigation actions.

You can automate this discovery process by integrating your inventory with their APIs, which is easily done in any popular programming language. You can even do this querying from a spreadsheet (although it is not recommended).

Finally, advancing on this automation journey will open you up to the possibility of correlating data from multiple sources, making your security solution more effective.

How will NIS2 affect European Industries

Víctor Jiménez Cerrada — Tue, 08 Oct 2024 13:13:23 +0000

The European NIS2 directive is coming to Europe to set a new high bar on the union's cybersecurity.

So far, the directive defines only a set of guidelines. State Members are expected to transpose it into local laws by October 17, then we’ll have more concrete details.

In this article, we’ll cover how it affects industrial environments with what we know so far.

Why is NIS2 Needed?

In recent years, we’ve seen an increasing adoption of technologies in every aspect of our lives. What used to be isolated is now connected, and we complement our personal computers with smartphones, smartwatches, smart TVs, and other smart devices.

Attackers have adapted to this new landscape. Cyberattacks rose by 57% in 2023 and the trend continues in 2024.

And more importantly, we’ve seen examples of attacks targeting essential infrastructure in the last years:

And also, the relationship between cyberattacks and warfare is clearer than ever with the current geopolitical situation in Europe.

With this in mind, the NIS2 directive aims to increase the cyber resilience of Europe and protect its essential services.

What Does the NIS2 Directive Look Like?

It won’t come as a surprise, but it’s a rather boring document expanding 60 pages and divided into 46 articles.

Most articles describe the new European security network and the framework the Member States need to implement. The requirements affecting businesses are mainly described in articles 21 and 23.

Section	Topic
Chapter 1 Articles 1-6	General provisions: Covers the scope of the directive and defines common terms.
Chapter 2 Articles 7-13	Coordinated cybersecurity frameworks: Lists the new entities each Member State needs to define.
Chapter 3 Articles 14-19	Coordination at union and international level: Defines the new entities that will be needed at a European level.
Chapter 4 Articles 20-25	Cybersecurity risk-management measures and reporting obligations: ⚠️ Provides a framework on what measures organizations will need to implement. Also covers how reporting of incidents will take place, and the communication flow between all entities.
Chapter 5 Articles 26-28	Jurisdiction and registration: Defines who is the authority each entity will respond to. Also adds some requirements for DNS providers, TLD registries and other hosting companies.
Chapter 6 Articles 29-30	Information sharing: Covers how Member States will communicate and coordinate to flag threats and raise security awareness.
Chapter 7 Articles 31-37	Supervision and enforcement: ⚠️ Lists how Member States will be able to audit the measures taken by entities and enforce proper implementation. Here, on article 34 is where the fines are defined.
Chapters 8 & 9 Articles 38-46	Delegated and implementing acts, and Final provisions.

As you may have noticed, the security requirements are just a small portion of the directive. A big chunk of it is dedicated to creating a dense network of entities that work together to monitor security incidents, supervise the implementation of security measures, and coordinate efforts to adapt to new threats.

This network can be split into three blocks. Here is a summarized description, please refer to the full directive to obtain the full context.

Every Member State must:

Transpose the directive into local laws by October 17th (2024), defining the specific requirements entities must comply with.
Define the competent authorities that will supervise and enforce the directive.
Define the CSIRTs (Computer Security Incident Response Teams) coordinating the vulnerability disclosures. They can be formed by competent authorities.
Name a single point of contact.

The Cooperation Group is:

Formed by representatives of Member States, the commission, and the European Union Agency for Cybersecurity (ENISA).
With the intervention of the European Supervisory Authorities (ESAs), the competent authorities, the European Parliament, and representatives of relevant stakeholders.

A CSIRTs Network will also be created:

To promote cooperation among Member States by exchanging information, ensuring interoperability, implementing coordinated responses…
It’s composed of representatives of the CSIRTs, the Commission as an observer, and assisted by ENISA.

Who is Affected by NIS2?

The following entities are affected by the NIS2 directive and will need to implement security requirements.

Medium and Big companies the following segments.

High criticality segments:

⚡️ Energy: Electricity, district heating and cooling, oil, gas, hydrogen.
🚅 Transport: Air, rail, water, road.
🏦 Banking.
📈 Financial market infrastructures.
🏥 Health.
💧 Drinking water.
🚱 Waste water.
💻 Digital infrastructure.
💁🏼 ICT service management (b2b).
🏢 Public administration.
🚀 Space.

Other critical sectors:

📨 Postal and courier services.
🚮 Waste management.
🧪 Manufacture production and distribution of chemicals.
🥘 Production, processing and distribution of food.
🏭 Manufacturing: Medical and in vitro diagnostic devices, computer electronic and optical products, electrical equipment, machinery and equipment, motor vehicles trailers and semi-trailers, and other transport equipment.
💻 Digital providers.
👩🏽‍🔬 Research.

Companies on given segments independent of size:

Providers of electronic communications networks and services.
Trust service providers and domain name registries.
Any company that is essential in any way:
- If they are the sole provider in a Member State of an essential service.
- If a disruption of the service could induce a significant systemic risk.
The entity is a public administration entity.

These entities are also classified by their importance.

Essential entities are those in the “high criticality segments” and the “companies independent of size”.

The rest are classified as Important entities.

This is a summarized description, please refer to the full directive to obtain the full context.

NIS2 Fines

The NIS2 doesn’t provide much detail into what fines can be expected. It just defines two maximums and leaves the Member States to provide more detail.

Essential entities: administrative fines of a maximum of 10.000.000 €, or 2 % of the total worldwide annual turnover, whichever is higher.

Important entities: administrative fines of a maximum of 7.000.00 €, or 1,4 % of the total worldwide annual turnover, whichever is higher.

This doesn't mean you’ll get fined that much on top of suffering a cyberattack. The directive positions itself as an understanding companion, taking into account your circumstances.

As long as you demonstrate good faith, by implementing the security requirements, and notifying any incident as soon as you are aware of it; you should be ok.

Direct Impact on the Affected Industries

Now that we understand the whole scope of the NIS2 directive, let’s jump into the meat. What does this mean for your business?

At the top executive level

One of the biggest changes of NIS2 is that now the management level of a company must be involved in the cybersecurity measures taken.

This symbolizes the change in paradigm that the directive is pushing for: Cybersecurity must be at the core of any entity from now on, and the top must lead the change.

IT / OT departments

For any IT / OT department that already implemented cybersecurity, there aren’t big changes. The requirements from NIS2 are basic or medium cybersecurity best practices.

However, those industries at the beginning of their cybersecurity journey will need to put in some effort.

The requirements to implement are:

Policies on risk analysis and IT security.
Incident handling.
Business continuity (backup and disaster recovery, crisis management).
Security in network and IT system acquisition, development, and maintenance. Including vulnerability handling and disclosure.
Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
Basic cyber hygiene practices and cybersecurity training.
Policies and procedures regarding the use of cryptography and, where appropriate, encryption.
Human resources security, access control policies, and asset management.
The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems within the entity, where appropriate.
Application of coordinated security risk assessment.

The main concern right now is how the Member States will adapt these guidelines into concrete requirements. Will they opt for an easy-to-comply regulation or stand up to the challenge and build comprehensive regulation? We’ll hopefully know on October 17th.

Supply Chain

One of the new aspects of NIS2 is securing the supply chain, regarding technology providers.

This is, securing the relationship between yourself, and anyone that provides you with services like hardware, cloud services, internet domains, email services…

The supply chain has been a major target for attackers. Regarding industry, one of the main attack vectors is identity theft via email. For example, an attacker may gain access to an email account, gather information for a while, then impersonate one of your providers and send invoices to be paid (to their bank account).

Another growing attack vector is vulnerabilities in hardware devices. More and more devices in a production plant need a network connection. However, not all providers implement security best practices.

The directive’s heart is in a good place, but this part has quite a broad description. Let’s hope local laws scope properly this aspect of NIS2.

Reporting

The star of NIS2 is reporting security incidents. We mentioned earlier that one of the motivators for fines will be not reporting a security incident on time.

The directive puts the focus on coordinating several local entities to see the big picture and being proactive in assisting by detecting threats. But to reach that goal, you need an “early warning system" driven by organizations reporting every security incident as it’s discovered.

Entities will be required to report significant incidents to the competent authority, who will forward them to the CSIRT. An incident is considered as significant if it caused or is capable of causing either severe operational disruption or financial loss; or if it affects natural or legal persons by causing material or non-material damage.

The timing will also be important:

Incidents must be reported within 24 hours of becoming aware. On this initial report, you should include suspicions of the incident being unlawful, or malicious, or having a cross-border impact.
You must update within 72 hours with an initial assessment including the severity of the incident, the impact, and indicators of compromise.
You may also need to report if requested by the CSIRT or competent authority with relevant status updates.
A final report will be needed within 1 month with a detailed description of the incident, the type of threat or root cause, the mitigation measures taken, and the cross-border impact.

Reporting is rather concrete in the NIS2 directive, we are only waiting for local authorities to define the actual format and communication method of the reports.

Inspections

And finally, the directive takes into account inspections and audits, as no norm is worth it unless it’s properly enforced.

Competent authorities can perform on-site inspections and targeted security audits, and may request any information and evidence of implementation of cybersecurity policies.

Conclusion

The European NIS2 directive is a needed regulation to ensure the safety of essential resources in Europe.

Its scope is ambitious, expanding from just security requirements by building a whole network of entities that will safeguard strategic organizations.

However, the federated nature of the European Union makes implementation one bit more challenging. The Member States now need to adapt the directive to local laws, and we won’t know the concrete details of the regulation until they do.

This uncertainty is far from desirable, moreover when such high fines are on the table, but keep in mind the understanding companion nature of the directive. If you are worried about it, start implementing cybersecurity best practices, you’ll both demonstrate good faith and be protected.

Good Security Boosts Your Flow

Víctor Jiménez Cerrada — Wed, 02 Oct 2024 10:17:37 +0000

Everyone agrees that implementing security is necessary. However, it’s often seen as throwing a spanner in the works, slowing down your momentum.

Delaying security gives a false sense of speed. Yes, you go faster and have less to worry about, but it will always come back to bite you. The moment a critical security incident shows up, it will stop you completely, you may receive substantial fines, and you will definitely suffer an impact on your reputation.

This argument is widely known, and still companies assume the risks, so let’s try a new approach in this article:

When security is implemented correctly, it boosts your operations speed.

A good approach to security motivates you to follow best practices in many areas. As a result, you end up streamlining many processes, improving your efficiency.

Such a paradigm change requires some time to adapt. But done right, you should only slow down for a short period and then proceed to be faster than ever.

So, where does this “momentum killer” reputation that security has come from?

Most of the time, it comes down to flaws when adapting. For example, overlooking some processes that don’t fit the new paradigm or not providing enough training to workers. You suddenly find yourself with a workforce that is no longer confident; thus, things don’t work as they should.

Why is a Radical Change Needed?

Well, the world has changed. When compared to a couple of decades ago, everything is connected now, and we have a huge attack surface.

At a personal level, we went from a laptop to also owning a mobile phone, a tablet, a watch, a TV, and other home appliances that all connect to the internet.

Companies are hosting their servers in fewer instances, increasingly leveraging cloud services. Plus, remote working is a thing now. You not only have to keep in mind your office’s security but also the one at your employees’ homes.

And the industry is more connected than ever. Production lines are now filled with PLCs and sensors that can be monitored from a control room. Machine manufacturers now request remote access to machines so technicians can perform maintenance without driving to the factory.

This interconnected world has plenty of advantages, and we love it. However, we sometimes forget how radical this change has been.

The more connected we are, the more important cybersecurity is. And we placed connectivity at the core of our lives and businesses, so cybersecurity should be as well.

But… I’m just a medium-small company. Who is gonna target me?

Well, attackers have changed too. Attacks are now mostly indiscriminate and automated, driven by botnets that restlessly scrape the internet. It doesn’t matter who you are.

You can easily test this. Leave unprotected remote access to a machine connected to the internet and monitor the access logs. How long do you think it will take for attackers to start pinging the door? The last time I tried it, it took only seconds.

It is no longer a matter of “if” you are going to be attacked but a matter of “when.”

The world has made a fundamental change comparable to the industrial revolution without us realizing it. Now, we need to adapt to radical changes if we want to survive.

Adapting to Change is key to Success

If you implemented security from the start, you are lucky. You probably are following best practices, and you had time to slowly tweak and improve processes.

However, if you are like most, you find yourself at a point where a big step up in security is required. Maybe you need to conform to a new security compliance standard in a short time frame, you thought your security was enough, and now you realize the journey ahead of you is more than you expected.

Don’t worry, you are not alone.

This happens to every company sooner or later; there is a lot of expertise on the topic, and the road is already paved.

The key to success will be your ability to adapt quickly.

Don’t fight it, you’ll end up implementing security halfway, many things won’t work, your employees will feel uncertainty, and overall, you’ll feel like you are slowing down.

Embrace security as a centerpiece of your strategy and take the time to do things right:

Place cybersecurity as a core pillar of your company.
Drive the changes from the top level.

It’s not enough to have a cybersecurity team pushing for the changes. You need the support of the top level, leading by example. It’s the only way the whole company will take this seriously, and people will get invested in doing things properly. After all, why will someone take care of cybersecurity if that’s the responsibility of another team? The message must be “We are all on the same boat.” A cybersecurity team can lead the way, but everyone must do their part.

Once the company culture is on the right path, it’s time to get to work.

Take your time to analyze the areas and processes that will need to change, and dedicate enough effort to empower your workers so they can work confidently under the new paradigm.

Some tips for this phase:

Re-evaluate processes and make them easier to follow.
Identify manual tasks and automate them as much as possible. Reduce the chance of errors that may compromise your security.
Work closely with each area to understand how they work. Don’t impose on them; it will feel like you are telling them how to do their work. If a security policy slows them down, look for solutions as a team.

The moment your workers have the right tools and processes are clear and ironed out; they will feel more confident and more effective than ever at their work.

You’ll Need Good Security Tools

One of the perks of implementing security nowadays is that you have access to a plethora of security tools that already solve most of the challenges you face. You’ll just need to identify those that are best for you.

A quick tip: Security tools must understand your workflow and work with you instead of against you. Look for things like:

Integrating security with your systems should be straightforward.
Security tools must provide you with the insights and reports you need right away.
Out-of-the-box detection rules and compliance controls must cover most of the threats, reducing onboarding and customization to a minimum.
Alerts must be precise. A false positive in an industrial facility may translate into stopping production.

A good security tool saves you time by guiding you:

It works ahead of you, assisting you prevent issues before they are incidents and proposing remediation and mitigation actions.
It cuts through the noise, highlighting the areas in need of immediate attention.

And finally, a good security tool treats security as a whole instead of focusing on a single problem. Attacks nowadays are complex, and you’ll need to correlate insights from several sources to detect them. The bigger the scope of your security tool, the more threats it will be able to detect.

If security is integrated every step of the way, you can stop thinking about security and focus on your work. This will work towards our goal of being faster than without security tools.

Let’s see a few concrete examples of features on security tools that can boost your flow.

Asset Auto-Discovery

Think of a cloud environment where you can have dozens of services. Or an industrial facility with hundreds of devices connected to a production line.

Keeping a manual inventory is a time-wasting endeavor. And it’s also error-prone, as some changes may be overlooked.

By contrast, a security tool can auto-discover all the network devices in a facility and automatically check compliance against them.

Then, you can focus on installing new devices. If a worker commits a mistake while setting a device, it will be easily recoverable; your security tool will find it, and it will be fixed soon enough.

Tracking Compliance Progress

When you are implementing compliance, the traditional way of reporting on progress is to manually check each of the requirements. Although you can automatize some of these checks, it’s another time-wasting process.

Moreover, what happens if a configuration change makes some assets fall out of compliance? When will you notice?

A good security tool will provide automation out-of-the-box for you. It will go even further, running checks periodically so you always have an up-to-date view of your compliance score, and suggesting remediation steps to assist you in meeting the requirements.

Your teams will spend less time doing checks and more time progressing toward compliance.

Continuous Vulnerability Management

A final example is vulnerability management.

It’s just too much work to constantly check for new vulnerabilities and manually check which of your resources is vulnerable.

However, a good security tool can do this automatically and continuously for you. It can even gather context from your environment to prioritize which vulnerabilities pose a higher risk for you and provide mitigation steps for your team.

Instead of performing painful manual checks, your team will be acting directly on the areas that will make a bigger impact. That’s vastly more rewarding.

Conclusion

Times have changed, and now cybersecurity must be at the very core of every business.

Resisting this change turns into half-assed implementations that slow down companies.

However, when security is integrated properly, you end up streamlining processes and growing your toolset. Good security tools also provide great insights that anticipate your needs and make you go faster.