SSA-311

ISA Security Compliance Institute

System Security Assurance - Functional security assessment for systems, Version 1.82

Summary of Worksheets:
Overview Overview - this worksheet providing summary information about each worksheet
Tree Tree Structure - hierarchical summary of all requirements organized by the 7 Foundation Requirements
GEN General - General requirements
IAC ID & Auth Control - detailed requirements for 1st Foundation Requirement
UC Use Control - detailed requirements for 2nd Foundation Requirement
SI System Integrity - detailed requirements for 3rd Foundation Requirement
DC Data Confidentiality - detailed requirements for 4th Foundation Requirement
RDF Restricted Data Flow - detailed requirements for 5th Foundation Requirement
TRE Timely Response to Event - detailed requirements for 6th Foundation Requirement
RA Resource Availability - detailed requirements for 7th Foundation Requirement

Common structure used for all requirement worksheets:

Requirement ID - unique ID number assigned to each requirement for unobvious reference

Reference Name - unique name for each requirement that provides an indication of the scope / content
Requirement Description - text of the particular requirement
Validation Activity - defines activity that must be performed as part of the evaluation audit
Validation by Independent Test Required - is the auditor required to perform independent testing as part of the validation activity
Source of Requirement - documents source of the particular requirement
Security Level - specifies for what levels of ISASecure this requirement applies
Rationale, Supplemental Guidance, and Notes - Additional information on the requirement

Revision History
Version Date Changes
1.82 2014.02.10 Initial version published to http://www.ISASecure.org

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved.
 SSA-311 Functional security assessment for systems(v1_82).xlsx Tree

Section Reference ID and Name Security Level

Identification & Authentication Control

FSA-S-IAC-1 Human user identification and authentication 1, 2, 3, 4
FSA-S-IAC-1.1 Unique identification and authentication 2, 3, 4
FSA-S-IAC-1.2 Multifactor authentication for untrusted networks 3, 4
FSA-S-IAC-1.3 Multifactor authentication for all networks 4
FSA-S-IAC-2 Software process and device identification and authentication 2, 3, 4
FSA-S-IAC-2.1 Unique identification and authentication 3, 4
FSA-S-IAC-3 Account management 1, 2, 3, 4
FSA-S-IAC-3.1 Unified account management 3, 4
FSA-S-IAC-4 Identifier management 1, 2, 3, 4
FSA-S-IAC-5 Authenticator management 1, 2, 3, 4
FSA-S-IAC-5.1 Initialize authenticator content 1, 2, 3, 4
FSA-S-IAC-5.2 Change default authenticators 1, 2, 3, 4
FSA-S-IAC-5.3 Change/ refresh all authenticators periodically 1, 2, 3, 4
FSA-S-IAC-5.4 Protect authenticators 1, 2, 3, 4
FSA-S-IAC-5.5 Hardware security for software process identity credentials 3, 4
FSA-S-IAC-6 Wireless access management 1, 2, 3, 4
FSA-S-IAC-6.1 Unique identification and authentication 2, 3, 4
FSA-S-IAC-7 Strength of password-based authentication 1, 2, 3, 4
FSA-S-IAC-7.1 Password generation and lifetime restrictions for human 3, 4
FSA-S-IAC-7.2 Password lifetime restrictions for all users 4
FSA-S-IAC-8 Public key infrastructure (PKI) certificates 2, 3, 4
FSA-S-IAC-9 Strength of public key authentication 2, 3, 4
FSA-S-IAC-9.1 Check validity of signature of a given certificate 2, 3, 4
FSA-S-IAC-9.2 Construct a certification path to an accepted CA 2, 3, 4
FSA-S-IAC-9.3 Check a given certificates revocation status 2, 3, 4
FSA-S-IAC-9.4 Establish user control of private key 2, 3, 4
FSA-S-IAC-9.5 Map authenticated identity to a user 2, 3, 4
FSA-S-IAC-9.6 Hardware security for public key authentication 3, 4
FSA-S-IAC-10 Authenticator feedback 1, 2, 3, 4
FSA-S-IAC-11 Unsuccessful login attempts 1, 2, 3, 4
FSA-S-IAC-12 System use notification 1, 2, 3, 4
FSA-S-IAC-13 Access via untrusted networks 1, 2, 3, 4
FSA-S-IAC-13.1 Explicit access request approval 2, 3, 4
Use Control
FSA-S-UC-1 Authorization enforcement 1, 2, 3, 4
FSA-S-UC-1.1 Authorization enforcement for all users 2, 3, 4
FSA-S-UC-1.2 Permission mapping to roles 2, 3, 4
FSA-S-UC-1.3 Supervisor Override 3, 4
FSA-S-UC-1.4 Dual Approval 4
FSA-S-UC-2 Wireless use control 1, 2, 3, 4
FSA-S-UC-2.1 Identify and report unauthorized wireless devices 3, 4
FSA-S-UC-3 Use control for portable and mobile devices 1, 2, 3, 4
FSA-S-UC-3.1 Preventing the use of portable and mobile devices 1, 2, 3, 4
FSA-S-UC-3.2 Requiring context specific authorization 1, 2, 3, 4
FSA-S-UC-3-3 Restricting code and data transfer to/from portable and mobile devices 1, 2, 3, 4
FSA-S-UC-3.4 Enforcement of security status of portable and mobile devices 3, 4
FSA-S-UC-4 Mobile code 1, 2, 3, 4
FSA-S-UC-4.1 Preventing the execution of mobile code 1, 2, 3, 4
FSA-S-UC-4.2 Requiring proper authentication and authorization for origin of the code 1, 2, 3, 4
FSA-S-UC-4.3 Restricting mobile code transfer to/from the SUT 1, 2, 3, 4
FSA-S-UC-4.4 Monitoring the use of mobile code 1, 2, 3, 4
FSA-S-UC-4.5 Mobile code integrity check 3, 4
FSA-S-UC-5 Session lock 1, 2, 3, 4
FSA-S-UC-6 Remote session termination 2, 3, 4
FSA-S-UC-7 Concurrent session control 3, 4
FSA-S-UC-8 Auditable events 1, 2, 3, 4
FSA-S-UC-8.1 Centrally managed, system-wide audit trail 3, 4
FSA-S-UC-9 Audit storage capacity 1, 2, 3, 4
FSA-S-UC-9.1 Warn when audit record storage capacity threshold reached 3, 4
FSA-S-UC-10 Response to audit processing failures 1, 2, 3, 4
FSA-S-UC-11 Timestamps 2, 3, 4
FSA-S-UC-11.1 Internal time synchronization 3, 4
FSA-S-UC-11.2 Protection of time source integrity 4
FSA-S-UC-12 Non-repudiation 3, 4
FSA-S-UC-12.1 Non-repudiation for all users 4
System Integrity
FSA-S-SI-1 Communication integrity 1, 2, 3, 4
FSA-S-SI-1.1 Cryptographic Protection of Integrity 3, 4

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 2 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx Tree

Section Reference ID and Name Security Level

FSA-S-SI-2 Malicious code protection 1, 2, 3, 4

FSA-S-SI-2.1 Protection of entry and exit points 2, 3, 4
FSA-S-SI-2.2 Central Management and reporting 3, 4
FSA-S-SI-3 Security functionality verification 1, 2, 3, 4
FSA-S-SI-3.1 Automated security verification 3, 4
FSA-S-SI-3.2 Security verification during normal operation 4
FSA-S-SI-4 Software and information integrity 1, 2, 3, 4
FSA-S-SI-4.1 Automated notification about integrity violations 3, 4
FSA-S-SI-5 Input validation 1, 2, 3, 4
FSA-S-SI-6 Deterministic output 1, 2, 3, 4
FSA-S-SI-7 Error handling 2, 3, 4
FSA-S-SI-8 Session integrity 2, 3, 4
FSA-S-SI-8.1 Invalidation of session IDs after session termination 3, 4
FSA-S-SI-8.2 Unique session ID generation and recognition 3, 4
FSA-S-SI-8.3 Randomness of session IDs 4
FSA-S-SI-9 Protection of audit information 2, 3, 4
FSA-S-SI-9.1 Audit records on write-once media 4
Data Confidentiality
FSA-S-DC-1 Information confidentiality 1, 2, 3, 4
FSA-S-DC-1.1 Protection of confidentiality at rest or in transit via untrusted networks 2, 3, 4
FSA-S-DC-1.2 Protection of confidentiality across zone boundaries 4
FSA-S-DC-2 Information persistence 2, 3, 4
FSA-S-DC-2.1 Purging of shared memory resources 3, 4
FSA-S-DC-3 Use of cryptography 1, 2, 3, 4
Restricted Data Flow
FSA-S-RDF-1 Network Segmentation 1, 2, 3, 4
FSA-S-RDF-1.1 Physical network segmentation 2, 3, 4
FSA-S-RDF-1.2 Independence from non-SUT networks 3, 4
FSA-S-RDF-1.3 Logical and physical isolation of critical networks 3, 4
FSA-S-RDF-2 Zone Boundary protection 1, 2, 3, 4
FSA-S-RDF-2.1 Deny by default, allow by exception 2, 3, 4
FSA-S-RDF-2.2 Island Mode 3, 4
FSA-S-RDF-2.3 Fail Close 3, 4
FSA-S-RDF-3 General purpose person-to-person communication restrictions 1, 2, 3, 4
FSA-S-RDF-3.1 Prohibit all general purpose person-to-person communications 3, 4
FSA-S-RDF-4 Application Partitioning 1, 2, 3, 4
Timely Response to Event
FSA-S-TRE-1 Audit log accessibility 1, 2, 3, 4
FSA-S-TRE-1.1 Programmatic access to audit logs 3, 4
FSA-S-TRE-2 Continuous monitoring 2, 3, 4
Resource Availability
FSA-S-RA-1 Denial of Service Protection 1, 2, 3, 4
FSA-S-RA-1.1 Manage Communication Loads 2, 3, 4
FSA-S-RA-1.2 Limit (D)DoS effects to other systems or networks 3, 4
FSA-S-RA-2 Resource Management 1, 2, 3, 4
FSA-S-RA-3 Control System Backup 1, 2, 3, 4
FSA-S-RA-3.1 Backup verification 2, 3, 4
FSA-S-RA-3.2 Backup automation 3, 4
FSA-S-RA-4 SUT recovery and reconstitution 1, 2, 3, 4
FSA-S-RA-5 Emergency power 1, 2, 3, 4
FSA-S-RA-6 Network and security configuration settings 1, 2, 3, 4
FSA-S-RA-6.1 Machine-readable reporting of current security settings 3, 4
FSA-S-RA-7 Least functionality 1, 2, 3, 4
FSA-S-RA-8 SUT component inventory 2, 3, 4

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 3 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx IAC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
All human users need to be identified and authenticated for all access to the SUT. Authentication of the identity of these users
should be accomplished by using methods such as passwords, tokens, biometrics or, in the case of multifactor
authentication, some combination thereof. The geographic location of human users can also be used as part of the
authentication process. This requirement should be applied to both local and remote access to the SUT. In addition to
identifying and authenticating all human users at the SUT level (for example, at system logon), identification and
authentication mechanisms are often employed at the application level.
The SUT shall provide the capability to identify and Where human users function as a single group (such as control room operators), user identification and authentication may
authenticate all human users. This capability shall enforce Verify that the SUT can uniquely identify and authenticate all be role-based or group-based. For some SUTs, the capability for immediate operator interaction is critical. It is essential that
Human user
such identification and authentication on all interfaces which users at all accessible interfaces and record results as: local emergency actions ‑ as well
‑ ‑ as SUT essential functions not be hampered by identification or authentication requirements
FSA-S-IAC-1 identification and No ISA-62443-3-3: SR1.1 1, 2, 3, 4
provide human user access to the SUT to support segregation a. Supported, or (see clause 4 for a more complete discussion). Access to these systems may be restricted by appropriate physical security
authentication
of duties and least privilege in accordance with applicable b. Not Supported mechanisms (see ISA 62443 2 1 (99.02.01)). An example of such a situation is a critical operations room where strict
security policies and procedures. physical access control and monitoring is in place and where shift plans allocate responsibility to a group of users. These
users may then be using the same user identity. In addition, the designated operator workstation clients should be
authenticated (see 5.4, SR 1.2 – Software process and device ‑ identification
‑ ‑ and authentication) or the use of this shared
account should be limited to the constrained environment of the control room.
In order to support IAC policies, as defined according to ISA 62443 2 1 (99.02.01), the SUT verifies the identity of all human
users as a first step. In a second step, the permissions assigned to the identified human user are enforced (see 6.3, SR 2.1 –
Authorization enforcement).
Verify that the SUT can uniquely identify and authenticate all
Unique identification and The SUT shall provide the capability to uniquely identify and users at all user accessible interfaces and record results as:
FSA-S-IAC-1.1 No ISA-62443-3-3: SR1.1 (1) 2, 3, 4
authentication authenticate all human users. a. Supported, or
b. Not Supported

The SUT shall provide the capability to employ multifactor Verify that the SUT can provide the capability of multifactor
Multifactor authentication authentication for human user access to the SUT via an authentication for remote access and record results as:
FSA-S-IAC-1.2 No ISA-62443-3-3: SR1.1 (2) 3, 4 Note: Access via untrusted networks to SUT components should be enabled only when necessary and approved.
for untrusted networks untrusted network (see 5.15, SR 1.13 – Access via untrusted a. Supported, or
networks). b. Not Supported
Verify that the SUT can require multifactor authentication for
local access (e.g. access within the zone) and record results
Multifactor authentication The SUT shall provide the capability to employ multifactor
FSA-S-IAC-1.3 as: No ISA-62443-3-3: SR1.1 (3) 4
for all networks authentication for all human user access to the SUT.
a. Supported, or
b. Not Supported
The function of identification and authentication is to map an ID to an unknown software process or device (henceforth
referred to an entity in this sub-clause) so as to make it known before allowing any data exchange. Allowing rogue entities to
send and receive SUT specific data can result in detrimental behavior of the legitimate SUT. All entities need to be identified
and authenticated for all access to the SUT. Authentication of the identity of such entities should be accomplished by using
methods such as passwords, tokens or location (physical or logical). This requirement should be applied to both local and
remote access to the SUT. However, in some scenarios where individual entities are used to connect to different target
systems (for example, remote vendor support), it may be technical infeasible for an entity to have multiple identities. In these
cases, compensating countermeasures would have to be applied. Identification and authentication mechanisms for all entities
The SUT shall provide the capability to identify and Vendor shall provide list of all software processes and devices are needed to protect against attacks such as man-in-the-middle or message spoofing. In some cases, these mechanisms
authenticate all software processes and devices. This that can connect to the SUT. Verify that evidence exists that may involve multiple software processes running on the same physical server, each having their own identity. In other cases,
Software process and
capability shall enforce such identification and authentication identification and authentication is done for each listed process the identity may be bound to the physical device, such as all processes running on a given PLC. Special attention needs to be
FSA-S-IAC-2 device identification and No ISA-62443-3-3: SR1.2 2, 3, 4
on all interfaces which provide access to the SUT to support and device and record results as: made when identifying and authenticating portable and mobile devices. These types of devices are a known method of
authentication
least privilege in accordance with applicable security policies a. Supported, or introducing undesired network traffic, malware and/or information exposure to SUTs, including otherwise isolated networks.
and procedures. b. Not Supported Where entities function as a single group, identification and authentication may be role-based, group-based or entity-based. It
is essential that local emergency actions as well as SUT essential functions not be hampered by identification or
authentication requirements (see clause 4 for a more complete discussion). For example, in common protection and control
schemes, a group of devices jointly execute the protection functions and communicate with multicast messages ‑among‑ the ‑
devices in the group. In these cases, group authentication based on shared accounts or shared symmetric keys are
commonly used. In order to support identification and authentication control policies as defined according to ISA 62443 2 1
(99.02.01), the SUT verifies the identity of all entities as a first step. In a second step, the permissions assigned to the
identified entity are enforced (see 6.3, SR 2.1 – Authorization enforcement).

Vendor shall provide list of all software processes and devices

that can connect to the SUT. Verify that evidence exists that
Unique identification and The SUT shall provide the capability to uniquely identify and each process and device that can connect to the SUT has a
FSA-S-IAC-2.1 No ISA-62443-3-3: SR1.2 (1) 3, 4
authentication authenticate all software processes and devices. unique identification and record results as:
a. Supported, or
b. Not Supported

Account management may include grouping of accounts (for example, individual, role-based, device-based and system),
Verify SUT supports account management functions by an establishment of conditions for group membership and assignment of associated authorizations. In certain SUT instances,
The SUT shall provide the capability to support the administrator type role to establish, activate, modify, disable where individual accounts are determined to be unnecessary from a risk-analysis and/or regulatory aspect, shared accounts
FSA-S-IAC-3 Account management management of all accounts, including establishing, activating, and remove accounts and record results as: No ISA-62443-3-3: SR1.3 1, 2, 3, 4 are acceptable as long as adequate compensating controls (such as limited physical access) are in place and documented.
modifying, disabling and removing accounts. a. Supported, or Non-human user accounts (sometimes termed service accounts) that are utilized for process-to-process communication (for
b. Not Supported example, a human-machine interface (HMI) connecting to a database) typically require different security policies and
procedures from human user accounts.
Verify SUT supports unified account management functions to
establish, activate, modify, disable and remove accounts.
Unified account The SUT shall provide the capability to support unified account Verify that performing these functions on an account is
FSA-S-IAC-3.1 Yes ISA-62443-3-3: SR1.3 (1) 3, 4
management management applicable to all components of the system that support user
accounts and record results as:
a. Supported, or
Identifiers are distinguished from the privileges which they permit an entity to perform within a specific SUT control domain or
zone (see 6.3, SR 2.1 – Authorization enforcement). Where human users function as a single group (such as control room
operators), user identification may be role-based, group-based or device-based. For some SUTs, the capability for immediate
Verify user documents indicate that SUT allows managing
operator interaction is critical. Local emergency actions for the SUT should not be hampered by identification requirements.
The SUT shall provide the capability to support the identifiers by user, group, role and / or interface and record
Access to these systems may be restricted by appropriate compensating countermeasures. Identifiers may be required on
FSA-S-IAC-4 Identifier management management of identifiers (e.g. user ID) by user, group, role results as: No ISA-62443-3-3: SR1.4 1, 2, 3, 4
portions of the SUT but not necessarily the entire SUT. For example, wireless devices typically require identifiers, whereas
and/or SUT interface a. Supported, or
wired
‑ devices
‑ ‑ may not.
b. Not Supported
The management of identifiers will be determined by local policies and procedures established in compliance with
ISA 62443 2 1 (99.02.01).

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 4 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx IAC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
The SUT shall provide the capability to: In addition to an identifier (see 5.6, SR 1.4 – Identifier management) an authenticator is required to prove identity. SUT
a) initialize authenticator content; authenticators include, but are not limited to, tokens, symmetric keys, private keys (part of a public/private key pair),
b) change all default authenticators upon SUT installation; biometrics, passwords, physical keys and key cards. Human users should take reasonable measures to safeguard
Authenticator
FSA-S-IAC-5 c) change/refresh all authenticators; and See child requirements No ISA-62443-3-3: SR1.5 1, 2, 3, 4 authenticators, including maintaining possession of their individual authenticators, not loaning or sharing authenticators with
management
d) protect all authenticators from unauthorized disclosure and others and reporting lost or compromised authenticators immediately.
modification when stored and transmitted.

Verify user documents indicate ability to define initial

The SUT shall provide the capability to define initial
Initialize authenticator authentication content and record results as:
FSA-S-IAC-5.1 authenticator content; No ISA-62443-3-3: SR1.5 (a) 1, 2, 3, 4
content a. Supported, or
b. Not Supported
Verify user documents indicate ability to change default
Change default The SUT shall provide the capability to change default authenticators and record results as:
FSA-S-IAC-5.2 No ISA-62443-3-3: SR1.5 (b) 1, 2, 3, 4
authenticators authenticators upon SUT installation; a. Supported, or
b. Not Supported
Verify user documents indicate ability to change/refresh
Change/ refresh all
The SUT shall provide the capability to change/refresh authenticators and record results as:
FSA-S-IAC-5.3 authenticators No ISA-62443-3-3: SR1.5 (c) 1, 2, 3, 4
authenticators periodically; and a. Supported, or
periodically
b. Not Supported
Verify user documents indicate ability to protect authenticators
The SUT shall provide the capability to protect authenticators
from unauthorized disclosure and record results as:
FSA-S-IAC-5.4 Protect authenticators from unauthorized disclosure and modification when stored No ISA-62443-3-3: SR1.5 (d) 1, 2, 3, 4
a. Supported, or
and transmitted.
b. Not Supported

Verify user documents indicate ability to protect relevant

Hardware security for For software process and device users, the SUT shall provide authenticators with hardware mechanisms and record results
FSA-S-IAC-5.5 software process identity the capability to protect the relevant authenticators via as: No ISA-62443-3-3: SR1.5 (1) 3, 4
credentials hardware mechanisms. a. Supported, or
b. Not Supported

Review user documentation and determine if wireless

communication is supported on the SUT. If not record the
result as: Any wireless technology can, and in most cases should, be considered just another communication protocol option, and thus
a. Not Applicable subject to the same IACS security requirements as any other communication type utilized by the IACS. However, from a
If wireless is communication is supported vendor shall provide security point of view, there is at least one significant difference between wired and wireless communications: physical
The SUT shall provide the capability to identify and
Wireless access list of all software processes and devices that can connect to security countermeasures are typically less effective when using wireless. For this and possibly other reasons (for example
FSA-S-IAC-6 authenticate all users (humans, software processes or No ISA-62443-3-3: SR1.6 1, 2, 3, 4
management the SUT via the wireless connection. Verify that evidence regulatory differences), a risk analysis might legitimately result in a higher SL-T(IAC,SUT) for wireless communications
devices) engaged in wireless communication.
exists that identification and authentication is done for each versus a wired protocol being used in an identical use case.
listed process and device and for human users and record Wireless technologies include, but are not limited to, microwave, satellite, packet radio, Institute of Electrical and Electronics
results as: Engineers (IEEE) 802.11x, IEEE 802.15.4 (ZigBee, IEC 62591 – Wireless HART®, ISA 100.11a), IEEE 802.15.1 (Bluetooth),
a. Supported, or wireless LAN mobile routers, mobile phones with tethering and various infrared technologies.
b. Not Supported

Review user documentation and determine if wireless

communication is supported on the SUT. If not record the
result as:
a. Not Applicable
The SUT shall provide the capability to uniquely identify and If wireless is communication is supported vendor shall provide
Unique identification and
FSA-S-IAC-6.1 authenticate all users (humans, software processes or list of all software processes and devices that can connect to No ISA-62443-3-3: SR1.6 (1) 2, 3, 4
authentication
devices) engaged in wireless communication. the SUT via the wireless connection. Verify that evidence
exists that each process and device that can connect to the
SUT has a unique identification and record results as:
a. Supported, or
b. Not Supported

User authentication based on a username and a secret password is a very commonly used mechanism. Many attacks on
such mechanisms focus on guessing the password (for example, dictionary attacks or targeted social engineering) or
breaking the cryptographic protection of the stored password representation (for example, using rainbow tables or brute-
forcing a hash collision).
Increasing the size of the set of valid passwords by increasing the number of allowed characters makes such attacks more
For SUT utilizing password-based authentication, the SUT
Strength of password- complex, but only if the increased set size is actually used (generally users would tend to not include special characters in a
FSA-S-IAC-7 shall provide the capability to enforce password strength See child requirements No ISA-62443-3-3: SR1.7 1, 2, 3, 4
based authentication password as they are perceived harder to remember). Limiting the lifetime of a password decreases the window of opportunity
restrictions
for an attacker to breach a given password’s secrecy. In order to prevent users from circumventing this control by once
changing their password to a new one and then immediately changing back to their original password, a minimum lifetime for
a password is commonly enforced as well. A notification to change the password prior the expiration allows the user to
change the password at a convenient time according to process operations conditions.

The SUT shall provide the capability to prevent any given

human user account from reusing a password for a Verify user documents indicate that password re-use can be
This protection can be further enhanced by limiting the reuse of passwords (preventing small sets of alternating passwords),
Password generation configurable number of generations. In addition, the SUT shall limited for a specified number of generations and record
which further decreases the usefulness of a once-breached password. Extended protection beyond password based
FSA-S-IAC-7.1 and lifetime restrictions provide the capability to enforce password minimum and results as: No ISA-62443-3-3: SR1.7 (1) 3, 4
mechanisms can be achieved using multifactor authentication (see 4.3, SR 1.1 – Human user, process and device
for human users maximum lifetime restrictions for human users. These a. Supported, or
identification and authentication).
capabilities shall conform with commonly accepted security b. Not Supported
industry practices.
Verify user documents indicate that the SUT provides the
For SUT utilizing password-based authentication, the SUT capability to enforce password minimum and maximum lifetime
Password lifetime
FSA-S-IAC-7.2 shall provide the capability to enforce password minimum and restrictions for all users and record results as: No ISA-62443-3-3: SR1.7 (2) 4
restrictions for all users
maximum lifetime restrictions for all users a. Supported, or
b. Not Supported
Registration to receive a public key certificate needs to include authorization by a supervisor or a responsible official and
needs to be accomplished using a secure process that verifies the identity of the certificate holder and ensures that the
certificate is issued to the intended party. Any latency induced from the use of public key certificates should not degrade the
Verify user documents indicate that the required public key
operational performance of the SUT.
authentication are supported if public key functionality is
Where PKI is utilized, the SUT shall provide the capability to The selection of an appropriate PKI should consider the organization’s certificate policy which should be based on the risk
Public key infrastructure offered and record results as:
FSA-S-IAC-8 operate a PKI according to commonly accepted best practices No ISA-62443-3-3: SR1.8 2, 3, 4 associated with a breach of confidentiality of the protected information. Guidance on the policy definition can be found in
(PKI) certificates a. Supported, or
or obtain public key certificates from an existing PKI. commonly accepted standards and guidelines, such as the Internet Engineering Task Force (IETF) Request for Comment
b. Not Supported, or
(RFC) 3647 [31] for X.509-based
‑ ‑ PKI.
‑ For example, the appropriate location of a certification authority (CA), whether within
c. NA - if public key is not supported
the SUT versus on the Internet, and the list of trusted CAs should be considered in the policy and depends on the network
architecture (see also ISA 62443 2 1 (99.02.01)).

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 5 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx IAC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
Public/private key cryptography strongly depends on the secrecy of a given subject’s private key and proper handling of the
For SUTs utilizing public key authentication, the SUT shall trust relationships. When verifying a trust between two entities based on public key authentication, it is essential to trace the
provide the capability to: public key certificate to a trusted entity. A common implementation error in certificate validation is to only check the validity of
a) validate certificates by checking the validity of the signature a certificate’s signature, but not checking the trust in the signer. In a PKI setting, a signer is trusted if they are a trusted CA or
of a given certificate; have a certificate issued by a trusted CA, thus all verifiers need to trace certificates presented to them back to a trusted CA. If
b) validate certificates by constructing a certification path to an such a chain of trusted CAs cannot be established, the presented certificate should not be trusted.
accepted certification authority (CA)CA or in the case of self- If self-signed certificates are used instead of a PKI, the certificate subject itself signed its certificate, thus there never is a
signed certificates by deploying leaf certificates to all hosts trusted third-party or CA. This should be compensated by deploying the self-signed public key certificates to all peers that
Strength of public key which communicate with the subject to which the certificate is need to validate them via an otherwise secured mechanism (for example, configuration of all peers in a trusted environment).
FSA-S-IAC-9 See child requirements No ISA-62443-3-3: SR1.9 2, 3, 4
authentication issued; Trusted certificates need to be distributed to peers through secure channels. During the validation process, a self-signed
c) validate certificates by checking a given certificate’s certificate should only be trusted if it is already present in the list of trusted certificates of the validating peer. The set of
revocation status; trusted certificates should be configured to the minimum necessary set.
d) establish user (human, software process or device) control In both cases, validation needs to also consider the possibility that a certificate is revoked. In a PKI setting this is typically
of the corresponding private key; and done by maintaining certificate revocation lists (CRLs) or running an online certificate status protocol (OCSP) server. When
e) map the authenticated identity to a user (human, software revocation checking is not available due to SUT constraints, mechanisms such as a short certificate lifetime can compensate
process or device). for the lack of timely revocation information. Note that short lifetime certificates can sometimes create significant operational
issues in a SUT environment.

Review user documentation and determine if public key

authentication is used. If not record results as:
a. Not applicable
If public key authentication is used, provide a certificate with
Check validity of
validate certificates by checking the validity of the signature of an invalid signature to a test system. Verity that the system
FSA-S-IAC-9.1 signature of a given Yes ISA-62443-3-3: SR1.9 (a) 2, 3, 4
a given certificate detects this problem and reports this problem to the user.
certificate
Verify that the connection is denied unless the user chooses to
allow the connection anyway and record results as:
a. Supported
b. Not Supported

Review user documentation and determine if public key

authentication is used. If not record results as:
a. Not applicable
If public key authentication is used, review design
validate certificates by constructing a certification path to an
documentation and determine if the system validates
Construct a certification accepted CA or in the case of self-signed certificates by
FSA-S-IAC-9.2 certificates by construction a certification path to an accepted No ISA-62443-3-3: SR1.9 (b) 2, 3, 4
path to an accepted CA deploying leaf certificates to all hosts which communicate with
CA or in the case of self-signed certificates, by deploying leaf
the subject to which the certificate is issued;
certificates to all hosts which communicate with the subject to
which the certificate is issued and record results as:
b. Supported
c. Not Supported

Review user documentation and determine if public key

authentication is used. If not record results as:
a. Not applicable
If public key authentication is used, provide a certificate with a
Check a given
validate certificates by checking a given certificate’s revocation revoked status. verify that the system detects this problem
FSA-S-IAC-9.3 certificates revocation Yes ISA-62443-3-3: SR1.9 (c) 2, 3, 4
status; and reports this problem to the user. Verify that the
status
connection is denied unless the user chooses to allow the
connection anyway and record results as:
a. Supported
b. Not Supported
Review user documentation and determine if public key
authentication is used. If not record results as:
a. Not applicable
If public key authentication is used, provide a certificate with
Establish user control of establish user (human, software process or device) control of
FSA-S-IAC-9.4 an valid signature and non-revoked status to a test system. Yes ISA-62443-3-3: SR1.9 (d) 2, 3, 4
private key the corresponding private key
verify that the system allows this connection and accepts the
data from this server and record results as:
a. Supported
b. Not Supported

Map authenticated map the authenticated identity to a user (human, software

FSA-S-IAC-9.5 Test for FSA-S-IAC-9.4 covers this item as well Yes ISA-62443-3-3: SR1.9 (e) 2, 3, 4
identity to a user process or device)

Review user documentation and determine if public key

authentication is used. If not record results as:
a. Not applicable
If public key authentication is used, review design
The SUT shall provide the capability to protect the relevant
Hardware security for documentation if hardware mechanisms according to
FSA-S-IAC-9.6 private keys via hardware mechanisms according to commonly No ISA-62443-3-3: SR1.9 (1) 3, 4
public key authentication commonly accepted security industry practices and
accepted security industry practices and recommendations
recommendations are used to protect the relevant private keys
and record results as:
b. Supported
c. Not Supported
Verify SUT is capable of obscuring feedback of authentication Obscuring the feedback protects the information from possible exploitation by unauthorized individuals, for example,
The SUT shall provide the capability to obscure feedback of information and record results as: displaying asterisks or other random characters when a human user types in a password obscures feedback of authentication
FSA-S-IAC-10 Authenticator feedback No ISA-62443-3-3: SR1.10 1, 2, 3, 4
authentication information during the authentication process a. Supported, or information. The authenticating entity should not provide any hint as to the reason for the authentication failure, such as
b. Not Supported "unknown user name".
The SUT shall provide the capability to enforce a limit of a
configurable number of consecutive invalid access attempts by Verify SUT is capable of monitoring of unsuccessful login Due to the potential for denial of service, the number of consecutive invalid access attempts may be limited. If enabled, the
any user (human, software process or device) during a attempts with configurable ability to deny access permanently SUT may automatically reset to zero the number of access attempts after a predetermined time period established by the
configurable time period. The SUT shall provide the capability or for a configurable time period based on repeated applicable security policies and procedures. Resetting the access attempts to zero will allow users (human, process or
Unsuccessful login
FSA-S-IAC-11 to deny access for a specified period of time or until unlocked unsuccessful attempts and record results as: No ISA-62443-3-3: SR1.11 1, 2, 3, 4 device) to gain access if they have the correct login identifier. Automatic denial of access for SUT operator workstations or
attempts
by an administrator when this limit has been exceeded. For a. Supported, or nodes should not be used when immediate operator responses are required in emergency situations. All lockout mechanisms
system accounts on behalf of which critical services or servers b. Not Supported should consider functional requirements for continuous operations so as to mitigate adverse denial of service operating
are run, the SUT shall provide the capability to disallow conditions which could result in total system failure or injury to personnel.
interactive logons.

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 6 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx IAC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
Privacy and security policies and procedures need to be consistent with applicable laws, directives, policies, regulations,
standards and guidance. Often the main justification for this requirement is legal prosecution of violators and proving
intentional breach. This capability is thus necessary to support policy requirements, and does not improve IACS security.
System use notification messages can be implemented in the form of warning banners displayed when individuals log in to the
SUT. A warning banner implemented as a posted physical notice in the SUT facility does not protect against remote login
Verify SUT is capable of displaying user configurable system
The SUT shall provide the capability to display a configurable issues.
use notifications and records results as:
FSA-S-IAC-12 System use notification system use notification message before authenticating. No ISA-62443-3-3: SR1.12 1, 2, 3, 4 Examples of elements for inclusion in the system use notification message are:
a. Supported, or
a) that the individual is accessing a specific SUT;
b. Not Supported
b) that system usage may be monitored, recorded and subject to audit;
c) that unauthorized use of the system is prohibited and subject to criminal and/or civil penalties; and
d) that use of the system indicates consent to monitoring and recording.

Verify user documents include the capability to monitor and Examples of access to the SUT via untrusted networks typically include remote access methods (such as dial-up, broadband
control all forms of remote access via untrusted networks is and wireless) as well as connections from a company’s office (non-SUT) network. The SUT should restrict access achieved
Access via untrusted The SUT shall provide the capability to monitor and control all
FSA-S-IAC-13 supported and records results as: No ISA-62443-3-3: SR1.13 1, 2, 3, 4 through dial-up connections (for example, limiting dial-up access based upon the source of the request) or protect against
networks methods of access to the SUT via untrusted networks.
a. Supported, or unauthorized connections or subversion of authorized connections (for example, using virtual private network technology).
b. Not Supported Security policies and procedures may require multifactor authentication for remote user access to the SUT
Verify user documents include the capability to deny remote
The SUT shall provide the capability to deny remote access
Explicit access request access by default and record results as: Access via untrusted networks to geographically remote SUT component locations (for example, control centers and field
FSA-S-IAC-13.1 requests by default (e.g. access via untrusted networks) No ISA-62443-3-3: SR1.13 (1) 2, 3, 4
approval a. Supported, or locations) should only be enabled when necessary and authenticated.
unless explicitly approved by an assigned role.
b. Not Supported

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 7 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx UC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
Use control policies (for example, identity-based policies, role-based policies and rule-based policies) and associated
read/write access enforcement mechanisms (for example, access control lists, access control matrices and cryptography)
are employed to control usage between users (humans, software processes and devices) and objects (for example, devices,
files, records, software processes, programs and domains).
Verify SUT enforces authorizations for human users to control
On all interfaces, the SUT shall provide the capability to After the SUT has verified the identity of a user (human, software process or device) and SUT objects (see 4.3, SR 1.1 –
use of the SUT as configured by account management and
Authorization enforce authorizations assigned to all human users for Human user, software process and device identification and authentication), it also has to verify that a requested operation is
FSA-S-UC-1 record results as: No ISA-62443-3-3: SR2.1 1, 2, 3, 4
enforcement controlling use of the SUT to support segregation of duties actually permitted according to the defined security policies and procedures (for example, in a role-based access control
a. Supported, or
and least privilege. policy, the SUT would check which roles are assigned to a verified user or object and which privileges are assigned to these
b. Not Supported
roles – if the requested operation is covered by the permissions, it is executed, otherwise rejected). This allows the
enforcement of segregation of duties and least privileges. Usage enforcement mechanisms should not be allowed to
adversely affect the operational performance of the SUT.

Verify SUT enforces authorizations for processes and devices

to control use of the SUT as configured by account
On all interfaces, the SUT shall provide the capability to
management and record results as:
Authorization enforce authorizations assigned to all users (humans, ISA-62443-3-3: SR2.1
FSA-S-UC-1.1 a. Supported, or No 2, 3, 4
enforcement for all users software processes and devices) for controlling use of the (1)
b. Not Supported
SUT to support segregation of duties and least privilege.
c. Not applicable if software processes and devices are not
supported as users.
Verify SUT provides the capability to map permisions to roles
The SUT shall provide the capability for an authorized user or if authorized by a supervisory level account and record results Roles should not be limited to fixed nested hierarchies in which a higher level role is a super set of a lesser privileged role.
Permission mapping to ISA-62443-3-3: SR2.1
FSA-S-UC-1.2 role to modify the mapping of permissions to roles for human as: No 2, 3, 4 For example, a system administrator should not necessarily encompass operator privileges. This RE should be applicable to
roles (2)
users a. Supported, or software processes and devices as well.
b. Not Supported
Verify that the SUT can support a configurable time limit or
event sequence limit for supervisor manual override, if
The SUT shall support supervisor manual override of the provided, and record results as: NOTE Implementation of a controlled, audited and manual override of automated mechanisms in the event of emergencies
ISA-62443-3-3: SR2.1
FSA-S-UC-1.3 Supervisor Override current human user authorizations for a configurable time or a. Supported, or No 3, 4 or other serious events is often needed. This allows a supervisor to enable an operator to quickly react to unusual conditions
(3)
event sequence b. Not Supported, or without closing the current session and establishing a new session as a higher privilege user.
c. Not Applicable (if supervisor manual override is not
supported)
NOTE Dual approval should be limited to actions which require a very high level of confidence that they will be performed
Verify that the SUT can provide the capability of dual approval
reliably and correctly. Requiring dual approval provides emphasis to the seriousness of consequences that would result from
The SUT shall support dual approval where an action can if required and record reulsts as: ISA-62443-3-3: SR2.1
FSA-S-UC-1.4 Dual Approval No 4 failure of a correct action. An example of a situation in which dual approval is required would be a change to a set point of a
result in serious impact on the industrial process a. Supported, or (4)
critical process. Dual approval mechanisms should not be employed when an immediate response is necessary to safeguard
b. Not Supported
health, safety or environmental (HSE) consequences, for example, emergency shutdown of a process.

Any wireless technology can, and in most cases should, be considered just another communication protocol option, and thus
subject to the same IACS security requirements as any other communication type utilized by the IACS. However, a risk
Verify that the SUT can provide the capability to authorize,
analysis may result in a requirement for wireless IACS components to support higher use control capabilities than are
monitor and enforce usage restrictions for wireless
The SUT shall provide the capability to authorize, monitor and typically required of wired systems for the same use case and SL-T. Regulatory differences may also result in different
connectivity to the SUT per commonly accepted security
FSA-S-UC-2 Wireless use control enforce usage restrictions for wireless connectivity to the SUT No ISA-62443-3-3: SR2.2 1, 2, 3, 4 required capabilities between wired and wireless communications.
practices and record results as:
according to commonly accepted security industry practices. As noted in 5.8, SR 1.6 – Wireless access management, wireless technologies include, but are not limited to, microwave,
a. Supported, or
satellite, packet radio, IEEE 802.11x, IEEE 802.15.4 (ZigBee, IEC 62591 – WirelessHART®, ISA 100.11a), IEEE 802.15.1
b. Not Supported
(Bluetooth), wireless LAN mobile routers, mobile phones with tethering and various infrared technologies.

Place an unauthorized wireless device within the SUT physical

environment. Verify that the SUT identifies and reports that
the unauthorized device has been detected and record results
Identify and report The SUT shall provide the capability to identify and report
as:
FSA-S-UC-2.1 unauthorized wireless unauthorized wireless devices transmitting within the SUT Yes 3, 4
a. Supported
devices physical environment.
b. Not Supported
c. Not applicable if the system does not support wireless
communications.
The SUT shall provide the capability to automatically enforce Portable and mobile devices (such as USB drives, portable harddrives, laptops, etc.) may introduce undesired network
configurable usage restrictions that include: traffic, malware and/or information exposure, so there should be specific control associated with their usage in the typical
a) preventing the use of portable and mobile devices; SUT environment. Security policies and procedures may not allow certain functions or activities via portable and/or mobile
Use control for portable
FSA-S-UC-3 b) requiring context specific authorization; and No ISA-62443-3-3: SR2.3 1, 2, 3, 4 devices. Note: Protecting information residing on portable and mobile devices (for example, employing cryptographic
and mobile devices See Child Requirements
c) restricting code and data transfer to/from portable and mechanisms to provide confidentiality and integrity protections during storage and while in transit when outside of controlled
mobile devices. areas) is covered elsewhere (see Clause 7, FR 4 – Data confidentiality).

Review user documentation and verify that the SUT provides

Preventing the use of The control system shall provide the capability to automatically a means to prevent the use of portable and mobile devices
ISA-62443-3-3: SR2.3
FSA-S-UC-3.1 portable and mobile enforce configurable usage restrictions that include: and record the results as: No 1, 2, 3, 4
(a)
devices a) preventing the use of portable and mobile devices; a. Supported
b. Not Supported
Review user documentation and verify that the SUT provides
The control system shall provide the capability to automatically
a means to authorize the use of portable and mobile devices
Requiring context enforce configurable usage restrictions that include: ISA-62443-3-3: SR2.3
FSA-S-UC-3.2 in context specific situations and record the results as: No 1, 2, 3, 4
specific authorization b) requiring context specific authorization (b)
a. Supported
b. Not Supported

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 8 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx UC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)

Configure the system such that portable and mobile devices

are not permitted in a certain context. Connect such a device
The control system shall provide the capability to automatically
Restricting code and to the system within the prohibited context and attempt to
enforce configurable usage restrictions that include:
data transfer to/from transfer data between the device and the system. Verify that ISA-62443-3-3: SR2.3
FSA-S-UC-3.3 c) restricting code and data transfer to/from portable and Yes 1, 2, 3, 4
portable and mobile no data can be sent to or from this device and record results (c)
mobile devices.
devices as:
a. Supported
b. Not Supported
Identify the security requirements of the SUT (which can be
considered a zone). This information should be documented
in the security requirements specification for the system.
Review system documentation to verify that the system can
verify that each of these security requirements are met by any
portable or mobile devices attemting to connect to the SUT. If
Enforcement of security The SUT shall provide the capability to verify that portable or
it is not possible or easy to verify that a requirement is met ISA-62443-3-3: SR2.3
FSA-S-UC-3, 4 status of portable and mobile devices attempting to connect to a zone comply with No 3, 4
from the system documentation, then a test of the system may (1)
mobile devices the security requirements of that zone.
be conducted to verify that such a requirement has been met.
Record results as:
a. Supported
b. Not supported
c. Not applicable if portable or mobile devices cannot connect
to the system.
The SUT shall provide the capability to enforce usage
restrictions for mobile code technologies based on the
Mobile code technologies include, but are not limited to, Java, JavaScript, ActiveX, portable document format (PDF),
potential to cause damage to the SUT that include:
Postscript, Shockwave movies, Flash animations and VBScript. Usage restrictions apply to both the selection and use of
a) preventing the execution of mobile code;
mobile code installed on servers and mobile code downloaded and executed on individual workstations. Control procedures
FSA-S-UC-4 Mobile code b) requiring proper authentication and authorization for origin No ISA-62443-3-3: SR2.4 1, 2, 3, 4
See Child Requirements should prevent the development, acquisition or introduction of unacceptable mobile code within the SUT. For example,
of the code;
mobile code exchanges may be disallowed directly with the SUT, but may be allowed in a controlled adjacent environment
c) restricting mobile code transfer to/from the SUT; and
maintained by SUT personnel.
d) monitoring the use of mobile code.

The SUT shall provide the capability to enforce usage Review system documentation and verify that the execution of
restrictions for mobile code technologies based on the mobile code is always prevented or that there is a configurable
Preventing the execution potential to cause damage to the SUT that include: option to prevent such code from being transferred into the ISA-62443-3-3: SR2.4
FSA-S-UC-4.1 No 1, 2, 3, 4
of mobile code a) preventing the execution of mobile code; SUT and record results as: (a)
a. Supported, or
b. Not Supported

Review system documentation and verify that if the execution

The SUT shall provide the capability to enforce usage
of mobile code is allowed, then the mobile code must be
restrictions for mobile code technologies based on the
Requiring proper authenticated before it is allowed to run. In addition, verify
potential to cause damage to the SUT that include:
authentication and that there is authorization as to which interfaces the mobile ISA-62443-3-3: SR2.4
FSA-S-UC-4.2 b) requiring proper authentication and authorization for origin No 1, 2, 3, 4
authorization for origin of code can be transferred onto the SUT to execute. Record the (b)
of the code;
the code results as:
A. Supported, or
B. Not Supported

Connect a device to the SUT that contains mobile code not

The SUT shall provide the capability to enforce usage authorized to transfer to the SUT. Verify that the transfer is
restrictions for mobile code technologies based on the prevented and the user is notified of this occurrence. Record
Restricting mobile code potential to cause damage to the SUT that include: the results as: ISA-62443-3-3: SR2.4
FSA-S-UC-4.3 Yes 1, 2, 3, 4
transfer to/from the SUT c) restricting mobile code transfer to/from the SUT; and A. Supported (c)
B. Not Supported
C. Not applicable if the device does not allow any mobile code
to execute.
Connect a device to the SUT that contains mobile code
The SUT shall provide the capability to enforce usage authorized to transfer to the SUT. Verify that the transfer is
restrictions for mobile code technologies based on the successful and the user is notified of this occurrence. Record
Monitoring the use of potential to cause damage to the SUT that include: the results as: ISA-62443-3-3: SR2.4
FSA-S-UC-4.4 Yes 1, 2, 3, 4
mobile code A. Supported (d)
d) monitoring the use of mobile code. B. Not Supported
C. Not applicable if the device does not allow any mobile code
to execute.
Review system documentation and verify that there is an
integrity check that must be run before allowing mobile code
exectuion and record the results as:
Mobile code integrity The SUT shall provide the capability to verify integrity of the ISA-62443-3-3: SR2.4
FSA-S-UC-4.5 A. Supported, or No 3, 4
check mobile code before allowing code execution. (1)
B. Not supported, or
C. Not applicable if the device does not allow any mobile code
to execute.

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 9 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx UC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)

The SUT shall provide the capability to prevent further access The entity responsible for an SUT should employ session lock to prevent access to specified workstations or nodes. The
by initiating a session lock after a configurable time period of Verify user documents include evidence that Session Locking SUT should activate session lock mechanisms automatically after a configurable time period for designated workstations or
inactivity or manual initiation. The session lock shall remain in Timeout is supported and records results as: nodes. In some cases, session lock for SUT operator workstations or nodes is not advised (for example, sessions which are
FSA-S-UC-5 Session lock No ISA-62443-3-3: SR2.5 1, 2, 3, 4
effect until the human user or authorized supervisory a. Supported, or required for immediate operator responses in emergency situations). Session locks are not a substitute for logging out of the
personnel re-establishes access using appropriate b. Not Supported SUT. In situations where the SUT cannot support session lock, the responsible entity should employ appropriate
identification and authentication procedures. compensating controls (for example, providing increased physical security, personnel security and auditing measures).
Verify the SUT is able to be configured to automatically
A remote session is initiated whenever an SUT is accessed across the boundary of a zone defined by the asset owner based
The SUT shall provide the capability to terminate a remote terminate a remote session after a configurable time and
Remote session on their risk assessment. This requirement may be limited to sessions that are used for SUT monitoring and maintenance
FSA-S-UC-6 session either automatically after a configurable time period of records results as: No ISA-62443-3-3: SR2.6 2, 3, 4
termination activities (not critical operations) based on the risk assessment of the SUT and security policies and procedures. Some SUT
inactivity or manually by the user who initiated the session. a. Supported, or
or components may not allow sessions to be terminated
b. Not Supported
The SUT shall provide the capability to limit the number of Verify the SUT is able to be configured to limit the number of A resource starvation denial of service (DoS) might occur if a limit is not imposed. There is a trade-off between potentially
Concurrent session concurrent remote sessions per interface for any given user concurrent remote sessions and record results as: locking out a specific user versus locking out all users and services due to a lack of SUT resources. Product supplier and/or
FSA-S-UC-7 No ISA-624423-3-3: SR2.7 3, 4
control (human, software process or device) to a configurable number a. Supported, or systems integrator guidance is likely required to provide sufficient information as to how the number of sessions value should
of sessions. b. Not Supported be assigned.
The purpose of this requirement is to record the occurrence of important events which need to be audited as significant and
relevant to the security of the SUT. Auditing activity can affect SUT performance. The security audit function is usually
coordinated with the network health and status monitoring function which may be in a different zone. Commonly recognized
The SUT shall provide the capability to generate audit records Verify via user documtation SUT supports capability to and accepted checklists and configuration guides should be considered when compiling a list of auditable events. The
relevant to security for the following categories: access generate audit records for the following categories: access security policies and procedures should define auditable events that are adequate to support after-the-fact investigations of
control, request errors, operating system events, SUT events, control, request errors, system events, configuration changes, security incidents. In addition, audit records should be sufficient to monitor the effectiveness and proper operation of the
backup and restore events, configuration changes, potential potential reconnaissance activity and audit log events and security mechanisms utilized to meet the requirements in this standard.
FSA-S-UC-8 Auditable events No ISA-624423-3-3: SR2.8 1, 2, 3, 4
reconnaissance activity and audit log events. Individual audit record results as: It should be noted that the requirement for event recording is applicable within the given system functionality, specifically
records shall include the timestamp, source (originating a. Supported, or given system security requirements on a given level. For example, the requirement for recording of authentication events (in
device, software process or human user account), category, b. Partially Supported -if not all specified criteria, or the access control category) on a SL 1 system is only applicable to the level of authentication functionality required for SL 1
type, event ID and event result. c. Not Supported according to the requirements in clause 5. Events may occur in any SUT component (for example login events) or may be
observed by dedicated monitors. For example, port scanning might be detected by an intrusion detection system (IDS) or
intrusion prevention system (IPS).

The SUT shall provide the capability to centrally manage audit

events and to compile audit records from multiple components Verify via user documtation SUT supports capability to
throughout the SUT into a system-wide (logical or physical), compile audit records from multiple components throughout
Centrally managed, ISA-624423-3-3: SR2.8
FSA-S-UC-8.1 time-correlated audit trail. The SUT shall provide the capability the system and record results as: No 3, 4
system-wide audit trail (1)
to export these audit records in industry standard formats for a. Supported, or
analysis by standard commercial log analysis tools, for b. Not Supported
example, security information and event management (SIEM).

Review audit record storage cpactiy and determine how many

records can be stored. Estimate rate of audit record
The SUT shall allocate sufficient audit record storage capacity generation based on existing systems. Verify that there is
The SUT should provide sufficient audit storage capacity, taking into account retention policy, the auditing to be performed
according to commonly recognized recommendations for log sufficient storage for at least 30 days of audit information
and the online audit processing requirements. Guidelines to be considered could include the NIST Special Publication (SP)
FSA-S-UC-9 Audit storage capacity management and system configuration. The SUT shall based on record generation on existing systems. Review No ISA-624423-3-3: SR2.9 1, 2, 3, 4
800 92 [29]. The audit storage capacity should be sufficient to retain logs for a period of time required by applicable policies
provide auditing mechanisms to reduce the likelihood of such system documentation and verify that the SUT provides
and regulations or business requirements.
capacity being exceeded. mechanisms to reduce the likelihood of this capacity being
exceeded (such as warnings when approach the limit or
periodic archiving of audit records).

Review user documentation and confirm that the control

system will provide a warning when allocated audit record
Warn when audit record
storage volume reaches a configurable percentage of the ISA-624423-3-3: SR2.9
FSA-S-UC-9.1 storage capacity The control system shall provide the capability to issue a No 3, 4
maximum audit record storage capacity. Record results as: (1)
threshold reached warning when allocated audit record storage volume reaches
A. Supported
a configurable percentage of maximum audit record storage
B. Not Supported
capacity.
The SUT shall provide the capability to alert personnel and Verify user documents include evidence that audit function Audit generation typically occurs at the source of the event. Audit processing involves transmission, possible augmentation
prevent the loss of essential services and functions in the support the following for lack of storage space to record new (such as the addition of a timestamp) and persistent storage of the audit records. Audit processing failures include, for
Response to audit event of an audit processing failure. The SUT shall provide the events: overwrite oldest audit records and stop generating example, software or hardware errors, failures in the audit capturing mechanisms and audit storage capacity being reached
FSA-S-UC-10 No ISA-624423-3-3: SR2.10 1, 2, 3, 4
processing failures capability to support appropriate actions in response to an audit records and records results as: or exceeded. Guidelines to be considered when designing appropriate response actions may include the NIST SP800 92. It
audit processing failure according to commonly accepted a. Supported, or should be noted that either overwriting the oldest audit records or halting audit log generation are possible responses to audit
industry practices and recommendations. b. Not Supported storage capacity being exceeded but imply the loss of potentially essential forensic information.

Timestamps (including date and time) of audit records should be generated using internal system clocks. If system-wide time
Verify that system-wide audit records include timestamps by
synchronization is not present (which is typical in many installations), known offsets would be needed to support analysis of a
The SUT shall provide system generated timestamps for use looking at system audit logs and recorded results as:
FSA-S-UC-11 Timestamps No ISA-624423-3-3: SR2.11 2, 3, 4 sequence of events. In addition, synchronization of internally generated audit records with external events might require
in audit record generation. a. Supported, or
synchronization with a generally recognized external time source (such as the Global Positioning System (GPS), Global
b. Not Supported
Navigation Satellite System (GLONASS) and Galileo). The time source should be protected from unauthorized alteration.

Verify user documents include evidence that time

synchronization for Time Stamp is provided and record results
Internal time The SUT shall provide the capability to synchronize internal ISA-624423-3-3: SR2.11
FSA-S-UC-11.1 as: No 3, 4
synchronization system clocks at a configurable frequency. (1)
a. Supported, or
b. Not Supported

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 10 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx UC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
Verify user documents include evidence that time
synchronization for Time Stamp is protected from
Protection of time The time source shall be protected from unauthorized ISA-624423-3-3: SR2.11
FSA-S-UC-11.2 unauthorized alteration and record results as: No 4
source integrity alteration and shall cause an audit event upon alteration. (2)
a. Supported, or
b. Not Supported
Examples of particular actions taken by a user include performing operator actions, changing SUT configurations, creating
information, sending a message, approving information (such as indicating concurrence) and receiving a message. Non-
Verify user documents include evidence that documentation
repudiation protects against later false claims by a user of not having taken a specific action, by an author of not having
that the human user responsible for initiation of an event may
The SUT shall provide the capability to determine whether a authored a particular document, by a sender of not having transmitted a message, by a receiver of not having received a
FSA-S-UC-12 Non-repudiation be included in the audit records and records results as: No ISA-624423-3-3: SR2.12 3, 4
given human user took a particular action message or by a signatory of not having signed a document. Non-repudiation services can be used to determine if
a. Supported, or
information originated from a user, if a user took specific actions (for example, sending an email and approving a work order)
b. Not Supported
or received specific information. Non-repudiation services are obtained by employing various techniques or mechanisms (for
example, digital signatures, digital message receipts and timestamps).
Verify user documents include evidence that documentation
that the device or process responsible for initiation of an event
The SUT shall provide the capability to determine whether a
Non-repudiation for all (including process or device users) may be included in the ISA-624423-3-3: SR2.12
FSA-S-UC-12.1 given user (human, software process or device) took a No 4
users audit records and records results as: (1)
particular action.
a. Supported, or
b. Not Supported

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 11 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx SI

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)

Many common network attacks are based on the manipulation of data in transmission,
for example manipulation of network packets. Switched or routed networks provide a
greater opportunity for attackers to manipulate packets as undetected access to these
networks is generally easier and the switching and routing mechanisms themselves can
also be manipulated in order to get more access to transmitted information. Manipulation
in the context of a SUT could include the change of measurement values communicated
from a sensor to a receiver or the alteration of command parameters sent from a control
application to an actuator.
Depending on the context (for example transmission within a local network segment
versus transmission via untrusted networks) and the network type used in the
transmission (for example transmission control protocol (TCP) / internet protocol (IP)
The SUT shall provide the capability to protect the integrity of No validation activity needed as covered by validation of the versus local serial links), feasible and appropriate mechanisms will vary. On a small
FSA-S-SI-1 Communication integrity NA ISA-62443-3-3: SR3.1 1, 2, 3, 4
transmitted information. child requirements network with direct links (point-to-point), physical access protection to all nodes may be
sufficient on lower SLs if the endpoints’ integrity is protected as well (see 7.6, SR 3.4 –
Software and information integrity), while on a network distributed in areas with regular
physical presence of staff or on a wide area network physical access is likely not
enforceable. If a commercial service is used to provide communication services as a
commodity item rather than a fully dedicated service (for example a leased line versus a
T1 link), it may be more difficult to obtain the necessary assurances regarding the
implementation of needed security controls for communication integrity (for example
because of legal restrictions). When it is infeasible or impractical to meet the necessary
security requirements it may be appropriate to implement either appropriate
compensating countermeasures or explicitly accept the additional risk.

Examine design and user documents and determine if integrity

NOTE The use of cryptographic mechanisms to provide message authentication and
of mission critical data transmitted over communication
The SUT shall provide the capability to employ cryptographic integrity should be determined after careful consideration of the security needs and the
Cryptographic Protection channels is protected via cryptographic measures and record ISA-62443-3-3: SR3.1
FSA-S-SI-1.1 mechanisms to recognize changes to information during No 3, 4 potential ramifications on system performance and capability to recover from system
of Integrity results as: (1)
communication. failure. Alternative physical protection measures include, but are not limited to, protected
a. Supported, or
distribution systems.
b. Not Supported
The SUT should use protection mechanisms to prevent, detect, mitigate and report
instances of detected malicious code (for example, viruses, worms, Trojan horses and
spyware) transported by electronic mail, electronic mail attachments, Internet access,
removable media (for example, universal serial bus (USB) devices, diskettes or compact
disks), PDF documents, web services, network connections and infected laptops or
other common means.
Detection mechanisms should be able to detect integrity violations of application binaries
and data files. Techniques may include, but are not limited to, binary integrity and
attributes monitoring, hashing and signature techniques. Mitigation techniques may
The SUT shall provide the capability to employ protection include, but are not limited to, file cleaning, quarantining, file deletion, host
Malicious Code mechanisms to prevent, detect, report and mitigate the effects No validation activity needed as covered by validation of the communication restriction and IPSs.
FSA-S-SI-2 NA ISA-62443-3-3: SR3.2 1, 2, 3, 4
Protection of malicious code or unauthorized software. The SUT shall child requirements Prevention techniques may include, but are not limited to, application blacklisting and
provide the capability to update the protection mechanisms. whitelisting techniques, removable media control, sandbox techniques and specific
computing platforms mechanisms such as restricted firmware update capabilities, No
Execute (NX) bit, data execution prevention (DEP), address space layout randomization
(ASLR), stack corruption detection and mandatory access controls. See 10.4, SR 6.2 –
Continuous monitoring for an associated requirement involving SUT monitoring tools
and techniques.
Prevention and mitigation mechanisms may include those designed for host elements
(such as computers and servers) and network-based mechanisms (such as IDSs and
IPSs) and those mechanisms focused on SUT specific components (such as PLCs and
HMIs).
Verify SUT provides the capability to employ malicious code
Protection of entry and The SUT shall provide the capability to employ malicious code protection at zone boundaries and record results as: ISA-62443-3-3: SR3.2 Note: Mechanisms at this level may include removable media, firewalls, unidirectional
FSA-S-SI-2.1 No 2, 3, 4
exit points protection mechanisms at all entry and exit points a. Supported, or (1) gateways, web servers, proxy servers and remote-access servers.
b. Not Supported
Verify through design document review that the SUT provides
the capability to centrally manage malicious code protection
Central Management The SUT shall provide the capability to manage malicious ISA-62443-3-3: SR3.2 NOTE Such mechanisms may be provided by endpoint infrastructure centralized
FSA-S-SI-2.2 mechanisms and record results as: No 3, 4
and reporting code protection mechanisms. (2) management and SIEM solutions
a. Supported, or
b. Note Supported

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 12 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx SI

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)

The product supplier and/or system integrator should provide guidance on how to test
the designed security controls. Asset owners need to be aware of the possible
ramifications of running these verification tests during normal operations. Details of the
execution of these verifications need to be specified with careful consideration of the
requirements for continuous operations (for example, scheduling or prior notification).
Examples of security verification functions include:
The SUT shall provide the capability to support verification of • Verification of antivirus measures by European Institute for Computer Antivirus
the intended operation of security functions and report when Research (EICAR) testing of the SUT file system. Antivirus software should detect this
Security functionality anomalies are discovered during FAT, SAT and scheduled No validation activity needed as covered by validation of the and appropriate incident handling procedures should be triggered.
FSA-S-SI-3 NA ISA-62443-3-3: SR3.3 1, 2, 3, 4
verification maintenance. These security functions shall include all those child requirements • Verification of the identification, authentication and use control measures by attempting
necessary to support the security requirements specified in access with an unauthorized account (for some functionality this could be automated).
this standard. • Verification of IDSs as a security control by including a rule in the IDS that triggers on
irregular, but known non-malicious traffic. The test could then be performed by
introducing traffic that triggers this rule and the appropriate IDS monitoring and incident
handling procedures.
• Confirmation that audit logging is occurring as required by security policies and
procedures and has not been disabled by an internal or external entity

Verify SUT or SUT documentation provides methods to verify

The SUT shall provide the capability to employ automated security functions during FAT, SAT or scheduled maintenance
Automated security ISA-62443-3-3: SR3.3
FSA-S-SI-3.1 mechanisms to support management of security verification and record results as: No 3, 4
verification (1)
during FAT, SAT and scheduled maintenance a. Supported, or
b. Not Supported
Verify SUT provides methods to test security functions during
The SUT shall provide the capability to support verification of
Security verification normal operation and record results as: ISA-62443-3-3: SR3.3 NOTE This RE needs to be carefully implemented to avoid detrimental effects. May not
FSA-S-SI-3.2 the intended operation of security functions during normal No 4
during normal operation a. Supported, or (2) be suitable for safety systems.
operations
b. Not Supported
Unauthorized changes are changes for which the entity attempting the change does not
have the required privileges. This SR complements related SRs from FRs 1 and 2. FRs
Verify SUT or SUT documentation provides manual or
1 and 2 involve enforcing the roles, privileges and use patterns as designed. Integrity
automated integrity mechanisms (such as cryptographic
The SUT shall provide the capability to detect, record, report verification methods are employed to detect, record, report and protect against software
Software and hashes) to verify the integrity of critical SUT software and
FSA-S-SI-4 and protect against unauthorized changes to software and No ISA-62443-3-3: SR3.4 2, 3, 4 and information tampering that may occur if other protection mechanisms (such as
information integrity configuration information and record results as:
information at rest authorization enforcement) have been circumvented. The SUT should employ formal or
a. Supported, or
recommended integrity mechanisms (such as cryptographic hashes). For example, such
b. Not Supported
mechanisms could be used to monitor field devices for their latest configuration
information to detect security breaches (including unauthorized changes).

Verify SUT provides automated methods to verify software

The SUT shall provide automated tools that detect, record, and configuration integrity with automated notification and
Automated notification ISA-62443-3-3: SR3.4
FSA-S-SI-4.1 and provide notification to a configurable set of recipients record results as: No 3, 4
about integrity violations (1)
upon discovering discrepancies during integrity verification. a. Supported, or
b. Not Supported

Rules for checking the valid syntax of SUT inputs such as set points should be in place
to verify that this information has not been tampered with and is compliant with the
specification. Inputs passed to interpreters should be pre-screened to prevent the
Verify SUT or SUT documentation provides manual or content from being unintentionally interpreted as commands. Note that this is a security
automated methods to verify integrity of information from SR, thus it does not address human error, for example supplying a legitimate integer
The SUT shall validate the syntax and content of any input external sources and records results as: number which is outside the expected range.
FSA-S-SI-5 Input validation which is used as an industrial process control input or input a. Supported, or No ISA-62443-3-3: SR3.5 1, 2, 3, 4 Generally accepted industry practices for input data validation include out-of-range
that directly impacts the action of the SUT. b. Not Supported, or values for a defined field type, invalid characters in data fields, missing or incomplete
c. NA - SUT does not accept process control inputs from data and buffer overflow. Additional examples where invalid inputs lead to system
external sources security issues include SQL injection attacks, cross-site scripting or malformed packets
(as commonly generated by protocol fuzzers). Guidelines to be considered could include
the Open Web Application Security Project (OWASP) [33] Code Review Guide.

The deterministic behavior of SUT outputs as a result of threat actions against the SUT
is an important characteristic to ensure the integrity of normal operations. Ideally, the
SUT continues to operate normally while under attack, but if the SUT cannot maintain
Review system documentation and verify that the system will normal operation, then the SUT outputs need to fail to a predetermined state. The
The SUT shall provide the capability to set outputs to a set outputs to a predetermined state if normal operation can appropriate predetermined state of SUT outputs is application dependent and could be
FSA-S-SI-6 Deterministic output predetermined state if normal operation cannot be maintained not be maintained as a result of an attack. Record results as: No ISA-62443-3-3: SR3.6 1, 2, 3, 4 one of the following user configurable options:
as a result of an attack. a. Supported, or • Unpowered – the outputs fail to the unpowered state
b. Not Supported. • Hold – the outputs fail to the last-known good value
• Fixed – the outputs fail to a fixed value that is determined by the asset owner or an
application

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 13 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx SI

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)

The structure and content of error messages should be carefully considered by the
Verify that SUT error messages provide sufficient and
The SUT shall identify and handle error conditions in a product supplier and/or systems integrator. Error messages generated by the SUT
necessary information to assist plant personnel to identify and
manner such that effective remediation can occur. This shall should provide timely and useful information without revealing potentially harmful
diagnose system problems without revealing sensitive
be done in a manner which does not provide information that information that could be used by adversaries to exploit the IACS. Since it may be
FSA-S-SI-7 Error handling information that could be used by attackers to exploit the No ISA-62443-3-3: SR3.7 2, 3, 4
could be exploited by adversaries to attack the IACS unless unclear whether a particular error condition is due to a security event, all error messages
system and record results as:
revealing this information is necessary for the timely may need to be easily accessible during incident response. Disclosure of this information
a. Supported, or
troubleshooting of problems. should be justified by the necessity for timely resolution of error conditions. Guidelines
b. Not Supported
to be considered could include the OWASP Code Review Guide.
This control focuses on communications protection at the session, versus packet, level.
The intent of this control is to establish grounds for confidence at each end of a
communications session in the ongoing identity of the other party and in the validity of
The SUT shall provide the capability to protect the integrity of
No validation activity needed as covered by validation of the the information being transmitted. For example, this control addresses man-in-the-
FSA-S-SI-8 Session integrity sessions. The SUT shall reject any usage of invalid session NA ISA-62443-3-3: SR3.8 2, 3, 4
child requirements middle attacks including session hijacking or insertion of false information into a session
IDs.
or replay attacks. Use of session integrity mechanisms can have a significant overhead
and therefore their use must be considered in light of requirements for real-time
communications.
Verify that user session identifiers are invalidated upon user
Invalidation of session The SUT shall provide the capability to invalidate session IDs logout and record results as:
ISA-62443-3-3: SR3.8
FSA-S-SI-8.1 IDs after session upon user logout or other session termination (including a. Supported, or No 3, 4
(1)
termination browser sessions). b. Not Supported, or
c. NA - if does not support sessions or session IDs
Verify that user session identifiers are unique and that session
IDs not generated by the system are rejected and record
Unique session ID The SUT shall provide the capability to generate a unique
results as: ISA-62443-3-3: SR3.8
FSA-S-SI-8.2 generation and session ID for each session and treat all unexpected session No 3, 4
a. Supported, or (2)
recognition IDs as invalid
b. Not Supported, or
c. NA - if does not support sessions or session Ids
Verify that user session identifiers are generated by the NOTE Session hijacking and other man-in-the-middle attacks or injections of false
system with an accepted level of randomness and record information often take advantage of easy-to-guess session IDs (keys or other shared
Randomness of session The SUT shall provide the capability to generate unique results as: ISA-62443-3-3: SR3.8 secrets) or use of session IDs which were not properly invalidated after session
FSA-S-SI-8.3 No 4
IDs session IDs with commonly accepted sources of randomness a. Supported, or (3) termination. Therefore the validity of a session authenticator must be tightly connected to
b. Not Supported, or the lifetime of a session. Employing randomness in the generation of unique session IDs
c. NA - if does not support sessions or session Ids helps to protect against brute-force attacks to determine future session IDs
Review system documentation and verify that audit
information and audit tools (if present) require authorization in Audit information includes all information (for example, audit records, audit settings and
order to access, modify or delete. Attempt to delete an audit audit reports) needed to successfully audit SUT activity. The audit information is
Protection of audit The SUT shall protect audit information and audit tools (if
FSA-S-SI-9 log as an unauthorized user and verify that access is denied. Yes ISA-62443-3-3: SR3.9 2, 3, 4 important for error correction, security breach recovery, investigations and related
information present) from unauthorized access, modification and deletion.
Record results as: efforts. Mechanisms for enhanced protection against modification and deletion include
a. Supported, or the storage of audit information to hardware-enforced write-once media.
b. Not Supported
Review system documentation and verify that the system has
the capability to produce audit records on hardware enforced
Audit records on write- The SUT shall provide the capability to produce audit records ISA-62443-3-3: SR3.9
FSA-S-SI-9.1 write once media. Record results as: No 4
once media on hardware-enforced write-once media. (1)
a. Supported, or
b. Not supported

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 14 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx DC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)

Protection of information, at rest or in transit, can be

maintained through physical means, compartmentalization or
encryption, among other techniques. It is crucial that the
technique chosen considers the potential ramifications on
SUT performance and the capability to recover from system
failure or attack.
The decision whether the confidentiality of a given piece of
information should be protected or not depends on the context
Review system documentation and verify if the system has and cannot be made at product design. However, the fact that
the ability to protect the confidentiality of information for which an organization limits access to information by configuring
explicit read authorization is supported (either all of the time or explicit read authorizations in the SUT is an indicator that this
The SUT shall provide the capability to protect the
Information as a configurable option). If the user must configure or setup information is considered confidential by the organization.
FSA-S-DC-1 confidentiality of information for which explicit read No ISA-62443-3-3: SR4.1 1, 2, 3, 4
confidentiality the system in a certain manner to meet this requirement, Thus, all information for which the SUT supports the capability
authorization is supported, whether at rest or in transit.
verify that this is clearly documented in a user manual. to assign explicit read authorizations should be considered
Record the results as: potentially confidential and thus the SUT should also provide
a. Supported, or the capability to protect it.
b. Not Supported. Different organizations and industries may require different
levels of encryption strength for different categories of
information, based on the sensitivity of the information as well
as industry standards and regulatory requirements (see 8.5,
SR 4.3 – Use of cryptography). In some situations network
configuration information stored and processed in switches
and routers may be considered as confidential.

Review system documentation and verify if the system has

the ability to protect the confidentiality of information
Protection of
The SUT shall provide the capability to protect the traversing an untrusted network. If the user must configure or
confidentiality at rest or ISA-62443-3-3: SR4.1 NOTE Cryptography is a common mechanism for ensuring
FSA-S-DC-1.1 confidentiality of information at rest and remote access setup the system in a certain manner to meet this No 2, 3, 4
in transit via untrusted (1) information confidentiality.
sessions traversing an untrusted network. requirement, verify that this is clearly documented in a user
networks
manual. Record the results as:
a. Supported, or
b. Not Supported.

Review system documentation and verify if the system has

the ability to protect the confidentiality of information
Protection of traversing any zone boundary. If the user must configure or
The SUT shall provide the capability to protect the ISA-62443-3-3: SR4.1
FSA-S-DC-1.2 confidentiality across setup the system in a certain manner to meet this No 4
confidentiality of information traversing any zone boundary. (2)
zone boundaries requirement, verify that this is clearly documented in a user
manual. Record the results as:
a. Supported, or
b. Not Supported.
Removal of a SUT component from active service should not
provide the opportunity for unintentional release of information
for which explicit read authorization is supported. An example
of such information would include ‘join keys’ (in the case of
Review system documentation and verify that the system has some wireless field devices) stored in non-volatile storage or
the ability to purge all information for which explicit read other cryptographic information that would facilitate
The SUT shall provide the capability to purge all information
authorization is supported. Verify that the data is purged from unauthorized or malicious activity.
for which explicit read authorization is supported from
FSA-S-DC-2 Information persistence the system such that it can not be recreated. Record results No ISA-62443-3-3: SR4.2 2, 3, 4 Information produced by the actions of a user or role (or the
components to be released from active service and/or
as: actions of a software process acting on behalf of a user or
decommissioned.
a. Supported, or role) should not be disclosed to a different user or role in an
b. Not Supported uncontrolled fashion. Control of SUT information or data
persistence prevents information stored on a shared resource
from being unintentionally disclosed after that resource has
been released back to the SUT.

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 15 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx DC

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
NOTE Volatile memory resources are those which generally
Review system documentation and verify that confidential
do not retain information after being released to memory
information is purged from RAM before that memory is
management. However, there are attacks against random
released back to the SUT for use by a different user. Review
The SUT shall provide the capability to prevent unauthorized access memory (RAM) which might extract key material or
Purging of shared system documentation and verify that confidential information ISA-62443-3-3: SR4.2
FSA-S-DC-2.1 and unintended information transfer via volatile shared No 3, 4 other confidential data before it is actually over-written.
memory resources is not stored in memory that can be accessed by unauthorized (1)
memory resources. Therefore, when volatile shared memory is released back to
programs or users. Record results as:
the SUT for use by a different user, all unique data and
a. Supported, or
connections to unique data need to be purged from the
b. Not Supported
resource so it is not visible or accessible to the new user.
The selection of cryptographic protection should match the
value of the information being protected, the consequences of
the confidentiality of the information being breached, the time
period during which the information is confidential and the
SUT operating constraints. This can involve either information
at rest or in transit, or both. Note that backups are an example
of information at rest, and should be considered as part of a
data confidentiality assessment process. The SUT product
supplier should document the practices and procedures
Verify through design documentation that if the SUT uses relating to cryptographic key establishment and management.
cryptography then algorithms, key sizes and mechanisms for The SUT should utilize established and tested encryption and
If cryptography is required, the SUT shall use cryptographic key establishment are done according to commonly accepted hash algorithms, such as the advanced encryption standard
algorithms, key sizes and mechanisms for key establishment industry best practices and recommendations and record (AES) and the secure hash algorithms (SHA series), and key
FSA-S-DC-3 Use of cryptography No ISA-62443-3-3: SR4.3 1, 2, 3, 4
and management according to commonly accepted industry results as: sizes based on an assigned standard. Key generation needs
practices and recommendations a. Supported, to be performed using an effective random number generator.
b. Not Supported, or The security policies and procedures for key management
c. NA (cryptography is not used) need to address periodic key changes, key destruction, key
distribution and encryption key backup in accordance with
defined standards. Generally accepted practices and
recommendations can be found in standards such as NIST
SP800 57 [23].
This SR, along with 7.6, SR 4.4 – Public key infrastructure
certificates, may be applicable when meeting many other
requirements defined within this standard (for example,
Clauses 4 and 6).

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 16 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx RDF

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)

Network segmentation is used by organizations for a variety of purposes, including cyber security. The
main reasons for segmenting networks are to reduce the exposure, or ingress, of network traffic into a
SUT and reduce the spread, or egress, of network traffic from a SUT. This improves overall system
response and reliability as well as provides a measure of cyber security protection. It also allows different
network segments within the SUT, including critical SUTs and safety-related systems, to be segmented
from other systems for an additional level of protection. Access from the SUT to the World Wide Web
should be clearly justified based on SUT operational requirements.
Network segmentation and the level of protection it provides will vary greatly depending on the overall
network architecture used by an asset owner in their facility and even system integrators within their
The SUT shall provide the capability to segment SUT SUTs. Logically segmenting networks based on their functionality provides some measure of protection,
No validation activity needed as covered by validation of the
FSA-S-RDF-1 Network Segmentation networks from non-SUT networks and to segment critical SUT NA ISA-62443-3-3: SR5.1 1, 2, 3, 4 but may still lead to single-points-of-failure if a network device is compromised. Physically segmenting
child requirements
networks from other SUT networks networks provides another level of ‑ protection by removing that single-point-of-failure case, but will lead to
a more complex and costly network design. These trade-offs will need to be evaluated during the
network design process (see ISA 99.02.01).
In response to an incident, it may be necessary to break the connections between different network
segments. In that event, the services necessary to support essential operations should be maintained in
such a way that the devices can continue to operate properly and/or shutdown in an orderly manner. This
may require that some servers may need to be duplicated on the SUT network to support normal network
features, for example dynamic host configuration protocol (DHCP), domain name service (DNS) or local
CAs. It may also mean that some critical SUTs and safety-related systems be designed from the
beginning to be completely isolated from other networks.

Verify through user documentation that the SUT provides the

capability to segment SUT networks from non-SUT networks
The SUT shall provide the capability to physically segment
Physical network and to physically segment critical SUT networks from other ISA-62443-3-3: SR5.1
FSA-S-RDF-1.1 SUT networks from non-SUT networks and to physically No 2, 3, 4
segmentation SUT networks and record results as: (1)
segment critical SUT networks from non-critical SUT networks
a. Supported, or
b. Not Supported
Verify through user documentation that the SUT provides the
capability to provide network services to SUT networks
The SUT shall have the capability to provide network services
Independence from non- without a connection to non-SUT networks and record results ISA-62443-3-3: SR5.1
FSA-S-RDF-1.2 to SUT networks, critical or otherwise, without a connection to No 3, 4
SUT networks as: (2)
non-SUT networks
a. Supported, or
b. Not Supported
Verify through user documentation that the SUT provides the
capability to logically and physically segment critical SUT
Logical and physical
The SUT shall provide the capability to logically and physically networks from other critical SUT networks and record results ISA-62443-3-3: SR5.1
FSA-S-RDF-1.3 isolation of critical No 4
isolate critical SUT networks from non-critical SUT networks as: (3)
networks
a. Supported, or
b. Not Supported
Any connections to external networks or other SUTs should occur through managed interfaces consisting
of appropriate boundary protection devices (for example, proxies, gateways, routers, firewalls,
unidirectional gateways, guards and encrypted tunnels) arranged in an effective architecture (for
Verify that the SUT manages its external interfaces at any
The SUT shall provide the capability to monitor and control example, firewalls protecting application gateways residing on a DMZ). SUT boundary protections at any
zone boundary through an appropriate boundary device and
Zone Boundary communications at zone boundaries to enforce the designated alternate processing sites should provide the same levels of protection as that of the primary
FSA-S-RDF-2 record results as: No ISA-62443-3-3: SR5.2 1, 2, 3, 4
protection compartmentalization defined in the risk-based zones and site.
a. Supported
conduits model. As part of a defense-in-depth protection strategy, higher impact SUTs should be partitioned into separate
b. Not Supported
zones utilizing conduits to restrict or prohibit
‑ network access in accordance with security policies and
procedures and an assessment of risk. SL T(system) categorization guides the selection of appropriate
candidates for zone partitioning (see ISA 99.03.02 [8]).
Verify SUT boundary device settings are able to be configured
The SUT shall provide the capability to deny network traffic by based on permit by exception and record results as:
Deny by default, allow ISA-62443-3-3: SR5.2
FSA-S-RDF-2.1 default and allow network traffic by exception (also termed a. Supported , or No 2, 3, 4
by exception (1)
deny all, permit by exception). b. Not Supported

Verify through user documentation that SUT boundary device

has the capability to prevent any communication through the
The SUT shall provide the capability to prevent any NOTE Examples of when this capability may be used include where a security violation and/or breach
SUT boundary and record results as: ISA-62443-3-3: SR5.2
FSA-S-RDF-2.2 Island Mode communication through the SUT boundary (also termed island No 3, 4 has been detected within the SUT, or an attack is occurring at the enterprise level, This island mode
a. Supported, or (2)
mode). needs to support essential functions (see also clause 4.2, Support of essential functions).
b. Not Supported

The SUT shall provide the capability to prevent any Verify through user documentation that SUT boundary device
communication through the SUT boundary when there is an can be configured to prevent all access upon failure and
NOTE Examples of when this capability may be used include scenarios where a hardware failure or
operational failure of the boundary protection mechanisms record results as: ISA-62443-3-3: SR5.2
FSA-S-RDF-2.3 Fail Close No 3, 4 power failure causes boundary protection devices to function in a degraded mode or fail entirely. This fail
(also termed fail close). This ‘fail close’ functionality shall be a. Supported, or (3)
close needs to support essential functions (see also clause 4.2, Support of essential functions).
designed such that it does not interfere with the operation of a b. Not Supported
SIS or other safety-related functions

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 17 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx RDF

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
General purpose person-to-person communications systems include but are not limited to: email
systems, forms of social media (Twitter, Facebook, picture galleries, etc.) or any message systems that
permit the transmission of any type of executable file. These systems are usually utilized for private
purposes which are not related to SUT operations, and therefore the risks imposed by these systems
normally outweigh any perceived benefit.
These types of general purpose communications systems are commonly used attack vectors to introduce
malware to the SUT, pass information for which read authorization exists to locations external to the
SUT, and introduce excessive network loading that can be used to create security problems or launch
Review user documentation and verify that there is a method attacks on the SUT. Application of a broad range of other system requirements covering, for example,
to prevent general purpose person-to-person messages from usage restrictions and limiting data flow as described elsewhere in this document to general purpose
General purpose person- being received from users or systems external to the SUT. If person-to-person communication systems can provide adequate compensating countermeasures to meet
The SUT shall provide the capability to prevent general
to-person necessary to confirm that this requirement has been met, this requirement.
FSA-S-RDF-3 purpose person-to-person messages from being received No ISA-62443-3-3: SR5.3 1, 2, 3, 4
communication follow the described method and then attempt to receive a The SUT may provide the capability to utilize these types of two-way communication systems, but only
from users or systems external to the SUT.
restrictions person-to-person message. Record results as: between servers and/or workstations within the SUT. Note that this SR needs to support the
a. Supported, or requirements associated with 8.3, SR 4.1 – Information confidentiality.
b. Not supported. The SUT may also restrict email or other messaging solutions that provide internal computer-to-external
computer communications using outbound messages. These internal-to-external communications may be
limited to the purpose of sending system alerts or other computer generated information messages to
users or systems external to the SUT. To prevent the passing of information for which explicit read
authorization is supported, pre-configured messages (perhaps with the ability to include some limited
text) should be used to transmit the alerts or status information. Users may not be given the ability to
attach files or other information to these outbound-only messages at the time the messages are created
by the system.

Review user documentation and verify that there is a method

to prevent general purpose person-to-person messages from
being sent to users or systems external to the SUT. If
Prohibit all general The SUT shall provide the capability to prevent both
necessary to confirm that this requirement has been met, ISA-62443-3-3: SR5.3
FSA-S-RDF-3.1 purpose person-to- transmission and receipt of general purpose person-to-person No 3, 4
follow the described method and then attempt to send a (1)
person communications messages.
person-to-person message. Record results as:
a. Supported, or
b. Not supported.
Partitioning may be accomplished via physical or logical means through the use of different computers,
Verify SUT user documents include evidence that Application
different central processing units, different instances of the operating system, different network
The SUT shall provide the capability to support partitioning of Partitioning capability is included to support zoning models
addresses and combinations of these methods or other methods as appropriate. Examples of
FSA-S-RDF-4 Application Partitioning data, applications and services based on criticality to facilitate and record results as: No ISA-62443-3-3: SR5.4 1, 2, 3, 4
applications and services that could be considered for different partitions include, but are not limited to,
implementing a zoning model a. Supported, or
emergency and/or safety systems, closed-loop control applications, operator workstations and
b. Not Supported
engineering workstations.

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 18 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx TRE

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)

The SUT generates audit records about events occurring in

the system (see 6.10, SR 2.8 – Auditable events). Access to
these audit logs is necessary to support filtering audit logs,
identifying and removing information that is redundant,
reviewing and reporting activity during after-the-fact
investigations of security incidents. This access should not
Verify SUT provides a means to access audit logs and record
alter the original audit records. In general, audit reduction and
The SUT shall provide the capability for authorized humans results as:
FSA-S-TRE-1 Audit log accessibility No ISA-62443-3-3: SR6.1 1, 2, 3, 4 report generation should be performed on a separate
and/or tools to access audit logs on a read-only basis. a. Supported, or
information system. Manual access to the audit records (such
b. Not Supported
as screen views or printouts) is sufficient for meeting the base
requirement, but is insufficient for higher SLs. Programmatic
access is commonly used to provide the audit log information
to analysis mechanisms such as SIEM. See relevant SRs in
clauses 5, 6 and 9 regarding the creation of, protection of and
access to audit logs.

Verify via SUT documents the system supports API access to

Programmatic access to The SUT shall provide programmatic access to audit records audit logs and record results as: ISA-62443-3-3: SR6.1 NOTE This capability is necessary to ensure complete and
FSA-S-TRE-1.1 No 3, 4
audit logs using an application programming interface (API) a. Supported, or (1) timely response to security incidents
b. Not Supported

SUT monitoring capability can be achieved through a variety

of tools and techniques (for example, IDS, IPS, malicious
code protection mechanisms and network monitoring
mechanisms). As attacks become more sophisticated, these
monitoring tools and techniques will need to become more
sophisticated as well, including for example behavior-based
IDS/IPS.
Monitoring devices should be strategically deployed within the
SUT (for example, at selected perimeter locations and near
server farms supporting critical applications) to collect
Verify SUT provides the capability to continuously monitor essential information. Monitoring mechanisms may also be
The SUT shall provide the capability to continuously monitor
security mechanisms to detect attacks and record results as: deployed at ad hoc locations within the SUT to track specific
FSA-S-TRE-2 Continuous monitoring all security mechanism performance to detect, characterize, No ISA-62443-3-3: SR6.2 2, 3, 4
a. Supported, or transactions.
mitigate, and report security breaches in a timely manner.
b. Not Supported Monitoring should include appropriate reporting mechanisms
to allow for a timely response to events. To keep the reporting
focused and the amount of reported information to a level that
can be processed by the recipients, mechanisms such as
SIEM are commonly applied to correlate individual events into
aggregate reports which establish a larger context in which the
raw events occurred.
Additionally, these mechanisms can be used to track the
effect of security changes to the SUT (see 6.10, SR 2.8 –
Auditable events). Having forensic tools pre-installed can
facilitate incident analysis.

Copyright © 2013 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 19 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx RA

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
A variety of technologies exist to limit, or in some cases,
eliminate the effects of DoS situations. For example, boundary
protection devices can filter certain types of packets to protect
Denial of Service The SUT shall provide the capability to operate in a degraded No validation activity needed as covered by validation of the devices on an internal, trusted network from being directly
FSA-S-RA-1 NA ISA-62443-3-3: SR7.1 1, 2, 3, 4
Protection mode during a DoS event. child requirements affected by DoS events or restricting the information flow to be
unidirectional outbound. Specifically, as noted in clause 4, a
DoS event on the control system should not adversely impact
any safety-related systems.
Perform CRT testing based on storms directed at devices and
verify upstream services return to normal by end of test, and
downstream services are not adversely effected during the
test. See EDSA 310 for details of this testing.
The SUT shall provide the capability to manage
Manage Communication ISA-62443-3-3: SR7.1
FSA-S-RA-1.1 communication loads (such as using rate limiting) to mitigate Record the results as: Yes 2, 3, 4
Loads (1)
the effects of information flooding types of DoS events a. Supported, or
b. Not Supported

Note: Devices that have ISASecure certification are exempt

from testing
Verify through user or design documentation that the SUT
Limit DoS effects to The SUT shall provide the capability to restrict the ability of all provides the capability to restrict the ability of users to cause
ISA-62443-3-3: SR7.1
FSA-S-RA-1.2 other systems or users (humans, software processes and devices) to cause DoS events and record the results as: No 3,4
(2)
networks DoS events which affect other control systems or networks a. Supported, or
b. Not Supported
Resource management (for example, network segmentation
Verify through user or design documentation that the SUT or priority schemes) prevents a lower-priority software process
provides the capability of limiting the user of resources for from delaying or interfering with the SUT servicing any higher-
The SUT shall provide the capability to limit the use of
security functions such as virus scanning and patch priority software process. For example, initiating network
FSA-S-RA-2 Resource Management resources by security functions to prevent resource No ISA-62443-3-3: SR7.2 1, 2, 3, 4
management and record the results as: scans, patching and/or antivirus checks on an operating
exhaustion
a. Supported, or system can cause severe disruption to normal operations.
b. Not Supported Traffic rate limiting schemes should be considered as a
mitigation technique.
The availability of up-to-date backups is essential for recovery
from an SUT failure and/or mis-configuration. Automating this
Verify the SUT provides the ability to conduct backups of user- function ensures that all required files are captured, reducing
The identity and location of critical files and the ability to level and system-level information (including system state operator overhead. Although not usually required for SUT
conduct backups of user-level and system-level information information) without affecting normal plant operations and recovery, information required for post-incident forensic
FSA-S-RA-3 Control System Backup No ISA-62443-3-3: SR7.3 1, 2, 3, 4
(including system state information) shall be supported by the record the results as: activity (for example, audit logs) should be specifically
SUT without affecting normal plant operations. a. Supported, or included in the backup (see 9.4, SR 6.2 – SUT monitoring
b. Not Supported tools and techniques). If the resulting backups contain
confidential information, encryption should be considered (see
7.5, SR 4.3 – Use of cryptography).

Verify the SUT provides the capability to verify the reliability of

The SUT shall provide the capability to verify the reliability of backup mechanisms and record results as: ISA-62443-3-3: SR7.3
FSA-S-RA-3.1 Backup verification No 2, 3, 4
backup mechanisms a. Supported, or (1)
b. Not Supported

Review system documentation and verify that the system has

the ability to automate the backup function based on a
The SUT shall provide the capability to automate the backup ISA-62443-3-3: SR7.3
FSA-S-RA-3.2 Backup automation configurable frequency. Record results as: No 3,4
function based on a configurable frequency. (2)
a. Supported, or
b. Not Supported.
SUT recovery and reconstitution to a known secure state
means that all system parameters (either default or
configurable) are set to secure values, security-critical
The SUT shall provide the capability to recover and Verify user data restore functionality and record results as: patches are reinstalled, security-related configuration settings
SUT recovery and
FSA-S-RA-4 reconstitute to a known secure state after a disruption or a. Supported, or No ISA-62443-3-3: SR7.4 1, 2, 3, 4 are reestablished, system documentation and operating
reconstitution
failure b. Not Supported procedures are available, application and system software is
reinstalled and configured with secure settings, information
from the most recent, known secure backups is loaded and
the system is fully tested and functional.

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 20 of 21
 SSA-311 Functional security assessment for systems(v1_82).xlsx RA

Validation by
Requirement ID Reference Name Requirement Description Validation Activity Independent Test Source of Requirement Security Level Rationale, Supplemental Guidance, and Notes
Required (Yes/No)
There may be instances where compensating
Verify the SUT's ability to switch to and from an emergency countermeasures such as physical door access control may
The SUT shall provide the capability to switch to and from an power supply without affecting the existing security state and be affected by loss of base power supply, in which case the
FSA-S-RA-5 Emergency power emergency power supply without affecting the existing record the results as: Yes ISA-62443-3-3: SR7.5 1, 2, 3, 4 emergency power supply should cover those associated
security state or a documented degraded mode. a. Supported, or systems. If this is not possible, other compensating
b. Not Supported countermeasures may be needed during such an emergency
situation.

The SUT shall provide the capability to be configured These configuration settings are the adjustable parameters of
according to recommended network and security Review vendor documentation and record the results as: the SUT components. In order to be able to detect and correct
Network and security
FSA-S-RA-6 configurations as described in guidelines provided by the SUT a. Supported, or No ISA-62443-3-3: SR7.6 1, 2, 3, 4 any deviations from the approved and/or recommended
configuration settings
supplier. The SUT shall provide an interface to the currently b. Not Supported configuration settings, the SUT needs to support monitoring
deployed network and security configuration settings. and control of changes to the configuration settings in
accordance with security policies and procedures.
Verify that a report can be generated listing the currently
Machine-readable The SUT shall provide the capability to generate a report deployed security settings in a machine-readable format and
ISA-62443-3-3: SR7.6
FSA-S-RA-6.1 reporting of current listing the currently deployed security settings in a machine- record the results as: No 3,4
(1)
security settings readable format a. Supported, or
b. Not Supported
SUT are capable of providing a wide variety of functions and
services. Some of the functions and services provided may
not be necessary to support essential operations (for example,
key missions and functions). Therefore, by default, functions
Verify the SUT documentation provides guidance for how to beyond a baseline configuration should be disabled.
prohibit and/or restrict the use of unnecessary functions, Additionally, it is sometimes convenient to provide multiple
The SUT shall provide the capability to specifically prohibit
ports, protocols and/or other services and record the results services from a single component of an SUT, but doing so
FSA-S-RA-7 Least functionality and/or restrict the use of unnecessary functions, ports, No ISA-62443-3-3: SR7.7 1, 2, 3, 4
as: increases risk over limiting the services provided by any one
protocols and/or services
a. Supported, or component. Many functions and services commonly provided
b. Not Supported by commercial-off-the-shelf (COTS) equipment may be
candidates for elimination, for example, email, voice over
internet protocol (VoIP), instant messaging (IM), file transfer
protocol (FTP), hypertext transfer protocol (HTTP) and file
sharing.
A control system component inventory may include but is not
Verify the SUT provides the capability to report the current list
limited to component ID, capability and revision level. The
of installed components and their associated properties and
SUT component The SUT shall provide the capability to report the current list component inventory should be consistent with the SuC. A
FSA-S-RA-8 record the results as: No ISA-62443-3-3: SR7.8 2, 3, 4
inventory of installed components and their associated properties formal process of configuration
‑ management
‑ ‑ should be
a. Supported, or
deployed to keep control of the changes in the component
b. Not Supported
inventory baseline (see ISA 62443 2 1 (99.02.01)).

Copyright © 2014 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 21 of 21