Realizing an information security risk management framework

All organizations face information security risk exposure. Every security manager must confront the reality that there are far more risks than can ever be reasonably managed. So, how does the security team determine which risks deserve its attention?

Every security manager must confront the reality that there are far more cybersecurity risks than can ever be reasonably managed.

From there, how much effort should be put into mitigating a given risk? Not all risks command the same level of resources. What countermeasures are suitable? The Information Security Risk Management Framework (ISRMF) provides a method for answering these important questions.

What is an information security risk management framework?

While definitions vary, an ISRMF is typically a bundle of processes and practices. The framework enables security managers to pinpoint where they are most vulnerable and, then, how to deal with those vulnerabilities.

The NIST Risk Management Framework is one prominent example. It’s required for Federal agencies that must comply with FISMA and related laws. In particular, compliant agencies must follow NIST SP 800-37, the “Guide for Applying the Risk Management Framework.”

Frameworks like NIST’s are based on the principle that risk can never be eliminated. Rather, it must be managed. That is, a good security manager will put maximum resources into protecting the organization from the most serious risks. The NIST framework offers six steps to get to this outcome:

1. Categorize Information Systems (NIST SP 800-60) – Involves categorizing security objectives (e.g. confidentiality, data integrity and defining impact levels as high, low, etc.).
2. Select Security Controls (NIST SP800-53) – Specifies implementing a minimum baseline of security controls.
3. Implement Security Controls – Includes the preparation of controls, setting up of threat detection and analysis methods and tools, threat containment, eradication and recovery as well as post-incident follow-up processes.
4. Assess Security Controls (NIST SP 800-53A) – Requires the assessment of security controls for effectiveness by methods like interviewing stakeholders, as well as the examination and testing of controls.
5. Authorize Information Systems (NIST SP 800-37) – Examines the output of the security controls assessment to determine whether or not the level of risk is acceptable.
6. Monitor Security State (NIST SP 800-137 and SP 800-53A) – Defines a continuous monitoring strategy, including monitoring frequency, metrics and reporting.

The subtext of the entire process delves into the analysis of four interdependent risk factors:

• Threats
• Vulnerabilities
• Likelihoods
• Impacts

A threat is a person or technology that has the potential to attack your organization (e.g. malware or a phishing attack). A vulnerability to the threat occurs when your organization’s defenses against that threat are not adequate (e.g. a deficient firewall). Likelihood is the probability that the attacker will take advantage of the vulnerability. Impact is the effect, usually in dollars, of a successful attack.

Put another way: How likely are you to experience a security incident with a high (costly) impact? Those with high impact obviously deserve the most attention and biggest resource allocations. In the NIST framework, the selection, implementation and assessment of security controls revolves around this question.

The selection, implementation and assessment of security controls can help you determine the likelihood that your organization will become the victim of a high impact incident.

How to realize an ISRMF

There are many details involved to realize an ISRMF. The NIST framework includes multiple Special Publications describing how it should be implemented. Yet, even though there are numerous suggestions and best practices provided, two underlying capabilities make the rest of it possible: Integration and automation.

Integration

Integration is essential to ISRMF implementation because many separate systems must work together to realize a framework’s objectives. Firewalls must communicate with the Intrusion Detection System (IDS) and Security Incident and Event Management (SIEM) solutions. Security monitoring tools work best when integrated with threat databases and specialized detection systems. Everything needs to connect with reporting tools, and on and on.

Today’s security solutions tend to use the Open API Specification as their main mode of integration. Open API details machine-readable Application Programming Interface (API) files that are able to describe, produce, consume and visualize RESTful web services. It’s possible to devise a RESTful web service and API from scratch, but the Open API Specification makes it simpler for multiple software applications to be connected.

Security tools using Open API can expose functional interfaces to one another relatively easily. One tool can request data, send data or invoke a procedure call from another tool using the REST standard and open source languages, like JSON, and common transports, like HTTP.

Automation

Automation, the other capability needed for ISRMF implementation, puts the API-based integrations to work. There are so many moving parts to an ISRMF, automation is extremely useful in making it practical for a security team. Without automation, ISMRF is often overwhelming.

Security automation and orchestration (SAO) and the ISRMF

Security Automation and Orchestration (SAO) tools bring together the potential of integration and automation for an ISRMF. They leverage these capabilities to help security teams automate time-consuming ISRMF processes. And they allow security analysts to focus their expertise on more subjective, important risk management tasks.

Security automation and orchestration (SAO) tools bring together the potential of integration and automation for an ISRMF.

The SAO’s integration functions, which typically use Open API, provide a way to orchestrate automated security processes across multiple systems. For example, in NIST’s Step 3, SAO can be used to set up automated threat detection and analysis. An SAO solution, like Swimlane, can identify a suspicious binary as it appears on the network. Then, it can automatically check it against known threats without the need for human involvement.

To check, Swimlane uses its Open API integration capability to send the binary to a third-party threat intelligence database. The database compares the suspicious binary to known threats. The Swimlane API then receives a message back from the threat database. At that point, if the threat is genuine, Swimlane’s orchestration engine is able to execute a series of automated steps. These include setting up a ticket, emailing key stakeholders, quarantining the threat, updating the threat database and so forth. In this way, Swimlane puts the ISRMF’s concepts into action while avoiding overloading the security team with busy work.

SAO tools also facilitate the implementation of ISRMF steps including monitoring and post-incident follow up. They create logs of the incident response tasks performed. This is a holistic approach that results in time savings in collecting information about the incident for later use.

How Swimlane can help

Swimlane delivers security automation and orchestration that is easy to implement and use. It is known for manageability and scalability. Swimlane allows a security operations team to leverage the capabilities of their existing security solutions to enrich the information presented. Combined with open API-based integration capabilities, these present a powerful means to realize an ISRMF.

To learn more about Swimlane SAO, schedule a demo today.