Tag: Security

Cyber Resilience Act Primer

Håkon OlsenLeave a comment

The Cyber Resilience Act is a new EU regulation intended to improve the cybersecurity posture of products sold in the EU/EEA area. The regulation requires producers to follow good security practices, to document security, and to provide security updates – and also to state compliance with the requiremetns in a Declaration of Conformity, as well as to assign a CE mark to the product. Vulnerability reporting becomes mandatory from 11 September 2026, and full CRA compliance and CE marking for market access becomes mandatory from December 2027.

This applies to all products with digital components that communicate with other systems, typically over a network. It does not apply in general to Open Source Software, but there are important requirements also there, especially for “open source stewards”.

The following overview is meant for software developers, product owners, cybersecurity professionals. It is written from a technical point of view, and not a legal one. For each of the requirements in Annex I, I have suggested in bullet points what “good practice looks like”. This is an opinion, and doing what I suggest here is no guarantee of future compliance. European standardization organizations are developing “harmonised standards” to support compliance. Manufacturers should refer to those when they become available.

What is the CRA and why do we need it?

The CRA is a cybersecurity requlations that applies to anyone “placing a product with digital components on the EU/EEA market”. It requires essential cybersecurity requirements and vulnerability handing requirements ot be met.

The purpose of the regulation is to help build a more cyber resilient Europe, and targets products whereas the perhaps more well-known directive NIS2 for services that are critical to society. Cybersecurity threats, ranging from nation-state intelligence operations to financially motivated organized crime, is costing society a lot and reducing the trust we have in each other, institutions and the technologies we depend on. The CRA is aiming to help reduce vulnerabilty to cyber attacks.

Does it apply to your product?

If you are making a product, the first question to determine is if the CRA applies. If the product is a software product that will be installed on a device (personal computer, smartphone, etc), or a physical product that contains software components such as a smart toaster or industrial machinery with built-in control system, it applies.

There are exceptions for products that are already regulated by other EU regulations. In particular, products in vehicles, aeroplanes, and medical devices are not covered, as well as maritime systems falling under the “Maritime Equipment Directive”. Toasters, smartphones and conveyor belts are in, boats and planes are out.

Requirements overview

The requirements of the CRA are in general “follow good security practices”. From the point of view of a manufacturer “placing products on the market”, the key requirements are found in Article 13 of the regulation, and in Annex I.

Before bringing any product with digital elements to market, manufacturers must design, develop, and produce it to meet essential cybersecurity standards. This means conducting a thorough cybersecurity risk assessment that guides every stage—from planning and design to production, delivery, and maintenance. The goal is to minimize risks, prevent incidents, and protect users, especially their health and safety. Manufacturers must also document this assessment, update it regularly during the product’s support period, and include it in the technical documentation. If third-party components (including open-source software) are used, manufacturers must ensure they don’t compromise the product’s security and must report and address any vulnerabilities found in those components. The essential cybersecuriyt requirements are listed in Annex I.

Manufacturers are also required to provide clear support periods—at least five years, or the expected lifetime if shorter, during which vulnerabilities must be actively managed. They must keep users informed about the end of support, maintain security updates for at least a decade, and ensure products can be identified and traced.

Transparency is key: users need accessible instructions, contact details, and information about risks, while authorities must have access to documentation for at least ten years after the product hits the market. If issues arise, manufacturers must act swiftly to correct them, withdraw, or recall products as needed.

Article 13 demands that good security practices are followed, and that a risk assessment is used to guide development and maintenance of the product. The product must be supported with security updates, and those must be available for at least 10 years.

Software security requirements from Annex I

The full requirements of Annex I can be found here: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_I.

Let’s dive into the essential security requirements in Part 1 of Annex I and review what realistically must be in place to meet the requiremetns.

(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

This is a broad requirement. In practice it means that you need to have a risk-based process for designing the software architecture and implementation. A good process would include the following aspects:

  • Define the user stories or main functional requirements of the component
  • Define baseline security requirements
  • Perform threat modeling/risk assessment using a structured and documented approach. Often a software-centric threat modeling method will be a good approach during design (such as STRIDE), supported by a product level risk assessment that is threat driven (asset-threat-vulnerability). Define mitigations based on the risk, and design test cases for them, especially if they are logic related and not purely related to bugs/implementation errors.
  • Make sure your software design is well-documented and that risk treatments are traceable.
  • Regularly update the risk assessment based on changes in the external environment, the software it self, or its use cases.

The second requirement (2) contains all the prescriptive security requirements of Annex I. We will go through these presecriptive requirements one-by-one with a short assessment of what will need to be done to meet it.

(2) On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall:

Click on the arrows to expand each requirement and see the interpretation of the requirement.

(a) be made available on the market without known exploitable vulnerabilities;
  • Keep track of all dependencies and their vulnerabilities – requiring a “software bill of materials”. The build or requirements system will typically take care of dependency tracking – like npm or pip.
  • Have a process or system to detect known vulnerabilities, especially “exploitable” ones. Following public catalogs such as the known exploited vulnerabilities from CISA and vendor security bulletins is necessary for this. Patch such vulnerabilities as-soon-as-possible and before releasing new versions.
  • Vulnerabilities can also exist in your own code. To satisfy the requirement you must hence also have good security testing practices. This would typically include static analysis (good at catching bugs), and security tests as part of unit and integration testing. You may also use AI coding agents to analyse code for vulnerabilities as part of your build process – this can be very efficient.
  • Perform penetration testing and active runtime testing regularly as part of your software assurance and maintenance processes.

(b) be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state;
  • Secure defaults means that you need to configure data access, user accounts, etc. in a secure way on release, and provide instructions to the user on how to use it in the secure configuration. This may make things more difficult at setup, for example when multi-factor authentication is reuqired.
  • The product shoould have a “factory reset” mechanism. This means that if you install the product in a secure configuration, and then as a user change it to unsafe configuration, reverting to the default secure state should be easy.
  • Exception: development of software for others, where the buyer (customer) is responsible for security if they want to “place it on the market”.

(c) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;
  • Design the system so that security updates can be provided automatically when possible
  • Provide the user with a way to opt-out temporarily
  • Notify users of available updates and how long the can postpone. It is best to integrate this as part of the software if it is end user focused, but if it is an IoT application or otherwise not frequently used by people another mechanism should be chosen, for example alert emails.
(d) ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access;
  • Provide strong authentication mechanisms – typically by MFA, passkeys, and similar mechanisms
  • Build in detection capabilities for identity breaches – either directly in the product or facilitate such detection throu log analytics in an external environment if appropriate (like a SIEM)
  • Create an access model for various roles (RBAC) if appropraite and enforce it.
  • Provide defensive mechanisms to temporarliy reduce access if there are indicators of account braches
  • Provide logs of suspicious authentication and access atttempts
  • Log authorization changes made by an administrator
  • Map the access control mechanisms to the risk assessment
(e) protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means;
  • Use TLS or other encryption methods for network transport. Make sure to only support up-to-date ciphers
  • Use disk encryption for data stored on the device. Note that this only protects data when the machine is powered off, if not the read/write access is provided through the operating system.
  • Provide file system level or row-level database encryption if so required based on the risk assessment.
  • Ensure handling of certificates and encryption keys is done in a secure and robust way
  • Monitor cryptographic recommended practices and update accordingly when needed, for example if vulnerabilities are discovered or more powerful crypto analysis attacks become available. Consider the use of quantum safe crypto.
(f) protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions;
  • Enable use of integrity control mechanisms for files and on-disk data through hash controls and similar mechanims. You may be able to use operating system level mechanisms for this.
  • TLS provides integrity control for data in transit through message integrity checks (HMAC for example)
  • Within the application, changes to data can be logged. To avoid creating too high volume of logs, a threat model should be used to decide the details to include and types of events to log.
  • To “report on corruptions” it is good practice to provide this in logs that can be exported ot a sink to avoid a threat actor manipulating important lgos.
(g) process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);
  • Decide which data will need to be process in the application and document this
  • Include data handing in risk assessment
  • Develop data retention policies with automatic deletion where appropriate

(h) protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks;
  • Based on risk assessment, plan and design failover and redundancy mechanisms
  • Include denial-of-service cases in risk assessment and build sufficient mitigation against it
  • Consider the addition of emergency access mechanisms in case of a serious incident blocking normal access. This can be through a separate interface, or a local “breaking glass account”. In the design of such mechanisms avoid any hardcoding of the access, and make sure use of such mechanisms are logged and detected.
(i) minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;
  • Include as a case in risk assessmen that a threat actor has taken control of the device and is using it to attack other devices. Build in protections against such abuse cases.
  • Limit the allowable egress protocols from the product to those that are necessary for the products functioning. Operating system features and software firewalls may be useful for this.
  • Where the products user interface does not intend for the user to have low-level access to the operating system or network stack, include the possibility of vulenrability exploitation causing such access for a threat actor in the risk assessment.
  • Design retry mechanisms using network calls to avoid sending too many messages in a short time

(j) be designed, developed and produced to limit attack surfaces, including external interfaces;
  • As part of the software design, enumerate and evalauate the attack surface from both external (network access) and internal (low-privileged user) perspectives.
  • Minimize access points as required
  • Disable debugging interfaces in a secure way when the product is in production mode. Make this part of the secure configuration design.
  • Include every entry point in the attack surface in the risk assessment and evaluate against expected abuse cases
(k) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;
  • Provide detection capabilities to discover cyber incidents and exploitation attempts
  • Design the system in a modular way, to allow for automated isolation of likely compromised subcomponents
  • Use separation of concerns to ensure complexity does not make partial isolation and containment unrealistic
  • Harden the underlying operating system to reduce the impact of incidents, especially to avoid escalation of privileges
  • Provide guidance in documentation to incident responders to help with detection, forensics and containment

(l) provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user;
  • Set up robust logging practices in the application
  • Use a threat model/risk assessment to determine which events will need to be logged, and if there should be any internal log filtering/rate limiting
  • Ideally provide a standardized logging mechanism to integrate with security tooling, such as using operating system logs or making standarized logs available over an API.
  • Create clear recommendation for logging and log integration practices
  • Allow the user to configure their logging in a transparent way – including turning all logging off, or some logging. The level of user control should be designed to fit the risk and use cases for the product.

(m) provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.
  • Create a “data export” feature to allow users to configure another product or export the data for use in another system
  • Create a way for users to remove/delate all data and settings in the product

This sums up the essential cybersecurity requirements. Tap each requirement to see recommended practices. These are based on my experience with application and device (mostly from OT) security. There will be “harmonised standards” available to prove compliance with CRA requirements – these will provide guidance on how to satisfy the requirements. There is no guarantee that my “quick and dirty empirical suggestions” will align with those (future) standards.

Vulnerability management requirements from Annex I

You will need to shape up your vulnerability handling process if you have not already done so; Manufacturers of products with digital elements shall:

(1) identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products;
  • Use tools to create the SBOM – there are both commercial and open source tools available for this. THe SBOM should be in a machine-readable format. CycloneDX and SPDX are common formats that can also be read by editor and IDE plugins.
  • Integrate dependency tracking in the CI/CD pipeline of the software, and freeze and SBOM for each release version
  • Include top-level dependencies at minimum, but aim to capture transitive dependencies where feasible, and ensure the SBOM is updated with every product release or significant change. Note that deep dependency-trees are generally unsafe and could be considered in breach of the attack surface minimization requirement in Part 1 of Annex I.
(2) in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates;
  • Create a process to issue security updates fast. The updates should go through the software assurance process to ensure quality, including testing for regressions.
  • When updating dependencies, make sure to perform thorough testing if there are breaking API changes in the dependencies.
  • Push security updates independently of your feature release cycle – unless you work on a frequent update schedule. If you update the system for features once per year, you cannot use that to push security updates.
(3) apply effective and regular tests and reviews of the security of the product with digital elements;
  • Integrate testing in development and build process, including unit/integration tests, static analysis and SBOM updates
  • Perform regular runtime level testing (pentesting)
  • Conduct architectural reviews regularly and with every major change – referencing an architectural best practice description. Use this as basis for updating risk assessments/threat models.
(4) once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch;
  • In general, provide security bulletins online
  • If providing the information to the public is a high risk to product users, you may delay publishing the vulnerability until users have updated. In this case, make sure to document the decision and provide sufficient help for customers to get systems patched.

(4) once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch;

(5) put in place and enforce a policy on coordinated vulnerability disclosure;
  • Establish a clear policy to the public on how to report security vulnerabilities. Provide secure channels for doing so, for example by providing a public encryption key
  • Define internal workflows for triaging, validating, and addressing reported vulnerabilities, including roles and responsibilities, escalation paths, and timelines for fixes, ensuring alignment with industry standards like ISO/IEC 29147 (coordinated disclosure) or ISO/IEC 30111 (vulnerability handling).
(6) take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements;
  • See also the items under (5)
  • Also recommended: consider adding a /.well-known/security.txt file on the web site
  • Include information on vulnerability disclosure in the product documentation
(7) provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner;
  • If possible and safe, plan for “updates-over-the-air” but allow the user to configure and potentially postpone such updates
  • Provide updates online if the suer needs to perform a download and update manually
  • Make sure update mechanisms are well-protected to avoid supply-chain breaches. Include SHA256 hashes of any updates, and mechanisms to verify patch downloads before installation

(8) ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.
  • Provide security updates as soon as they have been developed, tested and released
  • Ensure the patch development process is not a bottleneck
  • Provide informaiton on updates to registered customers with a push mechanism (emails, etc)
  • For “custom software made as a consultant”, make sure the responsibilites for handling distribution of security updates is agreed in the contract.

Documentation requirements

The technical documentation reuqired for CE conformity assessment is found in Annex VII: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_VII.

The Cyber Resilience Act (CRA) mandates that manufacturers of products with digital elements maintain technical documentation to prove compliance with its essential cybersecurity requirements. This documentation, detailed in Annex VII, must be prepared before placing a product on the market and kept updated throughout its support period. It serves as the foundation for conformity assessments and must be made available to market surveillance authorities upon request.

The technical documentation ensures transparency and accountability, enabling authorities and users to verify that products meet the CRA’s security standards. It also supports traceability, vulnerability management, and ongoing compliance.

The documentation is meant to show how the requirements in Article 13 and Annex I are met. It should containt he following:

  • General description of the product, its intended purpose, and security properties
  • The risk assessment for the product
  • Design, manufacturing, and operational details, including cybersecurity risk assessments
  • Test reports and evidence of conformity with Annex I requirements
  • Information on vulnerability handling processes and software bill of materials (SBOM)
  • User instructions and security-related information for safe installation, use, and decommissioning
  • The declaration of conformity (CE)

What about open source?

The CRA does not apply to open-source software not made in a commercial context.

If you integrate open source components in your product (and we all do, right?), you need to exercise “due diligence” to make sure the component does not compromise the security of your product, according to Article 13:

(5) For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity.

(6) Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.

This means that open-source component should be vetted before used.

  • Is it an actively maintained project?
  • Does it have well-known maintainers and “stewards” supporting development and maintenance?
  • Do they have available secuirity information, metrics, etc?

Paragraph (6) under Article 13 also states you should share code or documentation to aid in patching. A good way of doing that is submitting a patch as a pull request in open source projects.

You may also want to consider if the maintainer of the component has good security practices, including account practices. Compromised maintainer accounts on repositories such as PyPi and NPM have resulted in many supply-chain breaches over the last years. This can be hard to know anything about but increasingly stronger security requirements of code sharing platforms are improving the security of these platforms.

If you are one of the key maintainers of an open-source software, you are considered an “open-source steward” under the CRA. The rules require open-source stewards to create secure development policies and to collaborate with market surveillance authorities in order to help build a more secure ecosystem, but they are not subject to penalties for non-compliance. They can’t put you in jail for submitting a bad pull request, or failing to publish a security.md on your Github project.

Activities needed to be able to CE mark your product

The road to CE conformity depends on the classification of your product. Many of the requiements are the same no matter what (those listed above) but the way to “prove” to the market you have done the required things depends on the type of product. There are two key processes that need to be put in place – they should be documented and repeatable to ensure quality:

  • A secure development process
  • A vulnerability handling process

There are 3 types of products in the CRA: (1)Important products (Class 1 and Class 2) – a list of IT security relevant products defined in Annex III, and (2) Critical products – hardware devices with security boxes, smart meter gateways and high-security cryptographic units, and smartcards and similar products, and finally (3) Products, which is everything else.

If your product is not important or critical, you can generally “self-ceritfy” (Module A). The CRA has 4 modules for conformity assessment – A, B, C and H.

The “modules” refer to standardized conformity assessment procedures defined in the EU’s New Approach Directives and adopted in regulations like the CRA. They outline how manufacturers can demonstrate that their products meet legal requirements. In the CRA, these modules are detailed in Annex VIII and include:

  • Module A (Internal production control): The manufacturer performs all assessments internally and issues a self-declaration of conformity.
  • Module B (EU-type examination): A notified body examines the product’s technical design and issues an EU-type examination certificate.
  • Module C (Conformity to type): The manufacturer ensures their products conform to the approved type (certified under Module B) and issues a declaration of conformity.
  • Module H (Full quality assurance): The manufacturer operates a comprehensive quality system covering design, production, and testing, with regular audits by a notified body.

These modules provide flexibility, allowing manufacturers to choose the appropriate level of third-party involvement based on the product’s risk class. For Important products class 1, self-declaration is allowed if harmonised standards are used. If not, they may follow a CE marking route B+C or H.

GAP assessment

Start with a GAP assessment where the requirements of Annex I are measured against:

  • Software development practices and competence to perform the work at the required level. OWASP SAMM is a good baseline for this.
  • Does the manufacturer have a good product level risk assessment?
  • Is there a threat modeling or risk assessment practice in the SDLC to aid in developing security mechanisms and test cases?
  • Assess the product design and architecture against the requirements in Annex I
  • Assess whether vulnerability handling procedures according to Part 2 of Annex I are defined and in place

It is not expected that the GAP assessment shows zero gaps. One needs to be honest and use the GAP assessment to plan the roadmap towards compliance.

Software development practice implementation

Implement good security practices in software engineering, from developer traininig and competence, quality assurance, test routines, CI/CD, and SBOM generation.

Assign ownership and accountability for security work in design and development.

Risk assessment

Create or update the risk assessment to support product development and vulnerability management. A good security oriented risk assessment at product level should take into account threat actors and their capabilities, vulnerability classes and the types of assets and exposure in the product.

Documentation, DoC and CE marking

Draw up the documentation in accordance with Annex VII. Issue a DoC (Declaration of Conformty) and affix the CE mark to the product. Keep the documentation and DoC in archive for 10 years.

A bit of (free) advertising: Want to discuss the CRA more in detail? Contact TÜV Rheinland (where I work): https://www.tuv.com/world/en/cyber-resilience-act.html, or if you are in Norway, send an email to inquiry@safetec.tuv.com or reach out to me directly on LinkedIn: https://www.linkedin.com/in/hakondo/. This blog post is not sponsored or written on behalf of my employer.

– Håkon.

Sick of Security Theater? Focus on These 5 Basics Before Anything Else

Håkon Olsen1 Comment

Cybersecurity abounds with “to-do lists” in the form of guidance documents and control frameworks. However, these lists alone don’t strengthen a network; implementing the controls does. Given that frameworks often contain hundreds of controls, distinguishing between basic and additional security controls is beneficial. It’s crucial to implement the foundational basics before moving on to risk assessments, strict governance procedures, and other advanced measures.

– I don’t have the paperwork but at least we have firewalls and working patch management! 

Luckily, there are also “quickstart” guidelines available. One of the best is the UK NCSC’s “Cyber Essentials”. This includes 5 technical controls that will stop most cyber attacks and make your organization much more resilient. 

Help cover the cloud and hosting costs of this blog?

Buy Me A Coffee

1 – Secure configuration

  • Remove software and features you don’t need
  • Do not allow administrative accounts to be used for daily work. Use separate accounts for administration, and preferably only a few people from the IT department should be able to be administrators. 
  • Remove default accounts, and change any default passwords. 

2 – Malware protection

  • Install anti-malware software on all computers and smartphones
  • Configure the anti-malware software to check web links as well

3 – User access control

  • Only give access to people who need it
  • Only give access to necessary resources the user needs to do their job
  • Implement strong authentication with two-factor authentication for all services that can be reached from the Internet
  • Set a routine to go through user accounts regularly and remove or disable user accounts that should no longer be there

4 – Firewalls

  • Make sure all Internet connected devices have a firewall
  • Configure the firewalls to only allow the necessary traffic
  • Block all inbound traffic, unless the device has a role requiring it, for example a web server

5 – Security updates

  • Only use supported applications that still receive security updates
  • Automated security updates where possible
  • Keep an inventory of the installed software on all devices. This will be available in most modern anti-malware software systems. 
  • When a high severity vulnerability is published, check the inventory if you have this software and implement the patch or other mitigations quickly. 

Next steps

When the essential controls are in place, the next step should be to set up an incident response plan, and practice using it. Then you are ready to start building a risk based governance structure and focus on continuous improvement and compliance using one of the big frameworks such as ISO 27001.

Some good resources on the basics

NCSC Cyber Essentials

ENISA cybersecurity guide for SME’s

The Showdown: SAST vs. Github Copilot – who can find the most vulnerabilities?

Håkon OlsenLeave a comment

Vibe coding is popular, but how good does “vibe security” compare to throwing traditional SAST tools at your code? “Vibe security review” seems to be a valuable addition to the aresenal here, and performs better than both Sonarqube and Bandit!

Here’s an intentionally poorly programmed Python file (generated by Le Chat with instructions to create a vulnerable and poorly coded text adventure game): 

import random
import os

class Player:
    def __init__(self, name):
        self.name = name
        self.hp = 100
        self.inventory = []

    def add_item(self, item):
        self.inventory.append(item)

def main():
    player_name = input("Enter your name: ")
    password = "s3Lsnqaj"
    os.system("echo " + player_name)
    player = Player(player_name)
    print(f"Welcome, {player_name}, to the Adventure Game!")

    rooms = {
        1: {"description": "You are in a dark room. There is a door to the north.", "exits": {"north": 2}},
        2: {"description": "You are in a room with a treasure chest. There are doors to the south and east.", "exits": {"south": 1, "east": 3}},
        3: {"description": "You are in a room with a sleeping dragon! There is a door to the west.", "exits": {"west": 2}},
    }

    current_room = 1

    while True:
        room = rooms[current_room]
        print(room["description"])

        if current_room == 3:
            action = input("Do you want to 'fight' the dragon or 'flee'? ").strip().lower()
            if action == "fight":
                if random.randint(0, 1):
                    print("You defeated the dragon and found the treasure! You win!")
                else:
                    print("The dragon defeated you. Game over!")
                break
            elif action == "flee":
                current_room = 2
                continue

        command = input("Enter a command (go [direction], get [item]): ").strip().lower()

        if command.startswith("go "):
            direction = command.split("go ")[1]
            if direction in room["exits"]:
                current_room = room["exits"][direction]
            else:
                print("You can't go that way.")
        elif command.startswith("get "):
            item = command.split("get ")[1]
            player.add_item(item)
            print(f"You picked up {item}.")
        else:
            print("Invalid command.")

if __name__ == "__main__":
    main()

The code is made unnecessarily complex, and allows user input to be injected directly into the command line. It also has a hardcoded “password” that is not really used for anything. Let’s check the security of this with 3 methods:

  1. Sonarqube Cloud (free version)
  2. Bandit (Python SAST tool)
  3. Github Copilot with GPT-o4

Sonarqube is run with the default ruleset “Sonar Way” with no extra configuration effort. The scan detects “2 security hotspots” and some maintainability issues. A security hotspot is a potential weakness that the SAST tool can’t conclude on, and will require manual review.

The first hotspot is the “password”:

Sonarqube also gives guidance on how to assess if this is dangerous, and how to fix it, which is quite helpful. The other hotspot is “weak cryptography” when the game is using random.randint to choose whether fight or flee is the winning strategy when encountering a dragon – not a (software) security issue. Dragons can be dangerous, though!

Now, let’s try Bandit.

Badit did its job – and provides links to more information, including CWE references. Blue is “not good” and red is “bad”.

OK, now for Github Copilot.

Prompt – and then followed by the formatted report! 

You are a professional software quality expert and security test engineer. Please review this code and provide an overview of security weaknesses with references to CWE's, and suggested fixes. Analyse the current file. Create the output as a security vulnerability report in markdown format.

Security Vulnerability Report for spaghetti.py

This report provides an analysis of the security weaknesses in the provided spaghetti.py file. Each vulnerability is referenced with its corresponding Common Weakness Enumeration (CWE) and includes suggested fixes.

Vulnerabilities

1. Hardcoded Password

  • Description: The password is hardcoded in the file (password = "s3Lsnqaj"), making it vulnerable to exposure if the file is shared or accessed by unauthorized users.
  • CWE Reference: CWE-798: Use of Hard-coded Credentials
  • Impact: Hardcoded passwords can lead to unauthorized access to sensitive resources.
  • Suggested Fix:
    • Store the password securely using environment variables or a secrets management tool.
    • Example:
      import os
password = os.getenv("GAME_PASSWORD")
if not password:
    raise ValueError("Password not set in environment variables")

2. Command Injection

  • Description: The os.system call uses unsanitized user input (os.system("echo " + player_name)), which can lead to command injection if a malicious user provides crafted input.
  • CWE Reference: CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
  • Impact: A malicious user could execute arbitrary system commands, potentially compromising the host system.
  • Suggested Fix:
    • Use safer alternatives like subprocess.run with proper input sanitization.
    • Example:
      import subprocess
subprocess.run(["echo", player_name], check=True)

3. Unvalidated User Input

  • Description: User input (player_name, action, command) is not validated or sanitized, which can lead to unexpected behavior or vulnerabilities.
  • CWE Reference: CWE-20: Improper Input Validation
  • Impact: Unvalidated input can lead to crashes, security vulnerabilities, or incorrect program behavior.
  • Suggested Fix:
    • Validate and sanitize all user inputs.
    • Example:
      player_name = input("Enter your name: ").strip()
if not player_name.isalnum() or len(player_name) > 50:
    print("Invalid name. Please enter a valid name.")
    return

4. Predictable Randomness

  • Description: The use of random.randint(0, 1) for critical game logic (e.g., dragon fight outcome) is predictable and not cryptographically secure.
  • CWE Reference: CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
  • Impact: Predictable randomness can lead to unfair or exploitable outcomes in the game.
  • Suggested Fix:
    • Use a cryptographically secure random number generator if randomness is critical.
    • Example:
      import secrets
if secrets.choice([True, False]):
    print("You defeated the dragon and found the treasure! You win!")
else:
    print("The dragon defeated you. Game over!")

5. No Input Length Restriction

  • Description: The player_name input does not restrict the length, which could lead to buffer overflow or other issues in certain scenarios.
  • CWE Reference: CWE-1283: Improper Validation of Specified Quantity in Input
  • Impact: Excessively long input could cause performance issues or crashes.
  • Suggested Fix:
    • Limit the length of user input and validate it.
    • Example:
      player_name = input("Enter your name: ").strip()
if len(player_name) > 50:
    print("Name too long. Please enter a shorter name.")
    return

6. No Error Handling

  • Description: The code lacks error handling for invalid commands, missing keys in dictionaries, or unexpected input.
  • CWE Reference: CWE-703: Improper Check or Handling of Exceptional Conditions
  • Impact: The program may crash or behave unpredictably when encountering errors.
  • Suggested Fix:
    • Add proper exception handling to ensure the program handles errors gracefully.
    • Example:
      try:
    direction = command.split("go ")[1]
    if direction in room["exits"]:
        current_room = room["exits"][direction]
    else:
        print("You can't go that way.")
except KeyError:
    print("Invalid room configuration.")
except Exception as e:
    print(f"An unexpected error occurred: {e}")

Summary

The code contains several vulnerabilities that could compromise its security and reliability. Addressing these issues will improve the robustness and safety of the application.

Recommendations

  1. Replace hardcoded sensitive information with secure storage methods.
  2. Avoid using os.system with unsanitized input; use safer alternatives like subprocess.run.
  3. Validate all user inputs and restrict their length to prevent unexpected behavior.
  4. Use proper error handling to ensure the program does not crash due to invalid input or unexpected conditions.
  5. Consider using cryptographically secure randomness for critical game logic if necessary.

By implementing these fixes, the code will be more secure and maintainable.

Summary

Using Copilot to do a security review and generate a report created the most thorough assessment, which is not surprising. Bandit did quite well and detected the actually dangerous injection vulnerability. Sonarqube provides a nice UI but did not detect the one actually serious vulnerability here.

What to do when you lose your MFA device?

Håkon OlsenLeave a comment

Multifactor authentication is a great security control that makes breaking into user accounts much more difficult. But what do you do if you lose your MFA device? You need to set up recovery methods in advance so that you will be able of doing this. Different SaaS providers offer different levels of convenience and security for these use cases. At work, your IT department will be able to help, so we will focus on services we use in our personal lives here.

Prepare for losing your device: set up your backup options

The most common MFA authentication patterns today involve using a cell phone:

  • A text message (SMS) with a one-time code (this is probably the least secure MFA option)
  • An authenticator app with either a one-time code, or a push notification

If you lose access to the phone, you will be locked out of your MFA accounts. There are two main ways to avoid this:

  1. Download static recovery codes and store them in a secure location. These codes can be used to get access when your MFA device is lost.
  2. Set up multiple MFA channels, so that you can use an alternative channel if your primary MFA device is gone. Make sure they don’t both depend on the same physical device.

Security Consideration

When setting up backup MFA methods, make sure you don’t set up an insecure method that will allow hackers to easily bypass your MFA step. One such option is to use e-mail for one-time tokens, if the same e-mail address can also be used for password reset. If your e-mail address is compromised, the attacker will have full access to your account.

Example 1: Google Account

Google offers multiple logon choices when you try to log on to your account, including passkeys (Google’s description). Setting up a passkey is a good idea, it improves security and usability at once.

Google MFA prompt with multiple options (in Norwegian)

Google offers many MFA options to choose from (I aborted the default way, and clicked “try another way” on the first MFA prompt screen). It allows you to use:

  • A physical security key
  • Use a one time code from another device where you are logged into your account
  • Click “yes” to a pop-up on your phone
  • Use your phone or tablet to get a one-time code
  • Use your passkey

The SMS based option is blocked because more secure options have been configured. Most of these depend on my phone, so if I lose that one, I have much less options. I do have an Android tablet I can use as backup.

Example 2: Facebook account

A lot of people use Meta’s apps, including Facebook. Being locked out of a social media account is not a fun experience. I have created a demo Facebook account, and turned on MFA on this account using an authenticator app. Let’s say I have lost my phone, and need to log in. In the below picture I have entered my account’s e-mail address and password, and it is asking for a one-time code from my authenticator.

If you click the “Need another way to confirm it’s you?” link, you get two options:

  • Approve on a device where you are already logged in
  • Upload a government ID to get manual help to reclaim the account

You can also set up multiple authentication methods for MFA on Facebook (and most other big consumer sites). They also offer creating recovery codes that you can save for the rainy day when you lose your phone.

Now, let’s try to log in again and pretend we have lost the authenticator. We don’t get an option to use recovery codes, it looks like we still have to upload an ID to support. But: if you enter one of the 8-digit recovery codes in the field asking for the 6-digit one-time code, it works and you are logged in!

MFA Anti-Lockout Recipe

OK, so if you enable MFA without doing any preparations for losing your device, you will be in trouble the day your phone is lost. Here’s what to do:

  1. Set up MFA with your primary method. Use the most secure option available that you are able to use.
  2. Set up a backup MFA method. Try to avoid e-mail and SMS if you can.
  3. Download and store recovery codes somewhere safe if offered in the app. The best place is probably a password manager.
  4. Set up notifications for unknown logins, for example from new devices or new countries, if offered. This will help you react quickly if something unexpected happens.

Happy surfing without getting locked out of your account because MFA got in the way!

Vendor Security Management: how to decide if tech is safe (enough) to use

Håkon Olsen2 Comments

tl;dr: Miessler is right. We need to focus on our own risk exposure, not vendor security questionnaires

If you want to make a cybersecurity expert shiver, utter the words “supply chain vulnerabilities”. Everything we do today, depends on a complex mixture of systems, companies, technologies and individuals. Any part of that chain of interconnected parts can be the dreaded weakest link. If hackers can find that weak link, the whole house of cards comes crumbling down. Managing cyber supply chain risk is challenging, to say the least. 

Most companies that have implemented a vendor cybersecurity risk process, will make decisions based on a questionnaire sent to the vendor during selection. In addition, audit reports for recognized standards such as ISO 27001, or SOC2, may be shared by the company and used to assess the risk. Is this process effective at stopping cyberattacks through third parties? That is at least up for debate.

Daniel Miessler recently wrote a blog post titled It’s time for vendor security 2.0, where he argues that the current approach is not effective, and that we need to change the way we manage vendor risks. Considering how many cybersecurity questionnaires Equifax, British Airways and Codecov must have filled in before being breached, it is not hard to agree with @danielmiessler about this. What he argues in his blog is: 

  1. Cybersecurity reputation service (rating companies, etc) are mostly operating like the mob, and security questions are mostly security theater. None of this will save you from cyber armageddon.
  2. Stay away from companies that seem extremely immature in terms of security
  3. Assume the vendor is breached
  4. Focus more on risk assessment under the assumption that the vendor is breached than questionable questionnaires. Build threat models and mitigation plans, make those risks visible. 

Will Miessler’s security 2.0 improve things?

Let’s pick at the 4 numbered points above one by one. 

Are rating companies mobsters? 

There are many cybersecurity rating companies out there. They take measure of themselves to be the Moody’s or S&P’s of cybersecurity. The way they operate is they pull in “open source information about cybersecurity posture” of companies. They also say that they enrich this information with other data that only they have access to (that is, they buy data from marketing information brokers and perform data exchange with insurance companies). Then they correlate this information in more or less sound statistical ways (combined with a good dose of something called expert judgment – or guessing, as we can also call it) with known data breaches and create a security score. Then they claim that using companies with a bad score is dangerous, and with a good score is much better. 

This is definitely not an exact science, but it does seem reasonable to assume that companies that show a lot of poor practice such as a lack of patching, botnet infected computers pinging out to sinkholes and so on, have worse security management than similar companies that do not have these indicators. Personally, I think a service like this can help sort the terrible ones from the reasonably OK ones. 

Then, are they acting as mobsters? Are they telling you “we know about all these vulnerabilities, if you don’t pay us we will tell your customers?”. Not exactly. They are telling everyone willing to pay for access to their data these things, but they are not telling you about it, unless pay them. It is not exactly in line with accepted standards of “responsible disclosure”. At the same time, their findings are often quite basic and anyone bothering to look could find the same things (such as support for old ciphers on TLS or web servers leaking use of an old PHP version). Bottom line, I think their business model is acceptable and that the service can provide efficiency gains for a risk assessment process. I agree with Miessler that trusting this to be a linear scale of cyber goodness is naive at best, but I do think companies with a very poor security rating would be more risky to use than those with good ratings. 

mobster planning his next security rating extortion of SaaS cybersecurity vendors
Some security vendors have a business model that resemble extortion rackets of a 1930’s mobster. But even mobsters can be useful at times.

Verdict – usefulness: rating services can provide a welcome substitute or addition for slower ways of assessing security posture. An added benefit is the ability to see how things develop over time. Small changes are likely to be of little significance, but a steady improvement of security rating over time is a good sign. These services can be quite costly, so it is worth thinking about how much money you want to throw at it. 

Verdict – are they mobsters? They are not mobsters but they are also not your best friends. 

Are security questionnaires just security theater? 

According to Miessler, you should slim down your security questionnaires to two questions: 

  1. “when was the last time you were breached (what happened, why, and how did you adjust)”?, 
  2. and “do you have security leadership and a security program?”.

The purpose of these questions is to judge if they have a reasonable approach to security. It is easy for people to lie on detailed but generic security forms, and they provide little value. To discover if a company is a metaphorical “axe murderer” the two questions above are enough, argues Miessler. He may have a point. Take for example a typical security questionnaire favorite: “does your company use firewalls to safeguard computers from online attacks?” Everyone will answer “yes”. Does that change our knowledge about their likelihood of being hacked? Not one bit. 

Of course, lying on a short questionnaire with Miessler’s 2 questions is not more difficult than lying on a long and detailed questionnaire. Most companies would not admit anything on a questionnaire like this, that is not already publicly known. It is like flying to the US a few years ago where they made you fill out an immigration questionnaire with questions like “are you a terrorist?” and “have you been a guard at a Nazi concentration camp during WWII”. It is thus a good question if we can even just scrap the whole questionnaire. If the vendor you are considering is a software firm, at least if it is a “Software as a Service” or another type of cloud service provider, they are likely to have some generic information about security on their web page. Looking up that will usually be just as informative as any answer to the question above. 

Verdict: Security questionnaires are mostly useless – here I agree with Miessler. I think you can even drop the minimalist axe murderer detection variant, as people who lie on long forms probably lie on short forms too. Perhaps a good middle ground is to first check the website of the vendor for a reasonable security program description, and if you don’t see anything, then you can ask the two questions above as a substitute. 

Stay away from extremely bad practice

Staying away from companies with extremely bad practice is a good idea. Sometimes this is hard to do because business needs a certain service, and all potential providers are horrible at security. But if you have a choice between someone with obviously terrible security habits and someone with a less worrying security posture, this is clearly good advice. Good ways to check for red flags include: 

  • Create a user account and check password policies, reset, etc. Many companies allow you to create free trial accounts, which is good for evaluating security practices as well. 
  • Check if the applications are using outdated practices, poor configuration etc. 
  • Run sslscan to check if they are vulnerable to very old crypto vulnerabilities. This is a good indicator that patching isn’t exactly a priority.

Verdict: obviously a good idea.

Assume the vendor is breached and create a risk assessment

This turns to focus on your own assets and risk exposure. Assuming the vendor is breached is obviously a realistic start. Focusing on how that affects the business and what you can do about it, makes the vendor risk assessment about business risk, instead of technical details that feel irrelevant. 

Miessler recommends: 

  • Understand how the external service integrates into the business
  • Figure out what can go wrong
  • Decide what you can do to mitigate that risk

This is actionable and practical. The first part here is very important, and to a large degree determines how much effort it is worth putting into the vendor assessment. If the vendor will be used for a very limited purpose that does not involve critical data or systems, a breach would probably not have any severe consequences. That seems acceptable without doing much about it. 

On the other hand, what if the vendor is a customer relationship management provider (CRM), that will integrate with your company’s e-commerce solution, payment portal, online banking and accounting systems? A breach of that system could obviously have severe consequences for the company in terms of cost, reputation and legal liabilities. In such a case, modeling what could happen, how one can reduce the risk and assessing whether the residual risk is acceptable would be the next steps.

Shared responsibility – not only in the cloud

Cloud providers talk a lot about the shared responsibility model (AWS version). The responsibility for security of software and data in the cloud is shared between the cloud provider and the cloud customer. They have documentation on what they will take care of, as well as what you as a customer need to secure yourself. For the work that is your responsibility, the cloud provider will typically give you lots of advice on good practices. This is a reasonable model for managing security across organizational interfaces – and one we should adopt with other business relationships too. 

The most mature software vendors will already work like this, they have descriptions of their own security practices that you can read. They also have advice on how you should set up integrations to stay secure. The less mature ones will lack both the transparency and the guidance. 

This does not necessarily mean you should stay away from them (unless they are very bad or using them would increase the risk in unacceptable ways). It means you should work with them to find good risk mitigations across organizational interfaces. Some of the work has to be done by them, some by you. Bringing the shared responsibility for security into contracts across your entire value chain will help grow security maturity in the market as a whole, and benefit everyone. 

Questionnaires are mostly useless – but transparency and shared responsibility is not. 

In Miessler’s vendor security 2.0 post there is a question about what vendor security 3.0 will look like. I think that is when we have transparency and shared responsibility established across our entire value chain. Reaching this cybersecurity Nirvana of resilience will be a long journey – but every journey starts with a first step. That first step is to turn the focus on how you integrate with vendors and how you manage the risk of this integration – and that is a step we can take today. 

Do you consider security when buying a SaaS subscription?

Håkon Olsen2 Comments

tl;dr;  SaaS apps often have poor security. Before deciding to use one do a quick security review. Read privacy statements, ask for security docs, and test authentication practices, crypto and console.log information leaks before deciding if you want to trust the app or not. This post gives you a handy checklist to breeze through your SaaS pre-trial security review.

Over the last year I’ve been involved in buying SaaS access for lots of services in a corporate setting. My stake in the evaluation has been security. Of course, we can’t do active attacks or the like to evaluate if we are going to buy a software, but we can read privacy statements, look for strange things in the HTML and test their login process if they allow you to set up a free account or a trial account (most of them do). Here’s what I’ve generally found of challenges:

  • Big name players know what they are doing, but they have so many options for setup that you need to be careful what you select, especially if you have specific compliance needs.
  • Smaller firms (including startups)  don’t offer a lot of documentation, and quite often when talking to them they don’t really have much in place in terms of security management (they may still make great software, it is just harder to trust it in an enterprise environment)
  • Authentication blunders are very common. From HR support systems to payroll to IT management tools, we’ve found a lot of bad practices:
    • Ineffective password policies (5 digits and digits only, anyone?)
    • A theoretical password policy in place but validation is only performed client-side (that means it is easy to trick the server into setting a very weak password, or even no password in same cases, if you should so desire)
    • Lack of cookie security for session cookies (missing HTTPOnly and Secure flags, allowing for cookie theft by XSS attacks or man-in-the-middle attacks)
    • Poor password reset processes. In one case I found the supposedly random string used for a password reset link to be a base 64 encoding of my username…. how hard is that to abuse?
  • When you ask about development practices and security testing, many firms will lack such processes but try to explain that they implicitly have them because their developers are so smart (even with the authentication blunders mentioned above).

Obviously, at some point, security will be so bad that you have to say “No, we cannot buy this shiny thing, because it is rotten on the inside”. This is not a very popular decision in some cases, because the person requesting the service probably has some reason to request it.

egg power fear hammer
Don’t put your data and business at risk by using a SaaS product you can’t trust. By doing a simple due dilligence job you can at least identify services you definitely should be avoiding!

In order to evaluate SaaS security without spending too much time on it I’ve come up with a process I find works pretty well. So, here’s a simple way to sort the terrible from the average!

  1. Read the privacy statement and the terms and conditions. Not the whole thing, that is what lawyers are for (if you have some), but scan it and look for anything security related. Usually they will try to explain how they protect your personal data. If it is a clear and understandable explanation, they usually know what they are doing. If not, they usually don’t.
  2. Look for security or compliance documentation, or request it from their sales/support team. Specific questions to consider are:
    1. Do they offer encryption at rest (if this is reasonable to expect)?
    2. Do they explain how they store passwords?
    3. Do they use trustworthy data centers, and have some form of compliance proof for good practice for their data centers? SOC-2 reports, ISO certificates, etc?
    4. Do they guarantee limited access for insiders?
    5. Do they explain what cryptographic controls they are using for TLS, signatures and at-rest encryption? That means how they perform key management and exchange, what ciphers they allow, and the key strength they require?
    6. Do they say anything about vulnerability management and security testing?
    7. Do they say anything about incident handling?
  3. Perform some super-lightweight testing. Don’t break the law but do your own due diligence on the app:
    1. Create a free account if possible, and test if the authentication practices seem sound:
      • Test the “I forgot my password functionality” to see if the password reset link has an expiry time, and if it is a unguessable” link
      • Try changing your password to something really bad, like “password” or “dog”. Try to replay post requests if stopped by client-side validation (this can be done directly from the dev tools in Firefox, no hacker tool necessary)
      • Try logging in many times with the wrong password to see what happens (warning, lockout,… or most likely, nothing)
    2. Check their website certificate practices by running sslscan, or by using the online version at ssllabs.com. If they support really weak ciphers, it is an indicator that they are not on the ball. If they support SSL (pre TLS 1.0) it is probably a completely outdated service.
    3. Check for client-side libraries with known vulnerabilities. If they are using ancient versions of jQuery and other client side libraries, they are likely at risk of being hacked. This goes for WordPress sites as well, including their plugins.
    4. Check for information leaks by opening the console (Ctrl + I in most browsers). If the console logs a lot of internal information coming from the backend, they probably don’t have the best security practices.

So, should you dump a service if any of these tests “fail”? Probably not. Most sites have some weak points, and sometimes that is a tradeoff for some reason that may be perfectly legitimate. But if there are a lot of these “bad signs” in the air and you would be running some critical process or storing your company secrets in the app, you will be better off finding another service to suit your needs – or at least you will be able to sleep better at night.

 

Why you should be reading privacy statements before using a web site

Håkon OlsenLeave a comment

If you are like most people, you don’t read privacy statements. They are boring, often generic, and seem to be created to protect businesses from lawsuits rather than to inform customers about how they protect their privacy. Still, when you know what to look for to make up your mind about “is it OK to use this product”, such statements are helpful.

payphone-on-brick-wall_4460x4460
If somebody was wiretapping all of your phone calls you wouldn’t be happy. Why should you then accept surveillance when you use other services? Most people do, and while they may have a feeling that their browsing is “monitored” they may not have the full insight into what people can do with the data they collect, or how much data they actually get access to. 

Even so, there is much to be learned from looking at a privacy statement. If you are like most people you are not afraid of sharing things on the internet, but still you don’t want the platforms you use to abuse the information you share. In addition, you would like to know what you are sharing. It is obvious that you are sharing a photo when you include it in a Facebook status update – but it is obvious that you are sharing your phone number and location when you are using a browser add-on? The former we are generally OK with (it is our decision to share), the latter not so much – we are typically tricked into sharing such information without even knowing that we do it.

Here’s an example of a privacy statement that is both good and bad: http://hola.org/legal/privacy.  It is good in the way that it is relatively explicit about what information it collects (basically everything they can get their hands on), and it is bad because they collect everything they can get their hands on.. Hola is a “VPN” service that markets itself as a security and privacy product. Yet, their website does not use SSL, their socalled VPN service does not use encryption but is really an unencrypted proxy network, they accept users that register with “password” as password, and so on… So much for security. So, here’s a bit on what they collect (taken from their privacy policy):

  • So-called anonymous information: approximate geo-location, hardware specs, browser type and version, date of software installation (their add-on I presume), the date you last used their services, operating system type and version, OS language, registry entries (really??), URL requests, and time stamps.
  • Personal information: IP address, name, email, screen names, payment info, and other information we may ask for. In addition you can sign up with your Facebook profile, from which they will collect usernames, email, profile picture, birthday, gender, preferences. When anonymous information is linked to personal information it is treated as personal information. (OK….?)
  • Other information: information that is publicly available as a result of using the service (their socalled VPN network) may be accessed by other users as a cache on your device. This is basically your browser history.

Would you use this service when seeing all of these things? They collect as much as they can about you, and they have pretty lax security. The next thing in their privacy statement that should be of interest is “Information we share”. What they call anonymous they share with whoever they please – meaning marketing people. They may also share it for “research purposes”. Note that the anonymous information is probably enough to fingerprint exactly who you are, and to track you around the web afterwards using tracking cookies. This is pretty bad. They also state when they share “personal information” – it includes the usual reason; due to legal obligations (like subpoenas, court orders). In addition they may share it to detect, prevent or address fraud, security, violations of policy or other technical issues (basically, this can be whatever you like it to be), to enforce the privacy policy or any other agreements between the user and them, and finally the best reason they share personal information: to protect against harm to the rights, property or safety of the company, its partners, users or the public. So basically, they collect as much as they want about you and they share it with whoever they like for whatever reasons they like. Would anyone be using such a service? According to their web page they have 125 million users.

125 million users accept that their personal data is being harvested, analysed and shared at will by a company that provides “VPN” with no encryption and that accepts the use of “password” as password when signing up for their service.

So, here’s the take-away:

  • Read the privacy policy, look specifically for:
    • What they collect
    • How they collect it
    • What they are using the information for
    • With whom do they share the informaiton
    • How do they secure the information?
  • Think about what this means for the things that are important to your privacy. Do you accept that they do the stuff they do?
  • What is the worst-case use of that information if the service provider is hacked? Identity theft? Incriminating cases for blackmail? Political profiling? Credibility building for phishing or other scams? The more information they gather, the worse the potential impact.
  • Finally, never trust someone claiming to sell a security product that obviously does not follow good security practice. No SSL, accepting weak passwords? Take your business elsewhere, it is not worth the risk.

Do SCADA vulnerabilities matter?

Håkon OlsenLeave a comment

Sometimes we talk to people who are responsible for operating distributed control systems. These are sometimes linked up to remote access solutions for a variety of reasons. Still, the same people do often not understand that vulnerabilities are still found for mature systems, and they often fail to take the typically simple actions needed to safeguard their systems.

For example, a new vulnerability was recently discovered for the Siemens Simatic CP 343-1 family. Siemens has published a description of the vulnerability, together with a firmware update to fix the problem: see Siemens.com for details.

So, are there any CP 343’s facing the internet? A quick trip to Shodan shows that, yes, indeed, there are lots of them. Everywhere, more or less.

shodan_cp343

Now, if you did have a look at the Siemens site, you see that the patch was available from release date of the vulnerability, 27 November 2015. What then, is the average update time for patches in a control system environment? There are no patch Tuesdays. In practice, such systems are patched somewhere from monthly to never, with a bias towards never. That means that the bad guys have lots of opportunities for exploiting your systems before a patch is deployed.

This simple example reinforces that we should stick to the basics:

  • Know the threat landscape and your barriers
  • Use architectures that protect your vulnerable systems
  • Do not use remote access where is not needed
  • Reward good security behaviors and sanction bad attitudes with employees
  • Create a risk mitigation plan based on the threat landscape and stick to it practice too

 

New security requirements to safety instrumented systems in IEC 61511

Håkon Olsen3 Comments

IEC 61511 is undergoing revision and one of the more welcome changes is inclusion of cyber security clauses. According to a presentation held by functional safety expert Dr. Angela Summers at the Mary Kay Instrument Symposium in January 2015, the following clauses are now included in the new draft – the standard is planned issued in 2016:

  • Clause 8.2.4: Description of identified [security] threats for determination of requirements for additional risk reduction. There shall also be a description of measures taken to reduce or remove the hazards.
  • Clause 11.2.12: The SIS design shall provide the necessary resilience against the identified security risks

What does this mean for asset owners? It obviously makes it a requirement to perform a cyber security risk assessment for the safety instrumented systems (SIS). Such information asset risk assessments should, of course, be performed in any case for automation and safety systems. This, however, makes it necessary to keep security under control to obtain compliance with IEC 61511 – something that is often overlooked today, as described in this previous post. Further, when performing a security study, it is important that also human factors and organizational factors are taken into account – a good technical perimeter defense does not help if the users are not up to the task and have sufficient awareness of the security problem.

In the respect of organizational context, the new Clause 11.2.12 is particularly interesting as it will require security awareness and organizational resilience planning to be integrated into the functional safety management planning. As noted by many others, we have seen a sharp rise in attacks on SCADA systems over the past few years – these security requirements will bring the reliability and security fields together and ensure better overall risk management for important industrial assets. These benefits, however, will only be achieved if practitioners take the full weight of the new requirements on board.

Gas station’s tank monitoring systems open to cyber attacks

Håkon OlsenLeave a comment

Darkreading.com brought news about a project to set up a free honeypot tool for monitoring attacks against gas tank monitoring systems. Researchers have found attacks against gas tank monitoring systems at several locations in the United States (read about it @darkreading). Interestingly, many of these systems for monitoring tank levels etc., are internet facing with no protection whatsoever – not even passwords. Attacks have so far only been of the cyberpunk type – changing a product’s name and the like; no intelligent attacks have been observed.

If we dwell on this situation a bit – we have to consider who would be interested in attacking gas station chains at a SCADA level? Obviously, if you can somehow halt the operation of all gas stations in a country, you do limit people’s mobility. In addition to that, you obviously harm the gas station’s business. Two of the most obvious attack motivations may thus be “sabotage against the nation as a whole” as part of a larger campaign, and pure criminal activity by using for example ransomware to halt gasoline sales until a ransom is payed. The latter would perhaps be the most likely of the two threats.

So – what should the gas stations do? Obviously, there are some technical barriers missing here when the system is completely open and facing the internet. The immediate solution would be to protect all network traffic by VPN tunneling, and to require a password for accessing the SCADA interfaces. Hopefully this will be done soon. The worrying aspect of this is that gas stations are not the only installation type with very weak security – there are many potential targets for black hats that are very easy to reach. The more connected our world becomes through integration of #IoT into our lives – the more important basic security measures become. Hopefully this will be realized not only by equipment vendors, but also by consumers.