• Abdul Manaf

Security Architecture needs a common language

Updated: Jun 30, 2019

Any security professional will tell you that security is all about confidentiality, integrity and availability of information. If you ask them to create a security architecture, it will soon bring out chaos, as there is no common definition for security architecture. You will mostly receive a component deployment diagram with firewalls around it, showing some encryption on certain links. Why is that encryption (a means to achieve confidentiality, and at times integrity and authentication, depending on what sort of encryption technologies that you are using) the single most element of importance?

A more widely accepted definition of security architecture is the high-level organization of security controls that addresses the risks to information, information equipments and information processing facilities.

Given the definition, there are certain considerations to be given to a security architecture.


Life-cycle based means the architecture considers the entire life-cycle of a system, starting from its development, design, implementation and operation. It considers the risks that are to be addressed, and policies that are to be made for the secure operation of the system.

  1. Requirements analysis: Identifies the right requirements (“what”) to implement.

  2. Design: Describe “how” the stated requirements will be met.

  3. Implement: Describe the implementation of individual components, configurations, testing and acceptance of the system.

  4. Operate: Operate the system in accordance to its performance requirements and produce metrics and measurements for process control.

Risks and Policies driven

Risks to an organization’s assets (including business assets) are a primary driver for the security architecture.

  1. Requirements analysis: Identify the risks and mitigation measures, along with the policies that must be implemented.

  2. Design: Identify how controls (including policies) are implemented across physical, network, operating system, application and user layers.

  3. Implement: Implement the risk mitigation measures and the stated policies.

  4. Operate: Operate the controls and ensure policies are followed.


The defense-in-depth shows the controls in different planes (such as n onion ring) around the solution to achieve security.

Traceability assured

Security controls are mostly implemented for the following reasons:

  1. Compliance requirements: Legal, regulatory and contractual obligations require certain controls to be implemented.

  2. Standards: Controls are implemented to comply with certain standards.

  3. Audits: To resolve audit findings.

  4. Best practices: Certain controls are generally regarded as as best practices.

  5. Risk driven: Controls are implemented to mitigate risks that are identified as part of the risk management practices within the organization.

While all the above methods of controls selection may be necessary, it is important to maintain a traceability between the business drivers, control and enablement objectives towards the controls being implemented.

This will rationalise the existence of certain controls, identify redundancies in controls and facilitate change management.

"A life-cycle based, risk and policies driven, defense-depth and traceability assured security architecture template"