Have you ever wondered why Availability is included in the Confidentially, Integrity and Availability model? I did… and wrote this blog to express my thoughts.
Wikipedia definition “Information Security is concerned with the confidentiality, integrity and availability of data regardless of the form the data may take: electronic, print, or other forms.”
Hmmm, okay. But why should I, as a security professional, be worried about the availability of the data? The way I see it, if the information is unavailable… then that is better. I believe the Payment Card Industry (PCI) standard was the first regulation to catch on to this. If you read the standard it doesn’t mention the availability, back up or recovery of data, and being a Qualified Security Assessor (QSA), I understand the PCI Council has good reasons why.
As a security professional I understand that the evolution of security. Back in the day… security meant having a firewall and making sure that network was available. However, today security has a completely different role within organization. The ability for the information to be available falls under the jurisdiction of the Chief Information Officer.
I have authored hundreds of security documents that if/when implemented would “break” the functionality of the application, system or process. However, if these controls are not implemented the application, system or process is left vulnerable to attack. Being concerned with availability, you, as the security professional cannot push the implementation of the control. As such, you have accepted the vulnerability.
Why is this important? Many organizations are unable to position Security in the right structure, meaning that security still falls under the CIO. While this can work, there are too many points of failure for security to be embraced within the organization. So, as long as security professionals continue to position themselves with the responsibility of ensuring availability of information, the ability to truly secure the data will be jeopardized.
Read more!
Thursday, July 17, 2008
Tuesday, July 15, 2008
PCI DSS and Penetration Testing
At times it can be frustrating when the PCI DSS lacks clarity on certain requirements, though it is generally very prescriptive in nature. It creates problems for both the QSA and the client who can and will disagree with interpretation. This is especially true when it comes to penetration testing. The requirement states:
11.3 Perform penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following - network layer and application layer.
Now the first concern is that other requirements of the PCI DSS, such as 11.2 for vulnerability scanning, clearly distinguish where it should be performed (internal and external networks). Now generally, penetration tests are done externally. But the standard, when not specific, is supposed to have an understood "... as it applies to PCI data" in each requirement. So perhaps the penetration test should be on the PCI network. But from a risk perspective, wouldn't it be best to determine how might someone break in from the internal corporate network to the PCI network? As a QSA, I think any of them have to be acceptable.
Another concern lies in what a penetration test is. Other than the layers noted, it isn't really clear. Even there, I think it would be best to clarify the routing network versus the network operating system vs the operating system itself. All of these are distinct types of assets to attack. And as for the application layer, there isn't the same level of distinguishing between general applications and web applications, which are handled very differently within a pentest. Beyond these immediate symantics, there are many more nuances to what a pentest is that simply isn't defined or even referenced to some other body like OWASP for web application security.
But what bothers me the most about this requirement, is the lack of dictating who can perform a penetration test. PCI has done a great job establishing the ASV program to certify who can do a vulnerability scan. You'd think, at a minimum, that only ASV's could do them given that penetration tests are sort of the PhD to the associates degree of vulnerability scanning. But to the previous point, there are a lot of people who can do scans. Very few are actually good at penetration testing. So the real goal should be to make an even higher standard and program for pentests.
With all that said, I am still a big fan of the PCI DSS. It really does outline a pretty darn good formula for a good, effective security program. And with each rewrite, the DSS does tend to improve and provide clarity. For example, when requirement 6.6 was added for web application review or web application firewall, they did clearly state that an organization that specializes in those types of assessments should be used. Could they at least say that for the penetration tests?
Read more!
11.3 Perform penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following - network layer and application layer.
Now the first concern is that other requirements of the PCI DSS, such as 11.2 for vulnerability scanning, clearly distinguish where it should be performed (internal and external networks). Now generally, penetration tests are done externally. But the standard, when not specific, is supposed to have an understood "... as it applies to PCI data" in each requirement. So perhaps the penetration test should be on the PCI network. But from a risk perspective, wouldn't it be best to determine how might someone break in from the internal corporate network to the PCI network? As a QSA, I think any of them have to be acceptable.
Another concern lies in what a penetration test is. Other than the layers noted, it isn't really clear. Even there, I think it would be best to clarify the routing network versus the network operating system vs the operating system itself. All of these are distinct types of assets to attack. And as for the application layer, there isn't the same level of distinguishing between general applications and web applications, which are handled very differently within a pentest. Beyond these immediate symantics, there are many more nuances to what a pentest is that simply isn't defined or even referenced to some other body like OWASP for web application security.
But what bothers me the most about this requirement, is the lack of dictating who can perform a penetration test. PCI has done a great job establishing the ASV program to certify who can do a vulnerability scan. You'd think, at a minimum, that only ASV's could do them given that penetration tests are sort of the PhD to the associates degree of vulnerability scanning. But to the previous point, there are a lot of people who can do scans. Very few are actually good at penetration testing. So the real goal should be to make an even higher standard and program for pentests.
With all that said, I am still a big fan of the PCI DSS. It really does outline a pretty darn good formula for a good, effective security program. And with each rewrite, the DSS does tend to improve and provide clarity. For example, when requirement 6.6 was added for web application review or web application firewall, they did clearly state that an organization that specializes in those types of assessments should be used. Could they at least say that for the penetration tests?
Read more!
Subscribe to:
Posts (Atom)
Posts
