burton information integrity

Information IntegrityVersion: 1.0, Mar 15, 2007

AUTHOR(S):Eric Maiwald([email protected])

Additional Input:Dan Blum, Trent Henry

Statement of Problem

What technical approaches should organizations use to protect the integrityof electronic information in the resource layer?

Security and Risk Management Strategies

Reference Architecture Technical Position

23039
mailto:[email protected]

Publishing Information

Burton Group is a research and consulting firm specializing in network and applications infrastructure technologies.Burton works to catalyze change and progress in the network computing industry through interaction with leadingvendors and users. Publication headquarters, marketing, and sales offices are located at:

Burton Group7090 Union Park Center, Suite 200Midvale, Utah USA 84047-4169Phone: +1.801.566.2880Fax: +1.801.566.3611Toll free in the USA: 800.824.9924Internet: [email protected]; www.burtongroup.com

Copyright 2007 Burton Group. ISSN 1048-4620. All rights reserved. All product, technology and service names aretrademarks or service marks of their respective owners.

Terms of Use: Burton customers can freely copy and print this document for their internal use. Customers can alsoexcerpt material from this document provided that they label the document as Proprietary and Confidential and addthe following notice in the document: Copyright 2007 Burton Group. Used with the permission of the copyrightholder. Contains previously developed intellectual property and methodologies to which Burton Group retainsrights. For internal customer use only.

Requests from non-clients of Burton for permission to reprint or distribute should be addressed to the ClientServices Department at +1.801.304.8174.

Burton Group's Security and Risk Management Strategies service provides objective analysis of networkingtechnology, market trends, vendor strategies, and related products. The information in Burton Group's Security andRisk Management Strategies service is gathered from reliable sources and is prepared by experienced analysts, but itcannot be considered infallible. The opinions expressed are based on judgments made at the time, and are subject tochange. Burton offers no warranty, either expressed or implied, on the information in Burton Group's Security andRisk Management Strategies service, and accepts no responsibility for errors resulting from its use.

If you do not have a license to Burton Group's Security and Risk Management Strategies service and are interestedin receiving information about becoming a subscriber, please contact Burton Group.

Table Of Contents

Statement of Problem......................................................................................................................................................5Typical Requirements..................................................................................................................................................... 6

Maintain Integrity in All States of Data......................................................................................................................6Maintain Integrity Throughout the Information Lifecycle..........................................................................................7

Enterprise Policy..................................................................................................................................................... 7Infrastructure Surety............................................................................................................................................... 8

Manage Integrity in Context....................................................................................................................................... 9Protect Each Set of Information Appropriately.......................................................................................................... 9

Alternatives................................................................................................................................................................... 10Processes and Procedures..........................................................................................................................................10Adaptation and Disaggregation.................................................................................................................................10Infrastructure Layer...................................................................................................................................................11

Repository............................................................................................................................................................. 11Data Self-Protection (Content)..............................................................................................................................11Applications.......................................................................................................................................................... 12Systems................................................................................................................................................................. 12Identity and Access Layer.....................................................................................................................................13Perimeter Layer.....................................................................................................................................................14

Surety of Protection.................................................................................................................................................. 14Future Developments.................................................................................................................................................... 16Evaluation Criteria........................................................................................................................................................ 17Statement & Basis for Position..................................................................................................................................... 19

Data at Rest Position................................................................................................................................................. 19Establish an IT security baseline...........................................................................................................................19Protect the data itself.............................................................................................................................................20Protect at the application layer..............................................................................................................................21Use repository protections.................................................................................................................................... 21Use a change control system.................................................................................................................................21Use audit and monitoring processes......................................................................................................................21

Data in Motion Position............................................................................................................................................ 21Protect the data itself.............................................................................................................................................22Ignore the missing element................................................................................................................................... 22Use acknowledgments...........................................................................................................................................23Use sequencing to detect missing elements.......................................................................................................... 23

Data in Use Position..................................................................................................................................................23Use application layer mechanisms........................................................................................................................23

Data Self-Protection Position....................................................................................................................................23Use procedural controls, transfer, or avoid the risk.............................................................................................. 24Use a transform..................................................................................................................................................... 24Consider accepting the risk................................................................................................................................... 24

Application Layer Protection Position......................................................................................................................24The application should apply separation of duties through its design and functions............................................24Attempt to disaggregate the information and use procedures to reduce the consequences to medium or low.....25Use additional testing to validate the proper operation of the application and log all actions............................. 25Log all actions.......................................................................................................................................................25

Slowly Changing Unstructured Data at Rest Position.............................................................................................. 25Attempt to disaggregate the information and use procedures to reduce the consequences to medium or low.....26Use transforms to detect an unauthorized change and react as necessary............................................................ 26Periodically replace the data with a known good version.....................................................................................26Accept the risk...................................................................................................................................................... 27

3

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

Quickly Changing Unstructured Data at Rest Position.............................................................................................27Attempt to disaggregate the information and use procedures to reduce the consequences to medium or low.....27Audit and detect problems off line........................................................................................................................27Accept the risk...................................................................................................................................................... 28

Relationship to Other Components............................................................................................................................... 29Revision History........................................................................................................................................................... 30Notes............................................................................................................................................................................. 31Author Bio ....................................................................................................................................................................32

4


Statement of Problem

What technical approaches should organizations use to protect the integrity of electronic information in theresource layer?

5


Typical Requirements

Integrity is a security objective to prevent unauthorized or inappropriate changes to information (the knowledge,ideas, or business data that is represented in some electronic form) and to ensure that it maintains internal andexternal consistency. Verifying that the information actually reflects the reality of the real world is outside thescope of this Technical Position. For Burton Group's short definition of integrity and a detailed discussion ofintegrity and other security objectives, see the Security and Risk Management overviews, Concepts andDefinitions and An Objectives-Based Assessment Framework for Security Solutions.

The requirements for integrity come directly from the business. In order for the business to function properly, theinformation used in transactions and the configurations of hosts, applications, and network devices must be freefrom unauthorized or inappropriate modifications. Information reported to various regulatory agencies and tostockholders, employees, customers, and partners must also be free from unauthorized modifications. Suchchanges to information can have a range of consequences from simple embarrassment or minor outages toregulatory penalties or even incarceration for senior executives. Successful theft or fraud perpetrated against theorganization may also have its roots in the unauthorized modification of information which is then used to processtransactions. In fact, it was the potential for fraud that led to the use of certain accounting procedures (such asdouble entry bookkeeping and separation of duties between those who can authorize a financial transaction andthose who actually execute it).

Protecting business information such as accounting data is only one aspect of integrity that enterprises should beconcerned with. The other primary aspect of integrity is that of host and network device configurations. Althoughconfigurations seem to be different from electronic information on the surface, they are, in reality, just another setof informationalbeit with a different purpose. The integrity of configuration information is then also coveredunder the requirements and alternatives discussed in this Technical Position. It should be noted, however, that theintegrity of configuration information is also discussed to a greater depth of detail in the following ReferenceArchitecture Technical Positions:

Host Security Choices

Technical Security Policy Management: Mapping Intent into Implementation

Change Management with Assurance

Vulnerability Management

This Technical Position examines the architectural options an enterprise may use to prevent, detect, and respondto inappropriate modification or deletion of electronic information at rest, in motion, and in use. The requirementsfor information integrity are as follows:

Maintain integrity in all states of data

Maintain integrity throughout the information lifecycle

Manage integrity in context

Maintain Integrity in All States of DataData is the representation of information within an information technology (IT) environment. Data may not beuseful to the business until it is interpreted into some other form (for example, as text that can be read andunderstood by a user). However, it is the data that must be protected from unauthorized modification. Data can beat rest, in motion, or in use as described below:

Data at rest: Data that resides in some physical location and remains there. An example might be data that isstored on a hard disk.

Data in motion: Data that is moving from one place to another, such as when data is transmitted across anetwork.

Data in use: Data that is being processed by some application or transaction procedure.

6

http://www.burtongroup.com/Client/Research/Document.aspx?cid=644http://www.burtongroup.com/Client/Research/Document.aspx?cid=644http://www.burtongroup.com/Client/Research/Document.aspx?cid=958http://www.burtongroup.com/content/doc.aspx?cid=947http://www.burtongroup.com/content/doc.aspx?cid=665http://www.burtongroup.com/content/doc.aspx?cid=638http://www.burtongroup.com/content/doc.aspx?cid=714http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36058http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36059http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36062

Maintain Integrity Throughout the Information LifecycleInformation has the following lifecycle (see Figure 1):

Information is created

Information has a period of utility where it may be modified, used in transactions, examined, stored, ortransmitted

Information may be archived for later reference

Information may be destroyed when no longer needed

Figure 1: Subset of an Information Lifecycle

When information is created, some process or mechanism (usually a human process of some type) is used tovalidate that the information does, in fact, reflect the business or the observed reality. When information isdestroyed, it may be necessary to verify that it was, in fact, destroyed and not removed to some other location (butthis last aspect has more to do with the confidentiality of the information than its integrity).

During information's period of utility, enterprise policy and the surety1 of the technical controls define howintegrity is protected. Different sets of information may require different levels of protection. For example,financial records may require a higher level of integrity protection than a press release. The level of protectionthat is required will likely depend on the consequences of a violation of integrity for that set of information.

Enterprise Policy

7

http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36119

Translating the business requirements for integrity (as they are embodied in various business processes) into theIT domain is not straightforward. An early attempt at defining an integrity policy for secure computer systems

was made by K. J. Biba.2 This policy stated that information exists at different levels of integrity and systemsshould prevent information at lower levels of integrity from contaminating information at higher levels.Implementing this policy would prevent a user or application from reading low-integrity information and writingit to a high-integrity file. Unfortunately, though this model is relatively simple, it does not reflect businessrequirements.

A more appropriate policy was defined in 1987 by David Clark and David Wilson.3 This model put forward thecertification (C) and enforcement (E) rules shown in Table 1.

Table 1: Clark-Wilson Rules

But even this policy does not completely define the business requirements. For example, there is no mention ofthe assurance levels associated with the rules. Different levels of consequence associated with failures in integritymay place different testing, development, or functionality requirements on the mechanisms deployed within asystem. The policy also does not consider information that is transmitted outside of the organization or theconcept of data in motion (information being transmitted between systems).

However, this policy does bring out the fact that some type of authentication and authorization must be part of thesolution for information integrity. This means that the requirements for preventing unauthorized modification andfor detecting such a modification when it occurs will extend into mechanisms that prevent unauthorized access tosystems and information. Control will also have to be extended over administrators and other privileged userswho may have the ability to modify information outside of normal transformation procedures.

Infrastructure Surety

8

http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36119http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36119

Surety is the combination of function and an assurance that the expected mechanism performs as intended.Different security mechanisms provide different levels of surety. The need for a particular level of surety is drivenby the risk the organization faces. High-risk (or -consequence) situations should require high-surety controlmechanisms so that the risk is properly managed. Low-risk situations can be managed by low-, medium-, or high-surety controls, but the costs associated with the medium- and high-surety controls usually cause organizations touse those of low surety. More information about the surety of mechanisms can be found in the Security and RiskManagement Strategies overview, Surety Ratings of Security Mechanisms for Architecture Planning.

Risks for integrity can be less obvious than those for confidentiality. For example, although the confidentiality ofinformation on a website may not need to be protected, the integrity of that information may be very important tothe public reputation of the organization.

Not all integrity risk must be mitigated. Organizations may choose alternative approaches, such as to transfer,avoid, or accept the risk. More details on these alternative approaches can be found in the Security and RiskManagement Strategies report, Risk Management: Concepts and Frameworks.

Manage Integrity in ContextIntegrity must be managed in the context of the intended use of the information. In some cases, it may be moreimportant to make information and collaborative processes with fast turnaround times available than it is toprotect the integrity of the information. Strong change control, otherwise a good way to protect informationintegrity, is not appropriate in such collaborative environments.

Also, surrounding processes may provide compensating controls that make technology protections less important.Business processes have been developed over time to identify errors and, in some cases, malicious actions and tokeep them from causing severe consequences to the business. For example, accounting procedures have beendeveloped so that no single person can perpetrate fraud without risk of discovery. Double entry bookkeeping wasdeveloped so that mistakes can be identified when financial records are reconciled. The integrity of each part ofthe transaction may be acceptable, but in the case of financial transactions, it is the integrity of the transaction as awhole that must be understood and verified. If all parts of the transaction do not occur, the transaction is not valid.Similar procedures exist in nonfinancial procedures as well.

Technology alone will not meet all of the requirements for information integrity. For some situations, thesurrounding processes will be essential to identifying integrity violations and therefore no organization can expecttechnology to solve the problem of information integrity alone.

Protect Each Set of Information AppropriatelyA set of information is some collection of data items with a common context, defined from a combination of:

The type of information (as described during information classification)

The application or use to which that type of information is being put

The environment in which the use is taking place

9

http://www.burtongroup.com/Client/Research/Document.aspx?cid=960http://www.burtongroup.com/Client/Research/Document.aspx?cid=282

Alternatives

Integrity is similar to, but not the same as, confidentiality. While many of the same mechanisms can be used toprotect both integrity and confidentiality, in some cases, the mechanisms used to protect integrity may be at oddswith the need to protect confidentiality. Detailed positions on confidentiality protection can be found in theReference Architecture Technical Position, Information Confidentiality.

The purpose of this Technical Position is not to go into great detail on all of the various mechanisms that can beused to prevent or detect integrity violations. Rather, this Technical Position will map high-level alternatives intocategories of protection. Other Technical Positions will provide greater detail on specific technical architecturesand mechanisms that can be used to provide the protection. For example, perimeter controls can be used toprevent unauthorized access to protected information but the details of perimeter controls are discussed in theReference Architecture Technical Position, Perimeters and Zones.

Many mechanisms exist to provide integrity protection for information that is in physical form. Many of thesemechanisms fall into the category of processes and procedures discussed in the next section. However, theprotection of information in physical form is beyond the scope of this Technical Position.

This Technical Position is designed so that the reader begins with knowledge of the different sets of informationrequiring integrity protection. For each set, its state (i.e., at rest, in motion, in use) is determined and the readeruses that position as the starting point. Working through the initial positions may take the reader to additionalpositions regarding data self-protection, application layer protection, or the various aspects of unstructured data.Nothing in these positions should be taken to mean that only a single protection mechanism should be used. Onthe contrary, where possible, a layered approach is typically preferred so that there is some amount of defense indepth.

Processes and ProceduresBusiness processes and procedures provide much in the way of integrity protection. As mentioned in the TypicalRequirements section of this Technical Position, such procedures as double entry bookkeeping can be used toidentify fraud and simple mistakes.

Within IT, procedures such as proper change control have a great impact on the overall integrity of information.Validation procedures can be used so that modifications to information are verified before being authorized. Two-person rules can be used to verify that the authorized modification is the change that is actually made.

Different levels of risk require different levels of process and procedures. Detailed positions on change controlcan be found in the Reference Architecture Technical Position, Change Management with Assurance. Low-,medium-, and high-surety change control should be applied as required by the risk of an integrity violation tovarious sets of information.

Adaptation and DisaggregationManaging high-risk situations properly is critical to any organization since the consequences associated with highrisk include the complete failure of the business or the loss of life. Technical controls are rarely sufficient bythemselves to properly manage the risk of high-consequence situations and therefore organizations must eitheruse processes and procedures or find some way to adapt the business model or disaggregate the information.

Adapting the business model means that some aspect of the business process is modified to lower the risk of anintegrity violation. For example, if serious injury or death may result from an inappropriate device configuration,it may be appropriate to have two separate teams of people develop the configuration, compare and test the tworesults, and then have a two-person team configure the device while another two-person team verifies the correctconfiguration has, in fact, been obtained.

10

http://www.burtongroup.com/Client/Research/Document.aspx?cid=850http://www.burtongroup.com/Client/Research/Document.aspx?cid=16http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36057http://www.burtongroup.com/Client/Research/Document.aspx?cid=638

Risk disaggregation can be thought of as dividing your eggs between multiple baskets. In the case of integrity,risk may be reduced by keeping multiple copies of protected information in different locations. Doing so makes itmore difficult for an intentional or accidental action to modify all copies of the information while at the same timemaking it easier to compare the copies to identify that a modification has been made. Of course, distributinginformation to multiple locations may impact the confidentiality of the information and may actually conflict withconfidentiality requirements calling for the physical separation of the information. Here is a case wheremechanisms that help integrity may adversely impact confidentiality.

Another approach to risk disaggregation is to create redundant systems, each of which contains a part of one ormore information sets. For example, concerned that an integrity failure of its auctions database would doom itsbusiness, an online auction site could create multiple independent auctions databases. Such disaggregationreduces the benefits of centralization and may increase complexity, especially if the databases must appear tosupport a single seamless application and be able to exchange data with one another. For a general discussion ofrisk disaggregation, see the Security and Risk Management Strategies overview, Risk Aggregation: TheUnintended Consequence.

Infrastructure LayerThe layers at which integrity protection can be deployed correspond to the layers described in the ReferenceArchitecture Root Template, Information Security Technology Model. These include the repository, content,applications, systems, identity and access, and perimeter layers.

Repository

Repositories, content management systems, or database management systems (DBMSs) are places of protectionfor both structured and unstructured data at rest. Files are checked into the repository and it controls who isallowed to access the files. Although repositories are often considered controls for confidentiality, they can alsoprovide protection for integrity. The repository can control who is authorized to update a file and can also log allaccess and changes and provide rollback capability.

Historically, repositories were only used for high-value data, primarily due to the cost of the repository productsand the impact they had on the normal work of employees. However, this is changing with the cost of theseproducts coming down and the integration with normal employee workflow increasing.

Data Self-Protection (Content)

Protection for data that is in motion or outside the control of the enterprise must depend on the protection that iscarried along with the data. Data that is being transmitted between systems or facilities cannot be protected bymechanisms within those systems or facilities. Data that has been sent to another organization is also outside thecontrol of the enterprise.

Mechanisms that protect data for integrity generally are the same mechanisms that protect data for confidentiality.These include various forms of encryption, such as those found in virtual private network (VPN) or enterpriserights management (ERM) products. However, it should be noted that encryption algorithms can be used toenforce integrity protection without enforcing confidentiality. For example, a cryptographic checksum can beused to detect changes to data while leaving the data itself open for anyone to inspect. It should be noted,however, that mechanisms used to detect changes are not part of data self-protection but are instead part of theapplication that uses the data.

Related Reference Architecture components include:

Encryption (Technical Position)

Relevant Security and Risk Management Strategies research documents include:

11

http://www.burtongroup.com/Client/Research/Document.aspx?cid=144http://www.burtongroup.com/Client/Research/Document.aspx?cid=144http://www.burtongroup.com/Client/Research/Document.aspx?cid=17http://www.burtongroup.com/content/doc.aspx?cid=640

Cryptographic Systems Provide Foundations for Information Security (report) Rights Management: Driving Security to the Data (overview)

Applications

Applications use data to perform transactions. Therefore, applications are a critical component of any informationintegrity architecture. Applications provide the following:

User authentication and authorization

Separation of duties

Validation of data as it is used

Processes that mimic business processes

Processes that take protected information from one valid state to another

Logging and rollback of all transactions

Applications are also involved in data in motion as it may be the application that detects missing or modified data.The impact on the application will also determine if small amounts of information can be lost (therebydetermining if some type of acknowledgment or sequencing mechanism must be used). Audio and videotransmission is an example of data that can sustain the loss of small amounts of information. In fact, in thatexample, it is normally more disruptive to attempt to retransmit missing information.

Since applications are so critical for information integrity, it is important that they be designed and developedproperly. The surety associated with an application must match the risk level of the function performed and of thedata being processed unless compensated for by other controls. The surety required will impact the testing andvalidation requirements of the application.

Protection provided by applications must be recreated or reapplied for each application that is to be developed.Therefore, it may be more appropriate to implement global procedures within the DBMS.


Application Security (Application Platform Strategies Technical Position)


Application Security: Everybody's Problem (report)

Building Secure Applications: How secure do you want to be today? (report)

Web Services Security Standards 2006: Where Are We Now? (overview)

Raising the Bar: Solving Medium-Risk Problems with Medium-Surety Solutions (overview)

Relevant Application Platform Strategies research documents include:

Application Security Frameworks: Protecting Applications Consistently (overview)

To Err Is Human, So Test That Software (overview)

What's in Your Software Testing Wallet? (Methodologies and Best Practices document)

Systems

Integrity protection mechanisms on systems include both preventative controls and detection mechanisms.Mechanisms are deployed to prevent unauthorized user access with the idea that if unauthorized access isprevented, modifications cannot be made to protected information. Preventative controls include such things asantivirus software, host intrusion prevention system (HIPS) products, system firewalls, and various types of dataencryption products. These same controls can be used to protect the confidentiality of information. In other words,these mechanisms prevent any type of unauthorized access.

12

http://www.burtongroup.com/content/doc.aspx?cid=204http://www.burtongroup.com/content/doc.aspx?cid=204http://www.burtongroup.com/Client/Research/Document.aspx?cid=166http://www.burtongroup.com/content/doc.aspx?cid=21http://www.burtongroup.com/content/doc.aspx?cid=709http://www.burtongroup.com/Client/Research/Document.aspx?cid=102http://www.burtongroup.com/Client/Research/Document.aspx?cid=137http://www.burtongroup.com/Client/Research/Document.aspx?cid=710http://www.burtongroup.com/content/doc.aspx?cid=186http://www.burtongroup.com/content/doc.aspx?cid=729http://www.burtongroup.com/content/download.aspx?cid=817

Detection mechanisms on systems focus on detecting and correcting unauthorized changes to systemconfigurations. These mechanisms generally fit into the vulnerability management category, but this category hasexpanded to include policy and configuration management products. To some extent, these products are alsopreventative in nature as the proper configuration of the system prevents unauthorized access attempts fromsucceeding.

Generally, all system protection mechanisms are low surety as they rely on the operating system to not subvert thesecurity mechanism. Encryption products may achieve medium surety if the algorithm is vetted and theimplementation is properly tested. But even here, the encryption software must run under the operating system somedium surety is still difficult to achieve without some type of hardware component. Increasing the securityprovided by the operating system increases the overall preventative security provided by the system.


Host Security Choices (Technical Position)

Encryption (Technical Position)

Malicious Software (Technical Position)

Technical Security Policy Management: Mapping Intent Into Implementation (Technical Position)

Vulnerability Management (Technical Position)

Vulnerability Management: Agent-Based Model (Template)

Vulnerability Management: Agentless Model (Template)

Vulnerability Management: Service Provider Model (Template)


Malware, Cybercrime, and a Full Spectrum Defense (report)

Security in the Palm of Your Hand (report)

Encryption for Mobile Hosts: Protection on the Fly (report)

Replacement HIPS? Enterprise Considerations for Selecting Host Intrusion Prevention Systems (report)

Windows Security Vista Appears More Promising (overview)

Next-Generation Trustworthy Computing: Reality Falls Short of Potential (overview)

Vulnerability Management: Toward Technical Security Policy Management Products (report)

Cryptographic Systems Provide Foundations for Information Security (report)

Identity and Access Layer

User authentication and authorization controls are implemented within systems, perimeters, repositories, andapplications rather than being a separate layer. Burton Group's Reference Architecture Root Template (Information Security Technology Model) shows it as a separate layer to indicate that the controls form anotherboundary (or layer) or protection through which attackers and authorized users must pass.

It should be noted that user authentication and authorization controls legitimate users and prevents them fromperforming unauthorized actions. Preventative mechanisms at the system and perimeter layer tend to be focusedon unauthorized users attempting to gain access by circumventing the user authentication and authorizationmechanisms.

Authentication and authorization mechanisms are covered by Burton Group's Identity and Privacy ManagementStrategies service.

Related Identity and Privacy Management Strategies Reference Architecture components include:

User Authentication (Technical Position)

User Authorization (Technical Position)

Roles (Technical Position)

13

http://www.burtongroup.com/content/doc.aspx?cid=947http://www.burtongroup.com/content/doc.aspx?cid=640http://www.burtongroup.com/content/doc.aspx?cid=861http://www.burtongroup.com/content/doc.aspx?cid=665http://www.burtongroup.com/content/doc.aspx?cid=714http://www.burtongroup.com/content/doc.aspx?cid=808http://www.burtongroup.com/content/doc.aspx?cid=810http://www.burtongroup.com/content/doc.aspx?cid=809http://www.burtongroup.com/content/doc.aspx?cid=997http://www.burtongroup.com/content/doc.aspx?cid=624http://www.burtongroup.com/content/doc.aspx?cid=856http://www.burtongroup.com/content/doc.aspx?cid=791http://www.burtongroup.com/content/doc.aspx?cid=814http://www.burtongroup.com/content/doc.aspx?cid=753http://www.burtongroup.com/content/doc.aspx?cid=663http://www.burtongroup.com/content/doc.aspx?cid=204http://www.burtongroup.com/Client/Research/Document.aspx?cid=17http://www.burtongroup.com/content/doc.aspx?cid=629http://www.burtongroup.com/content/doc.aspx?cid=128http://www.burtongroup.com/content/doc.aspx?cid=631

Identity Auditing (Technical Position)

Perimeter Layer

The perimeter layer provides preventative integrity protections in that the deployment of perimeter mechanismsprevents unauthorized users from gaining access to systems and information. In a number of cases (such asinformation provided on a website), preventative controls focus not so much on preventing information frombeing accessed, but rather on preventing unauthorized users from gaining write access (i.e., the ability to make achange) to the information.

Filters are used by many perimeter mechanisms to block attacks or malicious content from entering a network.These filtering mechanisms may be deployed within firewalls or network intrusion detection and responsesystems (NIDRS), but they tend to be low surety.

Transforms (in the form of encrypted VPNs) may be used to protect data in motion as it traverses untrustednetworks. The VPNs may be implemented as part of the perimeter layer. It should be noted that information canalso be transformed at the application layer. Transforms may achieve medium surety if properly implemented.

The perimeter layer is also used to enforce separation. Physical separation can be used as a high-suretymechanism to protect information. However, separation does not have the same utility for integrity as it does forconfidentiality; therefore, it is less likely to prove valuable because information may need to be read even whenwriting is prohibited.


Perimeters and Zones (Technical Position)

Network Intrusion Detection and Response (Technical Position)

Perimeter Template: Closed Architecture Model (Template)

Perimeter Template: Control and Audit in the Layered Architecture Model (Template)

Perimeter Template: Layered Architecture Model (Template)

Perimeter Template: Open Architecture Model (Template)

Network Intrusion Detection and Response: Outer Security Zone (Template)

Network Intrusion Detection and Response: Business Security Zone (Template)

Network Intrusion Detection and Response: Restricted Security Zone (Template)


Web Application Firewalls Are Dead! Long Live Web Application Firewall Functionality (report)

Network Intrusion Detection and Response: More than Just Speed Bumps on the Network? (report)

Firewall Futures: Can a Mature Technology Learn New Tricks? (overview)

Enforcing Access Security: Maturing Role for SSL VPNs (report)

Wireless LAN Intrusion Detection Systems: Something's in the Air' (report)

Enterprise Firewalls and Perimeter Architecture (report)

Surety of ProtectionThe surety of protection should be matched to the risk associated with an integrity violation. The vast majority oftechnical controls are low-surety mechanisms. Even in cases where medium-surety mechanisms can be found(such as in the cases of properly implemented cryptographic devices), much depends on the surrounding devicesand system components. The surety of applications is related to the development process and to the testing thatthe application undergoes. It should be stressed that security testing (i.e., testing to determine that no fault existsthat will allow unauthorized transactions to occur) is significantly different and more resource intensive thanfunctional testing (i.e., testing that certain functions work as required and designed).

14

http://www.burtongroup.com/content/doc.aspx?cid=830http://www.burtongroup.com/content/doc.aspx?cid=830http://www.burtongroup.com/content/doc.aspx?cid=16http://www.burtongroup.com/content/doc.aspx?cid=635http://www.burtongroup.com/content/doc.aspx?cid=889http://www.burtongroup.com/content/doc.aspx?cid=890http://www.burtongroup.com/content/doc.aspx?cid=627http://www.burtongroup.com/content/doc.aspx?cid=891http://www.burtongroup.com/content/doc.aspx?cid=693http://www.burtongroup.com/content/doc.aspx?cid=694http://www.burtongroup.com/content/doc.aspx?cid=695http://www.burtongroup.com/content/doc.aspx?cid=908http://www.burtongroup.com/content/doc.aspx?cid=793http://www.burtongroup.com/content/doc.aspx?cid=213http://www.burtongroup.com/content/doc.aspx?cid=752http://www.burtongroup.com/content/doc.aspx?cid=748http://www.burtongroup.com/content/doc.aspx?cid=751

Generally, protection mechanisms can be grouped into three categories:

Filters: Filters provide a low-surety mechanism that is used to prevent something from occurring. If a filterdetects an unauthorized event, some action is taken to prevent the event from causing consequences.

Transforms: Transforms may (if implemented properly) provide a medium-surety mechanism. Transforms canbe used to prevent unauthorized modification by limiting access to information or to detect that a modificationhas been made.

Separation: Separation may (with the proper procedures) provide a high-surety mechanism that can be used toprevent an unauthorized modification. However, separation may not be possible in cases where the protectedinformation is to be read by anything but a small group of individuals.

A more comprehensive discussion of surety mechanisms can be found in the Security and Risk ManagementStrategies overview, Surety Ratings of Security Mechanisms for Architecture Planning.

15

http://www.burtongroup.com/Client/Research/Document.aspx?cid=960

Future Developments

While the future developments of specific technologies and mechanisms are considered in Reference ArchitectureTechnical Positions specifically devoted to those technologies and mechanisms, some larger issues and changesare coming that will impact how integrity protection is provided.

In many ways, integrity has been the poor stepbrother of confidentiality and this has resulted in a focus onprotecting information from unauthorized disclosure. While this protection has also prevented many types ofunauthorized modification from taking place (if I can't see it, I can't change it), integrity protection is becomingmore of an issue. Recent regulatory changes that require executives to sign off on financial statements or that havechanged how information is disclosed during legal procedures have increased the requirements for informationintegrity. It is likely that this trend will continue so that enterprises will need to define the integrity requirementsfor information. This will likely lead to more-detailed integrity requirements for applications processinginformation.

Information management systems or repositories are becoming more available and their increased use willprovide a more comprehensive environment for managing unstructured data. As the repositories become more apart of day-to-day workflow, organizations will have a built-in ability to track how information is changed overtime.

The nature of our information is also changing. Today, there is a difference between how structured andunstructured information are used, processed, and stored. But changes are coming as DBMSs (the traditionalhome of structured data) become capable of storing free-flowing text (normally considered unstructured data).The control capabilities of the DBMS will improve the mechanisms around the unstructured data but does thatmean that the mechanisms will be able to detect changes to the necessary level of granularity? On the other end ofthe spectrum, text files (traditionally the definition of unstructured data) are becoming more structured throughthe use of Extensible Markup Language (XML) tags. Perhaps this will make it easier to detect modifications andtrack how a file is changing over time.

On systems, the promise of secure or trusted operating systems and modules continues to loom on the horizon.Deployment of trusted platform modules (TPMs) to more systems opens the possibility of greater surety overcryptographic mechanisms, including those used to detect integrity violations. Matching the hardware moduleswith more-trusted operating systems and application code may increase the surety levels provided by systems.

16


Evaluation Criteria

In addition to the Reference Architecture Principles, the following evaluation criteria should guide anorganization's information integrity architecture decisions through the position statements found in the nextsection. In some cases, these evaluation criteria need to be considered separately for multiple sets of information.

Where is the information?

The location of the information will impact the types of preventative mechanisms that can be deployed toprotect it. Information that exists within repositories also may be protected by the capabilities of the repository.

Where is the control point?

The location of the control point impacts the choice of integrity protection to a large extent. If the control pointis located within the organization, a larger choice is available for preventative and detection mechanisms.

How fast does information change?

Information that is constantly being updated is very difficult to protect using change control procedures.Therefore, the faster the rate of change, the more after-the-fact detection mechanisms will be used.

Who has to validate that the information has not been modified in an unauthorized manner?

Procedures should be defined for verifying that information has not been modified. These procedures will needto be implemented in applications and in the processes and procedures around information.

Who can determine that the process implemented in software is a proper mirror of the actual business process?

Because the process is defined by the business, it may not be up to the IT staff to determine that the transactionprocess implemented within an application is the same as defined by the business. Business staff will need tobe involved in application testing.

What is the sensitivity of the information stored across the enterprise?

Just as different sets of information have different confidentiality requirements, different sets of informationwill have different integrity requirements. It is unlikely that a single classification tag (such as confidential)will communicate all of the necessary information to determine both confidentiality and integrity requirements.

What are the consequences of a violation of integrity?

Consequences and therefore risk will determine the surety requirements for integrity protection mechanisms.The consequences of an integrity violation should be determined for each set of data so that proper decisionscan be made.

What business processes are in place to detect violations of integrity?

Existing business processes may reduce the risk of an integrity violation. Alternatively, the business processeswill need to be implemented in applications or within the IT environment.

What existing preventative controls already exist in the organization?

Existing preventative controls can be used to reduce the risk of an integrity violation. For example, ifencryption is already being used to protect information for confidentiality, then the group of users capable ofaccessing the information and making a change is already reduced. The same is true for perimeter and systemcontrolsif they are already in place, they may reduce the risk of unauthorized modification.

What type of information is to be protected (structured vs. unstructured, static vs. dynamic)?

Different types of information require different mechanisms for integrity protection. Protection for structureddata will tend toward applications while protection for unstructured data will tend toward repositories, the useof transforms, or the use of logging and after-the-fact analysis.

17

http://www.burtongroup.com/Client/Research/Document.aspx?cid=15

How is the information used (does missing an element impact the communication)?

Information use will impact the consequences of an integrity violation and therefore the mechanisms andsurety levels required. If the loss of a small amount of information will impact the sender or receiver, somemechanism must be deployed to detect the loss and then to cause a retransmission to occur. Applications thatare not impacted from the loss of small amounts of information do not require such mechanisms.

What communication paths are available?

For data in motion, the available communication paths will impact the mechanisms that can be used to detectintegrity violations.

What type of testing is included in the software development lifecycle(SDLC)?

An organization's SDLC process impacts the surety of applications. If testing is only performed to make surethe required functions are provided, there is less surety than if more-detailed security testing is performed.

18


Statement & Basis for Position

To develop an architecture for information integrity, position statements are required in the following areas:

Data at Rest

What integrity protections should be used for data at rest?

Data in Motion

What integrity protections should be used for data in motion?

Data in Use

What integrity protections should be used for data in use?

Data Self-Protection

What integrity methods should be used to protect data itself?

Application Layer Protection

What integrity methods should be used to protect data at the application layer?

Slowly Changing Unstructured Data at Rest

What integrity methods should be used to protect slowly changing unstructured data at rest?

Quickly Changing Unstructured Data at Rest

What integrity methods should be used to protect quickly changing unstructured data at rest?

Generally, these position statements must be considered in the context of multiple sets of information.

Data at Rest PositionWhat integrity protections should be used for data at rest?

The first position for protecting data at rest is:

Establish an IT security baseline.

Baseline security mechanisms that should be provided as part of an organization's information securityarchitecture will support information integrity objectives. Different mechanisms may then be used, depending onthe context surrounding each set of information. For example, the capabilities for strong identity assurance orstrong change control are available even though it may not be cost and risk effective to use them with allinformation sets. The IT security baseline should include:

Proper authentication and authorization methods for all access to protected data: For all resources thatstore data, identity-based controls should be employed to mediate access to the data. Authorized users shouldbe limited to only the functions and permissions necessary. It should be noted that for proper integrityprotection, the functions of highest concern are those associated with writing data. does not affect the integrityof data.

Appropriate perimeter and host controls to prevent unauthorized access to protected data: Unauthorizedusers will attempt to gain access to resources through abnormal paths such as exploiting vulnerabilities inoperating systems or applications. Perimeter and host controls should be used to limit the potential for suchexploitation. Such controls include deploying filtering, separation, or transforms at the perimeter and deployingvulnerability, policy, malicious software, or configuration management systems on the host.

19

http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36078http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36086http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36092http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36095http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36100http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36106http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36112

Logging of the use of administrator privileges: Administrators (system, network, and database) can bypassnormal user and application controls due to the nature of their jobs. Although it is nearly impossible to preventan administrator from modifying data at rest, recording the actions of the administrator and storing the recordsin a protected environment to which the administrator does not have access provides a mechanism to detect theunauthorized modification.

Proper change control to mitigate mistakes: Proper change control procedures can do much to preventmistakes. Change control may include mechanisms such as two-person commit sequences for transactions orpeer review and approval for changes to websites and device configurations.

Figure 2 shows a flow chart depicting the logic to use when identifying integrity protections for information atrest. The protections that may be applied first depend on where the information's control point exists. The secondconsideration is the type of data that is being protected. Structured data requires different types of protectivemeasures than unstructured data. If a repository is available, it should be used for unstructured data as repositoriesprovide many integrity protections. If a repository is not available, the next consideration is whether the datachanges slowly or quickly.

Figure 2: Flow Chart for Initial Data at Rest Position

(Note: The following positions are recommended in addition to the position listed above.)

Alternative Data at Rest position statements (important: for each set of sensitive information, choose only one):

Protect the data itself.

20


Information may reside on user systems that are not under the control of the enterprise. The control point forprotecting the information from unauthorized modification may also reside outside the control of the enterprise. Inthese cases, the ability to prevent unauthorized modification or to determine if the information has been modifiedmust reside with the information (see the Data Self-Protection position).

Or

Protect at the application layer.

Structured information needs to abide by a set of rules so that it can be used and stored in the proper way.Applications can validate data as it is taken from storage and used or processed. It should be noted that in caseswhere the rules to be applied are the same across multiple applications, it may be more appropriate to leverageDBMS security features as much as possible (see the Application Layer Protection position).

Or

Use repository protections.

Repositories provide a number of protections for the information stored within. They control who can do what towhich files. Changes and access are audited. It may also be possible to have the repository detect changes that aremade to files. While repositories have been historically limited to high-value information, the cost and impact ofrepositories has been reduced in recent years.

Or

Use a change control system.

The nature of unstructured information makes it much more difficult to prevent an unauthorized change if theattacker can gain access to the file. Simply stated, unstructured information will not need to follow the same typeof strict formatting rules that structured information must follow. Information that changes slowly can bemonitored so that any changes are detected and compared with known, authorized changes. If an unauthorizedchange is detected, the appropriate reaction can be made (see the Slowly Changing Unstructured Data at Restposition).

Or

Use audit and monitoring processes.

Information that changes very quickly makes real-time monitoring extremely difficult as it becomes nearlyimpossible to implement a process to detect a change and verify that it is a correct change without limiting thespeed of change. Detecting changes after the fact through an audit and monitoring process may be necessary (seethe Quickly Changing Unstructured Data at Rest position).

Data in Motion PositionWhat integrity protections should be used for data in motion?

Figure 3 shows a flow chart depicting the logic to use when specifying integrity requirements for protectinginformation in motion. Applications using particular information sets, whether purchased or developed, shouldmake use of the required protections regardless of which protocol they employ (e.g., Internet Protocol security[IPsec], Secure Sockets Layer [SSL], and Web Services Security Language [WS-Security]), and in some cases,the requirements may influence the choice of protocol.

21

http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36095http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36100http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36106http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36112

The protections that may be applied first depend on whether the concern is for the modification of information orfor the complete deletion of the information. Note that it may be necessary to examine both cases for some typesof information. The second consideration is whether the loss of a single element (packet or message) willadversely impact the sender or receiver of the information. In some cases, the loss of a single packet will notimpact the communication and it is more advantageous to simply ignore the lost information. If the loss of asingle element will impact the sender or receiver, a third consideration is whether there is a path for the receiver tonotify the sender of the lost information.

Figure 3: Flow Chart for Data in Motion Position

Alternative Data in Motion position statements (important: for each set of sensitive information, chooseonly one):

Protect the data itself.

Information in motion may travel across unprotected networks or to user systems that do not have any way tocompare the information to what was originally transmitted. In these cases, the ability to prevent unauthorizedmodification or to determine if the information has been modified must reside with the information. Data self-protection technologies (such as transforms like cryptographic controls and rights management) are medium andlow surety respectively. Standing alone, they cannot mitigate high risk and must be supplemented by proceduralor other controls (see the Data Self-Protection position).

Or

Ignore the missing element.

22

http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36095

In some cases (such as in the transmission of voice or video), the loss of some information does not impact theoverall operation of either the sender or the recipient of information. In fact, attempts to ask for retransmissionmay adversely affect the operation of the system being used. In these cases, it is a better option to simply ignorethe missing element.

Or

Use acknowledgments.

Acknowledgments allow the recipient of information to notify the sender that the information has, in fact, beenreceived. If the sender does not receive an acknowledgment within some period of time, it can be assumed that theinformation did not arrive as planned and the sender can retransmit the information. It should be noted that it isalso possible that the acknowledgment was lost rather than the original information and therefore the recipientneeds a mechanism (such as a sequence number) to determine that the retransmission is a duplicate.Acknowledgments can occur as part of network protocols or may be built into applications. The use ofacknowledgments requires there to be a communication path from the recipient back to the sender. In some cases,the acknowledgment itself must be protected from an unauthorized modification. If this is the case, theacknowledgment becomes the data to be protected (see the Data Self-Protection position).

Or

Use sequencing to detect missing elements.

Applying sequence numbers to all transmitted information allows the recipient to identify when information ismissing. Sequence numbers do not allow the recipient to detect that the last element of a transmitted sequence ismissing unless there is also some code used to indicate the end of the information. The time it takes to detect theloss of information is indeterminate because it is based on receipt of information out of sequence.

Data in Use PositionWhat integrity protections should be used for data in use?

There is only one position for data in use:

Use application layer mechanisms.

Information in use is handled by applications, and logic should be built into the application to verify theinformation before adverse circumstances result. The application may include transforms, such as cryptographicchecksums, hashes, and signatures. This ensures that no unauthorized modification has been made before theapplication processes the information (see the Application Layer Protection position).

Data Self-Protection PositionWhat integrity methods should be used to protect data itself?

The logic for choosing a method to enable data to protect itself is as follows:

IF the consequences of an undetected violation of integrity are high

THENuse procedural controls, transfer, or avoid the risk

OTHERWISE IF the consequences of an undetected violation of integrity are medium

THENuse a transform

23

http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36095http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36100http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36097http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36098

OTHERWISEconsider accepting the risk

Alternative Data Self-Protection position statements (important: for each set of sensitive information,choose only one):

Use procedural controls, transfer, or avoid the risk.

Very specific procedural controls can be used instead of, or in addition to, technical controls to detect dataintegrity violations, but they tend to be expensive to implement. The procedural controls may include the use of atransform to prevent or detect integrity violations but the use of the transform by itself is insufficient for high-consequence situations since the transforms are medium- or low-surety mechanisms. If the consequences offailing to detect an integrity violation are high, transferring or avoiding the risk entirely may be more appropriateactions. The business process should also be examined to determine how it might be modified to reduce the risk.

Or

Use a transform.

Transforms can be used to limit access to data or to detect that the information has been modified. If it is onlynecessary to detect and prove that the data has been modified, then a cryptographic checksum can be used andkept with the information so that the integrity can be verified at the time of use (see the Data in Use position).However, if confidentiality is also desired, the proper transform should be used as confidentiality mechanismsalso protect the integrity of the protected information.

Or

Consider accepting the risk.

When consequences are low, business requirements and convenience, rather than the management or mitigationof risk, will dictate the acceptable level of protection. It may be appropriate for the business to accept that theinformation may be modified and go undetected if there are few or no consequences. Alternatively, transformscan be used to detect a modification if the inconvenience is not too great.

Application Layer Protection PositionWhat integrity methods should be used to protect data at the application layer?

Applications offer the ability to both prevent and detect integrity violations to protected data. As such, theapplication must be properly architected and tested prior to deployment and properly maintained once in use. Thisincludes the employment of proper preventative mechanisms, such as authentication and authorization controls(as discussed in the Data at Rest position).

The first position for protecting data at the application layer is:

The application should apply separation of duties through its designand functions.

The transaction logic within the application should be created to implement the proper business procedures whenperforming an action on protected information (for example, double entry bookkeeping or two-person commitsfor financial transactions). Transaction logic should only be modified by individuals authorized to changebusiness logic. This capability is necessarily separate from the capability to modify the data. Any change to thebusiness logic must be verified.

24

http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36099http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36092http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36078

(Note: One of the following positions is recommended in addition to the position listed above.)

IF the consequences of a violation of integrity are high

THENattempt to disaggregate the information and use procedures to reduce the consequences to medium orlow

OTHERWISE IF the consequences of a violation of integrity are medium

THENuse additional testing to validate the proper operation of the application and log all actions

OTHERWISElog all actions

Alternative Application Layer Protection position statements (important: for each set of sensitiveinformation, choose only one):

Attempt to disaggregate the information and use procedures toreduce the consequences to medium or low.

Technology alone does not offer sufficient surety to control high consequences. The information must be corrector if it is not correct, the problem must be detected before the transaction is processed. Limiting access to theinformation through physical separation would be the best option; however, if the information must be usedwidely, access must be granted in such a manner that the information cannot be modified. Ideally, the informationcan be divided or duplicated in such a manner as to make any single integrity violation result in lesserconsequences.

Or

Use additional testing to validate the proper operation of theapplication and log all actions.

Medium consequences are still significant to an organization and therefore greater care must be taken with theapplications that process information of this risk level. These applications should be tested so that any type ofincorrectly formatted input does not result in an integrity violation (i.e., an unauthorized modification of protectedinformation). It may be necessary to maintain mappings of which users and application modules have access tothe protected information and the actions that may be performed. The application itself must be protected fromunauthorized modification. All actions should be logged and the logs should be protected for integrity so thatevents can be recreated if necessary. The ability to roll back transactions should also be included in theapplication.

Or

Log all actions.

For any application that operates on protected information, a log should be kept of all actions. The log shouldinclude the user who performed the action and the exact modification that was made. Logs can be used forrollback purposes as well. The use of the logs should allow the data to be returned to a known good state. Logsshould be considered protected information so that any attempted modification of the log will be detected andprevented. In low-surety cases, the level and volume of logging may be traded off with performance and storageconsiderations.

Slowly Changing Unstructured Data at Rest Position

25


What integrity methods should be used to protect slowly changing unstructured data at rest?

In addition to maintaining an IT security baseline as described in the Data at Rest position, the followingpositions are also recommended.

IF the consequences of a violation of integrity are high


OTHERWISE IF the consequences of a violation of integrity are medium or the cost of detection is less than therisk

THENuse transforms to detect an unauthorized change and react as necessary

OTHERWISE IF the data is visible to the public

THENperiodically replace the data with a known good version

OTHERWISEaccept the risk

Alternative Slowly Changing Unstructured Data at Rest position statements (important: for each set ofsensitive information, choose only one):


Use disaggregation when the consequences of an integrity violation are simply too severe to control withtechnology alone. The information must be correct or if it is not correct, the problem must be detected. Althoughlimiting access to the information through physical separation would be the best option, if the information must beused, access must be granted in such a manner that the information cannot be modified. Ideally, the informationcan be divided or duplicated so as to make any single integrity violation result in lesser consequences.

Or

Use transforms to detect an unauthorized change and react asnecessary.

In addition to putting slowly changing, unstructured, medium-consequence information under change control,organizations should use transforms to detect an unauthorized change. Transforms, such as hash functions orcryptographic checksums, can be used to detect changes in information. The original information is run throughthe transform, which generates a unique value. At periodic times, the information is run through the transformagain and the resulting value is compared with the original. If the values are different, some change has occurred.The original unique value must itself be protected from unauthorized modification but it need not reside in thesame location as the information that is to be protected. If an unauthorized change is detected, an appropriatereaction should be made (usually the information is replaced with a known good version of the information).

Or

Periodically replace the data with a known good version.

26

http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36078http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36108http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36109http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36110http://www.burtongroup.com/Client/Research/Document.aspx?cid=999&display=full#36111

Information that needs to be protected from unauthorized changes may be highly visible (such as on a webpage)and on a host where the cost of verifying the integrity of the information is too expensive in terms of processingcycles or time to perform on a regular basis. The information is relatively static and so any change to theinformation can be considered to be unauthorized. Rather than perform the steps necessary to verify that theinformation has or has not been changed, it may be appropriate to simply replace it with information from aknown good source. The information within the known good source must itself be properly protected fromunauthorized changes, but the cost of verifying the information will be lower so that other controls can be used.

Or

Accept the risk.

If the risk is sufficiently low, it may be appropriate to accept the risk with the understanding that the unauthorizedmodification may exist for some period of time before it is noticed through some other means.

Quickly Changing Unstructured Data at Rest PositionWhat integrity methods should be used to protect quickly changing unstructured data at rest?

The logic for choosing a method for fast-changing data is as follows:

IF the consequences of an undetected violation of integrity are high


OTHERWISE IF the consequences of an undetected violation of integrity are medium

OR IF the costs of capturing, storing, and examining audit data do not outweigh the risk

THENaudit and detect problems off line

OTHERWISEaccept the risk

Alternative Quickly Changing Unstructured Data at Rest position statements (important: for each set ofsensitive information, choose only one):


Use disaggregation when the consequences of an integrity violation are simply too severe to control withtechnology alone. The information must be correct or if it is not correct, the problem must be detected. Althoughlimiting access to the information through physical separation would be the best option, if the information must beused, access must be granted in such a manner that the information cannot be modified. Ideally, the informationcan be divided or duplicated in such a manner as to make any single integrity violation result in lesserconsequences. Alternatively, consider the possibility of slowing down the transaction rate so that the properintegrity validation process can be performed prior to the commit cycle.

Or

Audit and detect problems off line.

27


Information that changes rapidly is very difficult to manage for integrity. By its very nature, the information isconstantly changing. Static mechanisms do not work well with this type of information and so it is moreadvantageous to maintain an audit trail of all changes. Using the audit trail, transactions can be recreated andverified off line. The audit trail should identify the change that was made and the user or process that made thechange. Audit trails can be used for rollback purposes as well. The use of the audit log should allow the data to bereturned to a known good state. Of course, the audit log itself must be properly protected from unauthorizedmodification. Automated analysis of the audit logs may catch up by verifying all changes during off-peak times,or statistical sampling could be used to identify potential problem areas for more intensive investigation.

Or

Accept the risk.

In cases where the consequences of not detecting an integrity violation are low, it may be appropriate for theorganization to accept the risk especially in cases where there are significant costs associated with prevention anddetection mechanisms. It should be noted that the risk may be low because other mechanisms are in place todetect an unauthorized modification (for example, business procedures).

28


Relationship to Other Components

The Reference Architecture Technical Position, Change Management with Assurance, discusses the process ofchange management and how it can be used to meet various surety requirements.

The Reference Architecture Technical Position, Encryption, discusses the use of encryption to provide for theprotection of information.

The Reference Architecture Technical Position, Host Security Choices, discusses ways of improving thepreventative capabilities of systems.

The Reference Architecture Technical Position, Information Confidentiality, discusses how organizations canmeet confidentiality requirements. In some cases, the mechanisms deployed for confidentiality protection willalso provide integrity protection. However, the two requirements may conflict in some cases.

The Reference Architecture Technical Position, Malicious Software, discusses the deployment of malicioussoftware control mechanisms. These mechanisms can provide some preventative protection for integrity.

The Reference Architecture Technical Position, Network Intrusion Detection and Response, discusses thedeployment of a perimeter preventative mechanism.

The Reference Architecture Technical Position, Perimeters and Zones, discusses the creation of networkperimeters and the deployment of perimeter mechanisms that can be used to prevent unauthorized access.

The Reference Architecture Technical Position, System Placement, discusses the placement of systems intozones and therefore how much protection a perimeter may provide to a particular system.

The Reference Architecture Technical Position, Technical Security Policy Management: Mapping Intent intoImplementation, discusses the management of organizational policy on systems.

The Reference Architecture Technical Position, Vulnerability Management, discusses how an organization canmanage vulnerabilities to prevent their exploitation by unauthorized individuals.

29

http://www.burtongroup.com/content/doc.aspx?cid=638http://www.burtongroup.com/content/doc.aspx?cid=640http://www.burtongroup.com/content/doc.aspx?cid=947http://www.burtongroup.com/content/doc.aspx?cid=850http://www.burtongroup.com/content/doc.aspx?cid=861http://www.burtongroup.com/content/doc.aspx?cid=635http://www.burtongroup.com/content/doc.aspx?cid=16http://www.burtongroup.com/content/doc.aspx?cid=639http://www.burtongroup.com/content/doc.aspx?cid=665http://www.burtongroup.com/content/doc.aspx?cid=665http://www.burtongroup.com/content/doc.aspx?cid=714

Revision History

March 2007

This is the first iteration of this Technical Position.

30


Notes

1 Burton Group. Security and Risk Management Strategies Concepts and Definitions. 6 Jul 2006. http://www.burtongroup.com/Content/doc.aspx?cid=644.

2 K. J. Biba. Integrity Considerations for Secure Computer Systems, Technical Report MTR-3153. MITRECorporation. Apr 1977.

3 David D. Clark, David R. Wilson. A Comparison of Commercial and Military Computer Security Policies. IEEE Symposium on Security and Privacy. IEEE Computer Society Press. Apr 1987.

31

http://www.burtongroup.com/Content/doc.aspx?cid=644

Author Bio

Eric Maiwald

Senior Analyst

Emphasis: Information security architecture, perimeter security, enterprise security management, infrastructureprotection, mobility and mobile security

Background: Over 18 years of experience in enterprise information security as a security officer and consultant(with Fortrex Technologies) for large financial institutions, healthcare providers, services firms, and manufacturers.Extensive experience in the security field performing assessments, policy development, architecture design, andproduct implementations. Also has experience as a product manager for Bluefire Security Technologies.

Primary Distinctions: Respected speaker on enterprise security topics and Certified Information Systems SecurityProfessional. Named inventor of several patents: "Apparatus and Method for Providing Multi-level Security forCommunications among Computers and Terminals on a Network," "Using Trusted Associations to Establish Trustin a Computer Network," "Apparatus and Method for Providing Network Security," and "Method for EstablishingTrust in a Computer Network via Association." Author of "Network Security: A Beginner's Guide, SecurityPlanning and Disaster Recovery," (with William Sieglein); and "Fundamentals of Network Security," all publishedby Osborne/McGraw-Hill.

32


burton information integrity

Documents

burton customers

burton group retainsrights

nonclients of burton

service marks

information integrityversion

information lifecycle

internal use

vendor strategies