Spending Developers on Security - Part 1
July 10, 2018

Hillel Solow
Protego

Securing cloud native applications presents an interesting challenge. Cloud native application developers view the cloud as an operating system, and they write for and run on that operating system. When it comes to security, this means spending time configuring this operating system to enforce security policies on the various parts of the application. In the cloud, this often translates into IAM roles, VPC configurations, etc.

In the shift to cloud native, many organizations have also adopted a configuration-as-code approach. This helps drive up application deployment velocity by letting developers and DevOps teams reconfigure their deployments as their needs arise. Other organizations, particularly the more regulated ones, still have security people owning these tools, but that creates increased pressure on the security organization to keep up.

Your Mileage May Vary

How much are organizations investing in this process, and how much is it getting them? I recently spent some time talking with developers using primarily serverless technologies, to understand how they handle security configuration.

If I oversimplify, there are three types of developers in the serverless arena:

Extreme Minimalists: This strategy can be summed up as "do nothing until you have to", or "why procrastinate today when you can procrastinate tomorrow", and basically means, don't touch security configuration until something you deploy to staging doesn't work, see what error you got, add a permission or configuration as needed.

Balanced Realists: Here the strategy consists of spending about two minutes before deploying a function reviewing roles and configuration, and trying to catch any missing or perhaps extra permissions or configurations before rolling it out. Handle the rest as exceptions.

High-Functioning Security Fundamentalists: This is less common, but not as extinct as one might think, and involves really reviewing the entire security configuration before each deploy, revalidating all permission, and tracking anything that might be missing.

As you can imagine, each profile ends up spending dramatically different amounts of time on security, and getting very different results. By and large the first group spends zero time on deployment, but then spends a lot more time when permissions are missing. In the end, they tend to still come out on top in terms of time spent, but are worst off in security, as by the time they see an error in the logs for some function that's missing permission, they're almost certainly going to drop a big wildcard in to get it working.

The second group tends to spend about two to three minutes per deploy, and still hit the occasional exception. Their security outcomes are somewhat better than the first group, but not a whole lot. They too have a lot of wildcards, but they are slightly better at removing old permissions that are no longer needed.

The third group spends 5-8 minutes per deploy but has a pretty low rate of exception after, and tend to have a much better security posture than the first two groups, both because they spend more time, but also because that time is spent within the mindset of "let me get the exact profile I need and no more." Bravo to them, but honestly, I don't think I could keep that up for long.

Read Spending Developers on Security - Part 2 to answer the question: What's it Going to Cost Me?

Hillel Solow is CTO and Co-Founder of Protego

The Latest

November 15, 2018

Serverless infrastructure environments are set to become the dominant paradigm for enterprise technology deployments, according to a new report — Why the Fuss About Serverless? — released by Leading Edge Forum ...

November 14, 2018

What to automate? Which parts of the delivery process are good candidates? Which applications will benefit from automation? At first, those sound like silly questions. Automate all your repetitive processes. If you think that you'll do the same thing manually more than once, automate it. Why would you waste your creative potential and knowledge by doing things that are much better done by scripts? Yet, an average company does not adhere to that logic. Why is that? ...

November 13, 2018

I'd love to see more security automation deeply integrated into the development process. Everybody knows since the 1990s that security as an afterthought just doesn't work, yet we keep doing it. The reason, I think, is because it's very hard to automate security ...

November 09, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 5, the final installment, covers deployment and production ...

November 08, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 4 is all about security ...

November 07, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 3 covers the development environment and the infrastructure ...

November 06, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 2 covers the coding process ...

November 05, 2018

Everyone talks about automating the software development lifecycle (SDLC) but the first question should be: What should you automate? With this question in mind, DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 1 starts with by-far the most popular recommendation: Testing ...

October 31, 2018

Halloween is a time for all things spooky, but not when it comes to your mobile app experience. A poor experience can not only scare off your customers but keep them away for good ...

October 30, 2018

As organizations have embraced open source, they have become polyglot — using multiple programming languages and technology stacks to accomplish software and hardware related tasks. Enterprises are caught between the benefits provided by a polyglot environment and the complexities and challenges these environments bring. Ultimately, if the situation remains unchecked, polyglot will kill your enterprise ...

Share this