Enterprise architecture (EA) and information security must work together seamlessly to ensure security is fully integrated across all organizational initiatives. This piece explores the integration points between information security and EA and details
the possible organizational constructs in which the two can function.
EA and Security Architecture Explained
EA is responsible for alignment of business and enterprise initiatives, serving as an advisor to business management on business and information integration strategies and auditing compliance with EA standards.
Security architecture, on the other hand, describes an organization’s core security principles and procedures for securing data—including not just in storage and other systems, but also personnel teams and their roles and functions. This information
is provided in the context of organizational requirements, priorities, risk tolerance and related factors to help ensure security architecture reflects both current and future business needs. Security architecture is narrower than EA and focuses on
hardware and software security controls and how to use those components to design, architect and evaluate secure computer systems.
READ: Enterprise Security Architecture Best Practices
Security Architecture Responsibilities
The NIST SP 800-37 Risk Management Framework and SP 800-53 Privacy Framework call out
security architecture in the configuration management, planning, program management, and system and services acquisition security and privacy control families. Key responsibilities of security architecture include:
- Conduct threat modeling to identify, communicate and understand threats and mitigations within the context of protecting enterprise infrastructure and applications. This is a crucial responsibility of security architecture.
- Have a strategic view of the attack surface and ensure it is captured in the design and implementation of security controls.
- Maintain a security reference architecture to ensure optimization and prevention of duplicate controls in the enterprise.
- Create baseline configurations of systems to reflect the current enterprise architecture.
- Develop security and privacy plans for systems that are consistent with the organization’s enterprise architecture.
- Develop security and privacy architectures for systems that describe how the security and privacy architectures are integrated into and support the enterprise architecture. Review and update the security and privacy architectures to reflect updates in
the enterprise architecture.
- Integrate security and privacy requirements into the SDLC: The effective integration of security and privacy requirements into enterprise architecture also ensures important security and privacy considerations are addressed early in the system lifecycle
and that those considerations are directly related to the organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent
with the risk management strategy of the organization.
- Require system/component/service developers to produce a design specification and security architecture consistent with and supportive of the organization’s security architecture, which is established within and is an integrated as part of the organization’s
enterprise architecture.
EA and Security Architecture Alignment
There are two typical ways in which EA and security architecture can align:
- Security architecture is a subcomponent of EA: In this model, EA’s 360-degree view of the organization means security can be involved in the planning stages of new initiatives, which decreases the risks involved. Furthermore, EA helps detect and
eliminate threats originating from shadow IT, redundant applications and other IT missteps. An up-to-date view of the entire architecture enables an organization to get the best possible view of its current technology assets. The main disadvantage
of this model is that EA is primarily accountable to the business and can be under intense pressure to roll out initiatives, whereas security architecture can have a slowing effect on rollouts when it identifies security issues and the remediation
requirements associated with them. Another disadvantage is that if security architecture sits in EA, it loses a line of sight with respect to what’s happening in the security organization from a technology and threat management perspective,
and that may limit its ability to define the right architecture.
- Security architecture is a subcomponent of information security: The benefit of this scenario is that security architecture develops intimate familiarity with security tools, platforms, changes, threats, as well as the attack surface and its management.
That level of familiarity grounds security architecture to develop proper architecture for the enterprise. The disadvantage of this scenario is that security architecture loses insight into companywide issues, such as shadow IT, new business initiatives,
etc.
A good way to get the best of both worlds is to create a dotted-line reporting relationship to the other function. For example, if security architecture is a subcomponent of EA, create a dotted-line relationship between security architecture and information
security. However, leadership must be very intentional about this. Multiple reporting relationships, if not aligned properly, can be a significant cause of consternation to the impacted individuals—and security architects are in high demand.
READ: How to Structure the Information Security Function
RACI Chart for Security Initiatives
A general responsible-accountable-consulted-informed (RACI) model is helpful to break down different functions across roles.
Figure 1 shows a sample RACI chart that prescribes the roles and responsibilities for security initiatives. However, please treat this as a starting point only for your situation because organizations and their technology deployment practices may differ
substantially. You may need to adapt this model for your specific needs (e.g., for DevOps or Agile variants in use within your organization).
Integrating EA and Security Architecture
It’s beneficial to consider and include security architecture at the inception point of enterprise architecture. Defining the framework for it may seem challenging, but to increase your chances of success:
- Ensure the responsibilities of security architecture are well-defined: NIST SP 800-37 and 800-53 are considered the de facto standards in this respect. Security architecture responsibilities should include solutioning, design, baseline configuration,
threat modeling, SDLC integration, attack surface management and developer security architecture.
- Align the security architecture function organizationally such that it has the empowerment necessary to fulfill its responsibilities: Placing security architecture within EA with dotted-line reporting to information security may work well. Just be aware
that being intentional in this organizational design is important to ensure your security architects feel empowered to define the right security strategy for the enterprise.
- Prepare a RACI chart and align the organization around that: A sample RACI chart has been provided with this report that you can adapt to your needs.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.