Section CB6.1 Third party agreements
(continued)CB6.1.3
Third party agreements should cover management activities, which include:
arrangements for managing changes to the application preparing for and managing information security incidents
the right to audit and monitor security arrangements within the third party
timeframes for completion of transactions (eg processing sales order requests, changing inventory levels, recording manufacturing statistics and updating production schedules) and arrangements for ensuring that transactions cannot be repudiated (eg by using ‘digital signatures’)
the respective liabilities of the parties to the agreement
protection of intellectual property rights, copyright assignment and collaborative work the right to monitor and revoke user activity
details about ownership of the information covered by the agreement actions to be taken in the event of a breach of the agreement the need for information security awareness
maintenance of documentation (eg asset lists and software licences).
CB6.1.4
Third party agreements should cover information security activities, which include:
details of the confidentiality, integrity and availability requirements of information covered by the agreement agreed security controls (eg access mechanisms, malware protection and back-up)
non-disclosure of information gained in the course of work
a requirement to return or destroy information or software on an agreed date, or upon request
how information can be used (eg the processing, storing and exchange of information with additional third parties)
arrangements for the protection of important information (eg cryptographic keys and software).
CB6.1.5
www.securityforum.org
CB
Section CB6.2 Cryptographic key management
Principle
Cryptographic keys should be managed tightly, in accordance with documented standards / procedures, and protected against unauthorised access or destruction.Objective
To ensure that cryptographic keys are not compromised (eg through loss, corruption or disclosure).CB6.2.1
There should be documented standards / procedures for managing cryptographic keys, which cover:
generation of cryptographic keys, using approved key lengths
secure distribution, storage, recovery and replacement / update of cryptographic keys
revocation of cryptographic keys (eg if a key is compromised, or a key owner changes job or leaves the organisation)
recovery of cryptographic keys that are lost, corrupted or have expired
management of cryptographic keys that may have been compromised, such as by disclosure to a third party back-up / archive of cryptographic keys and the maintenance of cryptographic key history
allocation of defined activation / de-activation dates
restriction of access to cryptographic keys to authorised individuals
sharing of cryptographic keys (eg using split key generation) required for protecting sensitive information and critical systems.
Cryptographic keys can be used to protect the confidentiality of information, preserve its integrity, provide strong authentication, and support non-repudiation (ie to enable the identity of the originator of information to be proven).
CB6.2.2
Individuals who clearly understand their responsibilities should be assigned to manage cryptographic keys.
CB6.2.3
Cryptographic keys should be protected against:
unauthorised access destruction.
a) b) c) d) e) f) g) h) i)
a) b)
CB6 Special Topics
www.securityforum.org
CB
Section CB6.3 Public key infrastructure
Principle
Any public key infrastructure (PKI) used by the application should be protected by ‘hardening’ the underlying operating system(s) and restricting access to Certification Authorities.Objective
To ensure that the public key infrastructure (PKI) operates as intended, is available when required and can be recovered in the event of an emergency.CB6.3.1
For an application that uses a public key infrastructure (PKI), documented standards / procedures should be established (eg a Certification Practice Statement (CPS) and one or more corresponding Certificate Policies (CP)), which define the:
process required to manage cryptographic keys / digital certificates associated with the PKI methods required to operate the PKI
actions to be taken in the event of a compromise or suspected compromise of the PKI (eg revocation of the Root Certification Authorities (CA), digital certificates and any sub-CAs).
A Certification Authority (CA) comprises the people, processes and tools that are responsible for the creation, issue and management of public key certificates that are used within a PKI.
CB6.3.2
Users of the public key infrastructure should be made aware of the purpose and function of the PKI and their responsibilities (eg to protect private keys, and how to use digital signatures).
CB6.3.3
Internal Certification Authorities should be protected by:
restricting access to the Certification Authority (eg by using access control mechanisms and strong authentication)
‘hardening’ the operating system(s) that support the Certification Authority (eg by removing all known vulnerabilities, disabling unnecessary services and changing vendor supplied passwords)
employing other general controls (eg change management, back-up and security event logging) in a particularly disciplined manner.
CB6.3.4
Contingency plans for the application supported by the PKI should include methods of recovering the PKI in the event of a disaster.
a) b) c)
a) b) c)
CB6 Special Topics
www.securityforum.org
CB
Section CB6.4 Web-enabled applications
Principle
Specialised procedural and technical controls should be applied to web-enabled applications and the servers on which they run.Objective
To ensure that the increased risks associated with web-enabled applications are minimised.CB6.4.1
The business practices and privacy policies applicable to the website(s) associated with the application should be independently accredited (eg by organisations such as Web Trust, TRUSTe or equivalent).
CB6.4.2
Web servers that support the application should be:
segregated from internal networks and untrusted networks (eg in a ‘Demilitarised Zone’ (DMZ))
run on one or more dedicated computers (ie they do not provide other services such as file and print, database or e-mail or other business applications)
run with ‘least privilege’ (eg excluding the use of high-level privileges, such as ‘root’ for UNIX systems or
‘Administrator’ for Windows systems)
prevented from initiating network connections to the Internet (eg through server configuration or by rules on a firewall)
configured so that scripts can only be run from specified locations
reviewed to ensure that all unnecessary software, network services and applications have been disabled / removed
configured to log security-related events generated by the website.
CB6.4.3
Connections between web servers and back-office systems (eg application and database servers) should be:
protected by firewalls (eg stateful inspection firewalls (typically located in the perimeter of a network), application proxy firewalls (typically located between internal networks) and application firewalls (typically located close to the application))
restricted to services that are essential to the application
restricted to those originating from web server applications (ie rather than originating from client applications) based on documented, tested and approved application programming interfaces (APIs)
supported by mutual authentication (ie two computers verifying each other’s identity before exchanging data).
CB6.4.4
User accounts that are used by web servers to make connections to back-office systems should run with ‘least privilege’ (eg excluding the use of high-level privileges, such as ‘root’ for UNIX systems or ‘Administrator’ for Windows systems).
www.securityforum.org