Security can be at odds with a fast and efficient development process. At QCon San Francisco Dorota Parad presented how to create a foundation for security without negatively impacting engineering productivity.
Traditionally, security is all about defense, Parad said. We focus on stopping the attackers, so we put obstacles in place to stop them. These very same obstacles often get in the way of our own employees as much, if not more, as the malicious actors, she mentioned.
Considering software development, engineers have the power to bring our whole system down, so it’s not much of a mental jump to treat them as a source of security risk, Parad argued. But it’s the same engineers who make the system run and release the features that keep our business going:
Putting too many obstacles in their way means slowing down our value delivery, which in the long run costs the business more than a security incident would.
Parad mentioned that there is the tension between security and productivity, which traditionally gets resolved by an unsatisfying mixture of security theater and lax security posture, all dressed up as “compliance”. In that situation, no one wins except the attackers, she added.
Parad presented a framework she created, called BLISS, which helps implement security without negatively impacting engineering productivity. BLISS stands for bulkheads, levels, impact, simplicity, and pit of success:
- Bulkheads let you limit the blast radius of security incidents through separation and isolation.
- Instead of applying a single, strict strategy to everything, have different levels of protection proportionate to the level of risk.
- Focus on minimizing the impact of the incidents instead of just limiting the probability.
- Keep your processes and tools simple to make them easier to secure.
- Create a pit of success, where it’s so easy to do the right thing that it happens by default.
This way, you can make your security strategy almost invisible to the engineers while embedding it deep into the culture at the same time, Parad said.
Focusing on minimizing the impact of breaches can be more effective than trying to prevent the breach in the first place, Parad said. What security teams often overlook is that modern software development already includes a lot of ways that make a successful attack less likely compared to the early days of the internet. CI/CD pipelines, ephemeral test environments with automated tests, code reviews, serverless infrastructure are just some of the examples, she explained:
I’m not saying we should completely ignore prevention, things aren’t so black and white. From what I see in the industry though, security teams often overindex on measures intended to prevent breaches, and that’s ineffective.
None of these offer full protection, but when we consider them all together, they create a baseline that’s good enough, Parad said. At that point, trying to reduce the likelihood of a breach tends to bring diminishing returns, so it makes sense to look at the impact side of things.
Assume every part of your system is going to get compromised at some point; it’s not a matter of if, but when, Parad said. She suggested thinking about what you do so that an event doesn’t turn into a total catastrophe.
InfoQ interviewed Dorota Parad about improving security and productivity.
InfoQ: What can be done to improve both engineer productivity and security?
Dorota Parad: An example is logging in with Single Sign On (SSO) instead of having to use multiple usernames and passwords. Not only is that easier for the user – no need to remember or type in that annoying password every time, it’s also more secure.
Any time you make a part of your development process simpler or more robust is going to be a productivity win; we all understand that intuitively. What’s less obvious is that those same optimizations tend to improve security as well. If it’s automated, it’s fewer places for a malicious actor to use social engineering to get access. Fewer steps in a process mean fewer attack vectors. Removing tools from our tool chain means fewer things to break and fewer vulnerabilities to patch.
InfoQ: You highlighted the importance of “bulkheads” to limit the blast radius of incidents—what are some practical ways teams can achieve this?
Parad: It’s all about the separation: separate git repositories with separate access controls, separate deployments, cloud accounts, databases, and so on. I always say security starts with the architecture and how well you can achieve that separation is going to be constrained by your architecture choices.
If you have a monolith where everything has to be deployed all together into a single cloud account, you’re going to be pretty limited on where you can place your bulkheads. But even then, having a separate instance for each customer will offer some way to limit the blast radius in the event that one instance gets compromised.
Ideally, we want a modular architecture with different parts of the system deployed and operated independently. That way, if one part becomes compromised, it doesn’t automatically mean the whole system is.
