February 2007

Elements of a Good Security Architecture

Effective security architectures help organizations to better coordinate companywide security efforts. Learning how security architectures work can help internal auditors maximize security audits and play a more proactive role in their organization's security activities.

Nelson E. Gibbs, CIA, CISA, CISM, CISSP
Senior Manager, Audit and Enterprise Risk Services
Deloitte & Touche

Antivirus programs, firewalls, and intrusion detection systems play a key role in protecting organizations against external threats. To maximize these security tools as well as existing policies and procedures, companies should implement a companywide architecture that integrates these different elements. This architecture should be a structured, coordinated activity consisting of the people, processes, and tools that work together to secure an organization's resources and should rely on the continuous flow of information throughout the entire organization to adapt to ongoing IT changes. To maximize audit efforts, new IT auditors need to understand the main components of a security architecture, the different frameworks for designing and evaluating an effective architecture, and how to assess the architecture's effectiveness.

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.
• 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.

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.

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.

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.

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.
• 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.

MOVING FORWARD

Effective and well-planned security architectures can help an IT department manage companywide risks consistently by leveraging industry best practices and allowing the department to make better, quicker decisions. In addition, security architectures can reduce the cost of managing IT risks, improve flexibility and adaptability to changes by implementing common IT practices and solutions, and promote interoperability and integration while minimizing risks.

Internal auditors who wish to obtain more information about the security architecture process could visit the following articles, Web sites, and publications:

• IBM's "A Security Architecture for the Internet Protocol" article.
• "Layered Insecurity" from Information Security magazine.
• ISACA's Control Risk Self-Assessment Procedure.
• The IT Infrastructure Library Security Management publication from the UK's Office of Government Commerce.
• The International Standardization Organization's 17799: 2005 Standard, Code of Practice for Information Security Management.
• The Software Engineering Institute's Operationally Critical Threat, Asset, and Vulnerability Evaluation (a.k.a., OCTAVE) Web page.
• The National Institute for Standards and Technology's Generally Accepted Principles and Practices for Securing Information Technology Systems (PDF, 188 KB) and Engineering Principles for IT Security (PDF, 144 KB).

Nelson Gibbs, CIA, CISA, CISM, CISSP, is a senior manager with Deloitte & Touche LLP in its Audit and Enterprise Risk Services function, where he works with control assurance for financial services industry clients. Gibbs has more than 14 years of experience in information systems operations and management and is a frequent presenter and instructor on IT audit, security, and risk management topics for several international industry organizations.

Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.

Name:

Email:

Subject:

Comment:

---

To make something bold:
<strong>Text to bold</strong>

To make something italic:
<em>Text to italicize</em>

To make a hyperlink:
<a href="URL">Text to link</a>

---