Burton Information Integrity

Security and Risk Management Strategies
Reference Architecture Technical Position
Information Integrity
Version: 1.0, Mar 15, 2007
AUTHOR(S):
Eric Maiwald
(emaiwald@burtongroup.com)
Additional Input:
Dan Blum, Trent Henry
Statement of Problem
What technical approaches should organizations use to protect the integrity
of electronic information in the resource layer?
23039
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 leading
vendors and users. Publication headquarters, marketing, and sales offices are located at:
Burton Group
7090 Union Park Center, Suite 200
Midvale, Utah USA 84047-4169
Phone: +1.801.566.2880
Fax: +1.801.566.3611
Toll free in the USA: 800.824.9924
Internet: info@burtongroup.com; www.burtongroup.com
Copyright 2007 Burton Group. ISSN 1048-4620. All rights reserved. All product, technology and service names are
trademarks 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 also
excerpt material from this document provided that they label the document as Proprietary and Confidential and add
the following notice in the document: Copyright 2007 Burton Group. Used with the permission of the copyright
holder. Contains previously developed intellectual property and methodologies to which Burton Group retains
rights. For internal customer use only.
Requests from non-clients of Burton for permission to reprint or distribute should be addressed to the Client
Services Department at +1.801.304.8174.
Burton Group's Security and Risk Management Strategies service provides objective analysis of networking
technology, market trends, vendor strategies, and related products. The information in Burton Group's Security and
Risk Management Strategies service is gathered from reliable sources and is prepared by experienced analysts, but it
cannot be considered infallible. The opinions expressed are based on judgments made at the time, and are subject to
change. Burton offers no warranty, either expressed or implied, on the information in Burton Group's Security and
Risk 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 interested
in receiving information about becoming a subscriber, please contact Burton Group.
Table Of Contents
Statement of Problem......................................................................................................................................................5
Typical Requirements..................................................................................................................................................... 6
Maintain Integrity in All States of Data......................................................................................................................6
Maintain Integrity Throughout the Information Lifecycle..........................................................................................7
Enterprise Policy..................................................................................................................................................... 7
Infrastructure Surety............................................................................................................................................... 8
Manage Integrity in Context....................................................................................................................................... 9
Protect Each Set of Information Appropriately.......................................................................................................... 9
Alternatives................................................................................................................................................................... 10
Processes and Procedures..........................................................................................................................................10
Adaptation and Disaggregation.................................................................................................................................10
Infrastructure Layer...................................................................................................................................................11
Repository............................................................................................................................................................. 11
Data Self-Protection (Content)..............................................................................................................................11
Applications.......................................................................................................................................................... 12
Systems................................................................................................................................................................. 12
Identity and Access Layer.....................................................................................................................................13
Perimeter Layer.....................................................................................................................................................14
Surety of Protection.................................................................................................................................................. 14
Future Developments.................................................................................................................................................... 16
Evaluation Criteria........................................................................................................................................................ 17
Statement & Basis for Position..................................................................................................................................... 19
Data at Rest Position................................................................................................................................................. 19
Establish an IT security baseline...........................................................................................................................19
Protect the data itself.............................................................................................................................................20
Protect at the application layer..............................................................................................................................21
Use repository protections.................................................................................................................................... 21
Use a change control system................................................................................................................................. 21
Use audit and monitoring processes......................................................................................................................21
Data in Motion Position............................................................................................................................................ 21
Protect the data itself.............................................................................................................................................22
Ignore the missing element................................................................................................................................... 22
Use acknowledgments...........................................................................................................................................23
Use sequencing to detect missing elements.......................................................................................................... 23
Data in Use Position..................................................................................................................................................23
Use application layer mechanisms........................................................................................................................ 23
Data Self-Protection Position....................................................................................................................................23
Use procedural controls, transfer, or avoid the risk.............................................................................................. 24
Use a transform..................................................................................................................................................... 24
Consider accepting the risk................................................................................................................................... 24
Application Layer Protection Position...................................................................................................................... 24
The application should apply separation of duties through its design and functions............................................24
Attempt to disaggregate the information and use procedures to reduce the consequences to medium or low.....
25
Use additional testing to validate the proper operation of the application and log all actions............................. 25
Log all actions....................................................................................................................................................... 25
Slowly Changing Unstructured Data at Rest Position.............................................................................................. 25
26
Use transforms to detect an unauthorized change and react as necessary............................................................ 26
Periodically replace the data with a known good version.....................................................................................26
Accept 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.............................................................................................27

27
Audit and detect problems off line........................................................................................................................27
Accept the risk...................................................................................................................................................... 28
Relationship to Other Components............................................................................................................................... 29
Revision History........................................................................................................................................................... 30
Notes............................................................................................................................................................................. 31
Author Bio ....................................................................................................................................................................32
4
Statement of Problem
What technical approaches should organizations use to protect the integrity of electronic information in the
resource 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 and
external consistency. Verifying that the information actually reflects the reality of the real world is outside the
scope of this Technical Position. For Burton Group's short definition of integrity and a detailed discussion of
integrity and other security objectives, see the Security and Risk Management overviews, Concepts and
Definitions 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, the
information used in transactions and the configurations of hosts, applications, and network devices must be free
from unauthorized or inappropriate modifications. Information reported to various regulatory agencies and to
stockholders, employees, customers, and partners must also be free from unauthorized modifications. Such
changes to information can have a range of consequences from simple embarrassment or minor outages to
regulatory penalties or even incarceration for senior executives. Successful theft or fraud perpetrated against the
organization may also have its roots in the unauthorized modification of information which is then used to process
transactions. In fact, it was the potential for fraud that led to the use of certain accounting procedures (such as
double entry bookkeeping and separation of duties between those who can authorize a financial transaction and
those who actually execute it).
Protecting business information such as accounting data is only one aspect of integrity that enterprises should be
concerned with. The other primary aspect of integrity is that of host and network device configurations. Although
configurations seem to be different from electronic information on the surface, they are, in reality, just another set
of informationalbeit with a different purpose. The integrity of configuration information is then also covered
under the requirements and alternatives discussed in this Technical Position. It should be noted, however, that the
integrity of configuration information is also discussed to a greater depth of detail in the following Reference
Architecture 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 respond
to inappropriate modification or deletion of electronic information at rest, in motion, and in use. The requirements
for 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 Data

Data is the representation of information within an information technology (IT) environment. Data may not be
useful to the business until it is interpreted into some other form (for example, as text that can be read and
understood by a user). However, it is the data that must be protected from unauthorized modification. Data can be
at 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 is
stored on a hard disk.
Data in motion: Data that is moving from one place to another, such as when data is transmitted across a
network.
Data in use: Data that is being processed by some application or transaction procedure.
6
Maintain Integrity Throughout the Information Lifecycle

Information 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, or
transmitted
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 to
validate that the information does, in fact, reflect the business or the observed reality. When information is
destroyed, it may be necessary to verify that it was, in fact, destroyed and not removed to some other location (but
this 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 how
integrity 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 protection
that is required will likely depend on the consequences of a violation of integrity for that set of information.
Enterprise Policy
7
Translating the business requirements for integrity (as they are embodied in various business processes) into the
IT 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 systems
should 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 writing
it to a high-integrity file. Unfortunately, though this model is relatively simple, it does not reflect business
requirements.
A more appropriate policy was defined in 1987 by David Clark and David Wilson.3 This model put forward the
certification (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 of
the assurance levels associated with the rules. Different levels of consequence associated with failures in integrity
may place different testing, development, or functionality requirements on the mechanisms deployed within a
system. The policy also does not consider information that is transmitted outside of the organization or the
concept 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 the
solution for information integrity. This means that the requirements for preventing unauthorized modification and
for detecting such a modification when it occurs will extend into mechanisms that prevent unauthorized access to
systems and information. Control will also have to be extended over administrators and other privileged users
who may have the ability to modify information outside of normal transformation procedures.
Infrastructure Surety
8
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 driven
by the risk the organization faces. High-risk (or -consequence) situations should require high-surety control
mechanisms so that the risk is properly managed. Low-risk situations can be managed by low-, medium-, or highsurety controls, but the costs associated with the medium- and high-surety controls usually cause organizations to
use those of low surety. More information about the surety of mechanisms can be found in the Security and Risk
Management 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 of
information on a website may not need to be protected, the integrity of that information may be very important to
the 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 Risk
Management Strategies report, Risk Management: Concepts and Frameworks.
Manage Integrity in Context

Integrity must be managed in the context of the intended use of the information. In some cases, it may be more
important to make information and collaborative processes with fast turnaround times available than it is to
protect the integrity of the information. Strong change control, otherwise a good way to protect information
integrity, 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 to
keep them from causing severe consequences to the business. For example, accounting procedures have been
developed so that no single person can perpetrate fraud without risk of discovery. Double entry bookkeeping was
developed so that mistakes can be identified when financial records are reconciled. The integrity of each part of
the transaction may be acceptable, but in the case of financial transactions, it is the integrity of the transaction as a
whole 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, the
surrounding processes will be essential to identifying integrity violations and therefore no organization can expect
technology to solve the problem of information integrity alone.
Protect Each Set of Information Appropriately

A 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
Alternatives
Integrity is similar to, but not the same as, confidentiality. While many of the same mechanisms can be used to
protect both integrity and confidentiality, in some cases, the mechanisms used to protect integrity may be at odds
with the need to protect confidentiality. Detailed positions on confidentiality protection can be found in the
Reference 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 be
used to prevent or detect integrity violations. Rather, this Technical Position will map high-level alternatives into
categories of protection. Other Technical Positions will provide greater detail on specific technical architectures
and mechanisms that can be used to provide the protection. For example, perimeter controls can be used to
prevent unauthorized access to protected information but the details of perimeter controls are discussed in the
Reference Architecture Technical Position, Perimeters and Zones.
Many mechanisms exist to provide integrity protection for information that is in physical form. Many of these
mechanisms fall into the category of processes and procedures discussed in the next section. However, the
protection 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 information
requiring integrity protection. For each set, its state (i.e., at rest, in motion, in use) is determined and the reader
uses that position as the starting point. Working through the initial positions may take the reader to additional
positions 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. On
the contrary, where possible, a layered approach is typically preferred so that there is some amount of defense in
depth.
Processes and Procedures

Business processes and procedures provide much in the way of integrity protection. As mentioned in the Typical
Requirements section of this Technical Position, such procedures as double entry bookkeeping can be used to
identify 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. Twoperson 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 control
can 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 to
various sets of information.
Adaptation and Disaggregation

Managing high-risk situations properly is critical to any organization since the consequences associated with high
risk include the complete failure of the business or the loss of life. Technical controls are rarely sufficient by
themselves to properly manage the risk of high-consequence situations and therefore organizations must either
use 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 an
integrity 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 two
results, and then have a two-person team configure the device while another two-person team verifies the correct
configuration has, in fact, been obtained.
10
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 it
more difficult for an intentional or accidental action to modify all copies of the information while at the same time
making it easier to compare the copies to identify that a modification has been made. Of course, distributing
information to multiple locations may impact the confidentiality of the information and may actually conflict with
confidentiality requirements calling for the physical separation of the information. Here is a case where
mechanisms 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 or
more information sets. For example, concerned that an integrity failure of its auctions database would doom its
business, an online auction site could create multiple independent auctions databases. Such disaggregation
reduces the benefits of centralization and may increase complexity, especially if the databases must appear to
support a single seamless application and be able to exchange data with one another. For a general discussion of
risk disaggregation, see the Security and Risk Management Strategies overview, Risk Aggregation: The
Unintended Consequence.
Infrastructure Layer
The layers at which integrity protection can be deployed correspond to the layers described in the Reference
Architecture 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 protection
for both structured and unstructured data at rest. Files are checked into the repository and it controls who is
allowed to access the files. Although repositories are often considered controls for confidentiality, they can also
provide protection for integrity. The repository can control who is authorized to update a file and can also log all
access and changes and provide rollback capability.
Historically, repositories were only used for high-value data, primarily due to the cost of the repository products
and the impact they had on the normal work of employees. However, this is changing with the cost of these
products 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 is
carried along with the data. Data that is being transmitted between systems or facilities cannot be protected by
mechanisms within those systems or facilities. Data that has been sent to another organization is also outside the
control 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 enterprise
rights management (ERM) products. However, it should be noted that encryption algorithms can be used to
enforce integrity protection without enforcing confidentiality. For example, a cryptographic checksum can be
used 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 the
application that uses the data.
Related Reference Architecture components include:
Encryption (Technical Position)
Relevant Security and Risk Management Strategies research documents include:
11
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 information
integrity 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 (thereby
determining if some type of acknowledgment or sequencing mechanism must be used). Audio and video
transmission is an example of data that can sustain the loss of small amounts of information. In fact, in that
example, 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 developed
properly. The surety associated with an application must match the risk level of the function performed and of the
data being processed unless compensated for by other controls. The surety required will impact the testing and
validation 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 is
prevented, modifications cannot be made to protected information. Preventative controls include such things as
antivirus software, host intrusion prevention system (HIPS) products, system firewalls, and various types of data
encryption 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
Detection mechanisms on systems focus on detecting and correcting unauthorized changes to system
configurations. These mechanisms generally fit into the vulnerability management category, but this category has
expanded to include policy and configuration management products. To some extent, these products are also
preventative in nature as the proper configuration of the system prevents unauthorized access attempts from
succeeding.
Generally, all system protection mechanisms are low surety as they rely on the operating system to not subvert the
security mechanism. Encryption products may achieve medium surety if the algorithm is vetted and the
implementation is properly tested. But even here, the encryption software must run under the operating system so
medium surety is still difficult to achieve without some type of hardware component. Increasing the security
provided 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, and
applications 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 another
boundary (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 from
performing unauthorized actions. Preventative mechanisms at the system and perimeter layer tend to be focused
on unauthorized users attempting to gain access by circumventing the user authentication and authorization
mechanisms.
Authentication and authorization mechanisms are covered by Burton Group's Identity and Privacy Management
Strategies service.
Related Identity and Privacy Management Strategies Reference Architecture components include:
User Authentication (Technical Position)
User Authorization (Technical Position)
Roles (Technical Position)
13
Identity Auditing (Technical Position)
Perimeter Layer
The perimeter layer provides preventative integrity protections in that the deployment of perimeter mechanisms
prevents unauthorized users from gaining access to systems and information. In a number of cases (such as
information provided on a website), preventative controls focus not so much on preventing information from
being accessed, but rather on preventing unauthorized users from gaining write access (i.e., the ability to make a
change) 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 response
systems (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 untrusted
networks. The VPNs may be implemented as part of the perimeter layer. It should be noted that information can
also 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-surety
mechanism to protect information. However, separation does not have the same utility for integrity as it does for
confidentiality; therefore, it is less likely to prove valuable because information may need to be read even when
writing 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 Protection
The surety of protection should be matched to the risk associated with an integrity violation. The vast majority of
technical 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 devices
and system components. The surety of applications is related to the development process and to the testing that
the application undergoes. It should be stressed that security testing (i.e., testing to determine that no fault exists
that will allow unauthorized transactions to occur) is significantly different and more resource intensive than
functional testing (i.e., testing that certain functions work as required and designed).
14
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 filter
detects 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 can
be used to prevent unauthorized modification by limiting access to information or to detect that a modification
has been made.
Separation: Separation may (with the proper procedures) provide a high-surety mechanism that can be used to
prevent an unauthorized modification. However, separation may not be possible in cases where the protected
information 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 Management
Strategies overview, Surety Ratings of Security Mechanisms for Architecture Planning.
15
Future Developments
While the future developments of specific technologies and mechanisms are considered in Reference Architecture
Technical Positions specifically devoted to those technologies and mechanisms, some larger issues and changes
are 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 on
protecting information from unauthorized disclosure. While this protection has also prevented many types of
unauthorized modification from taking place (if I can't see it, I can't change it), integrity protection is becoming
more of an issue. Recent regulatory changes that require executives to sign off on financial statements or that have
changed how information is disclosed during legal procedures have increased the requirements for information
integrity. It is likely that this trend will continue so that enterprises will need to define the integrity requirements
for information. This will likely lead to more-detailed integrity requirements for applications processing
information.
Information management systems or repositories are becoming more available and their increased use will
provide a more comprehensive environment for managing unstructured data. As the repositories become more a
part of day-to-day workflow, organizations will have a built-in ability to track how information is changed over
time.
The nature of our information is also changing. Today, there is a difference between how structured and
unstructured information are used, processed, and stored. But changes are coming as DBMSs (the traditional
home 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 that
mean that the mechanisms will be able to detect changes to the necessary level of granularity? On the other end of
the spectrum, text files (traditionally the definition of unstructured data) are becoming more structured through
the use of Extensible Markup Language (XML) tags. Perhaps this will make it easier to detect modifications and
track 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 over
cryptographic mechanisms, including those used to detect integrity violations. Matching the hardware modules
with 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 an
organization's information integrity architecture decisions through the position statements found in the next
section. 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 to
protect 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 point
is 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 need
to 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 transaction
process implemented within an application is the same as defined by the business. Business staff will need to
be 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 information
will 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 decisions
can 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 processes
will 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, if
encryption is already being used to protect information for confidentiality, then the group of users capable of
accessing the information and making a change is already reduced. The same is true for perimeter and system
controlsif 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 structured
data will tend toward applications while protection for unstructured data will tend toward repositories, the use
of transforms, or the use of logging and after-the-fact analysis.
17
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 and
surety levels required. If the loss of a small amount of information will impact the sender or receiver, some
mechanism must be deployed to detect the loss and then to cause a retransmission to occur. Applications that
are 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 detect
integrity 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 sure
the 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 Position

What 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 security
architecture will support information integrity objectives. Different mechanisms may then be used, depending on
the context surrounding each set of information. For example, the capabilities for strong identity assurance or
strong change control are available even though it may not be cost and risk effective to use them with all
information sets. The IT security baseline should include:
Proper authentication and authorization methods for all access to protected data: For all resources that
store data, identity-based controls should be employed to mediate access to the data. Authorized users should
be limited to only the functions and permissions necessary. It should be noted that for proper integrity
protection, the functions of highest concern are those associated with writing data. does not affect the integrity
of data.
Appropriate perimeter and host controls to prevent unauthorized access to protected data: Unauthorized
users will attempt to gain access to resources through abnormal paths such as exploiting vulnerabilities in
operating systems or applications. Perimeter and host controls should be used to limit the potential for such
exploitation. Such controls include deploying filtering, separation, or transforms at the perimeter and deploying
vulnerability, policy, malicious software, or configuration management systems on the host.
19
Logging of the use of administrator privileges: Administrators (system, network, and database) can bypass
normal user and application controls due to the nature of their jobs. Although it is nearly impossible to prevent
an administrator from modifying data at rest, recording the actions of the administrator and storing the records
in a protected environment to which the administrator does not have access provides a mechanism to detect the
unauthorized modification.
Proper change control to mitigate mistakes: Proper change control procedures can do much to prevent
mistakes. Change control may include mechanisms such as two-person commit sequences for transactions or
peer 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 at
rest. The protections that may be applied first depend on where the information's control point exists. The second
consideration is the type of data that is being protected. Structured data requires different types of protective
measures than unstructured data. If a repository is available, it should be used for unstructured data as repositories
provide many integrity protections. If a repository is not available, the next consideration is whether the data
changes 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 for
protecting the information from unauthorized modification may also reside outside the control of the enterprise. In
these cases, the ability to prevent unauthorized modification or to determine if the information has been modified
must 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 cases
where the rules to be applied are the same across multiple applications, it may be more appropriate to leverage
DBMS 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 to
which files. Changes and access are audited. It may also be possible to have the repository detect changes that are
made to files. While repositories have been historically limited to high-value information, the cost and impact of
repositories 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 the
attacker can gain access to the file. Simply stated, unstructured information will not need to follow the same type
of strict formatting rules that structured information must follow. Information that changes slowly can be
monitored so that any changes are detected and compared with known, authorized changes. If an unauthorized
change is detected, the appropriate reaction can be made (see the Slowly Changing Unstructured Data at Rest
position).
Or
Use audit and monitoring processes.

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

What 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 protecting
information in motion. Applications using particular information sets, whether purchased or developed, should
make 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
The protections that may be applied first depend on whether the concern is for the modification of information or
for the complete deletion of the information. Note that it may be necessary to examine both cases for some types
of information. The second consideration is whether the loss of a single element (packet or message) will
adversely impact the sender or receiver of the information. In some cases, the loss of a single packet will not
impact the communication and it is more advantageous to simply ignore the lost information. If the loss of a
single element will impact the sender or receiver, a third consideration is whether there is a path for the receiver to
notify 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, choose
only one):
Protect the data itself.

Information in motion may travel across unprotected networks or to user systems that do not have any way to
compare the information to what was originally transmitted. In these cases, the ability to prevent unauthorized
modification or to determine if the information has been modified must reside with the information. Data selfprotection technologies (such as transforms like cryptographic controls and rights management) are medium and
low surety respectively. Standing alone, they cannot mitigate high risk and must be supplemented by procedural
or other controls (see the Data Self-Protection position).
Or
Ignore the missing element.
22
In some cases (such as in the transmission of voice or video), the loss of some information does not impact the
overall operation of either the sender or the recipient of information. In fact, attempts to ask for retransmission
may adversely affect the operation of the system being used. In these cases, it is a better option to simply ignore
the missing element.
Or
Use acknowledgments.
Acknowledgments allow the recipient of information to notify the sender that the information has, in fact, been
received. If the sender does not receive an acknowledgment within some period of time, it can be assumed that the
information did not arrive as planned and the sender can retransmit the information. It should be noted that it is
also possible that the acknowledgment was lost rather than the original information and therefore the recipient
needs 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 of
acknowledgments 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, the
acknowledgment 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 is
missing. Sequence numbers do not allow the recipient to detect that the last element of a transmitted sequence is
missing unless there is also some code used to indicate the end of the information. The time it takes to detect the
loss of information is indeterminate because it is based on receipt of information out of sequence.
Data in Use Position

What 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 the
information before adverse circumstances result. The application may include transforms, such as cryptographic
checksums, hashes, and signatures. This ensures that no unauthorized modification has been made before the
application processes the information (see the Application Layer Protection position).
Data Self-Protection Position

What 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
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 data
integrity violations, but they tend to be expensive to implement. The procedural controls may include the use of a
transform to prevent or detect integrity violations but the use of the transform by itself is insufficient for highconsequence situations since the transforms are medium- or low-surety mechanisms. If the consequences of
failing to detect an integrity violation are high, transferring or avoiding the risk entirely may be more appropriate
actions. 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 only
necessary to detect and prove that the data has been modified, then a cryptographic checksum can be used and
kept 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 mechanisms
also 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 mitigation
of risk, will dictate the acceptable level of protection. It may be appropriate for the business to accept that the
information may be modified and go undetected if there are few or no consequences. Alternatively, transforms
can be used to detect a modification if the inconvenience is not too great.
Application Layer Protection Position

What 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, the
application must be properly architected and tested prior to deployment and properly maintained once in use. This
includes 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 design

and functions.
The transaction logic within the application should be created to implement the proper business procedures when
performing an action on protected information (for example, double entry bookkeeping or two-person commits
for financial transactions). Transaction logic should only be modified by individuals authorized to change
business logic. This capability is necessarily separate from the capability to modify the data. Any change to the
business logic must be verified.
24
(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 or
low
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 sensitive
information, choose only one):
Attempt to disaggregate the information and use procedures to

reduce the consequences to medium or low.
Technology alone does not offer sufficient surety to control high consequences. The information must be correct
or if it is not correct, the problem must be detected before the transaction is processed. Limiting access to the
information through physical separation would be the best option; however, if the information must be used
widely, access must be granted in such a manner that the information cannot be modified. Ideally, the information
can be divided or duplicated in such a manner as to make any single integrity violation result in lesser
consequences.
Or
Use additional testing to validate the proper operation of the

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

For any application that operates on protected information, a log should be kept of all actions. The log should
include the user who performed the action and the exact modification that was made. Logs can be used for
rollback purposes as well. The use of the logs should allow the data to be returned to a known good state. Logs
should be considered protected information so that any attempted modification of the log will be detected and
prevented. In low-surety cases, the level and volume of logging may be traded off with performance and storage
considerations.
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 following
positions are also recommended.
IF the consequences of a violation of integrity are high
low
OTHERWISE IF the consequences of a violation of integrity are medium or the cost of detection is less than the
risk
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 of
sensitive information, choose only one):

Use disaggregation when the consequences of an integrity violation are simply too severe to control with
technology alone. The information must be correct or if it is not correct, the problem must be detected. Although
limiting access to the information through physical separation would be the best option, if the information must be
used, access must be granted in such a manner that the information cannot be modified. Ideally, the information
can 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 as

necessary.
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 or
cryptographic checksums, can be used to detect changes in information. The original information is run through
the transform, which generates a unique value. At periodic times, the information is run through the transform
again 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 the
same location as the information that is to be protected. If an unauthorized change is detected, an appropriate
reaction 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
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 processing
cycles or time to perform on a regular basis. The information is relatively static and so any change to the
information can be considered to be unauthorized. Rather than perform the steps necessary to verify that the
information has or has not been changed, it may be appropriate to simply replace it with information from a
known good source. The information within the known good source must itself be properly protected from
unauthorized 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 unauthorized
modification may exist for some period of time before it is noticed through some other means.
Quickly Changing Unstructured Data at Rest Position

What 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
low
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 of
sensitive information, choose only one):

Use disaggregation when the consequences of an integrity violation are simply too severe to control with
technology alone. The information must be correct or if it is not correct, the problem must be detected. Although
limiting access to the information through physical separation would be the best option, if the information must be
used, access must be granted in such a manner that the information cannot be modified. Ideally, the information
can be divided or duplicated in such a manner as to make any single integrity violation result in lesser
consequences. Alternatively, consider the possibility of slowing down the transaction rate so that the proper
integrity 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 is
constantly changing. Static mechanisms do not work well with this type of information and so it is more
advantageous to maintain an audit trail of all changes. Using the audit trail, transactions can be recreated and
verified off line. The audit trail should identify the change that was made and the user or process that made the
change. Audit trails can be used for rollback purposes as well. The use of the audit log should allow the data to be
returned to a known good state. Of course, the audit log itself must be properly protected from unauthorized
modification. 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 the
organization to accept the risk especially in cases where there are significant costs associated with prevention and
detection mechanisms. It should be noted that the risk may be low because other mechanisms are in place to
detect an unauthorized modification (for example, business procedures).
28
Relationship to Other Components

The Reference Architecture Technical Position, Change Management with Assurance, discusses the process of
change 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 the
protection of information.
The Reference Architecture Technical Position, Host Security Choices, discusses ways of improving the
preventative capabilities of systems.
The Reference Architecture Technical Position, Information Confidentiality, discusses how organizations can
meet confidentiality requirements. In some cases, the mechanisms deployed for confidentiality protection will
also provide integrity protection. However, the two requirements may conflict in some cases.
The Reference Architecture Technical Position, Malicious Software, discusses the deployment of malicious
software control mechanisms. These mechanisms can provide some preventative protection for integrity.
The Reference Architecture Technical Position, Network Intrusion Detection and Response, discusses the
deployment of a perimeter preventative mechanism.
The Reference Architecture Technical Position, Perimeters and Zones, discusses the creation of network
perimeters 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 into
zones and therefore how much protection a perimeter may provide to a particular system.
The Reference Architecture Technical Position, Technical Security Policy Management: Mapping Intent into
Implementation, discusses the management of organizational policy on systems.
The Reference Architecture Technical Position, Vulnerability Management, discusses how an organization can
manage vulnerabilities to prevent their exploitation by unauthorized individuals.
29
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. MITRE
Corporation. 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
Author Bio
Eric Maiwald
Senior Analyst
Emphasis: Information security architecture, perimeter security, enterprise security management, infrastructure
protection, 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, and
product implementations. Also has experience as a product manager for Bluefire Security Technologies.
Primary Distinctions: Respected speaker on enterprise security topics and Certified Information Systems Security
Professional. Named inventor of several patents: "Apparatus and Method for Providing Multi-level Security for
Communications among Computers and Terminals on a Network," "Using Trusted Associations to Establish Trust
in a Computer Network," "Apparatus and Method for Providing Network Security," and "Method for Establishing
Trust in a Computer Network via Association." Author of "Network Security: A Beginner's Guide, Security
Planning and Disaster Recovery," (with William Sieglein); and "Fundamentals of Network Security," all published
by Osborne/McGraw-Hill.
32

Burton Information Integrity

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Burton Information Integrity

Hochgeladen von

Copyright:

Verfügbare Formate

Security and Risk Management Strategies

Reference Architecture Technical Position

Quickly Changing Unstructured Data at Rest Position.............................................................................................27

Host Security Choices

Maintain Integrity in All States of Data

Maintain Integrity Throughout the Information Lifecycle

Figure 1: Subset of an Information Lifecycle

Table 1: Clark-Wilson Rules

Manage Integrity in Context

Protect Each Set of Information Appropriately

Processes and Procedures

Adaptation and Disaggregation

Data Self-Protection (Content)

Cryptographic Systems Provide Foundations for Information Security (report)

User authentication and authorization

Application Security: Everybody's Problem (report)

Relevant Application Platform Strategies research documents include:

Host Security Choices (Technical Position)

Relevant Security and Risk Management Strategies research documents include:

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

Identity and Access Layer

Identity Auditing (Technical Position)

Perimeters and Zones (Technical Position)

Relevant Security and Risk Management Strategies research documents include:

Generally, protection mechanisms can be grouped into three categories:

Statement & Basis for Position

Data at Rest Position

Establish an IT security baseline.

Figure 2: Flow Chart for Initial Data at Rest Position

Protect the data itself.

Protect at the application layer.

Use repository protections.

Use a change control system.

Use audit and monitoring processes.

Data in Motion Position

Figure 3: Flow Chart for Data in Motion Position

Protect the data itself.

Ignore the missing element.

Use sequencing to detect missing elements.

Data in Use Position

Use application layer mechanisms.

Data Self-Protection Position

OTHERWISEconsider accepting the risk

Use procedural controls, transfer, or avoid the risk.

Consider accepting the risk.

Application Layer Protection Position

The application should apply separation of duties through its design

Attempt to disaggregate the information and use procedures to

Use additional testing to validate the proper operation of the

Log all actions.

Slowly Changing Unstructured Data at Rest Position

Attempt to disaggregate the information and use procedures to

Use transforms to detect an unauthorized change and react as

Periodically replace the data with a known good version.

Accept the risk.

Quickly Changing Unstructured Data at Rest Position

Attempt to disaggregate the information and use procedures to

Audit and detect problems off line.

Accept the risk.

Relationship to Other Components

Das könnte Ihnen auch gefallen