4. Estructura Norma ISO 9001-2008
4.9 Realización del Producto
Control 1570
The allocation and use of privileged access rights should be restricted and controlled. 1571
Implementation guidance. 1572
The allocation of privileged access rights shall be controlled through a formal authorization process in 1573
accordance with the relevant access control policy (see control 9.1.1). The following steps should be 1574
considered: 1575
a) the privileged access rights associated with each system or process, e.g. operating system, 1576
database management system and each application and the users to whom they need to be 1577
allocated should be identified; 1578
b) privileged access rights should be allocated to users on a need-to-use basis and on an event- 1579
by-event basis in line with the access control policy (see 9.1.1), i.e. based on the minimum 1580
requirement for their functional roles; 1581
c) an authorization process and a record of all privileges allocated should be maintained. 1582
Privileged access rights should not be granted until the authorization process is complete; 1583
d) requirements for expiry of privileged access rights should be defined; 1584
e) privileged access rights should be assigned to a user ID different from those used for regular 1585
business activities. Regular business activities should not be performed from privileged 1586
accounts; 1587
f) the competences of users with privileged access rights should be reviewed regularly in order to 1588
verify if they are in line with their duties; 1589
g) specific procedures[ENH9] should be established and maintained in order to avoid the
1590
unauthorized use of generic administration user IDs, according to systems’ configuration 1591
capabilities; 1592
h) for generic administration user IDs, the confidentiality of secret authentication information 1593
should be maintained when shared (e.g. changing passwords frequently and as soon as 1594
possible when a privileged user leaves or changes job, communicating them among privileged 1595
users with appropriate mechanisms); and 1596
i) rights/privileges or accesses needed by an asset owner (or processes acting on behalf of 1597
asset owners) for the performance of specified tasks. 1598
The organization shall: (i) approve individual access privileges and enforces physical and logical 1599
access restrictions associated with changes to the IACS; and (ii) generate, retain, and review 1600
records reflecting all such changes. 1601
(1) The organization employs automated mechanisms to enforce access restrictions and 1602
support auditing of the enforcement actions. 1603
Implementation guidance 1604
Planned or unplanned changes to the hardware, software, and/or firmware components of the IACS 1605
can have significant effects on the overall security of the system. Accordingly, only qualif ied and 1606
authorized individuals obtain access to IACS components for purposes of initiating changes, 1607
including upgrades and modifications. 1608
1609
Other information 1610
Inappropriate use of system administration privileges (any feature or facility of an information system 1611
that enables the user to override system or application controls) is a major contributory factor to failures 1612 or breaches of systems. 1613 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
The organization should employ the concept of least privilege for specific duties and IACS (zones 1614
and conduits) in accordance with risk assessments as necessary to adequately mitigate risk to 1615
organizational operations, organizational assets and individuals. 1616
9.2.4 Management of secret authentication information of users
1617
Control 1618
The allocation of secret authentication information should be controlled through a formal management 1619
process. 1620
Implementation guidance 1621
The process should include the following requirements: 1622
a) users should be required to sign a statement to keep personal secret authentication information 1623
confidential and to keep group information (i.e. shared) secret authentication information solely 1624
within the members of the group; this signed statement may be included in the terms and 1625
conditions of employment (see 7.1.2); 1626
b) when users are required to maintain their own secret authentication information they should be 1627
provided initially with secure temporary secret authentication information`, which they are forced 1628
to change on first use; 1629
c) procedures should be established to verify the identity of a user prior to providing new, 1630
replacement or temporary secret authentication information; 1631
d) temporary secret authentication information should be given to users in a secure manner; the 1632
use of external parties or unprotected (clear text) electronic mail messages should be avoided; 1633
e) temporary secret authentication information should be unique to an individual and should not 1634
be guessable; 1635
f) users should acknowledge receipt of secret authentication information; 1636
g) default vendor secret authentication information should be altered following installation of 1637
systems or software. 1638
Identifiers are distinguished from the privileges which they permit an entity to perform within a 1639
specific IACS control domain/zone (see also 2.6, Authenticator Management). Where users 1640
function as a single group (e.g., control room operators), user identification may be role-based, 1641
group-based, or device-based. For some IACS, the capability for immediate operator interaction is 1642
critical. Local emergency actions for the IACS must not be hampered by identification 1643
requirements. Access to these systems may be restricted by appropriate compensating security 1644
mechanisms. Identifiers may be required on portions of the IACS but not necessarily the entire 1645
system. 1646
For very high SAL level IACS the requirement for maximum control is increased, not decreased. 1647
Security measures that have the potential to cause loss of control in process operations are not 1648
acceptable. In these cases, to maintain the higher SAL levels, compensating measures external 1649
to the IACS (e.g. additional physical security measures and/or enhanced personnel background 1650
checks) will be needed. In these cases, it may be possible to see a normally high SAL level IACS 1651
at a lower SAL 1 or 2 rating, depending upon the compensating controls. Lockout or loss of control 1652
due to security measures is not acceptable in high availability IACS. 1653
IACS authenticators include, for example, tokens, Public Key certificates, biometrics, passwords, 1654
physical keys, and key cards. IACS users should take reasonable measures to safeguard 1655
authenticators including maintaining possession of their individual authenticators, not loaning or 1656
sharing authenticators with others, and reporting lost or compromised authenticators immediately. 1657
In the case of a process or device, such users should also take measures to protect their IACS 1658 authenticators. 1659 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
If the IACS is required to have a high level of availability, measures must be taken to maintain this 1660
high level of availability (e.g. compensating physical controls, duplicate keys, supervisory 1661
override). Lockout or loss of control due to security measures is not acceptable. 1662
1663
Other information 1664
Passwords are a commonly used type of secret authentication information and are a common means 1665
of verifying a user’s identity. Other types of secret authentication information are cryptographic keys 1666
and other data stored on hardware tokens (e.g. smart cards) that produce authentication codes. 1667
9.2.5 Review of user access rights
1668
Control 1669
Asset owners should review users’ access rights at regular intervals. 1670
The organization reviews accounts [Assignment: organization-defined frequency, at least 1671
annually]. A history of account changes shall be maintained if only manually.
1672
(1) The organization has policies and procedures to terminate guest or temporary accounts 1673
after [Assignment: organization-defined time period for each type of account]. 1674
(2) The organization has policies and procedures to disable inactive accounts after 1675
[Assignment: organization-defined time period]. 1676
(3) The organization employs mechanisms to audit account creation, Modification, disabling, 1677
and termination actions and to notify, as required, appropriate individuals. 1678
Implementation guidance 1679
The review of access rights should consider the following: 1680
a) users’ access rights should be reviewed at regular intervals and after any changes, such as 1681
promotion, demotion or termination of employment (see 7); 1682
b) user access rights should be reviewed and re-allocated when moving from one role to another 1683
within the same organization; 1684
c) authorizations for privileged access rights should be reviewed at more frequent intervals; 1685
d) privilege allocations should be checked at regular intervals to ensure that unauthorized 1686
privileges have not been obtained; 1687
e) changes to privileged accounts should be logged for periodic review. 1688
Account management might include (i.e., individual, role, and system, device-based, and system), 1689
establishment of conditions for group membership, and assignment of associated authorizations. 1690
In certain IACS instances, where the organization has determined that individual accounts are 1691
unnecessary from a risk-analysis and/or regulatory aspect, shared accounts are acceptable as 1692
long as adequate compensating controls (such as limited physical access) are in place and 1693
documented. 1694
Non-user accounts (sometimes termed service accounts) that are utilized for process-to-process 1695
communication (for example, an HMI connecting to a database) typically require different security 1696
policies from human user accounts. 1697
The organization identifies authorized users of the IACS and specifies access rights/privileges. 1698
The organization grants access to the IACS based on: 1699
a) a valid need-to-know/need-to-share that is determined by assigned official duties and 1700
satisfying all functional and security criteria; and 1701 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
b) Intended system usage. The organization requires proper identification for requests to 1702
establish accounts and approves all such requests. 1703
c) The organization specifically authorizes and monitors the use of guest/anonymous accounts 1704
and removes, disables, or otherwise secures unnecessary accounts. Account managers are 1705
notified when IACS users are terminated or transferred and associated accounts are 1706
removed, disabled, or otherwise secured. 1707
d) Account managers are also notified when users’ IACS usage or need-to-know/need-to- 1708
share changes. In cases where accounts are role-based, i.e., the workstation, hardware, 1709
and/or field devices define a user role, access to the IACS includes physical security 1710
policies and procedures based on organization risk assessment. 1711
e) In cases where physical access to the workstation, hardware, and/or field devices predefine 1712
privileges, the organization implements physical security policies, and procedures based 1713
on organization risk assessment. Account management may include additional account 1714
types (e.g., role-based, device-based, attribute-based). The organization removes, 1715
changes, disables, or otherwise secures default accounts. 1716
Other information 1717
This control compensates for possible weaknesses in the execution of controls 9.2.1, 9.2.2 and 9.2.6. 1718
9.2.6 Removal or adjustment of access rights
1719
Control 1720
The access rights of all employees and external party users to information and information processing 1721
facilities shall be removed upon termination of their employment, contract or agreement, or adjusted 1722
upon change. 1723
Implementation guidance 1724
Upon termination, the access rights of an individual to information and assets associated with 1725
information processing facilities and services should be removed or suspended. This will determine 1726
whether it is necessary to remove access rights. Changes of employment should be reflected 1727
in removal of all access rights that were not approved for the new employment. The access rights that 1728
should be removed or adjusted include those of physical and logical access. Removal or adjustment 1729
can be done by removal, revocation or replacement of keys, identification cards, information processing 1730
facilities or subscriptions. Any documentation that identifies access rights of employees and 1731
contractors should reflect the removal or adjustment of access rights. If a departing employee or 1732
external party user has known passwords for user IDs remaining active, these should be changed 1733
upon termination or change of employment, contract or agreement. 1734
Access rights for information and assets associated with information processing facilities should be 1735
reduced or removed before the employment terminates or changes, depending on the evaluation 1736
of risk factors such as: 1737
a) whether the termination or change is initiated by the employee, the external party user or 1738
by management, and the reason for termination; 1739
b) the current responsibilities of the employee, external party user or any other user; 1740
c) the value of the assets currently accessible. 1741
d) other risk factors to be considered when reducing or removing access rights should include 1742
risk associated with disruption to IACS availability, plant protection, and plant opoerations. 1743
Other information 1744
In certain circumstances access rights may be allocated on the basis of being available to more people 1745
than the departing employee or external party user, e.g. group IDs. In such circumstances, departing 1746
individuals should be removed from any group access lists and arrangements should be made 1747 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
to advise all other employees and external party users involved to no longer share this information 1748
with the person departing. 1749
In cases of management-initiated termination, disgruntled employees or external party users can 1750
deliberately corrupt information or sabotage information processing facilities. In cases of persons 1751
resigning or being dismissed, they may be tempted to collect information for future use. 1752
The organization promptly removes from the access list personnel no longer requiring access to 1753
the facility where the IACS resides. Authorized access shall be adjusted for assignments in 1754
restricted areas or for personnel dismissal. 1755
1756
9.3 User responsibilities
1757
Objective: To make users accountable for safeguarding their authentication information.
9.3.1 Use of secret authentication information
1758
Control 1759
Users should be required to follow the organization’s practices in the use of secret authentication 1760
information. 1761
Implementation guidance 1762
All users should be advised to: 1763
a) keep secret authentication information confidential, ensuring that it is not divulged to any other 1764
parties, including people of authority; 1765
b) avoid keeping a record (e.g. on paper, software file or hand-held device) of secret 1766
authentication information, unless this can be stored securely and the method of storing has 1767
been approved (e.g. password vault); 1768
c) change secret authentication information whenever there is any indication of its possible 1769
compromise; 1770
d) when passwords are used as secret authentication information, select quality passwords with 1771
sufficient minimum length which are: 1772
1) easy to remember; 1773
2) not based on anything somebody else could easily guess or obtain using person related 1774
information, e.g. names, telephone numbers and dates of birth etc.; 1775
3) not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries); 1776
4) free of consecutive identical, all-numeric or all-alphabetic characters; 1777
5) if temporary, changed at the first log-on; 1778
Other information 1779
Provision of Single Sign On (SSO) or other secret authentication information management tools 1780
reduces the amount of secret authentication information that users are required to protect and thus 1781
can increase the effectiveness of this control. However, these tools can also increase the impact of 1782
disclosure of secret authentication information. 1783
9.4 System and application access control
1784
Objective: To prevent unauthorized access to systems and applications.
This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
9.4.1 Information access restriction