Enterprise Security Architecture—A Top-down Approach

Rassoul Ghaznavi-Zadeh, CISM, COBIT Foundation, SABSA, TOGAF

Implementing security architecture is often a confusing process in enterprises. Traditionally, security

architecture consists of some preventive, detective and corrective controls that are implemented to
protect the enterprise infrastructure and applications. Some enterprises are doing a better job with
security architecture by adding directive controls, including policies and procedures. Many information
security professionals with a traditional mind-set view security architecture as nothing more than having
security policies, controls, tools and monitoring.

The world has changed; security is not the same beast as before. Today’s risk factors and threats are not
the same, nor as simple as they used to be. New emerging technologies and possibilities, e.g., the
Internet of Things, change a lot about how companies operate, what their focus is and their goals. It is
important for all security professionals to understand business objectives and try to support them by
implementing proper controls that can be simply justified for stakeholders and linked to the business risk.
Enterprise frameworks, such as Sherwood Applied Business Security Architecture (SABSA), COBIT and
The Open Group Architecture Framework (TOGAF), can help achieve this goal of aligning security needs
with business needs.

SABSA, COBIT and TOGAF and Their Relationships

SABSA is a business-driven security framework for enterprises that is based on risk and opportunities
associated with it. SABSA does not offer any specific control and relies on others, such as the
International Organization for Standardization (ISO) or COBIT processes. It is purely a methodology to
assure business alignment.

The SABSA methodology has six layers (five

horizontals and one vertical). Each layer has a
different purpose and view. The contextual layer
is at the top and includes business requirements
and goals. The second layer is the conceptual
layer, which is the architecture
view. Figure 1shows the six layers of this
framework.

COBIT 5, from ISACA, is “a comprehensive

framework that assists enterprises in achieving
their objectives for the governance and
management of enterprise IT.”1 This framework
includes tool sets and processes that bridge the
gap between technical issues, business risk and
process requirements. The goal of the COBIT 5
framework is to “create optimal value from IT by
maintaining a balance between realising benefits
and optimising risk levels and resource use.”
COBIT 5 aligns IT with business while providing governance around it.

The COBIT 5 product family has a lot of documents to choose from, and sometimes it is tough to know
exactly where to look for specific information. Figure 2 shows the COBIT 5 product family at a
glance.2 COBIT Enablers are factors that, individually and collectively, influence whether something will
work.

The COBIT framework is based on five principles (figure 3). Applying those principles to any architecture
ensures business support, alignment and process optimization.3

By using a combination of the SABSA frameworks and COBIT principles, enablers and processes, a top-
down architecture can be defined for every category in figure 2. As an example, when developing
computer network architecture, a top-down approach from contextual to component layers can be defined
using those principles and processes (figure 4).

TOGAF is a framework and a set of supporting

tools for developing an enterprise
architecture.4 The TOGAF architecture
development cycle is great to use for any
enterprise that is starting to create an enterprise
security architecture. Similar to other frameworks,
TOGAF starts with the business view and layer,
followed by technology and information
(figure 5).5

TOGAF is a useful framework for defining the

architecture, goals and vision; completing a gap
analysis; and monitoring the process.

By using SABSA, COBIT and TOGAF together, a

security architecture can be defined that is
aligned with business needs and addresses all
the stakeholder requirements. After the
architecture and the goals are defined, the
TOGAF framework can be used to create the
projects and steps, and monitor the
implementation of the security architecture to get
it to where it should be.

Using the Frameworks to Develop an

Enterprise Security Architecture
The fair question is always, “Where should the enterprise start?”

If one looks at these frameworks, the process is quite clear. This must be a top-down approach—start by
looking at the business goals, objectives and vision.

The initial steps of a simplified Agile approach to initiate an enterprise security architecture program are:

 Identify business objectives, goals and strategy

 Identify business attributes that are required to achieve those goals
 Identify all the risk associated with the attributes that can prevent a business from achieving its
goals
 Identify the required controls to manage the risk
 Define a program to design and implement those controls:
o Define conceptual architecture for business risk:
 Governance, policy and domain architecture
 Operational risk management architecture
 Information architecture
 Certificate management architecture
 Access control architecture
 Incident response architecture
 Application security architecture
  Web services architecture
 Communication security architecture
o Define physical architecture and map with conceptual architecture:
 Platform security
 Hardware security
 Network security
 Operating system security
 File security
 Database security, practices and procedures
o Define component architecture and map with physical architecture:
 Security standards (e.g., US National Institute of Standards and Technology
[NIST], ISO)
 Security products and tools (e.g., antivirus [AV], virtual private network [VPN],
firewall, wireless security, vulnerability scanner)
 Web services security (e.g., HTTP/HTTPS protocol, application program
interface [API], web application firewall [WAF])
o Define operational architecture:
 Implementation guides
 Administrations
 Configuration/patch management
 Monitoring
 Logging
 Pen testing
 Access management
 Change management
 Forensics, etc.

It is that simple. After all risk is identified and assessed, then the enterprise can start designing
architecture components, such as policies, user awareness, network, applications and servers.

Figure 6 depicts the simplified Agile approach to initiate an enterprise security architecture program.
A Real-Life Example
This section describes a simple and practical example of the steps that can be taken to define a security
architecture for an enterprise.

The enterprise in this example is a financial company, and their goal is to have an additional one million
users within the next two years. Some of the business required attributes are:

 Availability—Systems need to be available to customers at all times.

 Customer privacy—Customers’ privacy needs to be ensured.
 Accuracy—Customers’ and company information must be accurate.
 Regulatory—Company is under regulation (Payment Card Industry [PCI] in this case) and must
be aligned with regulatory requirements.

Some of the business risk includes:

 Not having a proper disaster recovery plan for applications (this is linked to the availability
attribute)
 Vulnerability in applications (this is linked to the privacy and accuracy attributes)
 Lack of segregation of duties (SoD) (this is linked to the privacy attribute)
 Not Payment Card Industry Data Security Standard (PCI DSS) compliant (this is linked to the
regulated attribute)

Some of the controls are:

  Build a disaster recovery environment for the applications (included in COBIT DSS04 processes)
 Implement vulnerability management program and application firewalls (included in COBIT
DSS05 processes)
 Implement public key infrastructure (PKI) and encryption controls (included in COBIT DSS05
processes)
 Implement SoD for the areas needed (included in COBIT DSS05 processes)
 Implement PCI DSS controls

All of the controls are automatically justified because they are directly associated with the business
attributes.

Like any other framework, the enterprise security architecture life cycle needs to be managed properly. It
is important to update the business attributes and risk constantly, and define and implement the
appropriate controls.

The life cycle of the security program can be managed using the TOGAF framework. This is done by
creating the architecture view and goals, completing a gap analysis, defining the projects, and
implementing and monitoring the projects until completion and start over (figure 5).

Using CMMI to Monitor, Measure and Report the Architecture Development Progress
Finally, there must be enough monitoring controls and key performance indicators (KPIs) in place to
measure the maturity of the architecture over time.

The first phase measures the current maturity of required controls in the environment using the Capability
Maturity Model Integration (CMMI) model. The CMMI model has five maturity levels, from the initial level
to the optimizing level.6 For the purpose of this article, a nonexistent level (level 0) is added for those
controls that are not in place (figure 7).
The aim is to define the desired maturity level, compare the current level with the desired level and create
a program to achieve the desired level.

This maturity can be identified for a range of controls. Depending on the architecture, it might have more
or fewer controls.

Some example controls are:

 Procedural controls
o Risk management framework
o User awareness
o Security governance
o Security policies and standards
 Operational controls
o Asset management
o Incident management
o Vulnerability management
o Change management
o Access controls
o Event management and monitoring
 Application controls
o Application security platform (web application firewall [WAF], SIEM, advanced persistent
threat [APT] security)
o Data security platform (encryption, email, database activity monitoring [DAM], data loss
prevention [DLP])
o Access management (identity management [IDM], single sign-on [SSO])
 Endpoint controls
 o Host security (AV, host intrusion prevention system [HIPS], patch management,
configuration and vulnerability management)
o Mobile security (bring your own device [BYOD], mobile device management [MDM],
network access control [NAC])
o Authentication (authentication, authorization, and accounting [AAA], two factor, privileged
identity management [PIM])
 Infrastructure controls
o Distributed denial of service (DDoS), firewall, intrusion prevention system (IPS), VPN,
web, email, wireless, DLP, etc.

The outcome of this phase is a maturity rating for any of the controls for current status and desired status.
After the program is developed and controls are being implemented, the second phase of maturity
management begins. In this phase, the ratings are updated and the management team has visibility of the
progress.

Figure 8 shows an example of a maturity dashboard for security architecture.

Conclusion
Regardless of the methodology or framework used, enterprise security architecture in any enterprise must
be defined based on the available risk to that enterprise. The enterprise frameworks SABSA, COBIT and
TOGAF guarantee the alignment of defined architecture with business goals and objectives.

Using these frameworks can result in a successful security architecture that is aligned with business
needs:

 COBIT principles and enablers provide best practices and guidance on business alignment,
maximum delivery and benefits.
 The COBIT Process Assessment Model (PAM) provides a complete view of requirement
processes and controls for enterprise-grade security architecture.
 SABSA layers and framework create and define a top-down architecture for every requirement,
control and process available in COBIT.
 The TOGAF framework is useful for defining the architecture goals, benefits and vision, and
setting up and implementing projects to reach those goals.
 The CMMI model is useful for providing a level of visibility for management and the architecture
board, and for reporting the maturity of the architecture over time.

The simplified agile approach to initiate an enterprise security architecture program ensures that the
enterprise security architecture is part of the business requirements, specifically addresses business
needs and is automatically justified.

Endno