How Risky Is Your App?

DZone 's Guide to

How Risky Is Your App?

This article discusses the FIPS 199 and 200 security triple, which represents the confidentiality, integrity, and availability risks and requirements for your app.

· Performance Zone ·
Free Resource

In a previous piece, I outlined the process NIST suggests to evaluate the sensitivity of applications, and they how you can use that analysis to determine the types of security controls you need to implement. I mentioned a couple of standards NIST has come out with through the years, including FIPS 199 and 200, and NIST SP-800-53. FIPS 199 and 200 are pretty quick reads, while NIST SP800-53 is ungodly huge. That's okay though, I'm not talking about 800-53 today. I'll save that for next time. Don't be scared.

Anyway, the process FIPS 199 and 200 outline is straightforward and pretty useful. Basically, you put together a triple, and that triple represents the confidentiality, integrity, and availability risks and requirements for your app (this is from FIPS 199):

{(confidentiality, impact), (integrity, impact), (availability, impact)}

...values for potential impact are LOW, MODERATE, HIGH, or NOT APPLICABLE. Then, you choose the highest level of sensitivity and use that for your entire system (this one is from FIPS 200).

A Single Score?

So, Why do you use the largest value for the entire system? Well, two reasons - the transitive trust and weakest link cyber security principles. First, the weakest link principle describes how most attackers will generally find the weakest link in a system and exploit that. If you have a system that contains sensitive information, and one of the subsystems is insecure, well, that's what's more likely to have vulnerabilities, and it's more likely to be attacked. And why is that attacked? Well, once you've compromised that section, you can hopefully use transitive trust to pivot to more interesting areas in the system. Transitive trust is the act of extending trust from component A, to component B, and then from component B to component C resulting in an implicit trust relationship between A and C that neither A nor C might realize is in place. This kind of things are typical paths for pivoting or privilege escalation.

You can do this in a variety of ways, from evaluating the whole system to evaluating subsystems and rolling them up. Now FIPS requires a high watermark approach, where one high means the entire system is high. You don't necessarily need to follow this (in fact, sometimes you can't) but you do need to make sure that you have very clear separation and controls in place between non-sensitive and sensitive processing (separation of privilege and duties comes into play here). Overall, FIPS would rather you just adopt the highest level of rigor for the whole system because it's just easier, and doesn't really depend on any kind of engineering expertise. This can be useful in acquisition-centric systems where you don't have visibility or control over some or most of the components.

Making It Work

Anyway, I personally find it more meaningful to divide the system into subsystems, and to then evaluate each subsystem. There's a couple of reasons I do this - first, it's easier to understand the function and needs of a smaller subsystem in a concrete way, and second, it allows me to more clearly and accurately characterize the system, even if I'm going to eventually score it with a single value. So, I apply a bit of engineering experience to sub-divide the system, or I follow the previous analysis by the system developers. I do try to clearly understand the dependencies, these are important from a transitive trust perspective. Then, I develop CIA triples for the subsystems, and I take the highest value from all the subsystems and use that to characterize the system as a whole.

This is really useful from a control selection perspective, and I'll cover that next.

analysis, cyber security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}