Fighting Black Swans in AWS

In the tipping point of cyber defense, I proposed a way to get grips with IT Black Swans with the help of simple and fictitious Monte Carlo simulations. Understanding such events is crucial because during an IT risks analysis, the stacking of conventional mitigations fails to curb residual risks.

I proposed to cope with Black Swans in a two-pronged process: first go conventional, then step back and enforce special mitigations called Taleb Fuses.

Elusive fuses

Knowing in which IT context and to which extent Taleb Fuses are strictly necessary is a difficult question: in my article, this is what I meant by finding the "tipping point".

The world of Black Swans is sustained by statistical laws without means and variance, which makes occurrences hard to gauge objectively. Still, IT is far from being the first industry affected by Black Swans: insurance and banks have been living with them for centuries and have been learning from their mistakes along the way (those which survived, at least).

A second difficult problem is to identify Taleb Fuse candidates. In my previous article I didn't provide an example. Today, I would like to suggest a feature which appeared recently in the Public Cloud: permission boundaries.

Introducing AWS Service Control Policies

Permission boundaries were introduced by AWS as part of the AWS organizations service. They are implemented in Service Control Policies (SCP).

For short, SCPs make it easy to describe the maximum set of permissions a principal may have in a given AWS account.

Weakness?

At first, one may see the introduction of SCPs as a way for AWS to acknowledge the shortcomings of its IAM model. Why would we need to place limits since we have a very elaborated IAM policy engine that puts security officers in control of their AWS accounts to the minutest details?

Opportunity!

The truth is that AWS IAM is so elaborated that it becomes less and less explainable and auditable as organization use cases grow complex, numerous and intertwined. This is a natural trend for any big corporation that is moving to any Cloud. What's worse, the almost pervasive use of wildcards and the lack of proper conditions on many services (this is improving fast, by the way) opens up avenues for combinatorial explosions and risks detonations.

We are typically in a Black Swan territory here. Let's be clear about which one because when we talk about the Cloud, there are many: this territory covers privilege escalation (from the customer, not AWS), IAM abuse for data exfiltration (from the customer again) and IAM abuse for unintended third party intrusion.

A "near" Taleb fuse

For years, AWS has been actively seeking to solve this problem by investing in formal proof validation. AWS Zelkova is probably the best known, and it is also one of the oldest tools for automated reasoning about policies they use internally. It offers a very interesting and valuable "bottom up" solution to the problem of leaky IAM permissions, but it cannot cover all the situations comprehensively -at least for now. The thing is, IAM caveats would be better off if applied a holistic treatment.

The Taleb Fuse we are looking for

Permission boundaries come handy to cover IAM Black Swans because of three critical properties:

Permission boundaries are a serious candidate for fighting IT Black Swans because they are unconditional, they cordon, and they are explainable.

Even if they operate at a coarser grain than proof validators, they have the holistic property we are looking for: unconditionality.

In an upcoming article, I will provide another interesting Taleb Fuse not related to the Cloud this time, but which shares the same three crucial properties.