What Aldous Huxley Knew about Building Security In
Sometimes all it takes to move forward is a little shift in perspective. The term “build security in” is so well-worn that it can be easy to forget what it really means. But by shifting our view of the term, we can apply it in a new light. To do that, I’ll enlist the help of on of my favorite thinkers, Aldous Huxley, author of Eyeless in Gaza and Brave New World. In Ends and Means he wrote “The end cannot justify the means, for the simple and obvious reason that the means employed determine the nature of the ends produced.”
In other words, the way that you derive something ultimately dictates what the result will be. In the context of software development, this means that if you justify following a slapdash, disorganized process you have a strong chance of winding up with a slapdash, disorganized result — one that is more likely to have vulnerabilities, security flaws, weaknesses, and other undesirable security properties.
So how can we do and see things differently? How can we use means that determine a secure end without slowing things down? By approaching architecture as a whole rather than in pieces. In the last post we explained what architects do in each phase of the software lifecycle, in this one we’ll show how to ensure those steps are accomplished holistically.
You may notice that in looking through the lens of the SDLC phases, specific goals and tasks of the architect are clear at each phase. You can likewise probably realize how and why the architect changes their approach and focus depending on the portion of the cycle they’re in. But the truth is more complex than it seems based on just looking at these discrete, monolithic phases; because most new software being built in enterprises today no longer uses such clearly defined phases. Instead, the lines between phases have blurred — or in some cases disappeared entirely.
In other words, under legacy models such as waterfall, development phases were closer to clearly defined, boundary-aligned steps with clear gates between stages ultimately leading to a developed project. It was never perfect even under waterfall, as some phases (for example, testing) were always iterative in nature and not a one-shot, monolithic process. However, newer models have less clear differentiation than even that. For example, DevOps blurs the lines between “development, release, and support” and approaches such as CI/CD (continuous integration and continuous development) mean that each portion of the cycle may be so compressed as to be almost meaningless.
What’s important to note about this is that the goals of the architect — and the scope of what they are called upon to do — don’t really change even when the development models don’t have clearly defined phases. We described them individually to illustrate the focus and key aspects of the architectural role in each area, but ultimately, the architect must stay focused on developing a clear vision (of the application’s security profile, security features, use and misuse cases, and how it might be attacked) for the application regardless of the underlying model used to author and deploy it.
One additional substantive part of the architect’s job that models such as DevOps and CI/CD can help illustrate is the role of architecture in the development methodology and release process itself. Meaning, application security architects often have a stake in how software gets developed in the first place. This means that they can have a role in ensuring a process that fosters reliable, consistent, and secure outcomes.
Under a waterfall model, this might mean that they incorporate security design reviews, manual or automated software security testing, code review, or other checkpoints or gates into the release process. Under agile, it might mean that sprint reviews include time to specifically discuss and evaluate security topics and features. Under DevOps, it might mean an automated security testing capability integrated into the pipeline. In all cases, it also likely means a culture built around security: by training developers on security coding techniques, by supplying components (for example, cryptographic modules, authentication components, services, or other software) to encapsulate and provide security functionality, or numerous other techniques.
The distinction between “what is built” and “how it’s built” is subtle, but the outcomes of each are clearly inter-related. If you follow a process that engenders security — where security is accounted for and actively espoused during the development process — the resulting software will tend to be more resilient than would otherwise be the case. Therefore, ensuring that the end result is secure requires the right means; an effort to “build security in” to the software development life cycle.
This post is part of a series excerpted from our book: Practical Cybersecurity Architecture: A guide to creating and implementing robust designs for cybersecurity architects, ISBN-13 : 978–1838989927 available at Amazon and published by Packt.
