Security Assessment Plan

Documents

  • EMI Security Assessment Plan - draft - DOCX, PDF
  • EMI Security Assessment Plan - v0.2 - DOCX, PDF

Description

The Security Assessment Plan identifies which software components are going to be assessed and when the assessments are going to take place.

The assessment plan should also refer to what has been done in the past. It should highlight the fact that past assessments have found problems, and that vulnerabilities have been removed and re-writes carried out in order to produce more secure software.

I'd also suggest stating that if the plans change (which they might) - this should be clear as the version of the document changes. (e.g. through change record). For the Progress and status - this should change.

numbering is just to give ideas of section/subsections/structure

Author

Introduction

The University of Wisconsin / Universitat AutÚnoma de Barcelona Middleware Security and Testing Group have developed and are continuing to develop First Principles Vulnerability Assessment techniques for assessing software for vulnerabilities. Assessments of several major middleware systems have been carried out, significant vulnerabilities found in many of them, and the developers helped with remediation strategies. These techniques are being applied to various security related middleware packages supplied by EMI as part of the Quality Control process.

This document describes the plans for this activity, and the current status. A new version will be produced approximately every 3 months as the status changes.

The Vulnerability Assessment Process

Principles

The 5 main steps

Probably as in the Requirements 5 bullet points on https://twiki.cern.ch/twiki/bin/view/EMI/SA1QCSA

Details of activities carried out during process

Description of the communication process

Somewhere need to state which of the EMI packages have been assessed using these techniques, have had problems addressed, and have not had a major re-write since so that the assessment is current. This needs to be 'not hidden' in an EMI deliverable - but readily accessible to those looking at installing EMI software. This should also be regardless of whether the software was assessed during EMI or earlier.

Plans for packages to be assessed during EMI.

The nature of the assessment technique means that it is very time consuming, plus only a small number of people are funded to work on this. Hence only a small number of middleware packages can be assessed during the project. Also, before the assessment process gets under way, it is very difficult to estimate the time the assessment process will take, hence it may not be possible to assess all packages planned or it may be possible to do more than originally planned.

The main suppliers of packages within EMI are gLite, ARC, Unicore and dcache.

Priority

In order of priority for each supplier - add a 1-2 sentence description of each package - and why it is important to assess it - e.g. setuid, authz decision process.....

gLite

  • Argus

Note that a Vulnerability Assessment is already in progress for Argus at the time of writing.

  • gLexec

gLexec has been assessed in the past and has since undergone a re-write, mainly to address some of the problems found by these assessments. It is necessary to re-assess as previous assessments no longer provide information about the current version of gLExec.

Note that a Vulnerability Assessment is already in progress for Argus at the time of writing.

  • VOMS Core

  • CREAM

  • WMS

Unicore

  • TSI
  • Gateway.

ARC

  • HED
  • A-REX

dCache

??

Detailed plan and provisional schedule

Work plan/schedule containing the services to be assessed, person doing the assessment and deadline to have the assessments ready.

Current Status

(Obviously expand/correct, update each time.)

(Status at date)

Packages assessed prior to EMI

(Obviously correct/modify as appropriate)

Various packages have been assessed using the techniques developed prior to the start of EMI, these include

Condor, SRB, gLexec, MyProxy........

ARC Grid Monitor (a minor but most exposed component) was assessed on several occasions; no issues were discovered, and no code change required.

(Include which are part of the EMI release - possibly only mention those that are part of EMI)

(State whether current version has any major re-write - or whether the current version can be considered assessed. If has, this gives confidence in the Security aspect of quality.)

Packages already assessed during EMI

VOMS admin. Completed on (date) Some issues found which are currently being addressed by the development team.

Packages in Work

  • gLexec
  • Argus

Packages about to start

??

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2011-05-26 - GiuseppeGiacomoFiameniExCern
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback