184 ◾ Security Strategy: From Requirements to Reality
Complete
Audit records must contain all the information required to prove compliance with applicable
statutory, regulatory, and industry requirements; this includes at a minimum:
e identity of the subject taking the action ◾
e name (identity) of the object being acted upon ◾
e action being taken ◾
e result or status of the action (success, failure) ◾
e old value and the new value (if the object was created, deleted, or otherwise changed) ◾
Possible actions include:
Mapping existing control objectives to evidentiary requirements ◾
Identifying gaps between existing audit capabilities at all levels (network, host, service/appli- ◾
cation, etc.)
Table 10.7 Audit Requirements for Accountability
Attribute/Control Type Risk and Requirements
Suffi cient
Domain and local
audit management
Soft Records must be collected across all domains and systems.
Comprehensive Soft It is possible to collect audit information for all objects that
can be acted upon, including infrastructure components,
systems, and applications.
Complete Hard Audit records must contain all the elements required to
prove accountability.
Temporal Hard Records must be associated with a global time source.
Quality
Consistent Soft Records have a common format across all objects.
Relevant Hard The information collected supports all associated
compliance and legal claims.
Understandable Soft The information in the record is easy to assimilate.
Simple Hard The records do not contain extraneous content.
Sequential Hard The records are in chronological order.
Correlated Soft The relationship between the records is apparent.
Authentic
Tamperproof Hard The records have not been altered from their original state.
Traceable Hard The records have a consistent chain of custody.
Retained Soft The records are retained for a suffi cient time frame.
TAF-K11348-10-0301-C010.indd 184TAF-K11348-10-0301-C010.indd 184 8/18/10 3:10:35 PM8/18/10 3:10:35 PM
Trust but Verify (Accountability) ◾ 185
Updating existing security standards to refl ect evidentiary auditing requirements ◾
Updating procedures and standards to refl ect evidentiary auditing requirements ◾
Promoting company and industry changes that will improve and unify auditing capabilities ◾
supporting accountability
Temporal
Records must be date and time stamped using a global time source so that they can be accurately
associated with other activities that occurred within the same time frame. Possible actions sup-
porting this objective include:
Ensuring that security standards require audit records to be date and time stamped based on ◾
a common global time source
Reviewing existing audit functions and identifying all instances of audit facilities that do ◾
not meet the above requirement
Updating procedures and standards to refl ect temporal auditing requirements supporting ◾
accountability
Consistent
e quality of audit records is highly dependent on the format of the data contents. is is one
of the major issues associated with existing logging facilities; they are written in so many dif-
ferent formats that correlating information across platforms, services, and applications is nearly
impossible. e SYSLOG facility is an excellent example. Although the records have well-defi ned
fi elds, the information in those fi elds does not have a common format. Consequently, correlating
SYSLOG records requires additional parsing. e Windows 2008 logging facility improves on
record consistency somewhat by providing an XML-based record parser. However, the facility
does not contain a standard naming convention for defi ning the XML content. Possible actions
supporting this objective include:
Developing a common taxonomy for the data content fi eld within audit records that includes ◾
at a minimum consistent naming for the data elements in the “Complete” section above
Ensuring that security standards require the use of the common taxonomy for all audit ◾
records
Updating procedures to specify the use of a common auditing taxonomy supporting ◾
accountability
Promoting company and industry changes to improve and unify auditing capabilities sup- ◾
porting accountability
Relevant
Complete records contain the relevant information needed to prove a fact or claim. e relevant
attribute actually relates to the other information contained in the record. It is possible for a record
to contain so much information that it is nearly impossible to discern what is relevant to the fact
or claim. e use of progressive logging controls is one way to ensure that extraneous information
does not dilute the relevance of the record. Progressive logging establishes levels of logging based
on the nested levels of application calls. For example, level 1 logging would only capture events
TAF-K11348-10-0301-C010.indd 185TAF-K11348-10-0301-C010.indd 185 8/18/10 3:10:35 PM8/18/10 3:10:35 PM
186 ◾ Security Strategy: From Requirements to Reality
related to the entry point and main application procedure, level 2 would capture events for the
methods and the main procedure call, level 3 for methods, level 2 calls, and so on. Possible actions
supporting this objective include:
Developing guidance for the development team on the use of progressive logging ◾
techniques
Updating procedures and development standards with auditing relevance guidance ◾
Understandable
e information contained in each record should be presented in such a way that a reasonably
intelligent person would be able to read and understand it. Audit records written for troubleshoot-
ing purposes often contain information that is only meaningful to the developer or a service
technician. For accountability purposes, the information in the record must be understandable by
the average person. us, when codes are used, they should be accompanied by a verbal explana-
tion. For example, “ e call returned 1 (Successful).” Possible actions supporting this objective
include:
Ensuring that standards require audit records to be constructed so that they can be easily ◾
assimilated by an average person
Reviewing existing audit functions and identifying all instances of audit facilities that do ◾
not meet the above requirement
Updating procedures and development standards to refl ect the understandable auditing ◾
attribute supporting accountability
Simple
Records are designed to convey one or two pieces of information. e more complex a record is,
the more diffi cult it is to understand or to explain. Records that use the same event code to convey
diff erent pieces of information are particularly troublesome because the information conveyed in
the description fi eld must be parsed to fi gure out which piece of information this record refers to.
Microsoft IPSec events logs are a great example. During negotiation, if the connection falls back to
a clear (non-IPSec protected) connection, the event number will be the same as any clear connec-
tions. e only way to determine whether the clear connection was the result of a fallback to clear
action is to parse the information in the description fi eld of the record. Possible actions supporting
this objective include:
Developing guidance on the use of simple logging techniques ◾
Updating procedures and development standards with auditing simplicity guidance ◾
Sequential
e order of the records is the same as the order of the events. Record sequence is seldom an issue
on a single host. e issue comes into play when records are being centrally collected and pro-
cessed. ere is a potential for the records to get out of order and thereby paint a faulty picture of
what actually took place. For example, Alice accesses and changes a record; then Bob accesses and
TAF-K11348-10-0301-C010.indd 186TAF-K11348-10-0301-C010.indd 186 8/18/10 3:10:35 PM8/18/10 3:10:35 PM
Trust but Verify (Accountability) ◾ 187
reads the record. If these records are misordered in the audit collection system, it would appear as
if Bob was the one making the change. Possible actions supporting this objective include:
Reviewing existing audit functions and collection technology to ensure that records are ◾
ordered the same as the events. e ability to index records by the date and time stamp is
suffi cient to meet this requirement.
Updating procedures and development standards to refl ect sequential auditing requirements ◾
supporting accountability.
Correlated
When multiple records from the same or diff erent sources are used to support a fact or claim, the
relationship between the information in these records must be obvious. is is one of the driving
forces behind a common taxonomy. It is important to keep the “average person” scenario in mind;
labeling the same piece of information with two diff erent names will make it more diffi cult for the
average person to understand the evidence being presented and may cause them to come to the
wrong conclusion. Possible actions supporting this objective include:
Reviewing existing audit functions across all platforms to ensure that records contain infor- ◾
mation that is consistent in content and format so that it can be easily correlated with
records from other platforms
Updating procedures and development standards to refl ect correlation auditing require- ◾
ments supporting accountability
Tamperproof
is attribute, together with the next two, are related to the admissibility of records. A tamper-
proof record is one that cannot be altered from its original state without the alteration being
detected. If a record can be tampered with, it can be argued that the information contained
therein is not reliable. Two mechanisms are commonly used to ensure tamperproof records: access
controls and integrity controls. Privileged use creates issues with the access control approach; that
is, a person with suffi cient privilege can tamper with the records. Sending events to a centralized
log server can resolve this issue provided the privileged use does not extend to this server as well.
However, integrity controls such as digital signatures or record hashing is much more diffi cult to
defeat. e records can be erased, but they cannot be altered without detection. Possible actions
supporting this objective include:
Ensuring that security standards require audit records to be tamperproof ◾
Reviewing existing audit functions and identifying all instances of audit facilities that do ◾
not meet the above requirement
Updating procedures and development standards to refl ect the tamperproof auditing attri- ◾
bute supporting accountability
Traceable
It is also necessary to ensure that a verifi able chain of custody is maintained for each record.
Traceable means that looking backward we can account for all entities that have control over or
TAF-K11348-10-0301-C010.indd 187TAF-K11348-10-0301-C010.indd 187 8/18/10 3:10:35 PM8/18/10 3:10:35 PM
188 ◾ Security Strategy: From Requirements to Reality
access to this record from the time of its creation. Any point in time when control over the record
cannot be accounted for means it could have been replaced or otherwise tampered with; such a
record is therefore unreliable. Possible actions supporting this objective include:
Reviewing existing audit procedures to ensure that audit records required for accountability ◾
have a management process that maintains a viable chain of custody
Updating operational procedures to refl ect traceability auditing requirements supporting ◾
accountability
Retained
Large computing environments generate large volumes of audit information that quickly becomes
impossible to manage. At the same time, not having the necessary evidence to prove compliance
with legal, regulatory, and industry requirements can be a major liability. ere must be a balance.
At the very least, audit records must be retained long enough to be duplicated (i.e., backed up).
Second, they must be maintained for as long as legal and/or regulator actions are possible. Possible
actions supporting this objective include:
Reviewing existing audit facilities to ensure that accountability-related audit records are ◾
being retained for a period commensurate with legal and/or regulatory requirements
Updating operational procedures and standards to refl ect retention auditing requirements ◾
supporting accountability
Conclusion
e accountability tactic is not easy to fully implement with today’s technology, but good account-
ability controls give you the ability to defend against accusations of malfeasance or negligence sur-
rounding an unauthorized disclosure or loss of data.
e ancient Romans had a tradition: whenever one of their engineers constructed an
arch, as the capstone was hoisted into place, the engineer assumed accountability for
his work in the most profound way possible: he stood under the arch.
Michael Armstrong
Accountability controls are also a way to prove compliance with regulatory requirements, thus
avoiding regulatory sanctions for alleged violations. Similarly, accountability controls help resolve
contract and/or service delivery disputes by providing a chronological record of what was done,
by whom, and at what time. Finally, accountability controls are a strong deterrent against “insider
threats” because the actions of highly trusted individuals (i.e., administrators and other privileged
users) are monitored to ensure they are not violating that trust. For large companies and service
providers, properly implemented accountability is a huge market diff erentiator. Eff ective account-
ability begins with an understanding of the problem and what needs to be done; hopefully, this
section provides a good start down that path.
TAF-K11348-10-0301-C010.indd 188TAF-K11348-10-0301-C010.indd 188 8/18/10 3:10:35 PM8/18/10 3:10:35 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.