This Weblog and the blogoshpere in generalhave been abuzz with controversy over Microsoft PatchGuard and issuesdealing with appropriate kernel security instrumentation. This blogentry is the first of a two-part series. It provides an excerpt of adraft posting that proposes an abstract host security metasystem andlaws of host security that attempt to raise the level of discourseabove specific features and implementations. This blog entry willoutline the sensor and effector instrumentation laws and the secondblog entry, covering the security and policy component laws, will bepublished later this week. Symantec posted this draft to openly solicitconstructive comments and helpful suggestions for draft refinements.The intent is to reach industry consensus on an architectural frameworkto guide designers of future host security subsystems and supportinginstrumentation.
The draft is intended for discussion and improvements by interestedparties in the security industry. The primary goal is to agree upon anabstract architecture and guiding principles to frame the debate aroundoperating system enabling of competitive host security services,without reference to specific features or implementations. Underlyingthis model is the assumption that the global computing community isbest served by an open security market that presents a diversity ofdefenses to potential threats, avoiding the cyber-pandemic risksexposed by a universal security monoculture.
The host security metasystem encompasses a policy component, asecurity component, and an instrumentation component; all intended tosecure a host system. The instrumentation component provides bothsensor and effector instrumentation to the security component. Thesecurity component uses sensor instrumentation to observe systembehavior, internal logic to evaluate behavior patterns, and effectorinstrumentation to interdict malicious behavior. Security componentactions are governed by security policy provided by the policycomponent. For this metasystem to provide security value, the followinglaws of host security are proposed. Each law below is numbered and isfollowed 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 orperformance overhead that would tempt a system owner to disable orreduce security protections.
1.2 Sensor observations shall be unspoofable
An attacker shall not be able to spoof sensor observations in anymanner, so as to defeat security protections, by masking or concealingmalicious activity, by frustrating the situation assessment, or bytricking 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 beobserved by sensor instrumentation, so as to enable securityprotections. Relevant occurrences may include access operations,resource consumption actions, system service requests, storage ornetwork activity, inter-process communications, or relevant behavioralaspects 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 befabrications or distortions, else the security component may be misledby such spoofed monitoring. An attacker could use this technique toimplement a denial of service action against a benign process, or tomask or conceal malicious activities by altering the observedbackground.
1.3 Sensor observations shall be timely
The host security metasystem implements a continuous protectivecycle of observation, evaluation, and, if necessary, regulation,interdiction or other enforcement action. Observations need to besufficiently timely that security policy goals for timeliness andadequacy of protection may be met. But timeliness must also beconstrained by unobtrusiveness and performance requirements that willrestrict the time granularity and latency of observations. Anappropriate balance needs to be sought.
1.4 Sensor observations shall be comprehensive
Security policy and the protections it affords should not beconstrained by any lack of comprehensiveness in sensor observations."Blind spots" in sensor observation create opportunities for attackersto evade protections and compromise the host system. Since attackersand defenders engage in a continual round of attack, defense, andcounter-attack, they co-evolve increasingly more sophisticatedstratagems. A sensor observation design that was earlier consideredcomprehensive may quickly be rendered inadequate as co-evolutionprogresses beyond its now primitive limitations. Foresight ininstrumentation planning is valuable insurance against attackinnovation, 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 orperformance overhead that would tempt a system owner to disable orreduce security protections. If gating every relevant action through asecurity turnstile cannot be avoided, this must have minimal overheadin terms of either throughput or latency. It is preferable to architectthe effector mechanisms such that they impose no penalty unless anuncommon enforcement action is taken. Resource consumption regulatorsshould impose no significant regulation penalty, since they wouldtypically operate on a full duty cycle.
2.2 Effector controls shall be unspoofable
An attacker shall not be able to spoof effector operations in anymanner, so as to defeat security protections, by altering orcircumventing security actions or by tricking the security component(e.g. returning a bogus error code) into inappropriately repeated orbroadened enforcement actions.
2.2.1 A control action shall have been issued by the security component
Security instrumentation effector controls shall be driven by thesecurity component (and not by unauthorized system components).Security effectors present a potential attack vector that could subvertor disrupt system operation if compromised. But without effectorcontrols, security is toothless and can only present alerts toadministrators, 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 performedconsistent with the interface specification. Deviation fromspecification can result in unintended consequences or undesiredcontrol operation, potentially weakening or evading security actions.Control errors (setpoint excursions) or control loop instability canresult if resource regulator actions (defending against denial ofservice attacks) are inaccurate or distorted. Misperformed controloperations could produce denial of service effects or other performanceproblems due to flawed or compromised resource allocation.
2.3 Effector controls shall be timely
Effective attack prevention or damage control requires timelycontrol operation execution. Behavioral detection techniques mayrequire a decision period to make a maliciousness determination andresolve upon a control action. Unnecessary prolongation of an effectiveresponse can result in increased system disruption or informationcompromise, or in the case of a regulator control loop it may causecontrol inaccuracies or even instabilities.
2.4 Effector controls shall be comprehensive
Effector control functionality shall cover the range of controlactions required to implement security policy. Security policyflexibility requires sufficient specificity, range and precision incontrol actions that future unanticipated threats can be dealt with.Unanticipated threats and the need for innovative new responsestratagems arise from the co-evolution of attack and defense describedearlier. Effector controls should be architected with skill andforesight since they impose the final limits on attack response, andsince retrofitting new hastily added controls can inflict performancepenalties 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.