Plain English Guide To Common Criteria Requirements In The Field Device Protection Profile Version 0.75 Prepared For: Process Control Security Requirements Forum (PCSRF) Prepared By: Digital Bond, Inc. June 14, 2006
Introduction Plain English Guide The Field Device Protection Profile was developed by the Process Control Security Requirements Forum (PCSRF) as a vehicle for the SCADA and Industrial Control System (ICS) community to express security requirements for the next generation field device. Examples of field devices include PLC s, PAC s, RTU s and IED s and are typically found in layer 1 or 2 of the ISA95 / Purdue CIM model. The field device security requirements were put in a Common Criteria Protection Profile to facilitate testing and certification of future field devices. The Common Criteria language and methodology can be difficult to understand. This document was created to help reviewers by making the requirements understandable without Common Criteria knowledge. This document is a translation and consolidation of the functional and assurance security requirements in the Field Device Protection Profile. It is a useful tool, but it is not a substitute for the Protection Profile. Vendors developing products and Security Targets should use the Protection Profile to work with the specific requirements the product will be tested against. How To Use This Document This document was developed for the following uses: 1. PCSRF members and other reviewers of the Protection Profile can use this document to understand the functional and assurance requirements in the Protection Profile without delving into the Common Criteria language and methodology. Comments made on this document will be used to update the Protection Profile and this document. 2. Other control system security efforts can use this document as input to procurement or requirement language projects. The Common Criteria is the result of an extensive effort by the IT security community and covers a broad range of security requirements. This document will help those groups working on procurement and requirements language to consider selected Common Criteria requirements without detailed study of the Common Criteria. 3. Asset owners and vendors can use this document in their efforts to develop, procure and deploy secure field devices. Requirements Audit The field device must have a robust audit capability. Each functional requirement has a list of mandatory events and information that must be recorded in an audit log. The field device vendor may also add to the required security related audit events and capabilities. Page 1
Plain English Guide The Administrator or Auditor roles determine what users are allowed to view the audit logs, while only the Auditor role is allowed to configure and manage the audit logs. Configuration can include determining what events and conditions are recorded, thresholds for alarms, and deletion of audit logs. The field device must prevent all users, including Administrators and Auditors, from modifying the audit logs. The field device shall record the date and time of the event, the user identity (if applicable), the system identity (if applicable), and the outcome of the event for every security related audit event. The field device shall have an indicator in each audit event that indicates if it is a security related audit event. Application Note: This requirement enables a security monitoring product or service to easily recognize and extract security events from the audit logs. The vendor may include more detail in the indicator such as the type of the security event, i.e. denial of service, authentication failure, or replay. The field device shall have the ability to monitor the accumulation and combination of audit events to identify the following potential security violations: - An Administrator specified number of user authentication failures - Replay of data or security parameters - Failure of periodic and on-demand self-tests - An Administrator specified number of encryption or decryption failures - An Administrator specified number of cryptographic data integrity verification failures The field device shall have an access control setting that allows an Administrator or Auditor to determine what users or roles have the ability to view audit records. The default setting shall be to deny access to all users except those in the Administrator or Auditor roles. The field device shall allow an Auditor to include or exclude the recording of audit events based on the following criteria: user identity, system identity, event type, and success or failure. The field device shall prevent any modifications to the audit records and only allow an Auditor to delete audit records. The field device shall generate an alarm and enter it in the audit log when the audit log reaches an Auditor set percentage of storage capacity. The field device audit log shall overwrite the oldest stored audit records when the audit log is full. Page 2
Plain English Guide Cryptography The field device may require a variety of cryptographic functions to, such as key management, encryption and decryption, and digital signature generation and verification. The Protection Profile does not require these functions, but there are requirements for any cryptographic functions used in the field device because the security of the cryptography is integral to the security of the field device. The protection profile specifies US Government FIPS 140-2 standard for all cryptographic modules, functions and parameters. Other regions, countries and industry groups may choose to use a different standard. All cryptographic functions shall take place in a FIPS 140-2, Level 3 approved module. This module may be implemented in software, hardware or a combination of software and hardware. Key management, including key generation, distribution and destruction, shall be performed in a manner specified in FIPS 140-2. All cryptographic functions, such as encryption, decryption, and digital signatures, shall be performed in a manner specified in FIPS 140-2. Users Managing users and their access rights introduces many requirements. First users must be uniquely identified and have that identity authenticated. Next a variety of access control measures, such as role based and time based, determine what a user is authorized to do. Administrators, the role with the rights to manage users and security, determine the access control settings in the field device. The field device shall support at least five user roles: Administrator, Auditor, Display, Engineer, and Operator. The field device vendor may choose to support additional user roles or allow an Administrator to create additional roles. An Administrator shall be able to assign a user to more than one role. Application Note: The Protection Profile includes definition of the Administrator and Auditor roles through a set of requirements for those roles. The Operator, Engineer and Display roles do not have specific requirements, and their authorization rights would be determined by the field device vendor and the asset owner configuration. The field device shall maintain at least the following information for each user account: unique userid, data required to verify authentication credentials, user role membership, time and date when account is to be disabled, time of days and days of the week the account is allowed to login to the field device. Page 3
Plain English Guide The field device shall require two-factor authentication for all users in the Administrator role. At least one of the authentication factors shall prevent replay of authentication data. The field device shall support setting a password complexity requirement for each role. The complexity requirement shall include the capability to require no password authentication for a role. The password complexity requirements shall be configurable by an Administrator. Application Note: This requirement supports setting a lenient password complexity or even no password required for users in the Display role and a highly secure password complexity requirement for Auditors and Engineers. The field device shall detect when a user fails to authenticate an Administrator selectable consecutive number of times and write a security event to an audit log. The field device shall not allow any user action until the user is authenticated. The field device shall only state the login attempt failed after a failed login attempt. Application Note: The field device must not indicate whether the userid or the authentication credentials were the cause of the login failure The field device shall detect when users authenticating in an Administrator role replay authentication data. This replayed authentication data shall result in a failed authentication and a security event shall be written to the audit log. Access Control After a user or system is authenticated, the field device must implement access control to determine and enforce what is allowed and disallowed. The field device shall implement access control to all data points, configuration parameters and other objects in the field device. The access control decision shall be based on a variety of factors that are configured by an Administrator. The field device shall support at least the following access control factors: user role, system location, and time of day / day of week. Application Note: The requirement for access control based on system location is sometimes referred to as station based access control. A common example of use would be to allow a user to perform more actions from the control center than from the corporate network. The field device shall deny access to all data points, configuration parameters and other objects in the field device unless expressly permitted by an Administrator. Application Note: This is a default least privilege configuration. All exported data from the field device shall include, retain and enforce the security functions that are present while the data is in the field device. Page 4
Data Authentication Plain English Guide The integrity status of process data, configuration settings, user data and audit logs must be maintained and periodically verified. Unauthorized modification of this data could be the result of an attack or a software or hardware failure. In all cases it is important for the Operators to know the data may be unreliable and the Administrators to know the field device may have been attacked. The field device shall detect when audit log data, process data, data related to configuration settings, and user data has been corrupted or modified without authorization. The field device shall write a security event to an audit log when a data authentication failure has been identified. All data imported into the field device shall have security fields that allow the field device to identify and verify the source of the data and verify the data has not been modified in transit. An imported data authentication failure shall generate a security event in an audit log. Application Note: Remote management, polling, commands and all other communication sent to the field device must have the source and data authenticated before being accepted by the field device. This will identify man-inthe-middle attacks and spoofing attacks. All data exported from the field device shall have security fields that allow the recipient to identify and verify the source of the data and verify the data has not been modified in transit. Application Note: This requirement has multiple impacts. Regular responses to polls and other commands require authentication of the source (the field device) and the content. This will identify man-in-the-middle attacks and spoofing attacks. The requirement also will protect the integrity of data that might be exported and used to configure other field devices, as a backup record, or for other management and maintenance purposes. Rollback Rollback allows an Administrator to quickly recover from configuration and other management errors. The field device must support rollback by an Administrator. Requirement: The field device shall support Administrator rollback of the last, or an Administrator specified number of, management and configuration changes. Application Note: The field device must support rollback of at least one change, but the field device vendor may allow an Administrator to select a higher number of changes to rollback. Rollback is not limited to security functions because most configuration changes can affect integrity and availability. Page 5
Management Plain English Guide Secure management of the field device is essential to secure operation. Only users in the Administrator role are allowed to manage the security related parameters in the field device. The sole exception to this is the Auditor role manages most of the security related audit settings. Each functional requirement may have one or more associated security management functions. The field device must be configured to be secure out-of-the-box with the security related parameters set to a high security value. Management of field device functions related to authentication, authorization, data integrity, software integrity, non-repudiation, and denial of service protection shall be restricted to users in the Administrator role. The default settings of all security related parameters shall be set to a restrictive value that represents a high security configuration. A user in the Administrator role shall be able to modify these settings. Application Note: This is similar to efforts being deployed in many software applications where the default is now a secure setting rather than a permissive setting. All of these security parameters and there settings must be documented in the Administrator Guidance. Self Protection The software and hardware in the field device must be protected against cyber and physical attacks. In many cases preventing attacks is not possible, but the field device must detect attacks on its integrity and not allow improper operation. Self-tests must be run at start-up, periodically and on Administrator request to identify errors in the field device software. These errors could be the result of an attack or system failure. Tests of the cryptographic functions and other security parameters must be included in the self tests because once these functions stop working the field device is unprotected. The field device shall implement and run a suite of self-tests to verify it is running correctly. These self-tests shall be run at start-up, periodically during normal operation at an Administrator specified interval, and at the request of an Administrator. The self tests shall include tests of all cryptographic functions. Any self-test failures shall generate a security event in an audit log. The field device shall fail secure unless failing secure conflicts with a fail safe operation. Fail safe shall take priority over fail secure. Fail secure shall not allow operation affected by the failure to continue until the failure is corrected. Failures Page 6
Plain English Guide include conditions that cause a reboot or the loss of available computing memory or storage. Application Note: There may be conditions where fail safe operation causes the field device to be an insecure state. The field device vendor should design the product to avoid or limit fail safe / fail secure conflicts, but the Protection Profile realizes this may be unavoidable in some circumstances. The field device shall attempt to auto-recover from a failure by restarting some or all of the processes. During this recovery period the field device shall not allow any operation until the field device returns to a secure state. The field device shall detect unauthorized modification or corruption to the executable code and configuration parameters in the field device. A security event shall be entered in the audit log that lists the affected code or parameters. Physical tampering with the field device must be identifiable in a physical inspection. Physical tampering shall generate a security related event in an audit log. Application Note: The Protection Profile requires the field device to be tamper evident, not tamper resistant or tamper proof. The distinctions and requirements are well defined and tested in FIPS 140-2. Denial of Service Protection It is impossible for a field device to stop all denial of service attacks. For example an attacker could use all available bandwidth and thereby prevent communication to the field device. The requirements in the Protection Profile focus on identifying and preventing denial of service attacks that aim to overwhelm computing resources in the field device. The field device shall assign a priority to each user and system that communicates with the field device. Use of all shareable resources, such as CPU and memory, shall be mediated on the basis of the assigned priorities. Application Note: System communication with the field device is often, but not always, run due to a user request. In this case the system would be assigned the priority of the users. Many control systems have system accounts that are not associated with a user, and these accounts must also be assigned a priority. An Administrator shall be able to assign maximum quotas for memory, processing power, and data storage for users and systems. The field device shall not allow the Administrator to configure the quotas to exceed a resources capability. The field device shall enforce the quota and issue a security related event to an audit log whenever the quota is reached. Page 7
Plain English Guide Time Source Time stamps are very important for field devices, and they must have access to a reliable time source. The field device shall be able to provide reliable time stamps for its own use. Application Note: The field device needs access to a reliable time source, but that time source does not need to be in the field device. Documentation Administrator Guidance Document The field device vendor must provide a document or set of documents that provides guidance on how to administer the field device in a secure manner. Requirement: The field device vendor shall provide an Administrator Guidance document. The document shall include: - A description of the administrative functions and interfaces - A list of all security parameters and recommended secure settings of these parameters. - All security events the field device generates and the related administrative action that should be taken. For example, an event indicating the audit log is almost full and how to save and clear the log. - A list of assumptions about user behavior necessary for secure operation. - A list of requirements for the IT environment the field device will reside in. User Guidance Document The field device vendor shall provide a document or set of documents that provides guidance for users that are not administrators. Requirement: The field device vendor shall provide a User Guidance document. The document shall include: - A description of the user-accessible security functions and the interfaces to these functions - A list of warnings related to user-accessible security functions that could affect the security of the field device - All user responsibilities necessary for the secure operation of a field device Page 8
Installation and Start-Up Procedures Plain English Guide Control of the field device changes from the vendor to the customer at delivery. The field device vendor is required to document the procedures to install and start-up the field device in a secure manner. This is a separate document from the User and Administrator Guidance documents. Requirement: The field device vendor shall provide a document with the procedures required for the secure installation and start-up of the field device. Field Device Product Development Secure Development Environment A member of the development team or someone with access to the development software, firmware or hardware could intentionally introduce a vulnerability into the field device. Examples include back doors, incorrect random number generation, fixed keys, and susceptibility to buffer overflows or other common attacks. The field device vendor shall have a documented development security program that covers the physical, procedural, personnel and other security measures to protect the confidentiality and integrity of the field device design and implementation. The field device vendor shall be able to provide evidence of compliance with the documented program and shall be available for audit. Design Documentation The field device vendor must have a documented set of requirements and a structured design process that insures the design meets this process. There are numerous assurance requirements related to the development methodology. The primary three requirements worthy of an end user review are the functional specification document, architectural design, and security design documentation. The field device vendor shall have a documented functional specification and make this available for inspection. The field device vendor shall have a documented architectural design that includes a description of the major subsystems and the interface between major subsystems. The document shall describe how the design meets all of the functional requirements and be available for inspection. The field device vendor shall identify and document all subsystems that play a role in meeting the security requirements. This security design document shall describe the security functions in the subsystem and be available for inspection. Page 9
Development Tools and Techniques Plain English Guide Development tools and techniques are used in the development of the field device. Examples include programming languages, runtime libraries, computer aided design (CAD) systems and implementation standards. These tools and techniques must be identified and all be well-defined. Well-defined implies industry standard or common tools and techniques that are easily considered applicable for the development without the need for further clarification. The field device vendor shall identify all development tools and only use tools that are well-defined. Configuration Management and Change Control The process of modifying the field device design or configuration must be well controlled to prevent unauthorized changes. Additionally, configuration management is involved in building one or more different versions of the product for delivery to customers. The process must uniquely identify each different build and configuration delivered by the vendor. The process must use an automated configuration management system to control changes and support generation of the field device. This process must include problem tracking for security flaws and their resolutions. When a valid distribution of the field device has been released by the vendor, the vendor must provide a means for the vendor and customer to identify any intentional or unintentional modification or corruption to the field device. The field device vendor shall use an automated configuration management system as part of the configuration management and change control process. The field device vendor shall document the configuration management and change control process, and this document shall be available for review and audit. This process shall also track all known security flaws and efforts at remediation of identified security flaws. The field device vendor shall have configuration management documentation for each unique version of the field device delivered to a customer that includes a configuration list with all components and parameters settings and an acceptance plan. The field device vendor shall identify and document all known security flaws and all security flaws corrected in the current version of the field device. Page 10
Plain English Guide The field device vendor shall provide a method for the vendor and customer to identify any modifications to a released version of the field device. Development Life Cycle There are opportunities for intentional and unintentional vulnerabilities to be added after the development phase of the field device product life cycle. For this reason the Protection Profile includes requirements for the entire product life cycle. The field device vendor shall describe the life cycle model used to develop and maintain the field device including the security controls and provide evidence the life cycle procedure is being followed. The life cycle procedure shall be available for audit. Fixing Security Vulnerabilities Security patches are an issue with most IT products. The SCADA community has had a mixed record on supporting security patches in the underlying operating system, related applications and the SCADA applications themselves. The Protection Profile requires the vendor have a documented program to correct identified flaws. Asset owners could include compliance with this program as a contractual obligation. The field device vendor shall have a documented flaw remediation procedure to address identified security vulnerabilities from any source. The procedure shall document how anyone can report a suspected flaw, how the flaw and remediation is tracked by the vendor, timelines for correcting the flaw, and how corrective actions (i.e. patches, administrative procedures, etc.) are provided to the purchasers of the field device. The process shall require a corrective action for each identified security flaw, and this correction is provided to all purchasers of the field device. Testing by the Developer The field device vendor is responsible for testing the field device and providing test documentation to prove proper implementation. Vendor testing required by the Protection Profile focuses on two areas: meeting the functional specifications and the interfaces between low-level modules in the field device. The functional testing demonstrates the field device satisfies the functional requirements, but it does not necessarily test that the field device does not identify or test additional Page 11
Plain English Guide functions that do not address functional requirements. The security of these additional functions is tested by the independent testing team. The vendor must document the test plan for each of the functional requirements. Where appropriate the vendor should test multiple functional requirements in various orders and frequency to test for resilience against timing attacks. The vendor must provide an analysis that the test plan adequately tests the functional requirements. The Protection Profile does not require exhaustive testing, with every possible value or option tested, but the vendor is responsible for proving the testing is appropriate. A field device, like most products, can be described as a set of low-level modules or subsystems, such as a CPU and input/output communication modules. There may be more than more than one low-level module on a module available for purchase in a field device. The vendor must identify the low-level modules in the design documentation and provide test documentation that the interface between these modules is as specified. The field device vendor shall provide testing documentation, including test plans, test procedure descriptions, expected test results and actual test results, for all field device functional requirements. The test documentation shall be available for audit. The field device vendor shall provide a document that shows an analysis of the testing that demonstrates the testing adequately covered all functional requirements. Independent Testing A testing group that is not part of the development team must repeat some or all of the functional testing by the Development group. The amount and type of testing is determined by this independent testing group. Additional tests may be developed and performed by the independent group if they believe it is required to verify correct implementation of the field device design. This group could be a Quality Assurance group in the vendor s organization or an independent lab. The field device vendor shall provide a test environment and test plans for independent testing. A group independent from the Development group shall exercise all or part of the test plans as required to verify the field device operates as specified. The test results shall be available for audit. The independent group shall consider if additional testing is required, and perform any testing they believe is required. The additional test plans, test procedure descriptions, expected test results and actual test results shall be documented and available for audit. Page 12
Vulnerability Assessment Plain English Guide The developer and independent testing verifies the field device works as specified in the functional requirements. The vulnerability assessment tests for exploitable vulnerabilities in the implementation, easily defeated security functions, vulnerabilities in recommended configuration parameters, vulnerabilities due to incorrect configuration, covert channels and a variety of other areas. The CCEVS introduces additional assurance requirements for the covert channel analysis. A covert channel is an unintended channel that provides information that may be used to help exploit the field device. The field device must be analyzed to identify any cover channels that leak critical security parameters. An independent third party shall perform a vulnerability assessment on the field device to determine if the field device can be exploited by a moderately skilled attacker. The assessor shall provide documentation that describes all tests, all test results, and any identified vulnerabilities. The field device vendor shall analyze the User Guidance, Administrator Guidance, and Installation Procedures to determine if there is clear, consistent and complete security guidance for all possible modes of operation. The guidance documentation shall include all assumptions about the environment and external security measures to maintain security. This analysis shall be documented and available for audit. The field device vendor or independent third party shall analyze the field device and identify any covert channels that leak critical security parameters. The analysis procedures and results must be documented, available for audit, and selectively validated by an independent third party. Page 13