Research

Building security in? Bolting it on? If you develop in-house applications, it’s likely both. Application security will be a key theme of the show. But the preponderance of application security tools will block, scan, mask, shield, ‘reperimeterize’, reconfigure, or reset connections from the outside. Bolt-on is the dominant application security model for the foreseeable future. The good news is that you may not be the one managing it, as there is a whole bunch of new cloud security services and technologies available. Security as a service, anyone? Here’s what we expect to see at this year’s RSA Conference. SECaaS Security as a Service, or ‘SECaaS’; basically using ‘the cloud’ to deliver security services. No, it’s not a new concept, but a new label to capture the new variations on this theme. What’s new is that some of the new services are not just SaaS, but delivered for PaaS or IaaS protection as well. And the technologies have progressed well beyond anti-spam and web-site scanning. During the show you will see a lot of ‘cloudwashing’ – where the vendor replaces ‘network’ with ‘cloud’ in their marketing collateral, and suddenly they are a cloud provider – which makes it tough to know who’s legit. Fortunately at the show you will see several vendors who genuinely redesigned products to be delivered as a service from the cloud and/or into cloud environments. Offerings like web application firewalls available from IaaS vendors, code scanning in the cloud, DNS redirectors for web app request and content scanning, and threat intelligence based signature generation, just to name a few. The new cloud service models offers greater simplicity as well as cost reduction, so we are betting these new services will be popular with customers. They’ll certainly be a hit on the show floor. Securing Applications at Scale Large enterprises and governments trying to secure thousands of off-the-shelf and homegrown applications live with this problem every day. Limited resources are the key issue – it’s a bit like weathering a poop storm with a paper hat. Not enough protection and the limited resources you have are not suitable for the job. It’s hard to be sympathetic as most of these organizations created their own headaches – remember when you thought it was a good idea to put a web interface on those legacy applications? Yeah, that’s what I’m talking about. Now you have billions of lines of code, designed to be buried deep within your private token ring, providing content to people outside your company. Part of the reason application security moves at a snail’s pace is because of the sheer scope of the problem. It’s not that companies don’t know their applications – especially web applications – are not secure, but the time and money required to address all the problems are overwhelming. A continuing theme we are seeing is how to deal with application security at scale. It’s both an admission that we’re not fixing everything, and an examination of how to best utilize resources to secure applications. Risk analysis, identifying cross-domain threats, encapsulation, reperimetrization, and multi-dimensional prioritization of bug fixes are all strategies. There’s no embodying product that you’ll see at the show, but we suggest this as a topic of discussion when you chat with folks. Many vendors will be talking about the problem and how their product fits within a specific strategic approach for addressing the issue. Code Analysis? Meh. DAST? Yeah. The merits of ‘building security in’ are widely touted but adoption remains sporadic. Awareness, the scale of the issue, and cultural impediments all keep tools that help build secure code a small portion of the overall application security market. Regardless, we expect to hear lots of talk about code analysis and white box testing. These products offer genuine value and several major firms made significant investments in the technology last year. While the hype will be in favor of white box code analysis, the development community remains divided. No one is arguing the value of white box testing, but adoption is slower than we expected. Very large software development firms with lots of money implement a little of each secure code development technique in their arsenal, including white box as a core element, basically because they can. The rest of the market? Not so much. Small firms focus on one or two areas during the design, development, or testing phase. Maybe. And that usually means fuzzing and Dynamic Application Security Testing (DAST). Whether it’s developer culture, or mindset, or how security integrates with development tools, or this is just the way customers want to solve security issues – the preference is for semi-black-box web scanning products. Big Data, Little App Security You’re going to hear a lot about big data and big data security issues at the conference. Big Data definitely needs to be on the buzzword bingo card. And 99 out of 100 vendors who tell you they have a big data security solution are lying. The market is still determining what the realistic threats are and how to combat them. But we know application security will be a bolt-on affair for a long period, because: Big data application development has huge support and is growing rapidly A vanishingly low percentage of developer resources are going into designing secure applications for big data. SQL injection, command injection, and XSS are commonly found on most of the front-end platforms that support NoSQL development. Some of them did not even have legitimate access controls until recently! Yes, jump into your time machine and set the clock for 10 years ago. Make no mistake – firms are pumping huge amounts of data into production non-relational databases without much more than firewalls and SSL protecting them. So if you have some architects playing around with these technologies (and you do), work on identifying some alternatives to secure them at the show. Share:

As you can tell from my TidBITS review of Gatekeeper, I think this is an important advancement in consumer security. There are a lot of in-depth technical aspects that didn’t fit in that article, so here’s an additional Q&A for those of you with a security background who care about these sorts of things. I’m skipping the content from the TidBITS article, so you might want to read that first. Will Gatekeeper really make a difference? I think so. Right now the majority of the small population of malware we see for Macs is downloaded trojans and tools like Mac Defender that download through the browser. While there are plenty of ways to circumvent Gatekeeper, most of them are the sorts of things that will raise even uneducated users’ hackles. Gatekeeper attacks the economics of widespread malware. It conveys herd immunity. If most users use it (and as the default, that’s extremely likely) it will hammers on the profitability of phishing-based trojans. To attackers going after individual users, Gatekeeper is barely a speed bump. But in terms of the entire malware ecosystem, it’s much more effective – more like tire-slashing spikes. How does Gatekeeper work? Gatekeeper is an extension of the quarantine features first implemented in Mac OS X 10.5. When you download files using certain applications a “quarantine bit” is set (more on that in a second). In OS X 10.5-10.7 when you open a file Launch Services looks for that attribute. If it’s set, it informs the user that the program was downloaded from the Internet and asks if they still want to run it. Users click through everything, so that doesn’t accomplish much. In 10.6 and 10.7 it also checks the file for any malware before running, using a short list that Apple now updates daily (as needed). If malware is detected it won’t let you open the file. If the application was code signed, the file’s digital certificate is also checked and used to validate integrity. This prevents tampered applications from running. In Mac OS X 10.8 (Mountain Lion), Gatekeeper runs all those checks and validates the source of the download. I believe this is done using digital certificates, rather than another extended attribute. If the file is from an approved source (the Mac App Store or a recognized Developer ID) then it’s allowed to run. Gatekeeper also checks developer certificates against a blacklist. So here is the list of checks: Is the quarantine attribute set? Is the file from an approved source (per the user’s settings)? Is the digital certificate on the blacklist? Has the signed application been tampered with? Does the application contain a known malware signature? If it passes those checks, it can run. What is the quarantine bit? The quarantine bit is an extended file attribute set by certain applications on downloaded files. Launch Services checks it when running an application. When you approve an application (first launch) the attribute is removed, so you are never bothered again for that version. This is why some application updates trigger quarantine and others don’t… the bit is set by the downloading application, not the operating system. What applications set the quarantine bit? Most Apple applications, like Safari, Firefox, Mail.app, and a really big list in /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist. Plus any applications where developers implement it as part of their download features. In other words, most things a consumer will use to download files off the Internet. But the clearly they won’t catch everything, so there are still applications that can download and avoid Gatekeeper. System utilities like curl, aren’t protected. What apps aren’t protected? Anything already on your system is grandfathered in. Files transferred or installed using fixed media like DVDs, USB drives, and other portable media. Files downloaded by applications that don’t set the quarantine bit. Scripts and other code that isn’t executable. So will this protect me from Flash and Java malware? Nope. Although they are somewhat sandboxed in browsers (which varies widely by browser), applets and other code run just fine in their container, and aren’t affected or protected. Now we just need Adobe to sandbox Flash like they did on Windows. What is the Developer ID? This is a new digital certificate issued by Apple for code signing. It is integrated into XCode. Any developer in the Mac App Developer Program can obtain one for free. Apple does not review apps signed with a Developer ID, but if they find a developer doing things they shouldn’t they can revoke that certificate. These are signed by an Apple subroot that is separate from the Mac App Store subroot. How are Developer ID certificates revoked? Mountain Lion includes a blacklist that Apple updates every 24 hours. If a malicious application is found and Apple revokes the certificate, will it still run? Yes, if it has already run once and had the quarantine bit cleared. Apple does not remove the app from your system, although they said they can use Software Update to clean any widespread malware as they did with Mac Defender. What about a malicious application in the Mac App Store? Apple will remove the application from the app store. This does not remove it from your system, and it would also need to be cleaned with a software update. If we start seeing a lot of this kind of problems, I expect this mechanism to change. Does this mean all Mac applications require code signing? No, but code signing is required for all App Store and Developer ID applications. Starting in Lion, Apple includes extensive support for code signing and sandboxing. Developers can break out and sign different components of their applications and implement pretty robust sandboxing. While I expect most developers to stick with basic signing, the tools are there for building some pretty robust applications (as they are on Windows – Microsoft is pretty solid here as well, although few developers take advantage of it). What role does sandboxing play? All Mac App Store applications must implement sandboxing by March 1st, long before Mountain Lion is released. Sandbox entitlements are

I managed to take a couple days off last week, and got out of town. I went camping with a group of friends, all from very different backgrounds, with totally unrelated day jobs – but we all love camping in the desert. Whenever we’re BSing by the camp fire, they ask me about current events in security. There’s almost always a current data breach, ‘Anonymous’ attack, or whatever. This group is decidedly non-technical and does not closely follow the events I do. This trip the question on their minds was “What ‘s the big deal with SOPA?” Staying away from the hyperbole and accusations on both sides, I explained that the bill would have given content creators the ability to shut down web sites without due process if they suspected they hosted or distributed pirated content. I went into some of the background around issues of content piracy; sharing of intellectual property; and how digital media, rights management, and parody make the entire discussion even more cloudy. I was surprised that this group – on average a decade older than myself – reacted more negatively to SOPA than I did. One of them had heard about the campaign contributions and was pissed. “Politicians on the take, acting on behalf of greedy corporations!” was the general sentiment. “My sons share music with me all the time – and I am always both happy and surprised when they take an interest in my music, and buy songs from iTunes after hearing it at my place.” And, “Who the hell pirates movies when you can stream them from Netflix for a couple bucks a month?” I love getting non-security people’s reactions to security events. It was a very striking reaction from a group I would not have expected to get all that riled up about it. The response to SOPA has been interesting because it crosses political and generational lines. And I find it incredibly ironic that the first thing both sides state is that they are against piracy – but they cannot agree what constitutes piracy vs. fair use. One of my favorite slogans from the whole SOPA debate was It’s No Longer OK To Not Know How The Internet Works, accusing the backers of the legislation of being completely ignorant of a pervasive technology that has already changed the lives of most people. And even people who I do not consider technically sophisticated seem to “get it”, and we saw wit the ground-swell of support. I am willing to bet that continuing advances in technology will make it harder and harder for organizations like the RIAA to harass their customers. Maybe invest some of that money in a new business model? I know, that’s crazy talk! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s OWASP presentation is live. Adrian’s Dark Reading post on The Financial Industry’s Effect On Database Security. Rich’s TidBITS posts: Mac OS X 10.8 Mountain Lion Stalks iOS & Gatekeeper Slams the Door on Mac Malware Epidemics. Favorite Securosis Posts Mike Rothman: RSAG 2012: Application Security. Love Adrian’s summary of what you’ll see at the RSA Conference around AppSec. Especially since we get to see SECaaS in print. Adrian Lane: OS X 10.8 Gatekeeper in Depth. Real. Practical. Security. Other Securosis Posts RSA Conference 2012 Guide: Key Themes. RSA Conference 2012 Guide: Network Security. Incite 2/15/2012: Brushfire. Friday Summary: February 10, 2012. [New White Paper] Network-Based Malware Detection: Filling the Gaps of AV. Implementing and Managing a Data Loss Prevention (DLP) Solution: Index of Posts. Implementing DLP: Starting Your Integration. Implementing DLP: Deploying Network DLP. Implementing DLP: Deploying Storage and Endpoint. Favorite Outside Posts Mike Rothman: The Sad and Ironic Competition Within the Draft “Expert” Community. Whether you are a football fan or not, read this post and tell me there aren’t similarities in every industry. There are experts, and more who think they are experts, and then lots of other jackasses who think breaking folks down is the best way to make themselves look good. They are wrong… Adrian Lane: Printing Drones. I can think of several good uses – and a couple dozen evil ones – for something like this. Control and power will be a bit tricky, but the potential for amusement is staggering! Project Quant Posts Malware Analysis Quant: Metrics – Build Testbed. Malware Analysis Quant: Metrics – Confirm Infection. Malware Analysis Quant: Monitoring for Reinfection. Malware Analysis Quant: Remediate. Malware Analysis Quant: Find Infected Devices. Malware Analysis Quant: Defining Rules. Malware Analysis Quant: The Malware Profile. Research Reports and Presentations Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Applied Network Security Analysis: Moving from Data to Information. Tokenization Guidance. Security Management 2.0: Time to Replace Your SIEM? Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Tokenization vs. Encryption: Options for Compliance. Top News and Posts Flash Player Security Update via Krebs, and a Java Security Update. Gatekeeper for Mountain Lion. Vote for Web Hacking Top Ten. No so random numbers lead to bad keys? Who Knew? Paget Demo’s Wireless Credit Card Theft. Carrier IQ Concerns. Blog Comment of the Week No comments this week. Starting to think our comments feature is broken. Oh, wait, it is! Share:

Storage deployment From a technical perspective, deploying storage DLP is even easier than the most basic network DLP. You can simply point it at an open file share, load up the proper access rights, and start analyzing. The problem most people run into is figuring out which servers to target, which access rights to use, and whether the network and storage repository can handle the overhead. Remote scanning All storage DLP solutions support remotely scanning a repository by connecting to an open file share. To run they need to connect (at least administrator-only) to a share on the server scan. But straightforward or not, there are three issues people commonly encounter: Sometimes it’s difficult to figure out where all the servers are and what file shares are exposed. To resolve this you can use a variety of network scanning tools if you don’t have a good inventory to start. After you find the repositories you need to gain access rights. And those rights need to be privileged enough to view all files on the server. This is a business process issue, not a technical problem, but most organizations need to do a little legwork to track down at least a few server owners. Depending on your network architecture you may need to position DLP servers closer to the file repositories. This is very similar to a hierarchical network deployment but we are positioning closer to the storage to reduce network impact or work around internal network restrictions (not that everyone segregates their internal network, even though that single security step is one of the most powerful tools in our arsenal). For very large repositories which you don’t want to install a server agent on, you might even need to connect the DLP server to the same switch. We have even heard of organizations adding a second network interfaces on a private segment network to support particularly intense scanning. All of this is configured in the DLP management console; where you configure the servers to scan, enter the credentials, assign policies, and determine scan frequency and schedule. Server agents Server agents support higher performance without network impact, because the analysis is done right on the storage repository, with only results pushed back to the DLP server. This assumes you can install the agent and the server has the processing power and memory to support the analysis. Some agents also provide additional context you can’t get from remote scanning. Installing the server agent is no more difficult than installing any other software, but as we have mentioned (multiple times) you need to make sure you test to understand compatibility and performance impact. Then you configure the agent to connect to the production DLP server. Unless you run into connection issues due to your network architecture, you then move over to the DLP management console to tune the configuration. The main things to set are scan frequency, policies, and performance throttles. Agents rarely run all the time – you choose a schedule, similar to antivirus, to reduce overhead and scan during slower hours. Depending on the product, some agents require a constant connection to the DLP server. They may compress data and send it to the server for analysis rather than checking everything locally. This is very product-specific, so work with your vendor to figure out which option works best for you – especially if their server agent’s internal analysis capabilities are limited compared to the DLP server’s. As an example, some document and database matching policies impose high memory requirements which are infeasible on a storage server, but may be acceptable on the shiny new DLP server. Document management system/NAS integration Certain document management systems and Network Attached Storage products expose plugin architectures or other mechanisms that allow the DLP tool to connect directly, rather than relying on an open file share. This method may provide additional context and information, as with a server agent. This is extremely dependent on which products you use, so we can’t provide much guidance beyond “do what the manual says”. Database scanning If your product supports database scanning you will usually make a connection to the database using an ODBC agent and then configure what to scan. As with storage DLP, deployment of database DLP may require extensive business process work: to find the servers, get permission, and obtain credentials. Once you start scanning, it is extremely unlikely you will be able to scan all database records. DLP tools tend to focus on scanning the table structure and table names to pick out high-risk areas such as credit card fields, and then they scan a certain number of rows to see what kind of data is in the fields. So the process becomes: Identify the target database. Obtain credentials and make an ODBC connection. Scan attribute names (field/column names). (Optional) Define which fields to scan/monitor. Analyze the first n rows of identified fields. We only scan a certain number of rows because the focus isn’t on comprehensive realtime monitoring – that’s what Database Activity Monitoring is for – and to avoid unacceptable performance impact. But scanning a small number of rows should be enough to identify which tables hold sensitive data, which is hard to do manually. Endpoint deployment Endpoints are, by far, the most variable component of Data Loss Prevention. There are massive differences between the various products on the market, and far more performance constraints required to fit on general-purpose workstations and laptops, rather than on dedicated servers. Fortunately, as widely as the features and functions vary, the deployment process is consistent. Test, then test more: I realize I have told you to test your endpoint agents at least 3 times by now, but this is the single most common problem people encounter. If you haven’t already, make sure you test your agents on a variety of real-world systems in your environment to make sure performance is acceptable. Create a deployment package or enable in your EPP tool: The best way to deploy the DLP agent is to use whatever software distribution

Yesterday we posted the key themes we expect to see at the upcoming RSA Conference. Now we’ll starting digging into our main coverage areas. Today we’ll start with network security. Firewalls are (still) dead! Long live the perimeter security gateway! Shockingly enough, similar to the past three years at RSAC, you’ll hear a lot about next generation firewalls (NGFW). And you should, as ports and protocol-based firewall rules will soon go the way of the dodo bird. If by soon, we mean 5+ years anyway, but corporate inertia remains a hard game to predict. The reality is that you need to start moving toward a deeper inspection of both ingress and egress traffic through your network, and the NGFW is the way to do that. The good news is that every (and we mean every) vendor in the network security space will be showing a NGFW at the show. Some are less NG than a bolted-on IPS to do the application layer inspection, but at the end of the day they can all claim to meet the NGFW market requirements, as defined by the name-brand analysts anyway. Which basically means these devices are less firewalls and more perimeter security gateways. So we will see two general positioning tactics from the vendors: Firewall-centric vendors: These folks will pull a full frontal assault on the IPS business. They’ll talk about how there is no reason to have a stand-alone IPS anymore and that the NGFW now does everything the IPS does and more. The real question for you is whether you are ready for the forklift that moving to a consolidated perimeter security platform requires. IPS vendors: IPS vendors have to protect their existing revenue streams, so they will be talking about how the NGFW is the ultimate goal, but it’s more about how you get there. They’ll be talking about migration and co-existence and all those other good things that made customers feel good about dropping a million bucks on an IPS 18 months ago. But no one will be talking about how the IPS or yesterday’s ports & protocols firewall remains the cornerstone of the perimeter security strategy. That sacred cow is slain, so now it’s more about how you get there. Which means you’ll be hearing a different tune from many of the UTM vendors. Those same brand-name analysts always dictated that UTM only met small company needs and didn’t have a place in an enterprise network. Of course that wasn’t exactly true but the UTM vendors have stopped fighting it. Now they just magically call their UTM a NGFW. It actually makes sense (from their perspective) as they understand that an application-aware firewall is just a traditional firewall with an IPS bolted on for application classification. Is that a ‘NGFW’? No, because it still runs on firewall blocking rules based on ports and protocols (as opposed to applications), but it’s not like RSA attendees (or most mid-market customers) are going to really know the difference. Control (or lack thereof) Another batch of hyperbole you’ll hear at the conference is about control. This actually plays into a deeply felt desire on the part of all security professionals, who don’t really control much of anything on a daily basis. So you want to buy devices that provide control over your environment. But this is really just a different way of pushing you towards the NGFW, to gain ‘control’ over the applications your dimwit end users run. But control tends to put the cart ahead of the horse. The greatest impact of the NGFW is not in setting application-aware policies. Not at first. The first huge value of a NGFW is gaining visibility over what is going on in your environment. Basically, you probably have no idea what apps are being used by whom and when. The NGFW will show you that, and then (only then) are you in a position to start trying to control your environment through application-centric policies. While you are checking out the show floor remember that embracing application-awareness on your perimeter is about more than just controlling the traffic. It all starts with figuring out what is really happening on your network. Network-based Malware Detection gains momentum Traditional endpoint AV doesn’t work. That public service message has been brought to you by your friend Captain Obvious. But even though blacklists and signatures don’t work anymore, there are certain indicators of malware that can be tracked. Unfortunately that requires you to actually execute the malware to see what it does. Basically it’s a sandbox. It’s not really efficient to put a sandbox on every endpoint (though the endpoint protection vendors will try), so this capability is moving to the perimeter. Thus a hot category you’ll see at RSA is “network-based malware detection” gear. These devices sit on the perimeter and watch all the files passing through to figure out which of them look bad and then either alert or block. They also track command and control traffic on egress links to see which devices have already been compromised and trigger your incident response process. Of course these monitors aren’t a panacea for catching all malware entering your network, but you can stop the low hanging fruit before it makes its way onto your network. There are two main approaches to NBMD, which are described ad nauseum in our recently published paper, so we won’t get into that here. But suffice it to say, we believe this technology is important and until it gets fully integrated into the perimeter security gateway, it’s a class of device you should be checking out while you are at the show. Big security flexes its muscle Another major theme related to network security we expect to see at the show is Big Security flexing its muscles. Given the need for highly specialized chips to do application-aware traffic inspection, and the need to see a ton of traffic to do this network-based malware detection and reputation analysis, network security is no longer really a place for start-ups (and no, Palo Alto is no

I had this fraternity brother back in college named Lucas. We gave him a pretty hard time, mostly because he was the nicest guy you’d ever want to meet. Turns out he didn’t know what jobs just sucked. We’d ask Luke to clean the grease trap, a typical task when we were pledges. Not a problem for him, and that was probably the nicest thing we asked him to do. Remember that when you live in a house with 40+ guys, you tend to share a lot of things. Get your heads out of the gutter. I’m talking about things like toiletries. It wouldn’t be a surprise to see your brand new shampoo bottle in the gang shower 80% gone. Nor should it have surprised anyone to find their toothpaste ravaged by the cheap slugs I lived with. I always figured it was a decent investment because most of these guys wouldn’t have brushed their teeth at all, if it weren’t for my toothpaste. But Luke would have none of that. He went berserk one day when he found his toothpaste mostly gone. He proceeeded to write his name on everything he owned, as if that would make a difference. He was ranting and raving. Of course, once we knew that bothered him, we hit the gas. We’d still take his toothpaste, but we’d put it back in his room – empty. We’d hide his stuff all over the house. Come on, you would have done the same thing when you were 20. But slowly I’ve become Luke in terms to my stuff. I live with 4 other people and they are constantly using my stuff. I know when the Boss has been in my toothpaste because she squeezes from the top, not the bottom like I do. Yeah, that annoys me, so I put a new tube in her drawer, hoping she won’t screw with mine. But it’s the brush that really annoys me. I know instantly when one of the girls has polluted my brush. There are all sorts of long hairs tickling my ears when I brush my hair. So I peek at my brush and sure enough there is a ton of long brown hair in my brush. My hair is short and gray – I know it’s not mine. I don’t know why, but it annoys me. In a fit of rage, I did consider lighting the brush on fire, as that seemed like the only way I could ever keep everyone else from using it. Now that would be a cool brushfire. So I did what any person does when annoyed. I bought about 10 other brushes. I put extra brushes in each girl’s room and a few downstairs. Just in case. But amazingly enough, even with the extra brush inventory, half the time we can’t find a brush when we need it. There must be some kind of gremlin with long hair in the house who keeps taking our brushes. So time and time again, they go to the only place where they can be absolutely sure there is always a brush in the house. Right, my drawer. Either that, or maybe they are just screwing with me, because they know finding hair in my brush annoys me. I annoy them enough that I probably deserve to be messed with a bit. I guess karma balances out in the long run. But who could have guessed it would be in the form of a brush? -Mike Photo credits: “Hairy Brush” originally uploaded by Ashley Coombs Heavy Research After a bit of a blogging hiatus, we are back at it. The Heavy Research feed is hopping, and here are a couple of links of our latest stuff. So check them out and (as always) let us know what you think via comments. We posted a new paper earlier this week, assembling the Network-based Malware Detection series into a spiffy document. Check it out. And we have started posting our annual RSA Conference Guide. The first post was on our Key Themes. It seems over the past year we haven’t lost our snark, so our themes include stuff like “Is that a Cloud in Your Pocket?” “#OccupyRSA,” “Ha-Duped about Security BigData,” and “Data Olestra.” Yes, we insist on having fun if we have to write. We’ll be doing 1-2 a day over the next week, and then we’ll package it up as a paper you can take with you to the conference. Here’s the other stuff we have been up to: Implementing and Managing a Data Loss (DLP) System: Index of Posts. Rich is still at it, so check out his latest on deploying DLP. Malware Analysis Quant: Take the Survey (and win fancy prizes!) We need your help to understand what you do (and what you don’t) for malware analysis. And you can win some nice gift cards from Amazon for your trouble. Remember, you can get our Heavy Feed via RSS, where you can access all our content in its unabridged glory. Incite 4 U Behold the Nortel ostrich: Great expose in the WSJ about Nortel being totally and utterly compromised for over a decade. Seems there was no part of their infrastructure that the attackers didn’t have access to. But that’s kind of an old, tired story. What’s more interesting is the reaction from former Nortel folks. As the carcass of what used to be Nortel has been auctioned off from bankruptcy, the folks acquiring the assets play stupid. The old CEOs play stupid. And then they mention one of the main forensics guys would cry wolf. But he wasn’t crying wolf, was he? But this is the kind of institutional disregard we, alas, expect to see. It’s not like Nortel had anything interesting to state-sponsored hackers, right? Like the signaling software that runs a huge fraction of the national voice networks. This is just a reminder: your organization is pwned. The question is whether you know it or not. Or want to know it, I guess. – MR Probing the unprobable: I have to admit that

It’s hard to believe, but we are two weeks out from the RSA Conference. As in previous years, your pals at Securosis have put together our 3rd annual RSA Guide, which we will distribute next week. But we will give you blog reading faithful, an early look at what we expect to see at the show. So let’s with the key themes… #OccupyRSA… It’s hard to believe, but the RSA breach was less than a year ago. Feels like forever, doesn’t it? At last year’s RSA Conference we heard a lot of marketing puffery about stopping the APT, and guess what? We’re in for another week of baseless claims and excessive FUD about targeted attacks, advanced malware, and how to detect state-sponsored attackers. As long as you remember that you can’t stop a targeted attack, and continue to focus on Reacting Faster and Better, you’ll have plenty to look at. Especially given that our conference hosts acquired the leading network forensics company (NetWitness) last spring. Just remember to laugh as you walk around the show floor in your Red Army uniform. But there is another return engagement we expect to witness at this year’s RSA: the Guy-Fawkes-mask-wearing crew from Anonymous. Though they have kept busy over the past year occupying every park in the nation, we figure they’ll make some kind of splash at RSA. If only because their boy Topiary’s trial is scheduled to start in May. Obviously it’ll be hard for them to top the grand entrance they made on the back of Aaron Barr and HBGary at last year’s conference, but we figure they’re up to something. Given the continuing rise of chaotic actors, and our inability to build a reasonable threat model against attackers who have no clear motive, it’ll be interesting to see them #OccupyRSA. Is That a Cloud in Your Pocket? Or are you just happy to see us? We’ve said it before and we’ll say it again – the overlapping rapid adoption of cloud computing and mobility make this the most exciting time to be in technology since the start of the Internet bubble. I find today far more interesting, because these two trends affect our lives more fundamentally than the early days of the Internet. Then again, avalanches, earthquakes, and someone pointing an assault rifle at your nose are also pretty exciting, but from a different perspective. Unlike the past two years, at this year’s conference we will see far more real cloud security solutions. Up until now most of what we’ve seen was marketecture or cloudwashing, but merely printing a pretty pamphlet or tossing your existing product into a virtual appliance doesn’t make a real cloud security tool. Of course we see plenty of make-believe, but we see the emergence of new and exciting tools designed from the ground up for cloud security. Our biggest problem is that we still need more people who understand practical cloud architectures, but most of the people I meet at security conferences are more interested in writing policy. Unless you know how this stuff works you won’t be able to tell which is which – it all looks good on paper. But here’s a hint – if it’s the same product name as an appliance on your network, odds are it’s an old product that’s been dipped in a bath of cloudy paint. And then there’s mobility. I can securely access every file I have on every computer through my phone or tablet, but for everyone like me there are dozens of less paranoid folks doing the same thing with no thought for protecting their data. IT lost the battle to fully control all devices entering the enterprise long ago, and combined with the current dramatic growth in local storage on laptops, even barely-technical users can snarf down all the storage they can choke down from the cloud. You’ll see consumerization and mobility themes at nearly every booth, even the food vendors, but for good reason. Everyone I know is forced to adapt to all those friggin’ iPhones and iPads coming in the door, as well as the occasional malware magnet (Android) and the very pretty, can’t-figure-out-why-she’s-being-ignored Windows Mobile. Ha-Duped about Security BigData Yep, it looks like security has gotten intelligence and business-style analysis religion. So you’ll see and hear a lot of BigData, massive databases, NoSQL, Hadoop, and service-based architectures that enable analysis of ginormous data stores to pinpoint attacks. And there is plenty of value in applying ‘BigData’ tactics to security analytics and management. But we clearly aren’t there yet. You will see a bunch of vendors talking about their new alerting engines taking advantage of these cool new data management tactics, but at the end of the day, it’s not how something gets done – it’s still what gets done. So a Hadoop-based backend is no more inherently helpful than that 10-year-old RDBMS-based SIEM you never got to work. You still have to know what to ask the data engine to get meaningful answers. Rather than being blinded by the shininess of the BigData backend focus on how to use the tool in practice. On how to set up the queries to alert on stuff that maybe you don’t know about. Unless the #OccupyRSA folks are sending you their attack plans ahead of time. Then you don’t have to worry… Data Olestra It’s supposed to be good for you. It’s in lots of the products you buy. Marketing documents advertise how you’ll stay slender while enjoying tasty goodness. It’s a miracle product and everyone uses it! Yep, I am talking about Olestra! The irony here is that the product actually makes you fatter. Worse, eat too much, and you’ll ‘leak’ like crazy in your pants. Yuck! Notice any similarities between that and IT products? We buy solutions that are supposed to keep us secure, but don’t. These products suck up all your budget and personnel resources. And the coup de grace is your boss – the person who gave you the budget to buy these security tools – has the deluded conviction that your data is secure. You’re leaking like

Deploying on the network is usually very straightforward – especially since much of the networking support is typically built into the DLP server. If you encounter complications they are generally: due to proxy integration incompatibilities, around integrating with a complex email infrastructure (e.g., multiple regions), or in highly distributed organizations with large numbers of network egress points. Passive sniffing Sniffing is the most basic network DLP monitoring option. There are two possible components involved: All full-suite DLP tools include network monitoring capabilities on the management server or appliance. Once you install it, connect it to a network SPAN or mirror port to monitor traffic. Since the DLP server can normally only monitor a single network gateway, various products also support hierarchical deployment, with dedicated network monitoring DLP servers or appliances deployed to other gateways. This may be a full DLP server with some features turned off, a DLP server for a remote location that pulls policies and pushes alerts back to a central management server, or a thinner appliance or software designed only to monitor traffic and send information back to the management server. Integration involves mapping network egress points and then installing the hardware on the monitoring ports. High-bandwidth connections may require a server or appliance cluster; or multiple servers/appliances, each monitoring a subset of the network (either IP ranges or port/protocol ranges). If you don’t have a SPAN or mirror port you’ll need to add a network tap. The DLP tool needs to see all egress traffic, so a normal connection to a switch or router is inadequate. In smaller deployments you can also deploy DLP inline (bridge mode), and keep it in monitoring mode (passthrough and fail open). Even if your plan is to block, we recommend starting with passive monitoring. Email Email integrates a little differently because the SMTP protocol is asynchronous. Most DLP tools include a built-in Mail Transport Agent (MTA). To integrate email monitoring you enable the feature in the product, then add it into the chain of MTAs that route SMTP traffic out of your network. Alternatively, you might be able to integrate DLP analysis directly into your email security gateway, if your vendors have a partnership. You will generally want to add your DLP tool as the next hop after your email server. If you also use an email security gateway, that means pointing your mail server to the DLP server, and the DLP server to the mail gateway. If you integrate directly with the mail gateway your DLP tool will likely add x-headers to analyzed mail messages. This extra metadata instructs the mail gateway how to handle each messages (allow, block, etc.). Web gateways and other proxies As we have mentioned, DLP tools are commonly integrated with web security gateways (proxies) to allow more granular management of web (and FTP) traffic. They may also integrate with instant messaging gateways, although that is very product specific. Most modern web gateways support something called the ICAP protocol (Internet Content Adaptation Protocol) for extending proxy servers. If your web gateway supports ICAP you can configure it to pass traffic to your DLP server for analysis. Proxying connections enable analysis before the content leaves your organization. You can, for example, allow someone to use webmail but block attachments and messages containing sensitive information. So much traffic now travels over SSL connections that you might want to integrate with a web gateway that performs SSL interception (also called a “reverse proxy”). These work by installing a trusted server certificate on all your endpoints (a straightforward configuration update) and performing a “man-in-the-middle” interception on all SSL traffic. Traffic is encrypted inside your network and from the proxy to the destination website, but the proxy has access to decrypted content. Note: this is essentially attacking and spying on your own users, so we strongly recommend notifying them before you start intercepting SSL traffic for analysis. If you have SSL interception up and running on your gateway, there are no additional steps beyond ICAP integration. Additional proxies, such as instant messaging, have their own integration requirements. If the products are compatible this is usually the same process as integrating a web gateway: just turn the feature on in your DLP product and point both sides at each other. Hierarchical deployments Until now we have mostly described fairly simple deployments, focused on a single appliance or server. That’s the common scenario for small and some mid-size organizations, but the rest of you have multiple network egress points to manage – possibly in very distributed situations, with limited bandwidth in each location. Hopefully you all purchased products which support hierarchical deployment. To integrate, you place additional DLP servers or appliances on each network gateway, then configure them to slave to the primary DLP server/appliance in your network core. The actual procedure varies by product, but here are some things to look out for: Different products have different management traffic bandwidth requirements. Some work great in all situations, but others are too bandwidth-heavy for some remote locations. If your remote locations don’t have a VPN or private connection back to your core network, you will need to establish them for handle management traffic. If you plan on allowing remote locations to manage their own DLP incidents, now is the time to set up a few test policies and workflow to verify that your tool can support this. If you don’t have web or instant messaging proxies at remote locations, and don’t filter that traffic, you obviously lose a major enforcement option. Inconsistent network security hampers DLP deployments (and isn’t good for the rest of your security, either!). We are only discussing multiple network deployments here, but you might use the same architecture to cover remote storage repositories or even endpoints. The remote servers or appliances will receive policies pushed by your main management server and then perform all analysis and enforcement locally. Incident data is sent back to the main DLP console for handling unless you delegated to remote locations. As we have mentioned repeatedly, if hierarchical

We know it’s a shock, but your endpoint protection suite isn’t doing a good enough job of blocking malware attacks. So the industry has resorted additional layers of inspection, detection, and even protection to address its shortcomings. One place focus is turning, which is seeing considerable innovation, is the network. We see a new set of devices and enhancements to existing perimeter platforms, focused on detecting and blocking malware. A paragraph from Network-Based Malware Detection: Filling the Gaps of AV says it best: We have been doing anti-virus for years and it hasn’t worked. Malware detection moving forward is about really understanding what the files are doing, and then determining whether that behavior is bad. By leveraging the collective power of the network we can profile bad stuff much more quickly. With the advancement of network security technology we can start to analyze those files before they make their way onto our devices. Can we actually prevent an attack? Under the right circumstances, yes. We would like to thank Palo Alto Networks for sponsoring this research, and making sure you can read it for a remarkably fair price. You can download the paper directly: Network-Based Malware Detection: Filling the Gaps of AV The paper is based on several posts: Introduction Identifying Today’s Malware Where to Detect the Bad Stuff? The Impact of the Cloud Share:

They say it takes 10,000 hours of practice at a task to become an expert. This isn’t idle supposition, but something that’s been studied scientifically – if you believe in that sorts of things. (I’d like to provide a reference, but I’m in the process of becoming an expert at sitting in an Economy Class seat without wireless). 10,000 hours translates, roughly, to practicing something for 40 hours a week for around 5 years. Having racked up that many hours in a couple different fields, my personal experience tells me (if you believe that sorts of things) that the 10K threshold only opens up the first gate to a long path of mastery. I can’t remember exactly what year I became an analyst, but I think it was right around a decade ago. This would put me well past that first gate, but still with a lot of room to learn and grow in front of me. That’s assuming you consider analysis a skill – I see it as more a mashup of certain fundamental skills, with deep knowledge and experience of the topic you focus on. Some analysts think the fundamental tools of analysis apply anywhere, and it’s only a matter of picking up a few basics on any particular topic. You can recognize these folks, as they bounce from area to coverage area, without a real passion or dedication to any primary focus. While I do think a good analyst can apply the mechanics to multiple domains, being handy with a wrench doesn’t make a plumber a skilled car mechanic. You have to dig deep and rip apart the fundamentals to truly contribute to a field. In a bit of cognitive bias, I’m fascinated by the mechanics of analysis. Like medicine or carpentry, it’s not a field you can learn from a book or class – you really need to apprentice somewhere. One of the critical skills is the ability to change your position when presented with contradictory yet accurate evidence. Dogma is the antithesis of good analysis. Unfortunately I’d say over 90% of analysts take religious positions, and spend more time trying to make the world fit into their intellectual models than fixing their models to fit the world. When you are in a profession where you’re graded on “thought leadership”, it’s all too easy to interpret that as “say something controversial to get attention and plant a flag”. Admitting you were wrong – not merely misinterpreted – is hard. I sure as hell don’t like it, and my natural reaction is usually to double down on my position like anyone else. I don’t always pull my head out of my ass, but I really do try to admit when I get something wrong. Weirdly, a certain fraction of the population interprets that as a fault. Either I’m an idiot for saying something wrong in the first place, or unreliable for changing my mind – even in the face of conflicting evidence. The easiest way to tell whether an analyst sucks is to see how they react when the facts show them wrong. Or whether they use facts to back up their positions. I don’t claim to always get it right – I’m as human as everyone else, and often feel an emotional urge to defend my turf. This is a skill that takes constant practice – it’s handy for everyone, but critical for anyone who sells knowledge for a living. And I believe it takes a heck of a lot more than 10,000 hours to master. I’m at double that and not even close. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s DR post: A Response To NoSQL Security Concerns. Rich quoted by Bloomberg on the Symantec hack. Favorite Securosis Posts Mike Rothman: Understanding and Selecting a Database Security Platform: Defining DSP. Database security has evolved. Rich and Adrian start fleshing this out by describing how the Database Security Platform is a superset of DAM. Other Securosis Posts Incite 2/7/2012: The Couch. Implementing and Managing a Data Loss Prevention (DLP) Solution: Index of Posts. Understanding and Selecting a Database Security Platform: Defining DSP. Implementing DLP: Starting Your Integration. Implementing DLP: Integration Priorities and Components. Favorite Outside Posts Mike Rothman: Executive Breakfast Briefing with Former DHS Secretary Michael Chertoff. Bejtlich lists 3 questions that you need to be asking yourself in this summary of an event they did with Secretary Chertoff. This seriously cuts to the heart of what security is supposed to be doing… Adrian Lane: Terrorism, SOPA And Zombies. Our Canadian brothers nailed this one. Cabal – cracks me up! Rich: Hoff gets all touchy-feely. Project Quant Posts Malware Analysis Quant: Monitoring for Reinfection. Malware Analysis Quant: Remediate. Malware Analysis Quant: Find Infected Devices. Malware Analysis Quant: Defining Rules. Malware Analysis Quant: The Malware Profile. Malware Analysis Quant: Dynamic Analysis. Malware Analysis Quant: Static Analysis. Malware Analysis Quant: Build Testbed. Research Reports and Presentations [New White Paper] Network-Based Malware Detection: Filling the Gaps of AV. Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Tokenization Guidance. Applied Network Security Analysis: Moving from Data to Information. Security Management 2.0: Time to Replace Your SIEM? Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Tokenization vs. Encryption: Options for Compliance. Top News and Posts Sorry, I didn’t have WiFi on my flights today and got home late, so I couldn’t compile a good list of stories. It doesn’t help that I’ve been slammed all week and haven’t read as much as usual. I suspect someone disclosed something, someone got hacked, and someone else tried to cover something up. That cover it? Oh – and there was a privacy violation by Google/Facebook/some social media service. Share: