There is a challenge facing any organization that has to meet compliance requirements – how to continuously meet those requirements and (even exceed them) by implementing a robust information security program tailored to the organization’s business, technology, threats, etc. – while ensuring a higher degree of security.
Many people are under the mistaken assumption that once they’ve met their compliance requirements, they are secure because compliance provides “good enough” security. Unfortunately, this is not necessarily true. Here’s why: it’s possible to be compliant but not “fully secure” because “secure” is always contextual to an organization and the unique and constantly evolving threats they face.
It is important to note that most compliance guidance is really a minimum level of security. Compliance standards are often prescriptive actions that are known to help improve security. In the specific case of Payment Card Industry Data Security Standard (PCI DSS), it is a great baseline standard, but it can’t possibly consider all the unique and evolving threats that each organization faces. Standards are guidance at a point in time, but the bad guys (and our systems, networks, and software) keep moving forward. As far as application security is concerned, there is no single standard that defines everything. Network and system security are mature areas and tend to have deeper coverage in the standard. But ultimately, it is up to each organization to consider the particulars of their business, infrastructure, and processes to incorporate the compliance guidance into a broader security initiative that tunes the security activities to the special nature of every organization.
While organizations work hard to become compliant, it’s still possible to be vulnerable to an attack due to gaps in their security posture.
With that said, let’s take a look at some specific examples of how being compliant doesn’t necessarily make you secure. I will make some recommendations that can help improve your security, too!
PCI DSS 4.1
PCI DSS 4.1 says, “Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks…”
Given the large number of vulnerabilities associated with SSL, the impending revision to the PCI standard will no longer permit the use of SSL. In fact, organizations that are still using SSL are exposing themselves and should move to TLS 1.1 or higher as soon as possible. Yet, using SSL is acceptable for PCI compliance purposes today. Another point to note: even with the pending release of the revised PCI guidance, there is a lag time between when the requirement is published and when organizations must be compliant. This window represents a security exposure, even though the organization may be technically compliant with the requirements of the standard.
PCI DSS 6.2
PCI DSS 6.2 says, “6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.”
For argument’s sake, let’s define a critical vulnerability as something that poses an enormous risk to the organization. Although the PCI standard says security patches for a critical vulnerability must be patched within 30 days, that could be an inordinately long time to wait if the vulnerability is actively being exploited or if it caused a system outage. Even waiting 2-3 months to patch lower-risk issues could result in prolonged exposure to attack. Yes, you may be compliant, but you probably aren’t secure as you could be if you just follow the standard.
An example of a more secure patching policy might be something like this:
- For a critical issue that involves an outage or active exploitation, patch immediately and work until fixed (7x24) - finish when the outage or exploitation is stopped
- For a critical issue that does not involve an outage or ongoing exploitation, patch immediately and work until fixed – during normal working hours
- For high-risk issues, patch within 2 weeks
- For medium risk issues, patch within one month
- For low risk issues, patch within the next quarter
Reducing attack surface not only means reducing the number and severity of the issues, but also reduces the exposure time. This is an example of a more robust security posture than provided by the compliance guidance.
PCI DSS 6.6
PCI DSS 6.6 says, “For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
- Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes…
- Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.”
The standard gives you a choice of conducting web application vulnerability assessments OR installing an automated solution such as a web application firewall (WAF) in front of public-facing websites. It certainly is understandable that the standard gives you a choice, but in order to be secure, I’d recommend doing both. Here’s why: it’s good defense in depth.
- Application vulnerability assessments look for vulnerabilities that are likely to be exploited by attackers. If you find and fix the issues, you’ve reduced the attack surface and made it harder to conduct a successful attack.
- An automated tool like a WAF can detect and block known attacks in real-time. The application may still be vulnerable, but at least if the WAF knows how to stop the attack, the application is protected. But a WAF is hard to tune and can’t detect all attacks.
As with most things, there are pro’s and con’s to each of these. The point is that each approach provides protection from a different perspective, and using both approaches provides better security than if using one OR the other. You’ll be compliant implementing one of the solutions, but your security will be better if you do both.
Additionally, the standard gives you the option to do an automated OR a manual application vulnerability assessment. Both approaches cover different areas of the vulnerability space.
- Automated tests are great at finding the “low-hanging fruit” or attacks that require lots of automation and would otherwise be too tedious to do by manually
- Manual assessments are useful for conducting complex attacks and for doing business logic attacks (something that automated testing tends to be weak at)
Doing both automated and manual testing provides increased security coverage. With each solution individually, you may be compliant, but probably not as secure if you did both.
Furthermore, the assessment must minimally look for vulnerabilities listed in requirement 6.5 (most of the OWASP Top 10 + buffer overflows, improper error handling, and all high risk vulnerabilities identified during the vulnerability identification process outlined in requirement 6.1). If you look for those vulnerabilities, you will be compliant with the standard, but you may not be secure. There are many more security vulnerabilities than just the minimal list. For increased security, be sure to look for more than just the minimum list of vulnerabilities as outlined by the standard. Attackers won’t be looking just for the minimum list.
Conclusion
Compliance guidance is a great way to implement prescriptive security solutions that are known to work. But it can be a mistake to think that JUST being compliant means you are necessarily secure. Although being compliant means that you are implementing the requirements of the compliance guidance, you still may have security vulnerabilities that the compliance guidance may not explicitly consider. Compliance standards don’t necessarily change as fast as the security threats. There is usually a grace period before the compliance guidance mandates a new or changed requirement. But that grace period is a window of opportunity for the attackers if those issues have not been secured. Instead, have security drive your compliance efforts. Good security means, among other things, being nimble and able to rapidly respond to changing threats. Compliance standards can’t do that, so organizations need to take it one step further and contextualize the recommended actives in the standard itself (which are good) to reduce most of the risk. Having a strong security posture can help you achieve your compliance requirements while being “secure”.
