174 ◾ Security Strategy: From Requirements to Reality
functionality must also be considered. First is the issue of maintenance (updates, patches, etc.);
second is the issue of compatibility with other products running on the system. One organization
Bill worked for could not identify a confl ict between Active Directory and the IDS agent they were
using. Every so often the agent caused the domain controller to blue screen. To resolve the problem
IDS was removed from the one system where it was needed most! Performance is the other impact
issue. How will the collecting and processing of audit information impact the response time of a
system? Years ago a friend of Bill’s at Digital Equipment Corporation told him that the auditing
capabilities of VMS were so extensive that turning them all on meant the system didn’t have time
to do anything else! It is doubtful the eff ect would be that severe, but it is going to have an impact
and that impact must be known for proper system planning. Ideally, you want a function that has
a fi xed impact; for example, the function will never exceed 7% processor usage or 25 megabytes
of memory.
e quantity of data is another issue that must be considered, especially in large environments.
ere are two aspects to consider: processing and storage. Accountability produces an audit record
for a large number of security-related actions each user performs. If you are an online service
provider with a million users, that’s a lot of audit records—probably close to 9 million records
a day for log-ons and log-off s alone. Collecting that number of records is challenging enough;
getting them into a searchable store is even harder. Bill remembers working on a Trivoli manage-
ment system that monitored 65 or so machines. On average, the system had between 15,000 and
20,000 management records in the import queue. e system only imported about 1,000 records
an hour, so this represented close to a day’s worth of delay between the event and the processing of
the event. Even worse, for every record taken out of the queue, one was added. is kind of delay
is totally unacceptable for detecting and responding to unauthorized actions; those responses need
to be in near real time. Database capacity and processing impacts may also need to be evaluated if
the system is using SQL Server as a backend.
e benefi ts that accountability provides to the organization in the areas of risk reduction,
compliance, and liability management are obvious, but providing a high level of accountability
is challenging. Eliminating or restricting the use of generic accounts can be diffi cult and with
some applications impossible, but conforming the content of audit records to a common and
comparable format is a bigger challenge. Individual vendors don’t even use the same formats for
their products; crossing vendor product lines only exacerbates the problem. In large environ-
ments, the volume (quantity) of data can be both a storage and a processing issue. If the goal
is to have near real-time responses to illicit activities, long processing delays cannot be toler-
ated. Making accountability a reality in any computing environment takes a lot of planning;
organizations must expect that changes will need to be made to existing controls, new controls
will have to be added, and enhancements made to development processes and applications.
Having identifi ed those challenges, we can now begin to look at how organizations can over-
come them.
Best Uses for the Accountability Tactic
Financial organizations and organizations that deal with classifi ed secrets already use this tactic.
Banks, brokerages, and trading companies have to ensure that transactions cannot be reputed.
is requires the collection and preservation of records that prove a particular action was taken (or
approved) by a specifi c individual. Government agencies, the military, and military suppliers must
account for the use and distribution of classifi ed information to protect national security. ey
TAF-K11348-10-0301-C010.indd 174TAF-K11348-10-0301-C010.indd 174 8/18/10 3:10:34 PM8/18/10 3:10:34 PM
Trust but Verify (Accountability) ◾ 175
must ensure not only that actions can be assigned to an individual but also that the individual
has the proper clearance to perform those actions. Financial organizations and government agen-
cies require accountability to be a part of their operational structure, but any organization that is
subject to compliance auditing can benefi t from the application of this tactic.
Any structure that reduces the overall time and eff ort required for compliance reporting is
benefi cial. Manual reporting is a costly, time-consuming resource hog; any degree of automa-
tion is of value. Accountability, however, provides a number of other long-term benefi ts that are
diffi cult to ignore. For example, the ability to prove compliance through accountability could
be used to reduce the overall scope of audits. Accountability can also reduce malicious conduct,
legal or regulatory sanctions, and liabilities from false accusations or claims. Every organization
stands to benefi t from these capabilities. e question is, “Will it be cost eff ective?” Given the
state of today’s audit technologies, the cost of achieving high levels of accountability for small to
medium-size businesses is prohibitive. Large enterprises, especially those with in-house applica-
tion development, will fi nd this tactic much easier to implement for two reasons: (1) the ability
to build missing functionality and (2) the ability to incorporate accountability functionality into
their applications. ese allow the gaps between existing technologies and accountability control
objects to be closed. Service providers have the most to gain from this tactic. Accountability is not
only a viable way to reduce liability, it also improves availability by discouraging illicit behaviors
and identifying operational defi ciencies. Finally, a high level of accountability is a major market
diff erentiator.
Comprehensive Accountability Identity Objectives
Accountability is an information security tactic that assures actions taken on a system can be traced
back to the individual or individuals who performed those actions. e U.S. National Institute of
Standards and Technology (NIST) defi nition notes that accountability “supports non-repudiation,
deterrence, fault isolation, intrusion detection and prevention, and after-action recovery and legal
action.” is section covers accountability controls and control objectives. Accountability relies on
two functions: identity and audit. It isn’t possible to trace actions back to an individual unless the
individual has a unique identity, nor is it possible to trace actions back to an individual without
suffi ciently detailed records (i.e., audit trails, logs) of those actions.
e primary accountability attributes for identity are unique, specifi c, and exclusive. Unique
means only one occurrence of this identity exists within the system. Specifi c means that the
identity references a real person or process as opposed to a generic entity such as anonymous,
guest, or testuser1. Exclusive means the identity is used by a single entity as opposed to being
shared with multiple entities. ese three requirements should be part of your information
security policy for systemwide (domain) identities as well as local system identities, and these
policies should be backed up with the appropriate procedures for identity issuance, monitoring,
and revocation.
e goal is high assurance identity management beginning with properly vetted identity
requests, assuring the requestors are who they claim to be and have been properly authorized to
receive an identity. It continues with an incorruptible process for validating a presented identity
such as multiple factor or third-party authentication. And it concludes by assigning the appropri-
ate permissions to data and computing resources (i.e., authorization).
Ideally, the user should only need to log on once (single sign-on) and be able to gain access to
all their assigned resources. When this isn’t possible, the ideal is to be able to use the same identity
TAF-K11348-10-0301-C010.indd 175TAF-K11348-10-0301-C010.indd 175 8/18/10 3:10:34 PM8/18/10 3:10:34 PM
176 ◾ Security Strategy: From Requirements to Reality
(alias) for all log-ons. It is not unusual to fi nd multiple identity management solutions in today’s
IT environments, but from an accountability perspective this creates problems. Although it is
possible to implement accountability on a system-by-system basis, collating information across
systems is less than ideal. e best solution for high-assurance identity management is to have a
single identity for each user. e best alternative, if no single system meets all your identity needs,
is a meta-directory that associates multiple system identities to a single-user meta-identity.
Identity Control Requirements for Accountability
is section covers the controls this tactic requires for eff ective operations. Table 10.1 maps the
identity attributes to specifi c accountability baselines. e type (hard or soft) is used to denote
how evidence is collected for each control. Soft indicates a procedure-based control, while hard
denotes a technology-based (i.e., automated) control.
Domain and Local Account Management
e identity management system needs to provide coverage for local and domain account man-
agement across all platforms. is includes the establishment of an identity-naming convention
that will reduce the likelihood of identity collisions, support “no identity reuse,” and facilitate the
automation of identity management across the enterprise. Possible actions include:
Updating the identity management strategy to include accountability controls ◾
Developing identity-naming standards across all platforms and services ◾
Updating existing operations procedures and development practices to refl ect identity nam- ◾
ing requirements
SIDEBAR: NAMING STANDARDS
Two factors need to be considered when developing naming standards: management and usernomics (i.e., the
human factor). Names should be constructed in a way that facilitates system management. For example, service
identities ought to clearly identify the infrastructure or hosted service with which they are associated, as well as the
role of the identity within the service. This is equally true for human identities; they should be easily associated with
a specifi c organization or service. These associations make it easier for service and support personnel to quickly
identity the environment they are serving.
Usernomics relates to the usability of services from a human perspective. Accountability requires uniqueness of
identity but the introduction of complexity or ambiguity that negatively impacts users in order to achieve unique-
ness must also be avoided. Examples include users that end up with multiple identities to access different resources
or users that end up with disassociated or convoluted identities like John Smith ending up with the alias KTmith or
JnSmith2a14.
Name Collision
Collision detection is inherent in most identity management systems, but clear procedures for
resolving collisions, especially when multiple technologies are involved, must be established.
Table 10.2 contains examples of potential name collision scenarios.
Name Collision Scenarios
A clear procedure must be in place for resolving name collision issues. Under no circumstances
should it be possible to write an ambiguous identity to an audit record. e procedure must contain
TAF-K11348-10-0301-C010.indd 176TAF-K11348-10-0301-C010.indd 176 8/18/10 3:10:34 PM8/18/10 3:10:34 PM
Trust but Verify (Accountability) ◾ 177
Table 10.1 Identity Requirements for Accountability
Attribute/Control Type Risk and Requirements
Unique
Domain and local
account management
Soft Controls must apply across all domains and systems.
Name collision
detection
Hard Identity creation or mergers/consolidations that would
result in multiple entities with the same identifi er must be
detected.
Collision remediation Soft The user ID is altered based on established creation or
migration practices.
Identity retention Soft
Hard
Process to ensure an identity is never reused.
Process is in place to detect and disable accounts that have
not been used within a certain period of time.
Specifi c
Identity verifi cation Soft Prior to the creation of any account, the identity of the
requestor MUST be verifi ed.
Generic account
detection
Hard
Hard
Prior to production, all systems must have all generic
accounts disabled.
Regular account scans are made to discover generic accounts
(i.e., accounts not attached to a real person or process).
No local system
accounts enabled
(exc. administrator)
1
Soft Prior to going into production all systems must have local
accounts removed (if possible); all other accounts except
administrator must be disabled.
Generic and local
account detection
(creation or enabled)
Hard During production operations, the creation or enablement
of any local or generic account must be detected and an
alert generated to security operations.
Generic or local
account remediation/
disablement
Soft Any detected generic domain or local account (other than
local administrator) must be deleted or disabled.
Generic or local
account usage
detection
Hard During production operations, the successful or failed use
of any local or generic account for any type of activity must
be detected and an alert generated to security operations.
Exclusive
Multiple log-ons from
disparate locations
Hard Simultaneous usage of an identity from disparate locations
should be detected and reported.
Out-of-band log-on
(nonwork hours)
Hard Frequent log-ons outside of the entity’s normal working
hours should be detected and reported.
1
Local administrator is retained for emergency recovery when access to the identity manage-
ment system (IMS) is not available.
TAF-K11348-10-0301-C010.indd 177TAF-K11348-10-0301-C010.indd 177 8/18/10 3:10:34 PM8/18/10 3:10:34 PM
178 ◾ Security Strategy: From Requirements to Reality
an expedient way to notify the parties involved to prevent a user from being locked out of their
account. A well-defi ned process aided by a universal naming standard for identities should pro-
vide the necessary foundation for automating the remediation process. Possible actions include the
following:
Ensuring that information security standards require name collision detection and remediation ◾
Updating identity management procedures to ensure compliance with the name collision ◾
detection and remediation policy
Developing technologies to detect and automatically resolve name collisions, including ◾
appropriate operations and where necessary end-user notifi cations
Identity Retention
Identity retention is another risk that must be addressed, including the reuse of identities and the
elimination of stale accounts. Identity reuse refers to the establishment of a new account with an
identifi er that was previously used to grant access to system or service resources. Stale accounts are
identities that have not been used for some predetermined amount of time. ese accounts can
result from troubleshooting/problem resolution eff orts, periodic audits (i.e., auditor access), vendor
maintenance access, personnel reassignments, leaves of absence, and the like. Table 10.3 contains
risk scenarios associated with identity retention.
Table 10.2 Identity Requirements for Accountability
Scenario Description
Customer
merger
A customer through acquisition or reorganization merges two identities into
a single domain, causing user aliases common to both domains to collide.
Technology
integration
An identity in one technology (e.g., AD) requires an associated identity in
another technology (e.g., Live ID), but the proposed identifi cation from the
initiator collides with an existing identity in responding technology.
Table 10.3 Identity Retention Scenarios
Scenario Description
Identity
reuse
A person is incorrectly associated with actions in an audit record performed by
the previous owner of the identity.
A person is inadvertently granted access to resources based on authorizations
associated with the previous owner of the identity.
Stale
account
A person reassigned to a different job function (role) uses an old (stale) account
to access resources they are no longer authorized to access.
A person granted access for a specifi c period of time (i.e., an auditor or vendor
service personnel) uses the account outside of that time frame to access
resources they are no longer authorized to access.
An attacker gains unauthorized access to resources using a brute force or other
type of attack to compromise the account password because it is not changed at
required intervals.
TAF-K11348-10-0301-C010.indd 178TAF-K11348-10-0301-C010.indd 178 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.