Geek

Will This Be The Next PCI Requirement Addition?

By Rich

I'm almost willing to bet money on this one...

Due to the nature of the recent breaches, such as Hannaford, where data was exfiltrated over the network, I highly suspect we will see outbound monitoring and/or filtering in the next revision of the PCI DSS. For more details on what I mean, refer back to this post.

Consider this your first warning.

–Rich

Recent Data Breaches- How To Limit Malicious Outbound Connections

By Rich

Word is slowly coming through industry channels that the attackers in the Heartland breach exfiltrated sniffed data via an outbound network connection. While not surprising, I did hear that the connection wasn't encrypted- the bad guys sent the data out in cleartext (I'll leave it to the person who passed this on to identify themselves if they want). Rumor from 2 independent sources is the bad guys are an organized group out of St. Petersburg (yes, Russia, as cliche as that is).

This is similar to a whole host of breaches- including (probably) TJX. While I'm not so naive as to think you can stop all malicious outbound connections, I do think there's a lot we can do to make life harder on the bad guys.

First, you need to lock down your outbound connections using a combination of current and next-generation firewalls. You should isolate out your transaction network to enforce tighter controls on it than on the rest of your business network. Traditional firewalls can lock down most outbound port/protocols, but struggle with nested/stealth channels or all the stuff shoveled over port 80. Next-gen firewalls and web gateways (I hate the name, but don't have a better one) like Palo Alto Networks or Mi5 Networks can help. Regular web gateways (Websense and McAfee/Secure Computing) are also good, but vary more on their outbound control capabilities and tend to be more focused on malware prevention (not counting their DLP products, which we'll talk about in a second).

The web gateway and next gen firewalls will focus on your overall network, while you can lock of the transaction side with tighter traditional firewall rules and segmenting that thing off.

Next, use DLP to sniff for outbound cardholder data. The bad guys don't seem to be encrypting, and DLP will alert on that in a heartbeat (and maybe block it, depending on the channel). You'll want to proxy with your web gateway to sniff SSL (and only some web gateways can do this) and set the DLP to alert on unauthorized encryption usage. That might be a real pain in the ass, if you have a lot of unmanaged encryption outside of SSL. Also, to do the outbound SSL proxy you need to roll out a gateway certificate to all your endpoints and suppress browser alerts via group policies.

I also recommend DLP content discovery to reduce where you have unencrypted stored data (yes, you do have it, even if you think you don't).

As you've probably figured out by now, if you are starting from scratch some of this will be very difficult to implement on an existing network, especially one that hasn't been managed tightly. Thus I suggest you focus on any of your processing/transaction paths and start walling those off first. In the long run, that will reduce both your risks and your compliance and audit costs.

–Rich

Building a Web Application Security Program, Part 8: Putting It All Together

By Adrian Lane

'Whew! This is our final post in this series on Building a Web Application Security Program (Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7), and it's time to put all the pieces together. Here are our guidelines for designing a program that meets the needs of your particular organization. Web application security is not a "one size fits all" problem. The risks, size, and complexity of the applications differ, the level of security awareness among team members varies, and most importantly the goals of each organization are different.

In order to offer practical advice, we needed to approach program development in terms of typical goals. We picked three use cases to represent common challenges organizations face with web app security, and will address those use cases with appropriate program models. We discuss a mid-sized firm tackling a compliance mandate for the first time, a large enterprise looking to improve security across customer-facing applications, and a mid-to-large organization dealing with security for internal applications. Each perspective has its own drivers and assumptions, and in each scenario different security measures are already in place, so the direction of each program will be different. Since we've been posting this over a series of weeks, before you dig in to this post we recommend you review Part 4: The Web Application Security Lifecycle which talks about all tools in all phases. First we describe the environment for each case, then overall strategy and specific recommendations.

Large Enterprise with Customer Facing Web Applications

For our first scenario, let's consider a large enterprise with multiple customer-facing web applications. These applications evolved to offer core business functions and are a principal contact point with customers, employees, and business partners. Primary business drivers for security are fraud reduction, regulatory compliance, and service reliability as tangible incentives. Secondary factors are breach preparedness, reputation preservation, and asset protection secondary -- all considerations for security spending. The question is not whether these applications need to be secured, but how. Most enterprises have a body of code with questionable security, and let's be totally honest here- these issues are flaws in your code. No single off-the-shelf product is going to magically make your application secure, so you invest not only in third-party security products, but also in improvements to your own development process which improve the product with each new release.

We assume our fictitious enterprise has an existing security program and the development team has some degree of maturity in their understanding of security issues, but how best to address problems is up for debate. The company will already have a 'security guy' in place, and while security is this guy's or gal's job, the development organization is not tasked with security assessments and problem identification. Your typical CISO comes from a network security background, lacks a secure code development background, and is not part of this effort. We find their security program includes vulnerability assessment tools, and they have conducted a review of the code for typical SQL injection and buffer overflow attacks. Overall, security is a combination of a couple third-party products and the security guy pointing out security flaws which are patched in upcoming release cycles.

Recommendations: The strategy is to include security within the basic development process, shifting the investment from external products to internal products and employee training. Tools are selected and purchased to address particular deficiencies in team skill or organizational processes. Some external products are retained to shield applications during patching efforts.

Training, Education, and Process Improvements: The area where we expect to see the most improvement is the skill and awareness of the web application development team. OWASP's top flaws and other sources point out issues that can be addressed by proper coding and testing ... provided the team knows what to look for. Training helps staff find errors and problems during code review, and iteratively reduces flaws through the development cycle. The development staff can focus on software security and not rely on one or two individuals for security analysis.

Secure SDLC: Knowing what to do is one thing, but actually doing it is something else. There must be an incentive or requirement for development to code security into the product, assurance to test for compliance, and product management to set the standards and requirements. Otherwise security issues get pushed to the side while features and functions are implemented. Security needs to be part of the product specification, and each phase of the development process should provide verification that the specification is being met through assurance testing. This means building security testing into the development process and QA test scenarios, as well as re-testing released code. Trained development staff can provide code analysis and develop test scripts for verification, but additional tools to automate and support these efforts are necessary, as we will discuss below.

Heritage Applications: Have a plan to address legacy code. One of the more daunting aspects for the enterprise is how to address existing code, which is likely to have security problems. There are several possible approaches for addressing this, but the basic steps are 1) identification of problems in the code, 2) prioritization on what to fix, and 3) planning how to fix individual issues. Common methods of addressing vulnerabilities include 1) rewriting segments of code, 2) method encapsulation, 3) temporary shielding by WAF ("secure & patch"), 4) moving SQL processing & validation into databases, 5) discontinuing use of insecure features, and 6) introduction of validation code within the execution path. We recommend static source code analysis or dynamic program analysis tools for the initial identification step. These tools are cost-effective and suitable for scanning large bodies of code to locate common risks and programming errors. They detect and prioritize issues, and reduce human error associated with tedious manual scanning by internal or external parties. Analysis tools also help educate staff about issues with certain languages and common programming patterns. The resulting arguments over what to do with 16k insecure occurrences of IFRAME are never fun, but acceptance of the problem is necessary before it can be effectively addressed.

External Validation: Periodic external review, through vulnerability assessment, penetration testing or source code review, is highly recommended . Skilled unbiased professionals with experience in threat analysis often catch items items which slip by internal scans, and can help educate development staff on different threat vectors. Plan on external penetration testing on a quarterly or biannual basis- their specific expertise and training goes far beyond the basics threats, and trained humans monitoring the output of sophisticated tools are very useful for detecting weaknesses that a hacker could exploit. We recommend the use of static testing tools for internal testing of code during the QA sweep, with internal penetration testing just prior to deployment so they can fully stress the application without fear of corrupting the production environment. Major releases should also undergo an external penetration test and review before deployment.

Blocking: This is one area that will really depend upon the specifics of your organization. In the enterprise use case, plan on using a Web Application Firewall. They provide basic protection and give staff a chance to remove security issues from the application. You may find that your code base is small and stable enough that you do not need WAF for protection, but for larger organizations this is not an option. Development and patching cycles are too long and cumbersome to counter threats in a reasonable timeframe. We recommend WAF + VA because in combination, they can relieve your organization from much of the threat research and policy development work for firewall rules. If your staff has the skill and time to develop WAF policies specific to your organization, you get customized policies at slightly greater expense in development costs. WAF isn't cheap, so we don't take this recommendation lightly, but it provides a great deal of flexibility in how and when threats are dealt with, today and as new threats evolve.

We recommend you take steps to improve security in every part of the development process. We are focused on improvements to the initial phases of development, as the impact of effort is greatest here, but we also recommend at the very least external assistance, and if budget allows, blocking. These later recommendations fill in other areas that need coverage, with penetration testing and web application firewalls. The risks to the enterprise are greater, the issues to overcome are more complex, and the corresponding security investment will therefore be larger. This workflow process should be formally documented for each stage of an application's lifecycle- from development through ongoing maintenance- with checkpoints for major milestones. Security shouldn't, and can't, be responsible for each stage, but should carry responsibility for managing the program and making sure the proper process is followed and maintained.

Mid-sized firm and PCI Compliance

If we are discussing web application security and compliance, odds are we are talking about the Payment Card Industry's Data Security Standard (PCI-DSS). No other compliance standard specifies steps to secure web applications like the PCI standard does. We can grouse about ambiguities and ways that it could be improved, but PCI is clearly the most widespread driver for web application security today, which is why our second use case is a mid-sized firm that needs to secure its web applications to satisfy PCI-DSS.

The profile for our company is a firm that generates a large portion of their revenue through Internet sales, and recent growth has made them a Tier 3 merchant. The commerce web site is relatively new (< 3 years) and the development team is small and not trained in security. Understanding the nuances of how criminals approach breaking code is not part of the team's skill set. PCI compliance is the mandate, and the team knows that they are both missing the basic requirements and susceptible to some kinds of attacks. The good news is that the body of code is small, and the web application accounts for a significant portion of the company's revenue, so management is supporting the effort.

In a nutshell, the PCI Data Security Standard is a security program specifically for companies that process credit card transactions for Internet commerce. In terms of compliance regulations, PCI-DSS requirements are clearer than most, making specific requirements for security tools and processes around credit card data. However, a company may also it has satisfy the spirit of the requirements in an alternate way, if it can demonstrate that the concern has been addressed. We will focus on the requirements outlined in sections 6.6 & 11.3, but will refer to sections 10 and compensating controls as well.

Recommendations: Our strategy focuses on education and process modifications to bring security into the development lifecycle. Additionally, we suggest assessment or penetration testing services to quickly identify areas of concern. Deploy WAF to address the PCI requirement immediately. Focus on the requirements to start, but plan for a more general program, and use compensating controls as your organization evolves. Use outside help and education to address immediate gaps, both in PCI compliance and more general application security.

Training, Education, and Process Improvements: Once again, we are hammering on education and training for the development team, including project management and quality assurance. While it takes time to come up to speed, awareness by developers helps keep security issues out of the code, and is cost-effective for securing the applications. Altering the process to accommodate fixing the code is essentially free, and code improvements become part of day to day efforts. With a small code base, education and training are easy ways to reap significant benefits as the company and code base grow.

External Help: Make friends with an auditor, or hire one as a consultant to help prepare and navigate the standard. While this is not a specific recommendation for any single requirement in PCI; auditors provide an expert perspective, help address some of the ambiguity in the standard, and assist in strategy and trade-off evaluations to avoid costly missteps.

Section 11.3.2: Section 11.3 mandates penetration testing of the network and the web application. In this case we recommend external penetration testing as an independent examination of the code. It is easy to recommend penetration testing, and not because it is required in the DSS specification, rather the independent & expert review of your application behavior will closely mimic the approach hackers will take. We also anticipate budget will require you make a choice between WAF and code reviews in section 6.6, so this will provide the necessary coverage. Should you use source code reviews, one could argue that acts as a compensating control for this section, but our recommendation is to stick with the external penetration testing. External testers provide much more than just a list of specific flaws, but also identify risky or questionable application behaviors in a near production environment.

Section 6.6: Our biggest debate internally was whether to recommend Web Application Firewall or expert code review to address section 6.6 of the PCI specification. The PCI Security Standards Council recommends that you do both, but it is widely recognized that this is prohibitively expensive. WAF provides a way to quickly meet the letter of 6.6's requirement, if not in spirit, provides basic monitoring, and is a flexible platform to block future attacks. The counter-arguments are significant and include cost, work required to customize policies for the application, and false positives & negatives. Alternatively, a code review by qualified security experts can identify weaknesses in application design and code usage and assist in education of the development team by pointing out specific flaws. Outside review is a very quick way to assess where you are and what you need. Down sides of review include cost, time to identify and fix errors, and that a constantly changing code base presents a moving target and thus requires repeated examinations.

Our recommendation here is deploy a WAF solution. Engaging a team of security professionals to review the code is an effective way to identify issues, but much of the value overlaps with the requirement of Section 11.3.2, periodic penetration testing of the application. The time to fix identified issues (even with a small-to-average body of code), with a development organization which is just coming to terms with security issues, is too long to meet PCI requirements in a timely fashion. Note that this recommendation is specific to this particular fictitious case- in other PCI audit scenarios, with a more experienced staff or a better handle on code quality, we might have made a different recommendation.

Monitoring: Database Activity Monitoring (DAM) is a good choice for Section 10 compliance- specifically by monitoring all access to credit card data. Web applications use a relational database back end to store credit card numbers, transactions, and card related data. DAM products that capture all network and console activity on the database platform provide a focused and cost-effective audit for all access to cardholder data. Consider this option for providing an audit trail for auditors and security personnel.

Internal Web Application Development

Our last use case is an internal web applications that serves employees and partners within a mid-to-large business. While this may not sound like a serious problem, given that companies have on average 1 internal application (web and traditional client/server) per 100 employees, even mid-sized companies have incredible exposure in this area. Using data from workflow, HR, accounting, business intelligence, sales, and other critical IT systems, these internal applications support employees and partners alike. And with access to pretty much all of the data within the company, security and integrity are major concerns. A common assumption is that these systems, behind the perimeter firewall, are not exposed to the same types of attacks as typical web applications, but this assumption has proven disastrous in many cases.

Investment here is motivated by fraud reduction, breach remediation, and avoidance of notification costs- and possibly by compliance. You may find this is difficult to sell to executive management if there is not a compliance mandate and hasn't been a previous breach, but if basic perimeter security is breached these applications need some degree of resiliency rather than blind confidence in network security and access control. TJ Maxx (http://www.tjx.com/) is an excellent illustration of the danger.

Strategy: Determine basic security of the internal application, fix serious issues, and leverage education, training, and process improvements to steadily improve the quality of code. We will assume that budgeting for security in this context is far smaller than for external-facing systems, so look to cooperate between groups and leverage tools and experience.

Vulnerability Assessment and Penetration Testing: Scanning web applications for significant security, patch and configuration issues is a recommended first step in determining if there are glaring issues. Assessment tools are a cost-effective way to establish baseline security and ensure adherence to minimum best practices. Internal penetration testing will help determine the overall potential risk and prioritization, but be extremely cautious of testing live applications.

Training, Education, and Process Improvements: These may be even more important in this scenario than in our other use cases, where the business justification provides incentive to invest in security, internal web applications may not get the same degree of attention. For these applications that have a captive audience, developers have greater controls over the types of environments that they support what can be required in terms of authentication. Use these freedoms to your advantage. Training should focus on common vulnerabilities within the application stack that is being used, and give critical errors the same attention that top priority bugs would receive. Verify that these issues are tested, either as part of the VA sweep, or a a component of regression testing.

Monitoring: Monitoring for suspicious activity and system misuse is a cost-effective way to detect issues and react to them. We find WAF solutions are often too expensive for deployment across hundreds of internal applications distributed across a company, and a more cost-effective approach to collecting and analyzing activity is highly recommended. Monitoring software that plugs into the web application is often very effective for delivering some intelligence at low cost, but the burden of analyzing the data then falls on development team members. Database Activity Monitoring can effectively focus on critical information at the back end and is more mature than Web Application Monitoring.

This segment of the series took much longer to write than we originally anticipated, as our research gave us conflicting answers to some questions, making our choices were far from easy. Our recommendations really depend upon the specifics of the situation and the organization. We approached this with use cases to demonstrate how the motivating factors; combined with the current state of web security; really guides the selection of tools, services, and process changes.

We found in every case that security as part of the overall development process is the most cost-effective and least disruptive to normal operations, and is our principal recommendation for each scenario. However, as transformation of a web application does not happen overnight, we rarely have the luxury of waiting for the development team to address all security issues is not realistic; in the meantime, external third-party services and products are invaluable for dealing with immediate security challenges.

–Adrian Lane

How The Cloud Destroys Everything I Love (About Web App Security)

By Rich

On Tuesday, Chris Hoff joined me to guest host the Network Security Podcast and we got into a deep discussion on cloud security. And as you know, for the past couple of weeks we've been building our series on web application security. This, of course, led to all sorts of impure thoughts about where things are headed. I wouldn't say I'm ready to run around in tattered clothes screaming about the end of the Earth, but the company isn't called Securosis just because it has a nice ring to it.

If you think about it a certain way, cloud computing just destroys everything we talk about for web application security. And not just in one of those, "oh crap, here's one of those analysts spewing BS about something being dead" ways. Before jumping into the details, in this case I'm talking very specifically of cloud based computing infrastructure- e.g., Amazon EC2/S3. This is where we program our web applications to run on top of a cloud infrastructure, not dedicated resources in a colo or a "traditional" virtual server. I also sprinkle in cloud services- e.g., APIs we can hook into using any application, even if the app is located on our own server (e.g., Google APIs).

Stealing from our yet incomplete series on web app sec and our discussions of ADMP, here's what I mean:

• Secure development (somewhat) breaks: we're now developing on a platform we can't fully control- in a development environment we may not be able to isolate/lock down. While we should be able to do a good job with our own code, there is a high probability that the infrastructure under us can change unexpectedly. We can mitigate this risk more than some of the other ones I'll mention- first, through SLAs with our cloud infrastructure provider, second by adjusting our development process to account for the cloud. For example, make sure you develop on the cloud (and secure as best you can) rather than completely developing in a local virtual environment that you then shift to the cloud. This clearly comes with a different set of security risks (putting development code on the Internet) that also need to be, and can be, managed. Data de-identification becomes especially important.
• Static and dynamic analysis tools (mostly) break: We can still analyze our own source code, but once we interact with cloud based services beyond just using them as a host for a virtual machine, we lose some ability to analyze the code (anything we don't program ourselves). Thus we lose visibility into the inner workings of any third party/SaaS APIs (authentication, presentation, and so on), and they are likely to randomly change under our feet as the providing vendor continually develops them. We can still perform external dynamic testing, but depending on the nature of the cloud infrastructure we're using we can't necessarily monitor the application during runtime and instrument it the same way we can in our test environments. Sure, we can mitigate all of this to some degree, especially if the cloud infrastructure service providers give us the right hooks, but I don't hold out much hope this is at the top of their priorities. (Note for testing tools vendors- big opportunity here).
• Vulnerability assessment and penetration testing... mostly don't break: So maybe the cloud doesn't destroy everything I love. This is one reason I like VA and pen testing- they never go out of style. We still lose some ability to test/attack service APIs.
• Web application firewalls really break: We can't really put a box we control in front of the entire cloud, can we? Unless the WAF is built into the cloud, good luck getting it to work. Cloud vendors will have to offer this as a service, or we'll need to route traffic through our WAF before it hits the back end of the cloud, negating some of the reasons we switch to the cloud in the first place. We can mitigate some of this through either the traffic routing option, virtual WAFs built into our cloud deployment (we need new products for it), or cloud providers building WAF functionality into their infrastructure for us.
• Application and Database Activity Monitoring break: We can no longer use external monitoring devices or services, and have to integrate any monitoring into our cloud-based application. As with pretty much all of this list it's not an impossible problem, just one people will ignore. For example, I highly doubt most of the database activity monitoring techniques will work in the cloud- network monitoring, memory monitoring, or kernel extensions. Native audit might, but not all database management systems provide effective audit logs, and you still need a way to collect them as your app and db shoot around the cloud for resource optimization.

I could write more about each of these areas, but you get the point. When we run web applications on cloud based infrastructure, using cloud based software services, we break much of the nascent web application security models we're just starting to get our fingers around. The world isn't over*, but it sure just moved out from under our feet.

*This doesn't destroy the world, but it's quite possible that the Keanu Reeves version of The Day the Earth Stood Still will.

–Rich

The Biggest Difference Between Web Applications And Traditional Applications.

By Rich

Adrian and I have been hard at work on our web application security overview series, and in a discussion we realized we left something off part 3 of the series when we dig into the differences between web applications and traditional applications.

In most applications we program the user display/interface. With web applications, we rely on an external viewer (the browser) we can't completely control, that can be interacting with other applications at the same time.

Which is stupid, because it's the biggest, most obvious difference of them all.

–Rich

Building A Web Application Security Program: Part 2, The Business Justification

By Adrian Lane

'In our last post in this series we introduced some of the key reasons web application security is typically underfunded in most organizations. The reality is that it's often difficult to convince management why they need additional protections for an application that seems to be up and running just fine. Or to change a development process the developers themselves are happy with. While building a full business justification model for web application security is beyond the scope of this post (and worthy of its own series), we can't talk about building a program without providing at least some basic tools to determine how much you should invest, and how to convince management to support you. The following list isn't a comprehensive business justification model, but provides typical drivers we commonly see used to justify web application security investments:

Compliance - Like it or not, sometimes security controls are mandated by government regulation, industry standards/requirements, or contractual agreements. We like to break compliance into three separate justifications- mandated controls (PCI web application security requirements), non-mandated controls that avoid other compliance violations (data protection to avoid a breach disclosure), and investments to reduce the costs of compliance (lower audit costs or TCO). The average organization uses all three factors to determine web application security investments.

Fraud Reduction - Depending on your ability to accurately measure fraud, it can be a powerful driver of, and justification for, security investments. In some cases you can directly measure fraud rates and show how they can be reduced with specific security investments. Keep in mind that you may not have the right infrastructure to detect and measure this fraud in the first place, which could provide sufficient justification by itself. Penetration tests are also useful is justifying investments to reduce fraud- a test may show previously unknown avenues for exploitation that could be under active attack, or open the door to future attack. You can use this to estimate potential fraud and map that to security controls to reduce losses to acceptable levels.

Cost Savings - As we mentioned in the compliance section, some web application security controls can reduce your cost of compliance (especially audit costs), but there are additional opportunities for savings. Web application security tools and processes during the development and maintenance stages of the application can reduce costs of manual processes or controls and/or costs associated with software defects/flaws, and may cause general efficiency improvements. We can also include cost savings from incident reduction- including incident response and recovery costs.

Availability - When dealing with web applications, we look at both total availability (direct uptime), and service availability (loss of part of the application due to attack or to repair a defect). For example, while it's somewhat rare to see a complete site outage due to a web application security issue (although it definitely happens), it's not all that rare to see an outage of a payment system or other functionality. We also see cases where, due to active attack, a site needs to shut down some of its own services to protect users, even if the attack didn't break the services directly.

User Protection - While this isn't quantifiable with a dollar amount, a major justification for investment in web security is to protect users from being compromised by their trust in you (yes, this has reputation implications, but not ones we can precisely measure). Attackers frequently compromise trusted sites not to steal from that site, but to use it to attack the site's users. Even if you aren't concerned with fraud resulting in direct losses to your organization, it's a problem if your web application is used to defraud your users.

Reputation Protection - While many models attempt to quantify a company's reputation and potential losses due to reputation damage, the reality is all those models are bunk- there is no accurate way to measure the potential losses associated with a successful attack. Despite surveys indicating users will switch to competitors if you lose their information, or that you'll lose future business, real world stats show that user behavior rarely aligns with survey responses. For example, TJX was the largest retail breach notification in history, yet sales went up after the incident. But just because we can't quantify reputation damage doesn't mean it isn't an important factor in justifying web application security. Just ask yourself (or management) how important that application is to the public image of your organization, and how willing you or they are to accept the risk of losses ranging from defacement, to lost customer information, to downtime.

Breach Notification Costs - Aside from fraud, we also have direct losses associated with breach notifications (if sensitive information is involved). Ignore all the fluffy reputation/lost business/market value estimates and focus on the hard dollar costs of making a list, sending a notification, and manning the call center for customer inquiries. You might also factor in the cost of credit monitoring, if you'd offer that to your customers.

You'll know which combination of these will work best for you based on your own organizational needs and management priorities, but the key takeaway should be that you likely need to mix quantitative and qualitative assessments to prioritize your investments. If you're dealing with private information (financial/retail/healthcare), compliance drivers and breach notification mixed with cost savings are your best option. For general web services, user protection & reputation, fraud reduction, and availability are likely at the top of your list. And let's not forget many of these justifications are just as relevant for internal applications.

Whatever your application, there is no shortage of business (not technical) reasons to invest in web application security.

–Adrian Lane

Upgrading to Parallels 4.0

By Adrian Lane

I installed Parallels 4.0 on the iMac last week, upgraded my licenses and converted my bootable images to the new format. It took a while to do as the conversion process takes a long time. While the installation was trivial, I had 4 different bootable images to convert, which took a good 3 hours to migrate even though they were only a couple of gigabytes a piece and only have a handful of applications installed. But I had no problems and everything worked fine. There are a couple subtle changes to the interface that make management of the images a little easier. I have not witnessed the performance enhancements that are claimed to be present, but I have not had performance issues in the past, so your mileage may vary.

As the build I used was the one provided right after the official announcement, I was expecting that a new one would be released soon to clear up some small issues that have popped up. Sure enough, build 4.0.3540.209168 popped up today. Problem is I cannot install it. The 'Continue' button is grayed out; tried a couple of times, but there are really no options other than to accept and continue, but still I cannot proceed. I cannot imagine something this simple not getting picked up by QA. Anyone else out there having this issue?

–Adrian Lane

Politics And Protocols

By Rich

Catching up from last week I saw this article in Techworld (from NetworkWorld) about an IETF meeting to discuss the impact of Dan Kaminsky's DNS exploit and potential strategies for hardening DNS.

The election season may be over, but it's good to see politics still hard at work:

One option is for the IETF to do nothing about the Kaminsky bug. Some participants at the DNS Extensions working group meeting this week referred to all of the proposals as a "hack" and argued against spending time developing one of them into a standard because it could delay DNSSEC deployment. Other participants said it was irresponsible for the IETF to do nothing about the Kaminsky bug because large sections of the DNS will never deploy DNSSEC. "We can do the hack and it might work in the short term, but when DNSSEC gets widely used, we'll still be stuck with the hack," said IETF participant Scott Rose, a DNSSEC expert with the US National Institute for Standards and Technology (NIST).

Look, any change to DNS is huge and likely ugly, but it's disappointing that there seems to be a large contingent that wants to use this situation to push the DNSSEC agenda without exploring other options. DNSSEC is massive, complex, ugly, and prone to its own failures. You can read more about DNSSEC problems at this older series over at Matasano (Part 1, Part 2, site currently experiencing some problems, should be back soon).

The end of the article does offer some hope:

The co-chairs of the DNS Extensions working group said they hope to make a decision on whether to change the DNS protocols in light of the Kaminsky bug before the group's next meeting in March. " We want to avoid creating a long-term problem that is caused by a hasty decision," Sullivan said. "There are big reasons to be careful here. The DNS is a really old protocol and it is fundamental to the Internet. We're not talking about patching software. We're talking about patching a protocol. We want to make sure that whatever we do doesn't break the Internet."

Good- at least the chairs understand that rushing headlong into DNSSEC may not be the answer. We might end up there anyway, but let's make damn sure it's the right thing to do first.

–Rich

Everything Old Is New Again In The Fog Of The Cloud

By Rich

Look I understand too little too late I realize there are things you say and do You can never take back But what would you be if you didn't even try You have to try So after a lot of thought I'd like to reconsider Please If it's not too late Make it a... cheeseburger

-Here I Am by Lyle Lovett

Sometimes I get a little too smart for my own good and think I can pull a fast one over you fair readers. Sure enough, Hoff called me out over my Cloud Computing Macro Layers post from yesterday. And I quote:

I'd say that's a reasonable assertion and a valid set of additional "layers." There also not especially unique and as such, I think Rich is himself a little disoriented by the fog of the cloud because as you'll read, the same could be said of any networked technology. The reason we start with the network and usually find ourselves back where we started in this discussion is because the other stuff Rich mentions is just too damned hard, costs too much, is difficult to sell, isn't standardized, is generally platform dependent and is really intrusive. See this post (Security Will Not End Up In the Network) as an example. Need proof of how good ideas like this get mangled? How about Web 2.0 or SOA which is for lack of a better description, exactly what RIch described in his model above; loosely coupled functional components of a modular architecture.

My response is... well... duh. I mean we're just talking distributed applications, which we, of course, have yet to really get right (although multiplayer games and gambling are close).

But I take a little umbrage with Chris's assumptions. I'm not proposing some kind of new, modular structure a la SOA, I'm talking more about application logic and basic security than anything else, not bolt-on tools. Because the truth is, it will be impossible to add these things on after the fact; it hasn't worked well for network security, and sure as heck won't work well for application security. These aren't add-on products, they are design principles. They aren't all new, but as everyone jumps off the cliff into the cloud they are worth repeating and putting into context for the fog/cloud environment.

Thus some new descriptions for the layers. Since it's Friday and all I can think about is the Stone Brewery Epic Vertical Ale sitting in my fridge, this won't be in any great depth:

• Network: Traditional network security, and the stuff Hoff and others have been talking about. We'll have some new advances to deal with the network aspects of remote and distributed applications, such as Chris' dream of IF-MAP, but we're still just talking about securing the tubes.
• Service: Locking down the Internet exposed APIs- we have a fair bit of experience with this and have learned a lot of lessons over the past few years with work in SOA- SOAP, CORBA, DCOM, RPC and so on. We face three main issues here- first, not everyone has learned those lessons and we see tons of flaws in implementations and even fundamental design. Second, many of the designers/programmers building these cloud services don't have a clue or a sense of history, and thus don't know those lessons. And finally, most of these cloud services build their own kinds of APIs from scratch anyway, and thus everything is custom, and full of custom vulnerabilities from simple parsing errors, to bad parameterization, to logic flaws. Oh, and lest we not forget, plenty of these services are just web applications with AJAX and such that don't even realize they are exposing APIs. Fun stuff I refer to as, "job security".
• User: This is an area I intend to talk about in much greater depth later on. Basically, right now we rely on static authentication (a single set of credentials to provide access) and I think we need to move more towards adaptive authentication (where we provide an authentication rating based on how strongly we trust that user at that time in that situation, and can thus then adjust the kinds of allowed transactions). This actually exists today- for example, my bank uses a username/password to let me in, but then requires an additional credential for transactions vs. basic access.
• Transaction: As with user, this is an area we've underexplored in traditional applications, but I think will be incredibly valuable in cloud services. We build something called adaptive authorization into our applications and enforce more controls around approving transactions. For example, if a user with a low authentication rating tries to transfer a large sum out of their bank account, a text message with a code will be send to their cell phone with a code. If they have a higher authentication rating, the value amount before that back channel is required goes up. We build policies on a transaction basis, linking in environmental, user, and situational measurements to approve or deny transactions. This is program logic, not something you can add on.
• Data: All the information-centric stuff we expend endless words on in this blog.

Thus this is nearly all about design, with a smidge of framework and shared security services support we can build into common environments (e.g. an adaptive authentication engine or encryption services in J2EE). No loosely coupled functional components, just a simple focus on proper application design with awareness of the distributed environment.

But as Chris also says,

It should be noted, however that there is a ton of work, solutions and initiatives that exist and continue to be worked on these topics, it's just not a priority as is evidenced by how people exercise their wallets.

Exactly. Most of what we write about cloud computing security will be ignored...

... but what would we be if we didn't even try. You have to try.

–Rich

Cloud Security Macro Layers

By Rich

There's been a lot of discussion on cloud computing in the blogosphere and general press lately, and although I'll probably hate myself for it, it's time to jump in beyond some sophomoric (albeit really funny) humor.

Chris Hoff inspired this with his post on TCG IF-MAP; a framework/standard for exchanging network security objects and events. It's roots are in NAC, although as Alan Shimel informs us there's been very little adoption.

Since cloud computing is a crappy marketing term that can mean pretty much whatever you want, I won't dig into the various permutations in this post. For the purposes of this post I'll be focusing on distributed services (e.g. grid computing), online services, and SaaS. I won't be referring to in the cloud filtering and other network-only services.

Chris's posting, and most of the ones I've seen out there, are heavily focused on network security concepts as they relate to the cloud. but if we look at cloud computing from a macro level, there are additional layers that are just as critical (in no particular order):

• Network: The usual network security controls.
• Service: Security around the exposed APIs and services.
• User: Authentication- which in the cloud word will need to move to more adaptive authentication, rather than our current username/password static model.
• Transaction: Security controls around individual transactions- via transaction authentication, adaptive authorization, or other approaches.
• Data: Information-centric security controls for cloud based data. How's that for buzzword bingo? Okay, this actually includes security controls over the back end data, distributed data, and any content exchanged with the user.

Down the road we'll dig into these in more detail, but anytime we start distributing services and functionality over an open public network with no inherent security controls, we need to focus on the design issues and reduce design flaws as early as possible. We can't just look at this as a network problem- our authentication, authorization, information, and service (layer 7) controls are likely even more important.

This gets me thinking it's time to write a new framework... not that anyone will adopt it.

–Rich

1 In 4 DNS Servers Still Vulnerable? More Like 4 in 4

By Rich

I was reading this article over at NetworkWorld today on a study by a commercial DNS vendor that concluded 1 in 4 DNS servers is still vulnerable to the big Kaminsky vulnerability.

The problem is, the number is more like 4 in 4.

The new attack method that Dan discovered is only slowed by the updates everyone installed, it isn't stopped. Now instead of taking seconds to minutes to compromise a DNS server, it can take hours.

Thus if you don't put compensating security in place, and you're a target worth hitting, the attacker will still succeed.

This is a case where IDS is your friend- you need to be watching for DNS traffic floods that will indicate you are under attack. There are also commercial DNS solutions you can use with active protections, but for some weird reason I hate the idea of paying for something that's free, reliable, and widely available.

On that note, I'm going to go listen to my XM Radio. The irony is not lost on me.

–Rich

WAF vs. Secure Code vs. Dead Fish

By Rich

I've been slowly catching up on my reading after months of near-nonstop travel, and this post over at Imperviews caught my eye. Ignoring the product promotion angle, it raises one of my major pet peeves these days. I'm really tired of the Web Application Firewall vs. secure coding debate, never mind using PCI 6.6 to justify one over the other for security effectiveness. It's like two drunk cajuns arguing over the relative value of shrimp or pork in gumbo- you need both, and if either is spoiled the entire thing tastes like sh&t. You also can't dress up the family dog and fish in a pinch, use them as substitutes, and expect your kids to appreciate either the results or use of resources (resulting gumbo or the loss of Rover).

Here's the real deal-

Secure coding is awesome and you need to adopt a formal process if you produce any meaningful volume of code. But it takes a ton of resources to get to the old code (which you should still try to do), and can't account for new vulnerability classes. Also, people screw up... even when there are multiple layers to detect or prevent them from screwing up.

On the other hand, WAFs need to get a hell of a lot better. We're seeing some positive advancements, as I've written about before, but they still can't stop all vulnerabilities, can't stop logic flaws and certain other categories of attack, can't deal with the browser end, and I hear a lot of complaints about tuning (while I think liking WAFs with Vulnerability Assessment is a great start on this problem, we're just at the start of that race).

I absolutely hate to tell you to buy more than you need, but if you have a major web presence you likely need both these days, in the right combination (plus a few other things).

If you don't have the resources for both, I suggest two options. First, if you are really on the low end of resources, use hosted applications and standard platforms as much as possible to limit your custom coding. Then, make sure you have kick ass backups. Finally, absolutely minimize the kinds of information and transaction you expose to the risk of web attacks- drop those ad banners, minimize collecting private information, and validate transactions on the back end as much as possible.

If you do have some more resources available, I suggest starting with a vulnerability assessment (not a cheap ass bare-bones PCI scan, but something deeper), and using that to figure out where to go next.

Yes- we are eating our own dog food on this one. The blog is hosted using a standard platform. We know it's vulnerable, so we've minimized the attack surface as best we can and make sure we have backups of all the content. I've been pleasantly surprised we haven't been nailed yet, but I expect it to happen eventually. None of our sensitive operations are on that server, and we've pulled email and our other important stuff in house.

Early next year we're going to be launching some new things, and we will again go with remote hosting (on a more powerful platform). This time, we are switching to a more secure platform than Wordpress (Expression Engine) and will pay for a full vulnerability assessment and penetration test (at least annually, or when any major new components come online). We may perform some financial transactions, and we'll use an external provider for that. A WAF is out of budget for us, so we'll focus on minimizing our exposure and manually fixing problems discovered by ongoing assessments. We also plan on using as little custom code as possible.

But seriously- I'm tired of this debate. Both options have value, they aren't exclusionary, and which you need depends on what you are doing and how many resources you have.

Eventually we'll get a better lock on this problem, but that's a few years out.

–Rich

Your Simple Guide To Endpoint Encryption Options

By Rich

On the surface endpoint encryption is pretty straightforward these days (WAY better than when I first covered it 8 years ago), but when you start matching all the options to your requirements it can be a tad confusing.

I like to break things out into some simple categories/use cases when I'm helping people figure out the best approach. While this could end up as one of those huge blog posts that ends up as a whitepaper, for today I'll stick with the basics. Here are the major endpoint encryption options and the most common use cases for them:

• Full Drive Encryption (FDE): To protect data when you lose a laptop/desktop (but usually laptop). Your system boots up to a mini-operating system where you authenticate, then the rest of the drive is decrypted/encrypted on the fly as you use it. There are a ton of options, including McAfee, CheckPoint, WinMagic, Utimaco, GuardianEdge, PGP, BitArmor, BitLocker, TrueCrypt, and SafeNet.
• Partial Drive Encryption: To protect data when you lose a laptop/desktop. Similar to whole drive, with some differences for dealing with system updates and such. There's only one vendor doing this today (Credent), and the effect is equivalent to FDE except in limited circumstances.
• Volume/Home Directory Encryption: For protecting all of a user's or group's data on a shared system. Either the users home directory or a specific volume is encrypted. Offers some of the protection of FDE, but there is a greater chance data may end up in shared spaces and be potentially recovered. FileVault and TrueCrypt are examples.
• Media Encryption: For encrypting an entire CD, memory stick, etc. Most of the FDE vendors support this.
• File/Folder Encryption: To protect data on a shared system- including protecting sensitive data from administrators. FDE and file folder encryption are not mutually exclusive- FDE protects against physical loss, while file/folder protects against other individuals with access to a system. Imagine the CEO with an encrypted laptop that still wants to protect the financials from a system administrator. Also useful for encrypting a folder on a shared drive. Again, a ton of options, including PGP (and the free GPG), WinMagic, Utimaco, PKWare, SafeNet, McAfee, WinZip, and many of the other FDE vendors (I just listed the ones I know for sure).
• Distributed Encryption: This is a special form of file/folder encryption where keys are centrally managed with the encryption engine distributed. It's used to encrypt files/folders for groups or individuals that move around different systems. There are a bunch of different technical approaches, but basically as long as the product is on the system you are using, and has access to the central server, you don't need to manually manage keys. Ideally, to encrypt you can right-click the file and select the group/key you'd like to use (or this is handled transparently). Options include Vormetric, BitArmor, PGP, Utimaco, and WinMagic (I think some others are adding it).
• Email Encryption: To encrypt email messages and attachments. A ton of vendors that are fodder for another post.
• Hardware Encrypted Drives: Keys are managed by software, and the drive is encrypted using special hardware built-in. The equivalent of FDE with slightly better performance (unless you are using it in a high-activity environment) and better security. Downside is cost, and I only recommend it for high security situations until prices (including the software) drop to what you'd pay for software. Seagate is first out of the gate, with laptop, portable, and full size options.

Here's how I break out my advice:

• If you have a laptop, use FDE.
• If you want to protect files locally from admins or other users, add file/folder. Ideally you want to use the same vendor for both, although there are free/open source options depending on your platform (for those of you on a budget).
• If you exchange stuff using portable media, encrypt it, preferably using the same tool as the two above.
• If you are in an enterprise and exchange a lot of sensitive data, especially on things like group projects, use distributed encryption over regular file/folder. It will save a ton of headaches. There aren't free options, so this is really an enterprise-only thing.
• Email encryption is a separate beast- odds are you won't link it to your other encryption efforts (yet) but this will likely change in the next couple years. Enterprise options are linked up on the email server vs. handling it all on the client, thus why you may manage it separately.

I generally recommend keeping it simple- FDE is pretty much mandatory, but many of you don't quite need file/folder yet. Email is really nice to have, but for a single user you are often better off with a free option since the commercial advantages mostly come into play on the server.

Personally I used to use FileVault on my Mac for home directory encryption, and GPG for email. I then temporarily switched to a beta of PGP for whole drive encryption (and everything else; but as a single user the mail.app plugin worked better than the service option). My license expired and my drive decrypted, so I'm starting to look at other options (PGP worked very well, but I prefer a perpetual license; odds are I will end up back on it since there aren't many Mac options for FDE- just them, CheckPoint, and WinMagic if you have a Seagate encrypting drive). FileVault worked well for a while, but I did encounter some problems during a system migration and we still get problem reports on our earlier blog entry about it.

Oh- and don't forget about the Three Laws. And if there were products I missed, please drop them in the comments.

–Rich

Your WPA-PSK Wireless Network Is At Risk… If You Are An Idiot

By Rich

There was some great hype in the wireless security world this weekend thanks to an article that made it on to Slashdot, and some FUD pumping so-called security consultants. Elcomsoft issued a press release that they can now crack WPA keys WAY faster using the GPUs (Graphics Processing Units) on the latest video cards.

It's kind of cool, and for wireless pen testing the tool sounds useful, but some of the quotes in the article from the security firm GSS (who I never heard of) are the typical garbage:

"This breakthrough in brute force decryption of Wi-Fi signals by Elcomsoft confirms our observations that firms can no longer rely on standards-based security to protect their data," said GSS managing director David Hobson. "As a result, we now advise clients using Wi-Fi in their offices to move on up to a VPN encryption system as well." ... Hobson added that the development could spur a step back from wireless to wired network connection in sensitive installation, such as financial services organisations, particularly concerned about data privacy.

Idiots.

These guys are forgetting two things- first, this method doesn't work AT ALL against an enterprise installation (RADIUS) of WPA. George Ou has more on this.

Second, as the original article added as an update, this attack only speeds up brute forcing. Use a long, strong passphrase for your WPA key and you're fine. Rob Graham also has more on this.

WPA-PSK still sucks to manage, and keys go stale, but use a good one and you're fine. GCC should go back to playing Team Fortress or something with those video cards, because they were either misquoted, or clueless.

–Rich

Mail Goggles

By Adrian Lane

Someone at Google has created Mail Goggles. It's a little Gmail utility to keep you from sending out email while, uh, under the influence. Jon Perlow, the author, had this to say ...

[snip] "Sometimes I send messages I shouldn't send. Like the time I told that girl I had a crush on her over text message. Or the time I sent that late night e-mail to my ex-girlfriend that we should get back together," [/snip]

And who hasn't, really? It's no wonder I am not smart enough to work at Google. I would never have through this up, never mind actually coding it. I checked, and it's really there, under the Lab's section, along with a dozen or so other productivity tools. I really think they could be onto something here ... just consider this from a 'Reputational Risk' perspective; this could be a hot product for Postini. One too many Martini's with lunch? Drowning your sorrows as you watch your stock portfolio plunge? A little testy that your "spa day" executive retreat was cancelled? No problem, Google will quarantine your outbound email! And if your too drunk to remember to turn this off, your email probably should be sequestered. Hoff was right, Google really is becoming a security company. Now, where did I leave that glass of bourbon ...

–Adrian Lane