In most instances the CIA requirements are "topic specific" and so are
the implemented controls. Controls for integrity-related risks may not
even include cryptographic controls such as the ones you offered.
Example 1 - a company web site. Its content integrity is important to
company image so a "web defacing" incident is ranked pretty high in
potential business impact. The controls you will implement *may* include
signature-checking for the web pages, but that will be only a small part
of the defense mechanisms you will employ just to guard against this
integrity risk.
Example 2 - an employee in the payroll department decides to steal from
the company and uses his AUTHORIZED access to the payroll system to
alter certain data elements. Here your controls will probably include
implementing a policy for "separation of duties", or in other words, a
policy that dictates that TWO people are required to authorize certain
updates in the payroll system.
To summarize:
1. CIA levels should be based on potential business impact.
2. Your budget for mitigating a risk should be based on the level of
business impact you are mitigating.
3. You will than use the budget and implement the most cost-effective
controls for the SPECIFIC risk. Controls may vary substantially in
mitigating different risks - even if the risks are all
integrity-related.
-----Original Message-----
From: Nicolas Stampf [mailto:nicolas.stampf@gmail.com]
Sent: ה 28 אוקטובר 2004 11:07
To: security-management@securityfocus.com
Subject: Integrity metrics ?
Hello,
Considering the current thread about security classifications, I wanted
to raise an issue regarding metrics for integrity.
I've seen on the list, and elsewhere, metrics with 4 or 5 levels
regarding Integrity.
Considering that security requirements (C, I and A), need, in the end,
to turn into security functionalities like access control,
authentication, signatures, etc.; there needs to be some sort of
relation between the initial requirements metrics and the technologies
for ensuring the requirements are fulfilled.
Given this, if we consider, say, confidentiality, we can map levels with
technologies, such as, for instance: C=0 => nothing (no requirement) C=1
=> access control lists (DAC) C=2 => ACL (MAC) C=3 => ACL + crypto 128
bits C=4 => ACL + crypto 256 bits
How would you do the same thing for integrity?
I came up with something such as:
I=0 => nothing
I=1 => checksum or hash (protection against errors)
I=2 => signature (protection against deliberate attacks)
and that's all. No other levels.
I can't see how other levels than these 3 (counting 0) could exist and
to what kind of technologies/practices or processes they could map.
Any thoughts, someone ?
Regards,
--
Nicolas STAMPF
http://www.ActuSecu.info
