The European Union Agency for Cybersecurity (ENISA) released its Guidelines for Securing the IoT, which covers the entire IoT supply chain – hardware, software and services.
Supply chains are currently facing a broad range of threats, from physical threats to cybersecurity threats. Organisations are becoming more dependent than ever before on third parties.
As organisations cannot always control the security measures of their supply chain partners, IoT supply chains have become a weak link for cybersecurity. Today, organisations have less visibility and understanding of how the technology they acquire is developed, integrated and deployed than ever before.
“Securing the supply chain of ICT products and services should be a prerequisite for their further adoption particularly for critical infrastructure and services. Only then can we reap the benefits associated with their widespread deployment, as it happens with IoT,” said Juhan Lepassaar, Executive Director, ENISA.
In the context of the development of the guidelines, ENISA has conducted a survey that identifies the existence of untrusted third-party components and vendors, and the vulnerability management of third-party components as the two main threats to the IoT supply chain. The publication analyses the different stages of the development process, explores the most important security considerations, identifies good practices to be taken into account at each stage, and offers readers additional resources from other initiatives, standards and guidelines.
As in most cases pre-prepared products are used to build up an IoT solution, introducing the concept of security by design and security by default is a fundamental building block to protect this emerging technology. The agency has worked with IoT experts to create specific security guidelines for the whole lifespan of IoT devices.
These guidelines to help tackle the complexity of IoT focus on bringing together the key actors in the supply chain to adopt a comprehensive approach to security, leverage existing standards and implement security by design principles.
According to a recent study, only a minority of software developers are actually working in a software development company. This means that nowadays literally every company builds software in some form or another.
As a professional in the field of information security, it is your task to protect information, assets, and technologies. Obviously, the software built by or for your company that is collecting, transporting, storing, processing, and finally acting upon your company’s data, is of high interest. Secure development practices should be enforced early on and security must be tested during the software’s entire lifetime.
Within the (ISC)² common body of knowledge for CISSPs, software development security is listed as an individual domain. Several standards and practices covering security in the Software Development Lifecycle (SDLC) are available: ISO/IEC 27024:2011, ISO/IEC TR 15504, or NIST SP800-64 Revision 2, to name some.
All of the above ask for continuous assessment and control of artifacts on the source-code level, especially regarding coding standards and Common Weakness Enumerations (CWE), but only briefly mention static application security testing (SAST) as a possible way to address these issues. In the search for possible concrete tools, NIST provides SP 500-268 v1.1 “Source Code Security Analysis Tool Function Specification Version 1.1”.
In May 2019, NIST withdrew the aforementioned SP800-64 Rev2. NIST SP 500-268 was published over nine years ago. This seems to be symptomatic for an underlying issue we see: the standards cannot keep up with the rapid pace of development and change in the field.
A good example is the dawn of the development language Rust, which addresses a major source of security issues presented by the classically used language C++ – namely memory management. Major players in the field such as Microsoft and Google saw great advantages and announced that they would focus future developments towards Rust. While the standards mention development languages superior to others, neither the mechanisms used by Rust nor Rust itself is mentioned.
In the field of Static Code Analysis, the information in NIST SP 500-268 is not wrong, but the paper simply does not mention advances in the field.
Let us briefly discuss two aspects: First, the wide use of open source software gave us insight into a vast quantity of source code changes and the reasoning behind them (security, performance, style). On top of that, we have seen increasing capacities of CPU power to process this data, accompanied by algorithmic improvements. Nowadays, we have a large lake of training data available. To use our company as an example, in order to train our underlying model for C++ alone, we are scanning changes in over 200,000 open source projects with millions of files containing rich history.
Secondly, in the past decade, we’ve witnessed tremendous advances in machine learning. We see tools like GPT-3 and their applications in source code being discussed widely. Classically, static source code analysis was the domain of Symbolic AI—facts and rules applied to source code. The realm of source code is perfectly suited for this approach since software source code has a well-defined syntax and grammar. The downside is that these rules were developed by engineers, which limits the pace in which rules can be generated. The idea would be to automate the rule construction by using machine learning.
Recently, we see research in the field of machine learning being applied to source code. Again, let us use our company as an example: By using the vast amount of changes in open source, our system looks out for patterns connected to security. It presents possible rules to an engineer together with found cases in the training set—both known and fixed, as well as unknown.
Also, the system supports parameters in the rules. Possible values for these parameters are collected by the system automatically. As a practical example, taint analysis follows incoming data to its use inside of the application to make sure the data is sanitized before usage. The system automatically learns possible sources, sanitization, and sink functions.
Back to the NIST Special Papers: With the withdrawal of SP 800-64 Rev 2, users were pointed to NIST SP 800-160 Vol 1 for the time being until a new, updated white paper is published. This was at the end of May 2019. The nature of these papers is to only describe high-level best practices, list some examples, and stay rather vague in concrete implementation. Yet, the documents are the basis for reviews and audits. Given the importance of the field, it seems as if a major component is missing. It is also time to think about processes that would help us to keep up with the pace of technology.
FIRST releases updated coordination principles for Multi-Party Vulnerability Coordination and Disclosure
The Forum of Incident Response and Security Teams (FIRST) has released an updated set of coordination principles – Guidelines for Multi-Party Vulnerability Coordination and Disclosure version 1.1.
Stakeholder roles and communication paths
The purpose of the Guidelines is to improve coordination and communication across different stakeholders during a vulnerability disclosure and provide best practices, policy and processes for reporting any issues across multiple vendors.
It is targeted at vulnerabilities that have the potential to affect a wide range of vendors and technologies at the same time.
Previous best practices, policy and process for vulnerability disclosure focused on bi-lateral coordination and did not adequately address the current complexities of multi-party vulnerability coordination.
Factors such as a vibrant open source development community, the proliferation of bug bounty programs, third party software, supply chain vulnerabilities, and the support challenges facing CSIRTs and PSIRTs are just a few of the complicating aspects.
Art Manion, Vulnerability Analysis Technical Manager, CERT Coordination Center said: “As software development becomes more complex and connected to supply chains, coordinated vulnerability disclosure practices need to evolve. The updated Guidelines are a step in that evolution, deriving guidance and principles from practical use cases.”
The Guidelines for Multi-Party Vulnerability Coordination and Disclosure contains a collection of best current practices that consider more complex as well as typical real-life scenarios that go beyond a single researcher reporting a vulnerability to a single company.
The Guidance includes:
- Establish a strong foundation of processes and relationships
- Maintain clear and consistent communications
- Build and maintain trust
- Minimize exposure for stakeholders
- Respond quickly to early disclosure
- Use coordinators when appropriate
- Multi-Party Disclosure Use Cases
FIRST Chair, Serge Droz said: “The Guidelines for Multi-Party Vulnerability Coordination and Disclosure is an important step towards a better and more responsible way of managing vulnerabilities.
“It was crucial that these Guidelines were created in tandem with key stakeholders who may be affected by multi-party vulnerabilities. I am proud that FIRST was able to bring these stakeholders together to work on this very important document.”
The U.S. Department of Justice’s Cybersecurity Unit has released guidelines for organizations that want to gather cyber threat intelligence from dark web forums/markets but, at the same time, want to stay on the right side of the (U.S. federal criminal) law.
The document focuses on “information security practitioners’ cyber threat intelligence-gathering efforts that involve online forums in which computer crimes are discussed and planned and stolen data is bought and sold. It also contemplates situations in which private actors attempt to purchase malware, security vulnerabilities, or their own stolen data—or stolen data belonging to others with the data owners’ authorization—in Dark Markets.”
It was compiled based on input from the US DOJ’s various divisions, the FBI, the U.S. Secret Service and the U.S. Treasury Department’s Office of Foreign Asset Control. In it, DOJ’s Cybersecurity Unit advises organizations on how to avoid becoming a perpertrator (consult with legat counsel, ask the FBI’s opinion before engaging in some legally murky activities) and a victim (institute security safeguards and adhere to cybersecurity practices that will minimize the risk of being victimized).
DOs and DON’Ts
- Gather cyber threat intelligence passively
- Access forums lawfully (by obtaining login credentials legitimately, for entirely fake personas)
- Ask questions and solicit advice on the forum (but document that they are doing that just for the purpose of gathering info, not committing a crime)
- Access forums unlawfully (by using stolen credentials, impersonating the identity of an actual person, including a government official, or using an exploit)
- Surreptitiously intercept communications occurring on a forum
- Provide the forum operator with malware or stolen personal info in order to gain access to the forum or provide other forum participants with useful information, services, or tools that can be used to commit crimes in order to get their trust
- Solicit or induce the commission of a computer crime
- Assist others engaged in criminal conduct (through advice or action)
- Involve their legal department in operational planning
- Share information about an ongoing or impending computer crime uncovered during intelligence gathering activities with law enforcement
Cybersecurity companies that monitor dark markets for specific types of information as a service to their customers – whether that’s stolen customer records offered for sale, malware or security vulnerabilities that target their customers’ networks or products – have additional specific things to take into consideration when attempting to purchase it (e.g., buying the data from a foreign terrorist organization is unlawful, and so is buying malware that is designed to intercept electronic communications surreptitiously).
The EU Agency for Cybersecurity (ENISA) published a cybersecurity procurement guide for hospitals.
The hospital is a vast ecosystem comprised of an entire network of devices, equipment and systems that often require connection to external systems, making monitoring and control a very hard task to do. This is due to the high sensitivity of medical data and the potential vulnerability the sector is faced with, cybersecurity has to be applied every step of the way to ensure patient data privacy and the availability and resilience of healthcare services at the same time.
A cybersecurity procurement guide for hospitals
The Procurement Guidelines for Cybersecurity in Hospitals published by the Agency is designed to support the healthcare sector in taking informative decisions on cybersecurity when purchasing new hospital assets. It provides the information to be included in the procurement requests that hospitals publish in order to obtain IT equipment.
This new report outlines good practices and recommendations for including cybersecurity as a provision in the procurement process in hospitals. Initially the report presents the set of hospital assets and the most prominent cybersecurity threats linked to them.
After categorising the procurement process in three steps, namely “Plan, Source and Manage”, it identifies the cybersecurity requirements associated with each step. To make this even easier, the guide provides suggestions for evidence on how the requirements can be fulfilled by the provider.
The EU Agency for Cybersecurity, Executive Director, Juhan Lepassaar, stated:
“Protecting patients and ensuring the resilience of our hospitals are a key part of the Agency’s work to make Europe’s health sector cyber secure”
Who can use the guide?
This report is addressed to healthcare professionals occupying technical positions in hospitals, i.e. Chief-level executives: CIO , CISO, CTO, IT teams as well as procurement officers in healthcare organisations.
It may be of interest to manufacturers of medical devices that provide products to hospitals (medical devices, clinical information systems, networking equipment, cloud services, etc.). When these manufacturers offer services or products, they will know the security requirements that the hospital expects them to fulfil and they can provide evidence to prove it.