169
10Chapter
Trust but Verify
(Accountability)
Trust but verify.
President Ronald Reagan
Introduction
Accountability is the ultimate observation tactic.
Accountability ensures that actions taken on a system can be traced back to the individual
or individuals who performed those actions. is is a huge deterrent against illicit activities and
false claims. Properly executed, accountability makes it nearly impossible for someone to deny
he performed a specifi c action or, conversely, to accuse others of doing something they did not
do. Accountability can also support rapid response by detecting illicit activities, alerting security
personnel, and taking preventative actions to stop or limit those activities. Accountability provides
evidence of compliance to statutory, regulatory and contractual requirements, tracks the usage
and distribution of intellectual property, and can be a signifi cant market diff erentiator for organi-
zations that do it properly. is chapter sets forth the control objectives for accountability and sug-
gests ways in which these objectives can be achieved within various types of computing enclaves.
Unmatched Value of Accountability
e accountability tactic provides a number of important benefi ts that are applicable to most com-
puting environments. e fi rst is unprecedented observation. e tactic is based on two principal
factors: (1) the collection and preservation of evidence and (2) the association of that evidence
with the identity performing the action. is is a huge deterrent against insider threats or, for that
matter, malfeasance in general. e premise behind observation is that people are not inclined
to do something wrong if they believe someone will see them doing it (i.e., they will get caught).
TAF-K11348-10-0301-C010.indd 169TAF-K11348-10-0301-C010.indd 169 8/18/10 3:10:33 PM8/18/10 3:10:33 PM
170 ◾ Security Strategy: From Requirements to Reality
Accountability means you are going to get caught because accountability creates an irrefutable
record of what was done under each account. Accountability means the answer to the “Does any-
one know it?” question in Figure 10.1 is always YES! is is especially valuable for highly trusted
(privileged) accounts; it provides a means to ensure that trust is not violated.
All computing environments require users with privileged access to build, confi gure, adminis-
ter, and maintain systems and applications. e best access controls and administrative procedures
will never eliminate the need for these users; at best, these controls can only limit who gets these
privileges and where they are allowed to use them. An accountability control cannot stop a privi-
leged user from performing a deliberate act of malfeasance, but it will certainly make them think
twice because there is no avoiding the consequences.
e second benefi t is compliance. Accountability ensures the proper collection and preserva-
tion of all the necessary information to satisfy legal, regulatory, industrial, and other external
audits. e current regulatory and legal environment makes the retention of customer data a risky
Does it work?
Yes
Yes
Yes
Yes
Yes
ere is
no
problem
No
No
No
No
No
Don’t mess
with it
Hide it
Did you mess
with it?
Does anyone
know it?
You poor
idiot
Can you blame
someone else?
Trash it
Will you
catch hell?
at was
stupid!
Figure 10.1 Problem-solving fl owchart.
TAF-K11348-10-0301-C010.indd 170TAF-K11348-10-0301-C010.indd 170 8/18/10 3:10:33 PM8/18/10 3:10:33 PM
Trust but Verify (Accountability) ◾ 171
business. According to a Ponemon Institute study in 2007, data breach incidents cost companies
$197 per compromised customer record, but this fi gure only accounts for notifi cation and restora-
tion costs; it does not include lost business opportunity, regulatory fi nes, or customer lawsuits that
drive the costs even higher. For large organizations and service providers these are billion dollar
fi gures. Accountability makes it possible to prove compliance and is designed to provide suffi cient
admissible evidence to ward off criminal or civil claims of negligence or malfeasance. Similarly,
accountability aids in the resolution of contract and/or service delivery disputes by providing a
chronological record of what was done, by whom, and when.
ird, accountability facilitates rapid response through the detection of illicit activities such as
logging on with a generic (e.g., guest) account or using a service account for an interactive log-on,
and the generation of alerts to security operations personnel. is is not limited to log-on events
because accountability can track virtually any type of user action; it can be confi gured to detect
all types of questionable behaviors, for example, database queries that return inordinately large
amounts of data. In this instance, the accountability control could also be confi gured to take pre-
ventative action by limiting the number of records returned or by “fi lling” the returned data with
randomly generated records. e accountability information collected also helps to focus response
eff orts by providing system and account specifi c records, as well as chronological records of all
actions leading up to the alert and all subsequent actions.
A fourth benefi t of accountability is intellectual property control. Accountability protects
against intellectual property loss by tracking what individuals were in possession of any particular
piece of information at the time it was compromised. is makes it possible to hold those indi-
viduals responsible for the breach and to take corrective action to reduce the likelihood of future
disclosure.
e fi nal benefi t of accountability, especially for organizations that deal with fi nancial and
other sensitive data and for service providers, is marketing. Accountability is a huge market diff er-
entiator. Few organizations have the ability to provide high levels of accountability, yet in today’s
compliance-heavy climate there is a need to account for handling sensitive customer data. e
ability to show potential customers an audit trail of every access and action taken to a particular
piece of stored information is an incredible marketing advantage.
Accountability is a security function that ensures actions taken on a system can be traced
back to the individuals who performed those actions. Assuming the records of these actions can-
not be tampered with, accountability makes it nearly impossible for someone to deny having
performed a specifi c action. Conversely, it makes it equally impossible to accuse people of doing
something they did not do. Accountability improves the detection of illicit activity and facilitates
rapid response through alerting and record retention. Accountability is also the vehicle for proving
compliance with statutory, regulatory, and contractual requirements and avoiding sanctions for
alleged violations. Finally, accountability is a huge deterrent to malicious behaviors and provides
a way to track the actions of highly trusted individuals (i.e., administrators and other privileged
users) to ensure they are not violating that trust.
SIDEBAR: OF AUDIT AND EVIDENCE
Before delving into the challenges and control objectives for accountability, it is necessary to discuss one other topic.
Compliance has caused one of the biggest shifts in system auditing since the invention of the computer. Originally,
system audit functions were designed for troubleshooting purposes; suffi cient information was collected to track sys-
tem behaviors and faults but little else. Often, standard audit records were augmented by debugging functions that
produced incredibly detailed logs of system activity. From a compliance standpoint, these two functions were part of
a “too little or too much” scenario. In order to prove compliance, audit mechanisms must create records containing
compliance evidence—proof of adherence to legal, regulatory, and industry requirements.
TAF-K11348-10-0301-C010.indd 171TAF-K11348-10-0301-C010.indd 171 8/18/10 3:10:34 PM8/18/10 3:10:34 PM
172 ◾ Security Strategy: From Requirements to Reality
Understanding the difference between the standard information an audit function provides and the evidence
that is required to prove compliance is critical to the success of your compliance efforts. Evidence is a collection of
relevant and suffi cient information to verify a fact. Unlike troubleshooting information, evidence has very specifi c
attributes; it must be:
Suffi cient—• containing enough information to lead others to the same conclusion
Appropriate—• containing information that is relevant, valid, and reliable enough to support the claim
Quality—• containing information that is easily discernible and supportive of the claim
S
UFFICIENT EVIDENCE
From an accountability standpoint, this means audit records must contain information about the entity performing
the action, the IT resource acted upon, the type of action or actions taken, and (if the action involves a change) the
old and new values. Standard event logs typically do not collect enough information to meet the suffi cient require-
ment, and debug logs collect too much to meet the quality requirement. This isn’t just an issue with operating system
capabilities; many services and applications have equally limited audit mechanisms. Having suffi cient information is
essential, but it isn’t everything; the information must meet the appropriate and quality bars as well.
A
PPROPRIATE EVIDENCE
The information collected must be relevant to the action taken. For example, if a change is made to the system, the
data must accurately refl ect what was changed as well as the changed values. In the case of a create action, the
name of the created object, as well as the value or values associated with the object, must be recorded; for a fi le
creation, the object would be a fi le and the value would be the fi le’s fully qualifi ed name (i.e., drive:pathfi lename.
ext). This level of detail is required for accountability. If only the directory (path) where the fi le was created was
recorded, additional information would have to be accumulated to determine what fi le was created. This situation is
completely unacceptable in large environments because of the quantity of data that would be generated (the goal in
large environments is to minimize, not increase, data collection).
This requirement is equally applicable to subjects; the subject must represent the individual entity that originated
the action. This account cannot be one that was delegated to do the action or a generic account such as guest or
administrator because there is no way to validate the subject. This requirement can be problematic for multitier
applications where service accounts are used for transactions between systems.
Finally, the appropriate attribute means the records are reliable. Records that are subject to unauthorized modifi -
cation are not reliable and therefore are not admissible. In other words, security-related audit records must be written
to a tamperproof container such as a centralized audit collection service managed by the security team. Since the
information is written to devices that are accessible only to security personnel, the integrity and reliability of the
audit information is assured.
Q
UALITY EVIDENCE
The quality attribute refers to the presentability of the evidence. Quality evidence is structured in a way that is easy
to understand and simple to correlate with the other pieces of evidence being presented. And, of course, it must
support the claim; quality-irrelevant evidence is still irrelevant. At odds with quality are the numerous places where
audit records are stored and the different formats of those records. Some sort of common measurement collection
capability is needed to address this issue. The goal is to force audit records into a common format and store them
in a structured database for the analysis and reporting of quality evidence. This capability is valuable only if it is
supported by infrastructure and by an enclave’s systems and applications. Ideally, all services should use a common
format and storage location for the audit records they generate.
Comprehensive Accountability Challenges
Implementing a comprehensive accountability control structure is no trivial pursuit. Accountability
relies on two factors: identity and audit. Actions must be traceable to a unique identity, and suf-
fi ciently detailed records (i.e., audit trails, logs) must be kept to support the claim that the identity
performed the actions. Both factors have their challenges.
Identity Challenges
A generic account is an account that cannot be associated with an individual identity. Examples
are the guest account, the root or administrator account, and service accounts. Two other
TAF-K11348-10-0301-C010.indd 172TAF-K11348-10-0301-C010.indd 172 8/18/10 3:10:34 PM8/18/10 3:10:34 PM
Trust but Verify (Accountability) ◾ 173
types of accounts also qualify as generic: shared accounts (accounts used by multiple people)
and Anonymous. None of these accounts allows you to trace an action back to an individual.
Eliminating the use of these accounts, however, isn’t always possible. For example, a poorly
designed application may require interactive log-ons for its service account. Management scripts
may require interactive log-ons for generic accounts as well. For example, a script to join systems
to the domain may require an interactive log-on by the SysPrepAdmin account to make sure it can
be run successfully by a less privileged user. Replacing or restricting the use of generic accounts in
a computing environment requires a thorough understanding of what each account is used for and
the type or types of authentication it requires. is sounds easy, but it takes a lot of eff ort to track
all this functionality down. It’s worth it in the end to have this level of understanding, but getting
there, especially in complex environments, is a major eff ort.
Audit Challenges
e sidebar presented earlier in this chapter highlighted a number of technological challenges
regarding the structure and content of system-generated audit records. e issue extends to appli-
cations as well. Take Active Directory (AD), for example, beginning with Microsoft Windows
Server 2008, changes to AD settings create two audit records: one containing the old value and
one containing the new value. From an accountability standpoint, this improvement is an impor-
tant one; yet, at the same time, it demonstrates the vendor’s lack of profi ciency. Why is this only a
feature in AD? Why isn’t it a standard audit feature in DHCP, DNS, and other domain services?
What is lacking in Windows 2008 and other major operating systems is a consistent audit archi-
tecture. In fact, so disparate are the audit log formats in the 2008 operating system that an XML
schema function was added to the event (log) viewer application so that it could display them in a
readable format. ese are major evidence issues within a single product manufactured by a single
vendor. Imagine what happens when you incorporate multiple vendors. A great example of this is
SYSLOG, a UNIX logging facility. SYSLOG is a model of simplicity; it contains just fi ve fi elds
of information: time, facility, priority, source, and meaning/description. ree of these fi elds have
a fi xed format; the other two (time and meaning) do not; consequently, there is no consistency
for these fi elds across vendors. is makes it nearly impossible to collate records across multiple
systems or applications without a sophisticated parser.
e emphasis on compliance in recent years has put pressure on manufacturers to provide
better auditing facilities, but the rate of change has been dismal. Instead, a number of com-
panies have introduced products designed to fi ll the gaps left by existing vendor audit func-
tions. Most of these products install an agent on the system capable of collecting detailed audit
information and converting it to a standard format for processing and reporting. Most have
the ability to identify and fl ag unauthorized or questionable actions, and some have the ability
to generate alerts as well. e main limitation of these products is processing time; usually a
signifi cant amount of time elapses between when the action took place and when it is detected
and reported. In other words, these products do not support rapid response. e rapid response
issue is somewhat understandable because the products are designed primarily for auditing and
most environments have other systems dedicated to detecting malicious activity. However, from
an operations standpoint, combining these two functions into a single system makes perfect
sense. It contributes to the principle of economy (force conservation) by reducing complexity
and simplifying operations.
Coverage is another limitation; the audit application may not have the ability to collect audit
information from one or several applications within an enclave. e operational impact of this
TAF-K11348-10-0301-C010.indd 173TAF-K11348-10-0301-C010.indd 173 8/18/10 3:10:34 PM8/18/10 3:10:34 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.