Risk based security is incredibly popular in information security nowadays. However, this is not the only way. I listened to the episode 191 of the Risky Business Podcast. In that episode, Patrick Gray interviews Brian Snow, former NSA director. He provides some experience-based thoughts on probabilistic risk assesment (PRA) and proposes alternative approaches in Infosec:
- Useful in scenarios with benign players (e.g. when Nature is the threat agent)
- Useful when there is enough good solid statistical information in the form of distributions curves and failure rates.
- The problem comes when trying to mitigate:
a. high impact risks with very very low probability or
b. a handful of low probability events with low impact that, if all of them happen in concert, the impact is huge.
- Probabilistic risk assessment does not take malice into consideration. When malice comes into play, distribution curves do not matter.
- Attackers do not use PRA as their main methodology to select targets (I would add, they choose their targets based on their relevance - benefit to risk ratio - and potential economic or mental benefit).
- PRA works well for reliability in a benign environment.
Thinking outside PRA (e.g in product security)
- Economic terms help i.e. let's design a system that is cheaper to create than the effort to attack it (this takes even decades!).
- How much (money) can the attacker devote to hit us?
- Forget studying the probability of malice-based acts, get some people in your security team thinking like the opponent. Look for the malice.
- Commercial product creators are not thought to counter malice.
- Military principles e.g. simple interfaces are required when you counter malice.
- It takes time to design security (quick time to market is not possible).
- Will the product work under attack? This is a key question to answer.
- Have an holistic attack team, at the design time, to systematically attack the product.
- 3 recommendations:
a. Make sure that you study the interactions among the different scenario dimensions and players. Pay more attention to the interactions.
b. Once you are under attack, whom can you call for help? Look for partnerships (especially intelligence sharing) in the industry arena, even among competitors (e.g. CERTS already do that).
c. Have some attack scenarios that you exercise yourself (even at design time). Think in advance and try to prepare yourself against them already at design time.
Food for thought. Enjoy and digest it!