Research

The forensics use case we discussed previously is about taking a look at something that already happened. You presume the data is already lost, the horse is out of the barn, and Pandora’s Box is open. But what if we tried to look at some of these additional data types in terms of making security alerts better, with the clear goal of reducing the window between exploit and detection: reacting faster? Can we leverage something like network full packet capture to learn sooner when something is amiss and to improve security? Yes, but this presents many of the same challenges as using log-based analysis to detect what is going on. You still need to know what you are looking for, and an analysis engine that can not only correlate behavior across multiple types of logs, but also analyze a massive amount of network traffic for signs of attack. So when we made the point in Collection and Analysis that these Network Security Analysis platforms need to be better SIEMs than a SIEM, this is what we were talking about. Pattern Matching and Correlation Assuming that you are collecting some of these additional data sources, the next step is to turn said data into actionable information, which means some kind of alerting and correlation. We need to be careful when using the ‘C’ word (correlation), given the nightmare most organizations have when they try to correlate data on SIEM platforms. Unfortunately the job doesn’t get any easier when extending the data types to include network traffic, network flow records, etc. So we continue to advocate a realistic and incremental approach to analysis. Much of this approach was presented (in gory detail) in our Network Security Operations Quant project. Identify high-value data: This is key – you probably cannot collect from every network, nor should you. So figure out the highest profile targets and starting with them. Build a realistic threat model: Next put on your hacker hat and build a threat model for how you’d attack that high value data. It won’t be comprehensive but that’s okay. You need to start somewhere. Figure out how you would attack the data if you needed to. Enumerate those threats in the tool: With the threat models, design rules to trigger based on the specific attacks you are looking for. Refine the rules and thresholds: The only thing we can know for certain is that your rules will be wrong. So you will go through a tuning process to hone in on the types of attacks you are looking for. Wash, rinse, repeat: Add another target or threat and build more rules as above. With the additional traffic analysis you can look for specific attacks. Whether it’s looking for known malware (which we will talk about in the next post), traffic destined for a known command and control network, or tracking a buffer overflow targeted at an application residing in the DMZ, you get a lot more precision in refining rules to identify what you are looking for. Done correctly this reduces false positives and helps to zero in on specific attacks. Of course the magic words are “done correctly”. It is essential to build the rule base incrementally – test the rules and keep refining the alerting thresholds – especially given the more granular attacks you can look for. Baselining The other key aspect of leveraging this broader data collection capability is understanding how baselines change from what you may be used to with SIEM. Using logs (or more likely NetFlow), you can get a feel for what is normal behavior and use that to kickstart your rule building. Basically, you assume what is happening when you first implement the system is what should be happening, and alert if something varies too far from that normal. That’s not actually a safe assumption but you need to start somewhere. As with correlation this process is incremental. Your baselines will be wrong when you start, and you adjust them over time based with operational experience responding to alerts. But the most important step is the start, and baselines help to get things going. Revisiting the Scenario Getting back to the scenario presented in the Forensics use case, how would some of this more pseudo-real-time analysis help reduce the window between attack and detection? To recap that scenario briefly, a friend at the FBI informed you that some of your customer data showed up as part of a cybercrime investigation. Of course by the time you get that call it is too late. The forensic analysis revealed an injection attack enabled by faulty field validation on a public-facing web app. If you were looking at network full packet capture, you might find that attack by creating a rule to look for executables entered into the form fields of POST transactions, or some other characteristic signature of the attack. Since you are capturing the traffic on the key database segment, you could establish a content rule looking for content strings you know are important (as a poor man’s DLP), and alert when you see that type of data being sent anywhere but the application servers that should have access to it. You could also, for instance, set up alerts on seeing an encrypted RAR file on an egress network path. There are multiple places you could detect the attack if you know what to look for. Of course that example is contrived and depends on your ability to predict the future, figuring out the vectors before the attack hits. But at lot of this discipline is based on a basic concept: “Fool me once, shame on you. Fool me twice, shame on me.” Once you have seen this kind of attack – especially if it succeeds – make sure it doesn’t work again. It’s a bit of solving yesterday’s problems tomorrow, but many security attacks use very similar tactics. So if you can enumerate a specific attack vector based on what you saw, there is an excellent

Most organizations don’t really learn about the limitations of event logs, until forensic investigators hold up their hands and explain they know what happened, but aren’t really sure how. Huh? How could that happen? It’s pretty simple: logs are a backward-looking indicator. They can help you piece together what happened, but you can only infer how. In a forensic investigation inferring anything is suboptimal. You want to know, especially given the needs to isolate the root cause of the attack and to establish remediations to ensure it doesn’t happen again. So we need to look at additional data sources to fill in gaps in what the logs tell you. Let’s take a look at a simplified scenario to illuminate the issues. We’ll look at the scenario both from the standpoint of a log-only analysis and then with a few other data sources added. For a more detailed incident response scenario, check out our React Faster and Better paper. The Forensic Limitations of Logs It’s the call you never want to get. The Special Agent on the other end of the line called to give you a heads-up: they found some of your customer data as part of another investigation into some cyber-crime activity that helps fund a domestic terrorist ring. Normally the Feds aren’t interested in giving you a heads-up until their investigation is done, but you have a relationship with this agent from your work together in the local InfraGard chapter. So he did you a huge favor. The first thing you need to do is figure out what was lost and how. To the logs! You aren’t sure how it happened, but you see some strange log records indicating changes on a application server in the DMZ. Given the nature of the data your agent friend passed along, you check the logs on the database server where that data resides as well. Interestingly enough, you find a gap in the logs on the database server, where your system collected no log records for a five-minute period a few days ago. You aren’t sure exactly what happened, but you know with reasonable certainty that something happened. And it probably wasn’t good. Now you work backwards and isolate the additional systems compromised as the attackers made their way through the infrastructure to reach their target. It’s pretty resource intensive, but by searching in the log manager you can isolate devices with gaps in their logs during the window you identified. The attackers were pretty effective, taking advantage of unpatched vulnerabilities (Damn, Ops!) and covering their tracks by turning off logging where necessary. At this point you know the attack path, and at least part of what was stolen, thanks to the FBI. Beyond that you are blind. So what can you do to make sure you aren’t similarly suprised somewhere down the line? You can set the logging system to alert if you don’t get any log records from critical assets in any 2-minute period. Again, this isn’t perfect and will result in a bunch more alerts, but at least you’ll know something is amiss before the FBI calls. With only log data you can identify what was attacked but probably not how the attack happened. Forensics Driven by Broader Data Let’s take a look at an alternative scenario with a few other data sources such as full network packet capture, network flow records, and configuration files. Of course it is still a bad day when you get the call from your pal the Special Agent. Of course Applied Network Security Analysis cannot magically make you omniscient, but how you investigate breaches changes. You still start with the logs on the perimeter server and identify the device that served as the attacker’s initial foothold. But you’ve implemented the Full Packet Capture Sandwich architecture described in the last post, so you are capturing the network traffic in your DMZ. You proceed to the network analysis console (using the full packet capture stream) and search all the traffic to and from the compromised server. Most sessions to that server are typical – standard application traffic. But you find some reconnaissance, and then something pretty strange: an executable injected into the server via faulty field validation on the web app (Damn, Developers!). Okay, this confirms the first point of exploit. Next we go to the target (keeping in mind what data was compromised) and do a similar analysis. Again, with our full packet capture sandwich in place, we captured traffic to/from the database server as well. As in the log-only scenario, we pinpoint the time period when logging was turned off, then perform a search in our analysis console to figure out what happened during that 5-minute period on that segment. Yep, a privileged account turned off logging on the database server and added an admin account to the database. Awesome. Using that account, the attacker dumped the database table and moved the data to a staging server elsewhere on your network. Now you know which data was taken, but how? You aren’t capturing all the traffic on your network (infeasible), so you have some blind spots, but with your additional data sources you are able to pinpoint the attack path. The NetFlow records coming from the compromised database server show the path to the staging server. The configuration records from the staging server indicate what executables were installed, which enabled the attacker to package and encrypt the payload for exfiltration. Further analysis of the NetFlow data shows the exfiltration, presumably to yet another staging server on another compromised network elsewhere. It’s not perfect, because you are figuring out what already happened. But now you can get back to your FBI buddy with a lot more information about what tactics the attacker used, and maybe even evidence that might be helpful in prosecution. Can’t Everyone Get Along? Clearly this is a simplified scenario that perfectly demonstrates the need to collect additional data sources to isolate the root cause and attack path of any

It all started with a simple tweet from The Mogull, which succinctly summed up a lot of the meat grinder of high tech marketing. You see the industry is based on upgrades and refreshes, largely driven by planned obsolescence. Let’s just look at Microsoft Word. I haven’t really used any new functionality since Office 2003. You? They have overhauled the UI and added some cloudiness (which they call Office Live), but it’s really moving deck chairs around. A word processor is a word processor for 95% of the folks out there. Rich was reacting to the constant barrage of “next generation” this and next generation that we are constantly get pitched, while most organizations can’t even make the current generation work. It is becoming rare to survive a vendor briefing without hearing about how their product is NextGen (only their product, of course). This is rampant in the spaces I cover: network and endpoint security. Who hasn’t heard of a next generation firewall? Now we have next generation IPS, and it’s just a matter of time before we see next generation TBD promising to make security easy. We know how this movie ends. To be fair, some innovations really are next generation, and they make a difference to leading edge companies that can take advantage of them. I mentioned NGFW in a tongue-in-cheek fashion, but the reality is that moving away from ports and protocols, to application awareness, is fundamentally different and can be better. But only if the customer can take advantage and build these new application-oriented policies. A NGFW is no better than a CGFW (current generation firewall) without a next-generation rule base to take advantage of the additional capabilities. I guess what I find most frustrating about the rush to the next generation is the arbitrary nature of what is called “next generation”. Our pals at the Big G (that’s Gartner for you Securosis n00bs) recently published a note on NGIPS (next generation IPS), which you can get from SourceFire (behind a reg wall). As the SourceFire folks kindly point out, they have offered many of these so-called next generation functions since 2003 – they just couldn’t tell a coherent story about it. Can something over 6 years old really be next generation? So next generation monikers are crap. Driven by backwards-looking indicators – like most big IT research. SourceFire did a crappy job of communicating why their IPS was different back in the day, and it wasn’t until some other companies (notably the NGFW folks) started offing application-aware IPS capabilities that the infinite wisdom in Stamford decided it was suddenly time for NGIPS. And now this will start a vendor hump-a-thon where every other IPS vendor (yeah, the two left) will need to spin their positioning to say ‘NGIPS’ a lot. Whether they really do NGIPS is besides the point. You can’t let the truth get in way of a marketing campaign, can you? What’s lost in all the NextGen quicksand? What customers need. Most folks don’t need a next generation word processor, but one shows up every 2-3 years like clockwork. Our infrastructure security markets are falling in line with this model. Do we need NextGen key management? NextGen endpoint security? NextGen application protection? Given how well the current generation works, I’d say yes. But here’s the problem. I know this is largely a marketing exercise, so let’s be clear about what we are looking for. Something that works. Call it what you want, but if it’s the same old crap that we couldn’t use before, rebranded as next generation… I’m not interested. And no one else will be either. Share:

In the introduction to our Applied Network Security Analysis series, we talked about monitoring everything and the limitations of a log-centric data collection approach, in our battle to improve security operational processes. Now let’s dig in a little deeper and understand what kind of data collection foundation makes sense, given the types of analysis we need to deal with our adversaries. Let’s define the critical data types for our analysis. First are the foundational elements, which were covered ad nauseum in our Monitoring Up the Stack paper. These include event logs from the network, security, databases, and applications. We have already pointed out that log data is not enough, but you still need it. The logs provide a historical view of what happened, as well as the basis for the rule base needed for actionable alerts. Next we’ll want to add additional data commonly used by SIEM devices – that includes network flows, configuration data, and some identity information. These additional data types provide increased context to detect patterns of potential badness. But this is not enough – we need to look beyond these data types for more detail. Full Packet Capture As we wrote in the React Faster and Better paper: One emerging advanced monitoring capability – the most interesting to us – is full packet capture. These devices basically capture all traffic on a given network segment. Why? The only way you can really piece together exactly what happened is to use the actual traffic. In a forensic investigation this is absolutely crucial, providing detail you cannot get from log records. Going back to a concept we call the Data Breach Triangle, you need three components for a real breach: an attack vector, something to steal, and a way to exfiltrate it. It’s impossible to stop all potential attacks, and you can’t simply delete all your data, so we advocate heavy perimeter egress filtering and monitoring, to (hopefully) prevent valuable data from escaping your network. So why is having the packet stream so important? It is a critical facet of heavy perimeter monitoring. The full stream can provide a smoking gun for an actual breach, showing whether data actually left the organization, and which data. If you look at ingress traffic, the network capture enables you to pinpoint the specific attack vector(s) as well. We will discuss both these use cases, and more, in additional detail later in this series, but for now it’s enough to say that full network packet capture data is the cornerstone of Applied Network Security Analysis. Intelligence and Context Two additional data sources bear mentioning: reputation and malware. Both these data types provide extra context to understand what is happening on your networks and are invaluable for refining alerts. Reputation: Wouldn’t it be great if you knew some devices and/or destinations were up to no good? If you could infer some intent from just an IP address or other identifying characteristics? Well you can, at least a bit. By leveraging some of the services that aggregate data on command and control networks, and on other known bad actors, you can refine your alerts and optimize your packet capture based on behavior, not just on luck. Reputation made a huge difference in both email and web security, and we expect a similar impact on more general network security. This data helps focus monitoring and investigation on areas likely to cause problems. Malware samples: A log file won’t tell you that a packet carried a payload with known malware. But samples of known malware are invaluable when scrutinizing traffic as it enters the network, before it has a chance to do any damage. Of course nothing is foolproof, but we are trying to get smarter and optimize our efforts. Recognizing something that looks bad as it enters the network would provide a substantial jump for blocking malware. Especially compared to other folks, whose game is all about cleaning up the messes after they fail to block it. We will dive into how to leverage these data types by walking through the actual use cases where this data pays dividends later in the series. But for now our point is that more data is better than less, and without building a foundation of data collection analysis is likely futile. Digesting Massive Amounts of Data The challenge of collecting and analyzing a multi-gigabit network stream is significant, and each vendor is likely to have its own special sauce to collect, index, and analyze the data stream in real time. We won’t get into specific technologies or approaches – after all, beauty is in the eye of the beholder – but there are a couple things to look for: Collection Integrity: A network packet capture system that drops packets isn’t very useful, so the first and foremost requirement is the ability to collect network traffic at your speeds. Given that you are looking to use this data for investigation, it is also important to maintain traffic integrity to prove packets weren’t dropped. Purpose-built data store: Unfortunately MySQL won’t get it done as a data store. The rate of insertions required to deal with 10gbps traffic demand something built specifically that purpose. Again, there will be lots of puffery about this data store or that one. Your objective is simply to ensure the platform or product you choose will scale to your needs. High-speed indexing: Once you get the data into the store you need to make sense of it. This is where indexing and deriving metadata become critical. Remember this has to happen at wire speeds, is likely to involve identifying applications (like an application-aware firewall or IDS/IPS), and enriching the data with geolocation and/or identity information. Scalable storage: Capturing high-speed network traffic demands a lot of storage. And we mean a lot. So you need to calibrate onboard storage against archiving approaches, optimizing the amount of storage on the capture devices based on the number of days of traffic to keep. Keep in mind that the metadata

Flat Stanley has it pretty good. If you have elementary school age kids, you probably know all about him. Flat Stanley is a cute story about a kid who gets flattened, and then spends most of the book trying to regain his natural form. Many teachers have kids do a Flat Stanley project, where they color a picture and send it to a friend or relative. The recipient then takes pictures of Flat Stanley doing something from their daily routine and writes a letter to send back with the photo. The kids learn a bit about someone else, and they have to read the letter. Win/win. Last week, XX2 gave me her Flat Stanley to take on a trip. I started at SecTor CA up in Toronto, so Flat Stanley got to take a picture by the CN Tower. While I’m on this topic, I need to shout out for the folks behind SecTor CA. It’s a great conference, with great speakers and a great community. If you are in or around Toronto, you need to get to SecTor CA. They even invited Stanley to get up on stage and talk about his curious life (picture below). The audience was enthralled. Evidently Stanley doesn’t make too many high-profile keynote speeches, so XX2’s teacher showed the class the picture. It was a big hit. Turns out the wonderful Arlen clan also has lots of experience with Flat Stanley. So we traded stories of what they did with Flat Stanley. They even heard tales of Flat Stanley going to London and attending the Royal Wedding. That dude gets around. Then I took Flat Stanley on my annual golf trip with the boys. Why not? That keynote speech business is hard work, and Stanley needed a bit of R&R. I’m pretty sure I should have had Stanley hit a few drives for me since – he couldn’t have done worse. Let’s just say I should stick to writing and pontificating. I did get some good photos of Stanley in the golf cart, and putting in a birdie. Stanley is a child, so I put him to bed before the evening festivities. And that’s all I’ll say about that. But all told, Flat Stanley has a pretty good gig. He travels around the world and experiences interesting stuff. Which, when I come to think about it, is kind of what I do. And I’m not flat either. That would be a win for me. -Mike Photo credits: Mike Rothman on his rockin’ iPhone 4S Incite 4 U Getting Binary on Risk Assessment: If there is one thing I can say with a high level of confidence, it’s that math guys will defend math. Alex Hutton doesn’t disappoint, as he critiques Ben Sapiro’s Binary Risk Assessment thought balloon (presented at SecTor CA). Alex is balanced but objects to calling Ben’s approach risk assessment, instead he calls it a way to assess vulnerability severity. Vernacular and semantics – the tools of lawyers and, seemingly, math guys. What I like about Ben’s approach is that it’s simple and quick. Most real risk assessment methods are neither. And given the need to prioritize actions in real time, it’s better to be quick than right to 5 decimal places. So I like Ben’s approach – read it and use it. That doesn’t mean you shouldn’t still push toward true risk quantification (if you have that kind of threshold for pain), but understand that there is a time and place for each approach. – MR NoSQL on NoCloud: I am not surprised that Oracle launched a NoSQL database at OpenWorld. NoSQL threatens the relational DB status quo with cheaper, more agile capabilities, with greater data capacity. What does surprise me is their release of NoSQL on a big-ass big data appliance. So new, yet so old school. This is especially interesting in light of the news that Oracle’s acquiring RightNow while talkin’ smack about how Salesforce.com is the roach motel of cloud. I think some of this puffery is because Oracle was late to adopt the cloud, much as Microsoft was with the Internet, but they are certainly making a concerted cloudy push now. Regardless, the big appliance deployment could really work. It’s anti-cloud, but wears like a comfortable old jacket. And it’s so self-contained that it’s generic storage, like a SAN, and you’ll likely be able to outsource security and maintenance and just worry about pushing data. I think this will be very popular for small enterprises who just need to get work done without worrying too much about new technologies. – AL Security small guy syndrome: I think I have ranted about this one before, but one of my pet peeves is people in security talking about how “We have to educate the users/developers/business/whatever.” Because, more often than not, when they say ‘educate’ they really mean ‘indoctrinate’. To me it always sounds like small guy syndrome – you know, the kid who has all the answers if the stupid world would just listen! Chris Eng pokes at a recent presentation that sounds like it falls into this category. It isn’t that security shouldn’t talk to development or try to work with them, but we will never succeed if we don’t understand their priorities in the context of our own bias. Even then their priorities will never completely align with ours because we have different jobs. So my advice is try to work with developers, but don’t expect to change them – instead assume you will be adding whatever else you need to improve the end product (secure code, right?). – RM Cyber-insurance: Win or Futility? We are starting to see better analyses of whether cyber-insurance makes sense. I have been pretty negative because it wasn’t clear to me that the underwriting was based on any real loss data – which means the environment has been rife Ouija board pricing. There is a good primer on NetworkWorld explaining how to maybe use cyber-insurance effectively, and I have seen a

Today we launch our next blog series, on a topic we believe is critical to success in today’s threat environment. It is network security analysis, a rather grand and nebulous term, but consider this the next step on the path which started with Incident Response Fundamentals and continued with React Faster and Better. The issues are pretty straightforward. We cannot assume we can stop the attackers, so we have to plan for a compromise. The difference between success and failure breaks down to how quickly you can isolate the attack, contain the damage, and then remediate the issue. So we build our core security philosophy around monitoring critical networks and devices, facilitating our ability to find the root cause of any attack. Revisiting Monitor Everything Back in early 2010, we published a set of Network Security Fundamentals, one of which was Monitor Everything. If you read the comments at the bottom of the post, you’ll see some divergent opinions of what everything means to different folks, but nobody really disagrees with broad monitoring as a core tenet of security nowadays. We can thank the compliance gods for that. To understand the importance of monitoring everything, let’s excerpt some research I published back in early 2008 that is still relevant today. New attacks are happening at a fast and furious pace. It is a fool’s errand to spend time trying to anticipate where the issues are. REACT FASTER first acknowledges that all attacks cannot be stopped. Thus, focus remains on understanding typical traffic and application usage trends and monitoring for anomalous behavior, which could indicate an attack. By focusing on detecting attacks earlier and minimizing damage, security professionals both streamline their activities and improve their effectiveness. That post then discusses some data sources you can (and should) monitor, including firewalls, IDS/IPS, vulnerability scans, network flows, device configurations, and content security devices. But we are still looking at this data in terms of profiling what has happened and using that as a baseline. Then watch for variations beyond tolerance and alert when you see them. We still fundamentally believe in this approach. It’s clearly the place to start for most organizations, for which any data is more than they have now. But for maturing security organizations, let’s examine why logs are only the start. Logs are not enough Back when I was in the SIEM space, it was clear that event logs are a great basis for compliance reporting, because they effectively substantiate implemented controls. As long as the logs are not tampered with, at least. But when you are working to isolate a security issue, the logs tell you what happened, but lack the depth to truly understand how it happened. Isolating a security attack using log data requires having logs from all points in the path between attacker and target. If you aren’t capturing information from the application servers, databases, and applications themselves, visibility is severely impaired. Contrast that against the ability to literally replay an attack from a full network packet capture. You could follow along as the attacker broke your stuff. See the path they took to traverse your network, the exploits they used to compromise devices, the data they exfiltrated, and how they covered their tracks by tampering with the logs. Of course this assumes you are capturing the right network traffic along the attacker’s path, and it might not be feasible to capture all traffic all the time. But still, if you look to implement a full network packet capture sandwich (as we described in the React Faster and Better series), incident responders have much more information to work with. We’ll discuss how to deploy the technology to address some of these issues later in this series. Given that you need additional data to do your job, where should you look? The Network Doesn’t Lie For the purposes of this discussion, let’s assume time starts at the moment an attacker gains a foothold in your network. That could be by compromising a device (through whatever means) already on the network, or by having a compromised device connect to the internal network. At that point the attacker is in the house, so the clock is ticking. What do they do next? An attacker will try to move through your environment to achieve their ultimate goal, whether that be compromising a specific data store or adding to their bot army, or whatever. There are about a zillion specific things the attacker could do, and 99% of them depend on the network in some way. They can’t find another target(s) without using the network to locate it. They can’t attack the target without trying to connect to it, right? Furthermore, even if they are able to compromise the ultimate target, the attackers must then exfiltrate the data. So they will try to use the network to move the data. They need the network, pure and simple. Which means they will leave tracks, but only if you are looking. This is why we favor (as described in React Faster and Better) capturing the full network packet data as possible. Attackers could compromise network devices and delete log records. They could generate all sorts of meaningless traffic to confuse network behavioral analysis. But they can’t alter the packet stream as it’s captured, which becomes the linchpin of the data you’ll collect to perform this advanced network security analysis. Data is not information But just collecting data isn’t enough. You need to use the data to draw conclusions about what’s happening in your environment. That requires indexing the data, supplementing and enriching it with additional context, alerting on the data, and then searching through the data to pursue an investigation. This is all technically demanding. Just capturing the full network packet stream requires a purpose-built data store, which does some black magic to digest and index network traffic at sufficient speed to provide usable, actionable information to shorten the exploit window. To get an idea of the magnitude of this challenge, note

As my kids get older, fundamental aspects of their personalities become more apparent. XX1 won the “most inquisitive” award in kindergarten. 5 years later, she still asks questions. Lots of questions. A seemingly endless stream of questions. The Inquisition went into full effect when we went to the Falcons game last weekend. This is the 4th year we’ve had tickets, so it now becoming more about the game, rather than just about the ice cream and other snacks. From the opening kickoff until the last touchdown in the 4th quarter, I got a steady stream of questions. Which direction are they going? Why was that a penalty? Who would you root for if the Giants played the Falcons? Should I get a Dippin’ Dots or frozen lemonade? What’s pass interference? Questions, questions, questions. Now I like watching my football. I don’t like to talk during the game. If I do talk, it’s about soft zones, off tackles, and shot plays. I felt myself getting a bit frustrated under the constant barrage of questions. Then I remembered this was my evil plan in the first place. I want the kids to love watching football. I want them to have memories of going to NFL games. If they don’t understand the game they won’t want to go with me, and I’ll be sad. So I spent the time and tried to explain a few easy concepts. Like possessions (the Falcons have the ball, and they are going for that end zone), first downs, and kickoffs/punts. And she started to understand. We had a great time and that’s what it’s all about. I love that she asks questions. She wants to learn and when she doesn’t understand, she asks questions until she does. That’s a lot better than nodding like you get it, but being too proud to admit you don’t. This is a great skill, and over time we’ll work on trying to figure some stuff out herself and then ask the remaining questions. But I need to keep in mind that it’s a patience thing for me as well. I don’t have all the answers – certainly not to an endless stream of questions. So I have to get better about admitting I don’t know, and (given all the devices in our house) walking up to one of my magic boxes to figure it out. So as uncomfortable as the Inquisition may be at times, I wouldn’t have it any other way. -Mike Photo credits: “Spanish Inquisition torture method: the rack” originally uploaded by un_owen Incite 4 U Love and Hate, version 1: I never met Dennis Ritchie, but he certainly had a major impact on my life. As a computer science undergrad at Cal, UNIX and C were everything to me. I lived with The C Programming Language. Literally. Along with The UNIX Programming Environment – neither book ever left my backpack. They remain on my bookshelf to this day. And I hated both. I thought C was a miserable language. Pointer issues, memory leaks, awkward syntax, hard-to-find information. The FAQ for proper uses of the null pointer was 100 pages long. Clearly a language is screwed if it takes 100 pages to describe just one aspect of the language (mostly things you must not do). When I read Creators Admit UNIX, C Hoax, I laughed my ass off because I thought it was true – C was a freakin’ prank. Only years later did a couple UNIX experts really teach me C and UNIX (no, they don’t teach you languages at Cal, they just assume you’re plugged into The Matrix and will imprint them into your brain as needed). Only when they handed me a copy of Using C on the UNIX System did I really start to admire the power of the C language and the beauty of UNIX’s architecture. Both are incredibly powerful, and the essence of flexible and extensible. Ritchie’s passing is a good time to reflect on their landmark achievements and celebrate all the things that we use almost every minute of the day, which have been built on those two standards. – AL If there are so many detection techniques, why do they still suck? Lenny Z highlights the current state of the art for malware detection in a couple articles at SearchSecurity: How antivirus software works: Virus detection technique, and in the deeper Antimalware product suites: Understanding capabilities and limitations, on full endpoint suites. But he begs the question: with all this technology, why can’t we stop the bad guys? Because they have changed tactics. They are going after users and applications, preying on those who haven’t updated their devices and the simply stupid (or ignorant, which is just as good for their purposes). Yes, there are a plenty of easy targets. But whining about what we can’t do isn’t my style, so let’s step back to fundamentals. Assume that devices (at least some of them) are compromised. The ones that must not get compromised (high value assets) should be locked down – even if users squeal like stuck pigs. Monitor the hell out of everything, and do some egress filtering and/or DLP monitoring to make sure stuff doesn’t get out. But we cannot assume that anti-malware provides any security. – MR You already had to do it: There has been a lot of hubbub this week over recent guidance from the SEC that public companies should report on cyber-security risk. This is interesting, because my understanding has been that companies have always been required to report any potentially material risk, no matter its origin. We have seen companies report major breach losses for a while, and in rare cases they report some of the cyber risk (usually as an add-on to a public breach). That the SEC felt they needed to issue additional guidance means that companies were either confused (I don’t see what’s confusing – a loss is a loss), trying to play games, or simply not reporting. So I don’t

As have been overly reported over the past week, Steve Jobs is gone. As Rich so adroitly pointed out, “His death hit me harder than I expected. Because not only do we not have a Steve Jobs in security, we no longer have one at all.” You know, someone who seems to be the master of the universe. Perfection personified. Of course, the reality is never perfection. But what’s perfect is imperfection. Jobs failed. Jobs started over. He took chances and ultimately triumphed. Jobs had the perspective you wished you could have. This is clearly demonstrated by what I believe to be the best speech written in my lifetime (at least so far), Steve Jobs’ Stanford Commencement speech. Why? Because if you pay attention, really pay attention to the words, it’s about the human struggle. Do what you love. Follow your own path. Don’t settle for mediocrity. Live each day to the fullest. Realize we are here for a short time, and act accordingly. It’s not trite. You can and should strive for this. You see impact and legacy works itself out, depending on the actions you take every day. Probably none of us will have an impact like Steve Jobs. Nor should we. You don’t need to be Steve Jobs. Just be you. You don’t have to change the world. Just make it a little better. Be a giver, not a taker. Believe in some kind of karma. Pay it forward. Do the right thing. Lead by example, and hopefully people around you will do the right thing ti. If that happens, we all win, collectively. I’m not going to say don’t change the world. Or don’t try. We need folks who want to change things on a massive scale, and will do the work to make it happen. My point is that it doesn’t have to be you. As Steve Jobs said, “Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma – which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.” Change happens in many forms. We all want to leave the world better than when we got here. That’s what I’m working for. It’s not my place to strive for a legacy or to worry about my impact. All I can do is get up every day and do something positive. Some days will go better than others. And eventually (hopefully many years from now), I’ll be gone. Then it will be up to others to figure out my impact and legacy. Since I don’t know when my time will be up, I had better get back to work. –Mike Photo credits: “Legacy Parkway shield” originally uploaded by CountyLemonade Incite 4 U Take my cards, give me back my wallet: It’s always interesting to see the market value of anything. Not just what you think something is worth. But what someone is actually willing to pay. So thanks to Imperva for mining some bad sites and posting the Current Value of Credit Cards on the Black Market. If you take a look at what’s in my wallet, you’ll see about $15 bucks worth of cards (2 AmEx, a MasterCard, and a bank card). My wallet is worth at least $30, since it’s nice Corinthian leather (said in my best Ricardo Montalban voice). So take my cards, but I’ll fight you for my wallet. – MR Free malware scans: Google announced a Free Safe Browsing Alert for Network Administrators this week, alerting IT when malware is discovered by Google on their machines. The service leverages their malware detection capability announced last year, which discovers malware through a combination of user generated Safe Browsing data and Google’s site indexing crawlers. IT admins can register for alerts when Google discovers malware on the public servers within their control. This free tool will be disruptive to all the security vendors positioning malware detection as a ‘must-have’ feature – so long as it works. Hard to see how folks can continue charging a premium for this ‘differentiating’ service. – AL How about a tour of Alaska? We all know that no matter what you do, bad stuff still happens. As we always say around here, you will be breached at some point. The true test of your security mettle isn’t if you keep the bad guys out, but how you respond when they get in. A lot of that is in the heart of our paper on advanced incident response. One of the main things we talk about in that paper is knowing when, and how, to escalate your incident response process and bring in the next level of experts. While we didn’t explicitly mention it, having your command and control center for air combat drones infected with a virus would be pretty high on the list. It seems the folks on the ground failed to escalate and let the cybersecurity experts get involved. The cybersecurity command learned about it by reading Wired. If a four star general is learning that your control center for those buzzing things sometimes armed with missiles might be a staging depot for the latest warez, it might be time to break out your cold weather gear. -RM Maybe actually do something: OK, time for some snark. I just had to see what pearls of wisdom were in the article 8 ways to become a cloud security expert. Basically it’s a list of conferences and a few blogs. So let me get this straight. Go to RSA or the CSA Congress and you are all of a sudden an expert. C’mon, man! I have a different idea. Why don’t you actually do something in the cloud and protect it. Yeah, maybe build an instance, harden it, configure some security

On reflection I talk about failure a lot. As I look back at my own career experience, FAIL has commonly appeared at inopportune times. Though it’s hard to say you can pinpoint a good time to fail. It’s part of both the business and human experience, so to me failure can be positive and productive, and position you for future success. But not always, and a lot depends on the form it takes. I guess when I think of the wrong kind of failure, I point to Andreas’ post on Network World, Fail a security audit already – it’s good for you. I do understand where he’s coming from. As I mentioned, failure can serve as a catalyst for action, as a good way to assess progress (ask the ATL Falcons about that), or as a way to figure out when it’s time to pack up your tent and move on. I guess my issue is with looking at an audit as a good venue for failure. Why? An audit is an awfully low bar for anything. Yes, I understand that’s a crass generalization. Many auditors are very talented and can find unseen issues and add value. But many aren’t that. Many adhere blindly to their checklists and ensure your security controls fit into a clean little box, even if there isn’t much clean about security in today’s environment. Have you ever heard the story about the scorpion and the frog? I think of it because many auditors adhere to their playbooks, disregarding actual circumstances – like the scorpion in that story. To be clear, the auditor will find something. They always do, or they understand they won’t be invited back. That doesn’t mean the stuff they find really matters. So what’s a better approach? How can you leverage an audit failure to your best advantage? Script it out and use the auditor as a piece of your evil plans. It’s okay – that’s how things get done in the real world. If you are a clued-in security professional, you know where the issues are. At least some of them. You also may face some organizational resistance to fixing issues. So you might direct the audit to miraculously find the issues you want/need fixed. Don’t make it too easy, but make sure they find what you need them to find. Amazingly enough, if something shows up in an audit’s findings of fact, it forces a decision. The decision may be to do nothing, but that will at least be a conscious decision to not address the risk. Then you can move onto the next thing and stop tilting at windmills. Or get the action you need. Either way it’s a win. So I’m all for failing. But fail correctly. Fail with a purpose. Use failure to your advantage. In some cases, actually stage your failure to make a point. I guess my real point is that any failure you face shouldn’t be a total surprise, though that will happen from time to time. Surprise failure is the kind you need to avoid. But that’s another story for another day. Photo credit: “Fail Whale Pale Ale” originally uploaded by jamesplankton Share:

What should you do right now? That’s one of the toughest questions for any security professional to answer. The list is endless, the priorities clear as mud, the risk of compromise ever present. But doing nothing is never the answer. We have been working with practitioners to answer that question for years, and we finally got around to documenting some of our approaches and concepts. That’s what “Fact-Based Network Security: Metrics and the Pursuit of Prioritization” is all about. We spend some time defining ‘risk’, trying to understand the metrics that drive decisions, working to make the process a systematic way to both collect data and make those decisions, and understanding the compliance aspects of the process. Finally we go through a simple scenario that shows the approach in practice. Check out the landing page for the report, if you want a better feel for the content, or download the report directly: Fact-Based Network Security: Metrics and the Pursuit of Prioritization (PDF) We would like to thank RedSeal Networks for sponsoring this research. Finally, if you are looking to check out the blog posts (with comments), here is an index of the posts: Introduction Defining Risk Outcomes and Operational Data Operationalizing the Facts Compliance Benefits In Action Share: