Research

By the time I post this you won’t be able to find a tech news site that isn’t covering this one. I know, since my name was on the list of analysts the press could contact and I spent a few hours talking to everyone covering the story yesterday. Rather than just reciting the press release, I’d like to add some analysis, put things into context, and speculate wildly. For the record, this is a big deal in the long term, and will likely benefit all of the major DLP vendors, even though there’s nothing earth shattering in the short term. As you read this, Microsoft and RSA are announcing a partnership for Data Loss Prevention. Here are the nitty gritty details, not all of which will be apparent from the press release: This month, the RSA DLP product (Tablus for you old folks) will be able to assign Microsoft RMS (what Microsoft calls DRM) rights to stored data based on content discovery. The way this works is that the RMS administrator will define a data protection template (what rights are assigned to what users). The RSA DLP administrator then creates a content detection policy, which can then apply the RMS rights automatically based on the content of files. The RSA DLP solution will then scan file repositories (including endpoints) and apply the RMS rights/controls to protect the content. Microsoft has licensed the RSA DLP technology to embed into various Microsoft products. They aren’t offering much detail at this time, nor any timelines, but we do know a few specifics. Microsoft will slowly begin adding the RSA DLP content analysis engine to various products. The non-NDA slides hint at everything from SQL Server, Exchange, and Sharepoint, to Windows and Office. Microsoft will also include basic DLP management into their other management tools. Policies will work across both Microsoft and RSA in the future as the products evolve. Microsoft will be limiting itself to their environment, with RSA as the upgrade path for fuller DLP coverage. And that’s it for now. RSA DLP 6.5 will link into RMS, with Microsoft licensing the technology for future use in their products. Now for the analysis: This is an extremely significant development in the long term future of DLP. Actually, it’s a nail in the coffin of the term “DLP” and moves us clearly and directly to what we call “CMP”- Content Monitoring and Protection. It moves us closer and closer to the DLP engine being available everywhere (and somewhat commoditized), and the real value in being in the central policy management, analysis, workflow, and incident management system. DLP/CMP vendors don’t go away- but their focus changes as the agent technology is built more broadly into the IT infrastructure (this definitely won’t be limited to just Microsoft). It’s not very exciting in the short term. RSA isn’t the first to plug DLP into RMS (Workshare does it, but they aren’t nearly as big in the DLP market). RSA is only enabling this for content discovery (data at rest) and rights won’t be applied immediately as files are created/saved. It’s really the next stages of this that are interesting. This is good for all the major DLP vendors, although a bit better for RSA. It’s big validation for the DLP/CMP market, and since Microsoft is licensing the technology to embed, it’s reasonable to assume that down the road it may be accessible to other DLP vendors (be aware- that’s major speculation on my part). This partnership also highlights the tight relationship between DLP/CMP and identity management. Most of the DLP vendors plug into Microsoft Active Directory to determine users/groups/roles for the application of content protection policies. One of the biggest obstacles to a successful DLP deployment can be a poor directory infrastructure. If you don’t know what users have what roles, it’s awfully hard to create content-based policies that are enforced based on users and roles. We don’t know how much cash is involved, but financially this is likely good for RSA (the licensing part). I don’t expect it to overly impact sales in the short term, and the other major DLP vendors shouldn’t be too worried for now. DLP deals will still be competitive based on the capabilities of current products, more than what’s coming in an indeterminate future. Now just imagine a world where you run a query on a SQL database, and any sensitive results are appropriately protected as you place them into an Excel spreadsheet. You then drop that spreadsheet into a Powerpoint presentation and email it to the sales team. It’s still quietly protected, and when one sales guy tries to email it to his Gmail account, it’s blocked. When he transfers it to a USB device, it’s encrypted using a company key so he can’t put it on his home computer. If he accidentally sends it to someone in the call center, they can’t read it. In the final PDF, he can’t cut out the table and put it in another document. That’s where we are headed- DLP/CMP is enmeshed into the background, protecting content through it’s lifecycle based on central policies and content and context awareness. In summary, it’s great in the long term, good but not exciting in the short term, and beneficial to the entire DLP market, with a slight edge for RSA. There are a ton of open questions and issues, and we’ll be watching and analyzing this one for a while. As always, feel free to email me if you have any questions. Share:

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:

Hard to believe we’ve been around to post this yet a third time, but here you go. Our list of advice for shopping safely online this year; and we even updated it this time: Yes folks, Black Friday is only days away and the silly season is upon us. As someone born and bred in good old North Jersey (until I could legally escape), land of honey and shopping malls, this is a time so deeply ingrained into my subconscious that I’ve occasionally found myself sleepwalking around the nearest parking lot, looking for our old wood-paneled station wagon. These days, thanks to the wonder of the Internet, anyone can experience the hustle and bustle of the Paramus malls from the comfort of their own home. And to help keep your shopping experience authentic, there’s no shortage of cheats and thieves ready to yank your painstakingly chosen gifts right out of the virtual trunk of your web browser. Of course they might take your house with them, which, even in Jersey (despite the legends) is somewhat rare. In the spirit of safe and happy holidays, Securosis presents our top 6 tips for safe online shopping, simply presented for the technical or non-technical consumer. Some of these tips also apply to the real world for those of you who just can’t restrain the draw to the mall. Spread the fun, and feel free to post your own tips in the comments. Use a dedicated credit card, temporary credit card number, or PayPal account for holiday shopping. Our first tip is also useful for the physical world- still the origin of most credit card fraud. Take your card with the lowest limit and use it exclusively for holiday shopping. Use one you can monitor online, and check the activity daily through the holidays (weekly at a minimum). Make sure it isn’t a debit card, and turn off any automatic payments (so you can dispute any charges before making payments). Keep tracking activity at least weekly for 12 months after the holidays are over, or cancel the card. DON”T USE A DEBIT CARD!!! These don’t have the same protections as credit cards, and you’re responsible for fraudulent charges. As for temporary credit cards or PayPal, read on to our second tip. Only use credit cards at major online retailers; use a PayPal debit account or temporary credit card for smaller shops . Sure, you might get a better deal from Billy-Bobs-Bait-Shop-And-Diamond-Wholesaler.com, but many smaller retailers don’t follow appropriate security practices. Those hosted with a major service are often okay, but few consumers really want to check the pedigree for specialty shops. Instead, create a dedicated PayPal account that’s not linked to any of your bank accounts or credit cards. Credit it with as much cash as you think you need and use it for those riskier online payments. Worst case, you only lose what’s in that account, and you can easily cancel it anytime. Another option, depending on your credit card company, is a temporary credit card number for online shopping. These are single use, or single retailer/session numbers that can’t be used again or leveraged to run up your account. Charges still appear on your same bill and are tied to your main credit card account. Check with your credit card company to see if they offer this service, but most of the major card issuers have it as an option. I like these better than account passwords (e.g. Verified by Visa and Mastercard SecureCode) since they work everywhere, and you don’t have to worry about anyone sniffing them. Never, ever, ever ,ever click on ANYTHING in email. It doesn’t matter if your best friend sent you a really good deal in email. It doesn’t matter if it’s your favorite retailer and you’ve always gotten email offers from them. Repeat after me, “I will never click on anything in email.” No special offers. No Ebay member to member emails. No “fraud alerts” to check your account. No nothing. Ever. Nada. Attackers are getting more and more refined in their attacks, some of which are very hard to distinguish from legitimate emails. Spam waves over the holidays are expected to break records this year. When you see an interesting offer in email, and it’s a business you want to deal with, just open your web browser, type in the address manually, and browse to the item, offer, or account area. Email is the single biggest source of online fraud; never click on anything in email! Update your browser- use Firefox 3.1, IE 7 or 8, Safari 3.2.1, or Opera 9.6. Turn on the highest security settings. Over the past few months or so we’ve seen big updates of all the major browsers to include enhanced security features. Since the Safari update last week, all major browsers include features to help detect fraudulent sites- if you see a warning, shut down the browser and don’t go back to that site. All of these browsers will ask you before installing any software when you visit a site; when shopping, never allow the site to install anything. Either it’s a fraud or they don’t deserve your business. Pay particular attention to plugins to watch video, or free games unless you know it’s a trusted site (both are usually trojans). Most browsers now install with security enabled by default, so we won’t be providing detailed instructions here. Just download them. Now. Then come back and read the rest of this list. We’ll wait. Download and install NoScript for Firefox. This is a free plugin for Firefox that blocks anything from running in your browser that you don’t allow (like Javascript, Flash, and so on). You won’t need it if you just stick with Amazon, but if you use Google to help you find that can’t-miss Drink-With-Me Elmo, you shouldn’t be trolling the Internet without it. If you don’t want it bothering you all the time, at least use it during your holiday shopping and turn it off later.