Research

Rich here… Some weeks I can’t decide if I should write something personal, professional, or technical in the Summary intro. Especially when I’m absolutely slammed and haven’t been blogging. This week I’ll err on the side of personal, and I’m sure you all will give me a little feedback if you prefer the geeky. Last summer and fall I had a bit of a health scare, when I thought I was, well, dying, at breakfast with Mr. Rothman. Now I know many people think they’ve felt that way while dining with Mike, but I seriously thought I was going out for the count. Many months and medical tests later, they think it was just something with my stomach, and beyond a more-than-fair share of indigestion, I have moved on with life. I have always tried to be a relatively self-aware individual (well, not counting most of my life before age 27 or so). Some people blow off scares like that, but I figured it was a good way to review my life priorities. I came up with a simple list: 1 Family/Health 2 Fitness 3 Work … … … … … … 4 Everything else Yes, in that order. I can’t be there for my family if I’m not healthy, and my wife and kids matter a lot more to me than anything else. I don’t begrudge people who prioritize differently – I know plenty of people who put work/career in front of family (although few admit it to themselves). That’s their decision to make, and some of them see financial health the way I look at physical health. That’s also why I put fitness ahead of work. For me, it is intrinsically tied to health, but the difference is that I will skip a workout if necessary to be there for my family. But aside from the health benefits (not counting the injuries), I want to be very active and very old someday, which I can’t do without working out. A lot. And it keeps me sane. Then comes work. As the CEO of a startup facing its most important year ever, work has to come before everything else. This Securosis thing isn’t just a paycheck – it is long-term financial security for my family. I can’t afford to screw it up. The upside of The List is that it makes decisions simple. Can I carve out 2 hours for a workout during business hours so I can be home with my family that night? Yes. Do I skip a Saturday morning ride because I have been traveling a lot and need to spend time with the kids? Yes. Can I travel for that conference during a birthday? No. The downside of my list is that “everything else” is a distant fourth to the top three items. That means less contact with friends; dropping most of my hobbies that don’t involve pools, bikes, or running shoes; and not having the diversity in my life that I enjoyed before my family. Other than the part about friends, I am okay with those sacrifices. When the kids are older I can start woodworking, recreational hacking, and playing with the soldering iron again. I don’t have much of a social life and I work at home, which is pretty isolating, and maybe I will figure that out as the kids get older. It also means I dropped nearly all my emergency services work, and for the first time since I was 18 I might drop it completely for a few years. And, in case you were wondering, The List is the reason I haven’t been writing as much. We are completing some seriously important long-term projects for the company and those need to take priority over the short stuff. But I like algorithms. Keeps things simple, especially when you need to make the hard choices. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Quiet. Must be summer. Favorite Securosis Posts Adrian Lane: Pragmatic WAF Management: Policy Management. I don’t normally pick my own posts but I like this one. And there was so much ground to cover I am afraid I might have left something out, so I would appreciate feedback. Mike Rothman: Pragmatic WAF Management: Policy Management. WAFs still ain’t easy, nor are they going to be. But understanding how to build and manage your policies is the first step. Adrian lays out what you need to know. Rich: Always Assume. This is an older post, but it came up in an internal discussion today and I think it is still very relevant. Other Securosis Posts Pragmatic WAF Management: Application Lifecycle Integration. Incite 8/15/2012: Fear (of the Unknown). Endpoint Security Management Buyer’s Guide: Ongoing Controls – Device Control. Endpoint Security Management Buyer’s Guide: Ongoing Controls – File Integrity Monitoring. Favorite Outside Posts Mike Rothman: Triple DDoS vs. krebsonsecurity. You know you have friends in high places when a one man operation is blasted by all sorts of bad folks. Krebs describes his battle against DDoS in this post and it’s illuminating. We will do some research on DDoS in the fall – we think this is an attack tactic you will need to pay much more attention to. Adrian Lane: Software Runs the World. I’m not certain we can say software is totally to blame for the Knight Capital issue, but this is a thought-provoking piece in the mainstream media. Although I am certain those of you who have read Daemon are unimpressed. Rich: Gunnar’s interview with Jason Chan of Netflix security. A gold mine for cloud security nuggets. Project Quant Posts Malware Analysis Quant: Index of Posts. Research Reports and Presentations Understanding and Selecting Data Masking Solutions Evolving Endpoint Malware Detection: Dealing with Advanced and Targeted Attacks. Implementing and Managing a Data Loss Prevention Solution. Defending Data on iOS. Malware Analysis Quant Report. Report: Understanding and Selecting a Database Security Platform. Vulnerability Management Evolution: From Tactical Scanner to Strategic Platform. Watching the Watchers: Guarding the Keys to the

FDR was right. We have nothing to fear, but fear itself. Of course, that doesn’t help much when you face the unknown and are scared. XX1 started middle school on Monday, so as you can imagine she was a bit anxious on Sunday night. The good news is that she made it through the first day. She even had a good attitude when her bus was over an hour late because of some issue at the high school. She could have walked the 3 miles home in a lot less time. But when she was similarly anxious on Monday night, even after a successful first day, it was time for a little chat with Dad. She asked if I was scared when I started middle school. Uh, I can’t remember what I had for breakfast yesterday, so my odds of remembering an emotion from 30+ years ago are pretty small. But I did admit to having a little anxiety before a high-profile speech or meeting with folks who really know what they’re talking about. It’s basically fear of the unknown. You don’t know what’s going to happen, and that can be scary. I found this quote when looking at Flickr for the image above, and I liked it: Fear is a question: What are you afraid of, and why? Just as the seed of health is in illness, because illness contains information, your fears are a treasure house of self-knowledge if you explore them. ~ Marilyn Ferguson Of course that’s a bit deep for a 11 (almost 12) year old, so I had to take a different approach. We chatted about a couple strategies to deal with the anxiety, not let it make her sick, and allow her to function – maybe even function a bit better with that anxiety-fueled edge. First we played the “What’s the worst that could happen?” game. So she gets lost. Or forgets the combination to her locker. Or isn’t friends with every single person in all her classes. We went through a couple things, and I kept asking, “What’s the worst thing that could happen?” That seemed to help, as she realized that whatever happens, it will be okay. Then we moved on to “You’re not alone.” Remember, when you’re young and experiencing new feelings, you think you might be the only person in the world who feels that way. Turns out most of her friends were similarly anxious. Even the boys. Then we discussed the fact that whatever she’s dealing with will be over before she knows it. I reiterated that I get nervous sometimes before a big meeting. But then I remember that before I know it, it’ll be over. And sure enough it is. We have heard from pretty much everyone that it takes kids about two weeks to adjust to the new reality of middle school. To get comfortable dealing with 7 teachers, in 7 different classrooms, with 7 different teaching styles. It takes a while to not be freaked out in the Phys Ed locker room, where they have to put on their gym uniforms. It may be a few weeks before she makes some new friends and finds a few folks she’s comfortable with. She knows about a third of the school from elementary school. But that’s still a lot of new people to meet. Of course she’ll adjust and she’ll thrive. I have all the confidence in the world. That doesn’t make seeing her anxious any easier, just like it was difficult back when I helped her deal with mean people and setbacks and other challenges in elementary school. But those obstacles make us the people we become, and she will eventually look back at her anxiety and laugh. Most likely within a month. And it will be great. At least for a few years until she goes off to high school. Then I’m sure the anxiety engine will kick into full gear again. Wash, rinse, repeat. That’s life, folks. –Mike Photo credits: The Question of Fear originally uploaded by elycefeliz Heavy Research We’re back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Endpoint Security Management Buyer’s Guide Ongiong Controls – Device Control Periodic Controls The ESM Lifecycle Pragmatic WAF Management Policy Management The WAF Management Process New Series: Pragmatic WAF Management Incite 4 U Even foes can be friends: You’ve have to think the New School guys really enjoy reading reports of increased collaboration, even among serious competitors. Obviously some of the more mature (relative to security) industries have been using ISAC (Information Sharing and Analysis Center) groups for a long time. But now the folks at GA Tech are looking to build a better collaboration environment. Maybe they can help close the gap between the threat intelligence haves (with their own security research capabilities) and the have-nots (everyone else). With the Titan environment, getting access to specific malware samples should be easier. Of course folks still need to know what to do with that information, which remains a non-trivial issue. But as with OpenIOC, sharing more information about what malware does is a great thing. Just like in the playground sandbox: when we don’t share, we all lose. I guess we did learn almost everything we need to know back in kindergarten. – MR Operational effectiveness: I have done dozens of panels, seminars, and security management round tables over the past 12 years, and the question of how security folks should present their value to peers and upper management has been a topic at most of them. I am always hot to participate in these panels because I fell into the trap of positioning security as a roadblock early in my career. I was “Dr. No” long before Mordac: Preventer of Information Services was conceived. I

As we discussed in the Endpoint Security Management Lifecycle, there are controls you run periodically and others you need to use on an ongoing basis. We tackled the periodic controls in the previous post, so now let’s turn to ongoing controls, which include device control and file integrity monitoring. The periodic controls post was pretty long, so we decided to break ongoing controls into two pieces. We will tackle device control in this post. Device Control Device control technology provides the ability to enforce policy on what you can and can’t do with devices. That includes locking down ports to prevent copying data (primarily via removable media), as well as protecting against hardware keyloggers and ensuring any data allowed onto removable media is encrypted. Early in this technology’s adoption cycle we joked that the alternative to device control involves supergluing the USB ports shut. Which isn’t altogether wrong. Obviously superglue doesn’t provide sufficient granularity in the face of employees’ increasing need to collaborate and share data using removable media, but it would at least prevent many breaches. So let’s get a bit more specific with device control use cases: Data leakage: You want to prevent users from connecting their phones or USB sticks and grabbing your customer database. You would also like to allow them to connect USB sticks, but not copy email or databases, or perhaps limit them to copying 200mb per day. Don’t let your intellectual property escape on removable media. Encryption: Obviously there are real business needs for USB ports, or else we would all have stopped at superglue. If you need to support moving data to removable media, make sure it’s encrypted. If you think losing a phone is easy, USB sticks are even easier – and if one has unencrypted and unprotected sensitive data, you will get a chance to dust off your customer notification process. Malware proliferation: The final use case to mention gets back to the future. Remember how the first computer viruses spread via floppy disks? Back in the day sneakernet was a big problem, and this generation’s sneakernet is the found USB stick that happens to carry malware. You will want to protect against that attack without resorting to superglue. Device Control Process As we have mentioned throughout this series, implementing technology controls for endpoint security management without the proper underlying processes never works well, so let’s quickly offer a reasonable device control process: Define target devices: Which devices pose a risk to your environment? It’s probably not all of them, so start by figuring out which devices need to be protected. Build threat models: Next put on your attacker hat and figure out how those devices are likely to be attacked. Are you worried about data leakage? Malware? Build models to represent how you would attack your environment. Then take the threat models to the next level. Maybe the marketing folks should be able to share big files via their devices, but folks in engineering (with access to source code) shouldn’t. You can get pretty granular with your policies, so you can do the same with threat models. Define policies: With the threat models you can define policies. Any technology you select should be able to support the policies you need. Discovery: Yes, you will need to keep an eye on your environment, checking for new devices and managing the devices you already know about. There is no reason to reinvent the wheel, so you are likely to rely on an existing asset repository (within the endpoint security management platform, or perhaps a CMDB). Enforcement: Now we get to the operational part of endpoint security management: deploying agents and enforcing policies on devices. Reporting: We security folks like to think we implement these controls to protect our environments, but don’t forget that at least a portion of our tools are funded by compliance. So we need some reports to demonstrate that we’re protecting data and compliant. Technology Considerations Now that you have the process in place, you need some technology to implement the controls. Here are some things to think about when looking at these tools: Device support: Obviously the first order of business is to make sure the vendor supports the devices you need to protect. That means ensuring operating system support, as well as the media types (removable storage, DVD/CDs, tape drives, printers, etc.) you want to define policies for. Additionally make sure the product supports all ports on your devices, including USB, FireWire, serial, parallel, and Bluetooth. Some offerings can also implement policies on data sent via the network driver, though that begins to blur into endpoint DLP, which we will discuss later. Policy granularly: You will want to make sure your product can support different policies by device. For example, this allows you to set a policy to let an employee download any data to an IronKey but only non-critical data onto an iPhone. You will also want to be able to set up different policies for different classes of users and groups, as well as by type of data (email vs. spreadsheets vs. databases). You may want to limit the amount of data that can be copied by some users. This list isn’t exhaustive, but make sure your product can support the policies you need. Encryption algorithm support: If you are going to encrypt data on removable media, make sure your product supports your preferred encryption algorithms and/or hooks to your central key management environment. You may also be interested in certifications such as EAL (Common Criteria), FIPS 140-2, etc. Small footprint agent: To implement device control you will need to implement an agent on each protected device. You’ll need sufficient platform support (discussed above), as well as some kind of tamper resistance for the agent. You don’t want an attacker to turn off or compromise the agent’s ability to enforce policies. Hardware keylogger protection: It’s old school, but from time to time we still see hardware keyloggers which use plug into a device port.

To get value out of your WAF investment – which means blocking threats, keeping unwanted requests and malware from hitting applications, and virtually patching known vulnerabilities in the application stack – the WAF must be tuned regularly. As we mentioned in our introduction, WAF is not a “set and forget” tool – it’s a security platform which requires adjustment for new and evolving threats. To flesh out the process presented in the WAF Management Process, let’s dig into policy management – specifically how to tune policies to defend your site. But first it’s worth discussing the different types of polices at your disposal. Policies fall into two categories, blacklists of stuff you don’t want – attacks you know about – and whitelists of activities that are permissible for specific applications. These negative and positive security models complement one another to fully protect applications. Negative Security Negative security models should be familiar – at least from Intrusion Prevention Systems. The model works by detecting patterns of known malicious behavior. Things like site scraping, injection attacks, XML attacks, suspected botnets, Tor nodes, and even blog spam, are universal application attacks that affect all sites. Most of these policies come “out of the box” from vendors, who research and develop signatures for their customers. Each signature explicitly describes an attack, and they are typically used to identify attacks such as SQL injection and buffer overflows. The downside of this method is its fragility – any variation of the attack will no longer match the signature, and will thus bypass the WAF. So signatures are only suitable when you can reliably and deterministically describe an attack, and don’t expect the signature to immediately become invalid. So vendors provide a myriad of other detection options, such as heuristics, reputation scoring, detection of evasion techniques, and several proprietary methods used to qualitatively detect attacks. Each method has its own strengths and weaknesses, and use cases for which it is more or less well suited. They can be combined with each other to provide a risk score for incoming requests, in order to block requests that look too suspicious. But the devil is in the details, there are literally thousands of attack variations, and figuring out how to apply policies to detect and stop attacks is quite difficult. Finally, fraud detection, business logic attack detection, and data leakage policies need to be adapted to the specific use models of your web applications to be effective. The attacks are designed to find flaws in the way application developers code, targeting gaps in the ways they enforce process and transaction state. Examples include issuing order and cancellation requests in rapid succession to confuse the web server or database into revealing or altering shopping cart information, replaying attacks, and changing the order of events. You generally need to develop your own fraud detection policies. They are constructed with the same analytic techniques, but rather than focusing on the structure and use of HTTP and XML grammars, they examine user behavior as it relates to the type of transaction being performed. These policies require an understanding of how your web application works, as well as appropriate detection techniques. Positive Security The other side of this coin is the positive security model: ‘whitelisting’. Yes, this is the metaphor implemented in firewalls. First catalog legitimate application traffic, ensure you do not include any attacks in your ‘clean’ baseline, and set up policies to block anything not on the list of valid behaviors. The good news is that this approach is very effective at catching malicious requests you have never seen before (0-day attacks) without having to explicitly code signatures for everything. This is also an excellent way to pare down the universe of all threats into a smaller, more manageable subset of specific threats to account for with a blacklist – basically ways authorized actions such as GET and POST can be gamed. The bad news is that applications are dynamic and change regularly, so unless you update your whitelist with each application update, the WAF will effectively disable new application features. Regardless, you will use both approaches in tandem – without both approaches workload goes up and security suffers. People Manage Policies There is another requirement that must be addressed before adjusting polices: assigning someone to manage them. In-house construction of new WAF signatures, especially at small and medium businesses, is not common. Most organizations depend on the WAF vendor to do the research and update policies accordingly. It’s a bit like anti-virus: companies could theoretically write write their own AV signatures, but they don’t. They don’t monitor CERT advisories or other source for issues to protect applications against. They rarely have the in-house expertise to write these policies even if they wanted to. And if you want your WAF to perform better than AV, which generally addresses about 30% of viruses encountered, you need to adjust your policies to your environment. So you need someone who can understand the rule ‘grammars’ and how web protocols work. That person must also understand what type of information should not leave the company, what constitutes bad behavior, and the risks your web applications pose to the business. Having someone skilled enough to write and manage WAF policies is a prerequisite for success. It could be an employee or a third party, or you might even pay the vendor to assist, but you need a skilled resource to manage WAF policies on an ongoing basis. There is really no shortcut here – either you have someone knowledgable and dedicated to this task, or you depend on the canned policies that come with the WAF, and they just aren’t good enough. So the critical success factor in managing policies is to find at least one person who can manage the WAF, get them training if need be, and give them enough time to keep the policies up to date. What does this person need to do? Let’s break it down: Baseline Application Traffic The first step

This Summary is a short rant on how most firms appear baffled about how to handle mobile and cloud computing. Companies tend to view the cloud and mobile computing as wonderful new advancements, but unfortunately without thinking critically about how customers want to use these technologies – instead they tend to project their own desires onto the technology. Just as I imagine early automobiles were saddled with legacy holdovers from horse-drawn carriages, when they were in fact something new. We are in that rough transition period, where people are still adjusting to these new technologies, and thinking of them in old and outmoded terms. My current beef is with web sites that block users who appear to be coming from cloud services. Right – why on earth would legitimate users come from a cloud? At least that appears to be their train of thought. How many of you ran into a problem buying stuff with PayPal when connected through a cloud provider like Amazon, Rackspace, or Azure? PayPal was blocking all traffic from cloud provider IP addresses. Many sites simply block all traffic from cloud service providers. I assume it’s because they think no legitimate user would do this – only hackers. But some apps route traffic through their cloud services, and some users leverage Amazon as a web proxy for security and privacy. Chris Hoff predicted in The Frogs Who Desired a King that attackers could leverage cloud computing and stolen credit cards to turn “The mechanical Turk into a maniacal jerk”, but there are far more legitimate users doing this than malicious ones. Forbidding legitimate mobile apps and users from leveraging cloud proxies is essentially saying, “You are strange and scary, so go away.” Have you noticed how may web sites, if they discover you are using a mobile device, screw up their web pages? And I mean totally hose things up. The San Jose Mercury News is one example – after a 30-second promotional iPad “BANG – Get our iPad app NOW” page, you get locked into an infinite ‘django-SJMercury’ refresh loop and you can never get to the actual site. The San Francisco Chronicle is no better – every page transition gives you two full pages of white space sandwiching their “Get our App” banner, and somewhere after that you find the real site. That is if you actually scroll past their pages of white space instead of giving up and just going elsewhere. Clearly they don’t use these platforms to view their own sites. Two media publications that cover Silicon Valley appear incapable of grasping media advances that came out of their own back yard. I won’t even go into how crappy some of their apps are (looking at you, Wall Street Journal) at leveraging the advantages of the new medium – but I do need to ask why major web sites think you can only use an app on a mobile device or a browser from a PC? Finally, I have a modicum of sympathy for Mat Honan after attackers wiped out his data, and I understand my rant in this week’s Incite rubbed some the wrong way. I still think he should have taken more personal responsibility and done less blame-casting. I think Chris Hoff sees eye to eye with me on this, but Chris did a much better job of describing how the real issues in this case were obfuscated by rhetoric and attention seeking. I’d go one step further, to say that cloud and mobile computing demonstrate the futility of passwords. We have reached a point where we need to evolve past this primitive form of authentication for mobile and cloud computing. And the early attempts, a password + a mobile device, are no better. If this incident was not proof enough that passwords need to be dead, wait till Near Field Payments from mobile apps hit – cloned and stolen phones will be the new cash machines for hackers. I could go on, but I am betting you will notice if you haven’t already how poorly firms cope with cloud and mobile technologies. Their bumbling does more harm than good. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted in CIO. Adrian in SIEM replacement video available this week. Rich’s Dark Reading post on Black Hat’s Future Rich quoted on iOS Security. Favorite Securosis Posts Adrian Lane: The TdF edition of the Friday Summary.. Just because that would be friggin’ awesome! Mike Rothman: Friday Summary, TdF Edition. It’s not a job, it’s an adventure. As Rich experienced with his Tour de France trip. But the message about never getting complacent and working hard, even when no one is looking, really resonated with me. Rich: Mike slams the media. My bet is this is everyone’s favorite this week. And not only because we barely posted anything else. Other Securosis Posts Endpoint Security Management Buyer’s Guide: Periodic Controls. Incite 8/8/2012: The Other 10 Months. Pragmatic WAF Management: the WAF Management Process. Favorite Outside Posts Adrian Lane: Software Runs the World. I’m not certain we can say software is totally to blame for the Knight Capital issue, but this is a thought-provoking piece in mainstream media. I am certain those of you who have read Daemon are not impressed. Mike Rothman: NinjaTel, the hacker cellphone network. Don’t think you can build your own cellular network? Think again – here’s how the Ninjas did it for Defcon. Do these folks have day jobs? Rich: How the world’s larget spam botnet was brought down. I love these success stories, especially when so many people keep claiming we are failing. Project Quant Posts Malware Analysis Quant: Index of Posts. Malware Analysis Quant: Metrics – Monitor for Reinfection. Malware Analysis Quant: Metrics – Remediate. Malware Analysis Quant: Metrics – Find Infected Devices. Malware Analysis Quant: Metrics – Define Rules and Search Queries. Malware Analysis Quant: Metrics – The Malware Profile. Malware Analysis Quant: Metrics – Dynamic Analysis. Research Reports and Presentations Evolving Endpoint Malware

I’m going to rant a bit this morning. I’m due. Overdue, in fact. I have been far too well behaved lately. But as I mentioned in this week’s Incite, summer is over and it’s time to stir the pot a bit. Tech media isn’t about reporting anymore. It’s about generating page views by hook or by crook, and when that doesn’t work, trying to get vendors to sponsor crappy survey-based reports that rank vendors based on … well, nothing of relevance. The page view whoring has driven quality into the ground. Those folks who used to man the beat of security reporting – giants like Brian Krebs, Ryan Naraine, George Hulme, Dennis Fisher, Paul Roberts, and Matt Hines – have moved out of mainstream media. Matt left the media business altogether (as have many other reporters). Ryan, Paul, and Dennis now work for Kaspersky with their hands in Threatpost. George is a freelance writer. And Krebs is Krebsonsecurity.com, kicking ass and taking names, all while fighting off the RBN on a daily basis. Admittedly, this is a gross generalization. Obviously there are talented folks still covering security and doing good work. Our friends at DarkReading and TechTarget stand out as providing valuable content most of the time. They usually don’t resort to those ridiculous slideshows to bump page views and know enough to partner with external windbags like us to add a diversity of opinion to their sites. But the more general tech media outlets should be ashamed of themselves. Far too much of their stuff isn’t worthy of a dog’s byline. No fact checking. Just come up with the most controversial headline, fill in a bunch of meaningless content, SEO optimize the entire thing to get some search engine love, and move on to the next one. Let’s go over a few examples. A friend pointed me to this gem on ZDNet, highlighting some Webroot research about Android malware. Would you like a Coke or a side of exhaust fumes with that FUD sandwich? It seems the author (Rachel King) mischaracterized the research, didn’t find alternative or contrary opinions and sensationalized the threat in the headline. Ed Burnette picks apart the post comprehensively and calls out the reporter, which is great. But why was the piece green lighted in the first place? Hello, calling all ZDNet editors. It’s your job to make sure the stuff posted on your site isn’t crap. FAIL. Then let’s take a look at some of the ‘reports’ distributed via InformationWeek. First check out their IDS/IPS rankings. 26 pages of meaningless drivel. The highlight is the overall performance rating, based on what, you ask? A lab test? A demo of the devices? A real world test? Market share? 3rd party customer satisfaction rankings? Of course not. They based them on a survey. Really, an online survey. Assessing performance of network security gear by asking customers if they are happy and about the features of the box they own. That’s pretty objective. I mean, come on, man! I’d highlight the results, but in good conscience I can’t highlight results that are totally contrary to the research I actually do on a daily basis. And what’s worse is that InformationWeek claims these reports “arm business technology decision-makers with real-world perspective based on qualitative and quantitative research, business and technology assessment and planning tools, and adoption best practices gleaned from experience.” But what qualitative research wouldn’t include Sourcefire in this kind of assessment of the IDS/IPS business? Their SIEM report is similarly offensive. These are basically blind surveys where they have contracted folks who know nothing about these technologies to compile the data and bang out some text so vendors on the wrong side of the innovation curve (but with name recognition) can sponsor the reports and crow about something. At least with a Magic Quadrant or a Wave, you know the analyst applied their own filter to the lies responses on vendor surveys. What really hurts is that plenty of folks believe what they read in the trade press. At times I think the Borowitz Report does more fact checking on its news. Far too many unsuspecting end users make short list decisions based on a farcical research reports that don’t even meet The Onion’s editorial standards. I have been around the block a hundred times, and my BS filter is highly tuned. I know what to pay attention to and what to ignore. Everyone else deserves better. Share:

As we discussed in the Endpoint Security Management Lifecycle, there are controls you use periodically and controls you need to run on an ongoing basis. This post will dig into the periodic controls, including patch and configuration management. Patch Management When Microsoft got religion about the security issues in Windows XP about a decade ago, they started a wide-ranging process called Trustworthy Computing to restore confidence in the integrity of the Windows operating system. That initiative included a monthly patch cycle to fix software defects that could cause security issues. Patch Tuesday was born, and almost every company in the world has since had to patch every month. Over the past decade, many software companies have instituted similar patch processes across many different applications and other operating systems. None are as regimented or predictable as Microsoft’s, and some have tried to move to a silent install process, where no effort is required of the customer organization. But most security and operations personnel don’t feel comfortable without control over what gets installed and when. So organizations needed to look beyond tactical software updates, considering patching as an operational discipline. Once a patch is issued each organization needs to assess it, figure out which devices need to be patched, and ultimately install the patch within the window specified by policy – typically a few days. Let’s dig a bit deeper. Patching Process Patching is an operational discipline, so an organization’s patching process must first be defined and then automated appropriately. Securosis documented a patch process in Patch Management Quant and if you are looking for an over-arching process for all your patching we recommend you start there. You can see the process map is detailed and granular – just use the parts that make sense in your environment. Let’s hit the high points of the process here: Define targets: Before you even jump into the Patch Management process you need to define what devices will be included. Is it just the endpoints or do you also need to patch servers? These days you also need to think about cloud instances. The technology is largely the same, but increased numbers of devices have made execution more challenging. In this series we largely restrict discussion to endpoints, as server operations are different and more complicated. Obtain patches: You need to monitor for the release of relevant patches, and then figure out whether you need to patch or you can work around the issue. Prepare to patch: Once the patch is obtained you need to figure out how critical fixing the issue is. Is it something you need to do right now? Can it wait for the next maintenance window? Once priority is established, give the patch a final Q/A check to ensure it won’t break anything important. Deploy the patch: Once preparation is done and your window has arrived you can install. Confirm the patch: Patches don’t help unless the install is successful, so confirm that each patch was fully installed. Reporting: In light of compliance requirements for timely patching, reporting on patching is also an integral function. Technology Considerations The good news about transforming a function from a security problem to an operational discipline is that the tools (products and services) to automate operational disciplines are reasonably mature and work fairly well. Let’s go over a few important technology considerations: Coverage (OS and apps): Obviously your patch management offering needs to support your operating systems and applications. Make sure you fully understand your tool’s value – what distinguishes it from the low-end operating system-centric tools such as Microsoft’s WSUS. Discovery: You can’t patch what you don’t know about, so you must ensure you have a way to identify new devices and get rid of deprecated devices – otherwise the process will fail. You can achieve this with a built-in discovery capability, bidirectional integration with asset management and inventory software, or (more likely) both. Library of patches: Another facet of coverage is accuracy and support of the operating systems and applications above. Just because something is ‘supported’ on a vendor’s data sheet doesn’t mean they support it well. So make sure to test the vendor’s patch library and check on the timeliness of their updates. How long does the vendor take to update their product after a patch is released? Deployment of patches and removal of software: This is self-explanatory. If patches don’t installed consistently or devices are negatively impacted by patches, that means more work for you. This can easily make the tool a net disadvantage. Agent vs. agentless: Does the patching vendor assess the device via an agent or do they perform an agentless scan (typically using a non-persistent or ‘disolvable’ agent), and then how to do they deploy patches? This borders on a religious dispute, but fortunately both models work. Patching is a periodic control, so either model is valid here. Remote devices: How does the patching process work for a remote device? This could be a field employee’s laptop or a device in a remote location with limited bandwidth. What kind of recovery features are built in to ensure the right patches get deployed regardless of location? And finally, can you be alerted when a device hasn’t updated within a configurable window – perhaps because it hasn’t connected? Deployment architecture: Some patches are hundreds of megabytes, so it is important to have some flexibility in patch distribution – especially for remote devices and locations. Architectures may include intermediate patch distribution points to minimize network bandwidth, and/or intelligent patch packaging to only install the appropriate patches to each device. Scheduling flexibility: Of course it’s essential that disruptive patching not impair productivity, so you should be able to schedule patches during off-hours or when machines are idle. There are many features and capabilities to consider and discuss with vendors. Later we will provide a handy list of key questions. Configuration Management As we described in the ESM Lifecycle post: Configuration Management provides the ability for an organization to define an authorized set

It’s hard to believe, but the summer is over. Not the brutally hot weather – that’s still around and will be for a couple more months in the ATL. But for my kids, it’s over. We picked the girls up at camp over the weekend and made the trek back home. They settled in pretty nicely, much better than the Boy. All three kids just loved their time away. We didn’t force the girls cold turkey back into their typical daily routine – we indulged them a bit. We looked at pictures, learned about color war (which broke right after the girls left) and will check the camp Facebook page all week. But for the most part we have a week to get them ready for real life. School starts on Monday and it’s back to work. But while we think they are getting back into their life at home, they have really just started their countdown to camp in 2013. Basically, once we drove out of camp, they started the other 10 months of the year. Any of you who went to sleep-away camp as kids know exactly what I’m talking about. They are just biding the time until they get back to camp. It’s kind of weird, but as a kid that’s really how you think. At least I did. The minute I stepped on the bus to head home, I was thinking about the next time I’d be back in camp. Now it’s even easier to keep a link to their camp friends over the other 10 months. XX1 was very excited to follow her camp friends on Instagram. We’re making plans to attend the reunion this winter. The Boss has been working with some of the other parents to get the kids together when we visit MD over the holidays. And I shouldn’t forget Words with Friends. I figure they’ll be playing with their camp friends as well, and maybe even learning something! Back in the olden days, I actually had to call my camp friends. And badger my Mom to take me to the Turkey Bowl in Queens Thanksgiving weekend, which was my camp’s reunion. It wasn’t until I got a car that I really stayed in touch with camp friends. Now the kids have these magic devices that allow them to transcend distance and build relationships. For the Boss and me, these 10 months are when the real work gets done. But don’t tell them that. And we’re not just talking about school. Each year at camp all the kids did great with some stuff, and had other areas that need improvement. Besides schoolwork and activities, we will work with each child over the next 10 months to address those issues and strengthen the stuff they did well at camp. So they are primed and ready next June. Remember, camp is the precursor to living independently – first at college and later in the big leagues. They’ll screw things up, and we’ll work with them to avoid those mistakes next time. It’s hard to get young kids to understand the big picture. We try, but it’s a process. They need to make mistakes and those mistakes are OK. Mistakes teach lessons, and sometimes those lessons are hard. All we ask of them is to work hard. That they strive to become better people – which means accepting feedback, admitting shortcomings, and doing their best. Basically to learn constantly and consistently, which we hope will serve them well when they start playing for real. If we can get that message across over the next 10 months, we will have earned our 2 months of vacation. –Mike Photo credits: Countdown calendar originally uploaded by Peter Heavy Research We’re back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Endpoint Security Management Buyer’s Guide The ESM Lifecycle The Business Impact of Managing Endpoints Pragmatic WAF Management The WAF Management Process New Series: Pragmatic WAF Management Incite 4 U It’s not over ‘til it’s over: Good luck to Rich Baich, who was recently named CISO of Wells Fargo. It’s a big job with lots of moving pieces and resources, and a huge amount at risk. He has his work cut out for him, but given his background he knows just how bad things can go. As Adam points out, Rich was CISO for ChoicePoint during their debacle, and some folks would have turned tail and found another area of technology to practice. That would have validated the clear myth that a breach = career death. But clearly that’s not true. As long as the lessons learned were impactful, executives living through experiences like that can end up the better for it. That’s why experienced CEOs keep getting jobs, even with Titanic-scale failures on their resumes. Investors and directors bet that an experienced CEO won’t make the same mistakes again. Sometimes they are right. As difficult as it is, you learn a hell of a lot more during a colossal failure than during a raging success. Take it from me – I learned that the hard way. – MR I’m with stoopid: It just friggin’ sad when someone says sensationalistic crap like How Apple and Amazon Security Flaws Led to My Epic Hacking. First because there was no ‘epic’ hacking. There was only epic stupidity, which produced epic fail. Apple and Google are only tangentially involved. The victim even stated a couple sentences in that “In many ways, this was all my fault.” You think? You daisy-chained your accounts together and they were all hacked. Of course you had cascading FAIL once the first account was breached. How about the author taking some real responsibility? If you want to help people understand the issue, how about titling the article “I’m with

As we discussed previously in The Trouble with WAFs, there are many reasons WAFs frustrate both security and application developers. But thanks to the ‘gift’ of PCI, many organizations have a WAF in-house, and now they want to use it (more) effectively. Which is a good thing, by the way. We also pointed out that many of the WAF issues our research has discovered were not problems with technology. There is entirely too much failure to effectively manage WAF. So your friends at Securosis will map out a clear and pragmatic 3-phase approach to WAF management. Now for the caveats. There are no silver bullets. Not profiling apps. Not integration with vulnerability reporting and intelligence services. Not anything. Effectively managing your WAF requires an ongoing and significant commitment. In every aspect of the process, you will see the need to revisit everything, over and over again. We live in a dynamic world – which means a static ruleset won’t cut it. The sooner you accept that, the sooner you can achieve a singularity with your WAF. We will stop preaching now. Manage Policies At a high level you need to think of the WAF policy/rule base as a living, breathing entity. Applications evolve and change – typically on a daily basis – so WAF rules also need to evolve and change in lockstep. But before you can worry about evolving your rule base, you need to build it in the first place. We have identified 3 steps for doing that: Baseline Application Traffic: The first step in deploying a WAF is usually to let it observe your application traffic during a training period, so it can develop a reference baseline of ‘normal’ application behavior for all the applications on your network. This initial discovery process and associated baseline provides the basis for the initial ruleset, basically a whitelist of acceptable actions for each application. Understand the Application: The baseline represents the first draft of your rules. Then you apply a large dose of common sense to see which rules don’t make sense and what’s missing. You can do this by building threat models for dangerous edge cases and other situations to ensure nothing is missed. Protect against Attacks: Finally you will want to address typical attack patterns. This is similar to how an Intrusion Prevention System works at the network layer. This will block common but dangerous attacks such as SQLi and XSS. Now you have your initial rule set, but it’s not time for Tetris yet. This milestone is only the beginning. We will going into detail on the issues and tradeoffs of policy management later in this series – for now we just want to capture the high-level approach. You need to constantly revisit the ruleset – both to deal with new attacks (based on what you get from your vendor’s research team and public vulnerability reporting organizations such as CERT), and to handle application changes. Which makes a good segue to the next step. Application Lifecycle Integration Let’s be candid – developers don’t like security folks, and vice-versa. Sure that’s a generalization, but it’s generally true. Worse, developers don’t like security tools that barrage them with huge amounts of stuff they’re supposed to fix – especially when the ‘spam’ includes many noisy inconsequential issues and/or totally bogus results. The security guy wielding a WAF is an outsider, and his reports are full of indigestible data, so they are likely to get stored in the circular file. It’s not that developers don’t believe there are issues – they know there’s tons of stuff that ought to be fixed, because they have been asked many times to take shortcuts to deliver code on deadline. And they know the backlog of functional stuff they would like to fix – over and above the threats reported by the WAF, dynamic app scans, and pen testers – is simply to large to deal with. Web-borne threat? Take a number. Security folks wonder why the developers can’t build secure code, and developers feel security folks have no appreciation of their process or the pressure to ship working code. We said “working code” – not necessarily secure code, which is a big part of the problem. Now add Operations into the mix – they are responsible for making sure the systems run smoothly, and they really don’t want yet another system to manage on their network. They worry about performance, failover, ease of management and – at least as much as developers do – user experience. This next step in the WAF management process involves collaboration between the proverbial irresistible force and immovable object to protect applications. Communication between groups is a starting point – providing filtered, prioritized, and digestible information to dev-ops is another hurdle to address. Further complicating matters are evolving development processes, various new development tools, and application deployment practices, which WAF products need to integrate with. Obviously you work with the developers to identify and eliminate security defects as early in the process as possible. But the security team needs to be realistic – adversely impacting a developer’s work process can have a dramatic negative impact on the quality and amount of code that gets shipped. And nobody likes that. We have identified a set of critical success factors for integrating with the DLC (development lifecycle): Executive Sponsorship: If a developer can say ‘no’ to the security team, at some point they will. Either security is important or it isn’t. To move past a compliance WAF, security folks need the CIO or CEO to agree that the velocity of feature evolution must give way to addressing critical security flaws. Once management has made that commitment, developers can justify improving security as part of their job. Establish Expectations: Agree on what makes a critical issue, and how critical issues will be addressed among the pile of competing critical requirements. Set guidelines in advance so there are no arguments when issues arise. Security/Developer Integration Points: There need to be logical (and documented)

As we described in The Business Impact of Managing Endpoint Security, the world is complex and only getting more so. You need to deal with more devices, mobility, emerging attack vectors, and virtualization, among other things. So you need to graduate from the tactical view of endpoint security. Thinking about how disparate operations teams manage endpoint security today, you probably have tools to manage change – functions such as patch and configuration management. You also have technology to control use of the endpoints, such as device control and file integrity monitoring. So you might have 4 or more different consoles to manage one endpoint device. We call that problem swivel chair management – you switch between consoles enough to wear out your chair. It’s probably worth keeping a can of WD-40 handy to ensure your chair is in tip-top shape. Using all these disparate tools also creates challenges in discovery and reporting. Unless the tools cleanly integrate, if your configuration management system (for instance) detects a new set of instances in your virtualized data center, your patch management offering might not even know to scan those devices for missing patches. Likewise, if you don’t control the use of I/O ports (USB) on the endpoints, you might not know that malware has replaced system files unless you are specifically monitoring those files. Obviously, given ongoing constraints in funding, resources, and expertise, finding operational leverage anywhere is a corporate imperative. So it’s time to embrace a broader view of Endpoint Security Management and improve integration among the various tools in use to fill these gaps. Let’s take a little time to describe what we mean by endpoint security management, the foundation of an endpoint security management suite, its component parts, and ultimately how these technologies fit into your enterprise management stack. The Endpoint Security Management Lifecycle As analyst types, the only thing we like better than quadrant diagrams are lifecycles. So of course we have an endpoint security management lifecycle. Of course none of these functions are mutually exclusive, and you don’t may not perform all these functions. And keep in mind that you can start anywhere, and most organizations already have at least some technologies in place to address these problems. It’s has become rare for organizations to manage endpoint security manually. We push the lifecycle mindset to highlight the importance of looking at endpoint security management strategically. A patch management product can solve part of the problem, tactically. And the same with each of the other functions. But handling endpoint security management as a platform can provide more value than dealing with each function in isolation. So we drew a picture to illustrate our lifecycle. We show both periodic functions (patch and configuration management) which typically occur every day or every two. We also depict ongoing activities (device control and file integrity monitoring) which need to run all the time – typically using device agents. Let’s describe each part of the lifecycle at a high level, before we dig down in subsequent posts. Configuration Management Configuration management provides the ability for an organization to define an authorized set of configurations for devices in use within the environment. These configurations govern the applications installed, device settings, services running, and security controls in place. This capability is important because a changing configuration might indicate malware manipulation, an operational error, or an innocent and unsuspecting end user deciding it’s a good idea to bring up an open SMTP relay on their laptop. Configuration management enables your organization to define what should be running on each device based on entitlements, and to identify non-compliant devices. Patch Management Patch management installs fixes from software vendors to address vulnerabilities in software. The best known patching process comes from Microsoft every month. On Patch Tuesday, Microsoft issues a variety of software fixes to address defects that could result in exploitation of their systems. Once a patch is issued your organization needs to assess it, figure out which devices need to be patched, and ultimately install the patch within the window specified by policy – typically a few days. The patch management product scans devices, installs patches, and reports on the success and/or failure of the process. Patch Management Quant provides a very detailed view of the patching process, so check it out if you want more information. Device Control End users just love the flexibility their USB ports provide for their ‘productivity’. You know – the ability to share music with buddies and download your entire customer database onto their phones became – it all got much easier once the industry standardized on USB a decade ago. All kidding aside, the ability to easily share data has facilitated better collaboration between employees, while simultaneously greatly increasing the risk of data leakage and malware proliferation. Device control technology enables you both to enforce policy for who can use USB ports, and for what; and also to capture what is copied to and from USB devices. As a more active control, monitoring and enforcement of for device usage policy eliminates a major risk on endpoint devices. File Integrity Monitoring The last control we will mention explicitly is file integrity monitoring, which watches for changes in critical system files. Obviously these file do legitimately change over time – particularly during patch cycles. But those files are generally static, and changes to core functions (such as the IP stack and email client) generally indicate some type of problem. This active control allows you to define a set of files (including both system and other files), gather a baseline for what they should look like, and then watch for changes. Depending on the type of change, you might even roll back those changes before more bad stuff happens. The Foundation The centerpiece of the ESM platform is an asset management capability and console to define policies, analyze data, and report. A platform should have the following capabilities: Asset Management/Discovery: Of course you can’t manage what you can’t see, so the first critical