Edition 17: Is CloudSec the new AppSec?
This edition argues that while there is increasing overlap between the two, it's not a useful framework to apply
As someone who started in AppSec and moved to other areas of Security, I am always tempted to apply the AppSec lens to everything. With the increased usage of public cloud, I’ve often wondered (and so have others) if securing infra is now just an extension of securing applications.
The argument is simple. Commissioning infra components no longer need custom tooling, support tickets to 3rd parties, or (the horror) physically walking into a data center. With a few lines of code, you can get most components up and running, throw in a few more lines and you deploy your application in that infra. So, if all infra is commissioned and managed through code, should we also secure infra through code? or at a minimum, should we treat infrastructure security (let’s call it “CloudSec” for brevity), the way we treat application security (AppSec)? At first glance, it feels like CloudSec could be the new AppSec. This edition argues otherwise.
The usefulness test
Allow me to digress for a bit. If the basics (or “first principles” as the kids these days call them) of all Security areas are the same, is there any value in thinking of such comparisons? I mean, who cares what we call it, what we do is important, right?
We could always find edge cases to show CloudSec is like AppSec or that it’s unlike AppSec. The real value of such frameworks is to evaluate if it passes the usefulness test. As George Pox said, “all models are wrong, but some are useful”. The idea is not to create a framework that sounds right but to create a useful one. This edition argues that thinking of CloudSec as the new AppSec is not useful.
The hypothesis
While the end goals of CloudSec and AppSec may be similar (i.e. make it simple to build and deploy software securely) there are 3 key areas why CloudSec should not be treated like AppSec:
When broken down, the components of CloudSec and AppSec only have a few overlapping components
When broken down, AppSec and CloudSec have many non-overlapping components As a company grows, CloudSec and AppSec scale differently
The automation trajectory for CloudSec is different (and often faster) than AppSec
Let’s dive deep into each of the 3 aspects
Non-overlapping program components
As the above image shows, when broken down, the key components of CloudSec and AppSec are quite different. Even in topics such as (say) logging, AppSec has to think about not logging sensitive data and avoiding log injection. CloudSec has to think about the right tech stack to collect the logs, the correlation of logs collected from various sources, and so on. Another example: For Secrets management, AppSec has to think about providing easy-to-use APIs for developers to create, store and manage secrets. From a CloudSec perspective, you’ll have to think about the right tooling to choose, user management for the key store, and so on.
Having said that, there are a few CloudSec areas that can benefit from an AppSec-type approach. Using Static analysis (SAST) to detect defects in IaaC is one of them. Building secure defaults to make it simpler for dev teams to get started is another area where AppSec rules apply.
The difference in the way they scale
Tech stack: Cloud tech stacks usually scale linearly. Even if your company wants to have a multi-cloud strategy, we are talking about using 2 or 3 public cloud vendors. When an acquisition happens, there is usually a path to migrate infrastructure components. On the other hand, the software tech stack usually complicates exponentially as a company grows. Each department may use its stack (e.g.: programming language) and acquisitions usually bring in different tech stacks which take a lot more effort. Also, given containers help reduce the downside of using different tech stacks in applications, the incentives to unify tech stacks are lower.
Stakeholder management: The number of stakeholders in CloudSec grows linearly as the company scales. Most of the collaboration happens with Infra/DevOps and IT teams. In engineering-led companies, the number of developers far outweighs the number of DevOps & IT folks. This means, when the company grows, developer enablement becomes exponentially more complex.
Security cost: The cost associated with CloudSec and AppSec tooling scales differently. Most AppSec tools have a license based on the number of users (e.g.: devs who check in code). However, most CloudSec tools are priced on consumption. While a company’s business growth and infra consumption may have a correlation, business growth and the number of developers are not necessarily correlated (largely depends on the stage of growth of the company).
Automation friendliness
Given infrastructure is less tied to business logic compared to applications, there are more predictable ways of infrastructure failing and predictability lends better to automation. On the other hand, the variables involved in how applications fail are much larger and vary with business logic. This makes it harder to automate AppSec initiatives efficiently. E.g.: It’s a lot easier to automate the detection of misconfiguration in cloud environments with low false positives than it is to find authz bypasses in applications.
Building CloudSec talent
There is a definite shortage of talented Security engineers across the board, however, the problem seems to be more acute in CloudSec. If you are an AppSec engineer who wants to plunge into CloudSec, this edition should not deter you. Much like AppSec a decade ago, there are many areas from which you can make a transition to being a CloudSec engineer and AppSec is definitely on that list. As an industry, we need creative ways to fill our talent gaps, and co-opting interested folks from different areas of tech is a good starting point.
Do you think “thinking of CloudSec as AppSec” actually passes the usefulness test? Are there other frameworks that sound right, but don’t pass the usefulness test? Hit me up! You can drop me a message on Twitter, LinkedIn, or email. If you find this newsletter useful, do share it with a friend, or colleague, or on your social media feed.