Research

We see continuing confusion regarding the CISO duties in many organizations. When I saw this opinion piece in SC Mag by an experienced CISO (David Nathans) with both commercial and defense sector experience, I figured we might finally get some clarification. Yeah, I should have known better. I have been involved in a lot of debate on whether a CISO should be a technical leader or more of a policy writer. Technical leadership and policy writing are not among the first CISO duties that come to my mind – not even close. David then explains that the CISO’s duties vary by company. Uh, no. Let me try to be clear here. The duty of the CISO is to be responsible and accountable for the organization’s security program. Period. But the definition, objectives, expectations, and funding models for the security program all depend on the organization. Clearly how the security program is implemented varies from company to company. That’s why we see so many experienced business folks taking on the CISO job. Typically after the technical guys fell on their swords, multiple times. I call these folks, “Mr/Ms. Fix It.” They don’t know a lot about security per se. But they know how to get things done in the organization. When you are asking folks to do things they don’t want to do – which is basically always in security – you need someone who either has compromising photos of key execs, or is a credible businessperson with a long track record of accomplishment within the organization. That credibility provides enough runway to get the security program moving. Without CISO credibility any security initiative will be stillborn. He also mentions the need to partner with the business to enable secure innovation; and not putting the organization at risk by pointing out potential issues with emerging business plans, technical services, and partner communications. The security team’s function could be implementation or just be a validation that chosen technology complies with security policy. A CISO and his or her organizational leaders need to be able to direct technical staff to ensure business objectives and risk tolerances are met. That is a critical duty for the CISO, which absolutely requires credibility with the business leaders of the organization. David’s point about the criticality of communications is spot on. Whether it is trying to coerce peers into getting with the security program or providing information about a breach or other attack, the ability to communicate at a high level, in business terms, is absolutely a critical success factor for the CISO. This is no easy task, as the person filling the CISO role needs to be able to articulate complex technical issues and risks effectively and in a way that is clear, quick to the point, can be well understood, and does not cause any unnecessary panic. But let’s not forget that without credibility, the CISO (any executive, for that matter) has very little chance of success. Photo credit: “There goes your credibility” originally uploaded by Hrag Vartanian Share:

We now resume our series on Continuous Security Monitoring. We have dug into the Attack Use Case so it’s time to cover the next most popular use case for security monitoring: Change Control. We will keep the same format as before; digging into what you are trying to do, what data is required to do it, and then how this information can and should guide your prioritization of operational activities. The Change Control Use Case We briefly described the change control use case as follows: An operations-centric use case is to monitor for changes, both to detect unplanned (possibly malicious) changes, and to verify that planned changes complete successfully. There are two aspects, first to determine whether unplanned change indicates an attack – covered in the attack use case. The other aspect is to isolate unplanned any non-malicious changes to figure out why they took occurred outside normal change processes. Finally you need to verify planned and authorized changes to close the operational process loop. Before we discuss the data sources you need we should mention monitoring frequency. As with the attack use case, the NIST definition – monitor as frequently as you need to – fits here as well. For highly critical devices you want to look for changes continuously, because if the device is attacked or suffers a bad change, the result could be or enable data loss. As we mentioned under the attack use case, automation is critical to maintaining a consistent and accurate monitoring process. Ensure you minimize human effort, increase efficiency, and minimize human error. Data Sources To evaluate a specific change you will want to collect the following data sources: Assets: As we discussed in the classification post you cannot monitor what you don’t know about; without knowing how critical an asset is, you cannot choose the most appropriate way to monitor it. This requires an ongoing – dare we say, ‘continuous’ – discovery capability to detect new devices appearing on your network, as well as a mechanism for profiling and classifying them. Work Orders: A key aspect of change control is handling unauthorized and authorized changes differently. To do that you need an idea of which changes are part of a patch, update, or maintenance request. That requires a link to your work management system to learn whether a device was scheduled for work. Patching Process: Sometimes installing security patches is outside the purview of the operations group, and instead something the security function takes care of. Not that we think that’s the right way to run things, but the fact is that not all operational processes are managed in the same system. If different systems are used to manage the work involved in changes and patches, you need visibility into both. Configurations: This use case is all about determining differentials in configurations and software loaded on devices. You need the ability to assess the configuration of devices, and to store a change history so you can review deltas to pinpoint exactly what any specific change did and when. This is critical to determining attack intent. We have always been fans of more data rather than less, so if you can collect device forensics, more detailed events/logs, and/or network full packet captures, as described in the attack use case – do that. But for the change control use case proper, you don’t generally need that data. It is more useful when trying to determine whether the change is part of an attack. Decision Flow Unlike the attack use case, which is less predictable in how you evaluate alerts from the monitoring process, the decision flow for change control is straightforward: Detect change: Through your security monitoring initiative you will be notified that a change happened on a device you are watching. Is this change authorized? Next you will want to cross-reference the change against the work management system(s) which manages all the operational changes in your environment. It is important that you be able to link your operational tracking systems with the CSM environment – otherwise you will spend a lot of time tracking down authorized changes. We understand these systems tend to be run by different operational groups, but in order to have a fully functional process those walls need to be broken down. If authorized, was the change completed successfully? If the change was completed then move on. Nothing else to see here. The hope is that this verification can be done in an automated fashion to ensure you aren’t spending time validating stuff that already happened correctly, so your valuable (and expensive) humans can spend their time dealing with exceptions. If the change wasn’t completed successfully you need to send that information back into the work management system (perhaps some fancy DevOps thing, or your trouble ticket system) to have the work done again. If not authorized, is it an attack? At this point you need to do a quick triage to figure out whether this is an attack warranting further investigation or escalation, or merely an operational failure. The context is important for determining whether it’s an ongoing attack. We will get into that later. If it’s an attack investigate: If you determine it’s an attack you need to investigate. We dealt with this process in both the Incident Response Fundamentals and also React Faster and Better. If it’s not an attack, figure out who screwed up: If you made it to this point the good news is that your unauthorized change is an operational mishap rather than an attack. So you need to figure out why the mistake happened and take corrective measures within the change process to ensure it doesn’t happen again. Let’s make a further clarification on the distinction between the attack and change control use cases. If you have only implemented the change use case and collected the data appropriate for it, then your visibility into what the malware is doing and how broadly it has spread up to this point will be limited. But that doesn’t mean starting with change control doesn’t provide value for detecting attacks. An alert of an

After reading this inane blog post, “Cisco – Buying into the security game,” from an EMEA product manager for HP TippingPoint, the Security Twittersphere rose up together to call out this nonsense. I figured I would just let it lie, but I couldn’t. This is the worst type of competitive positioning – basically calling out a competitor for doing exactly what you have done. I think psychologists call this projection. Let’s just excerpt a few statements from the post, so you can get a good feel for how ridiculous it was. By purchasing Sourcefire, Cisco has all but admitted that they had no relevance in today’s security solutions market. They’re stuck on enhancing the products they have in the market, and making acquisitions to get a foothold in IPS. Huh? You either enhance your existing products or you make an acquisition. Or sometimes both. Is there a third option I’m missing? And for a company with no relevance in today’s security market, Cisco sells a bunch of gear. In fact, substantially more than TippingPoint. And it’s not like HP has been in the network security space for years. They inherited TippingPoint along with the 3Com deal, which they did to enhance their position in network switching, not in security. But those are pesky details, eh? Now I’m not Cisco apologist here. As I wrote in the CSCO/FIRE deal analysis, Cisco isn’t as competitive as they need to be to have a place in the Perimeter Security Gateway market. That’s why they had to write the multi-billion-dollar check. HP TippingPoint is positioned worse then Cisco because they don’t have a FW platform at all, and you need both capabilities (FW, IPS, and other stuff) to be competitive moving forward. As we look at Snort–and know that Cisco has a limited OpenSource track record–one would tend to believe that they’ll eventually just scrap it. Another WTF. This guy has no basis for this statement. Especially after Cisco and Sourcefire publicly committed to future support for Snorty. This is just FUD-mongering nonsense. So, the question remains: Is Cisco serious? Are they REALLY in the security game for the long run? Looking back, surely the time for Cisco to get into the IPS business was 8 years ago, when Check Point failed to acquire Sourcefire–why the game change now? Wow. Cisco has been in the IPS business. But that’s the problem with folks who don’t get out much. They drink their own bathwater and don’t realize the rest of the industry is feeding on their installed base. They poke fun at companies making decisive moves to better their market position, while their city is burning to the ground. Share:

By the time most of you read this I will be on my way back down the east coast, shuttling all the kid’s stuff home after a summer of camp in the family truckster. 12+ hours in pleasant solitude as the Boss flies the kids home. They start school next Monday so we didn’t want them to sit in the car all day. So I’m taking one for the team, but it’s okay. I will spend the solitary time working over my world domination plans. Like I do on every long trip. I’d be lying if I said I’m excited that summer is over. And I know my kids feel the same way. Not that they don’t like school, but they like vacation and camp a lot better. As they should. For the Boss and me, there is something about living carefree for a couple weeks without real parental responsibilities while the kids are away. If the Boss and I wanted to go out to dinner, we did. If we wanted to go to a Braves game, we did. If I wanted to play hooky so we could take a long weekend, we did. But in the 10 months the kids are home we need to be a little more planned. The kids are old enough now to stay by themselves for short amounts of time, so we can be a little spontaneous, and we need to do that. Though it’s incredible how quickly you get back into the daily crap of washing dishes, doing laundry, and shuttling the kids around. It won’t be long before we area again mired in the daily battle to get homework done and get ahead of major projects. It goes with the territory. To be clear, I am excited the kids are coming home. I missed them every day and the house was very calm and quiet. That was nice, but it will also be good to get back to the craziness of our lives. But the end of summer also marks the passage of time. Another season in the books. The start of another school year is one year closer to the kids moving out of the nest and making their way in the world. It’s a reminder that we need to cherish the time they are home. Both the fun stuff and the not-so-fun stuff. I guess that’s the point. For 6+ weeks each summer I see the future. And it’s a good future. But those other 10 months are the present. And it’s a great present. Wrapped up in a bow and everything. –Mike Photo credit: “Summer’s End” originally uploaded by Jeremy Piehler Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. The Endpoint Security Buyer’s Guide Buying Considerations The Impact of BYOD and Mobility Endpoint Hygiene: Reducing Attack Surface Anti-Malware, Protecting Endpoints from Attacks Introduction Continuous Security Monitoring The Attack Use Case Classification Defining CSM Why. Continuous. Security. Monitoring? Database Denial of Service Countermeasures Attacks Introduction API Gateways Implementation Key Management Developer Tools Newly Published Papers Defending Cloud Data with Infrastructure Encryption Network-based Malware Detection 2.0: Assessing Scale, Accuracy, and Deployment Quick Wins with Website Protection Services Email-based Threat Intelligence: To Catch a Phish Network-based Threat Intelligence: Searching for the Smoking Gun Incite 4 U Don’t blame the cloud: I often remind people that the cloud is no more or less secure than your traditional infrastructure – it’s just different. That said, for many organizations the cloud is far more secure because if you properly leverage public it you can outsource security to a provider with better security staffing and controls than you can afford. But, as NASA demonstrates in this piece from The Verge, you can outsource stupid. It seems NASA completely failed to comply with their own security and cloud policies by putting data in a public cloud that shouldn’t be there, failing to include security requirements in contracts, and not bothering to test security controls. Details, details. The cloud can make you more secure but it doesn’t make you smarter. And all this from the guys who built a big chunk of OpenStack. I suppose that explains a few things. – RM ETDR just rolls off the tongue – NOT! I guess you should take comfort in the fact that most analysts are very bad at marketing type stuff. I mean just look at some of the category names they come up with. The latest to draw my ire is Endpoint Threat Detection and Response (ETDR), although you can also put NGFW and NGIPS in the bucket of names I hate. It’s not that ETDR is wrong, but it’s ponderous. And a lot of these technologies aren’t limited to endpoints. I come down on the side of simplicity – only three letters in an acronym. So Endpoint Activity Monitoring and Advanced Endpoint Protection. And throw Perimeter Security Gateway into that mix as well. But in the end those with the biggest megaphones get to name the category, and that ain’t me… – MR Now go to work: Tim Wilson’s post Black Hat: Moving Security Outside The Lines captures the essence of why you should attend Black Hat. If you want to to understand how attackers approach hacking your stuff, the technical conferences are invaluable for learning the attacker mindset. If you’re an IT practitioner who wants to make stuff secure, you are in the wrong place – there really aren’t any step-by-step guides. Defense tactics and research are elsewhere. You go to BH, B-Sides, and DEFCON to learn what the really skilled people have done to break stuff, so you don’t have to. But to find practical applications of that research within your environment you need to do the work. That is what most folks forget. It’s not the hack, but what you do with the information that’s important. – AL New problems? Or

It doesn’t happen very often so it’s highly scrutinized. No, it’s not me being nice to someone. It’s a security company IPO. Last week the folks at FireEye filed their Form S-1, which is the first step toward becoming a public company. The echo chamber blew up, mostly because of FireEye’s P&L. Basically, FireEye spent more on sales and marketing in the first half of 2013 than they took in revenue. Their top line revenue was $61.6MM; they spent $66.1MM on sales and marketing. Their total loss was $63.4MM. Yes, you read that correctly. On the surface that’s pretty ugly. Sure, revenue growth has been significant ($11.3MM, $33.6MM, and $83.3MM; in 2010, 2011, and 2012, respectively). But to lose that much money seems a bit troubling, no? Well, those folks squawking about the losses don’t really understand financial filings too well. In 2012, as I mentioned, they had $83.3MM in revenues. They showed a loss of $35.7MM. But they had positive net cash of $21.5MM in 2012. WTF? Those numbers don’t add up, do they? Keep in mind that bookings does not equal revenue. So FireEye figured out a way to get companies to pay them $75MM more than they could recognize in revenue due to accounting nuances. That’s listed on the balance sheet as Deferred Revenue. They had $43.7MM in current-year deferred revenue (which will be recognized over the coming 12 months), and $32.6MM in revenue deferred for longer than 12 months. And in the first half of 2013 they added another $12MM to their current deferred revenue and over $14MM to non-current deferred. To be clear, they booked a lot more than $83MM in 2012 and a lot more than $61.6MM in the first 6 months. Those revenue numbers are only the stuff they could recognize. The difference between bookings and recognized revenue is services they sold and got paid for now, which they will recognize over the life of the subscription. These multi-year agreements are great for cash flow, but not so great for the income statement. The good news is that companies don’t pay their employees with income statements. The sell-side analysts can do the math to figure out roughly what bookings were, but my point is not to get confused by nuances of the income statement, versus what they actually sell. To be clear, there are a number of issues with that kind of growth in sales and marketing spend. FireEye sees this as a land grab, and the best way to get land is to hire like drunken sailors, put scads of folks in the field, and try to sell product now. It is very expensive to build a global direct sales force, and it is usually done over a long period of time. Clearly FireEye sees their opportunity right now, so they are taking the express train to a huge go-to-market engine. FireEye is making a bet, which you can see in their spending on equipment including demo units (which presumably become production appliances when customers buy). They are betting that once they get a demo box installed on a customer site they will close the deal. They spent $18MM on “property and equipment and demonstration units” last year. That’s a lot of hardware, folks. So they are putting reps everywhere and giving them demo units to get into customer sites before the competition. At some point they will need to dial back the spending and show profits. Ultimately that’s what public company investors demand. But they get a pass on that for the time being because of the huge revenue growth, as well as the need to invest internationally to gain market share now. Which they had better do, because the competition is coming. Pretty much every network security vendor has a network-based malware detection device. They are all gunning for FireEye, which is why FireEye is grabbing as much real estate as they can, right now. Clearly the market for malware detection is red hot and very high profile for enterprises of all sizes. But we don’t expect a stand-alone technology to ultimately prevail for this capability. We expect malware detection to be part of a much bigger security strategy that spans not just the perimeter network, but also endpoints. So FireEye needs a much broader story in the works, or they’ll hit the wall hard. Perhaps they will use public market currency to acquire their way to a broader product line. They have also announced an ecosystem, while remaining focused on the malware detection space. Will that be enough? Time will tell. Listen, I’m not a stock analyst. Personally I cannot invest in the companies I cover, so I don’t have any skin in the game. But I can read a balance sheet, and FireEye is in land grab mode, spending like crazy to build global momentum. Maybe it will pay off and maybe it won’t. Maybe this S-1 is the catalyst they need for a bigger company to acquire them. Maybe they will IPO, broaden their story, and become a sustainable public company. Maybe they don’t. But it will be fun to watch in any case. Photo credit: “DKHouse 082” originally uploaded by May Monthong Share:

We have covered the reasons endpoint security is getting more challenging, and offered some perspective on what is important when buying anti-malware and endpoint hygiene products – or both in an integrated package. Then we addressed the issues BYOD and mobility present for protecting endpoints. To wrap up we just need to discuss the buying considerations driving you toward one solution over another, and develop a procurement process that can work for your organization. Platform Features As in most technology categories (at least in security), the management console (or ‘platform’, as we like to call it) connects the sensors, agents, appliances, and any other security controls. You need several platform capabilities for endpoint security: Dashboard: You should have user-selectable elements and defaults for technical and non-technical users. You should be able to only show certain elements, policies, and alerts to different authorized users or groups, with entitlements typically stored in the enterprise directory. Nowadays, given the state of widget-based interface design, you can expect a highly customizable environment, letting each user configure what they need and how they prefer to see it. Discovery: You cannot protect an endpoint (or any other device) if you don’t know it exists. So the next key platform feature is discovery. Surprise is the enemy of the security professional, so make sure you know about new devices as quickly as possible – including mobile devices. Asset repository integration: Closely related to discovery is the ability to integrate with an enterprise asset management system or CMDB for a heads-up whenever a new device is provisioned. This is essential for monitoring and enforcing policies. You can learn about new devices proactively via integration or reactively via discovery, but either way you need to know what’s out there. Policy creation and management: Alerts are driven by the policies you implement, and of course policy creation and management are also critical. Agent management: Anti-malware defense requires a presence on the endpoint device so you need to distribute, update, and manage agents in a scalable and effective fashion. You need alerts when a device hasn’t updated for a certain period of time, along with the ability to report on the security posture of these endpoints. Alert management: A security team is only as good as its last incident response, so alert management is key. It enables administrators to monitor for potential malware attacks and policy violations which might represent an attack. Time is of the essence during any response, so the ability to provide deeper detail via drill-down, and to send relevant information into a root cause analysis / incident response process, are critical. The interface should be concise, customizable, and easy to read at a glance – responsiveness key. When an administrator drills down into an alert the display should cleanly and concisely summarize the reason for the alert, the policy violated, the user(s) involved, and any other information helpful for assessing criticality and severity. System administration: You can expect the standard system status and administration capabilities within the platform, including user and group administration. For larger distributed environments you will want some kind of role-based access control (RBAC) and hierarchical management to manage access and entitlements for a variety of administrators with varied responsibilities. Reporting: As we mentioned under specific controls, compliance tends to fund and drive these investments, so substantiating their efficacy is necessary. Look for a mixture of customizable pre-built reports and tools to facilitate ad hoc reporting – both at the specific control level and across the entire platform. Cloud vs. Non-cloud The advent of cloud-based offerings for endpoint security has forced many organizations to evaluate the value of running a management server on premise. The cloud fashionistas focus on the benefit of not having to provision and manage a server or set of servers to support the endpoint security offering – which is especially painful in distributed, multi-site environments. They talk about continuous and transparent updates to the interface and feature set of the platform without disruptive software upgrades. They may even mention the ability to have the environment monitored 24/7, with contractually specified uptime. And they are right about all these advantages. But for an endpoint security vendor to manage their offering from the cloud requires more than just loading a bunch of AWS instances with their existing software. The infrastructure now needs to provide data segregation and protection for multi-tenancy, and the user experience needs to be rebuilt for remote management, because there are no longer ‘local’ endpoints on the same network as the management console. Make sure you understand the vendor’s technology architecture, and that they protect your data in their cloud – not just in transit. You also want a feel for service levels, downtime, and support for the cloud offering. It’s great to not have another server on your premise, but if the service goes down and your endpoints are either bricked or unprotected, that on-premise server will look pretty good. Buying Considerations After doing your research to figure out which platforms can meet your requirements, you need to define a short list and ultimately choose something. One of the inevitable decision points involves large vs. small vendors. Given the pace of mergers and acquisitions in the security space, even small vendors may not remain independent and small forever. As a rule, every small vendor is working every day to not be small. Working with a larger vendor is all about leverage. One type is pricing leverage, achieved by buying multiple products and services from the vendor and negotiating a nice discount on all their products. But smaller vendors can get aggressive on pricing as well, and sometimes have even more flexibility to sell cheaper. Another type is platform leverage from using multiple products managed via a single platform. The larger endpoint security vendors offer comprehensive product lines with a bunch of products you might need, and an integrated console can make your life easier. Given the importance of intelligence for tracking malware and keeping current on patches, configurations, and file integrity, it is important to consider the size and breadth of the vendor’s research

When thinking about endpoint security it is important to decide what you consider an endpoint. We define an endpoint as any computing device that can access corporate data. This deliberately broad definition includes not just PCs, but also mobile devices (smartphones and tablets). We don’t think it is too broad – employees today expect to access the data they need, on the device they are using, from wherever they are, at any time. And regardless of the details, the data needs to be protected. Of course the buzzword du jour is Bring Your Own Device (BYOD), which means you need to support employee-owned devices, just as you support corporate-owned devices today. These folks go to the local big box retailer and come home with the shiny new iDevice or Android thingy, then show up the next working day expecting their email and access to the systems they need to do their job on the shiny new device. For a while you said no because you couldn’t enforce policies on that device, nor could you assume the employee’s children or friends wouldn’t get into email and check out the draft quarterly financials. Then you were summoned to the CIOs office and told about the new BYOD policy put in place by the CFO to move some of these expensive devices off the corporate balance sheet. At that point, ‘no’ was no longer an option, so welcome to the club of everyone who has to support BYOD – without putting corporate data at risk. The first step is to define the rules of engagement – which means policies. The reality is you probably have policies in place already, so it is a case of going back and revisiting them to ensure they reflect the differences in supporting both mobile devices and the fact thats you may not own said devices. This is a Buyer’s Guide and not a policy guide, so we won’t focus on specific policies, but we will point out that without an updated set of policies to determine what employees can and cannot do – covering both mobile devices and BYOD – you have no shot at controlling anything. BYOD First let’s blow up the misconception that BYOD = mobile devices. Employees may decide they want to run their office applications in a virtual window on their new Mac, not the 4-year-old Windows XP laptop they were assigned. Which means you need to support it, even though you don’t own the device. This changes how you need to provision and protect the device, particularly in terms of enforcement granularity. For devices you don’t own, you need the ability to selectively enforce policies. You cannot dictate what applications employees run on their own machines. You cannot whitelist the websites they visit. You cannot arbitrarily decide nuke a device from orbit if it shows indicators of possible malware. Actually, if your policy says so, you probably can legally control and wipe the device. But it would make you very unpopular if you decided to blow away a device and lost a bunch of personal pictures and videos in the process. So the key with BYOD is granularity. It is reasonable to do a periodic vulnerability scan on the device to ensure it’s patched effectively. It is also reasonable to require the device be encrypted so the corporate data on it is protected. It is fair to block access to corporate networks if the device isn’t configured properly or seems to be compromised. BYOD has several implications for security. Let’s examine the impact of BYOD in terms of the aspects we have discussed already: Anti-malware: If you require anti-malware on corporate owned computers, you probably want to require it on employee-owned machines as well. It also may be required by compliance mandates for devices which access protected information. The question is whether you require each employee to use the corporate standard anti-malware solution. If so, you would use your existing anti-malware solution’s enterprise management console. If not you need the capability to confirm whether anti-malware protection is running on each device on connection. You also need to decide whether you will mandate anti-malware protection for mobile devices, given the lack of malware attacks on most mobile platforms. Hygiene: Under our definition (patch management, configuration management, and device control), the key change for BYOD is reassessment of the security posture of employee-owned device on each connection to the network. Then it comes down to a policy decision on whether you allow insecurely configured or unpatched devices on the network, or you patch and update the device using enterprise management tools. Keep in mind there may be a software licensing cost to use enterprise tools on BYOD devices. The ability to deal with BYOD really comes down to adding another dimension to policy enforcement. You need to look at each policy and figure out whether it needs to change for employee-owned devices. It is also a good idea to make sure you can both visualize and report on employee-owned devices because there will be sensitivity around ensuring they comply with BYOD policies. Mobility We just explained why mobile devices are endpoints, so we need to provide guidance on protecting them. As with most newish technology, the worst initial problem is more than security. The good news is that mobile devices are inherently better protected from attack due to better underlying operating system architectures. That means makes hygiene – including patching, configuration, and determining which applications can and should run on the devices – the key security requirement. That doesn’t mean there is no mobile malware threat. Or that rooting devices, having employees jailbreak them, dealing with new technologies which extend the attack surface such as NFC (Near Field Communications), and attackers exploiting advanced device capabilities, aren’t all real issues. But none of these is currently the most pressing issue. That can and probably will change, as attackers get better and management issues are addressed. But for now we will focus on managing mobile devices. The technologies that enable us to manage mobile devices fall into a

The point of sending the kids to sleepaway camp is that they experience things they normally wouldn’t. They expand their worldviews, meet new people, and do things they might not normally do when under the watchful (and at times draconian) eyes of their parents. As long as it’s legal and appropriate I’m cool. We got a letter from XX1 yesterday. The Boss and I really treasure the letters we get because it gives us some comfort to know that they are 1) still alive, and 2) having fun. All the kids go to Hershey Park at the end of their first month at camp. So I asked in one of my daily messages, what rides did she go on? The letter told me she went on the SooperDooperLooper and also the Great Bear. Two pretty intense roller coasters. Wait, what? When we went to Six Flags over Georgia a few years ago, I spent the entire day coercing her to go on a very tame wooden coaster. I had to bribe her with all sorts of things to get her on the least threatening ride at Universal last year. I just figured she’d be one of those kids who aren’t be comfortable on thrill rides. I was wrong. Evidently she loved the rides, and is now excited to go on everything. She overcame her fears and got it done, without any bribes from me. Which is awesome. And I missed it. I was with XX2 when she rode her first big coaster. But I missed when XX1 inevitably had second thoughts on line, the negotiations to keep her in the line, the anticipation of the climb, the screaming, and then the sense of satisfaction when the ride ends. I was kind of bummed. But then I remembered it’s not my job to be there for absolutely everything. My kids will live their own lives and do things in their own time. And sometimes I won’t be there when that time comes. As long as they get the experiences and can share them with me later, that needs to be enough. So it is. That doesn’t mean I won’t become a Guilt Ninja when she gets home. But I’ll let her off the hook, at a cost. We will need to make a blood oath to ride all the coasters when we go to Orlando next summer. Me, my girls, and a bunch of roller coasters. I don’t think it gets much better than that… –Mike Photo credit: “Great Bear 2” originally uploaded by Steve White Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. The Endpoint Security Buyer’s Guide Endpoint Hygiene: Reducing Attack Surface Anti-Malware, Protecting Endpoints from Attacks Introduction Continuous Security Monitoring The Attack Use Case Classification Defining CSM Why. Continuous. Security. Monitoring? Database Denial of Service Attacks Introduction API Gateways Implementation Key Management Developer Tools Security Analytics with Big Data Deployment Issues Integration New Events and New Approaches Use Cases Introduction Newly Published Papers Network-based Malware Detection 2.0: Assessing Scale, Accuracy, and Deployment Quick Wins with Website Protection Services Email-based Threat Intelligence: To Catch a Phish Network-based Threat Intelligence: Searching for the Smoking Gun Understanding and Selecting a Key Management Solution Incite 4 U Sideshow Bob: One of the advances big data clusters offer SIEM is the capability to collect more data – particularly as vendors begin to capture all network traffic rather than a small (highly filtered) subset. As Mike likes to say, that’s how you react faster and better. But stored data is of little use unless we do something with it – such as extract actionable intel from the data. This is why I stress that you need to stop thinking about “big data” as a lot of data – big data offers a fully customizable technology platform that can help you derive information from data you collect. Don’t be awed by the size – it’s what you do with it that counts. There’s a joke in there somewhere… A big data platform can also handle much larger data, but that’s a sideshow to the main event. – AL Pick a number, any number: I have long argued that we lack the fundamental structural frameworks to even consider measuring economic losses due to cybercrime. We can barely measure losses associated with physical theft – never mind IT. For example, how do you define downtime or response time, so you can measure is cost? I’ll bet your definition doesn’t match the person who sat next to you at your last conference, and neither of you really measures it consistently over the course of a year to produce valid statistics. This is why I slam all the Ponemon loss surveys – no matter how well the survey is built, there aren’t enough people in the world actually tracking these things to provide meaningful data. So it comes as no surprise that a report released by McAfee and the Center for Strategic and International Studies pegs cybercrime losses at somewhere between $300B and $1T. I give them props for honesty – they cite the problems I mentioned and more. But not even governments can make decision based on ranges like that. Maybe we should just say “bigger than a breadbox” and be done with it. – RM Make that a triple mocha grande exfiltration: One of our favorite Canadians (tied with Mr. Molson), Dave Lewis is now writing a blog for CSO Online, and doing a great job. Not that I’m surprised – Dave is not just an epic beard with security kung fu. The dude can write and come up with cool analogies, such as how data exfiltration is like a coffee ring on the table. Huh? Dave points out that like that inexplicable coffee ring, sometimes data is just lost. Then he goes through the fundamentals of incident response and data protection. Even telling a story or two

We have discussed why continuous security monitoring is important, how we define CSM, and finally how you should be classifying your assets to figure out the most appropriate levels of monitoring. Now let’s dig into the problems you are trying to solve with CSM. At the highest level we generally see three discrete use cases: Attacks: This is how you use security monitoring to identify a potential attack and/or compromise of your systems. This is the general concept we have described in our monitoring-centric research for years. Change: An operations-centric use case is to monitor for changes, both to detect unplanned (possibly malicious) changes, and to verify that planned changes complete successfully. Compliance: Finally, there is the check the box use case, where a mandate or guidance requires monitoring and/or scanning technology; less sophisticated organizations have no choice but to do something. But keep in mind the mandated product of this initiative is documentation that you are doing something – not necessarily an improved security posture, identification of security issues, or confirmation of activity. In this post and the next we will dig into these use cases, describe the data sources applicable to each, and deal with the nuances of making CSM work to solve each problem. Before we dig in we need to make a general comment about these use cases. Notice that they are listed from broadest and most challenging, to narrowest and most limited. The attack use case is bigger, broader, and more difficult than change management; compliance is the least sophisticated. Obviously you can define more granular use cases, but these three cover most of what people expect from security monitoring. So if we missed something we are confident you will let us know in the comments. This is a reversal of the order in which most organizations adopt security technologies, and correlates to security program sophistication. Many start with a demand to achieve compliance, then grow an internal control process to deal with changes — typically internal — and finally are ready to address potential attacks, which entails changes to devices posture. Of course the path to security varies widely — many organizations jump right to the attack use case, especially those under immediate or perpetual attack. We made a specific decision to address the broadest use case first — largely because even if you are not yet looking for attacks, you will need to soon enough. So we might as well lay out the entire process, and then show how you can streamline your implementation for the other use cases. The Attack Use Case As we start with how you can use CSM to detect attacks, let’s begin with the NIST’s official definition of Continuous Security Monitoring: Information security continuous* monitoring (ISCM) is maintaining ongoing* awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. *The terms “continuous” and “ongoing” in this context mean that security controls and organizational risks are assessed, analyzed and reported at a frequency sufficient to support risk-based security decisions as needed to adequately protect organization information. Data collection, no matter how frequent, is performed at discrete intervals. NIST 800-137 (PDF) Wait, what? So to NIST ‘continuous’ doesn’t actually mean continuous, but instead a “frequency … needed to adequately protect organization information.” Basically, your monitoring strategy should as continuous as it needs to be. A bit like the fact that advanced attackers are only as advanced as they need to be. We like this clarification, which reflects the fact that some assets need to be monitored at all times, and others not so much. But let’s be a bit more specific about what you are trying to identify in this use case: Determine vulnerable (and exploitable) devices Prioritize remediating those devices based on which have the most risk of compromise Identify malware in your environment Detect intrusion attempts at all levels of your environment Gain awareness and track adversaries in your midst Detect exfiltration of sensitive data Identify the extent of any active compromise and provide information useful in clean-up Verify clean-up and elimination of the threat Data Sources To address this laundry list of goals, you need the following data sources: Assets: As we discussed in classification, you cannot monitor what you don’t know about; without knowing how critical an asset is you cannot choose the most appropriate way to monitor it. As we described in our Vulnerability Management Evolution research, this requires an ongoing (and dare we say “continuous”) discovery capability to detect new devices appearing on your network, and then a mechanism for profiling and classifying them. Network Topology/Telemetry: Next you need to understand the network layout, specifically where critical assets reside. Assets which are accessible to attackers are of course higher priority than inaccessible assets, so it is quite possible to have a device which is technically vulnerable and contains critical data, but is less important than a less-valuable asset which is clearly in harm’s way. Events/Logs: Any technological device generates log and event data. This includes security gear, network infrastructure, identity sources, data center servers, and applications, among others. Patterns in the log may indicate attacks if you know how to look; logs also offer substantiation and forensic evidence after an attack. Configurations: Configuration details and unauthorized configuration changes may also indicate attacks. Malware generally needs to change device configuration to cause its desired behavior. Vulnerabilities: Known vulnerabilities provide another perspective on device vulnerability, can be attacked by exploits in the wild. Device Forensics: An advanced data source would the very detailed information (including memory, disk images, etc.) of what’s happening on each monitored device to identify indicators of compromise and facilitate investigation of potential compromise. But this kind of information can be invaluable to confirm compromise. Network Forensics: Capturing the full packet stream enables replay of traffic into and out of devices. This is very useful for identifying attack patterns, and also for forensics after an attack. That is a broad list of data, but — depending on the sophistication of your CSM process — you may not need all these sources. More data is better than less data, but everyone needs to strike a balance between capturing

This morning Cisco made its first decisive move in the network security space in years, acquiring Sourcefire for $2.7 billion. That represents a 30% premium over Sourcefire’s closing price yesterday. But much more importantly it is a clear signal that Cisco hasn’t given up on security and intends to compete as organizations rebuild their network security around the poorly named next generation application awareness technology. This was a move Cisco had to make. Pure and simple. We suspect there were other bidders to drive the 30% premium on an already rich valuation. But Cisco couldn’t lose out, mostly because there really isn’t anything else to buy for as reasonable a price. If you think $2.7 BILLION is reasonable, at least. The trends are clear. Enterprises are rearchitecting their perimeter security. They want application-aware technology for both firewall and IPS to enforce policies on web-based applications. They want the option to consolidate numerous devices and capabilities onto a common platform enforcing a common policy – what we call a perimeter security gateway. This common platform will also have other capabilities, such as advanced malware protection and web filtering. Cisco had none of the above. So they had no choice. I had joked that Chris Young (Cisco’s GM of Security) had a blank check, but it was only good for Starbucks cards. But I was wrong to joke. With one decisive move Cisco is back in the network security game – in concept, at least. Now they can tell their customers a story about how they haven’t abandoned the ASA platform, and can move forward with innovative and competitive technology from Sourcefire. Cisco can leverage their tremendous distribution reach to drive Sourcefire products well beyond what Sourcefire could do themselves, or likely with any other partner. Of course all this unicorn dust is on paper. Now the work begins to figure out how to wedge Sourcefire’s Agile Security strategy onto the latest Cisco marketecture. You couldn’t take more diametrically opposed paths to market. Cisco relied on marketecture to obscure product issues. Sourcefire focused on product and historically didn’t do a good job of painting a broad and compelling picture, although they have improved over the past 18 months. After the deal closes they need to figure out how to migrate the ASA base onto FirePOWER ASAP. They need to communicate a strong message based on product rather than PowerPoint. Job #1 is to protect what’s left of their installed base and ensure Sourcefire maintains their IPS share in a very competitive market. Of course Palo Alto and Check Point will step up their Cisco displacement efforts bigtime, grabbing all they can in the shortening window until Cisco has a competitive product. Big IT (IBM and HP) have IPS platforms. They will maintain that there is still a market for standalone IPS, and for a while they will be right. But that plays right into Cisco’s hands. Now they both get to compete with Cisco, instead of fighting Sourcefire for the chance to rip out existing Cisco IPS devices. On the firewall front Sourcefire is still playing at a disadvantage. They got into the market late and have been building the technology internally, and it takes time to reach feature parity with companies in the firewall market for a decade. But this deal buys Sourcefire time. Most of the folks still buying Cisco network security gear aren’t innovators. They are the late majority, don’t have overly rigorous requirements, and can wait for the integration story. Check Point, Palo Alto, and Fortinet will continue to fight mano a mano for the NGFW business. Due to the vagaries of Finnish public company trading rules, McAfee will actually be starting their true integration efforts with the acquired Stonesoft technology after Cisco completes the Sourcefire deal (expected in late Q3/early Q4). So what’s in it for Sourcefire? Besides $2.7B? They needed to find a partner at some point. They probably could have waited a bit to prove the viability of their NGFW/NGIPS integrated platform story. But there is a definite advantage to getting paid a high multiple on potential rather than on results. As the wise investor says, you never lose money when you take a profit. And Sourcefire investors are taking lots of profit from this deal. So the timing works well for Sourcefire. For this deal to pay off Cisco needs to hand the network security reins to Marty Roesch and his team. The group will report to Chris Young, but if Marty isn’t driving the security strategy for all Cisco they are missing a huge opportunity. And if they can’t keep Marty visible and engaged beyond his contractual commitment there will be a mass exodus, as we saw with all the other big security deals – with the exception of IBM/Q1 Labs. This is not a slam dunk for Cisco – they still need to do the work and regain their network security mojo, which has been long gone. But they really didn’t have a choice. They wrote a big check to solve a big problem. And it is not much more complicated than that. Share: