When planning a hardening project, there are two types of impact analysis you need to think of as part of your plan – policy impact analysis and security impact analysis.
Policy impact analysis refers to generating a report that indicates each policy rule’s impact on your production. It is especially important for avoiding system downtime caused by configuration changes.
The second type of impact analysis is Security Impact Analysis.
Each impact analysis is essential for the security and functionality of your network. The base of each impact analysis is your baseline hardening policy, which should guide you in deciding which configuration change to approve.
In this blog post we’ll dive into the Security Impact Analysis to understand:
- What is (and why should you perform) Security Impact Analysis?
- How to generate Security Impact Analysis?
What is Security Impact Analysis?
Security impact analysis is one of the most critical steps when securing configurations. Its goal is to analyze what will be the security impact of each configuration change on the organization and whether it can expose the organization to attacks. On the other way around, it also indicates how configuration changes benefit the security posture.
Security impact analyses are conducted by teams that deeply understand and know the information system and the potential risks that can be mitigated or exposed by configuration changes.
These teams should take into consideration the impact of changes on security in the following phases:
- Before the change is deployed –
it is critical to conduct a security impact analysis in this stage to understand if there should be any impact of the configuration change on the security posture. This is done before the change is approved so that any security concern can be addressed before investing energy in changing configurations.
- Development and implementation phases –
the way a configuration change is built and implemented can also influence the security impact of the change. It is relevant also when developing new components. Developers should take security into account when developing the component, considering what configuration changes in the system they may require and how will it influence the entire security posture of the system.
- After the change is deployed –
this is mainly to ensure that your security impact analysis was correct, and you didn’t expose your network to unexpected vulnerabilities. In addition, it is important to analyze the security impact of unscheduled or unauthorized configuration changes that often occur during operations.
How to perform security impact analysis?
After conducting a team with the right expertise to generate the security impact analysis, these are the following steps they should follow for each configuration change:
- Overview of the change – when planning to make a change, the first step will be to overview the architecture of the change and how it will be implemented. In case you review a change after it is already made, make sure you get all the documentation and the data by auditing your records, and asking directly the person who made the change. After collecting all the data, investigate the change’s impact on security.
- Identify vulnerabilities in off-the-shelf products- if the change is related to the implementation of a new off-the-shelf product, you should search for known vulnerabilities. By searching the National Vulnerability Database, for instance, you can address known vulnerabilities and mitigate them before the product becomes a part of your network. Vulnerability scanners can also come to hand in this situation. If the change involves the implementation of a costume development, you should also analyze it. Make sure to document each discovered vulnerability and what was done for mitigation.
- Treat each vulnerability according to its risk – not all vulnerabilities are the same. You should assess the risk that each vulnerability you found before taking actions to mitigate it. Identify the likelihood that the vulnerability will be leveraged and the impact of the potential event. You might decide that the risk is too low and can be accepted without remediation. In other cases, you’ll decide that the risk is too high and decline the change or implement safeguards to reduce it.
- Understand how the change will impact existing security controls – for example, the desired change may involve software installation that requires changing the existing baseline configuration. A good practice will be to compare the change to your hardening policy, to see if any conflicts that may indicate vulnerability. In other cases, the change may affect other systems or system components. For example, if you decide to update a database that supports auditing controls, you should take into consideration that auditing activity will be halted while you update the database.
- Develop safeguards and countermeasures – if the desired change exposes the organization to unacceptable risk, you should either choose a different course of action that will allow you to avoid this change or develop a relevant safeguard or practice that will reduce the risk.