Security can clash with development efficiency. Focusing on minimizing breach impact can be more effective than prevention. Dorota Parad argues for flexibility in compliance and collaborating with security teams to define practical protections. Limiting blast radius and using automation can boost security with minimal productivity loss.
At QCon San Francisco, Dorota Parad presented how to build secure software without sacrificing productivity.
Security can be at odds with a fast and efficient development process. Focusing on minimizing the impact of breaches can be more effective than trying to prevent the breach in the first place. In Ensuring Security without Harming Software Development Productivity, Dorota Parad explored creating a foundation for security without negatively impacting engineering productivity.
Parad suggested pushing back on security mandates, as they can hinder productivity. This starts with understanding where those mandates are coming from:
The job of a CISO and your security team is very rarely about security; they are there to ensure compliance. Contrary to popular opinion, compliance doesn’t just mean mindlessly ticking checkboxes, the checkboxes are just (one) means to an end.
It all boils down to crafting a narrative that will convince third-party stakeholders - auditors, regulators, insurance companies - that your company does a good enough job minimizing security risks, Parad said.
None of the security certifications or regulations are prescriptive; it is up to your company to define the scope, means, and implementation, Parad said. It can be a daunting task, so it may be tempting to optimize for the ease of audits and do something like force invasive MDM (mobile device management) software without considering how it will affect engineers’ productivity, she added.
If you want to get rid of some of the more annoying mandates, you need to start a dialog with your security team and help them craft that convincing narrative they’re after, Parad suggested. This means documenting how you think about risks in your area, what you’re doing to reduce the blast radius of breaches, what levels of protection you have in place, and how you’re minimizing the impact of incidents.
Parad explored what can be done to minimize the impact of security breaches. She gave the example of a common threat: a malicious actor getting their hands on one of our engineer’s cloud account credentials:
What’s the worst that can happen here? If we applied the principle of bulkheads, then those credentials are limited in scope to a single cloud account, which may or may not host our production environment.
Parad mentioned that if we utilize modern software development practices, the access would be limited to read-only and innocuous configuration changes, since resource creation and deletion would be automated and only permitted as part of CI/CD pipeline.
If that account includes access to a database containing user data, and if we applied proper encryption, the data is effectively useless to the attacker, Parad added.
Trying to prevent the incident would be a prohibitively costly endeavor, involving multiple remediations to account for all the different attack vectors, Parad said. Limiting the impact is a holistic solution that doesn’t take as much effort or cost, and often comes with additional benefits of increased robustness, she concluded.
InfoQ interviewed Dorota Parad about how security and engineering productivity can go together.
InfoQ: What’s your approach to pushing back on security mandates that hinder productivity?
Dorota Parad: You can only push back on mandates if you have an alternative way to minimize security risks. This is where the BLISS framework (bulkheads, levels, impact, simplicity, and pit of success) helps, by offering an alternative that doesn’t get in your engineers’ way. With Bliss, you can make your security strategy almost invisible to the engineers while embedding it deep into the culture at the same time, Parad said
InfoQ: Can a CI/CD pipeline be considered a security practice?
Parad: This sometimes raises eyebrows among security folks, but yes, I consider a CI/CD pipeline a security tool. Implemented properly, it severely reduces the risk of malicious code ending up in your production.
A typical build/deployment pipeline involves increasingly strict levels of protection the closer to production the code gets - we start with git access controls to make a commit, then developer credentials to create a pull request, we have automated testing that may catch some issues, and finally a second set of credentials and a human review to merge. That’s a very powerful way to minimize security risks.
InfoQ: How can we increase security with a CI/CD pipeline?
Parad: Every single piece of code needs to go through that pipeline in order to reach production, no exceptions. No manual tinkering to push the build through, no bypassing of steps, no logging onto the servers to copy files or run some scripts.
The only way to achieve that in practice is by keeping your CI/CD pipelines healthy and robust, so that they only fail when something is truly wrong. Flaky pipelines are the enemy of both security and productivity.