Research

By now you’ve probably noticed that we’re spending a lot of time discussing the non-technical issues of web application security. We felt we needed to start more on the business side of the problem since many organizations really struggle to get the support they need to build out a comprehensive program. We have many years invested in understanding network and host security issues, and have built nearly all of our security programs to focus on them. But as we’ve laid out, web application security is fundamentally different than host or network security, and requires a different approach. Web application security is also different from traditional software security, although it has far more in common with that discipline. In today’s post we’re going to get a little (just a little) more technical and talk about the specific technical and non-technical reasons web application security is different, before giving an overview of our take on the web application security lifecycle in the next post. Part 1 Part 2 Why web application security is different than host and network security With network and host security our focus is on locking down our custom implementations of someone else’s software, devices, and systems. Even when we’re securing our enterprise applications, that typically involves locking down the platform, securing communications, authenticating users, and implementing security controls provided by the application platform. But with web applications we not only face all those issues- we are also dealing with custom code we’ve often developed ourselves. Whether internal-only or externally accessible, web application security differs from host and network in major ways: Custom code equals custom vulnerabilities: With web applications you typically generate most of the application code yourself (even when using common frameworks and plugins). That means most vulnerabilities will be unique to your application. It also means that unless you are constantly evaluating your own application, there’s no one to tell you when a vulnerability is discovered in the first place. You are the vendor: When a vulnerability appears, you won’t have an outside vendor providing a patch (you will, of course, have to install patches for whatever infrastructure components, frameworks, and scripting environments you use). If you provide external services to customers, you may need to meet any service level agreements you provide and must be prepared to be viewed by them just as you view your own software vendors, even if software isn’t your business. You have to patch your own vulnerabilities, deal with your own customer relations, and provide everything you expect from those who provide you with software and services. Firewalls/shielding alone can’t protect web applications: When we experience software vulnerabilities with our enterprise software, from operating systems, to desktop applications, to databases and everything else, we use tools like firewalls and IPS to block attacks while we patch the vulnerable software. This model of shield then patch has only limited effectiveness for web applications. A web application firewall (WAF) can’t protect you from logic flaws. While WAFs can help with certain classes of attack, out of the box they don’t know or understand your application and thus can’t protect custom vulnerabilities they aren’t tuned for. WAFs are an important part of web application security, but only when part of a comprehensive program, as we’ll discuss. Eternal Beta Cycles: When we program a traditional stand-alone application it’s usually designed, developed, and tested in a controlled environment before being carefully rolled out to select users for additional testing, then general release. While we’d like all web applications to run through this cycle, as we discussed in our first post in this series it’s often not so clean. Some applications are designated beta and treated as such by the development teams, but in reality they’ve quietly grown into full-bore essential enterprise applications. Other applications are under constant revision and don’t even attempt to follow formal release cycles. Continually changing applications challenge both existing security controls (like WAFs) and response efforts. Reliance on frameworks/platforms: We rarely build our web applications from the ground up in shiny new C code. We use a mixture of different frameworks, development tools, platforms, and off the shelf components to piece them together. We are challenged to secure and deploy these pieces as well as the custom code we build with and on top of them. In many cases we create security issues through unintended uses of these components or interactions between the multiple layers due to the complexity of the underlying code. Heritage (legacy) code: Even if we were able to instantly create perfectly secure code from here on forward, we still have massive code bases full of old vulnerabilities still to fix. If older code is in active use, it needs just as much security as anything new we develop. With links to legacy systems, modification of the older applications often ranges from impractical to impossible, placing the security burden on the newer web application. Dynamic content: Most web applications are extremely dynamic in nature, creating much of their content on the fly, not infrequently using elements (including code) provided by the user. Because of the structure of the web, while this kind of dynamically generated content would fail in a traditional application, our web browsers try their best to render it to the user- thus creating entire classes of security issues. New vulnerability classes: As with standard applications, researchers and bad guys are constantly discovering new classes of vulnerabilities. In the case of the Web, these often effect nearly every web site on the face of the planet the moment they are discovered. Even if we write perfect code today, there’s nothing to guarantee it will be perfect tomorrow. We’ve listed a number of reasons we need to look at web applications differently, but the easiest way to think about it is that web applications have the scope of externally-facing network security issues, the complexity of custom application development security, and the implications of ubiquitous host security vulnerabilities. At this point we’ve finished laying out the background for

All right, people, here’s the deal. I just published my take on the whole “Apple he said/she said you do/don’t need antivirus” thing over at TidBITS. Here’s my interpretation of what happened: Back in 2007 some support guy posted a list of major AV products supported on the Mac. On November 21st, it was updated to reflect current version numbers. Whoever wrote it is a shitty writer, and didn’t realize how people would interpret it. The press found it and trumpeted it to the world. Apple management went, “WTF?!? We don’t tell people they should install three different AV programs all at once. Hell, we never tell them they need AV at all. Not that we’re going to tell them *not* to use it…” The support article was pulled and statements issued. Some people called it a conspiracy, because they like that sort of thing. Somewhere deep in the bowels of 1 Infinite Loop, there is a pike, holding a bloody head, on prominent display. So no, most of you don’t need antivirus. You can read my article on this from back in March if you want more help deciding if you should take a look at AV on your Mac. Alan Shimel is one of a group of people who think it’s about time Mac users payed attention to security and installed AV. I like to break that argument into two sections. First, as I’ve learned since writing for TidBITS and Macworld, the average Mac user is definitely worried about security. But (second) this doesn’t mean desktop AV is the right answer. Right now, the risk of malware infection on the Mac is so low for the average user that AV really doesn’t make sense. That can change, heck, it probably will change, but that’s the situation today. Thus I recommend most people use mail filtering and browse safely rather than installing desktop AV. Not recommending AV isn’t Apple’s ego (and I don’t deny they have an ego), it’s a reflection of the risk to users in the current environment. Now the odds are us Mac security types will recommend AV long before Apple does, but that day definitely isn’t here yet. Apple didn’t reverse their policies- something slipped out from the lower levels by accident, and all the hubbub is much ado about nothing. The day will likely come when Mac users need additional malware protection, but today isn’t that day, and even then, AV may not be the answer. Read my older article on this, and keep up with the news so you’ll know when the time comes. Share:

‘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. Share:

It’s just Martin and myself again this week as we discuss PCI, online identities, telecom immunity, and one wacky data breach. We also spend a fair bit of time talking about our home network setups and Martin’s adventures in protecting his kids from YouTube. I also dig into how I’m using our Drobo and how we manage backups here at Securosis HQ. Network Security Podcast, Episode 130, December 2, 2008 Show Notes: PCI Compliance Services FAQ The End of Online Anonymity – It’s not the end, it’s a change in how we look at it. EFF to fight against telecom immunity in Tuesday hearing – I hope everything went well for Jennifer Granick and friends Cybercrime servers selling billions of dollars worth of stolen information & illicit services Canadian IT exec accused of stealing customer database There is always a back story … – Richard digs into the Canadian IT story Share:

‘It’s official- Arizona Governor Janet Napolitano is President-Elect Obama’s choice for Secretary of Homeland Security. I’ve only been living in Arizona for about 5 years now and have been consistently impressed with Napolitano. She’s a Democratic gove or in a mostly-red state and well respected by everyone except the extreme end of the GOP. Very pragmatic, organized, and level headed. I realize most of you readers aren’t very familiar with her, but as a local constituent she’s a strong choice, known for teaming up with California, New Mexico, and the great nation of Texas to work on plugging some of the federal failures in managing border security. The only loser is Arizona- our Secretary of State will be taking over, switching the state government to single party control with a governor who isn’t really known as a strong leader. Hopefully she’ll rise to the occasion. It’s always an open question how much even the president and cabinet-level positions can change the bureaucracy of our government, but I have high expectations that some of the silliness we’ve seen in DHS- from FEMA to TSA- will slowly be weeded out of the system. As for cybersecurity, it’s still a big question mark. She has experience with border security, law enforcement, and disaster management, but I haven’t noticed IT security to be the biggest priority here in AZ. Can’t win them all… Share:

Happy Monday everyone. This year I broke with tradition and actually ventured outside of the house of Black Friday. We didn’t see too many deals, but I did manage to grab a new rolling tool chest for the garage. That was before I heard about the disgusting hoard of lowlifes that killed some poor temp worker in Long Island because he had the gall to stand between them and a plasma TV at Wal-Mart. That incident represents everything that can go wrong with a capitalist society, and this is the last year I’ll be feeding the beast with any Black Friday purchases. Sorry, that really got to me this weekend. Back to cybersecurity… A friend of Any the IT Guy’s is facing a bit of a problem at work. They are replacing their PC infrastructure and are looking at building out new workstation images with a full load of security tools. One they are looking at are asset recovery/phone home tools. You know, the ones that will register their location (as best they can) if someone loses one or it’s stolen and connected to the Internet again. No surprise, I’m not the biggest fan of these tools. Andy raises a series of questions about them: 1. Just how many systems do actually go missing every year? 2. Are they really missing or are they just not being tracked properly as they are moved, replaced, etc? 3. How many systems can they afford to lose per year before they actually see any real value in this program? 4. Can they replace any other applications with this software? Asset tracking, System Monitoring, etc 5. How much of an investment in infrastructure and personnel resources will be required to manage this program. I prefer to use a simple algorithm to measure their value: IF (cost of tool < ((average number laptops recovered/laptops lost) X (average value of laptop X average number laptops lost))) THEN tool != crap Now the tool in question also sounds like a regular asset management tool that also manages software deployments, inventory, and so on. But if this feature costs extra, or you are looking at a dedicated tool, hit the vendor up with my little algorithm to measure value. Share:

‘Did you buy one of the deeply discounted Plasma Televisions this weekend? How about a new digital camera? How about eBay? No, not something being sold there, but the company itself. Chris O’Brien over at the San Jose Merc speculates on what it would take to buy the auction site as there have been some rumors floating around on this subject, and indirectly points out why cash is king. Meanwhile while the London times claims Microsoft was doing a little Black Friday shopping of it’s own, another rumor that probably will not die until it is no longer a rumor. What the heck, take half off and let the Holiday rush begin! Share:

‘This Sunday’s Arizona Republic picked up Brian Krebs article in the Washington Post about thieves tapping into home equity lines of credit. This is a very interesting, and just because their are people out there who actually still have home equity, but that this is a very simple con with potentially devastating affect. One of which is there was no data theft here, rather the information was mined legally. Second is that when the bank falls for the con, since they believe it was the borrower who made the withdrawal, the borrower has to detect the fraud and provide some form of evidence that it was not they that made the withdrawal. After I read this story, I went out to see what data was available to see if this was possible. Despite a wife who uses this information on a daily basis to perform her job, I was still surprised. The amount and quality of information that is held in public databases, readily accessible to anyone who cares to view it is pretty amazing. If you are not aware of it, when you buy a home, pretty much every piece of information regarding that transaction is logged by the county recorder and placed in the public domain. If you are a homeowner, go out to your county recorders web site and search for the data; your name, address, signature, lender, the amount, possibly the interest rate and a lot of other information as well. Seriously, take a minute and check it out; I think you will be startled as to what you find. Stars, celebrities, politicians along with everyone else. In this particular case there was no data theft theft component in this particular case, rather it was simple and legal data mining for ID theft. They probably were able to cross reference those people who looked like they may have assets with a credit score, and voila, instant target list. A lot of people have had their HELOC, or Home Equity Line of Credit yanked from their banks recently, some amid remodeling projects. Part of the issue is the Banks trying to reduce their exposure on people who are living off their credit lines, but another is this type of fraud. Banks and financial institutions have long had the problem of ‘how do I know its really you’, and thieves often know in advance what the banks ask for in the way of authentication, and either have that information, or a suitable excuse. Had the group in this specific case not been so greedy and tied to move such a large sum of money, I am not sure they would have been caught. And since the perpetrator is able to mask their identity and location, it’s up to the bank’s representative to have enough savvy to not fall for the con. And in that event, it’s trouble for both the lender and hassle for the borrower, so check your statements as this could happen to pretty much anyone. Share: