- Email: [email protected]
The vulnerability instantiation methodology prototype
Information Security Technical Report - Prospectus
nent since although they are described as Write-Once-Read-Many, in practice the write process can often be repeated and existing data altered.
that must be secure. A further prerequisite is that it be possible to run (a set of) vulnerability detection tools on the system which produce a list o f vulnerabilities.
Media independency gives computer forensic scientists the immense advantage o f being able to conduct investigations on copies o f the data rather than on the data itself. Couple this with the fact that by far the biggest majority o f investigations are concerned with the overall content o f files which require httle or no subjective opinions, and once an accurate copy has been taken, forensic investigation can often adequately be undertaken by operatives with a limited degree o f computer expertise.
Knowledge o f vulnerabilities is in two parts: the amount o f effort required o f an attacker before vulnerabilities can be successfully exploited, and the assets that each vulnerability would put at risk if it were exploited. The VIM process is then a two-stage process o f comparing these two components with the two clauses o f the security policy. The first stage discards those vulnerabilities whose known cost o f exploitation is so great that the vulnerability does not come under the remit o f the security policy. The second stage then removes anything that does not threaten a protected asset. This leaves the Significant outcomes - which it should be a high priority to remedy.
Although it is possible to examine the contents o f computers directly, it is my opinion that this is not best practice because o f the risk o f contamination to the data. I define the forensic analysis process as falling into three distinct areas - collection, examination and evaluation, and these must be undertaken in this order with examination and evaluation taking place upon the collected copy rather than on the original data. I would define the term "forensically sound" as being applicable to a copy o f computer stored information containing as an absolute minimum the full operating arena o f information stored in all active semi-permanent storage. Copies taken via commercial file transfer facilities (e.g. LapLink) are not "forensically sound"; they are incomplete and this incompleteness might provide justification for the evidence to be declared invalid. The purpose o f forensic investigation is to enable observations and conclusions to be presented in court. Obviously this entails maintaining the absolute integrity o f the evidence under examination, as well as maintaining evidential continuity. It is paramount that a forensically sound copy is taken as quickly as possible w h e n a computer is seized for examination so that the computer may then be placed in secure storage. If the computer is to be retained by its owner, it is preferable to take two copies, one o f which is sealed in the presence o f the owner and then kept secure by the police. Forensic examination is conducted on the other copy and the computer is returned to the owner. In the event o f a challenge to the integrity o f the working copy, the court can order the seal to be broken on the secure copy and this can be verified - if necessary by an independent expert.The security o f this process would be helped if some system o f internal verification were implemented within the copying procedure such that any subsequent alterations might be located and identified.
The Vulnerability Instantiation Methodology Prototype, Robin Barker & Gavin Kelly. This report describes the Vulnerability Instantiation Methodology developed by NPL and a prototype that implements the methodology. The prototype takes the output from system security vulnerability detection tools and, using the system security policy, determines which vulnerabilities found by the tools constitute a real threat to the system. The methodology is based around a database o f how vulnerabilities can be combined to attack the security o f the system. The V I M model consists o f vulnerabilities, dependencies, costs and outcomes. Vulnerabilities are weaknesses in the system that may be used to attack the system. Dependencies between vulnerabilities arise where two or more vulnerabilities may be exploited in combination; e.g. the use o f weak passwords and easily accessible password file. The results o f attacks exploiting the dependencies are classified as outcomes. Associated with a dependency is a cost: the resources required by an attacker to achieve the outcome by exploiting the combination o f v u l nerabilities. ForVIM to be applied to a system, it is necessary for the system to have a security policy. This should detail both the maximum strength o f attacker it will be concerned with, and those assets within the system
m
The "costs" o f exploiting a single vulnerability are broken down into the following components: • Collusion - the degree to which the attacker needs to be an authorised user o f the system; • Connection - the degree to which an attacker needs to be connected on to the target machine; • Time - the length o f time an attacker will need to expend in the realisation o f the vulnerability; • Expertise - degrees o f technical competence required. The individual components o f an exploitation cost are not easily quantified, and the number o f values each component can take is limited to a small discrete set. Costs and outcomes also enter the model as input derived from the security policy. The security pohcy may determine that some costs are so high that the security policy will ignore attacks that require such a high amount o f resources. The level above which attacker costs will be ignored is termed the cost threshold, which is an input to the prototype. It is also possible that the security policy will only be interested in certain classes o f attacks, as the results o f other attacks do not threaten the protected assets o f the system. The security policy will determine the outcomes relevant to these assets and the set o f protected asset outcomes will also be an input toVIM. The output o f vulnerability detection tools is automatically processed by VIM to obtain a list o f numbers corresponding to the vulnerabilities. SATAN is the tool we have looked at in most detail. The prototype shows thatVIM could be built to handle the output o f a number o f different vulnerability detection tools. The dependency data in the prototype can be extended to handle further vulnerabihties and be revised in the light o f experience from usingVIM. The system security requirements input to V I M are derived from the security policy. This input can be varied to see how changes in the requirements would affect the perception o f what was a real threat to the system.
N T Security (volume 3 number 3) Windows NT Security Architecture,
John Hayday. Security is evident throughout the Microsoft Windows N T architecture and indeed was a primary design feature. This article provides an overview o f the component parts o f this architecture (Version 4.0), in order that the reader may appreciate some o f the security issues involved. The architecture is divided into two modes: Kernel Mode, where highly privileged code requiring direct access to memory and hardware operates; and User Mode, where applications and windows subsystems reside. In User Mode, memory space is allocated by the operating system and applications/sub systems are protected from each other, and
nent since although they are described as Write-Once-Read-Many, in practice the write process can often be repeated and existing data altered.
that must be secure. A further prerequisite is that it be possible to run (a set of) vulnerability detection tools on the system which produce a list o f vulnerabilities.
Media independency gives computer forensic scientists the immense advantage o f being able to conduct investigations on copies o f the data rather than on the data itself. Couple this with the fact that by far the biggest majority o f investigations are concerned with the overall content o f files which require httle or no subjective opinions, and once an accurate copy has been taken, forensic investigation can often adequately be undertaken by operatives with a limited degree o f computer expertise.
Knowledge o f vulnerabilities is in two parts: the amount o f effort required o f an attacker before vulnerabilities can be successfully exploited, and the assets that each vulnerability would put at risk if it were exploited. The VIM process is then a two-stage process o f comparing these two components with the two clauses o f the security policy. The first stage discards those vulnerabilities whose known cost o f exploitation is so great that the vulnerability does not come under the remit o f the security policy. The second stage then removes anything that does not threaten a protected asset. This leaves the Significant outcomes - which it should be a high priority to remedy.
Although it is possible to examine the contents o f computers directly, it is my opinion that this is not best practice because o f the risk o f contamination to the data. I define the forensic analysis process as falling into three distinct areas - collection, examination and evaluation, and these must be undertaken in this order with examination and evaluation taking place upon the collected copy rather than on the original data. I would define the term "forensically sound" as being applicable to a copy o f computer stored information containing as an absolute minimum the full operating arena o f information stored in all active semi-permanent storage. Copies taken via commercial file transfer facilities (e.g. LapLink) are not "forensically sound"; they are incomplete and this incompleteness might provide justification for the evidence to be declared invalid. The purpose o f forensic investigation is to enable observations and conclusions to be presented in court. Obviously this entails maintaining the absolute integrity o f the evidence under examination, as well as maintaining evidential continuity. It is paramount that a forensically sound copy is taken as quickly as possible w h e n a computer is seized for examination so that the computer may then be placed in secure storage. If the computer is to be retained by its owner, it is preferable to take two copies, one o f which is sealed in the presence o f the owner and then kept secure by the police. Forensic examination is conducted on the other copy and the computer is returned to the owner. In the event o f a challenge to the integrity o f the working copy, the court can order the seal to be broken on the secure copy and this can be verified - if necessary by an independent expert.The security o f this process would be helped if some system o f internal verification were implemented within the copying procedure such that any subsequent alterations might be located and identified.
The Vulnerability Instantiation Methodology Prototype, Robin Barker & Gavin Kelly. This report describes the Vulnerability Instantiation Methodology developed by NPL and a prototype that implements the methodology. The prototype takes the output from system security vulnerability detection tools and, using the system security policy, determines which vulnerabilities found by the tools constitute a real threat to the system. The methodology is based around a database o f how vulnerabilities can be combined to attack the security o f the system. The V I M model consists o f vulnerabilities, dependencies, costs and outcomes. Vulnerabilities are weaknesses in the system that may be used to attack the system. Dependencies between vulnerabilities arise where two or more vulnerabilities may be exploited in combination; e.g. the use o f weak passwords and easily accessible password file. The results o f attacks exploiting the dependencies are classified as outcomes. Associated with a dependency is a cost: the resources required by an attacker to achieve the outcome by exploiting the combination o f v u l nerabilities. ForVIM to be applied to a system, it is necessary for the system to have a security policy. This should detail both the maximum strength o f attacker it will be concerned with, and those assets within the system
m
The "costs" o f exploiting a single vulnerability are broken down into the following components: • Collusion - the degree to which the attacker needs to be an authorised user o f the system; • Connection - the degree to which an attacker needs to be connected on to the target machine; • Time - the length o f time an attacker will need to expend in the realisation o f the vulnerability; • Expertise - degrees o f technical competence required. The individual components o f an exploitation cost are not easily quantified, and the number o f values each component can take is limited to a small discrete set. Costs and outcomes also enter the model as input derived from the security policy. The security pohcy may determine that some costs are so high that the security policy will ignore attacks that require such a high amount o f resources. The level above which attacker costs will be ignored is termed the cost threshold, which is an input to the prototype. It is also possible that the security policy will only be interested in certain classes o f attacks, as the results o f other attacks do not threaten the protected assets o f the system. The security policy will determine the outcomes relevant to these assets and the set o f protected asset outcomes will also be an input toVIM. The output o f vulnerability detection tools is automatically processed by VIM to obtain a list o f numbers corresponding to the vulnerabilities. SATAN is the tool we have looked at in most detail. The prototype shows thatVIM could be built to handle the output o f a number o f different vulnerability detection tools. The dependency data in the prototype can be extended to handle further vulnerabihties and be revised in the light o f experience from usingVIM. The system security requirements input to V I M are derived from the security policy. This input can be varied to see how changes in the requirements would affect the perception o f what was a real threat to the system.
N T Security (volume 3 number 3) Windows NT Security Architecture,
John Hayday. Security is evident throughout the Microsoft Windows N T architecture and indeed was a primary design feature. This article provides an overview o f the component parts o f this architecture (Version 4.0), in order that the reader may appreciate some o f the security issues involved. The architecture is divided into two modes: Kernel Mode, where highly privileged code requiring direct access to memory and hardware operates; and User Mode, where applications and windows subsystems reside. In User Mode, memory space is allocated by the operating system and applications/sub systems are protected from each other, and