Security Assessment

Description

Vulnerability assessments will be carried out following the approach called First Principles Vulnerability Assessment (FPVA). FPVA is a primarily analyst-centric (manual) approach to assessment whose aim is to focus the analyst’s attention on the parts of the software system and its resources that are mostly likely to contain vulnerabilities. FPVA is designed to find new threats to a system. It’s not dependent on a list of known threats.

Requirements

• Architectural Analysis: identify the major structural components of the system, including modules, threads, processes, and hosts. For each of these components, identify the way in which they interact, both with each other and with users. The artefact produced at this stage is a document that diagrams the structure of the system and the interactions amongst the different components and with the end users.

• Resource Identification: identify the key resources accessed by each component and the operations supported on those resources. Resources include elements such as hosts, files, databases, logs, and devices. For each resource, describe its value as an end target or as an intermediate target. The artefact produced at this stage is an annotation of the architectural diagrams with resource descriptions.

• Trust and Privilege Analysis: identify the trust assumptions about each component, answering such questions as how are they protected and who can access them. Trust evaluation is also based on the hardware and software security surrounding the component. Associated with trust is describing the privilege level at which each executable component runs. The privilege levels control the extent of access for each component and, in the case of exploitation, the extent of damage that it can accomplish directly. A complex but crucial part of trust and privilege analysis is evaluating trust delegation. By combining the information from the first two steps, we determine what operations a component will execute on behalf of another component. The artefact produced at this stage is a further labelling of the basic diagrams with trust levels and labelling of interactions with delegation information.

• Component Evaluation: examine each component in depth. For large systems, a line-by-line manual examination of the code is infeasible, even for a well-funded effort. A key aspect of our technique is that this step is guided by information obtained in the first three steps, helping to prioritize the work so that high value targets are evaluated first. The artefacts produced by this step are vulnerability reports, perhaps with suggested fixes, to be provided to the software developers.

• Dissemination of Results: Once vulnerabilities are reported, the next step is for the developers to fix them.

Security Assessment Plan

• Security Assessment Plan

Review of the Security Assessment Plan

• The Architectural Analysis has been carried out and the output contains a diagram describing the interactions among components and end users.
• The Resource Identification has been carried out and the output contains the resource descriptions.
• The Trust and Privilege Analysis has been carried out and the output contains the trust levels and the delegation information for all the components and their interactions.
• The Component Evaluation has been carried out and the output contains identified vulnerabilities and their suggested fixes.
• The Dissemination of Results has been carried out.

Metrics

TBD

Output

It’s a document that contains a report on the status of checklist and the metrics and measurements associated with the Software Maintenance and Support Plan.

Frequency

PM6, PM9, PM12, PM15, PM18, PM21, PM24, PM27, PM30, PM33, PM36

-- GiuseppeFiameni - 15-Jul-2010