Compliance != Security

Thursday, June 17, 2010

Gaurav Kumar

E9a8f256f4904b06246375df06a8864b

Original blog post can be found here.

In this post I am going to express my disappointment with a disturbing trend - more focus is being given to compliance than security. I don't have anything personal against compliance, in fact, in my last job, I was IT Audit Manager and performed compliance related audits. While compliance is necessary and important, it is not sufficient from security perspective. One can be in compliance and still be vulnerable to easy attacks. Below are few examples-

1. PCI

We all know Heartland credit card breach was one of most significant credit card data breaches ever reported. According to this Q&A, their CEO commented "we certainly didn't understand the limitations of PCI and the entire assessment process. PCI compliance doesn't mean secure. We and others were declared PCI compliant shortly before the intrusion"

Not trying to nitpick PCI here, but there are 2 requirements in PCI which I always find interesting to talk about. These are:

Requirement 6.6

One of the most contentious PCI requirements. It requires that one should either a WAF or perform independent security assessment. According to PCI, below are "recommend" WAF (web application firewall) capabilities

 

Obviously, "recommended" is interesting keyword here. Why not change it to "mandatory"?

Last year in July 2009, this whitepaper presented evaluation of several WAFs. I've summarized "% of attacks blocked" of these WAFs as evaluated in whitepaper (please read the whitepaper for criteria used for evaluation)

WAF

% of attacks

blocked

phionairlock

36.92 %

Hyperguard

35.38 %

F5 BIG-IP

67.69 %

ModSecurity

52.31 %

The point I am trying to make is not that WAFs are worse than independent assessment (independent assessment could be worse also), the point is even if one is running WAF to get PCI compliant, there might be many vulnerabilities which won't be blocked by WAF.

Requirements 8.5.13 and 8.5.14

As per PCI, the requirements are:

8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts.

8.5.14 Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID

And now have a look at this post I made some time back. Got it?

Locking user accounts isn't a good idea- an attacker can write an automated script which will send six invalid credentials every 30 minutes thereby creating persistent account lockout, effectively, creating DoS on affected users. In case the usernames are predictable (e.g. some telecom web apps use phone numbers as login id), the impact of such "vulnerability" is more as one can effectively make large (or may be all) users locked out.

I don't know why PCI isn't recommending/requiring use of Captcha's instead of account lock out.

In short, one may be PCI compliant and yet vulnerable to simple DoS attack (by virtue of being compliant)

2. HITEC

HITEC provides exemption to notification requirements. In short, if PHI (Patient Health Information) data is encrypted and a breach is detected, there is no need to notify (the customers). For more info, read this

I disagree. Notification must be required even if data is encrypted. Even though HITEC requires you to follow NIST "approved" encryption algorithms, what is secure encryption today may not remain secure tomorrow. For example, DES 64 (58+8 parity bits) isn't considered secure anymore. What if AES gets broken in near future? What if it has already been? (yes, sort of extreme view, but  possible) Suddenly, all of the encrypted data will become exposed.

3. SAS 70

I think this post has really documented the problem of SAS70 being considered like a security certification very well.

One more example-

I was on a client location performing infrastructure security review. The  infrastructure/processes were ISO 27001 compliant. I came across this IDS (Intrusion Detection System) which was placed before web server and after the firewall. The network was configured in a way that only SSL (port 443) connections were allowed to be made to this web server. The SSL was terminated at web server itself. I immediately raised concern- is this IDS configured to inspect SSL connections? (several IDS now have this capability which allows you to import SSL certificate so that IDS can decrypt and inspect encrypted traffic) The answer was "No!" - Client was also astonished that he wasn't aware of such scenarios even though he is fully ISO 27001 compliant.

As a closing comment, I would like to say that while compliance is important, what is more important that it shouldn't be considered "the" security control. I would also like to quote a fellow CISSP -

managers and  executives can easily be misled by the ‘false advertising' associated with the supporters of these 'standards'

I would love to hear your comments/feedback.

Possibly Related Articles:
4048
HIPAA PCI DSS Webappsec->General
Compliance Web Application Firewalls
Post Rating I Like this!
29caf2d9c852c6936e9d8b256513d0bf
Lance Miller Amen.
1276787541
C643eec6350152c6c3fbd1288578d98a
Terry Perkins Ditto, Lance. Hallelujah!
1276791594
Default-avatar
Taz Wake Excellent article. Thanks.
1276881369
Default-avatar
Rob Lewis Good points. It will be interesting to see if the fact that a few states are moving towards a passed audit as being safe harbour for a whole year, will force the standards people to move the yardsticks towards more security.

1276883547
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.