In general, when we think about what is Security Architecture the term Security Architecture has different meanings and everything will depend on the context in which the term is placed.
The question of defining the term is so relevant to understanding that Gartner has reserved an entire article to describe his view of Safe Architecture. And for Gartner, the term means:
“In Gartner’s experience, practitioners use the term “security architecture” to refer to the security elements in a range of different (often unspoken) domains. These may be enterprise architecture, technical design, organizational structure, policy framework, process catalog, or some other intended focus area.”
From this understanding, Gartner also mentions that one of the best-known concepts for the term is when we use it to describe Enterprise Architecture.
You can also listen to the audio version of this article:
AppSec isn’t only codes
When we think of AppSec or Application Security, one of the first ideas that come to mind is the sole concern with maintaining and improving code security.
This is nonetheless important, but behind a secure application lies infinity controls, processes, layers, and structures that must work together for the end result to be a secure application.
Therefore, it is important for the application design team to look forward to ensuring the security of this software.
For this, a good strategy may be to perform threat modeling: even this topic has been the subject of other articles where we cover the 3 benefits of threat modeling. We approach threat modeling from a broader point of view in this article as well. If you are thinking about it, it is worth checking out.
Here are some things to keep in mind as you begin to plan or improve your application and structure.
Basic Application of a Web Security Architecture
In a pretty rudimentary way, we can start talking about security architectures by understanding the most basic models, which even though little used today still have an educational value.
Thus, when we talk about a basic security framework, as we have shown in the figure below (image 1), we can see that both the application framework and its database are sharing the same machine.
This, in addition to being a service continuity issue – as we have a single point of failure – is also a weakness in the architecture, since if there is a compromise of the application, the database will eventually be damaged.
It is not uncommon for this type of structure to be the same user responsible for running applications, and often the most privileged user, who may be root for *NIX or even the Administrator for Windows systems.
This introduces a serious security hole because when the user compromises, all systems running on them will be compromised.
Aforementioned, this is a much rarer structure to see in companies that really take the concept of security of their applications seriously, but it can still be found in smaller, less-resourced companies. Compromising a machine can compromise an entire service.
Well, now let’s go to a scenario where this structure has evolved and we move to a structure similar to what we have in this image below (image 2).
Even though we now have a better distribution of the services that deliver the application, we can still notice that there are multiple single points of failure: on each machine, there is a service, but only one machine to guarantee this service.
In general, we can relate as disadvantages of these models – both Single-Tier (image 1) and Two-Tier (image 2) – that in both there are single points of failure.
Apart from this feature, we can say that these models also have fails related to updates of any component of the structure. This is because to perform an upgrade, the system must be down during the process. This is nowadays unthinkable for a vast majority of systems.
There is still, as we have said, the possibility of a system component compromise, and this would eventually affect the entire structure and the system.
As we can see, these two ways of assembling our structure are not at all safe and rarely seen even today, but they served to introduce the concept of a single point of failure, or as you might find a single point of failure.
Multi-Tier solution-made concept
As you know, multi-tier architectures are architectures built with component separation, and this separation is widely used as safety compensatory control as it helps isolate critical systems and components.
In multi-tier architectures, as shown in the image below (image 3), components and systems are distributed on separate machines or sets of machines.
This model becomes even more real if we talk about virtualization or even the use of containers and microservices within systems creation.
As you can imagine, the use of such structures contributes greatly to the construction of safe systems as it ensures the isolation and rapid replacement of affected or even compromised components.
Also, one of the weaknesses in Single-Tier models, upgrading, is no longer a problem as we can upgrade and modify systems much more easily.
Multi-tier models are most effective for today’s security models and systems and are therefore best suited for building security-focused applications.
Thinking about software security is not just about improving your code or even writing more secure codes – there’s a lot more to it.
Introducing Security Architecture
The term architecture is already incorporated into many of the frameworks we know. Some examples can be found in ISO 27000 series standards or even others such as NIST CSF or even PCI-DSS.
However, what we realize is that this term has been lost within companies.
The understanding we have today is tied to organizational architecture security plans and has its origins in a thinking model created in the 1980s by John Zachman. This model became known as Zachman Framework.
The Zachman model focuses on presenting a way for us to view and structure organizational architecture in terms of information technology.
However, if you want a more structured and framed view for the present day, a good article to read is the one produced by Gartner presenting a Guide to help build a Security Architecture framework.
Considering the points discussed above, even having an area of Enterprise or Organizational Architecture, many companies still overlook the application of Security Architecture concepts.
This often happens by the way these two areas can be arranged within the organizational structure of the company. Here, the term architecture refers to how they are distributed within business functions.
In some companies, the Security Architecture area is directly linked to the Enterprise Structure area, but this is not always the case.
In others, it is linked to the area of Information Security, and this certainly affects how the term “security architecture” will be interpreted.
If you would like to know more about this point, in this Gartner’s article you can find more in-depth concepts about this structure.
This same conflict is often the same as what we see between security and development, which we dealt with in our article on Security Champion.
This is a conflict that must be resolved with assertive communication: a change of attitude is required to resolve the problem clearly.
We have also seen that communication errors can pose major security issues for the company in this DevSecOps communication article.
One solution that should be pursued is always to seek to convey the right information about what Security Architecture is because in many cases people understand that it is nothing more than the creation of maps and diagrams of networks or services.
We need to understand that the Security Framework is a process, and as such should be carried out by people and systems who understand its importance.
As we can see in the image below, Gartner has a much clearer view of what is Security Framework, a great aid to other areas and that can facilitate the vision of points that contribute to building a better solution.
Thus, the importance of a better understanding is evident. Here is the invitation to deepen this theme within its reality.
What is the relationship between Organizational Structure and Security Structure?
Well, it is clear that doubt would arise. After all, whose role is it to think about the security structure? A corporate architect who thinks about the business-based structure or the security expert?
Perhaps the answer may come from a view we found in Gartner’s “Improve Your Security With Security Architecture” article.
“The main challenge of security architecture is to propose architectures that can withstand real threats and comply with policies while serving the business and the rest of IT.”
As such, perhaps working closely with Enterprise Architecture is a good idea to get security architecture involved in projects, and projects may or may not be developed using agile methods.
In fact, we can say that the practices developed by the Security Architecture area are more easily aligned when working closely with the Corporate Architecture area, and this can be seen especially if your company uses a model like SABSA.
To reinforce this concept, we can point out research by Gartner that found to be more effective in the participation of the Corporate Architecture area together with the IT Security area, all under the same leadership.
So before making a decision on how to structure this area or how to reposition it within your organization, it will always be recommended to analyze and understand how your business structures best relate.
When these two areas work together, we can say that Security Architecture will be a great provider of standards and information for many other areas of the company – especially for risk management or even leaders, who are getting clearer and more detailed information.
As we can see in the image below, the synergy between the areas may be much greater than we previously imagined.
Why think about Security Architecture?
When a company seeks to develop a strategy to build a Security Architecture plan, the end result can be a set of benefits that are not always seen at first glance.
Creating a Security Framework enables a company to find better security controls and visualize where it best fits within its security plan. It also helps in creating a reference model that can contribute to different areas.
Security and risk management professionals responsible for deploying security in enterprise solutions must demonstrate that their approach meets the collective needs of the organization.
Security architecture methodologies are complex to execute and even more complex to demonstrate their value. The implementation of models previously created to be more generic needs to be adapted to be considered relevant to the business.
To help with this problem, Gartner is once again helping us with his article by presenting this rich material with a Guide on how to apply security architecture templates: we strongly recommend reading this.
The main benefits of Security Architecture
In general, we can list the following benefits:
- Improved company security posture by showing that security issues were properly addressed
- Process and control auditability
- A bridge between compliance and risk requirements, which are adjusted to business needs
- If there is a need to demonstrate compliance with internal standards and policies, they are better organized and planned.
- Facilitates viewing current business risk and compliance status and creating a roadmap for future steps
In closing, building your security architecture ensures that you systematically seek to address security issues – among them the risks of building the architecture that will support application or even code building.
In addition to these concerns, all requirements related to policies, standards, and regulations have been studied and addressed within their planning.
This also ensures that security measures and controls are communicated as well as possible to all involved. After all, measures and controls were created based on business needs, not simply acting to comply with any regulations.
The security architecture methodology and guidance given here can help in structuring the security architecture itself. By providing mechanisms for moving from uncoordinated activities to a structured and highly logical approach, the implementation of this model enables the enterprise to support all security as it provides the alignment of an internal security policy with external standards whenever necessary.