The Host Security Metasystem and Laws of Host Security – Part II
I posted a blog earlier this weekthat introduced an abstract host security metasystem and the sensor andeffector instrumentation laws, which are two components of the laws ofhost security. Today’s blog outlines the security and policy componentlaws. Symantec posted a draft proposal on an abstract host securitymetasystem and the laws of host security in order to gain discussionand suggested improvements from interested parties in the securityindustry. Symantec posted this draft to openly solicit constructivecomments and helpful suggestions for draft refinements. The intent isto reach industry consensus on an architectural framework to guidedesigners of future host security subsystems and supportinginstrumentation.
The primary goal is to agree upon an abstract architecture andguiding principles to frame the debate around operating system enablingof competitive host security services, without reference to specificfeatures or implementations. Underlying this model is the assumptionthat the global computing community is best served by an open securitymarket that presents a diversity of defenses to potential threats,avoiding the cyber-pandemic risks exposed by a universal securitymonoculture.
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
(Please refer to my earlier blog entry for the breakdown of these laws.)
2. Effector instrumentation laws
(Please refer to my earlier blog entry for the breakdown of these laws.)
3. Security component laws
These laws govern the security component for the host security metasystem.
3.1 The security component shall implement security policy
The security component performs the active realization of securitypolicy, as provided by the policy component. Security policy should notbe hardwired into the security component.
3.1.1 Valid security policy shall be enforced by the security component
Assuming consistent policy, valid policy rules with applicable conditions shall have their corresponding actions taken.
3.1.2 The security component shall enforce only valid security policy
Security component actions shall be governed by valid authorizedsecurity policy and not result from any spurious source of securitydirectives.
3.2 The security component shall be unobtrusive and performant
Assuming reasonable security policy, the operation of the securitycomponent should not impose undue system overhead. This property isessential for security to be maintained and not be disabled oroverridden by the user. Security component consumption of systemresources should be regulated, consistent with policy, and throughputand latency for system operations should not be unduly impacted.
3.3 The security component shall be “unspoofable”
An attacker shall not be able to spoof security component operationsin any manner, so as to defeat security protections, by taking or nottaking actions that cause a deviation from intended policy enforcement,or by misrepresenting the security situation in logging, alerting, orreporting.
3.3.1 Security sensor instrumentation shall deliver readings to the security component and only to the security component
Security sensor readings shall be delivered to the securitycomponent in an effective manner, without delay, distortion, orcorruption. Unauthorized eavesdropping on security sensor readingsshall be prevented. The connection between the security sensorinstrumentation and the security component constitutes a critical linkin the security control loop and shall not be compromised.
3.3.2 Security effector instrumentation shall accept control actionsfrom the security component and only from the security component
Control actions from the security component shall be delivered tothe security effector instrumentation in an effective manner, withoutdelay, distortion, or corruption. No other control actions shall bedelivered to the security effector instrumentation. The connectionbetween the security component and the security effectorinstrumentation constitutes a critical link in the security controlloop and shall not be compromised.
3.4 Security component actions shall be traceable to security policy
The logic sequence leading to a particular security component actionmay not be evident to security policy makers, given the potentialcomplexity of security policy. It should be possible to trace actionsback to policy to gain insight into the policy implications so as toaid in policy refinement and evolution.
3.5 Security component operation shall be securely loggable and auditable
For security and compliance purposes, the operation of the securitycomponent shall be securely loggable and auditable. This should includetraces of input sensor readings, output control actions, and internaloperation at an appropriate level of detail consistent with effectiveoperation.
4. Policy component laws
These laws govern the policy component for the host security metasystem.
4.1 The security policy shall be governed by the system owner
Although there may be multiple stakeholders pertaining to a system,such as system owner, users, content owners, system and devicemanufacturers, operating system and software providers, government andregulatory bodies, etc., but ultimately the system owner governssecurity policy, as a matter of common law property rights. Negotiationof security policy rules with other stakeholders is a prerogative ofthe system owner, and is out of scope of the security metasystem.Proper authentication of policy administrators shall be provided, andunauthorized manipulation of security policy is prohibited.
4.2 The security policy shall be comprehensive and dynamic
Comprehensiveness of system security rests upon a comprehensivesecurity policy. A system without comprehensive security is insecure,since attackers will find any weakness and exploit it. As discussedearlier with reference to the co-evolution of attack and defensestratagems, even comprehensive security policy will be attacked andovercome in time without continual progression. This implies thatsecurity policy is dynamic, evolving, and responsive to the dynamicthreat environment. If security policy is formulated as a policyrulebase, where rules comprise a policy condition and a policy action,then both conditions and actions must provide sufficient range,precision, and power to meet future unanticipated threats.
4.3 The security policy shall be “unspoofable”
Security policy is the executable realization of the intelligencebehind the system defenses. Any compromise of system security policy ispotentially fatal to these defenses, and policy compromise can place asystem under attacker control, enlisting it in cascading attacks onother uncompromised systems.
4.3.1 All policy rules shall be authentic
The policy component shall only provide authentic policy rules tothe security component. Enforcement of and determination of ruleauthenticity shall be a function of the policy component using wellaccepted secure protocols.
4.3.2 Rule access by the security component shall not be impeded
Execution of policy rules in compliance with security policy is thefunction of the security component, and its awareness of and access torelevant policy shall be unimpeded.