Research

Our days just keep getting longer and longer. When the kids were younger afternoons and early evenings were a blur of activities, homework, hygiene, meals, reading, and then bed. Most nights the kids were in bed by 8:30 and the Boss and I could eat in peace, watch a little TV, catch up, and basically take a breath. But since XX1 entered middle school, things have changed. The kids have adapted fine. The Boss and me, not so much. Now it’s all about dividing and conquering. I handle the early shift and get the twins ready for school. They are on the bus by 7:20 and then I usually head over to some coffee shop and start working. The Boss handles XX1 and has her on the bus at 8:10, and then she starts her day of working through all the crap that has to happen to keep the trains running. The twins get off the bus at 3pm or so. Then it’s homework time and shuttling them off to activities. XX2 isn’t home until 4:30; then some days she can get an hour or two of work in, and other days she can’t. Inevitably she gets home from dance and has to start her homework. She usually wraps up around 10, but I usually get enlisted to help with the writing or math. And there are nights when XX1 is up until 11 or even later trying to get everything done. So there is no peace and quiet. Ever. We find ourselves staying up past midnight because those 90 minutes after all the kids go to bed are the only time we have to catch up and figure out the logistics for the next day. Which assumes that I don’t have work I need to get done. I know Rich has it harder right now with his 2 (and soon to be 3) kids under 4. I remember those days, and don’t miss the sleep deprivation. And I’m sure he misses sleeping in on weekends. At least I get to do that – our kids want us to sleep as late a possible, so they can watch more crappy shows on Nick Jr. But I do miss the quiet evenings after the kids were sleeping. Those are likely gone for a little while. For the next 9 years or so, the kids own the night. –Mike Photo credits: We Own The Night originally uploaded by KJGarbutt 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. Defending Against Denial of Service (DoS) Attacks Introduction Securing Big Data Architectural Issues Security Issues with Hadoop Incite 4 U Responsible is in the eye of the beholder: My personal views on disclosure have changed a lot over the years. If you haven’t changed your views in the last 10 years you are either a hermit or a religious zealot – the operating environment has changed a lot. And the longer I have watched (and participated) in the debate, the more I realize it seems to be more about egos than the good of the public. And I fully mean this on all sides – researchers, vendors, users (but less), government, and pundits. Take Richard Bejtlich’s latest post on vendors or researchers going public when they find command and control servers. He expresses the legitimate concern that whoever finds and publicizes this information may often be blowing a law enforcement or intelligence operation. On the other hand law enforcement and intelligence agencies sure don’t make it easy to report these findings, and researchers might be sitting there watching people get compromised (including their customers). This is a hard problem to solve – if we even can. Just ask the Stratfor guys who were materially damaged while the FBI was not only watching, but ‘assisting’ the attack via their confidential informant. Better communication and cooperation is probably the answer, but I have absolutely no confidence that can happen at scale, even if some companies (including Richard’s employer) have those ties. No, I don’t have an answer, but we all need open minds, and probably a bit less ego and dogma. – RM The mark of a mature market: You can joke about the SC Magazine reviews operation. How they rarely actually test products, but instead sit through WebEx demos run by experienced SEs who make every product seem totally awesome. And that may be true but it’s not the point. It’s about relative ratings as an indicator of a mature market. If you look at SC Mag’s recent group test on email security devices, you’ll see 9 out of 10 products graded higher than 4 1/4 stars (out of 5). That 10th product must really suck for 3 stars. But even if you deflate the ratings by a star (or two) you’ll see very little outward differentiation. Which means the product category has achieved a lowest common denominator around a base set of features. So how do you decide between largely undifferentiated offerings? Price, of course… – MR Progress, at a glacial pace: I disagree with Mike Mimoso about the Disconnect Between Application Development and Security Getting Wider. We have been talking about this problem for almost a decade with not much improvement, so it certainly can feel that way. But I can say from personal experience that 10 years ago even the companies who developed security software knew nothing about secure code development, while now these is a better than even chance that someone on the team knows a little security. Have their processes changed to embrace security? Only at a handful of firms. The issue, in my opinion, is and has been the invisible boundary around the dev team to shield them from outside influence. Developers are largely isolated to keep

You will probably read this on Thursday or even Friday, and that’s late. This week got all screwed up. It’s a little matter of a bunch of things happening at the same time, mostly personal, all good. So Monday was a holiday for me and starts the fall renewal process where I don’t set goals and don’t worry about what I’m striving for any more. It also turns out Monday night was the Falcons home opener. Many of my ATL buddies consider me a sinner for going to a football game on the High Holy Days. As I told the Boss, “Football is my other religion,” so there was never a question whether I would go. Normally I work late on Tuesday night, but we took XX2 to see a Ben Folds concert for her birthday. So up late Monday (I’ll get to that) and up late Tuesday. And a check-up for the kids Wednesday morning. Which means not a lot of time to actually, well, work. And I won’t even mention the road trip to go see the Giants play in Carolina on Thursday night. Yeah, I have a pretty sweet deal. Now back to Monday night. Everyone was amped up for the game. The Broncos and their rebuilt QB, Peyton Manning, were in town. The atmosphere was electric. Until about midway through the first quarter, when the replacement refs lost control of the game. I mean totally lost control. I have never seen anything like it. Penalties were reversed or not called. Fights broke out. The ball was spotted wrong. The first quarter took over an hour. Monday Night Football didn’t end until Tuesday morning. NFL referees are like security folks. Until they are gone and all hell breaks loose, you don’t even notice them. The NFL is taking a hard line about pensions, and they locked out the regular referees. I thought I had a sweet deal, but refs have it pretty good too. Some make as much as $120K a year to work maybe 20 games, including playoffs. Even based on the NFL’s latest offer, they’ll still get something like $15K contributed to retirement. But it’s not enough. Everyone always wants more. So the NFL finds replacement refs, most of whom do a good enough job. Some don’t (like the team on the field in ATL on Monday night). But at the end of the day, Steve Young was right. The NFL is in an inelastic demand situation, and how cool is it that a Hall of Fame QB talks about Econ 101 on national TV? The NFL will take a hard line because the fans will continue to show up. And we will. I’ll bitch and moan to my pals. The football talking heads (which is actually a much bigger echo chamber than security) will bitch and moan. The fans will keep showing up. As evidenced by my upcoming road trip to Charlotte. So the scabs will continue to be entrusted with keeping games on track and in control. Hopefully no one gets hurt and the games end fairly. Truth be told, scabs is a derogatory and unfair term for the replacement refs. It’s not their fault they are in deep water. It’s like taking a recent security graduate and asking them to defend something important from [name your favorite pen tester]. It’s going to end poorly. Ultimately the real refs will cave. It’s all about the leverage. It’s always about the leverage. The real refs have none. The NFL continues to have record ratings and record attendance and record activity in the NFL ecosystem, even with replacement refs. And once the refs realize they are very small cogs in a multi-billion-dollar wheel, they will pull off the scabs and get back to work. –Mike Photo credits: Scabs originally uploaded by Thomas Hawk 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. Defending Against Denial of Service (DoS) Attacks Introduction Securing Big Data Security Issues with Hadoop Incite 4 U What makes an expert? Rob G levels a very uncharacteristic personal attack in his The know-nothings of cybersecurity, with the argument that someone who hasn’t actually configured a firewall or injected SQL cannot really be an expert. I reject that – it depends on what aspect of cybersecurity you’re talking about. A cybersecurity policy wonk probably hasn’t pwned devices using cool XSS code, but that doesn’t mean they don’t understand policies. And even if you are talking about technical expertise, it depends on who you’re talking to. Anyone can be an expert, if they are talking to n00bs. I’m no fan of generic statements that can’t be proven, nor am I a fan of the tons of charlatans claiming to be something they aren’t. But I don’t buy that there is only one kind of cybersecurity expert. – MR Mobile payments are HOT HOT HOT: Hat tip to Martin McKeay for bringing this up as we were recording this week’s Network Security Podcast. It looks like the PCI Council is going to release guidance on mobile payment applications. This is a big deal – a lot of apps tie into credit cards in some way, shape, or form. On one side are tools like Square payment card readers, but I suspect we might see other forms of apps tying to credit cards coming under scrutiny. It’s not something I would put money on – just something to watch. Think of all the QR-code based apps that use credit card somewhere on the back end. Then again, the PCI will do whatever they expect to piss off the smallest number of vendorsmembers, and Visa will end up making a blanket decision, anyway. – RM Estimates are like … never mind: There is a reason

For years security folks have grumbled about the role compliance has assumed in driving investment and resource allocation in security. It has all been about mandates and regulatory oversight, which drive a focus on protection, ostensibly to prevent data breaches. We have spent years in the proverbial wilderness focused entirely on the “C” (Confidentiality) and “I” (Integrity) aspects of the CIA triad, mostly neglecting the “A” (Availability). But that hasn’t worked out too well. Regulators pretty much only care whether data leaks out. They don’t care about the availability of systems – data can’t leak if the system is down, right? Without a clear compliance-driven mandate to address availability (due to security exposure), many customers haven’t and won’t do anything. Of course attackers know this. So they have adapted their tactics to fill the vacuum created by compliance spending. They increasingly leverage availability-impacting attacks to both cause downtime (costing site owners money), and use availability issues to mask other kinds of attacks. Yes, these availability-impacting attacks are better known as Denial of Service (DoS) attacks. To be clear, most security professionals are very familiar with DoS attacks. It may be hard to remember back over a decade ago, but in the heyday of the Internet bubble we saw many old-fashioned Distributed DoS (DDoS) attacks targeting high profile web properties (think Yahoo and E*Trade, back in the day), with attackers like Mafiaboy doing the damage more for notoriety than to cause real economic damage. Over the past decade attackers have reoriented toward financially motivated attacks, which has meant increasingly application-centric attacks designed to evade detection and exfiltrate lucrative data. Obviously knocking down a target interferes with efforts to rob it electronically. But DDoS never really went away – it became a supplementary extortion tactic. In this scenario, attackers would communicate with a company and promise to knock down their site unless they received a ransom. It’s a simple shakedown move, and many targets were simply unable to survive a significant outage. They paid up rather than fight. We didn’t hear about many of these attacks – nobody wants to publicize that they are vulnerable to shakedowns. But that is all changing now. It’s like Back to the Future a bit – the rise of hacktivism has brought the Denial of Service back into a prominent position in the nightmares of security folks. Facilitated by the availability of open source tools such as LOIC and the availability of bot networks to launch attacks, a DoS renaissance is underway – which means availability has once again become a major factor in security architecture and control design. We try to do forward-looking research at Securosis. So we have started poking around, talking to practitioners about their plans, but we still see a knowledge gap around the kinds of Denial of Service attacks in use today and the defenses needed to maintain availability. So today we launch a new series: Defending Against Denial of Service Attacks, which will (unsurprisingly) provide guidance on the DoS attacks in use today, defensive tactics, and the basic process required for any chance to defend your organization. Let’s start by understanding the major kinds of DoS attacks. Flooding the Pipes versus Filling the Servers We’ll dig into specific attack tactics in much more depth in the next post, but to understand Denial of Service we need to draw a clear distinction between network-based attacks and application-based attacks. Both have the same objective: to impair availability – but they go about it in fundamentally different ways. Network-based attacks overwhelm the network equipment and/or totally consume network capacity by throwing everything including the kitchen sink at a site. This prevents legitimate traffic from getting to the site. This volumetric type of attack tends to be what most folks consider Denial of Service, because it is the most visible type. If your adversary has a big enough cannon it’s very hard to defend against these attacks, and you will quickly be reminded that bandwidth may be plentiful, but it’s certainly not free. Application-based attacks are different – they target weaknesses in web application components to consume all the resources of a web, application, or database server to effectively disable it. These kinds of attacks can target either vulnerabilities or ‘features’ of an application stack to overwhelm servers and prevent legitimate traffic from accessing web pages or completing transactions. The beginning of a network-based attack is fairly obvious. But application-based DoS attacks are less obvious – you are unlikely to discover the attack is underway until servers inexplicably start falling over – so they require more sophisticated defenses. That said, much of DoS defense is about properly leveraging existing controls, and of course compliance mandates haven’t gone away, so still have those required controls. Since you are already robbing Peter to pay Paul to address audit deficiencies, for DoS protection you need to focus your defenses on the attacks you are most likely to see. Which brings us to our next concept: studying your adversaries. Adversary Analysis A new tactic increasingly leveraged by security practitioners is adversary analysis. It’s not enough to just understand attacks and build defenses based on attacks – there is simply too much attack surface, and too many attack vectors. Your security success depends on your ability to prioritize your efforts, as we hammered home in the Vulnerability Management Evolution paper. This involves making strategic bets about who is most likely to attack you and what tactics they tend to use. This will enable you to build control sets with the right initial focus, based on what’s likely to happen. Of course you will be wrong – attackers evolve tactics over time – but in the universe of things you can do, this approach helps narrow your options into something (mostly) manageable. So let’s coarsely group the kinds of adversaries who use DoS attacks. Protection Racketeers: These criminals use a DoS threat to demand ransom money. Attackers hold a site hostage by threatening to knock it down, and sometimes follow

It seems like so long ago that I read the Opposites board books to the kids when they were toddlers. And it was. Today XX2 and the Boy turn 9. It’s hard to believe how quickly the time has flown. Just yesterday I was emailing with an old colleague and I figured his youngest daughter must be in college by now. Turns out she graduated last year and is now in a PhD program. I’m no spring chicken anymore, that’s for sure. On a more dour note, yesterday we remembered the tragedy of 9/11. For us the contrast between 9/11 and 9/12 couldn’t be more pronounced. When the twins were born in 2003, the emotions around 9/11 were still very raw. Yet, after a challenging pregnancy, including carrying close to 13.5 pounds of baby for 37 weeks, the twins showed up the day after. Talk about opposite emotions. But that’s not all that’s opposite. I look at the twins now and they seem like polar opposites. It’s not just their respective genders. XX2 is loud and over the top. The Boy is pretty shy and reserved. Their interests are different. Their strengths are different. Their weaknesses are different. What they eat is different too. It’s like looking at Yin and Yang every day. Obviously dealing with opposites can be challenging at times. But we not only tolerate, we embrace their individuality. We push the kids to be their own people and have their own interests. To find their likes, understand their dislikes and hopefully spend more time doing the former than the latter. They need to embrace the fact they are different from each other, from XX1, and from us. Even though they were born on the same day, that shouldn’t define the twins or their relationship. It was funny visiting camp with them, where we met a bunch of folks who had no idea they were twins. Brother and sister clearly, but also individuals. They weren’t constrained by being in the same grade, getting on the same bus, or having the same family friends. They could just be XX2 and the Boy. They’re lucky, as they’ve always had someone to play with and talk to, even before either could really talk. It’s true that many siblings have that kind of bond, but with twins it’s different. They not only share a birthday, but they share some kind of strange bond that outsiders can’t understand. They probably won’t appreciate it until they get older, but they don’t need to. For now, we’ll live in the moment and wish them a Happy 9th Birthday! -Mike Photo credits: Yin Yang Candy originally uploaded by FadderUri Incite 4 U Research, not hyperbole: The first I heard of the supposed AntiSec/FBI/Apple UDID ‘hack’ last week was via email from a journalist I respect. He was checking in on the plausibility of the scenario. I was out of the office, but after a bit of research my response was (real cut and paste here): “I can’t really say anything informative. Could be true, could be BS, could be data they got from another source and then are pretending is from the FBI. No real way to know what’s true, and the folks who do this sort of thing like using a lot of disinformation.” Thanks to David Schuetz (@DarthNull) we have evidence the data came from an app vendor. The initial denials from the FBI and Apple, and the vendor saying they think it was them, reinforce this. As we continue our journey into the days where chaotic actors directly manipulate the press through social media, perhaps we should keep a little skepticism on the table. (Great work David!) – RM Targeted, not targeted attacks: It’s great that guys like Jay Jacobs have the time to mine security data and sometimes come across some pretty interesting ideas. Many of us make decisions mostly based on anecdotal evidence, which is usually close enough to point you in the right direction. But being able to analyze and quantify things can be cool. Jay just finished up a series examining what he calls opportunistic attacks (Part 1, Part 2), which are basically non-targeted attacks. But that gets back to how you define targeted. We tend to think about a targeted attack as focused on a specific organization, but as Jay shows, the bad guys are actually targeting by focusing their recon activities. They looked for a specific port, usually sending just one packet, and if they didn’t find it open, they moved on to the next target. Evidently it’s a big world and they don’t want to spend a lot of time going deep into a site to find an issue that may or may not be there, so they just move on. So these attackers are actually targeting, but a specific vulnerability rather than a specific victim. – MR A long way to go: Tom’s IT has a visual history of cryptography. What struck me, when looking at cryptography in this way, is how backwards it all seems. Simplistic, unscientific, and less than parlor trick obscurity. It dawns on you just how bad cryptography has been until very recently, and with the rate of change we are seeing, how much further we need to go. When I learned cryptography, DES was widely used and shipping 40-bit encryption algorithms out of the country would get you locked up for violating federal munitions restrictions. There was still a sense of mystery to it. Like most technologies, we have improved exponentially at algorithms and understanding attacks in just the last 10-15 years. But something about this visual representation makes me think we are still in the dark ages of this science. – AL Maximizing your pen test: Good post here on the SpiderLabs blog about how to get the most from your pen test. Yes, it’s a lot of common sense, but that’s okay. Far too many folks apply precious little sense in their daily activities. Their point is to

Back in March I mentioned it was about time for a new set of wheels. Of course nothing happens quickly in my world, so it wasn’t until mid-June that I got serious about a new car. You’d figure a guy like me would relish the opportunity to sit across from a car salesperson and beat them into submission to get the best deal. I’m not the kind of guy to blink, and I’d just as soon walk out if I don’t get what I want. Turns out I’ve been there and done that, and despite living to tell the tale, I have learned there is a better way to skin this specific cat. Of course, not everyone gets this or is willing to listen to a different approach. I remember 8 years ago when my in-laws told me they were going to test drive a new car. I told them not to buy the car that day. Just go in and test drive it. That I’d help them and save them some money. Sure enough they had to drive over to show me their spanking new generic car that they bought right off the lot. From the first dealer they visited. They got a good deal. That was their story and they were sticking to it. But they pretty much got raped. Hard. I just shook my head. But you know, they felt good about it, so I wasn’t about to piss in their oatmeal. But going into a car dealership and buying a car is a pretty stupid way to do things. Regardless of how good a negotiator you are, if you go into a dealership to negotiate for a car you’re doing it wrong. About 10 years ago I was introduced to a service called Fighting Chance. It’s pretty much a research service for car buyers. I get the power of research and tracking trends and leveraging other folks’ experiences to save time and money. That’s what I do for a living, after all. The fine folks at Fighting Chance teach you how to buy the car based on what’s really happening in the field, give you information about promotions and deals, help you figure out the data you need to compare apples to apples, and provide target values for recent sales for the model you are looking for. The service is awesome. It costs something like $40 and has saved me thousands. Their idea is that a car is a commodity. If you live in a typical metropolitan area, each car brand has 10-25 dealers within a short drive who will be happy to sell you a car. The exact same car. It’s not like Dealer A has a different Honda than Dealer B. You don’t buy a commodity by dealing with one seller. Not if you’re smart, anyway. You buy a commodity by getting dealers to compete with each other. I won’t give away the exact process (you should buy the service), but it involves getting dealers to bid against each other. I was able to buy a brand new current model Honda CR-V substantially under invoice by getting bids from 5 local dealers. I handled the process via email and a few phone calls, and it took me a couple hours. By the way, most car dealers hate this approach. They prey on folks who don’t know what they are doing. But it turns out that smart dealers focus on volume and make it up on the back end through incentives and other payments from the manufacturers, with far higher margins on services and trade-ins. These folks love guys like me, since I know exactly what I want and can get the transaction done in an hour. Notice I said CR-V, not Prius V, my preference back in March. Both the Boss and the dealer pointed out to that driving only about 7,000 miles a year means negligible savings in gas, and for 10% less I could get the fully decked-out CR-V instead of a mid-level Prius V. And they were right. Who said I’m inflexible and rock-headed? –Mike Photo credits: USED CAR SALESMAN KITTY originally uploaded by victoriafee 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. Pragmatic WAF Management Securing the WAF Application Lifecycle Integration Policy Management Incite 4 U Showing your true colors: Great post by Conrad Constantine about maintaining your sanity when dealing with a high profile incident. He should know – he was at ground zero for a pretty serious one. He points out that you’ll get to meet some pretty big wheels in your organization, and they will want answers and direction. Even if you don’t have any. He starts by telling you to keep a timeline of exactly what happened. Even if that information never sees the light of day (and likely it won’t) you need it. Conrad provides tips for playing above your pay grade and living to tell about it, and talks about the reality behind the PR spin machine. His point that it always ends at some point, and things go back to the new normal, are exactly right. But the best idea in the post is the reality of how people behave under duress: “Before anything else, no matter what field you work in during times of crisis you will see everyone’s true colors brought forth – not least of which – your own.” What he said. – MR Security Bypass: It’s not that IT users thumb their noses at IT security, as claimed by the author of this analysis of the iPass Mobile Workforce Report. But users sidestep anything that makes work more difficult. If the impediment is security controls on applications or data usage, users find ways around it. Mobile

Wake up. Get the kids ready for school. Exercise (maybe). Drink some coffee. Write. Make calls. Eat (sometimes too much). Write some more. Make more calls. Drink more coffee. Think some big thoughts. Pick up the kids from some activity. Have dinner. Get the kids to bed. Maybe get back to writing. Maybe watch a little TV. Go to bed much too late. Wake up and do it again. That’s an oversimplified view of my life, but it’s not far off. But that isn’t a bad thing – I really enjoy what I do. I reflect at least daily on the deal I cut with Satan to be able to actually make a living as a professional pontificator. But I am always on the run. Until I’m not, because there are times when my frontal lobe just shuts down and I sit in a mostly vegetative state or pass out on our couch. There doesn’t seem to be much in between. Is it healthy? You know, running as fast as you can until you collapse and then getting up and running full tilt again? I’m no runner, but it doesn’t seem to be a prudent way to train or live. A mentor always told me, “It’s not a sprint, it’s a marathon.” With ‘it’ being basically everything. Intuitively I understand the message. But that doesn’t mean anything changes. I still run at the razor’s edge of burnout and implosion, and every so often the machine fails. Yet I still find myself running. Every day. Consulting my lists and getting agitated when there isn’t structure to what needs to get done, especially at home. I’m constantly badgering the Boss for my list of house tasks every Saturday morning, so I can get running. Yet if I’m being honest with myself, I like my lists. More specifically, I like checking things off my lists. I like to feel productive and useful and getting things done helps with that. Again, that doesn’t mean that at the end of a long day or on Sunday afternoon I’m not slipping into that vegetative state. That’s how I recharge and get ready for the next day. This run, collapse, repeat cycle works for me. At least it does for now. In another 15 years, when the kids are out of college and fending for themselves, maybe I’ll have a different opinion. Maybe I’ll want to play golf, lounge by the pool, or sit in a cafe all day and read the newspaper. Or read whatever delivers news to me at that point in time, which is unlikely to be paper. Maybe I’ll just chill out, stop running, and enjoy the fruits of my labor. Then again maybe not. As I look back, I’ve been running at this kind of pace as long as I can remember. But it’s different now. Over the past couple years I stopped worrying about where I’m running to. I just get up every morning and run. Obviously I know the general direction my efforts are pointed in, but I no longer fixate on when I’m going to get there. Or if I’ll ever get there. As long as I’m having fun, it’s all good. And then a funny thing happened. I realized that I have a shot at hitting some of those goals I set many years ago. To actually get to the place I thought I was running to all this time. That’s kind of weird. What happens now? Do I set new goals? Do I slow down? Do I savor my accomplishments and take a bow? I’ll take D) None of the above. I think I’ll just keep running and wind up where I wind up. Seems to have worked out okay for me so far. –Mike Photo credits: Running originally uploaded by zebble 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 Summary: 10 Questions to Ask Your Endpoint Security Management Vendor Platform Buying Considerations Pragmatic WAF Management Securing the WAF Application Lifecycle Integration Policy Management Incite 4 U Massive unpatched java flaw being exploited: First, just the facts. There is a massive remotely exploitable cross platform flaw in the latest version of Java. How exploitable? Just read David Maynor’s description of owning everything including OS X, Windows, and Linux. This is as bad as it gets folks. Here’s the drama: after FireEye posted some info, based on real world exploitations, the attack was quickly added to Metasploit and now any script kiddie can compromise nearly any vulnerable system they can get their hands on. I’m generally not thrilled when Metasploit adds exploit code for 0days without giving defenders any chance in hell of blocking or otherwise mitigating the problem. On the latest Network Security Podcast my co-host Zach mentioned that the exploit itself may have leaked from Immunity, who frequently includes 0days in their pen testing product and doesn’t notify vendors or wait for patches. Once again, we are shooting ourselves in the head as an industry because someone doesn’t like the smell of our feet. – RM Epic security research fail: You know those times when you aren’t paying attention to where you’re walking and you run into a pole? And when you get up you look around and hope no one is watching. That happened to FireEye’s research team last week when they inadvertently stumbled upon a honeypot set up by Kaspersky and made a big stink about a change in attacker tactics. It didn’t take long for the Kaspersky researchers to call them out, and within a few hours FireEye issued a retraction. As my kids say, whoopsie! But this is a manifestation of the race for something newsworthy to fill the media sites with fodder to

WAFs themselves are an application, and as such they provide additional attack surface for your adversaries. Their goal isn’t necessarily to compromise the WAF itself (though that’s sometimes a bonus) – the short-term need is evasion. If attackers can figure out how to get around your WAF, many of its protections become moot. Your WAF needs to be secured, just like any other device sitting out there and accessible to attackers. So let’s start by discussing device security, including deployment and provisioning entitlements. Then we can get into some evasion tactics you are likely to see, before wrapping up with a discussion of the importance of testing your WAFs on an ongoing basis. Deployment Options Managing your WAF pragmatically starts when you plug in the device, which requires you to first figure out how you are going to deploy it. You can deploy WAFs either inline or out of band. Inline entails installing the WAF in front of a web app to block attacks directly. Alternatively, as with Network Access Control (NAC) devices, some vendors to provide an out-of-band option to assess application traffic via a network tap or spanning port, and then use indirect methods (TCP resets, network device integration, etc.) to shut down attack sessions. Obviously there are both advantages and disadvantages to having a WAF inline, and we certainly don’t judge folks who opt for out-of-band deployment rather than risking impact to applications. But as with NAC evasion, out-of-band enforcement can be evaded and presents an additional risk to the application. But balancing risks, such as reduced application protection against possible application disruption, is why you get the big bucks, right? You will also need to consider high availability (HA) deployment architectures. If a WAF device fails and takes your applications with it, that’s a bad day all around. So make sure you can deploy multiple boxes with consistent policy and utilize some kind of non-disruptive failover option (active/active, active/passive, load balancer front-end, etc.). Of course some folks opt for a managed WAF service, so the device doesn’t even sit in their data center. This offloads responsibility for scaling up the implementation, providing high availability, and managing devices (patching, etc.) to the service provider. Additionally, the service provider can offer some obfuscation of your IP addresses, complicating attacker reconnaissance and making WAF evasion harder. Depending on how the service is packaged, the service provider may also provide resources to manage policies. Of course they cannot offload accountability for protecting applications, and a service provider cannot be expected to interface directly with your developers. You should also understand the background of your WAF provider. Are they a security company? Does the WAF provide full application security features, or is it a glorified content distribution network (CDN)? Obviously a service provider isn’t likely to offer the full granular capabilities and policy options of a device in your data center, so you need to balance the security capabilities of a managed WAF service against what you can do yourself. Other Security Considerations Obviously you need to keep attackers away from the physical devices, so ensuring physical security of devices is the first step, and hopefully already largely covered by existing security measures. After that you need to ensure all credentials stored on the device are protected, including the SSL private keys used for SSL interception. You will also need to exercise good security hygiene on the device, which means detailed logging of any changes to device configuration and/or policies. Hopefully the logs will aggregated on an external aggregation system (a log management server) to prevent tampering, and alerts should be sent if logging is turned off. That also means keeping the underlying operating system (for software-based WAFs) and the WAF itself patched and up to date. No different than what you should do for every other security device in your environment. Again, a managed WAF service gets you out of having to update devices and/or WAF software, but make sure you can get access to the appropriate WAF activity logs. Make sure you have sufficient access for forensic investigation, if and when you need to go there. Finally, keep in mind that Denial of Service (DoS) attacks continue to be problematic, targeting applications with layer 7 attacks, in addition to simpler volume-based attacks. Make sure you have sufficent bandwidth to deal with any kind of DoS attack, a sufficiently hearty WAF implementation to deal with the flood, and a DDoS-focused service provider on call to handle additional traffic if necessary. Protecting against DoS attacks is a discipline unto itself, and we plan a series on that in the near future. Provisioning and Managing Entitlements Once you have secured the device, next make sure the policies and device configurations are protected. Take steps to control provisioning and management of entitlements. Given the sensitivity of the WAF, it makes sense to get back to the 3 A’s. Yeah, man, old school. Authorization: Who is allowed to access the WAF? Can they set up policies? Change configurations? Is this a group or set of individuals? Authentication: Once you know who can legitimately get into the device, how will you ensure it’s really them? Passwords? 2-factor authentication? Digital certificates? Retinal scans? Okay, that last was a joke, but this question isn’t. Audit: You want an audit event every time a WAF policy, configuration, entitlement, or anything else is changed. Note that a managed WAF service will complicate your ability to manage entitlements. The service provider will have the ability to change policies and may even be responsible for managing them. Ensure you adequately vet folks who will have access to your policies, with an audit trail. We know we are beating the audit horse, but it’s particularly important in this context. An alternative method for managing access to WAF devices is Privileged User Management (PUM). In this scenario administrators log into some sort of proxy, which manages credentials and provides access only to the WAFs each administrator has authorization for. That’s just one of

The impact of technology cannot be overstated. Not compared to when I was a kid. So we were having dinner over the weekend and XX2 started changing the lyrics to Michael Jackson’s Beat It, by crooning out “Eat It.” Of course, I mentioned that she was creative but hardly original and that Weird Al Yankovic recorded that exact song some 20 years ago. Then the Boy piped in with the chorus to Weird Al’s other Michael Jackson parody, “Fat.” Wait, what? The Boss and I were amazed that he not only knew who Weird Al was, but another of his songs. Upon further interrogation, he admitted that a friend showed him Weird Al’s videos on the Internet. Then I launched into a story about how in the olden days, when MTV played actual music videos, you had to wait by the TV for a video you liked. That the first video I ever saw was the J. Geils Band’s “Centerfold”. I didn’t leave my room for a week after that. Not like today, where they just search YouTube and listen to what they want when they want. Then the Boss talked about how she had to sit by the radio with her little cassette recorder in hand, waiting for her favorite songs. The art was in hitting the Record button (or more likely Record and Play simultaneously) at the perfect time. Not too early or you got a bunch of DJ gibberish, and not too late or you’d miss the first few bars of the song. Stopping recording was a similar high-wire act. Then we described the magic of the double cassette deck/recorder and how that made life a zillion times easier, so we could dub tapes from our friends. I guess now I need to expect a retroactive Cease and Desist letter from the RIAA for 30 years ago, eh? The kid’s response was classic. What’s a cassette, Mommy? It’s hard to comprehend, but these kids have never actually seen a cassette tape. Well, they probably have, but had no idea what it was. I just traded in my old Acura that actually had a cassette player, but I last used it 7 years ago. They have no need to understand what a cassette is. Nor the hoops we jumped through to access the music we wanted. I didn’t have the heart to further complicate things by describing the setup my brother and I had to record music, which included an old condenser mic and a reel-to-reel tape deck. I saved up for months to buy a blank reel-to-reel tape and I remember recording from Casey Kasem’s Top 40 every Sunday. Then I got my portable Panasonic cassette recorder, bought Kiss Alive II and was forever changed. Then we told the story of the first Walkman units, and how liberating it was to be able to play cassettes without having to carry around a 30-pound boom box on your shoulder. And believe me – my boom box was huge, loud, and cool – requiring 8 D batteries. I’d get a hernia just lugging around extra batteries for that beast. Looking back, the Walkman was truly transformative. When I made the analogy to the iPod, but bigger and requiring tapes you could only fit 60 minutes of music on, they kind of got it. But not really. Replaying that conversation in my mind makes me excited for the kinds of crazy stories our kids will tell their kids about those iPods and iPhones back in the olden days. And it also makes me feel old. Really really old. But then again, I can’t even imagine what my folks feel like, remembering when they first got TV… –Mike Photo credits: Cassette Player originally uploaded by grundkonzept 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 Summary: 10 Questions to Ask Your Endpoint Security Management Vendor Platform Buying Considerations Ongoing Controls – File Integrity Monitoring Ongoing Controls – Device Control Pragmatic WAF Management Application Lifecycle Integration Policy Management The WAF Management Process Incite 4 U Another vendor ranking grid. Oh, joy! Our friends at NSS Labs have introduced a new way to compare security vendors, specifically the network security folks: their security value map. One axis is Block Rate, and the other is price per protected mbps. No, I don’t get it either. Actually I do, but I suspect most customers will find this chart of limited value. Especially when 80% of the products are in the ‘good’ quadrant. They must know that way too many users use the quadrant charts to make decisions for them. This chart might help compare devices but it doesn’t help make decisions. In fairness, I really like the work NSS does. Hardly anyone else really tests devices objectively, and I applaud their efforts to remove the bias of vendor-sponsored tests. I also understand the need to have a chart that vendors will license and the genius to set up the tolerances so the greatest percentage of vendors are in the right quadrant to license the report. And their research is very useful to customers who do the work and actually need to understand how devices work. But the other 95% of their audience will ask how they can ‘short’ list just about everything. – MR Fixing a problem that doesn’t exist: Most users don’t regard mobile security problems as a big threat, notes Ben Wood, Director of Research at CCS Insight. No kidding. Even on Android viruses and malware are not generally considered a big threat. Antivirus vendors would like to point out the one or two instances where malware has appeared hoping the FUD will drive a new wave of adoption. AV has had it good for a

Normally we wrap up each blog series with a nice summary that goes through the high points of our research and summarizes what you need to know. But this is a Buyer’s Guide, so we figured it would be more useful to summarize with 10 questions. With apologies to Alex Trebek, here are the 10 key questions we would ask if we were buying an endpoint security management product or service. What specific controls do you offer for endpoint management? Can the policies for all controls be managed via your management console? Does your organization have an in-house research team? How does their work make your endpoint security management product better? What products, devices, and applications are supported by your endpoint security management offerings? What standards and/or benchmarks are offered out of the box for your configuration management offering? What kind of agentry is required for your products? Is the agent persistent or dissolvable? How are updates distributed to managed devices? What is done to ensure the agents are not tampered with? How do you handle remote/disconnected devices? What is your plan to extend your offering to mobile devices and/or virtual desktops (VDI)? Where does your management console run? Do we need a dedicated appliance? What kind of hierarchical management does your environment support? How customizable is the management interface? What kind of reports are available out of the box? What is involved in customizing specific reports? What have you done to ensure the security of your endpoint security management platform? Is strong authentication supported? Have you done an application pen test on your console? Does your engineering team use any kind of secure software development process? Of course we could have written another 10 questions. But these hit the highlights of device and application coverage, research/intelligence, platform consistency/integration, and management console capabilities. This list cannot replace a more comprehensive RFI/RFP, but can give you a quick idea of whether a vendor’s product family can meet your requirements. The one aspect of buying endpoint security management that we haven’t really discussed appears in question 5 (agents) and question 10 – the security of the management capability itself. Attacking the management plane is like a bank rather than individual account holders. If the attacker can gain control of the endpoint security management system, then they can apply malicious patches, change configurations, drop or block file integrity monitoring alerts, and allow bulk file transfers to thumb drives. But that’s just the beginning of the risks if your management environment is compromised. We focused on the management aspects of endpoint security in this series, but remember that we are talking about endpoint security, which means making sure the environment remains secure – both at the management console and agent levels. The endpoint security management components are all mature technology – so look less at specific feature/capability differentiation and more at policy integration, console leverage, and user experience. Can you get pricing leverage by adding capabilities from an existing vendor? Share:

As we wrap up the Endpoint Security Management Buyer’s Guide, we have already looked at the business impact of managing endpoint security and the endpoint security management lifecycle, and dug into the periodic controls (patch and configuration management) and ongoing controls (device control and file integrity monitoring). We have alluded to the platform throughout the posts, but what exactly does that mean? What do you need the platform to do? Platform Selection As with most other technology categories (at least in security), the management console (or ‘platform’, as we like to call it) connects the sensors, agents, appliances, and any other security controls. Let’s list the platform capabilities you need. Dashboard: The dashboard provides the primary exposure to the technology, so you will want to have user-selectable elements and defaults for technical and non-technical users. You will want to be able to only show certain elements, policies, and/or alerts to authorized users or groups, with the entitlements typically stored in the enterprise directory. Nowadays with the state of widget-based interface design, you can expect a highly customizable environment, letting each user configure what they need and how they want to see it. Discovery: You can’t protect an endpoint (or any other device, for that matter) if you don’t know it exists. So once you get past the dashboard, the first key feature of the platform is discovery. The enemy of the security professional is surprise, so make sure you know about new devices as quickly as possible – including mobile devices. Asset Repository Integration: Closely related to discovery is the ability to integrate with an enterprise asset management system/CMDB to get a heads-up whenever a new device is provisioned. This is essential for monitoring and enforcing policies. You can learn about new devices proactively via integration or reactively via discovery. But either way you need to know what’s out there. Alert Management: A security team is only as good as its last incident response, so alert management is key. This allows administrators to monitor and manage policy violations which could represent a breach. Time is of the essence during any response, so the ability to provide deeper detail via drill down and send information into an incident response process is critical. The interface should be concise, customizable, and easy to read at a glance – response time is critical. When an administrator drills down into an alert the display should cleanly and concisely summarize the reason for the alert, the policy violated, the user(s) involved, and any other information helpful for assessing the criticality and severity of the situation. This is important so we will dig deeper later. Policy Creation and Management: Alerts are driven by the policies you implement in the system, so policy creation and management is also critical. We will delve further into this later. System Administration: You can expect the standard system status and administration capabilities within the platform, including user and group administration. Keep in mind that for a larger more distributed environment you will want some kind of role-based access control (RBAC) and hierarchical management to manage access and entitlements for a variety of administrators with varied responsibilities within your environment. Reporting: As we mentioned when discussing the specific controls, compliance tends to funding and drive these investments, so substantiating their efficacy is necessary. Look for a mixture of customizable pre-built reports and tools to facilitate ad hoc reporting – both at the specific control level and across the entire platform. In light of the importance of managing your policy base and dealing with the resulting alerts – which could represent attacks and/or breaches – let’s go deeper into each of those functions. Policy Creation and Management Once you know what endpoint devices are out there, assessing their policy compliance (and remediating as necessary) is where the platform provides value. The resource cost to validate and assess each alert makes filtering relevant alerts becomes critical for successful endpoint security management. So policy creation and management can be the most difficult part of managing endpoint security. The policy creation interface should be accessible to both technical and non-technical users, although creation of heavily customized policies almost always requires technical skill. For policy creation the system should provide some baselines to get you started. For patching you might start with a list of common devices and then configure the assessment and patching cycles accordingly. This works for the other controls as well. Every environment has its own unique characteristics but the platform vendor should provide out-of-the-box policies to make customization easier and faster. All policies should be usable as templates for new policies. We are big fans of wizards to walk administrators through this initial setup process, but more sophisticated users need an “Advanced” tab or equivalent to set up more granular policies for more sophisticated requirements. Not all policies are created equal, so the platform should be able to grade the sensitivity of each alert and support severity thresholds. Most administrators tend to prefer interfaces that use clear, graphical layouts for policies – preferably with an easy-to-read grid showing the relevant information for each policy. The more complex a policy the easier it is to create internal discrepancies or accidentally define an incorrect remediation. Remember that every policy needs some level of tuning, and a good tool will enable you to create a policy in test mode to see how it would react in production, without firing all sorts of alerts or requiring remediation. Alert Management Security folks earn their keep when bad things happen. So you will want all your tools to accelerate and facilitate the triage, investigation, root cause analysis, and process in which you respond to alerts. On a day to day basis admins will spend most of their time working through the various alerts generated by the platform. So alert management/workflow is the most heavily used part of the endpoint security management platform. When assessing the alert management capabilities of any product or service, first evaluate them in terms of supporting