Security architecture in a nutshell
The security architecture practice focuses on security during the architectural design of the software system. The essence of this practice is to leverage proven patterns and principles both in terms of an architectural solution as well as technological implementation. On top of that you should ideally revisit the reference solutions, update them and propagate the changes back to your software systems in production. This practice is an essential step in claiming the security by design principle.
In this blog series, we present how Codific implements OWASP SAMM. Obviously describing all details is out of scope especially for this practice. We will however present a high-level overview and describe some of the tools we leverage to achieve a specific maturity level.
My journey in application security (AppSec) started nearly 20 years ago at the IMEC-DistriNet research lab of the KU Leuven in Belgium. Software architecture was and still is the discipline that draws the line between mere programmers and software engineers. There is no software architecture without quality attributes and security is an obvious choice in every web application. Security by design starts from placing security in the driver’s seat.
Implementing the SAMM Security Architecture practice
In this blog I will discuss how we implement SAMM’s Security Architecture practice. The Security Architecture practice focuses on the security linked to components and technology you deal with during the architectural design of your software. It consists of two streams, just like any other SAMM security practice:
- Architecture Design looks at the selection and composition of components that form the foundation of your solution, focusing on its security properties.
- Technology Management looks at the security of supporting technologies used during development, deployment and operations, such as development stacks and tooling, deployment tooling, and operating systems and tooling.
At Codific we largely leverage the philosophy that we evangelized throughout the course Software Architectures during my career as a TA at the University of Leuven. The course was (and still is) largely based on the book Software Architecture in Practice by Bass, Clements and Kazman. Nearly 20 years later the software engineering practice is still largely the same (minus a couple of new patterns and a gazillion of new technologies). In a nutshell, security takes the driver seat during the requirements analysis. We list the security requirements specific for the given application. Starting from those, in the software architecture we define solutions for the security requirements. Security principles, patterns and reusable components are obviously the keywords in secure software architectures.
Picking a list of relevant security requirements is not always obvious especially at the right granularity level. At the one extreme you might end up with a huge list of meaningless low-level requirements (e.g., passwords should be at least 12 characters long). The other end of the spectrum is a single security requirement stating that the system should be secure. Or even worse, i.e., comply with OWASP Top 10. All I’d recommend in this blog is to make the requirements specific, measurable, actionable, relevant and time-bound (SMART). Here are some great security requirements:
- Ensure personal data is properly protected in transit.
- Ensure all file uploads are encrypted with a separate key.
- Ensure no-one except the user has access to his own keys.
Once the requirements are defined (including the security requirements) you can start designing the software architecture. Ideally a list of reference architectures should be available for your organization. To make sure you achieve the highest maturity level in SAMM you should regularly revisit your reference architecture and propagate the updates to existing systems.
Patterns and security principles
Once you have selected the reference architecture to start from you should select the actual solutions to your security requirements. One of the security axioms is to never design your own cryptographic protocol. I would say the same is true for security requirements and secure architectures. When it comes to security try to find a pattern or a standard that implements best practices. To go back to the sample requirements I’ve listed above, here are the best practices / patterns that you should use:
- Use TLS to protect all personal data in transit.
- Use AES256 encryption with a randomly generated key for every file upload. Make sure you leverage secure random generators.
- Encrypt the user key folder with something only the user knows or has (note that this is not the complete solution, but that would take us too far).
Reusable services and components
Taking patterns a bit further we end up with reusable services and components that provide the solution as a code. The level of reusability in today’s world was a mere dream 20 years ago. Nowadays simply importing an existing (whether or not third party) library might give you an out-of-the-box solution that implements your security requirements. Just like with reference architectures you should regularly revisit this list and update if necessary.
In addition to reference architectures and a list of reusable services and components you should also define a list of technologies, frameworks, tools and integrations that the engineers should use. As an organization with a strong security posture you should revisit these regularly and update them. You should also try to enforce the correct usage (or automatically detect the incorrect usage) for each of these.
Reusable Security Architecture at Codific
At Codific for most of our projects we use the same reference architecture that comes with a whole lot of patterns and security principles. We also deploy the same tech stack including the framework, tools and various services and components. In fact, we leverage a code-generation framework. The framework is an in-house technology based on my doctoral research. The reference architecture and a number of security patterns are integrated in the framework core. Just a single architectural view (i.e., the data model) is described as a UML diagram and translated into code. We do regularly revisit and update the architectural and the technological building blocks. The great news is that updates are easy to propagate from one project to another. Indeed, we merely need to regenerate the solution from the model using the updated code-generation framework.
In this blog, I have presented how Codific implements the Security Architecture (SA) practice from OWASP SAMM. I have briefly discussed what are the main processes, activities and artefacts in implementing Architecture Design and Technology Management streams of SA. Ideally, you should have a reference architecture ready to use for a new project. This architecture obviously comes with a list of security patterns and principles. Taking it even further your reference architecture could also feature a scaffolded code including reusable components and services. Finally, an essential step to ensure maturity level 3 for SAMM is to regularly revisit the afore-mentioned artefacts. If an update is necessary you should also propagate these towards your existing software systems in production.
What do we build with SAMM and SAMMY?
Codific is a team of security software engineers that leverage privacy by design principles to build secure cloud solutions. We build applications in different verticals such as HR-tech, Ed-Tech and Med-Tech. Secure collaboration and secure sharing are at the core of our solutions.
Videolab is used by top universities, academies and hospitals to put the care in healthcare. Communication skills, empathy and other soft skills are trained by sharing patient interviews recordings for feedback.
SARA is used by top HR-Consultants to deliver team assessments, psychometric tests, 360 degree feedback, cultural analysis and other analytical HR tools.
SAMMY Is a Software Assurance Maturity Model management tool. It helps your organization assess and improve its security posture. That way other companies can help us build a simple and safe digital future. And we off course use it ourselves in all our application, including SAMMY itself.
We believe in collaboration and open innovation, we would love to hear about your projects an see how we can contribute in developing secure software and privacy by design architecture. Contact us.