Contact Us
| SecureWorks - On the Radar Newsletter - May 2008 | |
|---|---|
 |
|
SecureWorks Releases SIM On-Demand™
On May 13, SecureWorks announced SIM On-Demand – a new Software-as-a-Service offering that delivers Security Information Management without organizations having to install and manage SIM hardware or software. SIM On-Demand provides powerful real-time correlation and automated analysis of logs and alerts from security devices and IT assets. Using SIM On-Demand, organizations can also comply with many regulatory requirements and demonstrate compliance with PCI, SOX, GLBA, FFIEC, HIPAA, NERC CIP and other regulations.
PCI DSS Requirement 6.6 Deadline Approaching
When the PCI Security Standards Council first released the PCI DSS v1.1 in September of 2006, a key revision was the addition of Requirement 6.6 which requires organizations who process, store or transmit payment card data to protect their web-facing applications against known attacks. Set to go into effect on June 30, 2008, Requirement 6.6 has been the subject of much debate among merchants, service providers, security vendors and industry analysts.
The PCI DSS v1.1 gives covered entities two basic options for protecting web-facing applications:
- Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
- Installing an application layer firewall in front of web-facing applications
In order to be compliant, either option utilized must result in prevention of known attacks. However, there has been a lot of confusion as to what exactly constitutes an "application code review" and an "application layer firewall" in the context of the PCI DSS. To address this confusion and provide guidance for covered entities and Qualified Security Assessors (QSAs), the PCI Security Standards Council released an information supplement on April 22nd with additional guidance on acceptable ways to comply with Requirement 6.6.
Option 1: Application Code Review
According to the PCI Security Standards Council’s guidance, an application code review can be accomplished by properly implementing one or more of the following:
- Manual review of application code
- Proper use of automated application source code analyzer (scanning) tools
- Manual web application security vulnerability assessment
- Proper use of automated web application security vulnerability assessment (scanning) tools.
There are positives and negatives with each of these different methods. Manual reviews and assessments are going to take more time and require a deeper level of expertise. Automated tools make the process faster, but you still need sufficient expertise to properly utilize the tools and interpret their results. And even then, automated scanning may not be sufficient without manual review. Additionally, in order to review application code, whether manually or using an automated tool, you must have access to the source code. This should not be an issue when you are dealing with home grown applications, but it can be a problem with commercial applications if the vendor is not willing to provide their application’s source code.
Because of this and the costs associated with source code review and analysis, many organizations will look to use a combination of manual web application assessments and automated web application scanning as the path of least resistance. However, if you have homegrown or custom applications it is best to evaluate which combination of the four Code Review options, including automated and manual testing for both the code and application, best meets application risk management goals for your organization. If performed proactively during the Software Development Life Cycle, source code review is one the most effective methods to mitigating application vulnerabilities.
Option 2: Application Layer Firewall
In addition to guidance on acceptable methods of application code review, the PCI Security Standards Council also detailed the capabilities that must be present in a technology for it to be considered an acceptable web application firewall that meets the intent of Requirement 6.6.
According to the PCI Security Standards Council, a web application should be able to:
- Meet all applicable PCI DSS requirements pertaining to system components in the cardholder data environment.
- Handle the OWASP Top Ten and/or PCI DSS Requirement 6.5.
- Inspect web application input and respond (allow, block, and/or alert) based on active policy or rules, and log actions taken.
- Prevent data leakage—meaning have the ability to inspect web application output and respond (allow, block, mask and/or alert) based on the active policy or rules, and log actions taken.
- Enforce both positive ("white list") and negative ("black list") security models.
- Inspect both web page content, such as HTML, DHTML, and CSS, and the underlying protocols that deliver content, such as HTTP/S.
- Inspect web services messages, if web services are exposed to the public Internet. Includes SOAP and XML.
- Inspect any protocol (proprietary or standardized) or data construct (proprietary or standardized) that is used to transmit data to or from a web application.
- Defend against threats that target the web application firewall (WAF) itself.
- Support SSL and/or TLS termination, or be positioned such that encrypted transmissions are decrypted before being inspected by the WAF.
There are several web application firewalls on the market that can help you protect web-facing applications from known attacks and many of these tools support the baseline capabilities set forth. However, be advised that a WAF must be properly managed in order to meet the intent of Requirement 6.6. You cannot simply set a WAF in front of an application and expect to be compliant without keeping it properly configured to protect the application. Also, if a WAF is not properly managed and tuned there is significant risk of blocking legitimate web application traffic which may not be acceptable for some organizations -- particularly those in which a significant portion of their business is conducted through online transactions. That being said, WAFs are a good fit for organizations with less complex requirements when it comes to protecting their web applications and we expect many merchants to implement WAFs for Requirement 6.6.
Overall, reviewing application code AND implementing a WAF is the best approach to meeting the intent of Requirement 6.6 because it would provide multi-layered defense. Reviewing application code via PCI-approved methods will help to eliminate vulnerabilities and harden your applications, while deploying and properly managing a WAF will protect against known web application exploit attempts. Of course, doing both of these options is not viable for many organizations due to the cost and expertise involved. The PCI Security Standards has recognized this reality and accepts organizations implementing one option or the other as long as it is properly implemented to satisfy Requirement 6.6. You should evaluate your organization’s web application security, compliance and business needs and take a risk-based approach that is best suited to protect your organization’s externally-facing applications given your situation.
If you are unsure what steps you should take to comply with Requirement 6.6, consulting a PCI Qualified Security Assessor can help you to determine the best options for your organization. If you have any questions about this or other PCI DSS requirements, please contact us at info@secureworks.com. SecureWorks is an approved Qualified Security Assessor (QSA) for the PCI DSS and we can work with you to understand what the requirements mean for your organization and help you meet your compliance goals.
Additional Resources
- PCI Information Supplement for Requirement 6.6
- PCI Data Security Standard v1.1
- SecureWorks PCI Compliance Solutions
Security 101: Botnets
Description
Botnets, derived from the terms 'robot' and 'networks', are networks of malware-infected computers controlled by a remote server. Botnets consist of bots that discreetly install themselves on hundreds, thousands or millions of different computers. In this case, bots are the applications that distribute spam, malware, etc. The bots continuously infect new computers and create an army of zombies that work together to conduct malicious activity.
Objectives
Zombie PCs in a botnet can execute any program the bot herder writes for it. Some of the more common ways botnets are used are:
- Distributed Denial of Service (DDoS). These attacks involve using a botnet to flood a network’s bandwidth or resources, preventing legitimate network traffic. With a large enough botnet, the bot herder can slow or even shut down networks.
- Identity Theft. Because bot herders can have virtually unlimited access to zombie computers, they can easily collect any account numbers, usernames, passwords and other confidential information stored on the zombies.
- Spam. Zombie machines are commonly used to generate huge volumes of spam. According to Merrick Furst, associate dean for undergraduate programs at Georgia Tech’s College of Computing, "over 80% of all spam messages are coming from bot armies right now."
- Malware. Botnets are frequently the launching point for viruses, worms, Trojans, and other types of malicious code.
Strengths
Ability to detect: 3 (Medium)
Ease: 4 (Hard) It is fairly costly for the criminal to compromise a significant number of devices.
Weaknesses
This can be fairly complicated to manage a large number of remote devices.
Detection Points
Detection of a compromised host via analysis of the host is an option however most malware is good at hiding its presence. Detection of the command and control channel through network behavior analysis or detection of the command and control protocol.
Prevention Points
- Keep your systems updated. Download the most recent updates of anti-malware tools (anti-virus, anti-spyware, etc) and patches. Keep applications updated by downloading or installing the latest versions.
- Be wary of suspicious email. Educate users to always verify questionable emails and never click on a link or open an attachment in a message from an unverified source.
- Control the use of ActiveX and JavaScript. Hackers take advantage of active web content to automatically download and execute malware once a web page is visited. Disabling or limiting the use of ActiveX and JavaScript will keep the malicious code from infecting user PCs.
- Use Network Intrusion Prevention Systems (NIPS). Properly managed NIPS devices will block attempts to compromise hosts as well as detect tell-tale zombie activity and prevent additional infections.
- Monitor your Firewall logs. With the capability to develop the botnet infinitely, zombies are promiscuous in their attempts to infect others. Close scrutiny of both ingress (inbound) and egress (outbound) firewall traffic can alert you to zombies on your network.
- Know your ISP’s emergency contact number. The best way to mitigate DDoS attacks is to filter the traffic at the ISP before it reaches your network.
- Filter malicious content. Use content filtering technology to block malicious web pages and spam that would otherwise infect user PCs.
References
