Pages

Monday, June 28, 2010

Target of Evaluation (TOE) -Introduction

SCADA Field Device Protection Profile Project
Target of Evaluation (TOE)
Introduction
The Process Control Security Requirements Forum (PCSRF) has a project to develop and
complete a SCADA Field Device Protection Profile by April 30, 2006. The Protection Profile
will list the security requirements for field devices such as PLC’s, PAC’s, RTU’s and IED’s.
The Protection Profile is an opportunity for the asset owners, vendors, industry organizations,
government organizations and other interested parties to provide a clear and comprehensive set
of security requirements for the next generation of field devices. Vendors will then be able to
develop field devices that meet the Protection Profile requirements and have those devices
independently tested and certified by an internationally recognized third party.
PCSRF has chosen to use the Common Criteria methodology to specify functional and assurance
requirements. The Common Criteria has a precise language and methodology that enables for
clear specifications and objective testing. To achieve this, the Common Criteria sacrifices
readability and is not the appropriate document for a general reader to learn guidelines or best
practices. It may not be easy for even a subject matter expert in SCADA Field Devices to
understand some of the later sections of the Protection Profile text.
To encourage participation each milestone deliverable in this project will have a section with the
draft Protection Profile text and a section explaining the Protection Profile text.
We need your comments on either the Protection Profile text or the explanatory text. If you can
identify an issue in the explanatory text, we can convert it into the proper Common Criteria
format.
There are helpful books available, such as Debra Herrmann’s Using the Common Criteria for IT
Security Evaluations, if you want to understand the specific Common Criteria language. As Ms.
Herrman defines it, the Common Criteria “provide a complete methodology, notation, and syntax
for specifying requirements, designing a security architecture, and verifying the security integrity
of an ‘as built’ product, system or network.”

No comments:

Post a Comment