Security Rules

The two most rules in security are:

Rule 1: Protect your assets
Rule 2: See Rule #1

So many security organizations spend too much time chasing threats (or playing cops and robbers on the shareholder's dime), when in reality for most organizations threats are the least important area. Most time and focus should go to asset protection. Learning from Buffett we know the real risk is not volatility but permanent loss (capital in Buffett's world, digital assets in ours). The order of priorities for infosec should look like this:

1. Assets
2. Countermeasures to protect assets (design, deployment and operations) - countermeasures must form fit to the asset
3. Vulnerability management
4. Threat management

In fact, you often see the inverse of this in practice.

Comments

[Adam, asking for his own personal curiosity]

What assets does an OS have? What about an OS component?

[Gunnar]

Hi Adam- Well an OS is an asset, its platform to do other stuff but still an asset, as Pete Lindstrom would say it is worth at least what you pay to build/deploy/operate it. So whatever the ABC Insurance company spends on the OS budget annually, plus how much they pay their sys admins to deploy plus any other ongoing costs associated with provisioning their employees and contractors with all these laptops will give you an idea of the value they place on those assets.

At a minimum, I would quote Brian Snow here and say that I just need my OS to "remain benign and not be actively malicious."

Now for a software component, I would also add in all the design and development that ABC Insurance company spends to build their apps, maintain their apps and so on.

http://1raindrop.typepad.com/1_raindrop/2007/10/network-securit.html

Plus there may be additional confidentiality concerns and reliability concerns based on the business actions and decisions taken by the data the app is processing.

[Alex]

This is (hopefully) an extremely rare case, but I just couldn't disagree with you more.

I don't think you can discuss prioritization of information gathering and/or efforts in such a linear manner.

Think of Dan Geer's question: "Are we secure enough?" (Which I think we can say is a simple version of my question, "Is the risk we have within the context of our organizational tolerance").

To answer this question we *have* to look to "risk" - in which case even the crappiest of equations includes a necessity of information surrounding variables or "factors" that include "threat", "control", and "value".

Now if we remove one of these factors, our ability to answer that question tends to fall apart. Similarly, prioritization of certain information gathering efforts are going to suffer if we are missing those contexts. So without understanding which threat communities we most need to consider, our ability to assign relative value to assets is nominalized. Without considering what threat communities are most applicable, then our ability to prioritize countermeasures and resources for creating processes and maturity of processes will similarly be almost too broad to be useful. We will be forced to consider 'everything' which to me means we're considering nothing at all (until we build our own ad hoc manner of threat consideration).

Now all that to say I'm not suggesting a different linear prioritization that starts with "Threat Management". Rather a high level gathering of information across all four of your suggested domains that is processed together in context. From the results of that analysis, a deeper dive in order to prioritize efforts may or may not be needed, but if it is - then another lower level gathering of information occurs in which the information is gathered and considered together in context.

This, to me, is risk analysis.

[Adam, not speaking for his employer]

So, if you're designing and building an OS, does that help you threat model it?

You have customers ranging from your mom to the CIA and the KGB, and that insurance company.

I don't think that asset-centricity is the only or best way to go in this instance.

[Gunnar]

Alex: Not saying remove focus on threats, saying don't overfocus on threats. Not because they are not important, but because you will never guess all of the threats, and a lot of threat information is not actionable. The list of priorities I advocated is based on what is most actionable where you can be effective spending your time, with some elbow grease I can build a pretty good end to end lifecycle of an asset that I own. I can find teh weak points in that lifecycle and shore them up. I can use threat modeling to help understand my vulnerabilities better. What I can not do is understand the end to end lifecycle of all my threats.

Adam: Perhaps the asset is your relationship with your customer, perhaps its the availability of services. Did not say the asset is a hard, physical asset. A lot of my customers are in financial services, insurance and so on, so I am happy to cheat and commercial, enterprise metrics to weigh their assets. In an OS vendor case, the assets aren't as weighable, so the assets are softer.

[Alex]

"The list of priorities I advocated is based on what is most actionable where you can be effective spending your time, with some elbow grease I can build a pretty good end to end lifecycle of an asset that I own."

Again, I disagree. The relative state of maturity around those processes is going to drive the need to reduce uncertainties. You can just walk up to J Random Asset and start SDLCing, to be sure - but without considering all parts of the equation in necessarily equal context, that seems like a wasteful approach.

[Gunnar]

Alex: can you enumerate half of threats your system faces? I doubt it. Can you enumerate 90+% of the assets you own? I certainly hope so. Again the prioritization I suggest is *not* driven by importance its driven by effectiveness of follow on actions. So invoke Bryan Ware, we want to ideally focus on high risk areas where we have highly effective controls. (hard to find). Absent that chocie, we have the choice of spending time/focus/money on high risk areas with low effectiveness countermeasures (what I deem the current state of threat management today) or low risk highly effective countermeasure (what I deem asset focused). So this is clearly a Hobson's choice but if you have a $100 to spend you gotta pick one. I am hopeful if more organizations take this approach it would lead to better controls over time. Sure would be nice if the people working on high risk areas would also develop highly effective tools, right?

http://1raindrop.typepad.com/1_raindrop/2006/08/combining_risk_.html