The Biggest Misconception in Application Security

I’ve touched on this in previous articles, but it’s worth dedicating a little time to this misconception as it’s at the root of so many of the problems that organisations have with security and delivery. A common way to think about maintaining security while delivering software systems at pace is this.

Where rapid delivery of changes into production is one end of a scale, being secure is at the other end and, as an organisation, you pick where along the scale you’re comfortable according to your risk appetite. This makes intuitive sense - if your mental model of software delivery is like driving a car and you’re taking more risks with your foot down, going faster. The problem with this mental model is it’s completely wrong.

Building software is one of the most complex human endeavours. It’s not possible to deliver applications at pace unless the software is of high quality. The slowest release cadence projects I’ve ever worked with have all been the lowest quality, worst designs and codebases and I’m sure you have the same experience. These low quality systems simply can’t be changed quickly. They will functionally fall apart if you try and everyone is, quite correctly, far too scared to try. Every change leads to unpredictable failures in an overly-complex system with:

• A ball of mud architecture
• Incomprehensible code
• Global variables and state
• Poor functional decomposition
• Specialist teams of developers, testers, architects and operations all handing off changes to each other with ill-defined responsibilities

You simply can’t deliver at pace unless you’re paying attention to the non-functionals. Performant, interoperable, reliable, usable, maintainable and secure systems can be changed with confidence. They have:

• A decoupled design that allows for simpler subsystems or components of the system to be changed independently
• Code that is clear, understandable and functionally decomposed well
• Comprehensive instrumentation giving visibility into the running system in test and production so that any aberrant behaviours are immediately seen
• Delivery teams that are cross-functional with continuous responsibility for all aspects of the system so that quality, all quality, including security, can be assured continuously without slowdowns

Delivering slowly isn’t more secure, it’s fearful, and if you’re afraid of changing a system then the system is not secure

If this misconception is how your organisation is thinking about security then what it’s really saying is:

• We can’t assure security of daily releases
• A ticket raised for a security assessment won’t even get assigned to a security tester in that time
• Our security operations team would be swamped by daily changes going into production from all the development teams in our organisation
• We don’t have confidence that our development teams have the skills needed to deliver at pace

And these are all valid, fixable problems. Not an absolute truth about software delivery pace being antagonistic to security. The first step is identifying the real problems, I’ve listed some common ones here and I’m sure you can think of more. The next step - fixing things.

Let’s switch out security for another non-functional requirement that’s very important to your organisation: performance. From my experience working with everyone involved in software delivery it helps to avoid any ingrained ways of thinking. Can you deliver rapid changes to your software systems and maintain a high level of performance, or even improve performance in the process? Of course you can! If you wanted to ensure high performance while evolving your applications at pace you would:

• Think about the performance impact of any changes during planning and design
• Plan your overall system architecture with performance in mind
• Make sure everyone knows how to write performant code in the languages and frameworks you’re using
• Hire people with domain expertise in performance engineering to work with, train and coach teams
• Peer-review code changes for the inevitable human mistakes that could affect performance
• Share known-performant code and internal libraries across teams
• Make performance a key consideration in the selection of any third-party libraries you depend on
• Make performance a key consideration in the selection of any third-party services you depend on
• Automatically test all changes for performance regressions on every commit so developers can catch and fix them early
• Prioritise performance fixes in your backlog / development cycles
• Inject comprehensive telemetry into your systems to monitor performance in production
• Investigate & fix performance incidents in production and widely publish findings across the organisation to improve learning
• Make maintaining high performance the responsibility of the teams delivering the applications

Nothing controversial here - a sensible approach to meeting an important, non-functional engineering requirement. All of it equally applicable to security. Let’s make the obvious substitution:

• Think about the security impact of any changes during planning and design
• Plan your overall system architecture with security in mind
• Make sure everyone knows how to write secure code in the languages and frameworks you’re using
• Hire people with domain expertise in security engineering to work with, train and coach teams
• Peer-review code changes for the inevitable human mistakes that could affect security
• Share known-secure code and internal libraries across teams
• Make security a key consideration in the selection of any third-party libraries you depend on
• Make security a key consideration in the selection of any third-party services you depend on
• Automatically test all changes for security regressions on every commit so developers can catch and fix them early
• Prioritise security fixes in your backlog / development cycles
• Inject comprehensive telemetry into your systems to monitor security in production
• Investigate & fix security incidents in production and widely publish findings across the organisation to improve learning
• Make maintaining high security the responsibility of the teams delivering the applications

If you’re a delivery team, doing these things takes control of the security of your systems. If you’re a security team, ensuring your organisation is doing these things scales your knowledge and expertise across the whole business. Nobody, absolutely nobody, has to slow down.