Consistent use of subheaders
This commit is contained in:
parent
90ac17a99a
commit
2c59707ef5
90 changed files with 342 additions and 345 deletions
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.1 Policies for information security
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
At the highest level, the organization should define an "information security policy" which is approved by top management and which sets out the organization's approach to managing its information security.
|
||||
|
||||
The information security policy should take into consideration requirements derived from:
|
||||
|
|
@ -91,7 +91,7 @@ Level of detail | General or high-level | Specific and detailed
|
|||
Documented and formally approved by | Top management | Appropriate level of management
|
||||
|
||||
|
||||
#### Other information
|
||||
### Other information
|
||||
Topic-specific policies can vary across organizations.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
## 5.10 Acceptable use of information and other associated assets
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented and implemented.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure information and other associated assets are appropriately protected, used and handled.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Personnel and external party users using or having access to the organization’s information and other associated assets should be made aware of the information security requirements for protecting and handling the organization’s information and other associated assets. They should be responsible for their use of any information processing facilities.
|
||||
|
||||
The organization should establish a topic-specific policy on the acceptable use of information and other associated assets and communicate it to anyone who uses or handles information and other associated assets. The topic-specific policy on acceptable use should provide clear direction on how individuals are expected to use information and other associated assets. The topic-specific policy should state:
|
||||
|
|
@ -57,5 +57,5 @@ e\) clear marking of all copies of storage media (electronic or physical) for th
|
|||
|
||||
f\) authorization of disposal of information and other associated assets and supported deletion method(s) (see [8.10](a-8.10-Information-deletion.md)).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
It can be the case that the assets concerned do not directly belong to the organization, such as public cloud services. The use of such third-party assets and any assets of the organization associated with such external assets (e.g. information, software) should be identified as applicable and controlled, for example, through agreements with cloud service providers. Care should also be taken when a collaborative working environment is used.
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Personnel and other interested parties as appropriate should return all the organization’s assets in their possession upon change or termination of their employment, contract or agreement.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To protect the organization’s assets as part of the process of changing or terminating employment, contract or agreement.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
The change or termination process should be formalized to include the return of all previously issued physical and electronic assets owned by or entrusted to the organization.
|
||||
|
||||
|
|
@ -48,5 +48,5 @@ c\) specialist equipment;
|
|||
d\) authentication hardware (e.g. mechanical keys, physical tokens and smartcards) for information systems, sites and physical archives;
|
||||
e\) physical copies of information.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
It can be difficult to return information held on assets which are not owned by the organization. In such cases, it is necessary to restrict the use of information using other information security controls such as access rights management (5.18) or use of cryptography (8.24).
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.12 Classification of information
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Information should be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure identification and understanding of protection needs of information in accordance with its importance to the organization.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should establish a topic-specific policy on information classification and communicate it to all relevant interested parties.
|
||||
|
||||
The organization should take into account requirements for confidentiality, integrity and availability in the classification scheme.
|
||||
|
|
@ -49,7 +49,7 @@ The scheme should be consistent across the whole organization and included in it
|
|||
|
||||
The classification scheme used within the organization can be different from the schemes used by other organizations, even if the names for levels are similar. In addition, information moving between organizations can vary in classification depending on its context in each organization, even if their classification schemes are identical. Therefore, agreements with other organizations that include information sharing should include procedures to identify the classification of that information and to interpret the classification levels from other organizations. Correspondence between different schemes can be determined by looking for equivalence in the associated handling and protection methods.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Classification provides people who deal with information with a concise indication of how to handle and protect it. Creating groups of information with similar protection needs and specifying information security procedures that apply to all the information in each group facilitates this. This approach reduces the need for case-by-case risk assessment and custom design of controls.
|
||||
|
||||
Information can cease to be sensitive or critical after a certain period of time. For example, when the information has been made public, it no longer has confidentiality requirements but can still require protection for its integrity and availability properties. These aspects should be taken into account, as over-classification can lead to the implementation of unnecessary controls resulting in additional expense or, on the contrary, under-classification can lead to insufficient controls to protect the information from compromise.
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
An appropriate set of procedures for information labelling should be developed and implemented in accordance with the information classification scheme adopted by the organization.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To facilitate the communication of classification of information and support automation of information processing and management.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Procedures for information labelling should cover information and other associated assets in all formats. The labelling should reflect the classification scheme established in 5.12. The labels should be easily recognizable. The procedures should give guidance on where and how labels are attached in consideration of how the information is accessed or the assets are handled depending on the types of storage media. The procedures can define:
|
||||
|
||||
a\) cases where labelling is omitted (e.g. labelling of non-confidential information to reduce workloads);
|
||||
|
|
@ -61,7 +61,7 @@ Personnel and other interested parties should be made aware of labelling procedu
|
|||
|
||||
Output from systems containing information that is classified as being sensitive or critical should carry an appropriate classification label.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Labelling of classified information is a key requirement for information sharing.
|
||||
|
||||
Other useful metadata that can be attached to the information is which organizational process created the information and at what time.
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.14 Information transfer
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Information transfer rules, procedures, or agreements should be in place for all types of transfer facilities within the organization and between the organization and other parties.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To maintain the security of information transferred within an organization and with any external interested party.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
<u>General</u>
|
||||
The organization should establish and communicate a topic-specific policy on information transfer to all relevant interested parties. Rules, procedures and agreements to protect information in transit should reflect the classification of the information involved. Where information is transferred between the organization and third parties, transfer agreements (including recipient authentication) should be established and maintained to protect information in all forms in transit (see [5.10](a-5.10-Acceptable-use-of-information-and-other-associated-assets.md)).
|
||||
|
|
@ -156,6 +156,6 @@ e\) begin any sensitive conversations with a disclaimer so those present know th
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
No other information.
|
||||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 5.15 Access control
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Rules to control physical and logical access to information and other associated assets should be established and implemented based on business and information security requirements.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure authorized access and to prevent unauthorized access to information and other associated assets.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Owners of information and other associated assets should determine information security and business requirements related to access control. A topic-specific policy on access control should be defined which takes account of these requirements and should be communicated to all relevant interested parties.
|
||||
|
||||
These requirements and the topic-specific policy should consider the following:
|
||||
|
|
@ -67,7 +67,7 @@ c\) considering all types of available connections in distributed environments s
|
|||
|
||||
d\) considering how elements or factors relevant to dynamic access control can be reflected.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
There are often overarching principles used in the context of access control. Two of the most frequently used principles are:
|
||||
|
||||
|
|
|
|||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 5.16 Identity management
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The full life cycle of identities should be managed.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To allow for the unique identification of individuals and systems accessing the organization’s information and other associated assets and to enable appropriate assignment of access rights.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The processes used in the context of identity management should ensure that:
|
||||
|
||||
a\) for identities assigned to persons, a specific identity is only linked to a single person to be able to hold the person accountable for actions performed with this specific identity;
|
||||
|
|
@ -47,7 +47,7 @@ The organization should have a supporting process in place to handle changes to
|
|||
|
||||
When using identities provided or issued by third parties (e.g. social media credentials), the organization should ensure the third-party identities provide the required trust level and any associated risks are known and sufficiently treated. This can include controls related to the third parties (see [5.19](a-5.19-Information-security-in-supplier-relationships.md)) as well as controls related to associated authentication information (see [5.17](a-5.17-Authentication-information.md)).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Providing or revoking access to information and other associated assets is usually a multi-step procedure:
|
||||
|
||||
a\) confirming the business requirements for an identity to be established;
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ h) store and transmit passwords in protected form.
|
|||
|
||||
Password encryption and hashing should be performed according to approved cryptographic techniques for passwords (see [8.24](a-8.24-Use-of-cryptography.md)).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
Passwords or passphrases are a commonly used type of authentication information and are a common means of verifying a user’s identity. Other types of authentication information are cryptographic keys, data stored on hardware tokens (e.g. smart cards) that produce authentication codes and biometric data such as iris scans or fingerprints. Additional information can be found in the ISO/IEC 24760 series.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 5.18 Access rights
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure access to information and other associated assets is defined and authorized according to the business requirements.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
<u>Provision and revocation of access rights</u>
|
||||
The provisioning process for assigning or revoking physical and logical access rights granted to an entity’s authenticated identity should include:
|
||||
|
|
@ -71,7 +71,7 @@ b\) the current responsibilities of the user;
|
|||
|
||||
c\) the value of the assets currently accessible.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Consideration should be given to establishing user access roles based on business requirements that summarize a number of access rights into typical user access profiles. Access requests and reviews of access rights are easier managed at the level of such roles than at the level of particular rights.
|
||||
|
||||
Consideration should be given to including clauses in personnel contracts and service contracts that specify sanctions if unauthorized access is attempted by personnel (see [5.20](a-5.20-Addressing-information-security-within-supplier-agreements.md), [6.2](a-6.2-Terms-and-conditions-of-employment.md), [6.4](a-6.4-Disciplinary-process.md), [6.6](a-6.6-Confidentiality-or-non-disclosure-agreements.md)).
|
||||
|
|
|
|||
|
|
@ -24,15 +24,15 @@ status: active
|
|||
|
||||
## 5.19 Information security in supplier relationships
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
Processes and procedures should be defined and implemented to manage the information security risks associated with the use of supplier’s products or services.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
To maintain an agreed level of information security in supplier relationships.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
The organization should establish and communicate a topic-specific policy on supplier relationships to all relevant interested parties.
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ n\) level of personnel security and physical security expected from supplier's p
|
|||
|
||||
The procedures for continuing information processing in the event that the supplier becomes unable to supply its products or services (e.g. because of an incident, because the supplier is no longer in business, or no longer provides some components due to technology advancements) should be considered to avoid any delay in arranging replacement products or services (e.g. identifying an alternative supplier in advance or always using alternative suppliers).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
In cases where it is not possible for an organization to place requirements on a supplier, the organization should:
|
||||
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.20 Addressing information security within supplier agreements
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To maintain an agreed level of information security in supplier relationships.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Supplier agreements should be established and documented to ensure that there is clear understanding between the organization and the supplier regarding both parties’ obligations to fulfil relevant information security requirements.
|
||||
|
||||
The following terms can be considered for inclusion in the agreements in order to satisfy the identified information security requirements:
|
||||
|
|
@ -89,7 +89,7 @@ z\) ensuring, at the end of the contract, handover support to another supplier o
|
|||
|
||||
The organization should establish and maintain a register of agreements with external parties (e.g. contracts, memorandum of understanding, information-sharing agreements) to keep track of where their information is going. The organization should also regularly review, validate and update their agreements with external parties to ensure they are still required and fit for purpose with relevant information security clauses.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
The agreements can vary considerably for different organizations and among the different types of suppliers. Therefore, care should be taken to include all relevant requirements for addressing information security risks.
|
||||
|
||||
For details on supplier agreements, see ISO/IEC 27036 series. For cloud service agreements, see ISO/IEC 19086 series.
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.21 Managing information security in the ICT supply chain
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To maintain an agreed level of information security in supplier relationships.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
The following topics should be considered to address information security within ICT supply chain security in addition to the general information security requirements for supplier relationships:
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ l\) defining rules for sharing of information regarding the supply chain and any
|
|||
|
||||
m\) implementing specific processes for managing ICT component life cycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements. Identification of an alternative supplier and the process to transfer software and competence to the alternative supplier should be considered.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
The specific ICT supply chain risk management practices are built on top of general information security, quality, project management and system engineering practices but do not replace them.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
## 5.22 Monitoring, review, and change management of supplier services
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To maintain an agreed level of information security and service delivery in line with supplier agreements.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Monitoring, review and change management of supplier services should ensure the information security terms and conditions of the agreements are complied with, information security incidents and problems are managed properly and changes in supplier services or business status do not affect service delivery.
|
||||
|
||||
This should involve a process to manage the relationship between the organization and the supplier to:
|
||||
|
|
@ -77,5 +77,5 @@ m\) evaluate regularly that the suppliers maintain adequate information security
|
|||
|
||||
The responsibility for managing supplier relationships should be assigned to a designated individual or team. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate actions should be taken when deficiencies in the service delivery are observed.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
See ISO/IEC 27036-3 for more detail.
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.23 Information security for use of cloud services
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organization’s information security requirements.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To specify and manage information security for the use of cloud services.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
The organization should establish and communicate topic-specific policy on the use of cloud services to all relevant interested parties.
|
||||
|
||||
The organization should define and communicate how it intends to manage information security risks associated with the use of cloud services. It can be an extension or part of the existing approach for how an organization manages services provided by external parties (see [5.21](a-5.21-Managing-information-security-in-the-ICT-supply-chain.md), [5.22](a-5.22-Monitoring-review-and-change-management-of-supplier-services.md)).
|
||||
|
|
@ -71,7 +71,7 @@ c) use of peer cloud service providers or other sub-contractors (including chang
|
|||
The organization using cloud services should maintain close contact with its cloud service providers. These contacts enable mutual exchange of information about information security for the use of the cloud services including a mechanism for both cloud service provider and the organization, acting as the cloud service customer, to monitor each service characteristic and report failures to the commitments contained in the agreements.
|
||||
|
||||
|
||||
#### Other information
|
||||
### Other information
|
||||
This control considers cloud security from the perspective of the cloud service customer.
|
||||
|
||||
Additional information relating to cloud services can be found in ISO/IEC 17788, ISO/IEC 17789 and ISO/IEC 22123-1. Specifics related to cloud portability in support of exit strategies can be found in ISO/IEC 19941. Specifics related to information security and public cloud services are described in ISO/IEC 27017. Specifics related to PII protection in public clouds acting as PII processor are described in ISO/IEC 27018. Supplier relationships for cloud services are covered by ISO/IEC 27036-4 and cloud service agreements and their contents are dealt with in the ISO/IEC 19086 series, with security and privacy specifically covered by ISO/IEC 19086-4.
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
## 5.24 Information security incident management planning and preparation
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
|
||||
**Roles and responsibilities**
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ d\) creation of incident reports.
|
|||
|
||||
Any external requirements on reporting of incidents to relevant interested parties within the defined time frame (e.g. breach notification requirements to regulators) should be considered when implementing incident management procedures.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
Information security incidents can transcend organizational and national boundaries. To respond to such incidents, it is beneficial to coordinate response and share information about these incidents with external organizations as appropriate.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,12 +26,12 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The organization should assess information security events and decide if they are to be categorized as information security incidents.
|
||||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ To ensure effective categorization and prioritization of information security ev
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -49,5 +49,5 @@ Personnel responsible for coordinating and responding to information security in
|
|||
|
||||
Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
The ISO/IEC 27035 series provides further guidance on incident management.
|
||||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Information security incidents should be responded to in accordance with the documented procedures.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure efficient and effective response to information security incidents.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should establish and communicate procedures on information security incident response to all relevant interested parties.
|
||||
|
||||
Information security incidents should be responded to by a designated team with the required competency (see [5.24](a-5.24-Information-security-incident-management-planning-and-preparation.md)).
|
||||
|
|
@ -50,5 +50,5 @@ h\) conducting information security forensic analysis, as required (see [5.28](a
|
|||
i\) performing post-incident analysis to identify root cause. Ensure it is documented and communicated according to defined procedures (see [5.27](a-5.27-Learning-from-information-security-incidents.md));
|
||||
j\) identifying and managing information security vulnerabilities and weaknesses including those related to controls which have caused, contributed to or failed to prevent the incident.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
The ISO/IEC 27035 series provides further guidance on incident management.
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.27 Learning from information security incidents
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
Knowledge gained from information security incidents should be used to strengthen and improve the information security controls.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To reduce the likelihood or consequences of future incidents.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
The organization should establish procedures to quantify and monitor the types, volumes and costs of information security incidents.
|
||||
|
||||
The information gained from the evaluation of information security incidents should be used to:
|
||||
|
|
@ -41,6 +41,6 @@ b\) identify recurring or serious incidents and their causes to update the organ
|
|||
|
||||
c\) enhance user awareness and training (see [6.3](ISO_27002_2022_6.3_OT%20Information%20security%20awareness%2C%20education%20and%20training.md)) by providing examples of what can happen, how to respond to such incidents and how to avoid them in the future.
|
||||
|
||||
#### Other information
|
||||
### Other information
|
||||
|
||||
The ISO/IEC 27035 series provides further guidance.
|
||||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The organization should establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure a consistent and effective management of evidence related to information security incidents for the purposes of disciplinary and legal actions.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Internal procedures should be developed and followed when dealing with evidence related to information security events for the purposes of disciplinary and legal actions. The requirements of different jurisdictions should be considered to maximize chances of admission across the relevant jurisdictions.
|
||||
|
||||
In general, these procedures for the management of evidence should provide instructions for the identification, collection, acquisition and preservation of evidence in accordance with different types of storage media, devices and status of devices (i.e. powered on or off). Evidence typically needs to be collected in a manner that is admissible in the appropriate national courts of law or another disciplinary forum. It should be possible to show that:
|
||||
|
|
@ -47,7 +47,7 @@ Where available, certification or other relevant means of qualification of perso
|
|||
|
||||
Digital evidence can transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as digital evidence.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
When an information security event is first detected, it is not always obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve legal advice or law enforcement early in any contemplated legal action and take advice on the evidence required.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,13 +28,13 @@ status: active
|
|||
|
||||
## 5.29 Information security during disruption
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The organization should plan how to maintain information security at an appropriate level during disruption.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To protect information and other associated assets during disruption.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should determine its requirements for adapting information security controls during disruption. Information security requirements should be included in the business continuity management processes.
|
||||
|
||||
Plans should be developed, implemented, tested, reviewed and evaluated to maintain or restore the security of information of critical business processes following interruption or failure. Security of information should be restored at the required level and in the required time frames.
|
||||
|
|
@ -47,7 +47,7 @@ b\) processes to maintain existing information security controls during disrupti
|
|||
|
||||
c\) compensating controls for information security controls that cannot be maintained during disruption.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
In the context of business continuity and ICT continuity planning, it can be necessary to adapt the information security requirements depending on the type of disruption, compared to normal operational conditions. As part of the business impact analysis and risk assessment performed within business continuity management, the consequences of loss of confidentiality and integrity of information should be considered and prioritized in addition to the need for maintaining availability.
|
||||
|
||||
Information on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on business impact analysis (BIA) can be found in ISO/TS 22317.
|
||||
|
|
@ -19,11 +19,11 @@ status: active
|
|||
|
||||
## 5.30 ICT readiness for business continuity
|
||||
|
||||
## Purpose
|
||||
### Purpose
|
||||
|
||||
To ensure the availability of the organization’s information and other associated assets during disruption.
|
||||
|
||||
## Guidance
|
||||
### Guidance
|
||||
|
||||
ICT readiness for business continuity is an important component in business continuity management and information security management to ensure that the organization’s objectives can continue to be met during disruption.
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ c) ICT continuity plans include the following ICT continuity information:
|
|||
2) RTO of each prioritized ICT service and the procedures for restoring those components;
|
||||
3) RPO of the prioritized ICT resources defined as information and the procedures for restoring the information.
|
||||
|
||||
## Other **information**
|
||||
### Other information
|
||||
|
||||
Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to:
|
||||
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.31 Legal, statutory, regulatory and contractual requirements
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements should be identified, documented and kept up to date.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure compliance with legal, statutory, regulatory and contractual requirements related to information security.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
<u>General</u>
|
||||
External requirements including legal, statutory, regulatory or contractual requirements should be taken into consideration when:
|
||||
|
|
|
|||
|
|
@ -22,10 +22,10 @@ status: active
|
|||
|
||||
## 5.32 Intellectual property rights
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The organization should implement appropriate procedures to protect intellectual property rights.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights and use of proprietary products.
|
||||
|
||||
The following guidelines should be considered to protect any material that can be considered intellectual property:
|
||||
|
|
@ -54,7 +54,7 @@ k\) not duplicating, converting to another format or extracting from commercial
|
|||
|
||||
l\) not copying, in full or in part, standards (e.g. ISO/IEC International Standards), books, articles, reports or other documents, other than permitted by copyright law or the applicable licences.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licences.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
---
|
||||
## 5.33 Protection of records
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Records should be protected from loss, destruction, falsification, unauthorized access and unauthorized release.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure compliance with legal, statutory, regulatory and contractual requirements, as well as community or societal expectations related to the protection and availability of records.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should take the following steps to protect the authenticity, reliability, integrity and usability of records, as their business context and requirements for their management change over time:
|
||||
|
||||
a\) issue guidelines on the storage, handling chain of custody and disposal of records, which includes prevention of manipulation of records. These guidelines should be aligned with the organization’s topic-specific policy on records management and other records requirements;
|
||||
|
|
@ -49,7 +49,7 @@ Where electronic storage media are chosen, procedures to ensure the ability to a
|
|||
|
||||
Storage and handling procedures should be implemented in accordance with recommendations provided by manufacturers of storage media. Consideration should be given to the possibility of deterioration of media used for storage of records.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
Records document individual events or transactions or can form aggregations that have been designed to document work processes, activities or functions. They are both evidence of business activity and information assets. Any set of information, regardless of its structure or form, can be managed as a record. This includes information in the form of a document, a collection of data or other types of digital or analogue information which are created, captured and managed in the course of business.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,14 +26,13 @@ status: active
|
|||
|
||||
## 5.34 Privacy and protection of PII
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The organization should identify and meet the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure compliance with legal, statutory, regulatory and contractual requirements related to the information security aspects of the protection of PII.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should establish and communicate a topic-specific policy on privacy and protection of PII to all relevant interested parties.
|
||||
|
||||
The organization should develop and implement procedures for the preservation of privacy and protection of PII. These procedures should be communicated to all relevant interested parties involved in the processing of personally identifiable information.
|
||||
|
|
@ -44,7 +43,7 @@ Responsibility for handling PII should be dealt with taking into consideration r
|
|||
|
||||
Appropriate technical and organizational measures to protect PII should be implemented.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
A number of countries have introduced legislation placing controls on the collection, processing, transmission and deletion of PII. Depending on the respective national legislation, such controls can impose duties on those collecting, processing and disseminating PII and can also restrict the authority to transfer PII to other countries.
|
||||
|
||||
ISO/IEC 29100 provides a high-level framework for the protection of PII within ICT systems. Further information on privacy information management systems can be found in ISO/IEC 27701. Specific information regarding privacy information management for public clouds acting as PII processors can be found in ISO/IEC 27018.
|
||||
|
|
|
|||
|
|
@ -26,15 +26,13 @@ status: active
|
|||
|
||||
## 5.35 Independent review of information security
|
||||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The organization’s approach to managing information security and its implementation including people, processes and technologies should be reviewed independently at planned intervals, or when significant changes occur.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should have processes to conduct independent reviews.
|
||||
|
||||
Management should plan and initiate periodic independent reviews. The reviews should include assessing opportunities for improvement and the need for changes to the approach to information security, including the information security policy, topic-specific policies and other controls.
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
## 5.36 Compliance with policies, rules and standards for information security
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Compliance with the organization’s information security policy, topic-specific policies, rules and standards should be regularly reviewed.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure that information security is implemented and operated in accordance with the organization’s information security policy, topic-specific policies, rules and standards.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Managers, service, product or information owners should identify how to review that information security requirements defined in the information security policy, topic-specific policies, rules, standards and other applicable regulations are met. Automatic measurement and reporting tools should be considered for efficient regular review.
|
||||
|
||||
If any non-compliance is found as a result of the review, managers should:
|
||||
|
|
@ -49,5 +49,5 @@ Results of reviews and corrective actions carried out by managers, service, prod
|
|||
|
||||
Corrective actions should be completed in a timely manner as appropriate to the risk. If not completed by the next scheduled review, progress should at least be addressed at that review.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Operational monitoring of system use is covered in 8.15, 8.16, 8.17.
|
||||
|
|
@ -38,13 +38,13 @@ status: active
|
|||
|
||||
## 5.37 Documented operating procedures
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Operating procedures for information processing facilities should be documented and made available to personnel who need them.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure the correct and secure operation of information processing facilities.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Documented procedures should be prepared for the organization’s operational activities associated with information security, for example:
|
||||
|
||||
a\) when the activity needs to be performed in the same way by many people;
|
||||
|
|
@ -83,5 +83,5 @@ l\) maintenance instructions.
|
|||
|
||||
Documented operating procedures should be reviewed and updated when needed. Changes to documented operating procedures should be authorized. Where technically feasible, information systems should be managed consistently, using the same procedures, tools and utilities.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
No other information.
|
||||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 5.4 Management responsibilities
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
Management should require all personnel to apply information security in accordance with the established information security policy, topic-specific policies and procedures of the organization.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To ensure management understand their role in information security and undertake actions aiming to ensure all personnel are aware of and fulfill their information security responsibilities.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
Management should demonstrate support of the information security policy, topic-specific policies, procedures and information security controls.
|
||||
|
||||
Management responsibilities should include ensuring that personnel:
|
||||
|
|
@ -49,5 +49,5 @@ g) where practicable, are provided with a confidential channel for reporting
|
|||
|
||||
h) are provided with adequate resources and project planning time for implementing the organization’s security-related processes and controls.
|
||||
|
||||
#### Other information
|
||||
### Other information
|
||||
No other information.
|
||||
|
|
@ -30,18 +30,18 @@ status: active
|
|||
|
||||
## 5.5 Contact with authorities
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
The organization should establish and maintain contact with relevant authorities.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To ensure appropriate flow of information takes place with respect to information security between the organization and relevant legal, regulatory and supervisory authorities.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
The organization should specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner.
|
||||
|
||||
Contacts with authorities should also be used to facilitate the understanding about the current and upcoming expectations of these authorities (e.g. applicable information security regulations).
|
||||
|
||||
#### Other information
|
||||
### Other information
|
||||
Organizations under attack can request authorities to take action against the attack source.
|
||||
|
||||
Maintaining such contacts can be a requirement to support information security incident management (see 5.24 to 5.28) or the contingency planning and business continuity processes (see [5.29](a-5.29-Information-security-during-disruption.md), [5.30](a-5.30-ICT-readiness-for-business-continuity.md)). Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in relevant laws or regulations that affect the organization. Contacts with other authorities include utilities, emergency services, electricity suppliers and health and safety \[e.g. fire departments (in connection with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for equipment)\].
|
||||
|
|
|
|||
|
|
@ -27,13 +27,13 @@ status: active
|
|||
|
||||
## 5.6 Contact with special interest groups
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
The organization should establish and maintain contact with special interest groups or other specialist security forums and professional associations.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To ensure appropriate flow of information takes place with respect to information security.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
|
||||
Membership of special interest groups or forums should be considered as a means to:
|
||||
|
||||
|
|
@ -50,5 +50,5 @@ e) share and exchange information about new technologies, produ
|
|||
f) provide suitable liaison points when dealing with information security incidents (see 5.24 to 5.28).
|
||||
|
||||
|
||||
#### Other information
|
||||
### Other information
|
||||
No other information.
|
||||
|
|
@ -30,13 +30,13 @@ status: active
|
|||
|
||||
## 5.7 Threat intelligence
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
Information relating to information security threats should be collected and analysed to produce threat intelligence.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To provide awareness of the organization’s threat environment so that the appropriate mitigation actions can be taken.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
Information about existing or emerging threats is collected and analysed in order to:
|
||||
|
||||
a) facilitate informed actions to prevent the threats from causing harm to the organization;
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
## 5.8 Information security in project management
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
Information security should be integrated into project management.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes).
|
||||
|
||||
The project management in use should require that:
|
||||
|
|
@ -71,7 +71,7 @@ h) compliance with the legal, statutory, regulatory and contractual environme
|
|||
|
||||
i) level of confidence or assurance required for third parties to meet the organization’s information security policy and topic-specific policies including relevant security clauses in any agreements or contracts.
|
||||
|
||||
#### Other information
|
||||
### Other information
|
||||
The project development approach, such as waterfall life cycle or agile life cycle, should support information security in a structured way that can be adapted to suit the assessed severity of the information security risks, based on the character of the project. Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. ISO 21500 and ISO 21502 provide guidance on concepts and processes of project management that are important for the performance of projects.
|
||||
|
||||
ISO/IEC 27005 provides guidance on the use of risk management processes to identify controls to meet information security requirements.
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 5.9 Inventory of information and other associated assets
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
An inventory of information and other associated assets, including owners, should be developed and maintained.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
<u>Inventory</u>
|
||||
The organization should identify its information and other associated assets and determine their importance in terms of information security. Documentation should be maintained in dedicated or existing inventories as appropriate.
|
||||
|
|
@ -73,7 +73,7 @@ h\) they are involved in the identification and management of risks associated w
|
|||
|
||||
i\) they support personnel who have the roles and responsibilities of managing their information.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Inventories of information and other associated assets are often necessary to ensure the effective protection of information and can be required for other purposes, such as health and safety, insurance or financial reasons. Inventories of information and other associated assets also support risk management, audit activities, vulnerability management, incident response and recovery planning.
|
||||
|
||||
Tasks and responsibilities can be delegated (e.g. to a custodian looking after the assets on a daily basis), but the person or group who delegated them remains accountable.
|
||||
|
|
|
|||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 6.1 Screening
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Background verification checks on all candidates to become personnel should be carried out prior to joining the organization and on an ongoing basis taking into consideration applicable laws, regulations and ethics and be proportional to the business requirements, the classification of the information to be accessed and the perceived risks.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure all personnel are eligible and suitable for the roles for which they are considered and remain eligible and suitable during their employment.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
A screening process should be performed for all personnel including full-time, part-time and temporary staff. Where these individuals are contracted through suppliers of services, screening requirements should be included in the contractual agreements between the organization and the suppliers.
|
||||
|
||||
Information on all candidates being considered for positions within the organization should be collected and handled taking into consideration any appropriate legislation existing in the relevant jurisdiction. In some jurisdictions, the organization can be legally required to inform the candidates beforehand about the screening activities.
|
||||
|
|
@ -58,5 +58,5 @@ d\) termination of employment.
|
|||
|
||||
Verification checks should be repeated periodically to confirm ongoing suitability of personnel, depending on the criticality of a person’s role.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
No other information.
|
||||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 6.2 Terms and conditions of employment
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The employment contractual agreements should state the personnel’s and the organization’s responsibilities for information security.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure personnel understand their information security responsibilities for the roles for which they are considered.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The contractual obligations for personnel should take into consideration the organization’s information security policy and relevant topic-specific policies. In addition, the following points can be clarified and stated:
|
||||
|
||||
a\) confidentiality or non-disclosure agreements that personnel who are given access to confidential information should sign prior to being given access to information and other associated assets (see [6.6](a-6.6-Confidentiality-or-non-disclosure-agreements.md));
|
||||
|
|
@ -47,7 +47,7 @@ The organization should ensure that personnel agree to terms and conditions conc
|
|||
|
||||
Where appropriate, responsibilities contained within the terms and conditions of employment should continue for a defined period after the end of the employment (see [6.5](a-6.5-Responsibilities-after-termination-or-change-of-employment.md)).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
A code of conduct can be used to state personnel’s information security responsibilities regarding confidentiality, PII protection, ethics, appropriate use of the organization’s information and other associated assets, as well as reputable practices expected by the organization.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 6.3 Information security awareness, education and training
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Personnel of the organization and relevant interested parties should receive appropriate information security awareness, education and training and regular updates of the organization's information security policy, topic-specific policies and procedures, as relevant for their job function.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure personnel and relevant interested parties are aware of and fullfil their information security responsibilities.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
<u>General</u>
|
||||
An information security awareness, education and training programme should be established in line with the organization’s information security policy, topic-specific policies and relevant procedures on information security, taking into consideration the organization’s information to be protected and the information security controls that have been implemented to protect the information.
|
||||
|
|
@ -80,7 +80,7 @@ The education and training programme should consider different forms \[e.g. lect
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
When composing an awareness programme, it is important not only to focus on the ’what’ and ’how’, but also the ’why’, when possible. It is important that personnel understand the aim of information security and the potential effect, positive and negativ e, on the organization of their own behaviour.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ A disciplinary process should be formalized and communicated to take actions aga
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ To ensure personnel and other relevant interested parties understand the consequ
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ The response should take into consideration relevant legal, statutory, regulator
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 6.5 Responsibilities after termination or change of employment
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Information security responsibilities and duties that remain valid after termination or change of employment should be defined, enforced and communicated to relevant personnel and other interested parties.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To protect the organization’s interests as part of the process of changing or terminating employment or contracts.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The process for managing termination or change of employment should define which information security responsibilities and duties should remain valid after termination or change. This can include confidentiality of information, intellectual property and other knowledge obtained, as well as responsibilities contained within any other confidentiality agreement (see [6.6](a-6.6-Confidentiality-or-non-disclosure-agreements.md)). Responsibilities and duties still valid after termination of employment or contract should be contained in the individual’s terms and conditions of employment (see [6.2](a-6.2-Terms-and-conditions-of-employment.md)), contract or agreement. Other contracts or agreements that continue for a defined period after the end of the individual’s employment can also contain information security responsibilities.
|
||||
|
||||
Changes of responsibility or employment should be managed as the termination of the current responsibility or employment combined with the initiation of the new responsibility or employment.
|
||||
|
|
@ -41,5 +41,5 @@ A process should be established for the communication of the changes and of oper
|
|||
|
||||
The process for the termination or change of employment should also be applied to external personnel (i.e. suppliers) when a termination occurs of personnel, the contract or the job with the organization, or when there is a change of the job within the organization.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
In many organizations, the human resources function is generally responsible for the overall termination process and works together with the supervising manager of the person transitioning to manage the information security aspects of the relevant procedures. In the case of personnel provided through an external party (e.g. through a supplier), this termination process is undertaken by the external party in accordance with the contract between the organization and the external party.
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
Confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information should be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties.
|
||||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ To maintain confidentiality of information accessible by personnel or external p
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ Requirements for confidentiality and non-disclosure agreements should be reviewe
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ Security measures should be implemented when personnel are working remotely to p
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ To ensure the security of information when personnel are working remotely.
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ status: active
|
|||
## 6.8 Information security event reporting
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ The organization should provide a mechanism for personnel to report observed or
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ To support timely, consistent and effective reporting of information security ev
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ Personnel and users should be advised not to attempt to prove suspected informat
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -21,17 +21,17 @@ status: active
|
|||
---
|
||||
## 7.1 Physical security perimeters
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Security perimeters should be defined and used to protect areas that contain information and other associated assets.
|
||||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets.
|
||||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ c\) alarming, monitoring and testing all fire doors on a security perimeter in c
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Physical protection can be achieved by creating one or more physical barriers around the organization’s premises and information processing facilities.
|
||||
|
||||
A secure area can be a lockable office or several rooms surrounded by a continuous internal physical security barrier. Additional barriers and perimeters to control physical access can be necessary between areas with different security requirements inside the security perimeter. The organization should consider having physical security measures that can be strengthened during increased threat situations.
|
||||
|
|
@ -26,7 +26,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Storage media should be managed through their life cycle of acquisition, use, tr
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ To ensure only authorized disclosure, modification, removal or destruction of in
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -134,6 +134,6 @@ A risk assessment should be performed on damaged devices containing sensitive da
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
When confidential information on storage media is not encrypted, additional physical protection of the storage media should be considered.
|
||||
|
|
@ -27,7 +27,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ Information processing facilities should be protected from power failures and ot
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ To prevent loss, damage or compromise of information and other associated assets
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ Emergency lighting and communications should be provided. Emergency switches and
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ Cables carrying power, data or supporting information services should be protect
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ To prevent loss, damage, theft or compromise of information and other associated
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ Specialist advice should be sought on how to manage risks arising from cabling i
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ Equipment should be maintained correctly to ensure availability, integrity and c
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ To prevent loss, damage, theft or compromise of information and other associated
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ k\) applying measures for secure disposal or re-use of equipment (see [7.14](a-7
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ Items of equipment containing storage media should be verified to ensure that an
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ c\) the ability to reuse the controls at the next facility.
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Secure areas should be protected by appropriate entry controls and access points
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ To ensure only authorized physical access to the organization’s information an
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -162,6 +162,6 @@ g\) inspecting incoming deliveries for evidence of tampering on the way. If tamp
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
No other information.
|
||||
|
|
@ -26,7 +26,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ To prevent unauthorized physical access, damage and interference to the organiza
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -62,6 +62,6 @@ d\) not making directories, internal telephone books and online accessible maps
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
No other information.
|
||||
|
|
@ -30,7 +30,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ Premises should be continuously monitored for unauthorized physical access.
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ To detect and deter unauthorized physical access.
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -98,6 +98,6 @@ Any monitoring and recording mechanism should be used taking into consideration
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
No other information.
|
||||
|
|
@ -24,7 +24,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ Protection against physical and environmental threats, such as natural disasters
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ d\) explosives and weapons: performing random inspections for the presence of ex
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
Security measures for working in secure areas should be designed and implemented.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ To protect information and other associated assets in secure areas from damage a
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -74,6 +74,6 @@ f\) posting emergency procedures in a readily visible or accessible manner.
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
No other information.
|
||||
|
|
@ -21,7 +21,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ Clear desk rules for papers and removable storage media and clear screen rules f
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ To reduce the risks of unauthorized access, loss of and damage to information on
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -81,6 +81,6 @@ The organization should have procedures in place when vacating facilities includ
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
No other information.
|
||||
|
|
@ -26,7 +26,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Equipment should be sited securely and protected.
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ To reduce the risks from physical and environmental threats, and from unauthoriz
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -86,6 +86,6 @@ i\) physically separating information processing facilities managed by the organ
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
No other information.
|
||||
|
|
@ -26,7 +26,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ To prevent loss, damage, theft or compromise of off-site devices and interruptio
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ d\) logical access controls.
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Information stored on, processed by or accessible via user endpoint devices should be protected.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To protect information against the risks introduced by using user endpoint devices.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
<u>General</u>
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ The organization should establish procedures for:
|
|||
a\) the configuration of wireless connections on devices (e.g. disabling vulnerable protocols);
|
||||
b\) using wireless or wired connections with appropriate bandwidth in accordance with relevant topic-specific policies (e.g. because backups or software updates are needed).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Controls to protect information on user endpoint devices depend on whether the user endpoint device is used only inside of the organization's secured premises and network connections, or whether it is exposed to increased physical and network related threats outside of the organization.
|
||||
|
||||
The wireless connections for user endpoint devices are similar to other types of network connections but have important differences that should be considered when identifying controls. In particular, back-up of information stored on user endpoint devices can sometimes fail because of limited network bandwidth or because user endpoint devices are not connected at the times when backups are scheduled.
|
||||
|
|
|
|||
|
|
@ -21,13 +21,13 @@ status: active
|
|||
|
||||
## 8.10 Information deletion
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Information stored in information systems, devices or in any other storage media should be deleted when no longer required.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To prevent unnecessary exposure of sensitive information and to comply with legal, statutory, regulatory and contractual requirements for information deletion.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
<u>General</u>
|
||||
Sensitive information should not be kept for longer than it is required to reduce the risk of undesirable disclosure.
|
||||
|
|
@ -65,5 +65,5 @@ Control measures described in 7.14 should be applied to physically destroy the s
|
|||
|
||||
An official record of information deletion is useful when analysing the cause of a possible information leakage event.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Information on user data deletion in cloud services can be found in ISO/IEC 27017. Information on deletion of PII can be found in ISO/IEC 27555.
|
||||
|
|
@ -19,13 +19,13 @@ status: active
|
|||
|
||||
## 8.11 Data masking
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Data masking should be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To limit the exposure of sensitive data including PII, and to comply with legal, statutory, regulatory and contractual requirements.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Where the protection of sensitive data (e.g. PII) is a concern, the organization should consider hiding such data by using techniques such as data masking, pseudonymization or anonymization.
|
||||
|
||||
Pseudonymization or anonymization techniques can hide PII, disguise the true identity of PII principals or other sensitive information, and disconnect the link between PII and the identity of the PII principal or the link between other sensitive information.
|
||||
|
|
@ -55,7 +55,7 @@ c\) agreements or restrictions on usage of the processed data;
|
|||
d\) prohibiting collating the processed data with other information in order to identify the PII principal;
|
||||
e\) keeping track of providing and receiving the processed data.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Anonymization irreversibly alters PII in such a way that the PII principal can no longer be identified directly or indirectly.
|
||||
|
||||
Pseudonymization replaces the identifying information with an alias. Knowledge of the algorithm (sometimes referred to as the “additional information”) used to perform the pseudonymization allows for at least some form of identification of the PII principal. Such “additional information” should therefore be kept separate and protected.
|
||||
|
|
|
|||
|
|
@ -25,13 +25,13 @@ status: active
|
|||
|
||||
## 8.12 Data leakage prevention
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Data leakage prevention measures should be applied to systems, networks and any other devices that process, store or transmit sensitive information.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To detect and prevent the unauthorized disclosure and extraction of information by individuals or systems.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should consider the following to reduce the risk of data leakage:
|
||||
|
||||
a\) identifying and classifying information to protect against leakage (e.g. personal information, pricing models and product designs);
|
||||
|
|
@ -54,7 +54,7 @@ Where data is backed up, care should be taken to ensure sensitive information is
|
|||
|
||||
Data leakage prevention should also be considered to protect against the intelligence actions of an adversary from obtaining confidential or secret information (geopolitical, human, financial, commercial, scientific or any other) which can be of interest for espionage or can be critical for the community. The data le akage prevention actions should be oriented to confuse the adversary’s decisions for example by replacing authentic information with false information, either as an independent action or as response to the adversary’s intelligence actions. Examples of these kinds of actions are reverse social engineering or the use of honeypots to attract attackers.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Data leakage prevention tools are designed to identify data, monitor data usage and movement, and take actions to prevent data from leaking (e.g. alerting users to their risky behaviour and blocking the transfer of data to portable storage devices).
|
||||
|
||||
Data leakage prevention inherently involves monitoring personnel’s communications and online activities, and by extension external party messages, which raises legal concerns that should be considered prior to deploying data leakage prevention tools. There is a variety of legislation relating to privacy, data protection, employment, interception of data and telecommunications that is applicable to monitoring and data processing in the context of data leakage prevention.
|
||||
|
|
|
|||
|
|
@ -21,13 +21,13 @@ status: active
|
|||
|
||||
## 8.13 Information backup
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Backup copies of information, software and systems should be maintained and regularly tested in accordance with the agreed topic-specific policy on backup.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To enable recovery from loss of data or systems.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
A topic-specific policy on backup should be established to address the organization’s data retention and information security requirements.
|
||||
|
||||
Adequate backup facilities should be provided to ensure that all essential information and software can be recovered following an incident or failure or loss of storage media.
|
||||
|
|
@ -58,5 +58,5 @@ When the organization uses a cloud service, backup copies of the organization’
|
|||
|
||||
The retention period for essential business information should be determined, taking into account any requirement for retention of archive copies. The organization should consider the deletion of information (see [8.10](a-8.10-Information-deletion.md)) in storage media used for backup once the information’s retention period expires and should take into consideration legislation and regulations.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
For further information on storage security including retention consideration, see ISO/IEC 27040.
|
||||
|
|
@ -23,13 +23,13 @@ status: active
|
|||
|
||||
## 8.14 Redundancy of information processing facilities
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Information processing facilities should be implemented with redundancy sufficient to meet availability requirements.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure the continuous operation of information processing facilities.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should identify requirements for the availability of business services and information systems. The organization should design and implement systems architecture with appropriate redundancy to meet these requirements.
|
||||
|
||||
Redundancy can be introduced by duplicating information processing facilities in part or in their entirety (i.e. spare components or having two of everything). The organization should plan and implement procedures for the activation of the redundant components and processing facilities. The procedures should establish if the redundant components and processing activities are always activated, or in case of emergency, automatically or manually activated. The redundant components and information processing facilities should ensure the same security level as the primary ones.
|
||||
|
|
@ -47,7 +47,7 @@ f\) having duplicated components in systems (e.g. CPU, hard disks, memories) or
|
|||
|
||||
Where applicable, preferably in production mode, redundant information systems should be tested to ensure the failover from one component to another component works as intended.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
There is a strong relationship between redundancy and ICT readiness for business continuity (see [5.30](a-5.30-ICT-readiness-for-business-continuity.md)) especially if short recovery times are required. Many of the redundancy measures can be part of the ICT continuity strategies and solutions.
|
||||
|
||||
The implementation of redundancies can introduce risks to the integrity (e.g. processes of copying data to duplicated components can introduce errors) or confidentiality (e.g. weak security control of duplicated components can lead to compromise) of information and information systems, which need to be considered when designing information systems.
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 8.15 Logging
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and analysed.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To record events, generate evidence, ensure the integrity of log information, prevent against unauthorized access, identify information security events that can lead to an information security incident and to support investigations.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
<u>General</u>
|
||||
|
||||
|
|
@ -100,7 +100,7 @@ e\) correlating logs to enable efficient and highly accurate analysis.
|
|||
|
||||
Suspected and actual information security incidents should be identified (e.g. malware infection or probing of firewalls) and be subject to further investigation (e.g. as part of an information security incident management process, see >5.25>).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
System logs often contain a large volume of information, much of which is extraneous to information security monitoring. To help identify significant events for information security monitoring purposes, the use of suitable utility programs or audit tools to perform file interrogation can be considered.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
## 8.16 Monitoring activities
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Networks, systems and applications should be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To detect anomalous behaviour and potential information security incidents.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The monitoring scope and level should be determined in accordance with business and information security requirements and taking into consideration relevant laws and regulations. Monitoring records should be maintained for defined retention periods.
|
||||
|
||||
The following should be considered for inclusion within the monitoring system:
|
||||
|
|
|
|||
|
|
@ -23,13 +23,13 @@ status: active
|
|||
|
||||
## 8.17 Clock synchronization
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The clocks of information processing systems used by the organization should be synchronized to approved time sources.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To enable the correlation and analysis of security-related events and other recorded data, and to support investigations into information security incidents.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
External and internal requirements for time representation, reliable synchronization and accuracy should be documented and implemented. Such requirements can be from legal, statutory, regulatory, contractual, standards and internal monitoring needs. A standard reference time for use within the organization should be defined and considered for all systems, including building management systems, entry and exit systems and others that can be used to aid investigations.
|
||||
|
||||
A clock linked to a radio time broadcast from a national atomic clock or global positioning system (GPS) should be used as the reference clock for logging systems; a consistent, trusted date and time source to ensure accurate time-stamps. Protocols such as network time protocol (NTP) or precision time protocol (PTP) should be used to keep all networked systems in synchronization with a reference clock.
|
||||
|
|
@ -38,5 +38,5 @@ The organization can use two external time sources at the same time in order to
|
|||
|
||||
Clock synchronization can be difficult when using multiple cloud services or when using both cloud and on-premises services. In this case, the clock of each service should be monitored and the difference recorded in order to mitigate risks arising from discrepancies.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
The correct setting of computer clocks is important to ensure the accuracy of event logs, which can be required for investi gations or as evidence in legal and disciplinary cases. Inaccurate audit logs can hinder such investigations and damage the credibility of such evidence.
|
||||
|
|
@ -25,13 +25,13 @@ status: active
|
|||
|
||||
## 8.18 Use of privileged utility programs
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The use of utility programs that can be capable of overriding system and application controls should be restricted and tightly controlled.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure the use of utility programs does not harm system and application controls for information security.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The following guidelines for the use of utility programs that can be capable of overriding system and application controls should be considered:
|
||||
|
||||
a\) limitation of the use of utility programs to the minimum practical number of trusted, authorized users (see [8.2](a-8.2-Privileged-access-rights.md));
|
||||
|
|
@ -52,6 +52,6 @@ h\) limitation of the availability of utility programs (e.g. for the duration of
|
|||
|
||||
i\) logging of all use of utility programs.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
Most information systems have one or more utility programs that can be capable of overriding system and application controls, for example diagnostics, patching, antivirus, disk defragmenters, debuggers, backup and network tools.
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 8.19 Installation of software on operational systems
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Procedures and measures should be implemented to securely manage software installation on operational systems.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure the integrity of operational systems and prevent exploitation of technical vulnerabilities.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The following guidelines should be considered to securely manage changes and installation of software on operational systems:
|
||||
|
||||
a\) performing updates of operational software only by trained administrators upon appropriate management authorization (see [8.5](a-8.5-Secure-authentication.md));
|
||||
|
|
@ -61,5 +61,5 @@ The organization should define and enforce strict rules on which types of softwa
|
|||
|
||||
The principle of least privilege should be applied to software installation on operational systems. The organization should identify what types of software installations are permitted (e.g. updates and security patches to existing software) and what types of installations are prohibited (e.g. software that is only for personal use and software whose pedigree with regard to being potentially malicious is unknown or suspect). These privileges should be granted based on the roles of the users concerned.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
No other information.
|
||||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 8.2 Privileged access rights
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The allocation and use of privileged access rights should be restricted and managed.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure only authorized users, software components and services are provided with privileged access rights.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The allocation of privileged access rights should be controlled through an authorization process in accordance with the relevant topic-specific policy on access control (see [5.15](a-5.15-Access-control.md)). The following should be considered:
|
||||
|
||||
a\) identifying users who need privileged access rights for each system or process (e.g. operating systems, database management systems and applications);
|
||||
|
|
@ -55,7 +55,7 @@ k\) not sharing or linking identities with privileged access rights to multiple
|
|||
|
||||
l\) only using identities with privileged access rights for undertaking administrative tasks and not for day-to-day general tasks \[i.e. checking email, accessing the web (users should have a separate normal network identity for these activities)\].
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Privileged access rights are access rights provided to an identity, a role or a process that allows the performance of activities that typical users or processes cannot perform. System administrator roles typically require privileged access rights.
|
||||
|
||||
Inappropriate use of system administrator privileges (any feature or facility of an information system that enables the user to override system or application controls) is a major contributory factor to failures or breaches of systems.
|
||||
|
|
|
|||
|
|
@ -28,13 +28,13 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Networks and network devices should be secured, managed and controlled to protect information in systems and applications.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To protect information in networks and its supporting information processing facilities from compromise via the network.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Controls should be implemented to ensure the security of information in networks and to protect connected services from unauthorized access. In particular, the following items should be considered:
|
||||
|
||||
a\) the type and classification level of information that the network can support;
|
||||
|
|
@ -67,5 +67,5 @@ n\) disabling vulnerable network protocols.
|
|||
|
||||
The organization should ensure that appropriate security controls are applied to the use of virtualized networks. Virtualized networks also cover software-defined networking (SDN, SD-WAN). Virtualized networks can be desirable from a security viewpoint, since they can permit logical separation of communication taking place over physical networks, particularly for systems and applications that are implemented using distributed computing.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Additional information on network security can be found in the ISO/IEC 27033 series. More information concerning virtualized networks can be found in ISO/IEC TS 23167.
|
||||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 8.21 Security of network services
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Security mechanisms, service levels and service requirements of network services should be identified, implemented and monitored.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure security in the use of network services.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The security measures necessary for particular services, such as security features, service levels and service requirements, should be identified and implemented (by internal or external network service providers). The organization should ensure that network service providers implement these measures.
|
||||
|
||||
The ability of the network service provider to manage agreed services in a secure way should be determined and regularly monitored. The right to audit should be agreed between the organization and the provider. The organization should also consider third-party attestations provided by service providers to demonstrate they maintain appropriate security measures.
|
||||
|
|
@ -59,7 +59,7 @@ c\) caching (e.g. in a content delivery network) and its parameters that allow u
|
|||
|
||||
d\) procedures for the network service usage to restrict access to network services or applications, where necessary.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Network services include the provision of connections, private network services and managed network security solutions such as firewalls and intrusion detection systems. These services can range from simple unmanaged bandwidth to complex value-added offerings.
|
||||
|
||||
More guidance on a framework for access management is given in ISO/IEC 29146.
|
||||
|
|
@ -22,18 +22,18 @@ status: active
|
|||
|
||||
## 8.22 Segregation of networks
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Groups of information services, users and information systems should be segregated in the organization’s networks.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To split the network in security boundaries and to control traffic between them based on business needs.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should consider managing the security of large networks by dividing them into separate network domains and separating them from the public network (i.e. internet). The domains can be chosen based on levels of trust, criticality and sensitivity (e.g. public access domain, desktop domain, server domain, low- and high-risk systems), along organizational units (e.g. human resources, finance, marketing) or some combination (e.g. server domain connecting to multiple organizational units). The segregation can be done using either physically different networks or by using different logical networks.
|
||||
|
||||
The perimeter of each domain should be well-defined. If access between network domains is allowed, it should be controlled at the perimeter using a gateway (e.g. firewall, filtering router). The criteria for segregation of networks into domains, and the access allowed through the gateways, should be based on an assessment of the security requirements of each domain. The assessment should be in accordance with the topic-specific policy on access control (see [5.15](a-5.15-Access-control.md)), access requirements, value and classification of information processed and take account of the relative cost and performance impact of incorporating suitable gateway technology.
|
||||
|
||||
Wireless networks require special treatment due to the poorly-defined network perimeter. Radio coverage adjustment should be considered for segregation of wireless networks. For sensitive environments, consideration should be made to treat all wireless access as external connections and to segregate this access from internal networks until the access has passed through a gateway in accordance with network controls (see [8.20](a-8.20-Networks-security.md)) before granting access to internal systems. Wireless access network for guests should be segregated from those for personnel if personnel only use controlled user endpoint devices compliant to the organization’s topic-specific policies. WiFi for guests should have at least the same restrictions as WiFi for personnel, in order to discourage the use of guest WiFi by personnel.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Networks often extend beyond organizational boundaries, as business partnerships are formed that require the interconnection or sharing of information processing and networking facilities. Such extensions can increase the risk of unauthorized access to the organization’s information systems that use the network, some of which require protection from other network users because of their sensitivity or criticality.
|
||||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 8.23 Web filtering
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Access to external websites should be managed to reduce exposure to malicious content.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To protect systems from being compromised by malware and to prevent access to unauthorized web resources.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The organization should reduce the risks of its personnel accessing websites that contain illegal information or are known to contain viruses or phishing material. A technique for achieving this works by blocking the IP address or domain of the website(s) concerned. Some browsers and anti-malware technologies do this automatically or can be configured to do so.
|
||||
|
||||
The organization should identify the types of websites to which personnel should or should not have access. The organization should consider blocking access to the following types of websites:
|
||||
|
|
@ -47,5 +47,5 @@ Prior to deploying this control, the organization should establish rules for saf
|
|||
|
||||
Training should be given to personnel on the secure and appropriate use of online resources including access to the web. The training should include the organization’s rules, contact point for raising security concerns, and exception process when restricted web resources need to be accessed for legitimate business reasons. Training should also be given to personnel to ensure that they do not overrule any browser advisory that reports that a website is not secure but allows the user to proceed.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Web filtering can include a range of techniques including signatures, heuristics, list of acceptable websites or domains, list of prohibited websites or domains and bespoke configuration to help prevent malicious software and other malicious activity from attacking the organization’s network and systems.
|
||||
|
|
@ -24,11 +24,11 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ To ensure proper and effective use of cryptography to protect the confidentialit
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -164,7 +164,7 @@ In addition to integrity, for many use cases, the authenticity of public keys sh
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ status: active
|
|||
|
||||
## 8.25 Secure development life cycle
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ To ensure information security is designed and implemented within the secure dev
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ If development is outsourced, the organization should obtain assurance that the
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -31,13 +31,13 @@ status: active
|
|||
| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection #Defence |
|
||||
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
Information security requirements should be identified, specified and approved when developing or acquiring applications.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To ensure all information security requirements are identified and addressed when developing or acquiring applications.
|
||||
|
||||
#### Guidance
|
||||
### Guidance
|
||||
|
||||
<u>General</u>
|
||||
|
||||
|
|
@ -113,6 +113,6 @@ e\) where a trusted authority is used (e.g. for the purposes of issuing and main
|
|||
|
||||
Several of the above considerations can be addressed by the application of cryptography (see [[8.24]]), taking into consideration legal requirements (see [[5.31]], [[5.36]], especially see [[5.31]] for cryptography legislation).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
Applications accessible via networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public; incomplete transmission, mis- routing, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer.
|
||||
|
|
@ -24,15 +24,15 @@ status: active
|
|||
|
||||
## 8.27 Secure system architecture and engineering principles
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
To ensure information systems are securely designed, implemented and operated within the development life cycle.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
Security engineering principles should be established, documented and applied to information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology). New technology should be analysed for security risks and the design should be reviewed against known attack patterns.
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ The established security engineering principles should be applied, where applica
|
|||
The security engineering principles and the established engineering procedures should be regularly reviewed to ensure that they are effectively contributing to enhanced standards of security within the engineering process. They should also be regularly reviewed to ensure that they remain up-to- date in terms of combatting any new potential threats and in remaining applicable to advances in the technologies and solutions being applied.
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
Secure engineering principles can be applied to the design or configuration of a range of techniques, such as:
|
||||
|
||||
|
|
|
|||
|
|
@ -24,10 +24,10 @@ status: active
|
|||
|
||||
## 8.28 Secure coding
|
||||
|
||||
#### Control
|
||||
### Control
|
||||
Secure coding principles should be applied to software development.
|
||||
|
||||
#### Purpose
|
||||
### Purpose
|
||||
To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software.
|
||||
|
||||
#### Guidance
|
||||
|
|
|
|||
|
|
@ -25,13 +25,13 @@ status: active
|
|||
|
||||
## 8.29 Security testing in development and acceptance
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Security testing processes should be defined and implemented in the development life cycle.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To validate if information security requirements are met when applications or code are deployed to the production environment.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
New information systems, upgrades and new versions should be thoroughly tested and verified during the development processes. Security testing should be an integral part of the testing for systems or components.
|
||||
|
||||
Security testing should be conducted against a set of requirements, which can be expressed as functional or non-functional. Security testing should include testing of:
|
||||
|
|
@ -66,7 +66,7 @@ For outsourced development and purchasing components, an acquisition process sho
|
|||
|
||||
Testing should be performed in a test environment that matches the target production environment as closely as possible to ensure that the system does not introduce vulnerabilities to the organization’s environment and that the tests are reliable (see [8.31](a-8.31-Separation-of-development-test-and-production-environments.md)).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Multiple test environments can be established, which can be used for different kinds of testing (e.g. functional and performance testing). These different environments can be virtual, with individual configurations to simulate a variety of operating environments.
|
||||
|
||||
Testing and monitoring of test environments, tools and technologies also needs to be considered to ensure effective testing. The same considerations apply to monitoring of the monitoring systems deployed in development, test and production settings. Judgeme nt is needed, guided by the sensitivity of the systems and data, to determine how many layers of meta-testing are useful.
|
||||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 8.3 Information access restriction
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Access to information and other associated assets should be restricted in accordance with the established topic-specific policy on access control.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure only authorized access and to prevent unauthorized access to information and other associated assets.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Access to information and other associated assets should be restricted in accordance with the established topic-specific policies. The following should be considered in order to support access restriction requirements:
|
||||
|
||||
a\) not allowing access to sensitive information by unknown user identities or anonymously. Public or anonymous access should only be granted to storage locations that do not contain any sensitive information;
|
||||
|
|
@ -63,7 +63,7 @@ d\) defining the printing permissions for the information;
|
|||
e\) recording who accesses the information and how the information is used;
|
||||
f\) raising alerts if attempts to misuse the information are detected.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Dynamic access management techniques and other dynamic information protection technologies can support the protection of information even when data is shared beyond the originating organization, where traditional access controls cannot be enforced. It can be applied to documents, emails or other files containing information to limit who can access the content and in what way. It can be at a granular level and be adapted over the life cycle of the information.
|
||||
|
||||
Dynamic access management techniques do not replace classical access management \[e.g. using access control lists (ACLs)\], but can add more factors for conditionality, real-time evaluation, just-in-time data reduction and other enhancements that can be useful for the most sensitive information. It offers a way to control access outside the organization’s environment. Incident response can be supported by dynamic access management techniques as permissions can be modified or revoked at any time.
|
||||
|
|
|
|||
|
|
@ -32,13 +32,13 @@ status: active
|
|||
|
||||
## 8.30 Outsourced development
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The organization should direct, monitor and review the activities related to outsourced system development.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure information security measures required by the organization are implemented in outsourced system development.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Where system development is outsourced, the organization should communicate and agree requirements and expectations, and continually monitor and review whether the delivery of outsourced work meets these expectations. The following points should be considered across the organization’s entire external supply chain:
|
||||
|
||||
a\) licensing agreements, code ownership and intellectual property rights related to the outsourced content (see [5.32](a-5.32-Intellectual-property-rights.md));
|
||||
|
|
@ -63,5 +63,5 @@ j\) security requirements for the development environment (see [8.31](a-8.31-Sep
|
|||
|
||||
k\) taking consideration of applicable legislation (e.g. on protection of personal data).
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Further information on supplier relationships can be found in the ISO/IEC 27036 series.
|
||||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 8.31 Separation of development, test and production environments
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Development, testing and production environments should be separated and secured.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To protect the production environment and data from compromise by development and test activities.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The level of separation between production, testing and development environments that is necessary to prevent production problems should be identified and implemented.
|
||||
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ A single person should not have the ability to make changes to both development
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
Without adequate measures and procedures, developers and testers having access to production systems can introduce significant risks (e.g. unwanted modification of files or system environment, system failure, running unauthorized and untested code in product ion systems, disclosure of confidential data, data integrity and availability issues). There is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access to the production environment.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,13 +24,13 @@ status: active
|
|||
|
||||
## 8.32 Change management
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Changes to information processing facilities and information systems should be subject to change management procedures.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To preserve information security when executing changes.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Introduction of new systems and major changes to existing systems should follow agreed rules and a formal process of documentation, specification, testing, quality control and managed implementation. Management responsibilities and procedures should be in place to ensure satisfactory control of all changes.
|
||||
|
||||
Change control procedures should be documented and enforced to ensure the confidentiality, integrity and availability of information in information processing facilities and information systems, for the entire system development life cycle from the early design stages through all subsequent maintenance efforts.
|
||||
|
|
@ -57,7 +57,7 @@ h\) ensuring that operating documentation (see [5.37](a-5.37-Documented-operatin
|
|||
|
||||
i\) ensuring that ICT continuity plans and response and recovery procedures (see [5.30](a-5.30-ICT-readiness-for-business-continuity.md)) are changed as necessary to remain appropriate.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Inadequate control of changes to information processing facilities and information systems is a common cause of system or security failures. Changes to the production environment, especially when transferring software from development to operational environment, can impact on the integrity and availability of applications.
|
||||
|
||||
Changing software can impact the production environment and vice versa.
|
||||
|
|
|
|||
|
|
@ -21,13 +21,13 @@ status: active
|
|||
|
||||
## 8.33 Test information
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Test information should be appropriately selected, protected and managed.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure relevance of testing and protection of operational information used for testing.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Test information should be selected to ensure the reliability of tests results and the confidentiality of the relevant operational information. Sensitive information (including personally identifiable information) should not be copied into the development and testing environments (see [8.31](a-8.31-Separation-of-development-test-and-production-environments.md)).
|
||||
|
||||
The following guidelines should be applied to protect the copies of operational information, when used for testing purposes, whether the test environment is built in-house or on a cloud service:
|
||||
|
|
@ -44,5 +44,5 @@ e\) properly deleting (see [8.10](a-8.10-Information-deletion.md)) operational i
|
|||
|
||||
Test information should be securely stored (to prevent tampering, which can otherwise lead to invalid results) and only used for testing purposes.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
System and acceptance testing can require substantial volumes of test information that are as close as possible to operational information.
|
||||
|
|
@ -26,13 +26,13 @@ status: active
|
|||
|
||||
## 8.34 Protection of information systems during audit testing
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Audit tests and other assurance activities involving assessment of operational systems should be planned and agreed between the tester and appropriate management.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To minimize the impact of audit and other assurance activities on operational systems and business processes.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
The following guidelines should be observed:
|
||||
|
||||
a\) agreeing audit requests for access to systems and data with appropriate management;
|
||||
|
|
@ -51,5 +51,5 @@ g\) running audit tests that can affect system availability outside business hou
|
|||
|
||||
h\) monitoring and logging all access for audit and test purposes.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Audit tests and other assurance activities can also happen on development and test systems, where such tests can impact for example the integrity of code or lead to disclosure of any sensitive information held in such environments.
|
||||
|
|
@ -25,13 +25,13 @@ status: active
|
|||
|
||||
## 8.4 Access to source code
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Read and write access to source code, development tools and software libraries should be appropriately managed.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To prevent the introduction of unauthorized functionality, avoid unintentional or malicious changes and to maintain the confidentiality of valuable intellectual property.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Access to source code and associated items (such as designs, specifications, verification plans and validation plans) and development tools (e.g. compilers, builders, integration tools, test platforms and environments) should be strictly controlled.
|
||||
|
||||
For source code, this can be achieved by controlling central storage of such code, preferably in source code management system.
|
||||
|
|
@ -49,5 +49,5 @@ f\) maintaining an audit log of all accesses and of all changes to source code.
|
|||
|
||||
If the program source code is intended to be published, additional controls to provide assurance on its integrity (e.g. digital signature) should be considered.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
If access to source code is not properly controlled, source code can be modified or some data in the development environment (e.g. copies of production data, configuration details) can be retrieved by unauthorized persons.
|
||||
|
|
@ -22,13 +22,13 @@ status: active
|
|||
|
||||
## 8.5 Secure authentication
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
Secure authentication technologies and procedures should be implemented based on information access restrictions and the topic-specific policy on access control.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure a user or an entity is securely authenticated, when access to systems, applications and services is granted.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
A suitable authentication technique should be chosen to substantiate the claimed identity of a user, software, messages and other entities.
|
||||
|
||||
The strength of authentication should be appropriate for the classification of the information to be accessed. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as digital certificates, smart cards, tokens or biometric means, should be used.
|
||||
|
|
@ -54,5 +54,5 @@ j\) not transmitting passwords in clear text over a network to avoid being captu
|
|||
k\) terminating inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the organization’s security management or on user endpoint devices;
|
||||
l\) restricting connection duration times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
Additional information on entity authentication assurance can be found is ISO/IEC 29115.
|
||||
|
|
@ -28,13 +28,13 @@ status: active
|
|||
|
||||
## 8.6 Capacity management
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
The use of resources should be monitored and adjusted in line with current and expected capacity requirements.
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
To ensure the required capacity of information processing facilities, human resources, offices and other facilities.
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
Capacity requirements for information processing facilities, human resources, offices and other facilities should be identified, taking into account the business criticality of the concerned systems and processes.
|
||||
|
||||
System tuning and monitoring should be applied to ensure and, where necessary, improve the availability and efficiency of systems.
|
||||
|
|
@ -67,5 +67,5 @@ f\) denying or restricting bandwidth for resource-consuming services if these ar
|
|||
|
||||
A documented capacity management plan should be considered for mission critical systems.
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
For more detail on the elasticity and scalability of cloud computing, see ISO/IEC TS 23167.
|
||||
|
|
@ -34,11 +34,11 @@ status: active
|
|||
## Control
|
||||
Protection against malware should be implemented and supported by appropriate user awareness.
|
||||
|
||||
## Purpose
|
||||
### Purpose
|
||||
|
||||
To ensure information and other associated assets are protected against malware.
|
||||
|
||||
## Guidance
|
||||
### Guidance
|
||||
|
||||
Protection against malware should be based on malware detection and repair software, information security awareness, appropriate system access and change management controls. Use of malware detection and repair software alone is not usually adequate. The following guidance should be considered:
|
||||
|
||||
|
|
@ -82,6 +82,6 @@ n) implementing procedures to regularly collect information about new malware
|
|||
|
||||
o) verifying that information relating to malware, such as warning bulletins, comes from qualified and reputable sources (e.g. reliable internet sites or suppliers of malware detection software) and is accurate and informative.
|
||||
|
||||
## Other **information**
|
||||
### Other information
|
||||
|
||||
It is not always possible to install software that protects against malware on some systems (e.g. some industrial control systems). Some forms of malware infect computer operating systems and computer firmware such that common malware controls cannot clean the system and a full reimaging of the operating system software and sometimes the computer firmware is necessary to return to a secure state.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ status: active
|
|||
|
||||
|
||||
|
||||
**Control**
|
||||
### Control
|
||||
|
||||
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ Information about technical vulnerabilities of information systems in use should
|
|||
|
||||
|
||||
|
||||
**Purpose**
|
||||
### Purpose
|
||||
|
||||
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ To prevent exploitation of technical vulnerabilities.
|
|||
|
||||
|
||||
|
||||
**Guidance**
|
||||
### Guidance
|
||||
|
||||
|
||||
|
||||
|
|
@ -215,7 +215,7 @@ Where the organization uses a cloud service supplied by a third-party cloud serv
|
|||
|
||||
|
||||
|
||||
**Other information**
|
||||
### Other information
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue