PCI DSS guides how web applications and related systems that process, store or transmit cardholder data should be secured in compliance, specifically web application security.
Any way you look at it, almost all changes to PCI DSS affect web application security in some way. With a detailed look at PCI requirement 6, which has the most impact on web application security, you should be aware of the following:
- To understand what can happen if a vulnerability is exploited, you should use industry best practices and focus more on risk impact.
- You must use a web application firewall or other technology that may provide similar results.
- Web application penetration tests must include all vulnerabilities (SQLi, XSS, CSRF, etc.) listed in PCI DSS Requirement 6.5. Security issues should be addressed in a way that closely aligns with the OWASP Top 10 web application security risk.
- Assessing processes and documentation, interrogating persons, and examining system configuration settings are all recommended test methodologies for PCI DSS Requirement 6.6 to ensure proactive security controls are in place.
- Third parties or internal organizations may execute the security testing indicated in PCI DSS Requirement 6.6 as long as they remain independent of the developers.
In conclusion, if you have a robust information security program, you probably meet the PCI DSS web application security requirements. If not, you’ve got some work ahead of you. Following the guidelines in our article, you can make your online application PCI DSS compliant.
It’s critical to concentrate your attention on your Web applications if you need to store credit card data or want to improve your current security standards. PCI DSS Requirement 6.6 requires you to ensure that all Web-facing applications are protected from known attacks by using one of the following methods:
- An organization or person specializing in application security should analyze all custom application code for common vulnerabilities.
- An application-layer firewall should be installed in front of web-facing apps.
Instead of a simple source code review, automated source code review and automated and manual Web vulnerability assessment tools will also meet the requirement. Also, using a Web application firewall alone will not be enough to meet the PCI web application security requirement; however, if a WAF is used, it must be configured appropriately.
To figure out which of the solutions listed below is best for your business, you’ll need to know all of their advantages and disadvantages.
- Code reviews are when an expert or a tool examines your source code to look for vulnerabilities. In this way, you can identify both security vulnerabilities in your code and bad coding practices.
- Web vulnerability assessments or PCI external vulnerability tests are done from the perspective of an outside attacker trying to extract data from your system. Because vulnerability scan checks are only external, it usually results in faster results than a typical code review. PCI external vulnerability tests focus on what is vulnerable and test what is likely to be hacked.
- Web application firewalls (WAF) are not the same as the traditional firewalls that most people are familiar with, but they do the same job. Web application firewalls can use the blacklist approach, the whitelist approach, or a combination of the two. The level of data that a Web application firewall interacts with is crucial between it and a regular firewall. Traditional firewalls operate at the network/transport layer. On the other hand, Web application firewalls concentrate solely on the application layer and any mechanism that might be used to attack the Web application. Web application firewalls are frequently used as a second level of defense behind a standard firewall, preventing attacks on the Web application.
None of the options guarantee your complete security. Code reviews and vulnerability assessments are snapshots that examine your current level of vulnerability and may overlook some flaws.
When you make changes to application code or your infrastructure, you must make additional considerations. For your company and web application to be secure, you need to address any vulnerabilities found in the code.
Web application firewalls typically do not monitor business logic or access control violations, and a smart attacker who can overcome the filter can sometimes get through them. That is why a tiered security approach is preferable.
If you’re interested in using PCI to take advantage of a more secure system, the solution is to try to get as much defense as possible by complementing your strengths with your weaknesses.
If you don’t know which approach to follow to secure your Web Application, you can start with the following items:
- Determine your company’s most vulnerable areas and concentrate your efforts there first.
- Inquire about cross-site scripting, SQL injection, and access control violations with your developer. If they understand this terminology, ask if they have coded to prevent such attacks. If they respond positively, a code review/vulnerability assessment will show your developer’s security maturity. Deploying an application firewall is an excellent complement to what you already have. If your code contains application vulnerabilities that you are unaware of, it offers another degree of protection to your environment.
- If your developers can’t answer how they protect the app when you ask about app attacks, a code review/vulnerability assessment would be your best bet. A code review will reveal areas where code is not written securely, what your developers are doing incorrectly, and how they may improve. Once you have this information, you can create policy/code guidelines that will guide your existing or future development resources toward safer coding.
In a perfect world, it’s recommended to implement both code review/vulnerability assessment and application firewall, but your budget might not allow it. You can conduct due diligence with your staff or development resources and make the necessary planning to assess their security capabilities and identify the approach that complements the applications you already have or creates the building blocks for a safer application shortly.
How to Ensure PCI DSS Compliance for Web Applications?
Today, vulnerable websites and unsafe web applications have become one of the easiest ways to compromise the networks of small, medium, and large companies. By PCI DSS, Requirement 6.6 defines requirements for websites and web applications security.
See Also: What Does PCI Compliant Software Development Mean for Developers
According to the PCI DSS, attackers target public online applications first, and poorly developed web apps make it easier for them to access critical data and systems.
Essentially, to keep PCI Requirement 6.6 and public web applications secure, you must continually address new threats and vulnerabilities and ensure that these applications are protected from known attacks.
See Also: Best Practices and Recommendations for API Security
What is important here is the “always-on” condition, which clarifies that web security is a permanent process and emphasizes the importance of continued web security.
See Also: PCI DSS Session Timeout Requirements
PCI DSS proposes two ways to meet the web application security requirement:
- Manual or automated application vulnerability security assessment techniques or methodologies should be used to examine publicly exposed online applications at least once a year and after any modifications.
- An automated technical solution must be installed in front of public web applications that constantly detect and prevent web-based attacks from controlling all traffic (Web application firewall).
PCI DSS Web Application Security Test
For web application security testing, PCI recommends both manual and automated methods. Because both approaches have advantages and disadvantages, you can achieve the maximum level of application security by combining automated vulnerability scanning and manual penetration testing.
See Also: What Are the Impact Analysis Requirements for PCI DSS Compliance
You also need to ensure that all vulnerabilities in PCI Requirement 6.5 are included in the assessment. According to PCI Requirement 6.5, these vulnerabilities are as follows:
- Injection flaws, especially SQL injection
- OS Command Injection, LDAP, and XPath injection vulnerabilities
- Buffer overflows vulnerabilities
- Insecure cryptographic storage vulnerabilities
- Unsecured communication channels
- Incorrect error handling
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
- Broken authentication and session management
- Improper access control (unsafe direct object references, URL access restriction error).
Most of the web vulnerabilities mentioned above cannot be reliably detected by automated vulnerability scanning alone and require manual testing by security experts.
You must also select the appropriate penetration testing provider for PCI penetration testing. Even if your institution has an automated vulnerability scanning tool, choosing a suitable penetration testing provider can be more difficult. PCI DSS specifies that web application penetration testing will be performed by an organization specializing in application security.
Such an organization can be an organization, a third-party company, or an internal employee, as long as it can demonstrate that it specializes in application security and is independent of the development team.
The most crucial point here is independence. As a result, it’s always a good idea to select vendor and product agnostic penetration testing firms that don’t resell, integrate, or install IT security solutions. This could lead to a potential conflict of interest during the audit.
Ideally, penetration testing starts where a vulnerability scan ends. A penetration testing process considers reports from several different vulnerability scans and continues by quickly eliminating false positives and, most importantly, performing manual testing to detect overlooked vulnerabilities.
Especially in penetration tests, weaknesses in the application business logic that vulnerability scanners fail to detect efficiently are likely to be noticed and show how otherwise minor technical flaws can be chained to commit a significant breach.
What are the methods that can be used for PCI DSS Web Application Compliance?
PCI-DSS compliance requires organizations to either resort to code audits or install a Web Application Firewall to secure public Web applications.
A code audit puts a significant strain on a company with a large code that needs to be reviewed. This results in a considerable amount of time and cost for each application. Also, code auditing provides some points of protection.
A quarterly review should take place to account for any changes in the application code. However, this puts a burden on organizations by forcing software developers to fix security vulnerabilities instead of innovating.
Because web applications pose a high risk of vulnerability, PCI DSS specifically addresses them in Requirement 6.6. This indicates that organizations should ensure the highest level of application security because of the increased risk of PCI web applications.
PCI DSS Requirement 6.6 aims to ensure that web applications exposed to the public Internet are safe from the most frequent types of harmful input.
To comply with PCI DSS requirement 6.6, a company must conduct code reviews or use a web application firewall.
Code review for PCI DSS
The first alternative can provide a high level of security but can be an extremely costly solution. Organizations often use several apps and add new ones all the time. The total cost of code reviews consists of the review itself and the effort required to fix the vulnerabilities it identifies.
See Also: How to Perform Code Reviews for PCI Requirements
The IT team needs to prepare the code for review and be available for review. After consultants submit a vulnerability report, your organization will also need to plan remediation and testing cycles to ensure changes are working as expected.
The application testing cycle may not always find all vulnerabilities in an application, resulting in more cycles. Furthermore, Quality Assurance will need to verify that security fixes do not interfere with business processes. Therefore, any organization that chooses the code review alternative should dedicate the following resources annually:
- Services offered by application security experts
- IT resources are necessary to administer the code review process.
- Resources for developers to eliminate vulnerabilities
- QA resources
- R&D risks required by the development of security fixes and features
More importantly, a code review finds vulnerabilities known to the reviewer during the inspection. Unless the code reviewer is highly aggressive and above and above their mandated tasks, zero-day vulnerabilities that have yet to be detected are likely to go undiscovered.
Thus, the second alternative, installing a web application firewall, becomes a more attractive solution as it provides a one-time PCI compliance solution.
Web Application Firewall for PCI DSS
Another PCI-recommended method for safeguarding online applications is a Web Application Firewall (WAF). A Web Application Firewall (WAF) is an essential tool, but it should never be utilized in isolation from other security measures.
Modern web apps evolve at a rapid pace. Following modifications, updating current WAF rulesets, or introducing new ones is a time-consuming operation that frequently results in false negatives or outcomes.
Theoretically, a static web application with a dynamic but straightforward architecture or a WAF configuration ideal for a dynamic web application, free of false positives and false negatives, could exist.
However, some attacks against your web application, such as CSRF or application logic manipulations, authentication bypass, or complicated XSS inside JS code, will never be consistently blocked by WAF.
Most businesses choose to block only the most common and most apparent attack patterns on web traffic, giving hackers many opportunities to bypass WAF. Therefore, a WAF should always be completed with the web mentioned above security scanning and web application penetration testing.
Web application firewalls focus on protecting against vulnerabilities rather than identifying them. They create a layer of security in front of the application by performing a deep packet inspection of incoming traffic to detect threats.
This approach offers the following advantages:
- One-time investment for PCI compliance
- Quick fix for security issue without development effort
- Compatibility for third-party applications and components where the code is not easily accessible
Application Source Code Analysis for PCI DSS
Application security is a critical element for organizations seeking to be PCI compliant. Application attacks compromise logical flow and data processing from within the application, access sensitive data, and more.
See Also: Source Code Analysis for PCI DSS Application Security
Identifying and removing vulnerabilities during development and testing is the most effective way to mitigate these risks. In traditional application security solutions, security scans find vulnerabilities, but details must be passed to development, logged in to an issue tracker, prioritized, and tracked. These are separate workflows with separate systems and different perspectives.
See Also: PCI Secure Coding Training Requirements
Application source code analysis types are as follows:
- Static Application Security Testing (SAST) analyzes an application’s source code for common vulnerabilities. SAST automated code review helps developers quickly identify and resolve issues in their development workflow.
- Dynamic Application Security Testing (DAST) scans running web applications for common vulnerabilities. DAST is essentially automated penetration testing. DAST uses the CI/CD-built review application to test earlier in the application lifecycle than independent security tools.
