4 – Leveraging Assessment Management

Risk Management, Policy Management, Assessment Management and Incident Management are the four components of an Information Security Management System described in How to Manage Cyber Security Risk – A Security Leader’s Roadmap with Open FAIR. “The ideal is to deliver a periodic census of the security requirements compliance status for all instances of all controls.” This post will briefly examine measuring compliance status for the infrastructure and applications in scope for an enterprises’ risk analysis. This data helps inform estimating risistance strength for a FAIR analysis of relevant enterprise risk. Content of the next two sections are from How to Manage Cybersecurity Risk.

Assess Hosts and Networks

Compliance tests for hosts can be performed by vendor-provided or locally developed tools which are implemented to fulfill the control testing requirements. Requirements involving computing and network hardware drive inspection to test implementation. The assessment management system also receives periodic updates to control requirements, including occasional immediate change notifications. Obviously, these updates also need to trigger changes to the assessment tests. Less obvious is the need for assessment status reporting to distinguish when requirement changes have occurred. For example, a control may have been in compliance for many months, then suddenly fall out of compliance. The reader should easily understand the cause of non-compliance is the requirement change, and perhaps have indication of the schedule for bringing the control into compliance. {words about how this is used in risk analysis}

Assess Applications

Assessing applications ties directly to the security development life cycle. Manual or automated testing is used in the latter stages of development to discover or confirm the absence of security defects. These testing methods change over time in response to discoveries of potentially common code weaknesses, so periodic retesting is prudent. Compliance reporting can summarize quantities and severities of assessment findings with corrective action due dates. Security control requirements can mandate corrective action timelines based on severity. One challenge today is associating severity ratings from testing tools to the organization’s quantitative risk analysis. Consider the difference between an application that has users only within the organization’s intranet compared with an Internet-facing application: the threat event frequency is vastly different.

Host and Network Security Compliance

Security policy for hosts and networks specifies conditions that must be met. Compliance testing, automated where possible, measures server and network component instances to confirm compliance or to gather data about the non-compliant state. The test results are provided in human readable dashboards, from high-level summaries to the most minute drill-down detail.

An enterprise FAIR analysis may have a scope that includes all instances of the enterprise’s servers and networks, or may be a subset. For example, if the risk is related to the availability of customer-facing services, only the compliance testing results for the servers and networks related to the customer-facing service are relevant.

There are two characteristics to consider when estimating Resistance Strength (RS) for the FAIR analysis. First, estimate the RS based on the design specified in the security control requirement. Next, estimate how the RS is degraded by the non-compiant instances.

Now the organization has a basis to compare RS for the required compliance to the actual degradedation from non-compliance. A corrective action plan for the non-compliance state can be estiblished and its costs estimated. This can be compared to the difference between the expected risk and the actual risk (accounting for non-compliance), thereby providing a business case.

Application Security Compliance

Security policy for applications is integrated in the enterprise’s standard application development process, regardless of the methodology involved. The confidentiality, integrity and availability requirements muct be specifically defined. For example, a requirements phase includes considerations like what information requires access controls and what types of users are permitted which kind of actions. In addition, there are requirements to ensure the strength of interfaces, particularly user-system interfaces. Threat modeling is one technique that can be incorporated in the enterprise’s standard application development process.

Ideally, as each requirement is instantiated in the system design, a test is defined to exercise the requirement. There are also vendor-provided testing tools that mimic threat actions.

In contrast to host and network compliance testing, which is performed periodically, application security compliance testing is performed as a part of the development and maintenance life cycles. Similar to host and network compliance testing, the application security compliance testing can be displayed in dashboards with drill-down capability. One essential design for compliance reporting is that the enterprise maintain application and host inventories indexed to each other, to enable non-compliance resolution, particularly where a non-compliant host configuration is necessary based on the hosted application, which must be modified to resolve the issue.

Example Compliance Report with Host Details Displayed under Application

Just as with host and networks, there are two characteristics to consider when estimating Resistance Strength (RS) for the FAIR analysis. First, estimate the RS based on the design specified in the security control requirement. Next, estimate how the RS is degraded by the non-compiant instances.

Now the organization has a basis to compare RS for the required compliance to the actual degradedation from non-compliance. A corrective action plan for the non-compliance state can be estiblished and its costs estimated. This can be compared to the difference between the expected risk and the actual risk (accounting for non-compliance), thereby providing a business case.

Implication for Threat Modeling with ArchiMate and Open FAIR

Threat Modeling can be an important technique in the development of an application, providing a view of the security posture of an application. But on its own, threat modelng cannot support developing a business case for enterprise security control improvements.

Application systems rely on host and network security which are ideally managed organization-wide, with a single security control compliance monitoring system employed. These elements can and should be included in threat models. Standard ratings can be established so the threat modeling team need only be concerned with applications’ user and component interfaces.

What remains are interactions among processes and external interactions. It would appear that the more these interactions can be standardized, the fewer instances of relative resistance strength (RS) need to be understood. Where the RS is too low relative to a FAIR scenario, it now becomes possible to identify the organization-wide cost to improve RS to have a business case for enterprise risk reduction.

Summary and Next Steps

These ideas are provided as inspiration for improving the ability of threat modeling to influence enterprise funding for risk reduction projects. Readers are encouraged to provide suggesting to improve accuracy and clarity.

Should the concept be supported, the next step is to propose an Open Group Security Forum project potentially titled: Threat Modeling with ArchiMate and FAIR Guide. I recommend the project be lead by the Security Forum and to be a joint project with the ArchiMate forum.

Back to Introduction