This Weblog and the blogoshpere in general have been abuzz with controversy over Microsoft PatchGuard and issues dealing with appropriate kernel security instrumentation. This blog entry is the first of a two-part series. It provides an excerpt of a draft posting that proposes an abstract host security metasystem and laws of host security that attempt to raise the level of discourse above specific features and implementations. This blog entry will outline the sensor and effector instrumentation laws and the second blog entry, covering the security and policy component laws, will be published later this week. Symantec posted this draft to openly solicit constructive comments and helpful suggestions for draft refinements. The intent is to reach industry consensus on an architectural framework to guide designers of future host security subsystems and supporting instrumentation.
The draft is intended for discussion and improvements by interested parties in the security industry. The primary goal is to agree upon an abstract architecture and guiding principles to frame the debate around operating system enabling of competitive host security services, without reference to specific features or implementations. Underlying this model is the assumption that the global computing community is best served by an open security market that presents a diversity of defenses to potential threats, avoiding the cyber-pandemic risks exposed by a universal security monoculture.
The host security metasystem encompasses a policy component, a security component, and an instrumentation component; all intended to secure a host system. The instrumentation component provides both sensor and effector instrumentation to the security component. The security component uses sensor instrumentation to observe system behavior, internal logic to evaluate behavior patterns, and effector instrumentation to interdict malicious behavior. Security component actions are governed by security policy provided by the policy component. For this metasystem to provide security value, the following laws of host security are proposed. Each law below is numbered and is followed by a brief explanation.
1. Sensor instrumentation laws
These laws govern the monitoring interface for the host security metasystem.
1.1 Sensor observations shall be unobtrusive and performant
Sensor observations should not impose undue inconvenience or performance overhead that would tempt a system owner to disable or reduce security protections.
1.2 Sensor observations shall be unspoofable
An attacker shall not be able to spoof sensor observations in any manner, so as to defeat security protections, by masking or concealing malicious activity, by frustrating the situation assessment, or by tricking the security component into inappropriate enforcement actions.
1.2.1 A relevant occurrence shall be observed
A relevant occurrence (i.e. relevant to security policy) shall be observed by sensor instrumentation, so as to enable security protections. Relevant occurrences may include access operations, resource consumption actions, system service requests, storage or network activity, inter-process communications, or relevant behavioral aspects that may serve to distinguish benign from malicious activity.
1.2.2 An observation shall reflect an actual occurrence
Sensor observations shall reflect actual occurrences and not be fabrications or distortions, else the security component may be misled by such spoofed monitoring. An attacker could use this technique to implement a denial of service action against a benign process, or to mask or conceal malicious activities by altering the observed background.
1.3 Sensor observations shall be timely
The host security metasystem implements a continuous protective cycle of observation, evaluation, and, if necessary, regulation, interdiction or other enforcement action. Observations need to be sufficiently timely that security policy goals for timeliness and adequacy of protection may be met. But timeliness must also be constrained by unobtrusiveness and performance requirements that will restrict the time granularity and latency of observations. An appropriate balance needs to be sought.
1.4 Sensor observations shall be comprehensive
Security policy and the protections it affords should not be constrained by any lack of comprehensiveness in sensor observations. "Blind spots" in sensor observation create opportunities for attackers to evade protections and compromise the host system. Since attackers and defenders engage in a continual round of attack, defense, and counter-attack, they co-evolve increasingly more sophisticated stratagems. A sensor observation design that was earlier considered comprehensive may quickly be rendered inadequate as co-evolution progresses beyond its now primitive limitations. Foresight in instrumentation planning is valuable insurance against attack innovation, and preserves option flexibility for the defender.
2. Effector instrumentation laws
These laws govern the control interface for the host security metasystem.
2.1 Effector controls shall be unobtrusive and performant
Effector controls should not impose undue inconvenience or performance overhead that would tempt a system owner to disable or reduce security protections. If gating every relevant action through a security turnstile cannot be avoided, this must have minimal overhead in terms of either throughput or latency. It is preferable to architect the effector mechanisms such that they impose no penalty unless an uncommon enforcement action is taken. Resource consumption regulators should impose no significant regulation penalty, since they would typically operate on a full duty cycle.
2.2 Effector controls shall be unspoofable
An attacker shall not be able to spoof effector operations in any manner, so as to defeat security protections, by altering or circumventing security actions or by tricking the security component (e.g. returning a bogus error code) into inappropriately repeated or broadened enforcement actions.
2.2.1 A control action shall have been issued by the security component
Security instrumentation effector controls shall be driven by the security component (and not by unauthorized system components). Security effectors present a potential attack vector that could subvert or disrupt system operation if compromised. But without effector controls, security is toothless and can only present alerts to administrators, a control loop that could be fatally slow, ineffective, and insufficient to support a compliant security policy.
2.2.2 A control action shall be executed as specified
Security instrumentation effector operations shall be performed consistent with the interface specification. Deviation from specification can result in unintended consequences or undesired control operation, potentially weakening or evading security actions. Control errors (setpoint excursions) or control loop instability can result if resource regulator actions (defending against denial of service attacks) are inaccurate or distorted. Misperformed control operations could produce denial of service effects or other performance problems due to flawed or compromised resource allocation.
2.3 Effector controls shall be timely
Effective attack prevention or damage control requires timely control operation execution. Behavioral detection techniques may require a decision period to make a maliciousness determination and resolve upon a control action. Unnecessary prolongation of an effective response can result in increased system disruption or information compromise, or in the case of a regulator control loop it may cause control inaccuracies or even instabilities.
2.4 Effector controls shall be comprehensive
Effector control functionality shall cover the range of control actions required to implement security policy. Security policy flexibility requires sufficient specificity, range and precision in control actions that future unanticipated threats can be dealt with. Unanticipated threats and the need for innovative new response stratagems arise from the co-evolution of attack and defense described earlier. Effector controls should be architected with skill and foresight since they impose the final limits on attack response, and since retrofitting new hastily added controls can inflict performance penalties and create vulnerabilities.
Note: Please visit the Symantec Security Response Weblog later this week for the second and final blog entry in this series, when I will explain the security and policy component laws.