Docstoc

Information Confidentiality

Document Sample
Information Confidentiality Powered By Docstoc
					Security and Risk Management Strategies
Reference Architecture Technical Position

Information Confidentiality
AUTHOR(S):
Trent Henry
(thenry@burtongroup.com)

Additional Input:
Dan Blum

Statement of Problem
What technical approaches should organizations use to protect the confidentiality of electronic information in the resource layer?

103022

Table Of Contents
Statement of Problem......................................................................................................................................................4 Typical Requirements..................................................................................................................................................... 5 Information Disclosure Risk....................................................................................................................................... 6 Mapping to Enterprise Policy..................................................................................................................................... 7 State of Data................................................................................................................................................................8 Data at Rest............................................................................................................................................................. 8 Data in Motion........................................................................................................................................................ 9 Data in Use..............................................................................................................................................................9 Infrastructure Surety................................................................................................................................................... 9 Surrounding Processes................................................................................................................................................ 9 Alternatives................................................................................................................................................................... 10 Infrastructure Layers................................................................................................................................................. 10 Point of Use...........................................................................................................................................................11 Repositories...........................................................................................................................................................11 Applications.......................................................................................................................................................... 12 Identity and Access Layer.....................................................................................................................................13 Data Self-Protection.............................................................................................................................................. 13 Perimeter Layer.....................................................................................................................................................14 Methods of Protection (in Various Layers)...............................................................................................................14 Filters.................................................................................................................................................................... 15 Transforms............................................................................................................................................................ 15 Separation Mechanisms........................................................................................................................................ 15 Multiple Layers and Methods................................................................................................................................... 15 Future Developments.................................................................................................................................................... 18 Evaluation Criteria........................................................................................................................................................ 19 Statement and Basis for Position.................................................................................................................................. 21 Number of Protections Position................................................................................................................................ 21 Consider keeping information offline................................................................................................................... 21 Use at least two methods to secure confidentiality............................................................................................... 21 Use at least one method to secure confidentiality.................................................................................................22 Consider using at least one method to secure confidentiality............................................................................... 22 Infrastructure Layer Position.................................................................................................................................... 22 Infrastructure Layer for Data in Motion Position................................................................................................. 23 Protect at the point of use on target systems..................................................................................................... 23 Protect the data itself.........................................................................................................................................23 Protect at the perimeter layer............................................................................................................................ 23 Infrastructure Layer for Data at Rest Position...................................................................................................... 23 Protect the data itself.........................................................................................................................................24 Protect at the perimeter layer............................................................................................................................ 24 Protect at the repository layer........................................................................................................................... 24 Protect at the application layer..........................................................................................................................24 Infrastructure Layer for Data in Use Position....................................................................................................... 24 Protect at the application layer..........................................................................................................................25 Point-of-Use Protection Position.............................................................................................................................. 25 Use authentication and authorization methods to create an identity and access layer around the point of use..... 25 Use a content filter to protect information on the system..................................................................................... 25 Use a transform to encrypt the media at point of use............................................................................................25 Use a filter with data labeling to protect information on the system.................................................................... 26 Reevaluate the layer of infrastructure protection.................................................................................................. 26 Data Self-Protection Position....................................................................................................................................26 Reevaluate the layer of infrastructure protection.................................................................................................. 26 2
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Use a transform to enforce rights management over the use of the information.................................................. 27 Use a transform to encrypt the data in transit....................................................................................................... 27 Perimeter-Layer Protection Position......................................................................................................................... 27 Use separation methods to create enclaves that protect information.................................................................... 27 Use perimeter filtering methods to protect information........................................................................................27 Repository-Layer Protection Position....................................................................................................................... 28 Use authentication and authorization methods to create an identity and access layer around the repository.......28 Use separation methods to create content enclaves in the repository................................................................... 28 Use a transform to encrypt, hash, or mask information........................................................................................ 28 Use a filter to protect the information................................................................................................................... 29 Application-Layer Protection Position......................................................................................................................29 Use authentication and authorization methods to create an identity and access layer around the application..... 29 Consider using a transform to hash data when comparing sensitive values......................................................... 29 Use separation methods to isolate the application................................................................................................ 30 Consider using a transform to encrypt information.............................................................................................. 30 Consider using programmatic filters to limit information access......................................................................... 30 Relationship to Other Components............................................................................................................................... 31 Revision History........................................................................................................................................................... 32 Notes............................................................................................................................................................................. 33 Author Bio ....................................................................................................................................................................34

3
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Statement of Problem
What technical approaches should organizations use to protect the confidentiality of electronic information in the resource layer?

4
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Typical Requirements
Protecting information confidentiality1 is a critical security objective for all organizations. In keeping with a systematic and comprehensive security program, organizations must deploy confidentiality controls in addition to security controls for their other major security objectives. They also must choose a protection portfolio that may include preventative, detective, and responsive technologies. (The term “confidentiality” and other ideas related to information security are described in further detail in the Security and Risk Management Strategies overviews “ Concepts and Definitions” and “A Systematic, Comprehensive Approach to Information Security.”) The purpose of this technical position is threefold: • Help organizations create a broad set of architecture policies for confidentiality • For a project that is focused on a particular layer of infrastructure (e.g., a perimeter firewall project), provide information confidentiality requirements specific to that layer • Provide input on when to apply other Reference Architecture technical positions in securing confidential data Organizations should consider the types of sensitive information that exist across the enterprise (including information handled by partners, outsourcers, and customers) and what security objectives are important for each type of data. They should then decide on approaches for achieving those objectives. The purpose of this technical position is to guide high-level decisions about methods of satisfying confidentiality requirements. It points to other Reference Architecture documents that provide details on technologies to deploy. Maintaining confidentiality is but one of several security objectives that must be satisfied. In addition, the enterprise should consider how to achieve integrity, accountability, availability, and use-control of information. Other Burton Group materials focus on how to apply such controls, and in some cases, the resultant solutions overlap with the technologies described in this technical position. The types of information to place in scope should certainly include enterprise-owned valuable content, employee personal information, customer information, and related identity data. However, those broad categories clearly do not comprise an exhaustive list of information and media handled by the typical enterprise. A more complete list should include: • Backup tapes • Databases with credit card numbers (pursuant to payment card industry [PCI] security requirements) • Databases with electronic personal health information (pursuant to Health Insurance Portability and Accountability Act [HIPAA] security requirements) • Customer data in e-mail • Executive communications • Internal Chinese walls (e.g., barriers to communications between financial traders and analysts) • Company confidential information on laptops/portables • Customer confidential information on laptops/portables • Partner confidential information on laptops/portables • User-created company secrets (plans, diagrams, or memos) • Trade secrets • Sensitive financial information (e.g., natural gas inventories) • Student grades • Sales figures And the list goes on. The point is that organizations must assess the risk of exposure of such information—that is, the consequences of information being lost or otherwise exposed to unauthorized personnel—and determine how the data should be protected.

5
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

It is important to note that a great deal of information is stored in non-electronic forms or uses communication channels that aren't arbitrated by computers. Examples include information stored in filing cabinets or communicated through telephone conversations, human-to-human interactions, and so forth. Protections for such information might include physical separation of information (e.g., locked rooms), procedures for information handling, and awareness training for employees. Discussing such situations is beyond the scope of this technical position. This technical position covers what might be described as the “normal period of utility” of electronic information as it is stored, used, and transmitted by computer systems.

Information Disclosure Risk
The risk1 posed by a loss of confidentiality stems from the subsequent consequences. Burton Group categorizes such consequences into three major areas: high, medium, and low. High consequences are very serious—they involve loss of human life or limb (in effect, serious negative human safety issues) or destruction of the organization (either financially or physically). Medium-level consequences incur significant financial harm to an organization. Low consequences pose less serious problems. Some organizations might use alternative risk mappings or a greater number of categories. The main requirement is to understand that various types of information have different value and levels of importance, and therefore, their loss results in different consequences to the organization. This fact has a profound implication—namely, what constitutes medium risk for a smaller organization could be deemed quite low risk to a large organization. A supplier to a large retailer might consider its pricing sheet to be highly sensitive, proprietary data, the loss of which could create significant competitive problems. The retailer might not categorize the pricing sheet in a similar way. As a result, planners must take into consideration variances in risk assessment and decide accordingly how information will be shared and protected wherever it exists.

6
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Figure 1: Subset of Information Lifecycles A related issue is that risk can change at different points of the information lifecycle and generally over time. Figure 1 shows a high-level view. This technical position focuses on the normal period of electronic information utility as data is processed for day-to-day business activities. During this phase of the lifecycle, information can exist in several different states. It might remain at rest in backup tape repositories, it might be regularly transmitted to partners over public networks, it might be carried on personal laptops that are subject to theft and loss, or it might be used in the memory of shared database systems for processing sensitive healthcare claims. These factors must also be considered when evaluating how to protect data. Time also has effects on the sensitivity of information. For example, after information is leaked to the general public, its sensitivity to confidentiality threats drops significantly. Much information has relatively short lifecycles—for example, pricing information might only be sensitive for a few months—and even classified information becomes almost valueless for its secrecy once leaked. Finally, the consequences of loss might be affected by indirect factors. “Erosion of brand”—or reputation risk—is a consequence that might be hard to measure but is a profound factor in the decisions to protect information. Similarly, the costs associated with a regulatory failure may be difficult to fully assess, but they nonetheless play a role in establishing a protection posture, as local, state, and federal governments continually increase the burden of confidentiality.

Mapping to Enterprise Policy
7
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

This technical position uses the concept of low, medium, and high risk to define appropriate confidentiality mechanisms. In order for an organization to successfully employ this scheme, security teams might need to map enterprise security policy and information classification labels into relative risk ratings. Although only an organization itself has sufficient knowledge to do this properly, Burton Group's experience shows the taxonomy in Table 1 to be a close approximation. Commercial information Classification label Public Private/sensitive Confidential Secret/limited distribution Government information Classification label Unclassified Restricted/sensitive but unclassified (SBU) Confidential Secret Top secret Possible risk rating Low Low/medium This label varies from country to country Medium Medium/high High Note Possible risk rating Low Low/medium Often denotes employee or customer data that is medium risk depending on regulatory burden Medium Medium/high Note

Table 1: Mapping Information Classification to Risk Levels

State of Data
Content is the meaningful part of information that gives it utility; data is its representation. Although content is what an organization would typically desire to protect, because content is represented as data in computer systems, the protection of data becomes the key to protection of content utility. Data is often thought of in terms of its state. Like the states of matter (liquid, solid, gas, and plasma), the state of data is typically considered to be at rest, in transit, or in use. This section elaborates on data states.

Data at Rest
Data at rest typically resides in one physical location and remains there. For example, data on a hard disk is usually considered to be at rest. The increased mobility of computers introduces the notion that data on physically mobile hard disks may be thought of as “in motion,” but no additional term to describe this state of data has been widely introduced yet. In many ways, this is analogous to backup tapes that are transported from place to place.

8
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Data in Motion
Data in motion (also called data in transit) is data that is moving from place to place. Data sent electronically through networks is the most representative example. Some organizations classify portable disk drives and tapes as “in motion,” whereas others do not. For the purposes of this technical position, backup tapes contain at-rest data that is protected by the application layer of infrastructure. Laptops and portable media are data in motion—not because the data is constantly flowing electronically, or because the devices can move in physical space, but because the information on such devices is typically derived from other canonical sources and should be protected as though it will be in motion electronically.

Data in Use
Data in use is data that is being processed by algorithms to produce derivative content. For example, bank balances may have to be added up to calculate an aggregate cash position. While data is in use, there are considerable limits to the means by which it can be protected. For example, encryption becomes problematic. There are some exceptions, such as strict comparisons where hashes of data can be stored and compared to hashes of search criteria to find matches.

Infrastructure Surety
Surety1 is the extent to which a system will behave in the way it is supposed to. Different technical protection measures provide varying degrees of strength, predictability, and hardening from attack. To achieve high surety, a system must employ controls that have well-defined properties and that are demonstrably capable of performing as they are intended. High-risk information loss must be matched by high-surety technical measures; otherwise, the risk is not adequately mitigated. In a similar fashion, medium-level risks should be paired with medium-level surety, and low risks should be paired with low surety. An expanded discussion of surety and strength of protection mechanisms is found in the Security and Risk Management Strategies overview “Surety Ratings of Security Mechanisms for Architecture Planning.” An alternative risk management strategy is not to mitigate risk, but rather to transfer, accept, or avoid the risk altogether. In such cases, mismatches of risk and surety might not matter because mitigation isn't the key strategy. However, such alternative approaches are beyond the scope of this technical position. Readers should consult the Security and Risk Management Strategies overview “Risk Management: Concepts and Frameworks.”

Surrounding Processes
In addition to technical measures, information confidentiality necessitates the use of security program elements that are beyond the scope of this technical position. Organizations should be aware, however, that a complete confidentiality strategy must include proper policy development, employee training, and incident-response planning. In addition, confidentiality must coexist with other protection objectives, which might involve certain tradeoffs. For example, an enterprise might choose not to encrypt data in transit in certain places in order to allow detection of corrupted information. This means trading reduced confidentiality protection for greater integrity protection.

9
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Alternatives
The sheer number of technology alternatives for confidentiality architecture can be daunting. The purpose of this technical position is to map the high-level alternatives into categories of protection, which will be subsequently described in greater detail in technology-specific technical positions. For example, an organization might use this technical position to decide that a particular set of at-rest data should be encrypted. The organization can then find details about creating the encryption architecture in the Reference Architecture technical position “Encryption.” The general flow for selecting confidentiality alternatives is shown in Figure 2.

Figure 2: Choosing Confidentiality Alternatives The major alternatives covered here are the layers of infrastructure at which confidentiality should be enforced and the methods of enforcement that should be used. The “Statement and Basis for Position” section of this technical position provides a guide for deciding which confidentiality methods are most applicable in a given situation. However, the decision tree should not be taken to mean that a layered approach isn't acceptable. Quite the contrary, the greater the risk incurred by information leakage, the greater the number layers of control that should be considered in the architecture.

Infrastructure Layers
The layers at which confidentiality can be enforced correspond to major elements of the Reference Architecture root template “Information Security Technology Model.” These include the point of use of data, repositories, applications, the identity and access layer, data/content itself, and the perimeter layer.

10
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Point of Use
Point-of-use protection includes mechanisms that enforce confidentiality on target systems. Such protection is distinct from the repository layer because the information rarely remains at rest. In other words, point-of-use protection tends to be deployed on user systems or secondary hosts, rather than on the servers that host authoritative copies of information. This layer is fundamentally used to protect information that is intended to be in motion. Several types of solutions provide protection at this layer. Host intrusion prevention systems (HIPS), content filters, and point-of-use behavioral control agents all provide a means for detecting and controlling sensitive information. However, these solutions tend to be low surety because a malicious user or attacker can often bypass them. Point-of-use encryption solutions can provide somewhat higher surety. A number of vendors offer local file, volume, and disk encryption. Secure Sockets Layer (SSL) and Internet Protocol security (IPsec) virtual private network (VPN) technologies are two of several approaches that allow end-to-end encryption, in which the pointof-use system plays an active role in helping to enforce confidentiality. To achieve medium or high surety, however, organizations must turn to separation technologies such as strong identity and access control (e.g., smart card login to a system or two-person authentication to unlock secrets), system firewalls from vendors such as Check Point Software Technologies and Symantec, or trusted systems technology. Related Reference Architecture components include: • • • • “Encryption” (technical position) “Protecting Data in Motion” (template) “Protecting Data at Rest” (template) “Discovering Sensitive Resources” (template)

Relevant Security and Risk Management Strategies research documents include: • • • • • • “Cryptographic Systems: An Information Security Foundation” (overview) “Replacement HIPS? Enterprise Considerations for Selecting Host Intrusion Prevention Systems” (report) “Security in the Palm of Your Hand” (report) “Encryption for Mobile Hosts: Protection on the Fly” (report) “Rights Management: Driving Security to the Data” (overview) “Content Monitoring with Network Data Loss Protection” (report)

Repositories
Repositories such as application servers and database systems are classic data-at-rest scenarios. However, such systems often place data in motion as well, and therefore need layered protection to accommodate multiple data states. Protection at the repository layer is particularly fitting when multiple sets of sensitive information—often processed by a variety of different applications—can receive confidentiality enforcement from a centralized, shared resource. Certain types of repositories are often overlooked by enterprise planners, despite being important collections of confidential information. A case in point is the enterprise identity directory, which can contain user attributes, policies, and other kinds of information that are sensitive and may fall under regulatory scrutiny. In addition to shared file systems, databases, application servers, and other “obvious” repositories, architects are cautioned to consider typical infrastructure components like access control systems, authentication servers, and directories that may contain or otherwise handle confidential data.

11
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Repository protections include database encryption solutions—both from third parties or database management system vendors—or common rule-based filters and encryption frameworks provided by Java or .NET application servers. Network-based filters monitor transaction connections to repositories. These tools are often termed database activity monitoring (DAM) solutions or database auditing and monitoring solutions. Identity and access control to repositories are commonly deployed; they are implemented by a variety of authentication, authorization, and provisioning solutions covered by the Identity and Privacy Strategies service. For certain types of repositories, such as data warehouses, de-identifying sensitive data via redaction, masking, or other techniques may be appropriate. Related Reference Architecture components include: • • • • “Encryption” (technical position) “Protecting Data in Motion” (template) “Protecting Data at Rest” (template) “Discovering Sensitive Resources” (template)

Relevant research documents include: • “Cryptographic Systems: An Information Security Foundation” (Security and Risk Management Strategies overview) • “Database Encryption: The Hot Topic in Structured Information Protection” (Security and Risk Management Strategies report) • “Meeting the Content Control Challenge: Techniques, Tools, and Architectures” (Security and Risk Management Strategies report) • “Enhancing Compliance and Audit with Database Activity Monitoring” (Security and Risk Management Strategies report) • “Defusing the Personal Information Time Bomb: Data De-Identification” (Identity and Privacy Strategies overview)

Applications
The application layer provides programmatic control over content by restricting the way it is viewed, transmitted, or stored. Often, the application layer can provide protection not easily accommodated by other layers—such as segregation between administrative users and normal users, or controls over data in use. However, protection applied at the application layer must be re-created for each and every application that handles sensitive information. When possible, organizations should consider adding protections at the repository layer, which can protect the data of multiple applications with similar requirements. Although it's not wholly intuitive, backup tapes are often protected at the application layer. Encryption via the tape drive is feasible and growing in acceptance, but backups tend to be protected through encryption provided within the backup software itself or, in the case of virtual tape, within the underlying storage fabric. In many cases, this is a good choice; using a third-party encryption solution could be problematic because recoverability assumptions—such as those of the business continuity plan—tend to rely on features of the backup/recovery tool to accommodate information recovery. Note that for online backup methods, such as network attached storage used for data archive, the system operates as a repository and should be protected as such. However, much of the information in such an archive does not exist only as “information at rest”; the information tends to be in motion at some point during its lifecycle and therefore might need data-in-motion protections as well. Application protection tends to hinge on choices made by developers, such as which cryptographic tools to use from which vendors, how to compare values of sensitive information, when to strip out information presented to the user, and so forth. Related Reference Architecture components include:

12
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

• “Encryption” (technical position) • “Application Security Frameworks” (Application Platform Strategies technical position) Relevant Security and Risk Management Strategies research documents include: • “SOA Security: Developing a Technical Control Strategy” (overview) • “Building Secure Applications: How Secure Do You Want to Be Today?” (report) • “Web Application Firewalls: What's in a Name?” (report) Relevant research documents include: • “Web Services Security: A Plethora of Products” (Application Platform Strategies report) • “Data Modeling: A Necessary and Rewarding Aspect of Data Management” (Data Management Strategies overview) • “Access Control Frameworks: Protecting Applications Consistently” (Application Platform Strategies overview) • “Developing a Web Services Security Strategy” (Application Platform Strategies Methodologies and Best Practices [MBP] document)

Identity and Access Layer
Identity and access control is described as a layer in Burton Group's Reference Architecture because it is another boundary or protection mechanism through which attackers and authorized users must pass. In practice, however, identity and access controls tend to be deployed within a discrete infrastructure layer. For example, at the point of use on target systems, the operating system might enforce access control for all users. That is, the identity and access control “layer” is really part of the point-of-use layer on the system. Similarly, authentication and authorization to a general-ledger financial package are typically implemented in the application or repository infrastructure layers. Identity and access controls are part of the comprehensive coverage of Burton Group's Identity and Privacy Strategies service, which presents in-depth research at http://www.burtongroup.com/Client/Research/Document.aspx?cid=16. In addition, the Identity and Privacy Strategies Reference Architecture includes a number of important documents in its templates and technical positions.

Data Self-Protection
The protection of content or data itself is typically motivated by a need to defend data in motion that can't otherwise be effectively controlled. For some methods of data self-protection, an added benefit is persistent protection of the information—that is, whether the state is at rest or in motion, the information's confidentiality remains enforced. Encryption solutions that enforce the self-protection of data are similar to those found at the point of use on target systems. They include disk, file, and volume encryption solutions, and various forms of end-to-end encryption. The main difference is that the point-of-use layer always involves a user workstation or other type of client system, whereas data self-protection might involve encryption among other components in the infrastructure (e.g., network gateways). In addition, data self-protection includes enterprise rights management (ERM) technologies that join key management, encryption, data, and policies together in a data structure. A related Reference Architecture component: • “Encryption” (technical position) Relevant Security and Risk Management Strategies research documents include:

13
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

• • • •

“Rights Management: Driving Security to the Data” (overview) “Cryptographic Systems: An Information Security Foundation” (overview) “Windows Vista Balances Security and Convenience: Your Mileage Will Vary” (overview) “Windows Server 2008: Advancing Security in Multiple Roles” (overview)

Perimeter Layer
Enforcement at the perimeter layer often gives the broadest enforcement over confidentiality when the information remains within the enterprise boundary. Such breadth can potentially result in a tradeoff of depth. That is, perimeter confidentiality controls typically have less context to make enforcement decisions than do applications, repositories, and content itself. As a result, the perimeter layer is often a good choice for the validation of other confidentiality controls, to ensure that other layers of protection are operating correctly. Solutions available to protect confidentiality at the perimeter layer are numerous. At lower levels of surety are filtering solutions that monitor network traffic for confidentiality breaches. These include multiprotocol network content filters (so-called data loss protection [DLP] tools) and protocol-specific filters for e-mail, web, instant messaging, and other traffic. Certain network intrusion detection and response systems perform similar filtering functions. Moving up in surety, encryption solutions between perimeter network devices provide transport security for a particular “network hop.” Perimeter-layer encryption tends to imply that information will be transmitted in the clear at some point in its travel because this is not end-to-end encryption. Finally, network firewalls provide higher levels of surety by creating separation in networks. Related Reference Architecture components include: • “Encryption” (technical position) • Reference Architecture templates “Protecting Data in Motion,” “Protecting Data at Rest,” and “Discovering Sensitive Resources” • “Zones” (technical position) • “Network Perimeters” (technical position) • “Endpoint Admission” (technical position) • “Network Intrusion Detection and Response” (technical position) • “Detection Services” templates, including “Network Intrusion Detection and Response: Demilitarized Security Zone (DMZ),” “Network Intrusion Detection and Response: Trusted Security Zone,” and “Network Intrusion Detection and Response: Restricted Security Zone” Relevant Security and Risk Management Strategies research documents include: • • • • • • • “Content Monitoring with Network Data Loss Protection” (report) “Document Management Security: Not Receiving the Scrutiny It Should” (report) “Instant Messaging Security: It's Not Just Idle Chatter” (report) “Rights Management: Driving Security to the Data” (overview) “Database Encryption: The Hot Topic in Structured Information Protection” (report) “Enterprise Firewalls, Unified Threat Management Devices, and Perimeter Architecture” (report) “Network Intrusion Detection and Response: More Than Just Speed Bumps on the Network” (report)

Methods of Protection (in Various Layers)
Depending on the risk requirements of information, and therefore the consequent surety needed to provide adequate enforcement, each layer of infrastructure offers several options for the method of protection that can be employed. In increasing order of surety, these are filters, transforms, and separation mechanisms.

14
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Filters
Filters that make choices based on signatures (e.g., fingerprints) or information fragments (e.g., keywords/regular expressions) tend to be low-surety methods. They have limits in their detection capabilities, can be thwarted in high-performance environments, need ongoing updates over time, and can often be bypassed by reasonably skilled attackers. Examples of solutions in this realm include network content filters, deep packet inspection features of certain firewalls, e-mail message hygiene solutions, and web acceptable-use systems. A variation of filters can make use of data labeling to improve the accuracy of detection and the overall surety of the solution. Such capabilities are often associated with mandatory access controls enforced in trusted operating system technologies.

Transforms
Transforms involve some type of algorithmic change of data. Moving up the surety scale, transforms of information often provide medium-surety protection of confidentiality, provided that the quality of implementation is high. The primary transform used to enforce secrecy is encryption, although hashing is a viable option in some applications. Watermarking, signatures, or other forms of content marking can be coupled with filters, but the strength of protection is dependent on the surety of the filter, not the surety of the transform. Data de-identification techniques also transform information. Specifically, they redact, substitute, or otherwise mask information so that the original, sensitive information is not viewable. This is a popular technique in data warehouses or business analytics repositories, where certain types of data (e.g., detailed customer information) shouldn't reside. A variation of the encryption transform is rights management, which not only seals information from unauthorized view and use, but also couples policies and identity awareness to the protected data. Transforms can potentially achieve high-surety data protection, but some of the alternative technologies are beyond the scope of this technical position. One option is the use of one-time-pad cryptography, which is mathematically provably secure. Used by governments and militaries, such a solution is not practical for the typical commercial enterprise. A second option is quantum cryptography, which uses the changing quantum states of photons to make eavesdropping physically impossible. Although market solutions for quantum cryptography are beginning to emerge, implementations are extremely difficult to validate (and therefore their surety is unknown), and use of the technology is likely to be limited to governments.

Separation Mechanisms
Generally, the highest level of surety can be achieved through separation methods. By creating enclaves of similar information—strictly prevented from unauthorized interactions of any sort in a highly predictable, defined environment—separation methods are most likely to preserve information confidentiality. The most obvious example of such separation is a physical control, such as a bank vault door, but a technique like this is of limited value when dealing with electronic information. In the virtual world, separation methods include trusted operating system controls, hardware-based cryptographic controls, zoning and strong network perimeter enforcement, and certain forms of identity and access control to compartments.

Multiple Layers and Methods
Table 2 summarizes the various infrastructure layers and methods by which confidentiality can be protected, as discussed in the previous sections. Method of protection ([H]igh, [M]edium, or [L]ow surety)

15
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Layer of Filter infrastructure Point of use on [L] Host intrusion detection target hosts [L] System content filters [L] Point-of-use control agents Data selfprotection

Transform [L/M] Host encryption [L/M] Hashing or masking [L/M] End-to-end encryption (termination at the endpoint) [L/M] End-to-end encryption (termination at the endpoint) [L/M] Rights management

Separation [L/M] Identity and access control [M] System firewalls [M/H] Trusted systems technology

Application

[L/M] Programmatic filters and application filtering rules

[L/M] Application-specific encryption [L] Hashing [L/M] Database or other repository-level encryption [L/M] Hashing or masking [L/M] Transport encryption (termination in network infrastructure)

[L/M] Identity and access control [H] Physical and logical application separation [L/M] Identity and access control [H] Physical and logical repository separation [M] Network firewalls

Repository

[L/M] Programmatic filters and repository filtering rules

Perimeter

[L] Network intrusion detection and response systems [L] Application proxies or network content filters [L/M] Network firewall deep inspection

Table 2: Summary of Methods and Layers of Infrastructure for Confidentiality Protection Although Table 2 lists the rough surety levels of particular methods of protection, overall surety often depends on multiple confidentiality techniques. Particularly for medium- and high-risk information, organizations will employ multiple means to protect the data, either at various levels of infrastructure or by using multiple methods within a given layer of infrastructure. In addition, organizations need to consider not only the means by which to directly control confidentiality, but also the means by which to validate that the control is effective. For example, if a transform in a repository presumably encrypts all information as it rests and potentially flows out of the repository (for primary enforcement), an architect might choose to deploy a network content filter in the zone to ensure that no plaintext sensitive information is leaking out (for validation). There may be cases in which a higher overall level of surety can be achieved by combining many lower-surety techniques, but this technical position does not specifically address such issues. It's difficult to say, for example, what combination of several low-surety mechanisms at various infrastructure points might provide overall medium-surety protection. Does a network filter plus programmatic rule plus point-of-use agent provide betterthan-low surety? It's possible, though not likely, and it's definitely not certain. In short, this needs to be evaluated on a case-by-case basis. However, if disclosure of a given information set is truly of medium or high risk to an organization, an architect must carefully consider why a medium- or high-surety method is not being used. The best bet is minimally to employ a control of matching surety level and augment it with additional lower-surety controls for validation or additional protection.

16
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

In the converse case, some architects may find it desirable to use high-surety mechanisms to protect lower-risk information. Clearly, this provides adequate protection; the only issue is cost. Driving to higher assurance generally increases expense, and the architect needs to consider whether the consequence of information disclosure warrants what might be an extra expense to deploy higher-surety controls. On the other hand, if a stronger control is already in place to protect other data, it may be perfectly feasible and acceptable to use it for lower-risk data as well. To successfully protect confidentiality, most organizations will use a defense-in-depth strategy of some sort. But the architecture must take into consideration the potential erosion of effectiveness of some combinations. Some combinations are weak. For example, identity and access control at the point of use combined with identity and access control at the application layer might “feel” like multiple protections. But if a single-sign-on solution is deployed in an organization—in which a single authentication credential is required for access to both layers—then the goal of layered defense might not be realized. Similarly, when a transform is used to encrypt information at one layer, filters can be hamstrung in their ability to monitor content.

17
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Future Developments
Although the surety of many security products remains static, the surety of select protection mechanisms is increasing with time. The Trusted Computing Group's Trusted Platform Module (TPM) offers good possibilities for automated and reliable roots of trust, secret storage, and encryption of data without added hardware. TPMs could improve the surety of filters, transforms, and separation methods in many different infrastructure layers. Cloud computing—in which applications, platforms, or infrastructure are managed by third parties in remote locations—is a continuing trend that has profound implications for confidentiality. Although software as a service (SaaS) raised awareness of the dangers of sensitive information living beyond the traditional enterprise data center, it also broadened acceptance of the practice. Cloud computing amplifies the need for administrative and contractual controls to ensure that confidentiality is adequately protected. The Security and Risk Management Strategies MBP document “Considerations for Risk Management When Choosing Software as a Service” describes such controls in detail. Information destruction is an important part of the information lifecycle, but it's often neglected in information confidentiality architecture. An intensifying regulatory environment has caused organizations to pay closer attention to destruction. And with the increased use of encryption to protect data during its normal period of utility, the possibility of using encryption for destruction emerges. Specifically, disposing of encryption keys can effectively destroy at-rest data that is encrypted with strong ciphers and whose keys have been properly managed. Without the keys, encrypted data is rendered unusable. Although some enterprises entertain the notion of using this data-disposal technique, caution is warranted to ensure that spare copies of keys or weak encryption implementation don't undermine destruction. Other future technological developments are considered in more detail in each of the Reference Architecture pieces described in the “Relationship to Other Components” section of this technical position.

18
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Evaluation Criteria
In addition to the Reference Architecture principles, the following evaluation criteria should guide an enterprise's confidentiality architecture decisions through the position statements found in the next section: What is the sensitivity of information stored and used across the organization? Understanding the nature of enterprise information sensitivity is critical for selecting the confidentiality architecture. The guiding requirements come from contracts with customers and suppliers; regulations at local, state, and federal levels; common practices of peer organizations that might be deemed “prudent protection”; and self-determined risk management policies. What is the consequence of information loss? Protection technologies cost money, and the organization must understand the potential stakes of unauthorized information disclosure. Although strict quantitative analysis may not be feasible—that is, a specific dollar amount may not be determined—the notion of low-, medium-, or high-level risk is important in determining whether low-, medium-, or high-surety techniques should be deployed for various sets of data. Furthermore, consequences may be sufficiently high to warrant alternative risk management approaches, such as transferring or avoiding the risk of breach rather than trying to mitigate information loss technologically. What is the level of trust of networks and intermediate systems? At some point during their lifecycle, many instances of information will be in motion across enterprise networks and beyond. In order to assess appropriate technical protections, the organization must understand the level of trust placed in systems that handle the data along its various paths. These include e-mail servers, partner systems, routers, firewalls, or other gateways that might inspect content. Information touched by moretrusted infrastructure requires fewer confidentiality countermeasures than that handled by less-trusted infrastructure. Can information be relocated? Sets of information sometimes reside in repositories, user systems, or other locations for rather arbitrary reasons, perhaps because of historical chance. For example, critical customer information may rest in a reporting server located in the demilitarized zone (DMZ) of a corporate network because of a project from years prior that is now defunct—or for which firewall rules modification is now a viable alternative. In such a case, it might be entirely appropriate to move the data to an interior zone in order to vastly improve its protection and reduce the likelihood of external attack. Another relatively common example is log storage, which may need three to six months of historical data for analysis or trending, but often doesn't need to stay online (and exposed to leakage) indefinitely. As part of the data management lifecycle, information should be moved offline when feasible. How is sensitive information discovered? Successfully crafting a confidentiality architecture implies knowledge of what sensitive information and repositories actually exist. Such discovery can be a nontrivial problem, because it needs to include all business processes, all pieces of infrastructure, and all stages of the information lifecycle. It's not enough to assume that existing data sources are the only ones that need protection, because new ones are being created all the time. Are physical controls deployed? Physical access to electronic information systems can easily bypass all technological controls. Therefore, physical controls cannot serve merely as high-surety separation mechanisms, but must also serve as foundational parts of the information protection program. In addition, many forms of sensitive information exist in non-electronic forms and must be protected physically. How will information be destroyed?

19
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Information must be destroyed with a level of surety that matches the risk and surety of protection at other stages of the lifecycle. Through “dumpster diving,” recovering data from disposed magnetic media, and other related techniques, attackers have often reaped secret information that was otherwise reasonably well protected. For information that is in motion, what are the boundaries? When a set of sensitive information is authorized to be transmitted electronically, the organization needs to establish the proper limits of travel. Is it restricted to transmission within a particular zone or perimeter, across multiple zones or perimeters, or perhaps even from application to application in a specific repository? How is the information protected in other organizations that handle it? Much data gets handled by people and processes outside of the immediate enterprise. Technological countermeasures alone typically will not suffice. Relationships, policies, and procedures must be in place to ensure ongoing confidentiality.

20
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Statement and Basis for Position
To develop an architecture for information confidentiality, position statements are required in the following areas: • Number of Protections How many protection mechanisms should be used to enforce confidentiality? • Infrastructure Layer At what layer of infrastructure should confidentiality be protected? • Point-of-Use Protection What confidentiality methods should be used to protect at the point of use? • Data Self-Protection What confidentiality methods should be used to protect data itself? • Perimeter-Layer Protection What confidentiality methods should be used to protect at the perimeter layer? • Repository-Layer Protection What confidentiality methods should be used to protect at the repository layer? • Application-Layer Protection What confidentiality methods should be used to protect at the application layer?

Number of Protections Position
How many protection mechanisms should be used to enforce confidentiality? Note that this position should be evaluated for each set of sensitive information stored and used by the organization. The logic for choosing the number of confidentiality protections is as follows: IF loss of the sensitive information would result in high consequences to the organization THEN IF the information does not need to be routinely accessible electronically THEN consider keeping information offline OTHERWISE use at least two methods to secure confidentiality—one to primarily protect information from disclosure and one to validate the effectiveness of protection OTHERWISE if loss of the sensitive information would result in medium consequences to the organization THEN use at least one method to secure confidentiality OTHERWISE consider using at least one method to secure confidentiality Alternative Number of Protections position statements (important: for each set of sensitive information, choose only one):

Consider keeping information offline.
With organizational failure or human safety at stake, some information should not be accessible through electronic means. Physical controls should be used to protect the data. Or…

Use at least two methods to secure confidentiality.

21
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Some information still needs to be kept online, although high consequences mean that information loss will have dramatic effects on the organization. As a result, a defense-in-depth strategy should be employed so that information confidentiality is not only enforced but also verified to be working correctly. Therefore, at least two different methods of confidentiality control should be used. They may both reside in the same infrastructure layer, or, quite probably, may exist at different points in the enterprise architecture. For example, a particularly sensitive repository might employ access controls to create a content enclave, transforms to provide data-at-rest encryption, and a network filter to monitor and potentially block outbound communications for plaintext leakage or inappropriate use of encryption. In all cases, at least one enforcement mechanism should be a high-surety technology, in order to accommodate the high-risk environment. In addition, the use of multiple functions must take into consideration separation and redundancy (e.g., they shouldn't be reliant on one another for enforcement to work; independence is required). A separation of duties is required to prevent any single individual from causing a failure or bypass of the technical protection mechanism(s). Or…

Use at least one method to secure confidentiality.
Medium-consequence information loss can result in significant impact to the organization. Protection is not optional in such cases. At least one medium-surety confidentiality approach must be employed to prevent unauthorized information disclosure. Furthermore, separation of duties should be considered at the process level to ensure that multiple approvals are required in order to violate confidentiality. Or…

Consider using at least one method to secure confidentiality.
Some types of public information have no confidentiality requirements at all. A case in point is content on a publicly available marketing web server. However, confidentiality is an important security objective, and it is important to carefully evaluate whether a given set of data is truly and wholly “public.” Furthermore, although particular information may be permissibly disclosed, some associated content may not be. In the case of a web server, for example, administrative authentication credentials are not public, so a confidentiality method must be employed for that data, even if the hypertext requires no such protection.

Infrastructure Layer Position
At what layer of infrastructure should confidentiality be protected? At different times in its lifecycle, data might be used differently. At one point it may remain at rest, whereas at other points it may be in motion. Alternatively, such information may reside on or flow to different systems with varying protection characteristics (e.g., some that can and some that cannot use a local software agent). Therefore, three position statements are required: • Infrastructure Layer for Data in Motion At what layer of infrastructure should confidentiality be protected for data in motion? • Infrastructure Layer for Data at Rest At what layer of infrastructure should confidentiality be protected for data at rest? • Infrastructure Layer for Data in Use At what layer of infrastructure should confidentiality be protected for data in use?

22
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Infrastructure Layer for Data in Motion Position
At what layer of infrastructure should confidentiality be protected for data in motion? For each set of sensitive information, the logic for choosing a position to decide which infrastructure layer should protect data in motion (or data that will be in motion) is as follows: IF information traverses to endpoints via trusted networks and servers AND deployment of software agents is acceptable and feasible THEN protect at the point of use on target systems OTHERWISE IF sensitive information need not be inspected to satisfy another security objective THEN protect the data itself OTHERWISE protect at the perimeter layer Alternative Infrastructure Layer for Data in Motion position statements (important: for each set of sensitive information, choose only one):

Protect at the point of use on target systems.
Information that is handled and processed by endpoint systems cannot be simply constrained by controls around a particular information repository. Instead, the information must be protected from improper disclosure at the endpoint. In order to accommodate this, software agents must enforce confidentiality policies at each point of use of the information (see the “Point-of-Use Protection” position). Or…

Protect the data itself.
If information in motion needs to be protected everywhere it flows, then the data itself must enforce confidentiality controls. For such protection to be effective on target hosts, however, software agents must be deployed to interpret policy and handle rendering of the content. Alternatively, data can be self-protected through a transformation of the communication stream the information flows over (see the “Data Self-Protection” position). Or…

Protect at the perimeter layer.
Data in motion across networks often must be prevented from flowing to improper systems, repositories, or security zones. Perimeter protections are deployed in order to augment or stand in place of host-layer and application-layer confidentiality controls. Perimeter protections might be particularly important to prevent information from flowing to networks or servers of lesser trust (see the “Perimeter-Layer Protection” position).

Infrastructure Layer for Data at Rest Position
At what layer of infrastructure should confidentiality be protected for data at rest? For each set of sensitive information, the logic for choosing a position to decide which infrastructure layer should protect data at rest (or data that will be at rest) is as follows: IF data on an endpoint is subject to attack by unauthorized users THEN protect the data itself 23
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

OTHERWISE IF data needs to be verified as remaining at rest and not flowing over the network THEN protect at the perimeter layer OTHERWISE IF multiple sets of sensitive information can be protected by a common approach OR information disclosure risk does not warrant application-specific coverage THEN protect at the repository layer OTHERWISE protect at the application layer Alternative Infrastructure Layer for Data at Rest position statements (important: for each set of sensitive information, choose only one):

Protect the data itself.
Information at rest often resides on user systems that are highly portable and subject to attack. Such information may be at rest at a given point in time, but it's likely to become “in motion” because of theft or misuse. Therefore, the data itself must enforce confidentiality controls. For such protection to be effective on target hosts, however, software agents must be deployed to interpret policy and handle rendering of the content (see the “Data SelfProtection” position). Or…

Protect at the perimeter layer.
Repositories and applications typically provide the primary means for protecting data at rest, but to prevent improper network communications, perimeter-layer validation is often desirable (see the “Perimeter-Layer Protection” position). Or…

Protect at the repository layer.
When possible, repositories such as databases, identity stores, and application servers should be used to their fullest to protect secret data. Often, such systems have common frameworks to protect the confidentiality of information contained in them. These mechanisms should be used across all the applications or data stored that make shared use of the repository. This enhances confidentiality across a larger number of data sets and minimizes the potential for configuration errors or other administrative mistakes (see the “Repository-Layer Protection” position). Or…

Protect at the application layer.
Information-at-rest protection for applications may be handled by a common framework, like an application server, or by the application itself. In addition, particularly sensitive information might require greater amount of confidentiality than can be accommodated by other infrastructure layers. For example, information may need to be protected from system managers or repository administrators—who might otherwise have access to the data—and therefore would need to be protected in the application itself (see the “Application-Layer Protection” position).

Infrastructure Layer for Data in Use Position
At what layer of infrastructure should confidentiality be protected for data in use? 24
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

There is only one position for data in use:

Protect at the application layer.
Data in use is handled by applications to compare, read/write, transmit, and otherwise process information. In this state, information must be protected at the application layer (see the “Application-Layer Protection” position).

Point-of-Use Protection Position
What confidentiality methods should be used to protect at the point of use? The first position for protecting information at the point of use is:

Use authentication and authorization methods to create an identity and access layer around the point of use.
For all endpoints that consume or process confidential information, identity-based controls should be employed to create a content enclave—that is, access to the information must be restricted to authorized subjects. (Note: The following positions are recommended in addition to the position listed above.) The logic for choosing additional methods for protecting information at the point of use is as follows: IF the consequences of a confidentiality breach are low THEN use a content filter to protect information on the system OTHERWISE IF the consequences of a confidentiality breach are medium THEN IF loss or theft of media is a risk THEN use a transform to encrypt the media at point of use OTHERWISE use a filter with data labeling to protect information on the system OTHERWISE reevaluate the layer of infrastructure protection Alternative Point-of-Use Protection position statements (important: for each set of sensitive information, choose only one):

Use a content filter to protect information on the system.
Typical content filters are relatively low-surety mechanisms for watching the behaviors of information use on point-of-use target systems. They can help to prevent accidental leakage of information and defeat unsophisticated attacks. However, they can be bypassed by skilled, malicious users, and therefore shouldn't be relied on to thwart significant consequences. Or…

Use a transform to encrypt the media at point of use.

25
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Mobile endpoints have a notorious habit of getting lost or stolen. When sensitive customer records or intellectual property are stored at these points of use, they may fall into the wrong hands. In these cases, full-disk encryption helps to protect against unauthorized disclosure of the data. Furthermore, for customer data, encryption may provide an exception to breach-disclosure requirements in certain jurisdictions. File- and folder-encryption solutions may also be acceptable choices, but it's often a good practice to prevent users from choosing what data should or shouldn't be encrypted. That is, the solution should enforce mandatory encryption policy that can't be bypassed. Or…

Use a filter with data labeling to protect information on the system.
Adding labeled data protection can substantially improve the efficacy of a filter. Particularly when implemented in a trusted system, information leakage on the endpoint can be largely constrained. Or…

Reevaluate the layer of infrastructure protection.
Generally, the point-of-use systems deployed by most organizations do not have adequate controls to prevent loss of high-consequence data. As a result, this is not the appropriate infrastructure layer to protect such information.

Data Self-Protection Position
What confidentiality methods should be used for data to protect itself? The logic for choosing a method to enable data to protect itself is as follows: IF the consequences of a confidentiality breach are high THEN reevaluate the layer of infrastructure protection OTHERWISE IF information needs to be protected persistently (wherever it goes) THEN use a transform to enforce rights management over the use of the information OTHERWISE IF there is no mandatory requirement to maintain information in cleartext form THEN use a transform to encrypt the data in transit OTHERWISE reevaluate the layer of infrastructure protection Alternative Data Self-Protection position statements (important: for each set of sensitive information, choose only one):

Reevaluate the layer of infrastructure protection.
Self-protection of data essentially requires a transform. In select cases, transforms can be used for separation that might provide high-surety protection. But most often, a transform is reduced to medium or lower surety because of limits in its storage of secrets, quality of implementations, ease of defeating untrusted endpoints, and so forth. As a result, when the consequences of data loss are high, information should be protected at another layer or must be combined with other layers of protection. Or…

26
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Use a transform to enforce rights management over the use of the information.
To persistently protect data in motion, whether it flows to authorized or unauthorized users or systems, a transform with rights management is required. Other encryption transforms can protect data, but they often allow authorized recipients to violate confidentiality (either accidentally or unintentionally). Unfortunately, current rights management systems tend to be low-surety controls. Or…

Use a transform to encrypt the data in transit.
Encryption of valuable or sensitive data is desirable for information in transit unless there is a requirement that it not be encrypted, and even in those cases, using decryption-only capabilities (i.e., the authorized parties may decrypt but are unable to forge encrypted messages) to fulfill the requirement is often the most effective approach. This is a “default encrypt” position. As an example, the Chinese and French governments do not allow unfettered encryption; however, there may be situations in which they can be given keys for decryption that allow them to read the signals without being able to falsify them. Similarly, court-ordered decryption of encrypted data in transit may be applied anywhere in the world.

Perimeter-Layer Protection Position
What confidentiality methods should be used to protect at the perimeter layer? (Note that the perimeter layer can be used to implement certain information transforms, such as the encryption of data via VPN connections. However, the “Perimeter-Layer Protection” position is intended to cover methods other than transforms, which are described in the “Data Self-Protection” position.) The logic for choosing a method to protect information at the perimeter layer is as follows: IF loss of the sensitive information would result in medium or high consequences to the organization THEN use separation methods to create enclaves that protect information OTHERWISE use perimeter filtering methods to protect information Alternative Perimeter-Layer Protection position statements (important: for each set of sensitive information, choose only one):

Use separation methods to create enclaves that protect information.
Separation technologies are preventative controls that use definitive policies and mechanisms to enforce zones in the enterprise network. Physical controls themselves are a form of separation, in which barriers forcibly prevent interactions that aren't allowed. Although physical controls are outside the scope of this technical position, they serve as an illustration of what strong firewalls and other network (and system-level) controls accomplish electronically, and they are generally necessary to achieve medium or high surety levels. Although zoning is explicitly defined in terms of access policy rather than what constitutes allowed and disallowed content, zones and subzones are powerful means to isolate information and create enclaves of content that have similar protection requirements. Or…

Use perimeter filtering methods to protect information.
27
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Because they serve as detection-and-response tools, filtering mechanisms are more appropriate to lower-surety information protection. Filters often lack deterministic policies, can suffer from flaws in detection (both false positives and false negatives), and can generally be defeated by motivated adversaries. However, the use of filtering mechanisms in the perimeter layer is particularly well suited to validation of primary protection methods deployed at other layers. Filters often can be used as secondary controls (like validation) for higher-surety approaches if their implementation does not otherwise weaken protection.

Repository-Layer Protection Position
What confidentiality methods should be used to protect at the repository layer? The first position for protecting information at the repository layer is:

Use authentication and authorization methods to create an identity and access layer around the repository.
For all repositories that consume or process confidential information, identity-based controls should be employed to create a content enclave—that is, access to the information must be restricted to authorized subjects. Details about identity-based methods are found in the “Identity and Access Layer” section of this technical position. (Note: The following positions are recommended in addition to the position listed above.) The logic for choosing additional methods for protecting information at the repository layer is as follows: IF loss of information would result in high consequences to the organization THEN use separation methods to create content enclaves in the repository OTHERWISE IF loss of information would result in medium consequences to the organization AND the repository consists of secondary storage or other non-authoritative copies of data THEN use a transform to encrypt, hash, or mask information OTHERWISE use a filter to protect the information Alternative Repository-Layer Protection position statements (important: for each set of sensitive information, choose only one):

Use separation methods to create content enclaves in the repository.
Separation and isolation are the methods to protect high-risk information from disclosure. Akin to physical protections (which are outside of the scope of this technical position), separation prevents interactions in the repository that are not allowed, including unauthorized flow of information. If implemented with a very high degree of surety—usually with hardware mechanisms and on a strong underlying operating system—then cryptographic transforms can be used to create such enclaves. However, cryptographic transforms are much more likely to be employed as a medium-surety approach. The likely choices for separation in a repository are hardware-based isolation mechanisms and trusted systems technologies that enforce mandatory subject-object access control through a security kernel. Or…

Use a transform to encrypt, hash, or mask information.

28
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

A transform in the repository is the classic data-at-rest use case. Symmetric encryption can be used to protect information from disclosure while resident in the repository. Hashing can be used to protect information that only needs to be compared to other values, rather than manipulated directly. Masking allows for arbitrary data values to replace otherwise sensitive information. A popular example is replacing a credit card primary account number with a random numeric string or simple “XXXXs” if the application allows it. Or…

Use a filter to protect the information.
If information needs to be prevented from unauthorized egress from the repository or prevented from flowing to other compartments within the repository, then filters are the low-surety choice. They are not as robust as other alternatives because they can often be subverted by attackers—notably, repository managers. In addition, a filter must be carefully crafted not to have adverse effects on normal data operations. For example, a filter (e.g., a relational database view) could mistakenly block a normal repository report, which would likely result in a decision to terminate all filtering in favor of smooth operation.

Application-Layer Protection Position
What confidentiality methods should be used to protect at the application layer? The first position for protecting information at the application layer is:

Use authentication and authorization methods to create an identity and access layer around the application.
For all applications that consume or process confidential information, identity-based controls should be employed to create a content enclave. That is, access to the information must be restricted to authorized subjects. Details about identity-based methods are found in the “Identity and Access Layer” section of this technical position. (Note: The following positions are recommended in addition to the position listed above.) The logic for choosing additional methods for protecting information at the application layer is as follows: IF sensitive data is in use by the application (rather than at rest) THEN consider using a transform to hash data when comparing sensitive values OTHERWISE IF loss of information would result in high consequences to the organization THEN use separation methods to isolate the application OTHERWISE IF the application stores confidential data persistently AND the system houses secondary storage or other non-authoritative copies of data THEN consider using a transform to encrypt information OTHERWISE consider using programmatic filters to limit information access Alternative Application-Layer Protection position statements (important: for each set of sensitive information, choose only one):

Consider using a transform to hash data when comparing sensitive values.
29
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Generally, transforms aren't an option when information is in use (e.g., when it is being processed in an application). The one exception is hashing. Any time an application compares values in a confidential data set, the use of a transform to hash information should be considered in order to limit the likelihood of unauthorized disclosure. In many cases, however, the total combination of values that can be hashed may be subject to bruteforce attacks, making such hashes a low-surety mechanism. For example, in the case of health information, care facilities use fewer than 100,000 different procedure codes. It is not difficult for an attacker to precalculate all possible hashes of these codes, which erodes the value of the transform. Furthermore, in order to create a hash, cleartext data must exist in memory at some point. In short, hashing tends to be a low-surety mechanism for data in use. This weakness could be mitigated by creating hashes in enclaves separated from where values are actually compared. Such an approach is used for password protection in many systems, and it is advised when no alternatives are readily available but protection is warranted. Or…

Use separation methods to isolate the application.
Similar to separation in the repository layer, applications in high-risk environments must use strong separation and isolation techniques to prevent unauthorized interactions among memory, processes, users, and communication channels. Or…

Consider using a transform to encrypt information.
In many cases, an application will rely on some form of repository to store data, in which case transforms take place at the repository layer instead of the application layer. But if application data requires extra protection—perhaps from repository administrators—then an application transform is appropriate. An encryption transform should only be used on secondary (backup) or other non-authoritative copies of data, to prevent the possible availability problems associated with an encryption failure. Or…

Consider using programmatic filters to limit information access.
If an enterprise develops its own applications that handle low-consequence information, then programmatic filters should be used to limit information displayed, transmitted, or accessed by subjects. Programmatic filters may be applied via application programming interfaces (APIs), via query handlers, during an onscreen presentation, and anywhere else information might leave the direct control of the application.

30
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Relationship to Other Components
The Reference Architecture root template “Information Security Technology Model” provides an overview of the resource layer components and the attendant control layers that provide management services. For separation mechanisms in networks, see the Reference Architecture technical positions “Zones” and “ Network Perimeters.” To provide guidance on use of transforms, the Reference Architecture technical position “Encryption” asks the question, “What encryption mechanisms should be used to protect information confidentiality?” Overarching discussions of technical measures used to protect content are found in the Reference Architecture templates “Protecting Data in Motion,” “Protecting Data at Rest,” “Discovering Sensitive Resources,” and “ Mitigating Malware and Spam.” For monitoring problematic activity across enterprise networks—including potential confidentiality breaches—the Reference Architecture technical position “Network Intrusion Detection and Response” asks the question, “How should enterprises detect and respond to security incidents on their network?” It is complemented by three Reference Architecture templates: “Network Intrusion Detection and Response: Demilitarized Security Zone (DMZ),” “Network Intrusion Detection and Response: Trusted Security Zone,” and “Network Intrusion Detection and Response: Restricted Security Zone.”

31
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Revision History
February 2009 • • • • Removed vendor references. Added masking as a repository-layer transform technique. Added encryption as a point-of-use transform technique. Added future developments about cloud computing and using encryption for information destruction.

March 2006 • This is the first iteration of this technical position, with some materials deriving from a rewrite of the Reference Architecture technical position “Encryption.”

32
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Notes
1 Burton Group. Security and Risk Management Strategies “Concepts and Definitions.” 26 Nov 2007. http://www.burtongroup.com/Client/Research/Document.aspx?cid=644.

33
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com

Author Bio
Trent Henry Principal Analyst Emphasis: infrastructure protection, compliance and control standards, content security, cryptography Background: Trent Henry is a Principal Analyst for Burton Group's Security and Risk Management Strategies service. He covers data protection, compliance and control standards, content security, cryptography, and other topics. Prior to joining Burton Group, Trent served in the PKI industry as a chief information security officer, technology researcher, and Internet server developer. Other past experience includes work at Identrust, Digital Signature Trust, Ameritech, and Apple. With 18 years of experience, Trent is a respected speaker and writer on information security, audit, and compliance topics. He has participated on security standards bodies such as X9 and the Internet Engineering Task Force (IETF), and contributed to the first Common Criteria Protection Profile slated to become an ANSI standard. Trent received his undergraduate degree from Stanford University.
Copyright 2009 Burton Group. ISSN 1048-4620. All rights reserved. All product, technology and service names are trademarks or service marks of their respected owners. See Terms of Use and publishing information at http://www.burtongroup.com/AboutUs/TermsOfUse.aspx

34
BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:362
posted:9/2/2009
language:English
pages:34