Whether you’re working in finance, healthcare, or e-commerce, complying with industry regulations and business standards is a part of everyday working life. Over the years, information security has started to work its way into many compliance requirements, ensuring that businesses are putting in place relevant processes to identify, assess and address vulnerabilities across key areas of their operation.
Penetration testing can play a core role in this process; however, the use of penetration testing is not always a requirement to achieve compliance.
With that in mind, we thought we’d give you an overview of some of the key regulations we often deal with, outline the specific information security requirements within them and determine where penetration testing is a specific requirement.
Payment Card Industry Data Security Standard (PCI DSS)
The security of cardholder data is vital and if you are an organisation that processes, stores or transmits credit card payments, then you must comply with the Payment Card Industry Security Standard (PCI DSS), whether you are a start-up or a global enterprise.
Payment card industry compliance is mandated by credit card companies and ensures that organisations are maintaining a certain level of security around their Card Data Environment (CDE), therefore protecting consumer transactions as much as possible.
In relation to information security and penetration testing, there are several specific clauses you need to be aware of:
6.1 – Identify security vulnerabilities in your internal and external applications by using reputable outside sources for security vulnerability information and assign a risk ranking (e.g., ‘high,’ ‘medium,’ or ‘low’) to each vulnerability.
6.2 – Ensure that all software and system components are protected from known vulnerabilities by installing any applicable security patches. You must install the patches within the first month following their release.
6.6 – For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.
11.3.1 – Conduct external penetration tests at least once a year and after any significant changes or upgrades to the infrastructure/application (for example, upgrading the system, adding a subnet or webserver to the environment, etc.).
11.3.2 – Conduct internal penetration tests at least once a year and after any change or upgrade significant infrastructure or the application (for example, upgrade of the operating system or adding a subnet or web server in the environment).
11.3.3 – Vulnerabilities found during the penetration tests must be corrected and additional testing performed until the vulnerabilities have been corrected.
11.3.4 – If segmentation is used to isolate the CDE from other networks, this requirement mandates a penetration test at less once a year and following modification of the methods/controls of segmentation to verify that the segmentation methods are operational and effective.
As you can see, penetration testing not only helps in the development and maintenance of secure systems and applications (PCI DSS Requirement 6), but annual penetration testing is also mandated within its own testing requirements section (PCI DSS Requirement 11).
Find out more about our PCI DSS services here.
ISO 27001
ISO 27001 (also known as ISO/IEC 27001:2013) is an internationally recognised standard for information security, helping organisations establish, implement, maintain, and continually improve their information security management systems (ISMS).
Any organisation, whatever size, sector or shareholder structure, can implement ISO 27001 and certification requires organisations to identify and address security risks over time, applying controls to help ensure information assets remain safe and secure.
When it comes to penetration testing, how does this fit within IS0 27001?
A.12.6.1 – Information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organisation’s exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.
Penetration testing is not specifically mandated by ISO 27001; however, it can contribute to, and provide evidence for A.12.6.1. It can also help support organisations in providing assurances around their risk assessment, risk treatment and ongoing security improvement efforts.
Find out more about our ISO 27001 compliance services.
General Data Protection Regulation (GDPR)
The General Data Protection Regulation (GDPR) is probably one of the most widely known regulations, as it impacts almost all organisations that process personal data and operate or sell goods within the EU. Within the UK, GDPR requirements sit within the Data Protection Act 2018 (DPA), so still apply even though we may have left the EU.
GDPR was introduced to help standardise data protection laws and give people greater control over how their personal information is used. The regulation covers practically every type of data usage and how that data is ‘processed’, essentially how it is collected, stored, retrieved, altered, and destroyed.
But what does GDPR specifically say about information security and penetration testing? For that we turn to article 32:
Article 32 – Implement a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
Penetration can be used to meet this requirement; however, it is not specifically mandated. According to the Information Commissioner’s Office (ICO) penetration testing can be seen as good practice, advising organisations to:
“Run regular vulnerability scans and penetration tests to scan your systems for known vulnerabilities – make sure you address any vulnerabilities identified.” (ICO – A practical guide to IT security’)
The use of penetration testing is therefore down to the individual organisation; the data they hold and the risk that data would possess if it were to be accessed by a malicious threat. When data is of a sensitive nature and there is a high risk associated, we would certainly recommend conducting a penetration testing as best practice on an annual basis, providing the necessary assurances to your organisation and to the ICO in the case of any breach.
Service & Organisation Controls 2 (SOC 2)
SOC 2 is a voluntary international compliance standard for technology service providers and Software-as-a-Service (SaaS) companies. Developed by the American Institute of Certified Public Accountants (AICPA), it specifies how organisations should handle and store customer data based on the criteria of security, availability, processing integrity, confidentiality, and privacy.
The standard can also apply to any third-party vendors, partners, or support organisations working with the technology service provider, ensuring the integrity of their data systems and safeguards.
So, how does information security fit into SOC 2?
CC4.1 / COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
CC7.1 – The entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
As you can see, penetration testing is not specifically required to satisfy the relevant clauses set out in SOC 2, however it can be used to provide assurances, specifically in relation to CC4.1.
NIS Directive or NIS Regulations
The NIS Directive (Directive on security of Network and Information Systems) is an EU-wide cyber security legislation aimed at setting a high level of network and information system security across the EU’s (and the UK’s) critical infrastructure.
The regulation applies to two specific areas of critical infrastructure:
- Operators of Essential Services (OES) i.e. energy, transport, health, water etc.
- Digital Service Providers (DSP) i.e., online search engines, online marketplaces & cloud computing services (excluding smaller cloud service enterprises)
As you would expect, information security features heavily in the NIS Directive, however, we’ve outlined just some of the key clauses you may need to be aware of:
For OES:
Principle: A2 Risk Management
A2.a Risk Management Process – Your organisation has effective internal processes for managing risks to the security of network and information systems related to the operation of essential functions and communicating associated activities.
A2.b Assurance – You have gained confidence in the effectiveness of the security of your technology, people, and processes relevant to essential functions.
Principle: A4 Supply Chain
A4.a Supply Chain – The organisation understands and manages security risks to networks and information systems supporting the operation of essential functions that arise as a result of dependencies on external suppliers. This includes ensuring that appropriate measures are employed where third party services are used.
Principle: B3 Data Security
B3.b Data in Transit – You have protected the transit of data important to the operation of the essential function. This includes the transfer of data to third parties.
B3.c Stored Data – You have protected stored soft and hard copy data important to the operation of the essential function.
Principle: B4 System Security
B4.b Secure Configuration – You securely configure the network and information systems that support the operation of essential functions.
B4.c Secure Management – You manage your organisation’s network and information systems that support the operation of essential functions to enable and maintain security.
B4.d. Vulnerability Management – You manage known vulnerabilities in your network and information systems to prevent adverse impact on the essential function.
For DSP:
SO 04 – Third party management
The DSP establishes and maintains a policy with security requirements for contracts with suppliers and customers. SLAs, security requirements in contracts, outsourcing agreements etc., are established to ensure that the dependencies on suppliers and residual risks do not negatively affect security of the offered services.
SO 10 – Access control to network and information systems
The DSP established and maintains appropriate policies and measures for access to business resources. For example, zero trust model, ID management, authentication of users, access control systems, firewall and network security etc.
SO 11 – Integrity of network components and information systems
The DSP establishes, protects, and maintains the integrity of its own network, platforms and services by taking steps to prevent successful security incidents. The goal is the protection from viruses, code injections and other malware that can alter the functionality of the systems or integrity or accessibility of information.
SO 20 – System tests
The DSP establishes and maintains appropriate procedures for testing key network and information systems underpinning the offered services.
SO 21 – Security assessments
The DSP establishes and maintains appropriate procedures for performing security assessments of critical assets.
SO 25 – Software security
The DSP establishes and maintains a policy which ensures that the software is developed in a manner which respects security.
Penetration testing is not specifically mandated under the NIS Directive; however, it can be used to show high level compliance across several of the security objectives outlined above.
Health Insurance Portability and Accountability Act (HIPAA)
The HIPAA (Health Insurance Portability and Accountability Act) is a US federal law designed to protect sensitive patient health information.
The act applies to companies handling the protected health information (PHI) of U.S. citizens and primarily focuses on healthcare providers (doctors, dentists, pharmacies, psychologists etc…) and health plans (health insurance, health maintenance organisations etc), but can also be applied to clearing houses (companies that process health information).
164.308(a)(1)(ii)(a) – Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.
164.308(a)(1)(ii)(b) – Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a).
164.308(a)(8) – Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity‘s or business associate‘s security policies and procedures meet the requirements of this subpart.
The HIPAA regulation does not specifically require that a penetration test be conducted. However, the regulations do require that covered entities perform a security risk analysis to evaluate risks and vulnerabilities in their environments, and to implement security controls to address those risks and vulnerabilities. Something a penetration test can help provide.
Sarbanes-Oxley Act (SOX)
The Sarbanes-Oxley Act of 2002 (often called SOX or Sarbox) is a US law designed for publicly traded companies, along with their wholly owned subsidiaries and foreign companies that are publicly traded and do business in the U.S. It was designed primarily to protect investors from fraudulent accounting activities by corporations following high profile accounting scandals such as at Enron.
Whilst SOX does not have a specific focus on information security, it does have an impact on information systems, requiring organisations to have policies & procedures which prevent, detect, and disclose cybersecurity risks and incidents that could be significant to the accuracy and security of data that feeds into financial reporting.
So, what clauses are relevant when it comes to information security?
Section 404 – Management Assessment of Internal Controls – All annual financial reports must include an Internal Control Report stating that management is responsible for an “adequate” internal control structure, and an assessment by management of the effectiveness of the control structure. Any shortcomings in these SOX controls also must be reported. In addition, registered external auditors must attest to the accuracy of the company management’s assertion that internal accounting controls are in place, operational and effective.
SOX does not specifically require that a penetration test be conducted, however, it can help organisations assess risks, discover weaknesses, and decide which countermeasures to put into place.
Gramm-Leach-Bliley Act (GLBA)
The Gramm-Leach-Bliley Act (GLB Act or GLBA) is a US based federal law that requires US based financial institutions and organisations offering financial services, investment, insurance, and financial advice, to explain how they share and protect their customers’ private information.
Under the GLBA, many organisations qualify as ‘financial institutions’, including organisations that may not normally consider themselves to be so – such as check-cashing businesses, payday lenders and mortgage brokers.
In terms of information security, organisations need to be aware of the following requirements under the GLBA:
314.4 d
(1) Regularly test or otherwise monitor the effectiveness of the safeguards’ key controls, systems, and procedures, including those to detect actual and attempted attacks on, or intrusions into, information systems.
(2) For information systems, the monitoring and testing shall include continuous monitoring or periodic penetration testing and vulnerability assessments. Absent effective continuous monitoring or other systems to detect, on an ongoing basis, changes in information systems that may create vulnerabilities, you shall conduct:
(i) Annual penetration testing of your information systems determined each given year based on relevant identified risks in accordance with the risk assessment.
As you can see, the GLBA requires that information security testing is undertaken. However, this can take the form of continuous monitoring or periodic penetration testing and vulnerability assessments. Where continuous monitoring is absent penetration testing is mandated.
Federal Information Security Management Act (FISMA)
The Federal Information Security Management Act (FISMA) is a US legislation which applies to federal agencies, state agencies administering federal programs and any private businesses that are involved in a contractual relationship with the US government.
The act establishes a set of guidelines and security standards that federal agencies must meet and was introduced to reduce the security risk to federal information and data while managing federal spending on information security.
When it comes to information security and penetration testing, there are several relevant clauses to consider:
NIST SP 800-53, REV. 5
3.4 ASSESSMENT, AUTHORIZATION, AND MONITORING
CA-8 – Penetration Testing – Control: Conduct penetration testing [Assignment: organization-defined frequency] on [Assignment: organization-defined systems or system components].
(1) PENETRATION TESTING AGENT OR TEAM – Employ an independent penetration testing agent or team to perform penetration testing on the system or system components.
(2) RED TEAM EXERCISES – Employ the following red-team exercises to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement: [Assignment: organization-defined red team exercises].
(3) FACILITY PENETRATION TESTING – Employ a penetration testing process that includes [Assignment: organization-defined frequency] [Selection: announced; unannounced] attempts to bypass or circumvent controls associated with physical access points to the facility.
3.17 SYSTEM AND SERVICES ACQUISITION
SA-11 DEVELOPER TESTING AND EVALUATION
(5) PENETRATION TESTING – Require the developer of the system, system component, or system service to perform penetration testing: (a) At the following level of rigor: [Assignment: organization-defined breadth and depth of testing]; and (b) Under the following constraints: [Assignment: organization-defined constraints]
3.18 SYSTEM AND COMMUNICATIONS PROTECTION
SC-7 BOUNDARY PROTECTION
(10) PREVENT EXFILTRATION (a) Prevent the exfiltration of information; and (b) Conduct exfiltration tests [Assignment: organization-defined frequency].
3.20 SUPPLY CHAIN RISK MANAGEMENT
SR 5 ACQUISITION STRATEGIES, TOOLS, AND METHODS
Control: Employ the following acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks: [Assignment: organization-defined acquisition strategies, contract tools, and procurement methods].
(2) ASSESSMENTS PRIOR TO SELECTION, ACCEPTANCE, MODIFICATION, OR UPDATE Assess the system, system component, or system service prior to selection, acceptance, modification, or update.
As you can see, penetration testing features heavily within FISMA (& the associated NIST SP 800-53 framework), particularly CA-8, which is dedicated to penetration testing and red teaming within the organisation. The frequency and coverage of these tests is defined by the organisation itself and should be dictated by risk assessments carried out.
But that’s not the only area penetration testing is required, it is also required of developers and can be extremely useful in assuring boundary protection as part of the supply chain risk management process.
NHS National Data Guardian’s (NDG) Data Security Standards
The National Data Guardian’s (NDG) Data Security Standards applies to UK organisations who are handling health & social care information and has been designed to protect critical IT services from disruption, and protect extremely sensitive health & social information.
The application of the standard will depend on the type and size of organisation; however, information security plays a key role throughout the obligations:
Leadership Obligation 2: Process: ensure the organisation proactively prevents data security breaches and responds appropriately to incidents or near misses.
- Data Security Standard 4. Personal confidential data is only accessible to staff who need it for their current role and access is removed as soon as it is no longer required. All access to personal confidential data on IT systems can be attributed to individuals.
Leadership Obligation 3: Technology: ensure technology is secure and up-to-date.
- Data Security Standard 9. A strategy is in place for protecting IT systems from cyber threats which is based on a proven cyber security framework such as Cyber Essentials. This is reviewed at least annually.
Whilst penetration is not specifically mandated under NHS NDG Standards, it can be used to provide key assurances as part of the obligations above.
SWIFT Customer Security Program (CSP)
The SWIFT Customer Security Program (CSP) is an international security framework designed to improve the security of the SWIFT interbank system and the institutions which use it.
The program contains controls, both mandatory and advisory, to help secure environments, restrict access, as well as detect and respond to treats. Using the Customer Security Controls Framework (CSCF), organisations can evaluate their security measures against the security controls outlined, ensuring they have the correct level of compliance for their organisation.
But how does penetration testing fit into SWIFT CSP?
Principle 7 – Plan for Incident Response and Information Sharing
Control 7.3 – Penetration Testing – Validate the operational security configuration and identify security gaps by performing penetration testing.
As you can see Penetration testing is specifically mentioned within control 7.3 of SWIFT CSP, however it is an advisory control, and therefore not mandated. Due the sensitive nature of the information, penetration testing should be seen as best practice and can also assist in providing assurances around other SWIFT CSP principles, specifically:
- Principle 2 – reduce attack surface & vulnerabilities
- Principle 4 – prevent compromise if credentials
- Principle 5 – manage identities and segregate privilege
How can Pentest assist when it comes to compliance?
Whether penetration testing is mandated or not, security testing can play a vital role throughout the compliance process, particularly in the regulations outlined above. As a company, we work with organisations from across the globe, not only assisting them in relation to their regulatory requirements, but to help take their information security beyond compliance. Ultimately, providing them with the information security confidence they, their clients and their regulators need. So, if you’re looking to meet you information security compliance requirements or just want to take your security to the next level, why not get in touch with us and see how we can help you and your organisation.
