As version 3.3 stable comes near, H.D. Moore and the crew from the Metasploit team has released a couple of great new features with the 3.3 dev version. Most notably last night was the commit for the latest SMBv2 remote code execution vulnerability that specifically targets Windows Vista and Windows 2008 and is still currently unpatched!!
The second awesome looking feature is the capability to take screenshots of an already compromised system through metasploit. When delivering the meterpreter payload you simply migrate to explorer.exe and type in screenshot /yourdir/screenshot.bmp, after that the victims machine will then be captured. Just another reason why the meterpreter console is one of the best post-exploitation swiss army knife out there.
Stay tuned for more Metasploit additions!
Read more!
Monday, September 28, 2009
Monday, September 21, 2009
Using SWOT to Evaluate Your Security Posture
Because the value of security is based on what is prevented, or doesn’t happen, it can be difficult to quantify. One simple way to evaluate your security needs can be with a SWOT analysis modified for security. Almost all of us are familiar with the SWOT analysis- it is business 101. For those who are not, it as an analysis of Strengths, Weaknesses, Opportunities, and Threats. When you are trying to get buy in and the resulting budget for security initiatives, the SWOT analysis lets you speak in the language that executives understand.
The exercise is most effective when combined with the systems approach. Without getting into the details, basically you need to clearly define the security objectives before completing the SWOT analysis.
Objectives can be anything from supporting the organization’s financial goals to protecting client information. If you can put dollar amounts to the categories, you are a step ahead.
Strengths
It is helpful to start with the good. What are the organizations security strengths? For smaller organizations, a strength may be the very fact that they are small, and thus fairly easy to secure. Maybe the organization already has a “security culture” with security embedded. Often, an organization’s strengths present an easy opportunity to increase security. By building on or positively modifying existing controls, security can usually be increased.
Weaknesses
Weakness can be broad or specific. A general lack of a security program or culture is a weakness, but is not defined enough to guide action. Look for specific areas. For example, not having a patch management program in place is a definite weakness. But organizations lacking a robust patch management process have a great opportunity to increase security. We see organizations fall prey to vulnerabilities that would not have been able to be exploited if they had a proper patch management program. Implementing a patch management program may involve spending some money, but it is a small price compared to remediating damage caused by an exploited vulnerability.
Many weaknesses are highly technical in nature. Lack of logging or change management are weaknesses that likely will take significant effort to fix. Articulating the weakness presented by not having systems like this in place and the strengths from implementing them is important to get management to approve the effort. Once again, putting dollar amounts on the costs of a successful exploitation of a vulnerability is paramount.
Another weakness that is especially common in today’s economy is a lack of funds. It can be tough to get buy in for initiatives without ample funding, but for organizations with cash flow problems, the expenses resulting from a security breach may be enough to put them out of business for good. That is a point that if properly articulated, should sway even the most security adverse executive.
Opportunities
Opportunities are generally fairly distinct. Does the organization have funds for security allocated, but not spent? Are logging systems in place, but not used? Do robust security policies exist, but have never been distributed? Think of driving around without buckling the seatbelt. Simply buckling your seatbelt costs nothing, doesn’t take much effort, and instantly and vastly improves safety. Opportunities are low hanging fruit that you can’t afford not to take advantage of. The best part is that taking advantage of most opportunities doesn’t require management approval or any significant spending.
Threats
Many threats, especially from a security perspective, are fairly easy to delineate. If the organization is subject regulations such as PCI DSS, HIPAA or SOX, the cost of non compliance can be astronomical. The costs of reputational damage often far outweigh the fines for non compliance. And the fines for non compliance are stiff.
How do I get started?
A good template in MS Word format for a SWOT analysis can be found here: http://www.zeltser.com/sans/isc/swot-matrix-template.doc
The best place to start is with an assessment. Many times organizations have trouble assessing their own security because they are too close to it, or lack the time or expertise. An experienced outside assessor will have seen countless situations and levels of security, and will be able to help with all four areas of the SWOT analysis.
If an assessment is not possible, a brainstorming session can be good for getting most of the fields started. The more people you can involve in the brainstorming sessions the better, and be sure to include front line employees if possible. They are often aware of the issues that exist in an organization, but lack the proper channels of communication to get to executives.
This is definitely an exercise worth your time and effort. The sooner you get started, the sooner you can approach executive management and get started on increasing security.
Read more!
The exercise is most effective when combined with the systems approach. Without getting into the details, basically you need to clearly define the security objectives before completing the SWOT analysis.
Objectives can be anything from supporting the organization’s financial goals to protecting client information. If you can put dollar amounts to the categories, you are a step ahead.
Strengths
It is helpful to start with the good. What are the organizations security strengths? For smaller organizations, a strength may be the very fact that they are small, and thus fairly easy to secure. Maybe the organization already has a “security culture” with security embedded. Often, an organization’s strengths present an easy opportunity to increase security. By building on or positively modifying existing controls, security can usually be increased.
Weaknesses
Weakness can be broad or specific. A general lack of a security program or culture is a weakness, but is not defined enough to guide action. Look for specific areas. For example, not having a patch management program in place is a definite weakness. But organizations lacking a robust patch management process have a great opportunity to increase security. We see organizations fall prey to vulnerabilities that would not have been able to be exploited if they had a proper patch management program. Implementing a patch management program may involve spending some money, but it is a small price compared to remediating damage caused by an exploited vulnerability.
Many weaknesses are highly technical in nature. Lack of logging or change management are weaknesses that likely will take significant effort to fix. Articulating the weakness presented by not having systems like this in place and the strengths from implementing them is important to get management to approve the effort. Once again, putting dollar amounts on the costs of a successful exploitation of a vulnerability is paramount.
Another weakness that is especially common in today’s economy is a lack of funds. It can be tough to get buy in for initiatives without ample funding, but for organizations with cash flow problems, the expenses resulting from a security breach may be enough to put them out of business for good. That is a point that if properly articulated, should sway even the most security adverse executive.
Opportunities
Opportunities are generally fairly distinct. Does the organization have funds for security allocated, but not spent? Are logging systems in place, but not used? Do robust security policies exist, but have never been distributed? Think of driving around without buckling the seatbelt. Simply buckling your seatbelt costs nothing, doesn’t take much effort, and instantly and vastly improves safety. Opportunities are low hanging fruit that you can’t afford not to take advantage of. The best part is that taking advantage of most opportunities doesn’t require management approval or any significant spending.
Threats
Many threats, especially from a security perspective, are fairly easy to delineate. If the organization is subject regulations such as PCI DSS, HIPAA or SOX, the cost of non compliance can be astronomical. The costs of reputational damage often far outweigh the fines for non compliance. And the fines for non compliance are stiff.
How do I get started?
A good template in MS Word format for a SWOT analysis can be found here: http://www.zeltser.com/sans/isc/swot-matrix-template.doc
The best place to start is with an assessment. Many times organizations have trouble assessing their own security because they are too close to it, or lack the time or expertise. An experienced outside assessor will have seen countless situations and levels of security, and will be able to help with all four areas of the SWOT analysis.
If an assessment is not possible, a brainstorming session can be good for getting most of the fields started. The more people you can involve in the brainstorming sessions the better, and be sure to include front line employees if possible. They are often aware of the issues that exist in an organization, but lack the proper channels of communication to get to executives.
This is definitely an exercise worth your time and effort. The sooner you get started, the sooner you can approach executive management and get started on increasing security.
Read more!
Thursday, September 17, 2009
Information Security's Silver Bullet: There Isn't One
Back on June 27, 2008 ComputerWorld published an article "Web firewalls trumping other options as PCI deadline nears" just before the well known June 30, 2008 PCI 6.6 deadline. In February of 2008, the PCI Council published clarification on the PCI DSS section 6.6 and what the intent of it was. Over a year later, I frequently encounter Web applications that are far from compliant and this is no surprise. What is (sort of) surprising, is the false sense of security people have with PCI after completing their self-assessment questionnaire (SAQ) and dropping in a Web application firewall (WAF) thinking they are secure that is still ubiquitous.
Year after year I interface with individuals that think there is a single silver bullet to solve their information security concerns. Have they been misled somewhere in the past? Are they simply uninformed about security and the attacks out there? In a past web application review, my user ID was passed through the URL (example: http://www.website.com/index.php?uid=swhite) and I trivially changed it in my browser to "admin". This in turn allowed me to view over 11,500 files containing sensitive information on customers. A Web application firewall more often than not would not have caught this more than likely valid request, and allowed for identity theft with the information I was able to obtain.
ComputerWorld's article makes me nod my head, but at the same time, question the expertise of who is writing it. For example, they mention that web application firewalls can protect against things such as sql injection, buffer overflows, and cross-site scripting. The OWASP Top 10 list (2007 and 2004) doesn't mention buffer overflows and the PCI DSS section 6.6 specifically calls out Web applications. Buffer overflows in Web applications themselves are very unlikely to be exploited outside the capacity of a denial of service attack, but would more likely target a web server or other service running. As one who hosts web applications, I would worry about injection flaws and XSS before buffer overflows. I'm not sure why the author of the article included buffer overflows other than it is a buzzword for some people that makes them think security.
As a security professional, I commonly have to describe very technical issues in "normal people" terms. For information security, a field that has very techical aspects, non-technical individuals should understand that there is no single silver bullet to solve your security issues. Just as throwing up a WAF in front of your Web application that handles PCI data isn't the best (not necessarily least expensive) approach to complying with PCI DSS 6.6, that seemingly simply and one-time solutions to write off security concerns are not in accordance with industry best practices.
Defense in depth should be employed so that your resources are protected when preventative measures may fail, to ensure that you are protected from zero-day to patch day or until the controls are operating properly again. If at the end of the day, you learn one thing, let it be that there is no single solution to information security, or everyone would be doing it and the solution would be spreading like wildfire.
Read more!
Year after year I interface with individuals that think there is a single silver bullet to solve their information security concerns. Have they been misled somewhere in the past? Are they simply uninformed about security and the attacks out there? In a past web application review, my user ID was passed through the URL (example: http://www.website.com/index.php?uid=swhite) and I trivially changed it in my browser to "admin". This in turn allowed me to view over 11,500 files containing sensitive information on customers. A Web application firewall more often than not would not have caught this more than likely valid request, and allowed for identity theft with the information I was able to obtain.
ComputerWorld's article makes me nod my head, but at the same time, question the expertise of who is writing it. For example, they mention that web application firewalls can protect against things such as sql injection, buffer overflows, and cross-site scripting. The OWASP Top 10 list (2007 and 2004) doesn't mention buffer overflows and the PCI DSS section 6.6 specifically calls out Web applications. Buffer overflows in Web applications themselves are very unlikely to be exploited outside the capacity of a denial of service attack, but would more likely target a web server or other service running. As one who hosts web applications, I would worry about injection flaws and XSS before buffer overflows. I'm not sure why the author of the article included buffer overflows other than it is a buzzword for some people that makes them think security.
As a security professional, I commonly have to describe very technical issues in "normal people" terms. For information security, a field that has very techical aspects, non-technical individuals should understand that there is no single silver bullet to solve your security issues. Just as throwing up a WAF in front of your Web application that handles PCI data isn't the best (not necessarily least expensive) approach to complying with PCI DSS 6.6, that seemingly simply and one-time solutions to write off security concerns are not in accordance with industry best practices.
Defense in depth should be employed so that your resources are protected when preventative measures may fail, to ensure that you are protected from zero-day to patch day or until the controls are operating properly again. If at the end of the day, you learn one thing, let it be that there is no single solution to information security, or everyone would be doing it and the solution would be spreading like wildfire.
Read more!
Quick Trac Backup and Upgrade Script
Trac is an open source, web-based project management and bug-tracking tool. The program is inspired by CVSTrac, and was originally named svntrac due to its ability to interface with Subversion. It is developed and maintained by Edgewall Software.
When using trac, its often that you will have to upgrade to different versions, create backups and everything else. I just wrote a quick little script to do it all for you. Enjoy.
#!/usr/bin/python
import subprocess
from time import time
# TRAC LOCATION HERE
trac=("/var/local/trac/trac.website.com/")
# BACKUP DIR HERE
backup=("/home/yourname/tracbackups/")
# set time for directory
timesave=time()
print "Upgrading Trac..."
# Easy Install Trac just in case (wont erase anything)
subprocess.Popen("sudo easy_install Trac", shell=True).wait()
# STOP APACHE
subprocess.Popen("/etc/init.d/apache2 stop", shell=True).wait()
# BACKUP TRAC
subprocess.Popen("trac-admin %s hotcopy %s%s" % (trac,backup,timesave), shell=True).wait()
# UPGRADE TRAC
subprocess.Popen("easy_install --upgrade Trac", shell=True).wait()
# START APACHE
subprocess.Popen("/etc/init.d/apache2 start", shell=True).wait()
print "Finished upgrading Trac..."
Read more!
When using trac, its often that you will have to upgrade to different versions, create backups and everything else. I just wrote a quick little script to do it all for you. Enjoy.
#!/usr/bin/python
import subprocess
from time import time
# TRAC LOCATION HERE
trac=("/var/local/trac/trac.website.com/")
# BACKUP DIR HERE
backup=("/home/yourname/tracbackups/")
# set time for directory
timesave=time()
print "Upgrading Trac..."
# Easy Install Trac just in case (wont erase anything)
subprocess.Popen("sudo easy_install Trac", shell=True).wait()
# STOP APACHE
subprocess.Popen("/etc/init.d/apache2 stop", shell=True).wait()
# BACKUP TRAC
subprocess.Popen("trac-admin %s hotcopy %s%s" % (trac,backup,timesave), shell=True).wait()
# UPGRADE TRAC
subprocess.Popen("easy_install --upgrade Trac", shell=True).wait()
# START APACHE
subprocess.Popen("/etc/init.d/apache2 start", shell=True).wait()
print "Finished upgrading Trac..."
Read more!
Tuesday, September 15, 2009
Data Analytics to Detect Fraud
Some say that detecting fraud is fraud is like finding needle in a haystack. Often times this is true, but more often you don’t even know what the needle looks like or what haystack to look in. To overcome these obstacles data mining techniques can be used. One of the ways that is very powerful is data visualization. Using this technique you can “see” the anomalies much easier than just staring a list of numbers.
One of the earliest, but still powerful analytic like this is called “Benford’s Law” – also called “Digital Analysis”. The basic premise of this law is that certain leading digits in any random set of data will appear in a specific non-uniform manner or in a certain frequency. Anything that is outside that frequency indicates a non-compliant anomaly. For example, if an employee has a limit of approval of $5000, you might see a spike in the first two digits of “48” or “49” that is beyond what Benford’s law says it should be.
There are some great tools out there that can let you apply this to your data – including MS Excel (click here).
Read more!
One of the earliest, but still powerful analytic like this is called “Benford’s Law” – also called “Digital Analysis”. The basic premise of this law is that certain leading digits in any random set of data will appear in a specific non-uniform manner or in a certain frequency. Anything that is outside that frequency indicates a non-compliant anomaly. For example, if an employee has a limit of approval of $5000, you might see a spike in the first two digits of “48” or “49” that is beyond what Benford’s law says it should be.
There are some great tools out there that can let you apply this to your data – including MS Excel (click here).
Read more!
Sunday, August 30, 2009
WPA Flawed, Not Broken.
Reading the headlines the past few days on Slashdot, and other sites, you would think the world was ending. WPA IS BROKEN JUST LIKE WEP are a few of the headlines I've seen.
You can also see a SlashDot article (http://hardware.slashdot.org/story/09/08/27/180249/WPA-Encryption-Cracked-In-60-Seconds?from=rss) reading "WPA Encryption Cracked in Under 60 Seconds!".
From these articles you would believe that WPA is SERIOUSLY flawed allowing an attacker to CRACK the encryption and ultimately read your sensitive data, get your TKIP key, and own everything on your wireless network. Unfortunately, this is one whopper of media hype. A great article REALLY explaining the vulnerability can be found here: http://wifinetnews.com/.
Ultimately no keys are cracked, no encryption is "broken", and your ultimately a little less safe then you use to be with TKIP. The vulnerability was actually introduced last year and just improved on by the Japanese researchers.
There are some serious implications with the improved attack though, most notably if you are fairly close to the client, have a directional antenna, and can intercept some traffic, you can potentially ARP cache poison the victim and have all traffic go through the attacker first. This has a wide spectrum of exposures from sniffing traffic to having a fake DNS server and serving up bad pages.
A couple other mentions are that this only affects TKIP because of the backwards compatibility with IV's and WEP, this does not affect AES. The TKIP key is NOT recovered, it is simply the MIC checksum for message integrity. Since this is only for short packets with known data, there are only a select avenue for attack (i.e. ARP).
Ultimately, this is still a vulnerability that can have some serious repercussions, it is not the doomsday message that everyone seems to be portraying.
Read more!
You can also see a SlashDot article (http://hardware.slashdot.org/story/09/08/27/180249/WPA-Encryption-Cracked-In-60-Seconds?from=rss) reading "WPA Encryption Cracked in Under 60 Seconds!".
From these articles you would believe that WPA is SERIOUSLY flawed allowing an attacker to CRACK the encryption and ultimately read your sensitive data, get your TKIP key, and own everything on your wireless network. Unfortunately, this is one whopper of media hype. A great article REALLY explaining the vulnerability can be found here: http://wifinetnews.com/.
Ultimately no keys are cracked, no encryption is "broken", and your ultimately a little less safe then you use to be with TKIP. The vulnerability was actually introduced last year and just improved on by the Japanese researchers.
There are some serious implications with the improved attack though, most notably if you are fairly close to the client, have a directional antenna, and can intercept some traffic, you can potentially ARP cache poison the victim and have all traffic go through the attacker first. This has a wide spectrum of exposures from sniffing traffic to having a fake DNS server and serving up bad pages.
A couple other mentions are that this only affects TKIP because of the backwards compatibility with IV's and WEP, this does not affect AES. The TKIP key is NOT recovered, it is simply the MIC checksum for message integrity. Since this is only for short packets with known data, there are only a select avenue for attack (i.e. ARP).
Ultimately, this is still a vulnerability that can have some serious repercussions, it is not the doomsday message that everyone seems to be portraying.
Read more!
Monday, August 17, 2009
Passing the PCI Buck
If you've been following any of the recent PCI (Payment Card Industry) breaches, you'll see two trends coming from the breached organization. One one hand, they'll say that the PCI standard is flawed since it they were compliant and still got hacked. On the other hand, they'll say the problem was their QSA (Qualified Security Assessor) messed up. Although both the standard could be better and a QSA can be more thorough, it's time for organizations to stop passing the buck and admit that they screwed up.
Now I understand that there are certainly differences of quality in each QSA. I've seen everything from rubberstamped reports that make you wonder if the QSA can spell 'PCI' to a tinfoil hat QSA who uses the standard to create new, crazy requirements. But in the end, I sometimes wonder if the organizations understand truly what makes a good QSA and what their role is. Ultimately, the QSA is supposed to be an auditor (yes, I know technically we are 'assessors'). That means the QSA is trying to make sure the processes the organization established are working properly. In order to do that, the QSA needs to typically sample the controls and do some digging around. This should allow the QSA to determine that the control is generally operating correctly. However, the QSA is NOT the master of the organization's destiny for security. Heck, the audit is only once a year and cannot turn over every stone. The organization owns and is responsible for the processes, the controls, monitoring, and reacting. If they break down, that is the organization's problem.
Now as far as the standard goes, I hear a lot of people (generally non-QSA) stating that the PCI DSS is flawed. First of all, let's just understand that this was written to push compliance, not security, to a certain level since it was severely lacking in most organizations. Just to be clear, compliance is just a hurdle and not a ceiling. What I don't understand is then what other framework or compliance is better than PCI? For example, ISO 27001 is still too general and based on business decisions. The standard is still the most thorough, prescriptive, and layered one out there. This is not only for the controls within it but also the testing. For example, testing applies both externally and internally and escalates from scans, to pentests, and even web app reviews. For all the naysayers out there, I'd love to see a better version from them. Remember, PCI was the first and still the onyl one out there that has pushed hard for web application security such as the OWASP Top 10. Now for those who think the standard isn't detailed enough, give me a break. It isn't going to tell you exactly how to do X with product Y in a Z architecture. There are just too many variables.
So let's look at the latest details on the big breaches (http://www.wired.com/threatlevel/2009/08/tjx-hacker-charged-with-heartland/ ). Now we are finally starting to get enough details to understand what happened. Let's go with the assumption that the downfall to Heartland/Hannaford was SQL injection and see where the problem hypothetically is. Well the standard clearly states that it needs to be properly coded in requirements 6.5.2. Keep in mind that a QSA will not and may not even be able to review all your code. Oh yeah, that is the organization's requirement in 6.3.7. This also needs further tested through a web application review (possible third party problem) or prevented through a web application firewall (organization's problem) in 6.6. Not to mention that this would or should be detected during the vulnerability scanning (ASV problem) and penetration testing (probably third party problem) from requirements 11.2 and 11.3. So how exactly did the standard fail here when there are at so many layers of controls and testing designed to stop this?
This brings me back to yet another ranting point. It is unbelievable the number of organizations who are constantly trying to find the absolute cheapest vendor for any of the stuff we just discussed including the QSA, the ASV, and other testing. There is little going into understanding the quality or qualifications of the vendors being selected by the organization. This absolutely leads to 'getting what you pay' for quite a bit. But just remember, that is a choice of the organization to pick a deficient vendor.
We also need to realize that even if SQL injection had worked, there were still plenty of other controls within PCI that could have stopped the breach. First of all, there is a anti-malware requirement. Yes, I know that only recently was it clearly required for all platforms, not just those 'commonly affected'. But we have seen Linux malware and it's supported by all commercial anti-virus vendors and even free ones. So did the organization just not do it because it wasn't clearly dictated as a hurdle within the standard? I guess so. There is also a requirement to restrict firewall traffic both inbound AND outbound. So why was the malware allowed to talk to the internet from payment systems? There is no good business reason there. So the standard certainly isn't as flawed as people want to assert, though there it could be improved.
In the end, we certainly can conclude a few things. First of all, despite the fact that these organizations had been assessed as compliant, the organizations clearly were not compliant. Though it is possible that a QSA missed something, that is still the organization's problem. Also, the standard cannot be perfect but it is very well built and, if followed, would have stopped these. In security, like any process, it may only take one flaw for a breach to occur - even if that was the standard or the QSA. But that's why security has to be layered and has to be based on quality, not compliance. Regardless, the whole security process is owned by the organization and they need to take responsibility when it breaks. Passing the buck doesn't undo the breach, but does make for some interesting blamestorming to watch.
Read more!
Now I understand that there are certainly differences of quality in each QSA. I've seen everything from rubberstamped reports that make you wonder if the QSA can spell 'PCI' to a tinfoil hat QSA who uses the standard to create new, crazy requirements. But in the end, I sometimes wonder if the organizations understand truly what makes a good QSA and what their role is. Ultimately, the QSA is supposed to be an auditor (yes, I know technically we are 'assessors'). That means the QSA is trying to make sure the processes the organization established are working properly. In order to do that, the QSA needs to typically sample the controls and do some digging around. This should allow the QSA to determine that the control is generally operating correctly. However, the QSA is NOT the master of the organization's destiny for security. Heck, the audit is only once a year and cannot turn over every stone. The organization owns and is responsible for the processes, the controls, monitoring, and reacting. If they break down, that is the organization's problem.
Now as far as the standard goes, I hear a lot of people (generally non-QSA) stating that the PCI DSS is flawed. First of all, let's just understand that this was written to push compliance, not security, to a certain level since it was severely lacking in most organizations. Just to be clear, compliance is just a hurdle and not a ceiling. What I don't understand is then what other framework or compliance is better than PCI? For example, ISO 27001 is still too general and based on business decisions. The standard is still the most thorough, prescriptive, and layered one out there. This is not only for the controls within it but also the testing. For example, testing applies both externally and internally and escalates from scans, to pentests, and even web app reviews. For all the naysayers out there, I'd love to see a better version from them. Remember, PCI was the first and still the onyl one out there that has pushed hard for web application security such as the OWASP Top 10. Now for those who think the standard isn't detailed enough, give me a break. It isn't going to tell you exactly how to do X with product Y in a Z architecture. There are just too many variables.
So let's look at the latest details on the big breaches (http://www.wired.com/threatlevel/2009/08/tjx-hacker-charged-with-heartland/ ). Now we are finally starting to get enough details to understand what happened. Let's go with the assumption that the downfall to Heartland/Hannaford was SQL injection and see where the problem hypothetically is. Well the standard clearly states that it needs to be properly coded in requirements 6.5.2. Keep in mind that a QSA will not and may not even be able to review all your code. Oh yeah, that is the organization's requirement in 6.3.7. This also needs further tested through a web application review (possible third party problem) or prevented through a web application firewall (organization's problem) in 6.6. Not to mention that this would or should be detected during the vulnerability scanning (ASV problem) and penetration testing (probably third party problem) from requirements 11.2 and 11.3. So how exactly did the standard fail here when there are at so many layers of controls and testing designed to stop this?
This brings me back to yet another ranting point. It is unbelievable the number of organizations who are constantly trying to find the absolute cheapest vendor for any of the stuff we just discussed including the QSA, the ASV, and other testing. There is little going into understanding the quality or qualifications of the vendors being selected by the organization. This absolutely leads to 'getting what you pay' for quite a bit. But just remember, that is a choice of the organization to pick a deficient vendor.
We also need to realize that even if SQL injection had worked, there were still plenty of other controls within PCI that could have stopped the breach. First of all, there is a anti-malware requirement. Yes, I know that only recently was it clearly required for all platforms, not just those 'commonly affected'. But we have seen Linux malware and it's supported by all commercial anti-virus vendors and even free ones. So did the organization just not do it because it wasn't clearly dictated as a hurdle within the standard? I guess so. There is also a requirement to restrict firewall traffic both inbound AND outbound. So why was the malware allowed to talk to the internet from payment systems? There is no good business reason there. So the standard certainly isn't as flawed as people want to assert, though there it could be improved.
In the end, we certainly can conclude a few things. First of all, despite the fact that these organizations had been assessed as compliant, the organizations clearly were not compliant. Though it is possible that a QSA missed something, that is still the organization's problem. Also, the standard cannot be perfect but it is very well built and, if followed, would have stopped these. In security, like any process, it may only take one flaw for a breach to occur - even if that was the standard or the QSA. But that's why security has to be layered and has to be based on quality, not compliance. Regardless, the whole security process is owned by the organization and they need to take responsibility when it breaks. Passing the buck doesn't undo the breach, but does make for some interesting blamestorming to watch.
Read more!
Subscribe to:
Posts (Atom)
Posts
