Discovery for Security Processes
Beyond integration into CMDB, there are many other areas, where discovery can be of immense value. One such pretty unknown area is It security.
Discovery as part of ITIL asset management is also a foundation building block for security. In this first part of two videos regarding security use cases for discovery, we look at how to use discovery for creating a threat and risk assessment and security concept and how to support vulnerability management with up-to-date asset information from the environment.
IT Asset Management in Security Process
Security is not only relevant during software development but accross whole life-cycle of a system. In the video we illustrate this using the NIST cybersecurity framework. IT assets and threats need to be identified, the system be protected against attacks, which need to be detected and an incident response processes started, in case there is a breach. Finally the system or environment needs to be recovered after a compromise.
When I’m not writing blog post or creating videos for JDisc, I’m member of the security guild of a large company in the Stuttgart area and introduced the security process in a new business unit and support development teams in setting up a secure development process. With this experience I think I qualify to write about security in the enterprise context.Peter Klotz
In this framework, IT asset management plays a critical role in the identification phase. You can only protect assets that you know they exist and only detect attacks for assets that have previously been identified and taken into the security monitoring process. Therefore having a complete and detailed list of assets that make up a system is a crticial prerequisite for the security activities.
This IT asset management, where discovery fits in in the ITIL framework, is the basis for further activities in the security process. For example it is a critical early step in creating a threat and risk assessment of a product or system and required for a complete and continous security monitoring in the detect phase. Also a discovery tool can serve well in the analysis of a incident response process.
Threat & Risk Analysis
When developing a new system or product, there are two main documents that are normally written for security at least:
- Threat and risk assessment (TRA)
- Security concept
The threat and risk assessment identifies the threats and risks for the system so that security requirements can be derived that are then detailed and made concrete in the security concept. While there are many specific ways how to write a TRA, it usually starts with understanding the context such as relevant standards and procedures that need to be followed in the organization. Next one identifies the data that is being processeed, stored or transferred and this data is classified regarding security goals such as confidentiallity, integrity and availability (so called CIA triade).
The data, primary assets, that flows through the system determine the protection need but security is implemented on the supporting assets. Supporting assets are the software components that store, process or transfer the primary assets. This is the point where IT asset management comes into play, we need to identify all these components so that we can later secure them. This is where, among other tools, a discovery tool can support, especially for assets that are already deployed. Of course in a project supporting assets will also include services that are not yet deployed as they are being developped in the course of the current project. But details of the network environment or existing database or other infrastructure services can be taken from discovery data.
When performing a classical threat and risk analysis, the next step is to find all possible threats for the identified supporting assets, rate these regarding likelihood and impact and identify the risk associated with these threats.
Finally we would come up with security requirements for the security concept.
This only works if the project has corresponding security experts staffed, that understand both the system domain as well as the security threats well enough. Unfortunately this is more often than not, not the case. Therefore instead one can find for each supporting asset a corresponding security requirement standard or best practice, written by industry and domain experts, that pre-defines what security measures should be taken for a certain type of asset. Such requirement catalogs exist for web services (OWASP application security verfication standard, ASVS), mobile or IoT devices, operating systems and application server but also cloud and virtualization environments (CIS benchmarks from the Center of Internet Security). Other examples of domain specific best practices are IEC 62443 for industrial control systems (IACS).
These requirement catalogs can simply be applied for the corresponding security level identified previously and a baseline security can be established on this basis. Discovery was in this process an important basis to get a complete list of supporting assets. Independend of what specific process is used, none should be forgotten, even if some very primitive devices cannot be secured, transparency ensures that we have at least considered security for these assets, too.
The second area of security we cover with this video is the vulnerability management process, that starts with development and extends way into operational security, after release of the system or product. In vulnerability management, we try to identify all known weaknesses that are present in the supporting assets that have previously been identified.
Sources of known vulnerabilities such as the National Vulnerability Database (NVD) from NIST but also corresponding data sources from operating system vendors as well as security advisories provide CVEs (Common Vulnerability and Exposures) that need to be mitigated.
What is important in vulnerability management is of course to have a complete list of assets and checking the CVEs for all of them and to clearly identify the asset not only its name but also exact version of the component. Otherwise no CVE can be found, although they exist. Discovery can help with an automatic classification of the component and provide all the details needed.
The mapping to CVEs is usually done in a specialized system, such as OWASP dependency track or corresponding commercial solutions. So information about the assets needs to be exported as a software bill of material (BoM), that can be loaded into the vulnerability management tool in the form of corresponding standards such as CycloneDX or SPDX.
We will see in the next video just how important asset management is for security beyond the touch points covered in this article.