“There is another value in architecture in that it adds speed to a release process. Just like writing testing software in code slows down the first few releases but speeds up all the rest of them, so too does architecture make the first design iteration maybe take a little longer – but all future design work that leverages it will go more smoothly and more quickly.”
– Adam Shostack, President, Shostack & Associates
In our last post, we took a deeper look into how network architects can secure the stack. In this post we’ll do the same for application architects using phases of the SDLC (software development lifecycle).
Requirements and Design
During the earliest stages of planning, the architect is involved in making sure that security requirements are captured, that key features reflect not only important elements of security (for example, authentication, protection of data, data integrity, availability, and so on) but also that “misuse cases” (for example, how the application might be attacked or features subverted) are considered along with the use cases or “user stories” that are used as input in the application design process.
Development
During the period when software is being actively developed, the life of the cybersecurity architect is very busy. At this stage, the architect must create a plan for the application and an overall design that addresses a few different considerations:
- Security functionality: Strategies to ensure that any functional security requirements are addressed securely. This includes features such as user account management, administrator and user authentication, logging and monitoring features, secrets management (for passwords, API tokens, cryptographic keys, and so on), availability considerations, and others.
- Threat mitigation: Strategies to ensure that the application is resilient against attack or accidental misuse. This includes input tampering or over-run, insecure business logic, race conditions, or any other flaw in the software that could allow or facilitate unauthorized activity.
As you might imagine, each of these areas of focus has its own tools and techniques to achieve with optimal effect; we will discuss some of these tools and techniques in future posts.
Software engineer and professor Barry Boehm famously pointed out in Software Engineering Economics, Prentice Hall PTR, that the cost of fixing a software flaw increases non-linearly over time; in other words, that the farther along in the development life cycle a flaw is discovered, the more expensive it becomes to fix.
Just like fixing a defect, changes made to the security model of an application are much more easily and cost-effectively addressed earlier in the life cycle than they are later. For example, consider a security defect that could undermine a key portion of the application or that could allow an attacker a method to subvert the application. Should a developer find a bug like this immediately after authoring the code that contains it, fixing it is relatively simple: they just modify the offending code, test it, and call it a day.
What happens though if they do not find that bug until much later in the process; say, for example, after they have shipped a million units of that software across the globe? At that point, the complexity – and cost – of applying the fix is comparatively astronomical: the developer still has to update the source code and unit test it the way they always would – but now, they also need to integration test the change against the rest of the product, slot it for a release, rebuild, release a patch, notify users of the issue and get them to patch.
Release
During the release process, security is also an important consideration and goal for the architect. At this point, because of their efforts during the development phase, the architect will ideally have a solid design for the application that is implemented (to a greater or lesser degree) within the application as the organization undertakes fielding it to production. As you might expect, there will likely be some aspects of the security model, vision, and design that will require orchestration during the release process to work and perform optimally.
As an example, consider the situation where the architecture calls for the use of cryptography as part of the application security model and overall design. During the development process, the security architect would work with the development team to create the logic behind this, but reasonable security hygiene obviously would preclude using the same secrets (keys) during development as what will ultimately be fielded into production. Therefore, the process of actually creating those production keys – and storing them in a location where they are themselves appropriately protected – needs to happen during the release process itself.
Support
Once the application is released, the focus of the architect shifts once again. In fact, this is where the work gets the most interesting for the architect, as there are multiple areas of focus that they must maintain simultaneously. These are as follows:
- Execute the long-term vision.
- Respond to unanticipated behaviors of the application in the field.
- Participate in the design of future iterations of the application.
It is highly likely that some of the security features, along with countermeasures required to keep the application secure, may not make it into the first release. Working with other stakeholders, the security architect will need to continue to work to get these deployed over the long term.
In addition, just like there are “hiccups” in new applications, so too can there be unexpected events that arise in security features and security controls. As part of the support process, the architect will need to be involved in ironing those out.
Lastly, don’t forget that it’s a rare application that has one release and doesn’t ever get updated. It’s almost certain that as an application enters the support phase for a given release, the next release will be entering (or have already entered) the design and development stages for new features. So, just like the architect needed to plan security features and protections around the initial release, so too will subsequent releases bring with them modifications and necessary changes that the architect will need to be involved in.