204 ◾ Security Strategy: From Requirements to Reality
Passive Detection Control Objectives
Today most detection functionality in applications is passive: the patrolling guard scenario. Every
so often, someone comes by and looks at the door. ey may note some damages to the door and
investigate how it got there, or even worse they may fi nd that the door has been broken down!
Periodic application log review is the same scenario (assuming application logging is turned on
and subject to periodical review). Occasionally, some abnormal activity may be noted, investi-
gated, and result in the discovery of a breach. e eff ectiveness of this scenario depends largely on
the quality of the information recorded in the logs. Developers are interested in catching problems
with code execution, not detecting malicious activity. Sometimes, these are one and the same
(the malicious activity is the cause of the problem), but more often, this isn’t the case. Audit trails
designed for debugging seldom contain the quality of information required to identify malicious
activity. Error codes are frequently used to identify where the fault took place rather than why
it took place. Determining the why requires parsing the text—not a trivial activity for unstruc-
tured data. Quantity is another issue; reviewers are forced to wade through hundreds of irrelevant
events to fi nd security-related information, and when it is found, it is often insuffi cient to detect
malicious activity or to facilitate investigation, not to mention provide evidence for compliance
reporting. is situation is completely unacceptable. Audit trails must contain quality informa-
tion suffi cient for the detection and investigation of malicious activity, as well as the prosecution
of the perpetrator.
Table 11.2 maps audit trail attributes to specifi c baselines. e type (hard or soft) is used to
denote how the metric for each control objective is collected. Soft indicates a procedure-based
control, while hard denotes a technology-based (i.e., automated) control.
ese requirements are essentially the same as the audit control objectives for accountability.
For a detailed description of these control objects, see the Audit Requirements for Accountability
section of Chapter 10.
Active Detection Control Objectives
From a response perceptive, passive detection is an ineff ective security control because the detec-
tion takes place after the fact. As the interval of time between the event and its review increases,
the potential damage the attacker can do also increases. Passive detection alone is not suffi cient to
meet strategic security objectives; real-time (active) detection is required. Active detection enhances
the detection process by generating an alert when the event takes place. ere are two possible
scenarios; the audit trail can be reviewed in real time or the application can generate the alerts.
e fi rst scenario is the current approach the industry has taken; audit records are forwarded to a
central collection point and evaluated (reviewed) against a set of predefi ned rules, and alerts are
generated for activities that violate one or more rules. e eff ectiveness of the control depends on
the quality of the information in the record, the accuracy of the rules, and the processing effi ciency
of the evaluation system. One advantage of this approach is the ability to collate records from
multiple systems to get a broader understanding of the event, thus facilitating the accuracy of the
response. e downsides of this approach are a propensity for false detections (false positives) and
processing lag under high record volumes.
e application-based intrusion detection system (AIDS) doesn’t suff er from these short-
comings because detection is based on programmatic security functionality; not on the inter-
pretation of a recorded event. At a security conference in 1991, Bill presented the concept of
TAF-K11348-10-0301-C011.indd 204TAF-K11348-10-0301-C011.indd 204 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
SDL and Incident Response ◾ 205
exceptional logging as the basis for application intrusion detection. e concept was based on
the idea that in the normal course of operations certain things should never happen, and when
they do happen they are an exceptional event that should be logged and where appropriate
should generate an alert and/or take corrective action. e process diagram in Figure 11.5 is
an example. Web-based applications verify data on the client side because it is quicker and it
reduces the amount of traffi c that passes back and forth between the client and server. However,
any data transmitted from an application that is outside of your control (i.e., the Web page and
associated scripts on the client) cannot be trusted, so data submitted to the server is checked
a second time to ensure its validity. How many times should this validation fail? ZERO! e
only way for this validation to fail is for someone to deliberately disable the checks on the client
side. Disabling these checks is indicative of malicious activity. erefore, the event should be
logged and the session with the user terminated. If the user has to log back on the next time
he or she accesses the server, it won’t take long to realize you can’t access the system with a
hacked client!
Table 11.2 Audit Trail Control Objectives
Attribute/Control Type Risk and Requirements
Suffi cient
Coverage Soft Audit/logging mechanisms must be enabled for all
applications and subject to review at established intervals.
Complete Hard Audit records must contain all the information required
to detect and investigate malicious activity and prove
compliance with all applicable legal, regulatory, and
industry requirements.
Temporal Hard Records must be associated with a global time source.
Quality
Consistent Soft Records must have a common format that complies with
established standards.
Relevant Hard The information collected must support all associated
compliance and legal claims.
Understandable Soft The information in audit records should be easy to assimilate.
Simple Hard The records should not contain extraneous content.
Sequential Hard The records must be in chronological order.
Correlated Soft The relationship between the records should be apparent.
Authentic
Tamperproof Hard Records must be protected against malicious alteration.
Traceable Hard The records should have a consistent chain of custody.
Retained Soft The records must be retained for a suffi cient time to assure
proper review and to facilitate investigations.
TAF-K11348-10-0301-C011.indd 205TAF-K11348-10-0301-C011.indd 205 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
206 ◾ Security Strategy: From Requirements to Reality
Assuming there is an ExceptionalEventHandler class, the process requires the insertion of a
line or two of code to provide real-time alerting for malicious activity. Exceptional logging also
encompasses the audit component of this control objective. All events must be logged using the
same criteria as passive detection.
Alert generation should also be a call to a predefi ned set of methods (class). e details of
this functionality will be discussed in the Transition Objectives section later in this chapter. For
now just remember that AIDS requires an alerting capability. e fi nal component is corrective
action (intrusion prevention): the application of a countermeasure or mitigating control. e use
of this response mechanism depends on a number of things, including the value of the data on
the system, the severity of the event, the application interface, and the response processes you have
in place. In some instances, a programmatic response from the application makes sense; in other
cases, allowing the alert management process to decide on countermeasures is more appropriate.
e level (intensity) of response is also a judgment call; in the example above, the user’s session was
killed. A more graceful approach might be to return a Web page informing the user their client is
corrupted and they need to download a new version.
Table 11.3 maps active detection attributes to specifi c baselines. e type (hard or soft) is used
to denote how the metric for each control objective is collected. Soft indicates a procedure-based
control, while hard denotes a technology-based (i.e., automated) control.
ese control objectives form the basis for AIDS, and when applied to a database management
application, they become the basis for data intrusion detection. e control objectives are designed
to ensure the timeliness and eff ectiveness of this tactic, including minimizing false detections and
providing fl exible intelligent alerting to facilitate event management for application-level instances
of malicious activity. ese control objectives also include an intrusion prevention option design
to proactively invoke countermeasures that will reduce or eliminate the risks associated with cer-
tain types of malicious activity. is capability is particularly valuable for systems processing or
storing high-value or high-sensitivity data.
Server side failure of client-validated data
Validate data
Validation
failed?
Yes
Yes
No
No
Continue
Exceptional
event?
Apply
counter-
measure
Generate
security alert
Log malicious
activity
Figure 11.5 Exceptional event example.
TAF-K11348-10-0301-C011.indd 206TAF-K11348-10-0301-C011.indd 206 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
SDL and Incident Response ◾ 207
Table 11.3 Active Detection Control Objectives
Attribute/Control Type Risk and Requirements
Coverage Soft All applications must have a means of detecting malicious
activity, logging such activity, and generating an alert
(notifi cation) for event management purposes.
Audit Detection processes shall conform to passive detection audit
record control objectives.
Detection
Timely Hard Detection must be in real time and result in the immediate
creation of an audit record.
Accurate Hard Detection to the best extent possible shall:
- Identify all known types of malicious activity (i.e., minimize
false negatives).
- Be based on actual malicious activity (i.e., minimize false
positives).
Alerting
Intelligent Soft Alerting mechanisms whenever possible should have features
that improve the accuracy and effi ciency of alert processing
such as the ability to:
- Consolidate multiple occurrences of an event within a certain
time frame into a single alert message.
- Generate alerts based on threshold triggers (e.g., too many
events within a certain time frame) instead of on every
occurrence of an event.
- Filter (ignore) certain events.
- Confi rm the delivery of alert messages.
- Direct alerts to multiple destinations.
- Be remotely confi gurable
Timely Hard Alerts shall be generated in real or near real time according to
established alerting standards.
Consistent Soft Alert messages must have a common format that complies with
established standards.
Suffi cient Hard Alert messages should contain suffi cient information to support
a directed response.
Understandable Soft The information in alert messages should be understandable by
a person of normal intelligence.
Simple Hard Alert messages should not contain extraneous content.
Temporal Hard Alert messages must be associated with a global time source.
(continued)
TAF-K11348-10-0301-C011.indd 207TAF-K11348-10-0301-C011.indd 207 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
208 ◾ Security Strategy: From Requirements to Reality
e following actions are recommended to facilitate the observation and recognition of mali-
cious activities at the application level:
1. Survey existing application detection and alerting mechanisms and associated interfaces to
determine application requirements and identify gaps in capability.
2. Review existing alerting message formats and content to identify gaps in information com-
pleteness, clarity, and the like.
3. Assess the risks associated with existing time interval standards for generating alerts.
4. Update existing standards to conform to security strategic objectives.
5. Build a knowledge base of exceptional events patterns.
6. Review and update application development processes (in-house or contracted) to incorpo-
rate AIDS requirements into all development eff orts (in-house and contracted).
Table 11.3 Active Detection Control Objectives (Continued)
Attribute/Control Type Risk and Requirements
Sequential Hard Alert messages should be in chronological order.
Correlated Soft The relationship between alert messages should be apparent.
Authentic Hard Alert messages should have a means for proving authenticity to
prevent message tampering or spoofi ng.
Countermeasures
Coverage Soft Countermeasures may be included in applications to provide
proactive protection against malicious activity.
Callable Soft Programmatic countermeasures should have an interface that
allows them to be invoked by an external management process.
Timely Hard Countermeasures shall have a means for setting the time
interval between an event and the countermeasure execution.
Accurate Hard Countermeasures shall only mitigate the threat associated with
a specifi c instance of malicious activity (i.e., the countermeasure
should not adversely impact overall system performance or
usage).
Effective Soft Countermeasures should mitigate the threat associated with the
malicious activity to an acceptable risk level.
Note: SHOULD is used because mitigation to acceptable levels
is not always possible, and to acknowledge that any measure
reducing risk is better than no action at all.
Comprehensive Hard Countermeasures should ensure that all actions taken result in
the return of all related resources to the system (i.e., no open
fi les, allocated memory, etc.) to prevent a potential Denial of
Service from repeated attacks.
Reporting Hard Countermeasures shall generate an audit trail of actions taken
and when possible the results of said actions.
TAF-K11348-10-0301-C011.indd 208TAF-K11348-10-0301-C011.indd 208 8/18/10 3:11:03 PM8/18/10 3:11:03 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.