Research

We have finished and put a little bow around our Security Management 2.0: Time to Replace Your SIEM? paper. So it’s time to post the series index, as well as a link to the completed paper. As always, we couldn’t provide content like this without support from our sponsors. For this project, we would like to thank Dell SecureWorks, Nitro Security, Q1 Labs, and Tenable Network Security. Check out the paper in our research library, or you can download it directly: Security Management 2.0: Time to Replace Your SIEM? Index of Posts Time to Replace Your SIEM? (new series) Platform Evolution Revisiting Requirements Platform Evaluation, Part 1 Platform Evaluation, Part 2 Vendor Evaluation – Culling the Short List Vendor Evaluation – Driving the PoC Security Management 2.0: Making the Decision Security Management 2.0: Negotiation Security Management 2.0: Migration Managed Services in a Security Management 2.0 World Share:

Most of the time, the words flow. I have a thought, and the next thing I know there are hundreds (if not thousands) of words on the screen. I’m a writer, so that shouldn’t be surprising. What may be surprising is that there are times I get writer’s block. Like now. At some point in the early part of the week, I get a flash of inspiration and bang out the Incite. It’s usually the easiest part of my job, but not this week. Now (Tuesday night) is not the time to be blocked. Tuesday nights I work late. XX1 is at dance until 8pm, and when I’m in town I pick her up at the studio. The Boss and I have an arrangement where I can catch up on some of my writing and she handles getting the twins ready for bed, since she takes a class Tuesday nights – so I take over when we get home. So I’m sitting here needing to bang out the Incite, but the words just aren’t flowing. I consult my ongoing list of Incite topics. Nothing strikes my fancy. It’s like taking a look in a full refrigerator, but nothing is appealing. Sure there is food there, but it’s not the right food. I hate that. You probably do as well. So I check Twitter. I move on to another project and make some progress on that. I read some NFL news. But in the back of my mind, I know the Incite still awaits me. It’s not going anywhere, and if it’s not done by the time I have to get XX1, it’s going to be a long night. Sometimes panic sets in. I get anxious when the words aren’t there. That doesn’t help them come any easier, of course. If anything it compounds the issue. Still blocked. I walk around a bit. I stretch. I grab another coffee, so now I’m hyper-caffeinated. That’s not helpful either. Oy, I wish I had some writer’s Drano. That would clear up the blockage, even if it hurts the environment. I start writing (again). I get about two paragraphs in and I hate it. I try to rework the concept. I still hate it. So I delete it. Back to square 1. More anxiety. More checking Twitter. More NFL news. No more progress towards where I need to be. I feel the window starting to close, and know that the Boss will be disappointed, since I’ll be working when we’d normally be catching up and enjoying each other’s company. More anxiety and the cycle starts again. Then it happens. Inspiration strikes. I think, why don’t I write about being blocked? Maybe that topic is only interesting to me, but I have always written the Incite for me, documenting what’s in my mind at any given time. Sometimes it’s even useful to someone else, which is a bonus. I start writing. And the words come. The coffee shop disappears. There is no noise. The rest of the world goes away. And before I know it, I’m done. I should have known the words would come. The words always come. I’m lucky that way. But sometimes my impatience gets the better of me. This was one of those times. And the next time I get blocked, I’ll forget that the words come as my anxiety increases. But now I’ll have this post to remind me. How about that? -Mike Photo credits: “Blockage” originally uploaded by Martin Whitmore Incite 4 U Fresh crop of hackers: Brandjacking is the “web site defacement” news item of the decade. The struggle for ownership of the Internet is fascinating – big corporations respond to threats with the tools they know best: lawsuits, marketing campaigns, and lobbying the government. Pressuring the government to get rid of net neutrality, suing customers who have bad experiences, and attempting to outlaw anonymity are prime examples. But this is a losing fight; both because corporations are targeting their customers and because their lame responses show the weakness of their various positions. For example, Google+ not allowing anonymity in their corner of the Internet is effectively forcing people to wear ID cards – and we know how that story ends. Claiming they won’t allow anonymity because attribution promotes civility is crap – it’s because these firms are pissed off that they can’t control their brand image like they did with TV, radio, and magazine media. Rather than accept criticism – or have faith in the majority of people to understand that many negative comments came from psych patients hopped up on Fruit Loops and pharmaceuticals – they threaten legal action. Then we get firms like Reputation.com because business owners need someone to hold their hands when “The Internet” calls them A-holes. Given anti-corporate sentiment; I think we will see a lot more defacement, hacking, and DoS attacks because we are teaching a generation of kids that hacking gives them control they otherwise lack. China may sponsor and educate hackers, but we’re growing them organically. – AL Congressional insanity: The Stop Online Piracy Act is so crazy that it’s hard to imagine anyone taking it seriously. Which is why it seems to have bipartisan support. It is basically a tool for government and media industry censorship. I’m not exaggerating – I don’t support piracy and I pay for the content I consume, but this bill literally forces software developers to add censorship mechanisms to any proxy software. You know, like VPNs and ssh. It also allows the US government to muck with DNS in ways that have broad potential effects beyond merely targeting “file sharing” sites. Take a look and make your own decision, but this is bad for security… completely aside from free speech. – RM FundamentaLiu sound advice: Sometimes folks turn their noses up when I go through my Endpoint or Network Fundamentals pitch. You mean secure configurations, default deny, and patching? Boooooooring. But as Vinnie Liu points out at Dark Reading, these boring tactics actually

Over the past few weeks we have been inundated by the 24/7 media cycle, endlessly fascinated bythe alleged child abuse by a Penn State football coach. I couldn’t bring myself to read the grand jury findings, as I have a young son and the idea of anyone doing that to The Boy makes my blood boil. Regarding the perpetrator, I’m with Jay Glazer. But we Americans do take that innocent until proven guilty thing pretty seriously, so we need to let the legal system play it out. But the other villains in this story are the Penn State administrators, who evidently looked the other way when presented with enough evidence to demand action. Two of them have been criminally charged, and the president of the university and coaching legend Joe Paterno have been forced out. Of course, we really have no way to know exactly what they knew, but the public sentiment is right: the victims deserved a full and immediate law enforcement investigation. That’s pretty cut and dried. But what when it isn’t so cut and dried? We security folks are privy to lots of stuff. Sometimes inadvertently, sometimes not so inadvertently, we get to see information that indicates impropriety. Maybe it’s a situation of financial shenanigans. Like Enron or any of the other folks cooking the books during the stock market bubbles. Perhaps it’s adultery by someone you know. Maybe it’s organized crime or drug dealing in your neighborhood. Wrong is wrong. All three of those examples are wrong, but they also have different risk profiles for coming forward. Many of the folks complicit in the Enron scandal didn’t say anything because they were worried for their jobs – their livelihoods. But still, when you look at it, the right thing to do is to come forward. Is an organization which clearly disregards financial reporting, and systematically cooks the books, a place you would want to work? On the plus side, if you do blow the whistle, you could receive a windfall. Not that you’d use that as motivation, but as Dad told me when I entered the workforce, “No job is worth compromising your integrity.” He’s right. I love the saying: “A friend helps you move, a real friend helps you move a body.” But is that the case? In our adulterer scenario, do you enable the behavior because of your code of guy (or gal) ethics? Considering the emotional fallout and other ramifications of calling someone out on that, do you just let things go? That’s a decision only you can make, but what’s right is not always easy. And what about the local drug dealer? That one is tough because there is a real risk of retribution. These bad guys don’t value your life nearly so much as you do, and you can’t negotiate with them (Anonymous tried – ask them how that worked out). They leave people they don’t like hanging by their own intestines under bridges. And then they hunt down the families of their enemies. Do you put yourself in the way of clear physical harm? Ah, the decision is less clear now, isn’t it? Of course bullies and other folks rely on the threat of cement overshoes as the only tool to maintain their position. But what’s the best decision, given your need to protect your family? So what do you do? Do you speak up or do you shut up? There really are no universal right or wrong answers here, but a set of imperfect choices – all of which can end poorly. Let us know what you think in the comments. Photo credit: See No Evil originally uploaded by tim ellis Share:

I guess if you have been around long enough, you have seen everything over and over again. I felt my age today when I saw yet another (lame) attempt to Move Security from a Cost Center to a Brand Differentiator. How many times have we security folks wished for the day we could get project funding because it helped the business either to make more money or to spend less money? Gosh, that would make life a lot easier. The holy grail has always been to position security as an enabling technology. Unfortunately it just isn’t. The only thing security enables is…uh…nothing. It gets back to assurances, and we security folks can’t make assurances either way. If you spend $X on $widget, maybe it will stop an attack. Maybe it won’t. If you don’t have $widget maybe you won’t even be attacked, so you might as well light a bag of money on fire. It’s like building a house on quicksand. To be fair, in some cases security is table stakes. For example you expect your private data to be protected. In a many cases you will be disappointed, but we don’t really see organizations positioning security as a differentiator. They make those pronouncements to allay our fears and eliminate an obstacle to purchase – not as a buying catalyst. But the most offensive part of the article comes later, in a section that at first seemed kind of logical. But this quote from some guy named Alan Wlasuk almost made me fall out of my chair: “But any company can shine in an industry environment where the majority of their competitors have suffered from confidence destroying security attacks.” Shine? Really? Your suggestion is that companies tells customers to do business with them because they suck less?? That’s how I read Alan’s statement. I’ll admit I clearly didn’t learn too much as a VP Marketing, but I do know it’s a bad idea to position and build campaigns around attributes with little to no longevity. So we should build our brands on being more secure? Unbreakable much? Thanks to our pals at LiquidMatrix for that little chuckle this morning. I thump vendors regularly for trying to run campaigns based on competitor breaches. Like when a token vendor (okay – all of them) tried to capitalize on the RSA token breach by positioning their tokens as more secure, whatever that means. Kicking the competition when they are down comes back to haunt you – we all live in glass housees. Sure enough, some of those very vendors had high profile issues with their own certificate authorities. Karma is a bitch, isn’t it? Take it from someone who has tried to position security as anything but a cost center for close to a decade. It doesn’t work. Your best bet is to realistically show the risk of not doing something, and let business people make their business decisions. And if your marketing folks tell you about this brand spanking new campaign to be launched based on a breach at your competitor, give them my number. I have a clue bat for them. Photo credit: “VISI Black Hat” originally uploaded by delta407 Share:

As we posted the Security Management 2.0 series, we focused heavily on replacing an on-premise option with another on-premise option. We paid a bit of lip service to the managed SIEM/Log Management option, but not enough – the reality is that, under the proper, circumstances a managed service presents an interesting alternative to racking and stacking another set of appliances. So consider this a primer for managed services in the context of our Security Management 2.0 discussion. We will go through the drivers, use cases, and deployment architectures for those considering managed services. And we will provide cautions for areas where a service offering might not meet your expectations. Drivers for Managed Services We have no illusions about the amount of effort required to get a security management platform up and running, or what it takes to keep one current and useful. Many organizations have neither the time nor the resources to implement technology to help automate some of these key functions. So they are trapped on the hamster wheel of pain, reacting without sufficient visibility, but without time to invest in gaining that much-needed visibility into threats without diving deep into raw log files. A suboptimal situation for sure, and one that usually triggers discussions of managed services in the first place. Let’s be a bit more specific about situations where it’s worth a look at managed services. Lack of internal expertise: Even having people to throw at security management may not be enough. They need to be the right people – with expertise in confirming exposures, closing simple issues, and when to pull the alarm and escalate to the investigations team. Reviewing events, setting up policies, and managing the system, all take skills that come with training and time with the product. Clearly this is not a skill set you can just pick up anywhere – finding and keeping talented people is hard – so if you don’t have sufficient sophistication internally, that’s a good reason to check out a service alternative. Scalability of existing platform: You may have a decent platform, but perhaps it can’t scale to what you need for real-time analysis. As we discussed in the Platform Evaluation post, this is common for those deploying first generation database-based SIEM products, who then face a significant and costly upgrade to scale the system. This can also happen to acquisitive organizations, who bring on significant assets and need to integrate management capabilities quickly to get sufficient leverage. With a managed service offering scale is not an issue – any sizable provider is handling billions of events per day. Risk Transference: You have been burned before – that’s why you are looking at alternatives, right? You’re not sure what solution to select for the long haul. Why risk the investment when you can drop that monkey on someone else’s back? This allows you to focus on the functionality you need instead of vendor hyperbole and sniping. Ultimately you only need to be concerned with the application and the user experience, and all that other stuff is the provider’s problem. So selecting a provider becomes effectively an insurance policy to minimize your investment risk. Similarly, if you are worried about your ops team’s ability to keep a broad security management platform up and running, you can transfer operational risk to a safer outside team. Once again, that operational risk goes to the provider, who assumes responsibility for uptime and performance. Geographically dispersed small sites: Managed services also interest organizations which need to support many small locations. Think retail or other distribution-centric organizations, where the central site may have sufficient expertise but there is very little capability at the remote sites. That might work well – particularly if event traffic can be centrally aggregated. But if not, this presents a good opportunity for a service provider who can monitor the remote sites. Round the clock monitoring: Some organizations need to move from a 8-hour/5-day monitoring schedule to a round-the-clock approach. Whether this is driven by a breach, a new regulatory requirement, or some kind of religious awakening in the executive suite, staffing a security operations center (SOC) 24/7 is a huge undertaking. But a service provider can leverage that 24/7 staffing investment across many customers, and might be in a much better position to deliver round-the-clock services. Of course you can’t outsource thinking or accountability, so ultimately the buck stops with the internal team, but under the right circumstances managed services can address skills and capabilities gaps. So let’s dig into a few of the use cases that provide a good fit for managed SIEM or Log Management. Favorable Use Cases Many providers offer a managed SIEM/Log Management platform as the equal of an in-house solution, and that may be the case. Or it might not – depending on the sophistication of the implementation, as well as the capabilities of the provider’s technology and internal processes. Under the right circumstances you can get a managed SIEM offering to do (almost) everything you could with an in-house option, but in reality we very rarely see that. More often we see the following use cases when considering a service alternative: Device Monitoring: You have a ton of network and security devices and you don’t have the resources to properly monitor them. That’s a key situation where managed security management can help. These services are generally architected to aggregate data on your site and ship it to the service provider for analysis and alerting. The provider should have a correlation system to identify issues, and a bunch of analysts who can verify issues quickly and then give you a heads-up. Compliance Reporting: Another no-brainer for a services alternative is basic log aggregation and reporting – typically driven by a compliance requirement. This isn’t a very complicated use case, and it fits well with service offerings. It also gets you out of the business of managing storage and updating reports when a requirement changes. The provider should take care of all that for you.

Heading down into Atlanta last week for the BSides ATL conference, I got into my car and the magic began. I whipped out my magic box and pulled up the address on the Maps app, just to make sure I remembered where it is. Then I fired up Pandora, which dutifully streamed rocking music to my Bluetooth-equipped car stereo. I checked out the NaviGAtor mobile site for real-time traffic data; then I was set and on my way. Wait. What? Think about this for a second. None of what I just described was even possible 4 years ago. I normally just take all this rapid technology evolution for granted, but that day I reflected a bit on how surreal that entire trip was. The idea of having a personalized radio station streaming from the Internet and playing through my car stereo? Ha! Having a fairly accurate map and an idea of traffic before I stumbled into bumper to bumper mayhem? Maybe in a science fiction movie, or something. But no, this stuff happens every day on a variety of smartphones, enabled by fairly ubiquitous wireless Internet connectivity. As another example, Rich just texted me on Monday to let me know he deposited my monthly commission check to our bank from his device, while taking a potty break during a strategy day. Yeah, that’s probably TMI. My bad. Our recently departed leader talked about the sense of “childlike wonder” you get when discovering these applications that enable totally different ways of communicating and living. And it’s true. As I drove down the highway, jamming to my music, with no traffic because I routed around the congestion, I could only marvel at how things have changed. It’s a far cry from my first bag phone. Or that ancient StarTac, which was state of the art, what, five years ago? How can you not be excited by the future? We have only just scratched the surface on how these little computers will change the way we do things. Bandwidth will get broader. Devices will get smarter. Apps will get more capable. And we’ll all benefit. Maybe. It takes a lot of self-control to just enjoy the music while I’m driving. The inclination is to multi-task, at all times. You know, checking Twitter, texting, and catching up on email, in a metal projectile traveling about 70mph, surrounded by other metal projectiles traveling just as fast. That can’t end well. As with everything, there is a downside to this connectivity. It’s hard to just shut down the distractions and think, or to focus enough to stay on the road. It seems the only place I can get some peace is on a plane, and even there I can get WiFi (though I tend not to connect on most flights). The good news is that nothing I do is really that urgent. My Twitter can wait 15 minutes until I stop moving. But it doesn’t mean I don’t have to make a conscious effort to stay focused on the road. I do, and you probably do as well. I guess what is most amazing to me is that my kids have no idea that there was a time when all this stuff didn’t exist. The idea of not being able to text whenever they wanted? Madness. A world without Words with Friends? A time when they could only listen to 10 CDs because that’s all they could carry in their travel bag? They can hardly remember what a CD is. Nor should they. It’s not like when I was a kid I had any concept of a world where we hung out by the radio to get news, sports, entertainment – basically everything. But that’s how my folks grew up. I wonder if someday SkyNet will look back and wonder what things were like before it was self-aware? Oy, that’s a slippery slope. -Mike Photo credits: “Childlike Wonder” originally uploaded by SashaW Incite 4 U Peeking into Dan’s brain: There are a select few folks who really make me think. Like every time I talk to them (which isn’t enough), I have to bring my A game, just to hold a conversation. Dan Geer is one of those folks. So when the Threatpost folks asked Dan about the research agenda in security, he didn’t disappoint. He starts by proposing that we’d need a lot less research if we put into practice what we already know, and that we should research why we don’t do that. Yeah, Dan makes recursive thinking cool. Then there are other nuggets about building systems too complex to effectively manage, the strategic importance of traffic analysis, and the security implications of IPv6. He may not have all those research-grade answers yet, but Dan certainly knows the questions to ask. – MR Johnny doesn’t care: Carnegie Mellon released a research paper called Why Johnny Can’t Opt Out, an examination of tools to thwart online behavioral monitoring, and how users use them. I recommend downloading the paper and taking a quick look at the study – it contains some interesting stuff, but I am a bit disappointed by several aspects. First, the executive summary makes it sound like the tools they surveyed are ineffective, when that’s clearly not the case. They found users were confused by the UIs of the respective products and failed to configure the products correctly. OK, that’s reasonable – most utilities leave a bit to be desired from a user experience standpoint. But not all offerings are like that; for example Ghostery’s setup wizard is dead simple to use, but the data is the data. The other thing that bothered me was not testing NoScript (a fantastic tool!) as another privacy tactic. The final annoyance was their assumption that users do not want privacy tools to hinder usability! WTF? They do understand behavioral advertising is woven into the web’s fabric, right? That “no hindrance” requirement eliminates NoScript, and stymies any effective product, because there’s no way to eliminate certain risks

As our last use case in Applied Network Security Analysis, it’s time to consider breach confirmation: confirming and investigating a breach that has already happened. There are clear similarities to the forensics use case, but breach confirmation takes forensic analysis to the next level: you need to learn the extent of the breach, determining exactly what was taken and from where. So let’s revisit our Forensics scenario to look at how that can be extended to confirm a breach. In that scenario, a friend at the FBI gave you a ring to let you know they found some of your organization’s private data during a cybercrime investigation. In the initial analysis you found the compromised devices and the attack paths, as part of isolating the attack and containing the damage. You cleaned the devices and configured IPS rules to ensure those particular attacks will be blocked in the future. You also added some rules to the network security analysis platform to ensure you are watching for those attack traffic patterns moving forward – just in case the attackers evade the IPS. But you still can’t answer the question: “What was stolen?” with any precision. We know the attackers compromised a device and used it to pivot within your environment to get to the target: a database of sensitive information. We can’t assume that was the only target, and if your attack was like any other involving a persistent attacker, they found multiple entry points and have a presence on multiple devices. So it’s time to head back into your analysis console to figure out a few more things. What other devices were impacted: Start by figuring out how many other machines were compromised by the perimeter device. By searching all traffic originating from the compromised DMZ server, you can see which devices were scanned and possibly owned. Then you can confirm using either the configuration data you’ve been collecting, or by analyzing the machine using an endpoint forensics tool. You may already have some or all of this information already when trying to isolate the attack path. What was taken: Next you need to figure out what was taken. You already know at least one egress path, identified during the initial forensic analysis. Now you need to dig deeper into the egress captures to see if there were any other connections or file transfers to unauthorized sites. The attackers continue to improve their exfiltration techniques, so it’s likely they’ll use both encrypted protocols and encrypted files to make it hard to figure out what was actually stolen. Having the full packet stream allows you to analyze the actual files, though depending on the sophistication of your attacker, you might need specialized help (from third party experts or law enforcement) to break the crypto. Remember that the first wave of forensic investigation focuses on determining the attack paths and gathering enough information to do an initial damage assessment and remediation. From there it’s all about containing the immediate damage as best you can. This next level of forensic analysis is more comprehensive: determine the true extent of the compromise and inventory what was taken. As you can imagine, without having the network packet capture it’s impossible to do this analysis. You would be stuck with log files telling you what happened, but not what, how, or how much was taken. That’s why we keep harping on the need for more comprehensive data on which to base network security analysis. Clearly you can’t capture all the data flowing around your networks, so it’s likely you’ll miss something. But you will have a lot more useful information for responding to attacks than organizations which do not capture traffic. Summary To wrap up our Applied Network Security Analysis series let’s revisit some of the key concepts we’ve covered. First of all, in today’s environment, you can’t assume you will be able to stop a targeted attacker. It is much smarter and more realistic to assume your devices are compromised, and to act accordingly. This assumption puts a premium on detecting successful attacks, preventing breaches, and containing damage. All those functions require data collection to be able to understand what is happening in your environment. Log Data Is Not Enough: Most organizations start by collecting their logs, which is clearly necessary for compliance purposes. But it’s not sufficient – not by a long shot. Additional data – including configuration, network flow, and even the full network packet stream, is key to understanding what is happening in your environment. Forensics: We walked through how these additional data sources can be instrumental in a forensic investigation, ultimately resulting in a breach confirmation (or not). The key objective of forensics is to figure out what happened, and the ability to replay attacks and monitor egress points (using the actual traffic) replaces forensic interpretation with tested fact. And forensics folks like facts much better. Security: These additional data sources are not just useful after an attack has happened, but also to recognize issues earlier. By analyzing the traffic in your perimeter and critical network segments, you can spot anomalous behavior and investigate preemptively. To be fair, the security use cases are predicated on knowledge of what to look for, which is never perfect. But in light of the number of less sophisticated attackers using known attacks, making sure you don’t get hit by the same attack twice is very useful. We all know there are always more projects than your finite resources and funding will allow. So why is network security analysis something that should bubble up to the top of your list? The answer is about what we don’t know – we cannot be sure what the attack will be in the future, but we know it will be hard to detect, and it will steal critical information. We built the Securosis security philosophy on Reacting Faster and Better, by focusing on gathering as much data as possible, which requires an institutional commitment to data collection and analysis.

As we resume our tour of advanced use cases for Network Security Analysis, it’s time to consider malware analysis. Of course most successful attacks involve some kind of malware at some point during the attack. If only just to maintain a presence on the compromised device, some kind of bad stuff is injected. And once the bad stuff is on a device, it’s very very hard to get rid of it – and even harder to be sure. Most folks (including us) recommend you just re-image the device, as opposed to trying to clean the malware. This makes it even more important to detect malware as quickly as possible and (hopefully) block it before a user does something stupid to compromise their device. There are many ways to detect malware, depending on the attack vector, but a lot of what we see today is snuck through port 80 as web traffic. Sure, dimwit users occasionally open a PDF or ZIP file from someone they don’t know, but more often it’s a drive-by download, which means it comes in with all the other web traffic. So we have an opportunity to detect this malware when it enters the network. Let’s examine two situations, one with a purpose-built device to protect against web malware, and another where we’re analyzing malware directly on the network analysis platform. Detecting Malware at the Perimeter As we’ve been saying throughout this series, extending data collection and capture beyond logs is essential to detecting modern attacks. One advantage of capturing the full network packet stream at the ingress point of your network is that you can check for known malware and alert as they enter the network. This approach is better than nothing but it has two main issues: Malware sample accuracy: This approach requires accurate and comprehensive malware samples already loaded into the device to detect the attack. We all know that approach doesn’t work well with endpoint anti-virus and is completely useless against zero-day attacks, and this approach has the same trouble. No blocking: Additionally, once you detect something on the analysis platform, your options to remediate are pretty limited. Alerting on malware entering the network is useful, but blocking it is much better. Alternatively, a new class of network security device has emerged to deal with this kind of sneaky malware, by exploding the malware as it enters the network to understand the behavior of inbound sessions. Again, given the prevalence of unknown zero-day attacks, the ability to classify known bad behavior and see how a packet stream actually behaves can be very helpful. Of course no device is foolproof, but these devices can provide earlier warning of impending problems than traditional perimeter network security controls. Using these devices you can also block the offending traffic at the perimeter if it is detected in time, reducing the likelihood of device compromise. But you can’t guarantee you will catch all malware, so you must figure out the extent of t he compromise. There is also a more reactive approach: analyzing outbound traffic to pinpoint known command and control behavior and targets, which usually indicating a compromised device. At this point the device is already pwned, so you need to contain the damage. Either way, you must figure out exactly what happened and whether you need to sound the alarm. Containing the Damage Based on the analysis on the perimeter, we know both the target device and the originating network address. With our trusty analysis platform we can then figure out the extent of the damage. Let’s walk through the steps: Evaluate the device: First you need to figure out if the device is compromised. Your endpoint protection suite might not be able to catch an advanced attack, so search your analysis platform (and logging system) to find any configuration changes made on the device, and look for any strange behavior – typically through network flow analysis. If the device is still clean all the better. But we will assume it’s not. Profile the malware: Now you know the device is compromised, you need to figure out how. Sure you could just wipe it, but that eliminates the best opportunity to profile the attack. The network traffic and device information enable your analysts to piece together exactly what the malware does, replay the attack to confirm, and profile its behavior. This helps figure out how many other devices have been compromised, because you know what to look for. Determine the extent of the damage: The next step is to track malware proliferation. You can search the analysis platform to look for the malware profile you built in the last step. This might mean looking for communication with the external addresses you identified, identifying command and control patterns, or watching for the indicative configuration changes; but however you proceed, having all that data in one place facilitates identifying compromised devices. Watch for the same attack: You know the saying: “Fool me once, shame on you. Fool me twice, shame on me.” Shame on you if you let the same attack succeed on your network. Add rules to detect and block attacks you have seen for the future. We have acknowledged repeatedly that security professionals get no credit for blocking attacks, but you certainly look like a fool if you get compromised repeatedly by the same attack. You are only as good as your handling of the latest attack. So learn from these attacks; the additional data collection capabilities of network security analysis platforms can give you an advantage, both for containing the damage and for ensuring it doesn’t happen again. As we wrap up this Applied Network Security Analysis series early next week, we will examine the use case of confirming a breach actually happened, and then revisit the key points to solidify our case for capturing network traffic as a key facet of your detection capabilities. Share:

Last week I was invited to speak at Kennesaw State University’s annual cybersecurity awareness day. They didn’t really give me much direction on the topic, so I decided to give my Happyness presentation. I figured there would be students and other employees who could benefit from my journey from total grump to fairly infrequent grump, and a lot of the stuff I’ve learned along the way. One of my key lessons is to accept the way I am and stop trying to be someone else. Despite my public persona I like (some) people. Just not many, and in limited doses. I value and need my solitary time and I have designed a lifestyle to embrace that. I say what I think, and know I can be blunt. Don’t ask me a question if you don’t want the answer. Sure, I have mellowed over the years, but ultimately I am who I am, and my core personality traits are unlikely to change. The other thing I have realized is the importance of managing expectations. For example, I was at SecTor CA a few weeks back, and at the beginning of my presentation on Cloud Security (WMV file), I mentioned the Internet with a snarky, “You know, the place were pr0n is.” (h/t to Rich – it’s his deck). There was a woman sitting literally in the front row who blurted out, “That’s totally inappropriate.” I immediately stopped my pitch, because this was a curious comment. I asked the woman what she meant. She responded that she didn’t think it was appropriate to mention pr0n on a slide in a conference presentation. Yeah, I guess she doesn’t get to many conferences. But it wasn’t something I was going to gloss over. So I responded: “Oh you think so, then this may not be the session for you.” Yes, I really said that, much to the enjoyment of everyone else in the room. I figured given the rest of the content and my presentation style that this wasn’t going to end well. There was no reason for her to spend an hour and be disappointed. To her credit, she got up and found another session, which was the best outcome for both of us. Earlier in my career, I would have let it go. I would probably have adapted my style a bit to be less, uh, offensive. I would have gotten the session done, but it wouldn’t have been my best effort. Now I just don’t worry about it. If you don’t like my style, leave. If you don’t think I know what I’m talking about, leave. If you don’t like my blog posts, don’t read them. It’s all good. I’m not going to feel bad about who I am. Which philosophy is directly from Steve Jobs. “Your time is limited, so don’t waste it living someone else’s life.” I have got lots of problems, but trying to be someone else isn’t one of them. For that I’m grateful. So just be yourself, not who they want you to be. That’s the only path to make those fleeting moments of happiness less fleeting. -Mike Photo credits: “Just be Yourself” originally uploaded by Akami Incite 4 U Keeping tabs on theNurse: I know Brad “theNurse” Smith isn’t familiar to most of you, but if you have been to a major security conference, odds are you have seen him and perhaps met him. I first met Brad 5+ years ago when we worked as Black Hat room proctors together, and have since seen him all over the place. Last week Brad suffered a serious stroke while delivering a presentation at the Hacker Halted conference in Miami, and he still hasn’t regained consciousness. You can get updates on Brad over at the social-engineer.org site, and can leave donations if you want. Maybe I’m identifying a bit too much after my recent health scare on the road, but we feel terrible for Brad and his wife and all of us at Securosis wish them the best. We are also putting our money where our mouths are, and directing (and increasing) our Friday Summary donation his way this week. – RM The weakest link? Your people… I just love stories of social engineering. Yes, there are some very elegant technical attacks, but they seem so much harder than just asking for access to the stuff you need. Like a wiring closet or conference room. Why pick the lock on the door when they’ll just open when you knock? Kai Axford had a great video (WMV) of actually putting his own box into a pen test client’s wiring closet – with help from the network admin – in his SecTor CA presentation. And NetworkWorld has a good story on social engineering, including elegant use of a tape measure. But it’s not like we haven’t seen this stuff before. On my golf trip, we stumbled across Beverly Hills Cop on a movie channel and Axel Foley is one of the best social engineers out there. – MR Token gesture: 403 Labs QSA and PCI columnist Walt Conway noted a major change to the PCI Special Interest Groups (SIGs) this year. The “participating organizations” – a group comprised mostly of the merchants who are part of the PCI Council – will get the deciding vote on which SIGs get to provide the PCI Council advice. Yes, they get a vote on what topics get the option of community guidance. The SIGs do a lot of the discovery and planning work that goes into the guidance ultimately published by the PCI Council – end to end encryption is one example. Unless, of course, someone like Visa objects to the SIG’s guidance, in which case the PCI Council squashes it like a bug – as they did with tokenization. This olive branch is nice, but it’s a token minuscule gesture. – AL Job #1: Keep head attached to body: I joke a lot during presentations about the importance of a public execution

It seems far too much of security research has become like Mel Gibson in “Conspiracy Theory.” Unbalanced, mostly crazy, but not necessarily wrong. But we created this situation, so we have to deal with it. I’m reacting to the media cycle around the Duqu virus, or Son of Stuxnet, identified by F-Secure (among others). You see, no one is interested in product news anymore. No one cares about the incremental features of a vendor widget. They don’t care about success stories. The masses want to hear about attacks. Juicy attacks that take down nuclear reactors. Or steal zillions of dollars. Or result in nudie pictures of celebrities stolen from their computers or cell phones. That’s news today, and that’s why vendor research teams focus on giving the media news, rather than useful information. It started with F-Secure claiming that Duqu was written by someone with access to the Stuxnet source code. Duqu performs reconnaissance rather than screwing with centrifuges, but their message was that this is a highly sophisticated attack, created by folks with Stuxnet-like capabilities. The tech media went bonkers. F-Secure got lots of press, and the rest of the security vendors jumped on – trying to credit, discredit, expand, or contract F-Secure’s findings – anything that would get some press attention. Everyone wanted their moment in the sun, and Duqu brought light to the darkness. But here’s the thing. Everyone saying Duqu and Stuxnet were related in some way might have been wrong. The folks at SecureWorks released research a week later, making contrary claims and disputing any relation beyond some coarse similarities in how the attacks inject code (using a kernel driver) and obscure themselves (encryption and signing using compromised certificates). The media went bonkers again. Nothing like a spat between researchers to drive web traffic to the media. So who is right? That is actually the wrong question. It really doesn’t matter who is right. Maybe Duqu was done by the Stuxnet guys. Maybe it wasn’t. Ultimately, though, to everyone aside from page-whoring beat reporters who benefit from another media cycle, who’s right and who’s wrong about Duqu’s parentage aren’t relevant. The only thing that matters is that you, as a security professional, understand the attack; and have controls in place to protect against it. Or perhaps not – analyzing the attack and accepting its risk is another legitimate choice. This is how the process is supposed to work. A new threat comes to light, and the folks involved early in the cycle draw conclusions about the threat. Over time other researchers do more work and either refute or confirm the original claims. The only thing different now is that much of this happens in public, with the media showing how the sausage is made. And it’s not always pretty. But success in security is about prioritizing effectively, which means shutting out the daily noise of media cycles and security research. Not that most security professionals do anything but fight fires all day anyway. Which means they probably don’t read our drivel either… Photo credit: “Tin Foil Hat” originally uploaded by James Provost Share: