Assessing Risk

The Risk Problem

All organizations should assess the risks of all technologies used to conduct their business. An organization that does not do so risks unexpected and severe disruptions of operations or personal/organizational damage to reputations. In extreme cases an organization could even cease to exist. Risk assessment and mitigation allows business management to understand risk, and matches an organization's risk tolerance with  project decisions.

Risk management is not a black and white, one size fits all process. One organization's unacceptable risk might be another's  non-issue. IT's role in this process should be to transparently and objectively communicate risk to business leaders. Too many times risk has been a process of private opinions with vendors and IT workers using Fear, Uncertainty, and Doubt to sell solutions to the organization. Decision makers understand this and feel uneasy because they can't gauge the difference between what someone wants and what must be done.

In our opinion, communicating risk has always been a problem which is independent of technology choices and organizational appetite for risk. Approaches that appeal to technological wizardry and the black arts of penetration testing  can only measure what is already understood and vary from expert to expert. Approaches that assign mathematical values to risk pretend an objectivity that does not exist. Asking an expert if something is "secure" does not lead to actionable business intelligence. 

A better approach is to appeal to best practices and standards. The process of comparing systems to the consensus of the security community reduces personal prejudices and different levels of assessor skills. In the event of a breach, it is also a measure of proof that reasonable precautions were taken. COBIT or the NIST 800 series are broad frameworks of a repeatable assessment process.

We particularly like how FIPS 199 lays out a methodology to rank security priorities. The standard lays out three criteria for security, which are, Confidentiality, Integrity, and Availability. Confidentiality is a measure of desired secrecy. Integrity is a measure of the importance to protect data or systems from unauthorized modifications. Availability is a measure of the need to have the data available when needed. 

We break up availability into two components. The first is Service Availability which is a measure of how long a service can be unavailable. A good example of this is your email or web services. A disruption of your customers ability to send you emails or view your main web page could be quite disconcerting to them and might cost sales if the customers question if you are a going concern.

The second component of availability is Transactional Availability. This is a measure of a business process tolerance of a lost transaction. A bank places very high importance to the Transactional Availability of their automated teller machine networks. An ATM being down is an inconvenience but imagine your concern if your cash deposit was lost. 

Many smart security people would say that Transactional Availability is really part of Integrity. They are correct, but we have found it useful to discuss it under availability with business leaders.

In general we use Confidentiality to discuss remote access, network segmentation, vulnerability management, client device security and system interconnects, etc. We discuss roles and identity management under Integrity and use Service Availability to discuss load balancing, fail over, geographical dispersal and disaster recovery while we discuss databases and transaction logs with Transaction Availability.  

These standards are a great way to frame a discussion with business leaders and discover how they perceive and value the data in a particular system. This process helps us guide a decision maker's attention to particular security controls and limits unnecessary attention to controls they would not value.  

An offshoot of a standards based security program is regulatory or contract negotiated privacy and security compliance. Sometimes the people who collect the data are not the people who suffer most if the data is breached. Financial people might call this a "moral hazard". I may spend less protecting your personal information than you would because you bear the cost if a breach happens.

Society and some organizations recognize this imbalance and pass laws or contract compliance programs like the Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI DSS) or parts of Sarbanes-Oxley (SOX).

It tells us something if we know that a business partner maintains HIPAA compliance with regular audits or if a system we wish to interconnect with is maintained to a NIST medium.

In either case, security standards and compliance programs are great ways to improve risk communications and we consider them the best way to implement security controls in a project. They however have some flaws.

First, a system can comply to all standards and still be breached. Nothing is perfect and a standards approach does not give insight into the residual risk of a compliant system. Second, a system can be completely compliant to standards and have underlying and serious flaws. Security standards based risk assessment really measures compliance to a standard and does not really measure how "secure" a system is.

An intriguing possibility is to use Data Breach Insurance  as a way to measure organizational risk and prioritize security projects. Organizations do not normally think this way about IT risk so some examples might help.

Suppose you wish to purchase a vehicle for your sixteen year old. She wants the latest Camaro with the large V8 engine.  Your spouse suggests that the latest "Your Father's" Oldsmobile is exactly the same price and maybe "safer".

Your automobile insurance company can provide a objective and quantified measure of "safer". Suppose that you discover that the Camaro's insurance cost is three times that of the Oldsmobile. For the sake of the argument let us assume you investigate the costs of repairs and discover they are the same for each model.

The difference in insurance price between the models is the risk premium. The Camaro is three times less safe (from all possible losses) than the Oldsmobile.