Cloud is now everywhere and yet we have the overwhelming feeling of déjà-vu: it's a big step forward for infrastructure and end users, and 5 jumps backwards for security. Like it happened for IoT before, it seems that common sense and security best practises must be learned again.

Unfortunately the big Cloud platforms do not help much with the adoption of best security practices. From overbroad permissions to open default values, running a secure infrastructure on the cloud requires time and knowledge.

Cloud security engineers are yet hard to find and security teams are usually thinly spread, Cloud security being rarely the only area they need to focus on. To scale better, teams need to rely on automation. Cloud security automation today doesn't use the full possibilities offered by cloud infrastructure.

Since the first release of nmap in 1997, a lot of progress has been done in the vulnerability scanning space. From simple version detection to fully automated exploits, detection of vulnerabilities has improved dramatically, helping teams focus on securing their most critical assets.

I define security scanning as a 4 steps process:

inventory
data collection
data analysis
action/remediation

These steps apply to vulnerability scanning, penetration testing, compliance scanning and other fields as well. These steps are usually excected with variable degrees of automation. As Alaeddine mentions in https://blog.ostorlab.co/autonomous-security-scanning.html, there are multiple levels of automation.

1 Inventory

Inventory is not a simple list of IPs or assets. Without metadata, an inventory is just another outdated piece of data, like your wish list to Santa from last year.

To be usable, inventory should:

Be always up to date - freshness of the data should suit your needs and the dynamism of your organisation

Contain ownership information - who owns this piece of infrastructure, who can act on it

Contain freshness information - when was this asset created, last seen, updated

For example in DNS, there is freshness (TTL), ownership information (WHOIS) and up to date (resolvers are updated if the TTL is expired). This is a good inventory of domain names.

It may sound like an evidence, but this step is the most critical and often the most neglected.

In cloud environments, most of the inventory is readily available, but not necessarily in a directly usable form. For instance, ownership of assets could be extracted from IAM policies, but this step usually require custom made solution to have usable data.

2 Data collection

With data analysis, this step is the one for which automation works relatively well. Once the scope has been defined, data collection runs mostly smoothly if the targets are reachable.

Data collection consist mostly in fetching software versions, answer to specially crafted requests or IAM policies.

3 Data analysis

This has made significant progress in the recent years, and most of the security tooling embed at least a version comparison algorithm that identifies vulnerable libraries, outdated hash algorithm usage and common misconfigurations.

The biggest issue at this step is false positive rate and the actual exploitability of the reported vulnerability.

Here we need to take a break to talk about shift left.

This new tendency to report all the versions vulnerabilities to the developers without filtering leads to an information overload on teams that have different priorities. Updating software is the easiest way to prevent vulnerabilities on an infrastructure, but this avalanche of security alerts, like the boy who shouted wolf, gives an unnecessary sense of urgency that hurts the communication in case of real emergencies.

4 Action

Before speaking about actions and remediation, we must define some roles in this process:

The owner of the piece of inventory: this is usually the person running the project in which this asset is needed
The person able to act on this asset: this is usually a developer or an SRE member of said project
The person starting the scan: this can be a time based or human based process, usually owned by security but not necessarily. As an example, there could be an organisation wide requirement to run an automated scan at least once a day, leaving each team the possibility to run it at the most suitable time for them.
The person interested in the statistics of results: usually Leadership and security

In the security/vulnerability scanning space, most of the tools usually assume that all the roles mentioned above are assumed by the same person. This creates a large communication overhead for the receiving end of this process, that still has to find the owner of the asset, contact them, explain them the issue that was found, proof check that the reported issue is actually present and actually an issue (false positive), and make sure that the issue is actually fixed in a reasonable time window.

In our world where security engineers are a rare resource and security teams represent <1% of the workforce to assume all tasks, including tasks as varied as endpoint security, GDPR reviews, threat modelling, detection and prevention, compliance work, the communication overhead eats up most of the benefits of the automation. In large organisations with bad inventory and high turnover, the task becomes almost impossible.

Lifting the assumption of the role distribution will open the road for new designs that will bring us to the next step of automation.

I hope to see more tools with better integration into existing systems and better information distribution enabling a two way communication between the security team and the teams owning infrastructure inside an organisation.