Information Assurance and Security 1 P age |1

Lesson 6 Security Architecture

Security Architecture Components
Effective and efficient security architectures consist of three components. These are the
people, processes, and tools that work together to protect companywide assets. To
align these components effectively, the security architecture needs to be driven by
policy stating management's performance expectations, how the architecture is to be
implemented, and how the architecture will be enforced. This enables the architecture to
guide management so that decisions are aligned and consistent throughout the entire IT
landscape. The architecture also should be strategic — it must be structured in a way
that supports the organization's business goals.
The components described below should form part of an effective and carefully planned
security architecture and should be evaluated during audits of the security architecture.
These are:

 Guidance in the areas of incident response, baseline configuration, account creation

and management, disaster recovery, and security monitoring.
 Identity management.
 Inclusion and exclusion of who and what is subject to the domain of the security
architecture.
 Access and border control.
 Validation and adjustment of the architecture.
 Training.
 Technology.

Guidance
The security architecture should be created and implemented based on established
security guidance (i.e., policies and procedures).
These companywide policies and procedures should:

 Document and communicate management's goals and objectives for the architecture.
 Define the organization's response to laws, regulations, and standards of due care
(i.e., those actions that would be considered reasonable by a prudent individual to
avoid harm to another and are included frequently in contractual agreements).
 Identify the elements, function, and scope of the security architecture.
 Support other functional policies (e.g., policies that identify specific ways to achieve a
safe, reliable, and consistent customer experience).

Security policies and procedures also should help the organization implement the
elements needed to support the architecture.
These elements include:

 Standards that define common expectations on each security tool or procedure, such
as the organization's firewall design or specific antivirus software in use.
 Procedures that provide step-by-step instructions on actions to be performed to
complete a task, such as user registration or incident response activities.

Jennifer Roxas-Magbanlac, MIT

Information Assurance and Security 1 P age |2

 Baselines that identify a minimum level of expected performance and provide a

starting point for measuring the degree of compliance with management
expectations, such as server-build specifications and intrusion detection system
configurations.
 Guidelines that provide general items or approaches to consider, such as product
evaluation criteria or government recommendations.

Incorporating these elements will enforce the security policy principles on every
business process and system. Figure 1 illustrates a typical policy hierarchy.

Figure 1. Security policy hierarchy (Copyright © 2004 Deloitte Development LLC)

Identity Management
Identity management is an integrated system of companywide policies, processes, and
technologies that enables user access to network resources and online applications.
Clear security roles and responsibilities need to be established for all company users as
part of the identity management system.
Common security architecture users include:

 The executive managers responsible for establishing corporate strategy and

monitoring corporate goals.
 The information security employees responsible for the security environment's daily
operation and monitoring.
 The application and data owners who use the IT applications and related business
data.
 The data custodians or the IT staff responsible for maintaining IT applications and
database infrastructure.
 The end-users or employees who interact with the IT applications and data on a daily
basis.
 The internal auditors who are responsible for reviewing the identity management
system's compliance with internal and external rules.

Jennifer Roxas-Magbanlac, MIT

Information Assurance and Security 1 P age |3

Many organizations establish these user roles at a minimum. Which specific roles are
identified and established depends on the company's structure and level of granularity
associated with each job function.
Inclusion and Exclusion
The security architecture should protect all elements of the company's IT environment
— from publicly accessible Web and e-mail servers and financial reporting systems to
confidential human resources (HR) data and private customer information. To address
this breadth of resources and information, it is vital that a consistent architecture be
deployed that takes into account who is authorized to access which systems and data
(i.e., inclusion) and who is to be prevented from accessing particular systems and data
(i.e., exclusion). Understanding who the various potential users are and the potential
information they might need to access allows the organization to determine whom to
include and exclude from different portions of the IT environment.
Access and Border Control
Access to IT and business resources should be controlled through a series of layers —
from broad and general to discrete and granular. In many cases, stopping the majority
of users at the border of a network and allowing only recognized business partners and
employees to come through is sufficient to control access. Once inside a company's
environment, access to various areas should be restricted based on business need. A
typical guideline in this respect is the Principle of Least Privilege, which states that
users are given the minimum access and authority necessary to perform their required
job functions. Discrete levels of assigned access rights results in a robust security
matrix that is understandable and maintainable when combined with a detailed data
classification process that accounts for the varying sensitivity of business information.
Validation and Adjustment
Developing secure borders and restricting access based on business need is not a one-
time process — businesses grow and change, people come and go, and technology
advances. This constantly changing environment requires that the security architecture
be monitored continuously and adjusted as needed. The status quo should be validated
periodically through IT audits, security testing, and regular attestations by IT
management to ensure it continues to meet the needs of the business. If not, the
security architecture should be modified to provide the required level of security and risk
management. (Refer to the security assessments section for information on how to
evaluate the security architecture).
Training
By nature, most people are helpful and focus on performing their tasks efficiently.
However, they perceive security as an impediment to their job function and give little
thought to the risks they face every day. Additionally, as an organization changes and
new security threats are discovered, the security architecture also changes. Regular
training keeps security concerns fresh in the minds of employees and allows them to
remain updated with current practices and management expectations.

Jennifer Roxas-Magbanlac, MIT

Information Assurance and Security 1 P age |4

Technology
The hardware and software used to deploy, manage, and monitor the security
architecture is the element most frequently associated with security. However, a
security architecture that relies on technology alone and disregards the people and
processes that impact the architecture may not perform as well as intended. Because of
the rapid nature of change in the technology industry, new solutions are frequently
deployed to address existing concerns. Any time a technology change occurs in the
security architecture, the change's impact on the existing people and processes should
be evaluated to determine if related changes need to be made.
Design Frameworks
Organizations can choose from a variety of existing frameworks when creating their
security architecture. Once selected, a framework only needs to be established once to
simplify the management of security domains, trust levels, and data classification.
Subsequently, the framework can be validated and updated periodically or as needed.
This framework also can be used to design, manage, and grow the security
architecture. Auditors should recommend that all classification levels — such as security
domains, trust levels, and data classifications — be restricted to a small, manageable
amount, depending on the complexity of the IT environment.
When managing security domains, the IT environment should be classified into discrete,
logical entities that ease management activities (i.e., granularity) and minimize negative
impact (i.e., compartmentalization). For instance, logical entities could be divided based
on their expected trust levels (i.e., trusted — a restricted internal network, semi-trusted
— a shared drive to which business partners have access, and untrusted — public
wireless networks used by employees to work remotely) and function levels (i.e., a local
area network for user access to applications, a transport network in a client/server
environment to which users do not have access, or a data storage network where a
company's critical information resources are stored).
Trust levels are the criteria used to determine the reliability and access authorities of an
unknown user and should be hierarchical in nature. However, they could be equal or
unequal across security domains. For example, an HR network in New York (i.e., one
security domain) may be equal in trust level to another HR network in Los Angeles (i.e.,
a second security domain). However, both networks are connected across the Internet
(i.e., an untrusted network). Therefore, a request for Los Angeles data from an HR clerk
in New York might be fully trusted if the data request originated from the New York
network, but not from the Internet.
In addition, users can move from a higher to a lower area of trust without restriction. It is
quite common for a business to allow employees to access the Internet from an internal
network without authenticating their identity, but quite uncommon to allow anyone on
the Internet access to their internal network without authentication. Furthermore, data
can move from areas of lower trust to higher trust, but not from higher to lower. For
example, financial information that is available to the public on the Internet should be
available to the chief financial officer (CFO) from the internal network. Yet, information
that is available to the CFO on the internal network should not be available to the public
on the Internet. Figure 2 below shows three different trust levels used for the
organization's physical domain.

Jennifer Roxas-Magbanlac, MIT

Information Assurance and Security 1 P age |5

Figure 2. Trust level categories based on physical domains (Copyright © 2004 Deloitte
Development LLC)
Finally, all company data and resources should be classified upon entry to an
organization, using descriptors such as public, private, proprietary, privileged,
confidential, top secret, sensitive, and restricted. The specific labels used are less
important than the meanings assigned to each and whether they are defined clearly,
applied consistently companywide, manageable in number, and reviewed periodically.
Because security costs increase as access to the data becomes more restricted, and
data classification can change based on the value and nature of the information, the
classification should be as cost effective as possible and based on the value of the
information. For instance, corporate policies do not need to be stored on a separate
encrypted network or be monitored by an intrusion detection system.
Another aspect of data classification is that of access control. Access to data and
resources can be granted using the following three controls:

 Principle of Least Privilege, in which access is granted only to resources that are
required for specific, authorized functions (e.g., allowing an employee access to
Microsoft Publisher or Word).
 Mandatory access control, in which technical, low-level access is granted by the
custodian of the application or data (e.g., allowing or denying access to a file).
 Discretionary access control, in which high-level access is established by the
application or data owner based on need (e.g., creating a purchase order).

Companywide data should be classified based on this role-based access control to

enable the organization to define roles and functions, as well as grant, modify, or
remove user rights more effectively.

Jennifer Roxas-Magbanlac, MIT

Information Assurance and Security 1 P age |6

Security Assessments
Assessments are an essential component of the security architecture because they
enable the company to determine the architecture's effectiveness. As part of the
assessment, internal auditors can recommend that the organization creates a cross-
functional team consisting of the following:

 Information security staff, subject-matter experts who will be responsible for the
architecture's daily security.
 IT and operations management staff who will be responsible for supplying the IT
infrastructure that supports the organization.
 System and network administrators familiar with the IT environment and responsible
for implementing much of the technical element of the security architecture.
 Internal auditors who are subject-matter experts in the areas of risk, controls, and
business process oversight.
 Operations staff who will work with the information security staff to secure corporate
IT resources.
 Business process and information owners who use the security architecture and
perform a key role in the security architecture's successful operation.
 Legal and human resources with knowledge on legal, regulatory, and personnel
issues and concerns.
 System owners who are responsible for application controls, data classification, and
granting access to IT resources.
 Outside service providers with specialized technical skills that can supplement or
enhance internal skills.

Before the assessment, auditors should solicit input from each of the team members
above as early in the planning stage as possible to ensure all potential risks and
concerns are addressed and a good understanding of the environment is available to
guide the development of audit activities. In addition, auditors need to consider the use
of an independent external provider with the skills and tools necessary to assess the
environment in thorough detail if the required capacity is not available within the
company. This is particularly relevant where vulnerability assessments and penetration
testing are concerned due to the highly specialized nature of the work and the
continuously expanding scope of the threat environment. In some cases, it may even be
more efficient to rely on a service provider to keep up with the constant flux in the
required field of knowledge rather than attempt to get internal resources up to speed a
few times per year.
Once the necessary information is gathered from those responsible for each
architecture component or activity, auditors are ready to begin the assessment process.
To maximize their efforts, auditors need to become familiar with influencing factors,
including but not limited to:

 Common industry risks, such as corporate espionage.

 Unique risks to the individual organization, such as the use of a particular operating
system.
 Specific frameworks published by government agencies, academic researchers, and
professional organizations.

Jennifer Roxas-Magbanlac, MIT

Information Assurance and Security 1 P age |7

 The methodology used by the organization in the design and operation of the security
architecture.

In addition, auditors should consider "breaking" the architecture into manageable

pieces. To do this, auditors need to perform a review of the documented policies and
procedures for completeness, aligning them with recognized standards and by
relevance to the environment and business needs. This needs to be followed by a
review of the security organization and associated business processes for concerns
such as staffing levels, training, and segregation of duties. A separate technical audit for
design, configuration, and operation of the security infrastructure also should take place
and might include vulnerability and penetration testing.

Jennifer Roxas-Magbanlac, MIT