When planning a hardening project for information security, there are two types of impact analysis to consider - 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, including all network devices. The base of each impact analysis is your baseline hardening policy, which should be regularly updated through continuous monitoring to guide decision-making on configuration changes.
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?
In any comprehensive security plan, Security impact analysis is critical to securing configurations. Its goal, a critical aspect of risk management, 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 of the system.
In security engineering, 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 - In this stage, it’s critical to conduct a security impact analysis to determine the extent of the impact of the configuration change on the security posture. Do this before the change is approved so that any security concerns can be addressed before investing energy in changing configurations.
- Development and implementation phases -
the way a configuration change is built and implemented influences its security impact. 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, in line with NIST SP guidelines.
- 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. This is a critical phase in the certification and accreditation process.
Security Impact Analysis Checklist: 5 Essential Steps
These are the following steps your team should follow for each configuration change:
- Overview of the change - when planning to make a change, the first step is to overview the architecture of the change and how it will be implemented. If 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 security impact.
- 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 enters your network. Vulnerability scanners are also useful here. If the change involves the implementation of a costume development, you should also analyze it. Document all vulnerabilities and mitigation measures.
- Treat each vulnerability according to its risk - not all vulnerabilities are the same. You should assess the risk of each vulnerability you find before taking action. 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, risk may be too high, so 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. 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, auditing activity will be halted while you update the database.
- Develop safeguards and countermeasures - an essential step in risk management is to evaluate whether the desired change exposes the organization to unacceptable risk. If it does, 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.
