Integrity Requirements
An
integrity requirement is any
security requirement that
specifies a required amount of integrity, which is a
quality factor that is defined as follows:
- Integrity
- 1)
adj.[quality factor] the degree to which
communications or [data, hardware, or software] components are
protected from intentional corruption (e.g., via unauthorized
creation, modification, deletion, or replay).
- 2)
n. the means by which communication and components are
protected from intentional corruption.
The typical objectives of an integrity requirement are to:
- Prevent unauthorized individuals and programs from
corrupting communications, data, or programs.
- Thereby ensure that these can be trusted.
Integrity requirements are typically specified in terms of the
following measurements:
- Maximum percentage of data files/records corrupted per unit
time.
- Maximum percentage of messages corrupted.
- Maximum percentage of programs corrupted per unit
time.
This section includes reusable templates for producing
integrity requirements as well as corresponding example integrity
requirements taken from the Global Personal Marketplace (GPM)
system, a fictional international Web-based marketplace bringing
together private individuals and small companies to buy and sell
all manner of items.
- Template:
“The application shall protect the data it
transmits from [unsophisticated / sophisticated] attack
involving unauthorized addition, modification, deletion, or
replay when it transmits the data during execution of [a set of
interactions / use cases] in [specified table].”
- [Table of interactions / use cases versus percentage of
protected transmissions].
- Example:
“The Global Personal Marketplace (GPM) system shall
protect the data it transmits from unsophisticated attack
involving unauthorized addition, modification, deletion, or
replay when it transmits the data during execution of the Buyer
use cases as indicated in table 1.”
- Table 1:
Global Personal Marketplace (GPM)
Buyer Use Cases
|
Minimum
Transmissions
Protected
from Corruption
|
|
GPM Notifies Buyer of Acceptance of
Sealed Offer
|
99.9%
|
|
GPM Notifies Buyer of Being
Outbid
|
99.9%
|
|
GPM Notifies Buyer of Canceled
Sale
|
99.9%
|
|
GPM Notifies Buyer of Relevant
Sale
|
99.9%
|
|
GPM Notifies Winning Buyer of
Auction Results
|
99.99%
|
- Template:
“The application shall protect the communicated
data it receives from [unsophisticated / sophisticated] attack
involving unauthorized addition, modification, deletion, or
replay during execution of [a set of interactions / use cases]
as indicated in [specified table].”
- [Table of interactions / use cases versus percentage of
protected transmissions].
- Example:
“The Global Personal Marketplace (GPM) system shall
protect the communicated data it receives from unsophisticated
attack involving unauthorized addition, modification, deletion,
or replay during execution of the Buyer use cases as indicated
in table 2.”
- Template:
“The application shall determine if communicated
data it receives has been modified, if additional data has been
added to it, if some protected data has been deleted, and if
any protected data has been replayed during execution of [a set
of interactions / use cases] when subject to [unsophisticated /
sophisticated] attack as indicated in [specified table].”
- [Table of interactions / use cases versus percentage of
corrupted transmissions detected].
- Example:
“The Global Personal Marketplace (GPM) system shall
determine if communicated data it receives has been modified,
if additional data has been added to it, if some protected data
has been deleted, and if any protected data has been replayed
during execution of the following Buyer use cases when subject
to unsophisticated attack as indicated in table 2.”
- Template:
“The application shall perform [list of
application-specific actions] within [time limit] if
communicated data it receives has been modified, if additional
data has been added to it, if some protected data has been
deleted, and if any protected data has been replayed during
execution of [a set of interactions / use cases] when subject
to [unsophisticated / sophisticated] attack as indicated in
[specified table].”
- [Table of interactions / use cases versus percentage of
corrupted transmissions responded to].
- Example:
“The Global Personal Marketplace (GPM) system shall
notify the security team within 5 minutes if communicated data
it receives has been modified, if additional data has been
added to it, if some protected data has been deleted, and if
any protected data has been replayed during execution of the
following Buyer use cases when subject to unsophisticated
attack as indicated in table 2.”
Global Personal Marketplace (GPM)
Buyer Use Cases
|
Minimum
Corrupted
Transmissions
Prevented
|
Minimum
Corrupted
Transmissions
Detected
|
Minimum
Corrupted
Transmissions
Notified
|
|
Buyer Buys Item at Direct Sale
|
99.99%
|
99.9%
|
99.9%
|
|
Buyer Modifies Bid on Item
|
99.99%
|
99.9%
|
99.9%
|
|
Buyer Modifies Sealed Offer
|
99.99%
|
99.9%
|
99.9%
|
|
Buyer Places Bid on Item
|
99.99%
|
99.9%
|
99.9%
|
|
Buyer Places Sealed Offer at Decreasing
Price Sale
|
99.99%
|
99.9%
|
99.9%
|
|
Buyer Reads Buyer Guidelines
|
99%
|
99%
|
99%
|
|
Buyer Registers Feedback about
Seller
|
99.99%
|
99.9%
|
99.9%
|
|
Buyer Registers For Notification Of
Future Sales
|
99.9%
|
99.9%
|
99.9%
|
|
Buyer Reviews Personal History
|
99.99%
|
99.9%
|
99.9%
|
|
Buyer Reviews Seller Feedback
History
|
99.9%
|
99.9%
|
99.9%
|
|
Buyer Searches For Items
|
99.9%
|
99.9%
|
99.9%
|
- Protect Stored Data.
“At least [a percentage such as 99.99]% of the
time, the application shall protect the following data it
stores from unauthorized addition, modification, or deletion:
- [List of application-specific data].”
- Detect Stored Data Corruption.
“At least [a percentage such as 99.99]% of the
time, the application shall be able to determine if the
following stored data has been modified without authorization,
if additional data has been added without authorization, or if
some or all data has been deleted without authorization:
- [List of application-specific data].”
- Stored Data Corruption Response.
“When the application determines that stored data
has been modified without authorization, that additional data
has been added without authorization, or that some data has
been deleted without authorization, then the application shall
[list of application-specific actions].”
Persistent Data— “The GPM shall
protect a minimum of 99.999% of its persistent data from
unauthorized intentional corruption including:
- Account Information
- Accounting Information
- Feedback Information
- Transaction Information
- Sale Information
- Security Information
- User Inquiry Information
- Protect Programs.
“At least [a percentage such as 99.99]% of the
time, the application shall protect its programs from
unauthorized addition, modification, or deletion.”
- Detect Program Corruption.
“At least [a percentage such as 99.99]% of the
time, the application shall be able to determine if programs
have been modified, if new programs have been added, or if
programs have been deleted.”
- Program Corruption Response.
“When the application determines that a program has
been modified without authorization, that additional programs
have been added without authorization, or that some programs
have been deleted without authorization, then the application
shall [list of application-specific actions].”
The following guidelines have been found to be useful when
producing integrity requirements:
- The scope of an integrity requirement can be:
- Integrity requirements can be identified and specified in
term of the following:
| Component of
Requirement |
Possibile Values |
| Target of Corruption |
Message
Persistant Data
Program |
| Corruption Type |
Addition
Deletion
Modification
Replay |
| State |
Normal Processing
Degraded Mode
Under Attack |
| Measurement |
Maximum number corrupted per unit time
Maximum percentage corrupted per unit time
Maximum percentage corrupted per attack. |
- A potential problem with integrity requirements is that
each individual communication, stored datum, etc. could require
its own individual level of protection from corruption. While
this is actually never occurs, the opposite end of the spectrum
in which all communication and data require the same level of
protection is also too simplistic. It is up the the
requirements team working with the security team to identify a
reasonable way to express the common levels of protection
required. It may be to provide a standard default level of
integrity and then to explicitly specify only the
communications and data the require a different level of
protection.
- Integrity requirements associated with communication can be
specified as annotations to the associated functional
requirements (e.g., use cases), whereas integrity requirements
associated with data, hardware, and software components can be
analyzed and specified using security use cases.
- Integrity requirements are similar to correctness
requirements in that data that has lost its integrity (i.e.,
has been corrupted) is no longer correct. However, integrity
deals with malicious corruption whereas correctness deals with
accidental corruption (e.g., due to sensor inaccuracy or
program error).
- Use
misuse cases to perform security
threat analysis and
security use
cases to analyze and specify security requirements.
- Integrity requirements should
not be specified in terms of the types of
security architecture mechanisms that are typically used to
implement them:
- Cryptography
- The use of hash codes