diff --git a/doc/ref_arch/openstack/chapters/chapter06.md b/doc/ref_arch/openstack/chapters/chapter06.md index 08979cfee6..51e8be9a89 100644 --- a/doc/ref_arch/openstack/chapters/chapter06.md +++ b/doc/ref_arch/openstack/chapters/chapter06.md @@ -27,8 +27,8 @@ Chapter 2 gathers all requirements and recommendations regarding security topics ## 6.3 Cloud Infrastructure and VIM Security -OpenStack security guide: -https://docs.openstack.org/security-guide/introduction/introduction-to-openstack.html. In the section "[Security boundaries and threats](https://docs.openstack.org/security-guide/introduction/security-boundaries-and-threats.html)" there is extensive description on security domains, threat classifications, and attack vectors. The following only touches on some of the topics and at a high level. +In the "[Security boundaries and threats](https://docs.openstack.org/security-guide/introduction/security-boundaries-and-threats.html)" section of the [OpenStack security guide] +(https://docs.openstack.org/security-guide/introduction/introduction-to-openstack.html), there is extensive description on security domains, threat classifications, and attack vectors. The following only touches on some of the topics and at a high level. ### 6.3.1 System Hardening @@ -49,7 +49,7 @@ Access to all the platform's components must be restricted (sec.gen.013) applyin - Restrict access to Operating System (sec.gen.005) #### 6.3.1.3 Password policy -For all infrastructure components, passwords must be hardened and a strict password policy must be applied (sec.gen.002). +For all infrastructure components, passwords must be hardened, and a strict password policy must be applied (sec.gen.002). Passwords must be strengthened: - All vendors default passwords must be changed @@ -65,10 +65,10 @@ Password's composition, complexity and policy should follow the recommendations - Check the password for known bad passwords (repetitive or sequential characters, dictionary words, context-specific words, previously used passwords, etc.) - Limit number of failed login attempts - Implement Multi-factor Authentication -- Periodic (for example, Yearly, Quarterly, etc.) password change or on key events such as indication of compromise, change of user roles, a defined period of inactivity, when a user leaves the organization, etc.. +- Periodic (for example, Yearly, Quarterly, etc.) password change or on key events such as indication of compromise, change of user roles, a defined period of inactivity, when a user leaves the organisation, etc. #### 6.3.1.4 Function and Software -Infrastructure must be implemented to perform the minimal function that’s practically needed to support Cloud Infrastructure. +Infrastructure must be implemented to perform the minimal functions needed to operate the Cloud Infrastructure. Regarding software (sec.gen.004): - Install only software which is required to support the functions @@ -76,7 +76,7 @@ Regarding software (sec.gen.004): - Where software cannot be removed, disable all services to it #### 6.3.1.5 Patches -All deployed Cloud Infrastructure software must be audited and system must be implemented to allow installation of the latest patches to address security vulnerabilities in the following timescale from discovery (sec.gen.008, sec.lcm.011): +All deployed Cloud Infrastructure software must be audited and must be implemented to allow installation of the latest patches to address security vulnerabilities in the following timescale from discovery (sec.gen.008, sec.lcm.011): | Severity | Time to Remediate | | ----------- | ----------- | | Zero-Day | Immediately or as soon as practically possible | @@ -85,14 +85,14 @@ All deployed Cloud Infrastructure software must be audited and system must be im | Medium | 90 days | | Low | 180 days | -**See** [Common Vulnerability Scoring System](https://nvd.nist.gov/vuln-metrics/cvss) +**See** [Common Vulnerability Scoring System](https://cve.mitre.org/) and [NIST Vulnerability Metrics](https://nvd.nist.gov/vuln-metrics/cvss). #### 6.3.1.6 Network Protocols - Only allow protocols that are required by the system functions (sec.sys.002) - Tighten all required TCP/IP (Transmission Control Protocol/Internet Protocol) services #### 6.3.1.7 Anti-Virus and Firewall -- Install and run your Enterprise approved anti-virus software/ intrusion protection/ malware/ spyware endpoint security software with up to date profiles, minimal refresh daily +- Install and run your Enterprise approved anti-virus software/ intrusion protection/ malware/ spyware endpoint security software with up-to-date profiles; minimal daily refresh - Install and run firewall software where applicable #### 6.3.1.8 Vulnerability Detection and Prevention @@ -105,7 +105,7 @@ All deployed Cloud Infrastructure software must be audited and system must be im ### 6.3.2 Platform Access #### 6.3.2.1 Identity Security -The [OpenStack Identity service (Keystone)](https://docs.openstack.org/security-guide/identity.html) provides identity, token, catalog, and policy services for use specifically by services in the OpenStack family. Identity service is organized as a group of internal services exposed on one or many endpoints. Many of these services are used in a combined fashion by the front end (sec.sys.006). +The [OpenStack Identity service (Keystone)](https://docs.openstack.org/security-guide/identity.html) provides identity, token, catalog, and policy services for use specifically by services in the OpenStack family. Identity service is organised as a group of internal services exposed on one or many endpoints. Many of these services are used in a combined fashion by the front end (sec.sys.006). OpenStack Keystone can work with an Identity service that your enterprise may already have, such as LDAP with Active Directory. In those cases, the recommendation is to integrate Keystone with the cloud provider's Identity Services. @@ -115,22 +115,22 @@ Authentication is the first line of defense for any real-world implementation of Limiting the number of repeated failed login attempts (configurable) reduces the risk of unauthorised access via password guessing (Bruce force attack) - sec.mon.006. The restriction on the number of consecutive failed login attempts ("lockout_failure_attempts") and any actions post such access attempts (such as locking the account where the "lockout_duration" is left unspecified) should abide by the operator's policies. For example, an operator may restrict the number of consecutive failed login attempts to 3 ("lockout_failure_attempts = 3") and lock the account preventing any further access and where the account is unlocked by getting necessary approvals. ##### Keystone Tokens -Once a user is authenticated, a token is generated for authorization and access to an OpenStack environment and resources. By default, the token is set to expire in one hour. This setting can be changed based on the business and operational needs, but it's highly recommended to set the expiration to the shortest possible value without dramatically impacting your operations. +Once a user is authenticated, a token is generated for authorisation and access to an OpenStack environment and resources. By default, the token is set to expire in one hour. This setting can be changed based on the business and operational needs, but it's highly recommended to set the expiration to the shortest possible value without dramatically impacting your operations. **Special Note on Logging Tokens:** since the token would allow access to the OpenStack services, it *MUST* be masked before outputting to any logs. -#### 6.3.2.3 Authorization -Authorization serves as the next level of defense. At its core, it checks if the authenticated users have the permission to execute an action. Most Identity Services support the notion of groups and roles. A user belongs to groups and each group has a list of roles that permits certain action on certain resources. OpenStack services reference the roles of the user attempting to access the service. OpenStack policy enforcer middleware takes into consideration the policy rules associated with each resource and the user’s group/roles and association to determine if access will be permitted for the requested resource. For more details on policies, please refer to the [OpenStack Policies](https://docs.openstack.org/security-guide/identity/policies.html#policy-section). +#### 6.3.2.3 Authorisation +Authorisation serves as the next level of defence. At its core, it checks if the authenticated users have the permission to execute an action. Most Identity Services support the notion of groups and roles. A user belongs to groups and each group has a list of roles that permits certain actions on certain resources. OpenStack services reference the roles of the user attempting to access the service. OpenStack policy enforcer middleware takes into consideration the policy rules associated with each resource and the user’s group/roles and association to determine if access will be permitted for the requested resource. For more details on policies, please refer to the [OpenStack Policies](https://docs.openstack.org/security-guide/identity/policies.html#policy-section). #### 6.3.2.4 RBAC -In order to properly manage user access to OpenStack services, service providers must utilize the Role Based Access Control (RBAC) system (sec.sys.001, sec.sys.007). Based on the OpenStack Identify Service (Keystone v3) Group and Domain component, the RBAC system implements a set of access roles that accommodate most use cases. Operations staff can create users and assign them to roles using standard OpenStack commands for users, groups, and roles. +In order to properly manage user access to OpenStack services, service providers must utilise the Role Based Access Control (RBAC) system (sec.sys.001, sec.sys.007). Based on the OpenStack Identify Service (Keystone v3) Group and Domain component, the RBAC system implements a set of access roles that accommodate most use cases. Operations staff can create users and assign them to roles using standard OpenStack commands for users, groups, and roles. Keystone provides three [default roles](https://docs.openstack.org/keystone/latest/admin/service-api-protection.html): admin, member, and reader. As of Train release, Keystone applies the following personas consistently across its API. -The reader role provides read-only access to resources within the system, a domain, or a project. -The member role is the same as reader in Keystone, but allows to introduce granularity between admin and reader to other OpenStack services. -The admin role is reserved for the most privileged operations within a given scope for managing resources. +- The reader role provides read-only access to resources within the system, a domain, or a project. +- The member role is the same as reader in Keystone, but allows to introduce granularity between admin and reader to other OpenStack services. +- The admin role is reserved for the most privileged operations within a given scope for managing resources. -For specific use-case, policies can be overridden and new roles can be created for each OpenStack service by editing the policy.json file. +For specific use-case, policies can be overridden, and new roles can be created for each OpenStack service by editing the policy.json file. ###### Rules The following rules govern create, read, update, and delete (CRUD) level access. @@ -184,7 +184,7 @@ The following rules govern create, read, update, and delete (CRUD) level access. ### 6.3.3 Confidentiality and Integrity -Confidentiality implies that data and resources must be protected against unauthorized introspection/exfiltration. Integrity implies that the data must be protected from unauthorized modifications or deletions. +Confidentiality implies that data and resources must be protected against unauthorised introspection/exfiltration. Integrity implies that the data must be protected from unauthorised modifications or deletions. Regarding confidentiality and integrity in Cloud Infrastructure, 2 main concerns are raised: - confidentiality and integrity of the Cloud Infrastructure components (networks, hypervisor, OpenStack services) @@ -194,7 +194,7 @@ The Cloud Infrastructure must also provide the mechanism to identify corrupted d #### 6.3.3.1 Confidentiality and Integrity of communications (sec.ci.001) -It is essential to secure the infrastructure from external attacks. To counter this threat, API endpoints exposed to external networks must be protected by either a rate-limiting proxy or web application firewall and must be placed behind a reverse HTTPS proxy (sec.mon.008). Attacks can also be generated by corrupted internal components, and for this reason, it is security best practice to ensure integrity and confidentiality of all network communications (internal and external) by using Transport Layer Security (TLS) protocol (sec.sys.003, sec.sys.004). +It is essential to secure the infrastructure from external attacks. To counter this threat, API endpoints exposed to external networks must be protected by either a rate-limiting proxy or web application firewall (WAF), and must be placed behind a reverse HTTPS proxy (sec.mon.008). Attacks can also be generated by corrupted internal components, and for this reason, it is security best practice to ensure integrity and confidentiality of all network communications (internal and external) by using Transport Layer Security (TLS) protocol (sec.sys.003, sec.sys.004). When using TLS, according to the [OpenStack security guide](https://docs.openstack.org/security-guide/secure-communication/introduction-to-ssl-and-tls.html) recommendation, the minimum version to be used is TLS 1.2. 3 categories of traffic will be protected using TLS: @@ -202,40 +202,40 @@ When using TLS, according to the [OpenStack security guide](https://docs.opensta - communications between OpenStack components (OpenStack services, Bus message, Data Base) - management traffic -Certificates used for TLS encryption must be compliant with X.509 standards and be signed by a trusted authority (sec.sys.017). To issue certificates for internal OpenStack users or services, the cloud provider can use a Public Key Infrastructure with its own internal Certification Authority (CA), certificate policies, and management. +Certificates used for TLS encryption must be compliant with X.509 standards and be signed by a trusted authority (sec.sys.017). To issue certificates for internal OpenStack users or services, the cloud provider can use a Public Key Infrastructure (PKI) with its own internal Certification Authority (CA), certificate policies, and management. #### 6.3.3.2 Integrity of OpenStack components configuration The cloud deployment components/tools store all the information required to install the infrastructure including sensitive information -such as credentials. It is recommended to turn off deployment components after deployment to minimize attack surface area, limit the risk of compromise, and to deploy and provision the infrastructure through a dedicated network (VLAN). +such as credentials. It is recommended to turn off deployment components after deployment to minimise the attack surface area, limit the risk of compromise, and to deploy and provision the infrastructure through a dedicated network (VLAN). Configuration files contain sensitive information. -These files must be protected from malicious or accidental modifications or deletions by configuring strict access permissions for such files. All access, failed attempts to change and all changes (pre-change, post-change and by who) must be securely logged, and all failed access and failed changes must be alerted (sec.mon.005). +These files must be protected from malicious or accidental modifications or deletions by configuring strict access permissions for such files. All access, failed attempts to change and all changes (pre-change, post-change and by who) must be securely logged, and all failed access and failed changes must be alerted on (sec.mon.005). The Cloud Infrastructure must provide the mechanisms to identify corrupted data (sec.gen.009): -- the integrity of configuration files and binaries must be checked by using cryptographic hash, +- the integrity of configuration files and binaries must be checked by using cryptographic hash - it is recommended to run scripts (such as checksec.sh) to verify the properties of the QEMU/KVM -- it is recommended to use tool such as [CIS-CAT](https://www.cisecurity.org/cybersecurity-tools/cis-cat-pro/) (Center for Internet security- Configuration Assessment Tool) to check the compliance of systems configuration against respective [CIS benchmarks](https://www.cisecurity.org/cis-benchmarks/). +- it is recommended to use tools such as CIS-CAT ([Center for Internet security- Configuration Assessment Tool](https://www.cisecurity.org/cybersecurity-tools/cis-cat-pro/)) to check the compliance of systems configuration against respective [CIS benchmarks](https://www.cisecurity.org/cis-benchmarks/). -It is strongly recommend to protect Linux repositories and Docker registries against the corruption of their data, by adopting protection measures such as hosting a local repository/registry with restricted and controlled access, and using TLS (sec.img.004, sec.img.005, sec.img.006). +It is strongly recommend to protect all repositories, such as Linux repositories and Docker registries, against the corruption of their data and unauthorised access, by adopting protection measures such as hosting a local repository/registry with restricted and controlled access, and using TLS (sec.img.004, sec.img.005, sec.img.006). This repository/registry must contain only signed images or packages. #### 6.3.3.3 Confidentiality and Integrity of tenant data (sec.ci.001) -Tenant data are forwarded unencrypted over the network. Since the VNF is responsible for its security, it is up to the VMs to establish secure data plane, e.g. using IPsec over its tenant network. +Tenant data are forwarded unencrypted over the network. Since the VNF is responsible for its security, it is up to the VMs to establish secure data plane, e.g., using IPsec over its tenant network. A Cloud actor must not be able to retrieve secrets used by VNF managers. -All communications between the VNFM or orchestrator, and the infrastructure must be protected in integrity and confidentiality (e.g. by using TLS) and controlled via appropriate IP filtering rules (sec.lcm.006). +All communications between the VNFM or orchestrator, and the infrastructure must be protected in integrity and confidentiality (e.g., by using TLS) and controlled via appropriate IP filtering rules (sec.lcm.006). -The Cloud Infrastructure must onboard only trusted and verified VM images implying that VNF vendors provide signed images (sec.img.001). -Images from non-trusted sources may contain security breaches or unsolicited malicious code (spoofing, information disclosure). +The Cloud Infrastructure must onboard only trusted and verified VM images, implying that VNF vendors provide signed images (sec.img.001); +images from non-trusted sources may contain security breaches or unsolicited malicious code (spoofing, information disclosure). It is recommended to scan all VM images with a vulnerability scanner(sec.img.002). The scan is mandatory for images from unknown or untrusted sources. -To mitigate tampering attacks, it is recommended to use [Glance image signing feature](https://docs.openstack.org/glance/pike/user/signature.html) to validate an image when uploading. In this case, Barbican service must be installed. +To mitigate tampering attacks, it is recommended to use the [Glance image signing feature](https://docs.openstack.org/glance/pike/user/signature.html) to validate an image when uploading. In this case, Barbican service must be installed. In order to protect data, VNFs must encrypt the volumes they use. In this case, the encryption key must not be stored on the infrastructure. When a key management service is provided by the infrastructure, OpenStack can encrypt data on behalf of tenants (sec.gen.010). -It is recommended to rely on Barbican, as key manager service of OpenStack. +It is recommended to rely on Barbican, as the key manager service of OpenStack. ### 6.3.4 Workload Security @@ -246,14 +246,14 @@ Separation of non-production and production workloads, or by workload category ( Regions also support the sec.wl.004 requirement for separation by Location (for example, country). -Operational security is handled through a combination of mechanisms including the above and security groups (sec.sys.002). Security groups limit the types of traffic that have access to instances. One or more security groups can be automatically assigned to an instance at launch. The rules associated with a security group control the incoming traffic. Any incoming traffic not matched by a rule is denied access. The security group rules govern access through the setting of different parameters: traffic source, protocols and destination port on a VM. Errors in provisioning/managing OpenStack Security Groups can lead to non-functioning applications and can take a long time to identify faults and correct them. Thus, use of tools for auto provisioning and continued inspection of security groups and network policies is required. +Operational security is handled through a combination of mechanisms including the above and security groups (sec.sys.002). Security groups limit the types of traffic that have access to instances. One or more security groups can be automatically assigned to an instance at launch. The rules associated with a security group control the incoming traffic. Any incoming traffic not matched by a rule is denied access. The security group rules govern access through the setting of different parameters: traffic source, protocols and destination port on a VM. Errors in provisioning/managing OpenStack Security Groups can lead to non-functioning applications, and it can take a long time to identify faults and correct them. Thus, the use of tools for auto provisioning and continued inspection of security groups and network policies is required. Given the rate of change in the workload development and deployment, and the cloud environment itself, sec.wl.003 requires that the workloads must be assessed during the CI/CD process as the images are created and then whenever they are deployed. In addition, the infrastructure must be configured for security as discussed elsewhere in this chapter including secure boot. ### 6.3.4.1 SR-IOV and DPDK Considerations -SR-IOV agent only works with NoopFirewallDriver when Security Groups are enabled, but can still use other firewall_driver for other Agents by updating their conf with the requested firewall driver." Please see [SR-IOV Passthrough for Networking](https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking). +The SR-IOV agent only works with NoopFirewallDriver when Security Groups are enabled, but can still use other firewall_driver for other Agents by updating their conf with the requested firewall driver. Please see [SR-IOV Passthrough for Networking](https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking). Operators typically do not implement Security Groups when using SR-IOV or DPDK networking technologies. @@ -272,25 +272,24 @@ Images must be also updated to benefit from the latest security patches (sec.gen ### 6.3.6 Security LCM -Cloud Infrastructure LCM encompasses provisioning, deployment, configuration and management (resources scaling, services upgrades…) as described in [chapter 7](./chapter07.md). These operations must be securely performed in order to keep the infrastructure safe and operational (sec.lcm.003). +Cloud Infrastructure LCM encompasses provisioning, deployment, configuration and management (resources scaling, services upgrades, etc.) as described in [chapter 7](./chapter07.md). These operations must be securely performed in order to keep the infrastructure safe and operational (sec.lcm.003). **Provisioning/Deployment** Regarding the provisioning of servers, switches, routers and networking, tools must be used to automate the provisioning eliminating human error. For Infrastructure hardware resources, a set of recommendations is detailed in [7.2.1](./chapter07.md#7.2.1) to automate and secure their provisioning (sec.lcm.001). -For OpenStack services and software components, deployment tools or components must be used to automate the deployment and avoid errors. The deployment tool is a sensitive component storing critical information (deployment scripts, credentials…). +For OpenStack services and software components, deployment tools or components must be used to automate the deployment and avoid errors. The deployment tool is a sensitive component storing critical information (deployment scripts, credentials, etc.). The following rules must be applied: - The boot of the server or the VM hosting the deployment tool must be protected - Integrity of the deployment images must be checked, before starting deployment - Deployment must be done through dedicated network (e.g. VLAN) - When the deployment is finished, the deployment tool must be turned-off, if the tool is only dedicated to deployment. Otherwise, any access to the deployment tool must be restricted. - -Strict access permissions must be set on OpenStack configuration files. +- Strict access permissions must be set on OpenStack configuration files. **Configuration and management** -Configuration operations must be tracked (sec.gen.015, sec.mon.006, sec.mon.007). Events such as system access attempts, actions with high privileges, modification of configuration must be logged and exported on the fly to a distant storage. The communication channel used for log collection must be protected in integrity and confidentiality and logs protected against unauthorized modification (sec.mon.004). +Configuration operations must be tracked (sec.gen.015, sec.mon.006, sec.mon.007). Events such as system access attempts, actions with high privileges, modification of configuration, must be logged and exported on the fly to a non-local storage. The communication channel used for log collection must be protected for integrity and confidentiality, and the logs protected against unauthorised modification (sec.mon.004). Per sec.sys.0016 and sec.lcm.002 requirements, management protocols limiting security risks must be used such as SNMPv3, SSH v2, ICMP, NTP, syslog and TLS. How to secure logging is described in the following section. @@ -304,22 +303,22 @@ To defend against virus or other attacks, security patches must be installed for ### 6.3.7 Monitoring and Security Audit -The intent of this section is to provide a baseline and minimum requirements to implement logging that can meet the basic monitoring and security auditing needs. This should provide sufficient preliminary guidance, but is not intended to provide a comprehensive solution. Regular review of security logs that record user access, as well as session (sec.mon.010) and network activity (sec.mon.012), is critical in preventing and detecting intrusions that could disrupt business operations. This monitoring process also allows administrators to retrace an intruder's activity and may help correct any damage caused by the intrusion (sec.mon.011). +The intent of this section is to provide a key baseline and minimum requirements to implement logging that can meet the basic monitoring and security auditing needs. This should provide sufficient preliminary guidance, but is not intended to provide a comprehensive solution. Regular review of security logs that record user access, as well as session (sec.mon.010) and network activity (sec.mon.012), is critical in preventing and detecting intrusions that could disrupt business operations. This monitoring process also allows administrators to retrace an intruder's activity and may help correct any damage caused by the intrusion (sec.mon.011). -The logs have to be continuously monitored and analysed with alerts created for anomalies (sec.lcm.005). The resources for logging, monitoring and alerting also need to logged and monitored and corrective actions taken so that they are never short of the needed resources (sec.mon.015). +The logs have to be continuously monitored and analysed with alerts created for anomalies (sec.lcm.005). The resources for logging, monitoring and alerting also need to be logged and monitored, and corrective actions taken so that they are never short of the needed resources (sec.mon.015). #### 6.3.7.1 Creating Logs -* All resources to which access is controlled, including but not limited to applications and operating systems must have the capability of generating security audit logs (sec.mon.001). -* Logs must be generated for all components (ex. Nova in OpenStack) that form the Cloud Infrastructure (sec.mon.001). -* All security logging mechanisms must be active from system initialization (sec.mon.018): - * These mechanisms include any automatic routines necessary to maintain the activity records and cleanup programs to ensure the integrity of the security audit/logging systems. +* All resources to which access is controlled, including but not limited to applications and operating systems, must have the capability of generating security audit logs (sec.mon.001). +* Logs must be generated for all components (e.g., Nova in OpenStack) that form the Cloud Infrastructure (sec.mon.001). +* All security logging mechanisms must be active from system initialisation (sec.mon.018): + * These mechanisms include any automatic routines necessary to maintain the activity records and clean-up programs to ensure the integrity of the security audit/logging systems. * Logs must be time synchronised (sec.mon.002). #### 6.3.7.2 What to Log / What NOT to Log ##### What to log Where technically feasible the following system events must be recorded (sec.mon.005): * Successful and unsuccessful login attempts including: - * Command line authentication (i.e. when initially getting token from keystone) + * Command line authentication (i.e., when initially getting token from keystone) * Horizon authentication * SSH authentication and sudo on the computes, controllers, network and storage nodes * Logoffs @@ -330,17 +329,17 @@ Where technically feasible the following system events must be recorded (sec.mon * Creating, removing, or changing the inherent privilege level of users (sec.lcm.012) * Connections to a network listener of the resource * Starting and stopping of processes including attempts to start unauthorised processes -* All command line activity performed by the following innate OS programs known to otherwise leave no evidence upon command completion including PowerShell on Windows systems (e.g. Servers, Desktops, and Laptops) +* All command line activity performed by the following innate OS programs known to otherwise leave no evidence upon command completion including PowerShell on Windows systems (e.g., Servers, Desktops, and Laptops) * Where technically feasible, any other security events should be recorded ##### What NOT to log Security audit logs must NOT contain: -* Authentication credentials, even if encrypted (ex. password) (sec.mon.019); +* Authentication credentials, even if encrypted (e.g., password) (sec.mon.019); * Keystone Token; * Proprietary or Sensitive Personal Information. #### 6.3.7.3 Where to Log -* The logs must be store in an external system (sec.mon.018), in a manner where the event can be linked to the resource on which it occurred. +* The logs must be stored in an external system (sec.mon.018), in a manner where the event can be linked to the resource on which it occurred. * Where technically feasible, events must be recorded on the device (e.g. VM, physical node, etc.) where the event occurs, if the external logging system is not available (sec.mon.021). * Security audit logs must be protected in transit and at rest (sec.mon.004).