I'm a cyclist. Not necessarily a very good one, but I can hold my own in the middle of the pack.
On group rides you always have the person who locks into a gear and sticks with it. Their pedaling cadence slows on hills, speeds up on inclines, and they don't really shift a lot. It isn't overly efficient, especially compared to the pro-level riders who keep a constant cadence and work the shifter like a guitar to keep things in tune. I used to be one of those riders. Because shifting gears takes mental effort, while mashing the pedals is thoughtless.
We are currently seeing a very similar trend in the security world. Cloud and DevOps are massively disruptive, with deeper implications than most people realize until they are practically falling over halfway up the hill because they forgot to shift gears. Instead of dragging this metaphor out even further, let's dig into technical specifics to better illustrate what I mean.
Recently, on multiple client engagements, vulnerability assessment in the cloud has cropped up as an issue. In nearly every case, it was because the team was thinking of the cloud in the same manner they consider their existing infrastructure. This doesn't work.
In traditional infrastructure, we tend to position a small number of scanners around the network (ideally as few as possible for cost reasons) and scan subnets directly, or over VPN. This centralized model makes sense in the traditional network, but it tends to fall apart when we look at the cloud.
Some cloud providers allow you complete control over your virtual network, including picking arbitrary (non-Internet routable) IP ranges. Since this is fully controlled via software and you can automate the entire network architecture with templates, it isn't unusual to have multiple networks all sharing the same exact network structure under one or multiple enterprise-managed cloud accounts from the same provider. This isn't unusual. It is actually the dominant pattern when deploying applications in the cloud.
The instinct is to deploy a central scanner, either in the cloud or on-premise, and then connect to all those virtual networks for assessments. But the level of complexity here rapidly becomes unmanageable based on the sheer number of networks that look exactly alike and the large number of connections you need to make, all of which reduce security.
You can do it, but there's a better way. There are two design patterns for deploying vulnerability assessment in the cloud I tend to recommend:
Many cloud applications use the concept of immutable servers. Instead of changing anything in production, you configure servers in development, run automated testing in a test environment or account, and then automatically convert that into a gold image that you deploy in the production environment. Remote access is completely disabled in the image, and you use host integrity monitoring to make sure nothing changes. This continuous deployment (yep, part of Devops), is the preferred method of deploying applications in the cloud for a lot of reasons, mostly tied to resiliency, agility, and security. The list is beyond what I can fit into this short post, but there are plenty of good reasons.
Need vulnerability scans? When a server change is checked in and automated testing starts, integrate the scan into the testing suite by starting up the scan server, running the test, and then shutting down. Log the results with the other test results and you can prove to auditors that everything in staging was tested, not changed in production, and, most importantly, can't be changed in production. Some of my clients then don't have to even run other internal scans in production ever again.
What about those virtual networks with static resources? Build automation scripts to launch and configure an assessment server in that network, run the scan, then shut it down, all on schedule. You don't even need to leave it running 24/7, since, thanks to automation, there's really no effort to start, configure, and stop the server (but plenty of cost savings).
Notice another shift — moving away from the concept of one big connected network. Heck, you don't even try to keep everything in a single account. There are cloud consumers out there with hundreds of accounts for different projects, all to get better separation of duties and isolation. It isn't like you need to manually run the cables under a floor and configure the switches anymore.
All of us in security need to change our gears and think about these problems differently. It isn't that we've been doing anything wrong, it's that we are moving into environments that allow us to appear to do things as we always have, peddling along, but that certainly isn't the best, or even appropriate, way to manage them.