Building the Foundation: Architecture Design - Chapter 3

This is Chapter 3 in Tom Olzak's book, "Enterprise Security: A practitioner’s guide."

Chapter 2 is available here: Risk Management – Chapter 2

Chapter 1 is available here: Enterprise Security: A practitioner’s guide – Chapter 1

Security enables the business; that is the central them of this book. However, how do we ensure that what we daily implement consistently meets this objective? This is the purpose of architecture designs and the processes and documentation supporting them. In this chapter, we define the various types of enterprise architectures, how to integrate them into strategic and tactical business objectives, and how to build from business need to system and network design.

Architecture Defined

In general, architecture brings focus to key areas of the enterprise. It helps define decision criteria used when designing and managing technical solutions. Without this close integration with business need, what we build will not pass the management test. In other words, it will not provide the flexibility needed to meet changing business demand; nor will it allow addition of emerging technologies needed to compete in the organization's industry.

An architect must understand business strategy and intended outcomes before taking any actual design steps. We meet with all stakeholders in the organization's success to ensure we know enough to integrate sufficient versatility into the design to help us avoid saying "no" whenever project planning meetings include discussions about new technology. In other words, we start with business understanding and move to a logical view of the organization's required infrastructure, software, and security.

The umbrella term "enterprise architecture" covers various technical blueprints needed to move, process, and store information: information, network, system, and security. Architecture design addresses information collection, processing, storage and delivery requirements, and conceptual models. It is vendor-, technology-, and solution-neutral.

Information Architecture

Information drives and supports a business. The information architecture identifies required information, how and where to collect it, required processing, what to store, and how users, business partners, customers, etc. access and share it. It is the blueprint describing how the business functions, or will function.

Network Architecture

The network architecture consists of all components creating pathways between systems, end-point devices, and business entities, including routing, switching, protocols, etc.

System Architecture

System architecture defines all components needed to support business processes. For example, components needed to support payroll include end-user devices, application servers, database servers, and operating systems.

Software Architecture

Software architecture defines how applications should behave and interact with other applications, including source code constructs. It conceptually addresses inputs to and outputs from each phase of the software development lifecycle. Again, it is conceptual, not functional.

Security Architecture

Security architecture design encompasses all other architectures. It enables solution design that complies with both business and regulatory/policy constraints. It is built into each of the other architectures and supports them. The existence of documented security architecture takes much of the daily responsibility for security policy compliance away from the security team and places it on the desks of business analysts as well as network, server, and software engineers.

Architecture Design

The outcome of architecture design is an integrated model that supports business information requirements, strategy, and outcomes. Figure 3-1 is a conceptual model of the various architectures and their relationships. This model is driven by several basic principles. The following list is a condensed and modified version of Price's design principles in, "Conceptual Principles for the Security Architect" (2011).

Principle 1 – Documentation might be the most important outcome of the design process. Be sure it is easy to understand and correctly reflects design concepts. Any disconnect between intent and documentation results in functional designs that fail to meet expectations. Such designs have a short life… possibly as short as the career of the sloppy architect.
Principle 2 – No plan is foolproof. The army has a saying: a good plan is only good until the boots hit the ground. So, too, with architectures. What seems like a good idea in a conference room might be unworkable in the existing data center. In addition, what is buildable might not produce expected outcomes. Expect the unexpected.
Principle 3 – The same security goal underlies all enterprise architectures: successful business operation supported by reasonable and appropriate controls that ensure data confidentiality, integrity, and availability in accordance with standards of best practice and relevant regulations.
Principle 4 – Business requirements require translation into forms that technical architecture designers can mold into conceptual models. The business requirements and related architecture models need approval by all stakeholders.

Figure 3-1: Enterprise Architecture (Olzak, 2010, p. 4)

Principle 5 – It makes no sense to design something that engineers cannot build. For example, existing infrastructure and budget constraints might prohibit certain models.
Principle 6 – Architects who do not clearly understand the business, its mission, and its operations, design incomplete architectures.
Principle 7 – Use attack trees and other tools and techniques to understand how threats can exploit critical systems and sensitive data.
Principle 8 – Technical and IT users will avoid complex and hard to use security controls.
Principle 9 – Testing models and final architecture implementations must take into consideration design. For example, if a critical vulnerability is found on a system component, but existing controls result in very low probability of exploitation, what is the actual risk to the business?
Principle 10 – Ensure architecture constraints are reviewed during the change management process. Implementing solutions not compliant with architecture design often leads to higher business risk.
Principle 11 – If the security architecture does not meet all requirements for expected risk outcomes, risk is probably greater than management expects.
Principle 12 – Meeting security requirements means the architecture is compliant with regulatory and best practice constraints. However, compliance does not equal low risk. Only risk assessments during and after architecture design and technology implementation can measure success in meeting desired risk mitigation objectives.

Business Strategy and Relevant Regulations

In Chapter 2, we looked at the importance of understanding business strategy and operations. It is even more important to document this information when designing new or modifying existing architecture designs. However, architecture design also requires that we look forward to what the business might look like in the future. An accurate look at current and future business operation requires participation of C-level managers or department heads.

To remain successful, business must change as industry and markets change. Consequently, architectures not designed to meet the dynamic nature of business are doomed. For example, if a current architecture does not include various types of Internet-facing security zones, you might find yourself struggling not to simply say, "We can't do that!" However, designers who looked to the future saw the possibility that various types of remote access might be required designed conceptual models flexible enough to absorb new, and possibly as yet unknown, technologies.

In addition to general security best practices and optimized business operation, designers must pay close attention to data protection mandates unique to the target organization. What federal, state, and federal regulations apply to the business?

Information Architecture

Information architecture arises from business analysis documentation. It mirrors how the business operates and how it measures success. It crystallizes around answers to the following.

What information does the business collect? How is it used? How much of it is stored and where? Why is it kept?
What are all the different types of data and how are they classified? Do data owners exist for each data type or aggregate data collections?
How is data collected? Why?
How is data shared? Why?
What are the business information availability requirements? Why?
What confidentiality, integrity, and availability requirements apply?
What is the legal environment surrounding the organization's industry and the data it uses?

I include several "why's" in the questions. Often, information previously required is no longer needed. Further, operations can often survive on much less data than departments think they need. Applying need-to-know principles early helps reduce cost of implementing other architectures.

The next three architectures directly implement information requirements, as shown in Figure 3-2.

Figure 3-2: Information Delivery and Processing Architectures

Network Architecture

A common mistake when designing technical architectures is immediately jumping to solutions. This causes undue influence of technical designer preferences while pushing to the background vendor- and solution-neutral models that best illustrate business future state. Again, architecture design is a conceptual exercise: the infrastructure do we need, not how we should build it.

Network architecture design begins with answering important questions.

How many locations are supported?
What are the remote access requirements?
Do data and system classifications call for security zones? What should zones contain?
What types of devices must the network support?
What wireless capabilities does the business require?
What are the minimum performance requirements, overall and by security zone?
What are system, security zone, and network maximum tolerable downtimes?

The outcome of network architecture design is documentation that includes,

How users (human, machine, application, etc.) will access the network, both remotely and internally.
Where data is collected, how it traverses the business, where it is processed, and how it is stored.
Intended protocols and encryption requirements.
Business thresholds for cost, performance, and availability.

The network architecture provides connectivity, security, and communication services for systems.

System Architecture

Most information work is performed in systems, and systems provide the richest targets for cyber-criminals. A "system" consists of all components necessary to collect, process, store, and disseminate information related to a business process. Figure 3-3 shows common system components.

Figure 3-3: System Components (Olzak, 2010, p. 6)

System architecture begins with capstone requirements that apply to all current and future systems, including

What mechanisms are allowed for data collection? For example, is all data collected with wired desktops, or will data collection include RF devices, laptops, tablets, etc.?
With what external systems, remote or local, may systems communicate? What security or regulatory requirements exist?
What security and performance considerations affect allowed protocols and communication methods? What business constraints exist?
What are the minimum access control requirements?

In addition to these basic modeling requirements and guidelines, some data classifications might require greater system assurance levels. For example, one set of input/output protocols might work fine for systems managing confidential data, but it might fall short of constraints necessary for restricted data systems. Remember, a system is classified based on the most sensitive data it receives, processes, stores, or shares.

Software Architecture

Most of the information gathered for network and system architectures applies directly to software architecture. However, software architecture constructs unique to internal software design require separate consideration. Usually, it is poorly designed or written software that provides the open gate for cyber-attack.

Figure 3-4 depicts one approach to the software/system development lifecycle. In each phase, risk and regulatory issues impact outcomes… or they should. Table 3-1 lists risk considerations.

Figure 3-4: SDLC

Software presents the biggest attack surface to potential threats. An attack surface, as described in Chapter 2, consists of entry points, exit points, data channels, and untrusted data items. Most applications include all these attack surface components.

Ensuring application security standards of best practice included in the SDLC requires a clear picture of what the software environment should look like. The final software architecture provides necessary vision and guidelines. Examples of development standards of best practice include the Open Source Web Application Security Program (OWASP, http://owasp.org) and the Carnegie Mellon Software Engineering Institute (http://www.cert.org/secure-coding/).

Table 3-1: SDLC Risk Considerations (Stoneburner, Goguen, & Feringa, 2002, p. 5)

Regardless of the standard of best practice you select, software architecture design requires input, collaboration, and cooperation across many stakeholder groups, as shown in Figure 3-5. The effectiveness of security architecture is only as good as the organization's willingness and ability to implement solutions within its framework. Office politics, developer preferences, infrastructure engineer biases, and security team flags-in-the-sand are just a few of the hurdles software architects must overcome.

Figure 3-5: SDLC Stakeholders (Paul, n.d., p. 1)

One thing the stakeholders should decide upon early in architecture design is a set of guiding principles. A short list of required outcomes is a good start toward helping everyone begin moving in the same direction. Table 3-2 is an example of what development principles might look like. Loosely based on a table by Paul (n.d.), it provides a short list of development should-do's that put data protection at the center of the design process.

Table 3-2: Basic Software Architecture Design Principles

Security Architecture

Figure 3-1 infers that security architecture is the foundation for enabling all other enterprise architectures. While this is a good definition, it also lacks an important characteristic: security architectural elements are integrated into all other architectures.

The basis for the security architecture is the definition of layered-defense as it applies to the unique requirements and operational characteristics of the organization. Although the "how" varies widely across implementations, the "what" is typically the same. Figure 3-6 shows components of a layered security architecture. Creating a visual representation of the control categories is the first step in helping the architecture design team agree to the basics.

Figure 3-6: Layered Defense

Policy, Standards, Guidelines

Before starting on security architecture, we need to understand management's appetite for risk as documented in policy. The architecture design is a blueprint arising from policy intent and management's expectations of risk. The outcome of security architecture design must fit within these constraints.

Employee Awareness

No architecture survives poor employee security behavior. In addition to defining controls and infrastructure design, include a map of how you plan to ensure safe employee behavior through training and awareness practices.

Network Intrusion Defense and Access Control

How do you plan to prevent unauthorized internal and external access to your networks? Remember, this is a discussion about what you plan to do, not how. White-boarding possible design scenarios helps work through common and unique challenges; it helps identify gaps. What mechanisms will you use to authenticate subjects (users, computers, software, services, etc.)? Is multi-factor authentication a requirement for some or all network access. How do you plan to identify and react to probable intrusions?

Segmentation

Will you implement a flat network or one segmented to provide extra protection for highly sensitive data or critical systems? Segmentation begins with creating isolated remote access zones and is a common way to prevent compromise of one system from quickly spreading to all information resources. (See Chapter 4.)

System Access Control

At this layer, we begin looking at specific system and platform requirements… the final lines of defense. (See Chapter 11.)

What is your approach to authentication and authorization (e.g., role-based, mandatory, discretionary, rule-based, etc.)?
Is the proposed solution compatible with your identity management solution?
How will you enforce least privilege?
How does your design enforce separation of duties?
Have you considered need-to-know constraints?
How are these controls affected by data center virtualization?

Anti-malware and HIPS

How will you manage anti-malware solutions, including updates? Will all, some, or none of your end-point devices include host-based intrusion prevent solutions (HIPS)? Is it necessary to restrict connection of mobile devices to USB and other ports? Will you allow copying of data to CD/DVD drives?

Device Hardening

The most important defense involves hardening end-point devices. Hardening requires close attention to eliminating all possible vulnerabilities: reducing the attack surface. One of the best places to start is implementation of an aggressive patch management process. How do you plan to test and deploy critical security patches? What is the minimum period between patch release and patch deployment? Who is responsible for patching and who provides oversight?

In addition to patching, individual device attack surfaces require lock-down. One of the easiest methods is application of vendor baseline security recommendations. How will you assess baselines, and integrate those and future changes, into your architecture design and management processes?

BCP and SIEM

No layered defense is perfect. Consequently, two additional considerations crown security architecture: business continuity planning (BCP) and security information and event management (SIEM). BCP, including disaster recovery challenges, must be part of your blueprint. Will you use a co-location or a hot-site? How will you ensure systems come back on line after an incident? Does your BCP include maximum tolerable downtimes for each critical business process and the technology supporting it?

SIEM is a more sophisticated approach to log management. Detecting anomalous behavior in early attack phases helps to mitigate business impact. Combined with a documented and practiced incident response plan, it is one of the most important additions to architecture and operational management. (See Chapter 14.)

Outcomes

Up to this point, management is directly involved. However, turning architecture into concrete solutions is the responsibility of subject matter experts (SME's). Converting abstract concepts into administrative, technical, and physical controls requires training and experience. If relevant SME's were involved in all architecture design activities, a strong bridge already exists between theory and practice.

Outcomes of security architecture design include the supporting components shown in Figure 3-7. In addition to capstone policies, system- or network-specific policies often control unique, targeted constraints. Tools include documentation, checklists, etc. that help maintain consistent compliance with architecture design. Standards and guidelines support policies and provide a decision framework for building or acquiring technology to support business processes. Controls bring abstract outcomes defined in policy and architecture to practical solutions. Finally, processes ensure technical teams consistently and effectively use and update policies, tools, standards, guidelines, and controls.

Figure 3-7: Security Architecture Design Outcomes

Measure and Manage

Implementations of architecture-guided security controls are optimally effective only until something changes. Emerging threats, changes in business processes, and new business technologies cause both architecture design and controls to provide less protection over time. Additionally, new controls do not always work as expected.

Information related to architecture reviews comes from four primary sources, as depicted in Figure 3-8. These same sources also serve as input into initial design activities. Any significant change to any one of them requires a close review of whether the existing enterprise architectures still adequately supports it. If not, changes are necessary that filter through all architectures and supporting elements. Information from all sources is necessary to effectively measure changing risk.

Figure 3-8: Sources of Change

Tools and processes for measuring initial and changing risk provide information necessary for reviewing architecture design and the organization's defensive posture. As shown in Figure 3-9, three best practice approaches to measuring and managing security are audits, vulnerability and penetration tests, and risk assessments.

Audits ensure employees, both business and IT, follow policies and use existing processes. Auditors identify key controls as standards of compliance and test to see if business and IT practices achieve them. For example, a key control might measure to see if processes and employee actions achieve the policy requirement of disabling user accounts within 24 hours of an employee leaving the company. Using a sample population of former employee records from the human resources system, auditors test to see if all related user accounts were disabled in the required time frame.

Figure 3-9: Measure and Manage

Penetration tests look at the network and its controls as an attacker would. Using the five phases of a successful network penetration in Figure 3-10, testers attempt to circumvent or crack human and technical controls and reach an intended target.

Figure 3-10: Phases of Successful Penetration

Chapter 2 explains methods used to discover vulnerabilities and perform risk assessments. Regular system, network and software risk assessments help ensure consistent, and acceptable, levels of risk.

Post-assessment architecture review is critical if your organization intends to maintain consistent levels of risk. As the architecture drifts, so does the overall strength of policies, tools, standards and guidelines, controls, and processes.

Summary

Security enables the business by ensuring all architectures are designed for safe and robust collection, processing, and delivery of information. Documented and up-to-date architectures provide SME's with the tools to design production systems that consistent conform to management's operational and risk expectations. Each of the architectures—information, network, system, software, and security—must seamlessly integrate with and support the others.

Architecture requirements change over time. Change comes from multiple directions. Close attention to shifts in business strategy, regulations, technology, and threats leads to continuous architecture improvements. Audits, testing, and risk assessments help aggregate multi-source changes and provide important information to architects and SME's.

References

Olzak, T. (2010, September). Build an Enterprise Security Architcture-based Framework. Retrieved January 16, 2011, from CBS Interactive/TechRepublic: http://www.techrepublic.com/downloads/build-an-enterprise-architecture-base-framework/2212421

Paul, M. (n.d.). The Ten Best Practices for Secure Software Development. Retrieved January 24, 2012, from International Information Systems Security Certification Consortium: https://www.isc2.org/uploadedFiles/(ISC)2_Public_Content/Certification_Programs/CSSLP/ISC2_WPIV.pdf

Price, S. (2011). Conceptual Principles for the Security Architect. ISSA Journal, 9 (8).

Stoneburner, G., Goguen, A., & Feringa, A. (2002, July). Risk Management Guide for Information Technology Systems, NIST Special Publication 800-30. Retrieved November 9, 2011, from http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf