You need to comply with a particular regulation or standard. Application penetration testing may or may not help you meet its requirements. In this article, we will describe the role that application penetration testing can play in your compliance efforts.
First, what is application penetration testing, exactly? It is a highly structured exercise where a “white hat” cyber security expert behaves as an attacker with malicious intent would behave, in order to test the vulnerability of an application. The expert needs to know what to look for; the more experienced testers have deep experience conducting tests and hands-on experience with IT systems in general and application development specifically.
Application penetration testing for compliance results in a report that spells out the high-risk issues that need to be addressed quickly, plus those that are less severe but still need attention. It should also say what was or was not tested, and why. It should include remediation recommendations.
Once the discovered security gaps have been remediated, you will need to test again to ensure that the previous issues were resolved. Compliance requirements often recommend or require testing on a regular basis to account for recent application updates and newly-discovered vulnerabilities and exploits.
Of course, the securing of user data should be central to any software application development effort; regular penetration testing provides validation of this—both for customers and your industry’s regulatory bodies. Additionally, it is pretty common now for customers or partners to demand proof of regulatory compliance before they will do business with your company.
The Most Common Standards and Regulations
Here are the most common regulations and standards, and whether they require penetration testing. Then we will discuss penetration testing itself.
Common regulations and standards include:
- PCI DSS and PA DSS
- SOC 2
- ISO 27001
- OWASP 10
- CIS CIS Controls
PCI DSS and PA-DSS Compliance
The Payment Card Industry Data Security Standard (PCI DSS) was introduced by card service operators and other types of financial and vendor organizations in 2004. Designed to reduce credit card fraud, the standard requires any merchant who accepts credit/debit card payments online to protect credit card information and secure payment portals, among other items.
PA-DSS is a global standard (also referred to as Payment Application Best Practices) that applies to vendors that produce and sell payment applications. The PA-DSS compliance standards were also created by the Payment Card Industry Security Standards Council. It will be phased out on October 28, 2022.
If you accept credit and debit card payments, you are most likely familiar with the 12 PCI DSS requirements:
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks
- Use and regularly update anti-virus software or programs
- Develop and maintain secure systems and applications
- Restrict access to cardholder data by business need-to-know
- Assign a unique ID to each person with computer access
- Restrict physical access to cardholder data
- Track and monitor all access to network resources and cardholder data
- Maintain a policy that addresses information security for employees and contractors
Penetration testing can help you meet requirements 6 and 11, as it is one of the most effective ways to make sure your applications are secure.
The American Institute of Certified Public Accountants (AICPA) created Service and Organization Controls (SOC) based on the organization’s Trust Services Criteria (TSC). The TSC framework consists of five main trust categories:
Security: Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to achieve its objectives.
Availability: Refers to the accessibility of information used by the entity’s systems as well as the products or services provided to its customers.
Processing Integrity: Refers to the completeness, validity, accuracy, timeliness, and authorization of system processing. Addresses whether systems . . . perform their intended functions in an unimpaired manner, free from error, delay, omission, and unauthorized or inadvertent manipulation.
Confidentiality: Addresses the entity’s ability to protect information designated as confidential from its collection or creation.
Privacy: Personal information is collected, used, retained, disclosed, and disposed of to meet the entity’s objectives.
In the section above, we have called attention to one phrase that relates specifically to penetration testing: whether systems are “free from . . . unauthorized or inadvertent manipulation.” A penetration test is well-suited to meet this objective, as it reveals whether an application is vulnerable to “unauthorized manipulation.” The AICPA does mention penetration testing in its Trust Services guide, in section CC4.1: “Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certification made against established specifications . . . and internal audit assessments.”
ISO 27001, published by the International organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). ISO 27001 was designed to help organizations worldwide protect their information through the adoption of an Information Security Management System (ISMS). Certification ensures customers and partners that their data is responsibly safeguarded, and that the company is keeping up with changes to external threats. ISO 27001 focuses on threats that endanger the confidentiality, integrity, and availability of an organization’s information.
Clause 6.1.2.c in ISO 27001, the “Information Security Risk Assessment” clause, states that companies must develop risk criteria and carry out repeated risk assessments that “produce consistent, valid, and comparable results.”
This process requires that the Chief Information Security Officer (or another staff member or outside consultant operating in that capacity) creates an inventory of all digital assets, and catalogs all threats and vulnerabilities that could harm those assets.
The significance of these risks are then ranked (risk analysis) and decisions are made regarding their acceptability (risk evaluation). Obviously, penetration testing can help you identify vulnerabilities in your applications, which then informs your risk analysis.
The Health Insurance Portability and Accountability Act of 1996 does not specifically require penetration testing. However, in the Administrative Safeguards section, (164.308), in section A (“Risk Analysis – Required”), the regulation requires that organizations “conduct an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.” And in the “Evaluation” section of the HIPAA regulation (164.308(a)(8)) it is required that the organization “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.”
NIST (National Institute of Standards and Technology) publishes a HIPAA guide (“Conduct Evaluation” section, page 31) where they recommend that organizations “conduct penetration testing (where trusted insiders attempt to compromise system security for the sole purpose of testing the effectiveness of security controls), if reasonable and appropriate.”
In fact, as NIST states, these three main objectives of HIPAA (in the “Security Standards: General Rules” section), can be straightforwardly satisfied via penetration testing:
- Ensure the confidentiality, integrity, and availability of EPHI that it creates, receives, maintains, or transmits;
- Protect against any reasonably anticipated threats and hazards to the security or integrity of EPHI; and
- Protect against reasonably anticipated uses or disclosures of such information that are not permitted by the Privacy Rule.
The scope of the testing should be driven by your unique requirements; this is something we work out with each client prior to performing the necessary penetration tests.
In its Technical Guide to Information Security and Assessment, NIST defines testing as “the process of exercising one or more assessment objects under specified conditions to compare actual and expected behaviors.” NIST correctly states that “penetration testing can be invaluable, but it is labor-intensive and requires great expertise to minimize the risk to targeted systems. . . . [it] should be performed only after careful consideration, notification, and planning.”
The NIST SP 800-53 is a set of standards and controls for all U.S. Federal IT systems except those related to US national security. (By the way, this link includes a Control Catalog Spreadsheet that includes the “entire security privacy and control catalog” in a spreadsheet format, which might be helpful.)
Section CA-8 states: “A standard method for penetration testing includes a pretest analysis based on full knowledge of the system, pretest identification of potential vulnerabilities based on the pretest analysis, and testing designed to determine the exploitability of vulnerabilities. All parties agree to the rules of engagement before commencing penetration testing scenarios. Organizations correlate the rules of engagement for the penetration tests with the tools, techniques, and procedures that are anticipated to be employed by adversaries. Penetration testing may result in the exposure of information that is protected by laws or regulations, to individuals conducting the testing. Rules of engagement, contracts, or other appropriate mechanisms can be used to communicate expectations for how to protect this information. Risk assessments guide the decisions on the level of independence required for the personnel conducting penetration testing.”
The GDPR is an EU regulation focused on the collection and security of personal data (i.e., personally identifiable information, or PII). It affects companies in the US that have customers in the EU. The regulation had an immediate and profound effect on companies worldwide, in no small part due to the hefty fines for non-compliance: up to 20 million euros or 4% of a company’s annual gross revenue, whichever is higher.
GDPR does not mention penetration specifically but states in Article 32 that organizations should take measures to “ensure a level of security appropriate to the risk . . . including . . . a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing.” Of course, it is applications that typically do the “processing,” and application penetration testing is the method used most often for evaluating the effectiveness of the security measures in place.
The regulation is enforced by the Information Commissioner’s Office (ICO). They do mention penetration testing in various pages on their website. “Run regular vulnerability scans and penetration tests to scan your systems for known vulnerabilities,” they advise, in this guide aimed at small businesses. On their detailed Security page, they say:
Yes, the UK GDPR specifically requires you to have a process for regularly testing, assessing and evaluating the effectiveness of any measures you put in place. What these tests look like, and how regularly you do them, will depend on your own circumstances. However, it’s important to note that the requirement in the UK GDPR concerns your measures in their entirety, therefore whatever ‘scope’ you choose for this testing should be appropriate to what you are doing, how you are doing it, and the data that you are processing.
Technically, you can undertake this through a number of techniques, such as vulnerability scanning and penetration testing. These are essentially ‘stress tests’ of your network and information systems, which are designed to reveal areas of potential risk and things that you can improve.
Any applications containing personal information need to be tested. These can include CRM systems, payroll systems (whether developed/run in-house or by a third-party payroll provider), and any applications/portals that require customer authentication.
The United States Department of Defense is the authority behind the Cybersecurity Maturity Model Certification (CMMC), and is designed to standardize cyber security efforts across the federal government’s defense industrial base. It specifies five levels of security. All DoD contractors and subcontractors were required to have level 1 certification by December 21, 2020. The maturity levels are:
- Maturity Level 1 – Basic Cyber Hygiene, with the goal of safeguarding federal contract information
- Maturity Level 2 – Intermediate Cyber Hygiene, which serves as a transition step to protect Controlled Unclassified Information (CUI)
- Maturity Level 3 – Good Cyber Hygiene, which serves to protect CUI
- Maturity Level 4 – Proactive Cyber defenses, which works with Level 5 to protect CUI and reduce risk of Advanced Persistent Threats (APTs)
- Maturity Level 5 – Advanced/Progressive cyber defense
Maturity Level 3 is where penetration testing is mentioned (CA.4.164): “Conduct penetration testing periodically, leveraging automated scanning tools and ad hoc tests using human experts.”
The CMMC model consists of 17 domains, most of which come from the Federal Information Processing Standards (FIPs) Publication 200, and the security requirements listed in NIST SP 800-171. The 17 domains include:
- Access Control
- Asset Management
- Audit and Accountability
- Awareness and Training
- Configuration Management
- Identification and Authentication
- Incident Response
- Media Protection
- Personnel Security
- Physical Protection
- Risk Management
- Security Assessment
- Situational Awareness
- System and Communications Protection
- System and Information Integrity
Obviously, the more you rely on DoD contracts, the more you will want to move up the maturity scale to stay ahead of the DoD’s hard and fast deadlines.
OWASP Top 10
The Open Web Application Security Project (OWASP) is the preeminent standards-setting body for web application security. Consisting of a global network of community contributors, the organization is responsible for creating and maintaining the OWASP Top 10—a standards framework for improving software security and resilience. Its OWASP Top 10 has become a standard go-to reference for application pentesters and web application security professionals. Meeting OWASP compliance helps developers ensure that their applications are safe from malicious exploits and compromises.
CIS CIS Controls
The Center for Information Security’s (CIS) CIS Controls is a set of benchmarks and guidelines for protecting against the most common attack vectors. Formerly known as the SANS Critical Security Controls (SANS Top 20) and the CIS 20 Critical Security Controls, the two standards have since been merged and are now collectively referred to as the CIS Controls.
Control 20 recommends that firms: “Establish a program for penetration tests that includes a full scope of blended attacks, such as wireless, client-based, and web application attacks.”
Now that we are done looking at the various regulations and their requirement for pen testing, let’s look at the particulars of application penetration testing.
Application Penetration Testing: A quick overview
The most meaningful result of a pen test is a report showing how attackers could gain access to customer or confidential information. The data in the report can then be used to fix security flaws before attackers can exploit them. Of course, as we all know, the techniques that attackers use are constantly evolving, which is why penetration tests need to be conducted on a regular basis. In addition, some regulations (PCI DSS, for example) also require that penetration tests be conducted after vulnerabilities have been remediated, to ensure that they have been sufficiently addressed.
This, by the way, can be a weakness of the pen testing process. It’s not enough to generate a report or even use that information to secure the risks found through the test. The success of those repairs needs to be confirmed.
Another advantage of application penetration testing is that it approaches your application as an attacker would, searching for any exploitable vulnerabilities. The attacker doesn’t care about the source of the vulnerability, which can include coding misconfigurations; end-user error; entries to the application via application programming interfaces (APIs);
White hat penetration testing is critical for surfacing software security issues exploitable through methods such as:
- SQL Injection: The attacker interrupts the queries that an application makes to the database associated with the application. The attacker is able to view and even modify data in the database or the application. Obviously this puts customer or confidential data at risk, but it can also give the hacker temporary or long-term access to the backend infrastructure, including servers.
- XSS (Cross Site Scripting): This is another injection type of attack, where an attacker uses a web application to send malicious code that an end user’s browser executes. Untrusted data is inserted into an HTML response, and used to access cookies, session tokens, or other information. These scripts can be used to rewrite the content of an HTML page.
- CSRF (Cross Site Request Forgery): This type of attack fools the user into carrying out undesirable actions inside a web application that they have access to, including transferring funds or altering their email address. If the user is an administrator, the entire web application can be compromised.
- Weak Passwords: This one is pretty obvious, and quite common. A large majority of attacks involve stolen passwords, gained through methods such as phishing; dictionary attacks (e.g., using the most common passwords); brute force attacks (e.g., using alphanumeric combinations); keylogger attacks (e.g., where the attacker uses a key-logging program installed using malware); and spidering (e.g., crawling sites for words or phrases that might be used for passwords).
In addition to being carried out for compliance purposes, penetration tests should also be conducted when major changes are made to the IT infrastructure or when new cybersecurity threats emerge.
The types of application penetration tests and related services we typically conduct for clients automated/manual code reviews,static or white box testing, dynamic or black box testing, grey box penetration testing (i.e., a combination of both white and black box testing), architectural risk assessments, threat modeling, API evaluations, web application assessments and social engineering assessments.
Our goal with all clients is to be both appropriate and thorough—appropriate in the sense that the tests required match the company’s compliance and overall cyber security needs and goals and thorough in the sense that we are “buttoned up” in all aspects of designing/conducting the tests and communicating in-progress status and final results. Our current clients can attest to the level of professionalism and reliability we bring to every project. If you are looking for penetration testing services or evaluating penetration testing companies, let us know if we can help.