A security architecture‍ is topic which has been more and more demanded, although stakeholders in organizations may still have quite different views on it and also very different expectations from it. In many cases it is just about solution design that is capable to resolve some security issue, however it also includes strategic views and should drive development of future security capabilities so the organization is capable to deal with recent challenges. As it is obviously quite complex topic, with many dependencies to internal existing processes in organizations, it may be worth to write few observations and clarify further the topic here among security professionals.

Well established security architecture function provides following services to the rest of organization:

Drivers of #securityarchitecture are typically coming from frequent changes of business services, growing complexity of IT infrastructure, increased legal and regulatory requirements and traditional demands to reduce costs and improve efficiency.

As mentioned, term #securityarchitecture does not have commonly adopted and unique definition. Every organization interprets in its own way. Often there are three different views on what scope of the security architecture should be: the architecture at organization level, security architecture of an application level or security architecture design of specific vendor provided service or product.

Regarding dependencies and relationships, #enterprisesecurityarchitecture is seen as part of enterprise IT architecture which is derived from both business requirements and security policies. Very nice overview of the taxonomy is provided by http://www.opensecurityarchitecture.org at the figure below:

Assuming the security architecture consists of multiple representations that describe function, structure and relationships between security components in given organization, well defined and consistent security architecture framework will contain these documents:

a.Enterprise Security Architecture Concept is a high level description of overall security architecture approach, relevant domains and common design principles. The document is to be used as baseline to build security architecture.

b.Security Services and Controls Catalogue- logical view on existing ("as is") security services and controls with assessment of their maturity level. The document is to be used for reviewing current status of the security architecture and to ensure that existing security services are actually efficient as required.

c. Architecture Reference Models- logical view on target ("to be") security architecture models which provides details of threat scenarios, risks and required security controls to be applied on different architecture layers within security domains.

d. Security Architecture Roadmap - strategy definition with planned vision for acquiring or developing security services and controls. The document is to be used for budget planning and for making decisions to acquire new security capabilities.

e. Security Patterns, Guidelines and Templates- detailed view on standardized solutions for the problems that reoccur in many different situations. These documents represent most operationalized part of security architecture that issued as supporting documents for designing and implementing controls that resolve practical problems.

Benefits from established enterprise security architecture are similar to benefits of IT architecture - cost effectiveness through standardization, risk driven approach to development of security capabilities, better integration of security capabilities, reusing of existing skills. However, despite several public architecture frameworks such as SABSA, TOGAF and ZACHMAN there are still number of challenges related to #securityarchitecture development as well as defining suitable processes to apply architecture framework and also to maintain it up to date. Finding right approach is not a simple task, but starting a vision for #securityarchitecture that is presented to security stakeholders and approved by management is in most cases first step forward.