Research

I have bunch of random research thoughts I am working on. I think they are building into a cohesive whole but cannot make any promises. I’m branding these forming ideas as my “research scratchpad”, and will appreciate any feedback. Yesterday, while working with a client, I was asked to define Software Defined Security. This won’t be that post, but as part of discussing the definition and characteristics we got into another concept that has really been standing out to me for a while, and I suspect is on the verge of changing in a big way. Early security was pretty much just another aspect of infrastructure. Access controls, networking, and our minimal other controls were built into the infrastructure. This started changing in the 90’s, into what I call our “outside looking in” posture. The vast majority of security controls starting moving to external tools that are often desynchronized from the underlying infrastructure. This isn’t an absolute rule – the balance has shifted materially to a security control layer, not merely a security management layer… added to infrastructure, not necessarily embedded within it. A heck of a lot of our security involves cutting wires between boxes and inserting new boxes, or adding software agents where no one really wants them. This was a natural, proper evolution – not a mistake or stupidity. It was all we had. But the cloud and virtualization blow this apart in two ways: We are regaining hooks, thanks to APIs, into the infrastructure itself. The security management plane doesn’t necessarily need to be as decoupled as in ‘traditional’ infrastructure architectures. We are losing the ability to insert external security controls into the infrastructure. Adding these integration/choke points adds performance and functional costs beyond those we have learned to generally work around over the past couple decades. The ability to manage large swatches of infrastructure security using the same tools, techniques, and interfaces as those building and maintaining the infrastructure is a major opportunity to remediate many perceived shortcomings of existing security methods. Share:

A key aspect of business today is the extended enterprise. That’s a fancy way of saying no organization does it alone anymore. They have upstream suppliers who help produce whatever it is they produce. They have downstream distribution channels that help them sell whatever needs to be sold. They outsource business processes to third parties who can handle them better and more cheaply. With the advent of advanced communication and collaboration tools, teams work on projects even if they don’t work for the same company or reside on the same continent. Jack Welch coined the term “boundaryless organizations” back in 1990 to describe an organization that is not defined by, or limited to, horizontal, vertical, or external boundaries imposed by a predefined structure. They are common today. In order to make the extended enterprise work, your trading partners need access to your critical information. And that’s where security folks tend to break out in hives. It’s hard enough to protect your networks, servers, and applications, while making sure your own employees don’t do anything stupid to leave you exposed. Imagine your risk – based not just on how you protect your information, but also on how well all your business partners protect their information and yours. Well, actually, you don’t have to imagine that – it’s reality. Let’s do a simple thought exercise to get a feel for the risk involved in one of these interconnected business processes. Let’s say that for cost reasons the decision was made to outsource software maintenance on legacy applications to an offshore provider. These applications run in your datacenter, and maintenance only involves pretty simple bug fixes. You can’t shut down the application, but it’s clearly not strategic. What’s the risk here? Start getting a feel for your exposure by asking some questions: Which of our networks do these developers have access to? How do they connect in? Who are the developers? Has the outsourcer done background checks on them? Are those checks trustworthy? What is the security posture of the outsourcer’s network? What kinds of devices do they use? Even if the developers are trustworthy, can you trust that their machines are not compromised? Yes, you can segment your network to ensure the developers only have access to the servers and code they are responsible for. You can scan devices on connection to your network to ensure they aren’t pwned. You can check the backgrounds of the developers yourself. You can even audit the outsourcer’s network. And you can still get compromised via business partners, because things move too fast to really stay on top of everything. It takes seconds for a machine to be compromised. With one compromised machine your adversary gains presence on your network and can then move laterally to other devices with more access than the developers have. This happens every day. The point is that you have very little visibility into trading partner networks, which means additional attack surface you don’t control. No one said this job was easy, did they? These interconnected business processes will happen whether you like it or not. Even if you think they pose unacceptable risk. You can stamp your feet and throw all the tantrums you want, but unless you can show a business decision maker that the risk of maintaining the connection is greater than the benefit of providing that access you are just Chicken Little. Again. So you need to do your due diligence to understand how each organization accessing your network increases your attack surface. You need a clear understanding of how much risk each of your trading partners presents. So you need to assess each partner and receive a notification of any issues which appear to put your networks at risk. We call this an Early Warning System, and external threat intelligence can give you a head start on knowing which attacks are heading your way. Here is an excerpt from our EWS paper to illuminate the concept. You can shrink the window of exploitation by leveraging cutting-edge research to help focus your efforts more effectively, by looking in the places attackers are most likely to strike. You need an Early Warning System (EWS) for perspective on what is coming at you. None of this is new. Law enforcement has been doing this, well, forever. The goal is to penetrate the adversary, learn their methods, and take action before an attack. Even in security there is a lot of precedent for this kind of approach. Back at TruSecure (now part of Verizon Business) over a decade ago, the security program was based on performing external threat research and using it to prioritize the controls to be implemented to address imminent attacks. Amazingly enough it worked. Following up our initial EWS research, we delved into a few different aspects of threat intelligence, which provides the external content of the EWS. There is Network-based Threat Intelligence and Email-based Threat Intelligence, but both of those sources are more about what’s happening on your networks and with your brands. These really help you understand what’s happening on your partner networks, which clearly pose a risk to your environment. So we are spinning up a new series to continue our threat intelligence arc. This series is called Ecosystem Threat Intelligence and will delve into how to systematically assess your extended network of trading partners to understand the risk they present. Armed with that information you will finally have the information to block a trading partner or tune your defenses based on the risk they pose. As with all our research, we will focus on tangible solutions that can be implemented now, while positioning yourself for future advances. As a reminder, we develop our research using our Totally Transparent Research methodology to make sure you all have an opportunity to let us know when we are right – and more importantly when we are wrong. Finally, we would like to thank BitSight Technologies for potentially licensing the paper at the end of this process. Our next post will delve into the types of information you need to assess your trading partners, and how it

I remember back in my 20s, when I though my success and wealth were assured. I was a high-flying analyst during the Internet bubble and made a bunch of coin. Then I lost a bunch of coin as the bubble deflated. Then I started a software company, which was sold off for the cash on our balance sheet. Then I chased a few hot startups that got less hot once I got there. None had a happy ending. Maybe my timing just sucks. Maybe I wasn’t very good at those specific jobs. Probably some combination of the two. But at the end of the day it doesn’t matter. I have reached the conclusion, 15 years later, that success rarely happens quickly. Some outliers get lucky, know a guy at Instagram, and walk away with big bucks in 18 months, but that is rare. You have a slightly better chance of quick startup riches than winning the lottery, and slightly worse odds than getting run over by a semi walking to the corner store. For every two steps forward, you are likely to take a step and a half back. Sometimes you have a bad day and take 3 steps back. Overnight success is usually 20 years in the making. Conversely, the express train to the mountaintop usually ends with a fall from grace and a mess at the bottom of the hill. Just check out the horror stories of all those folks who won the lottery… and were broke or dead 5 years later. It comes back to sustainability. If the change happens too fast it may not be sustainable, and sooner or later you will be right back where you started. Probably sooner. Small changes that add up over a long period of time become very substantial. Yes, you learned that in elementary school, or perhaps back when you discovered the magic of compound interest. It seems silly but it does work. Let’s take my weight as an example. I have been in good shape. I have been in bad shape as well. It has been a challenge since I was a kid. When I finally make up my mind to drop some pounds, it’s never a straight line. I lose some. I backslide a bit. I try to have more good days than bad. But if I can stay consistent with small changes the trend continues in the right direction. It’s all about tracking those trends. At some point I will get my weight to the point where it’s both comfortable and sustainable. The same goes for the size of the business. I’m looking for higher highs and higher lows, which we have been able to achieve over the past four years. If you’re trying to grow at 15% quarter over quarter, that’s probably not sustainable… not for an extended period of time. But having bigger quarters year over year? Achievable. Definitely. In other words, remember to take the scenic route. If it happens too fast don’t believe it – it’s probably not sustainable. If the trend starts to go against you think differently – what you’re doing may not be working. But don’t be surprised when an instant change vaporizes into thin air. It was never real to begin with… –Mike Photo credit: “November 7 2007 day 27 – Graphs, trends, averages, numbers…” originally uploaded by sriram bala 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. Continuous Security Monitoring The Compliance Use Case The Change Control Use Case 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 It’s you: The slippery use of terminology by the NSA, claiming that they only use metadata and don’t search people’s email content, is ludicrous. In the field of behavioral monitoring we use attributes and metadata (e.g., time of day, location, IP addresses of senders and recipients, type of request, etc.) to detect anomalous behavior – not content! All that’s needed is metadata grouped by or linked to a specific attribute, and then scan for behavioral patterns you deem suspicious. Terrorist detected, right? Keep in mind that an attribute – something like your cellphone number, email address, SIM chip ID, or a random ID token – is used as a reference for you. The NSA neither needs nor wants to read your content, or even know your individual identity, until after they have picked a target, because metadata is all you need for behavioral tracking. This word game is complete BS: saying they are not “reading your email” is a red herring. The fact is you, and your actions, are being monitored. McNealy was right all those years ago. You have no privacy. – AL Pointing the finger at the mirror: Man, Paul Proctor tells the hard truth in No One Cares About Your Security Metrics and You are to Blame. His main point is that senior management asks you for metrics because they have to – not because they want to, or even care. To change this you need to give them information that helps them make better decisions. He then goes through a bunch of metrics that are completely worthless to senior management, including number of attacks and number of unpatched vulnerabilities. Of course Paul doesn’t put any meat into the post because he wants you to become a client, which is fine. There is no free lunch. But I will reiterate a point he makes as well: it’s not that those typical metrics are totally useless. They are quite useful, but only in an operations context.

We spent a bulk of this series defining the major use cases for Continuous Security Monitoring, taking a journey through Attacks, Change Control, and Compliance. We know that many of you tend to be people of action, who want to just get going. But without a proper plan and definition for what you are trying to achieve with your security monitoring initiative, you will just end up with a lot of shiny expensive shelfware. Now you need to decide on the technology platform you will use to aggregate your data sources and perform the CSM analysis. You have a bunch of candidates, and probably a few already operational in your environment – though likely underutilized. We will cover the general requirements you need to cover, and then consider whether an existing platform can satisfy them. Not to spoiler the ending, but shockingly enough it will depend on your use case. Then we will discuss deployment models and the process involved to broaden our use cases. Selecting the CSM Platform Many folks feel their eyes glaze over when someone uses the word ‘platform’. Security folks have a long and tattered history with all sorts of ‘platforms’, none of which have really done what they were supposed (promised) to do. Now we have the opportunity to reset expectations, which is why looking at the CSM platform in terms of use cases is critical. Let’s start with the general platform requirements and what you need: Secure and scalable: Depending on your primary use case and the data sources you choose to aggregate, you may have significant scalability requirements. But for lighter use cases such as compliance, data storage demands are less intense. But we like planning for the future, which means picking a solution that can provide increased scale – even if you don’t need it yet. That comes back to architecture and deployment models, as described in our Security Management 2.0 paper. Keep in mind that the CSM environment includes sensitive data. So you will want to make sure your platform provides adequate security (strong authentication, data protection at rest, data integrity, etc.) to protect your information. Analytics: Monitoring is all about being able to find patterns in disparate data sources, which requires the ability to analyze lots of data. Does that mean you need “big data” analytics? Again it depends on the use case, but make sure you can both look for patterns you already know about (standard attack scenarios) and also unknown situations that are clearly not normal. Agentry: For the attack and change control use cases you will need to get information directly from monitored endpoints, which requires some kind of agent running on the devices. Does it need to be a persistent agent? Not necessarily. You can get much of the data you need via credentialed scans or dissolving agents. But for truly continuous monitoring you will need something on the device looking for indicators of malicious activity. Flexible alerting: Collecting data is good, but alerts make that data useful. You will want to ensure each alert provides enough information for you to actually do something about it. Whether that’s a poor man’s capability to manage an incident, or integration with a broad investigative platform, you will need some way to operationally use the information from the platform. With the increasing availability of third-party threat intelligence, you should also look for the ability to pull in external research feeds to search for specific indicators in the monitored environment. Visualization: A good dashboard environment offers user-selectable elements, and defaults for both technical and non-technical users. The dashboard should focus on the highest-level information (which devices are at risk, aggregate reports, system health, etc.), and provide the ability to drill down as appropriate. Given the current state of technology, a web-based interface with significant customization is now table stakes. Reporting: If compliance is your primary use case, then your requirements are all about reporting. You need to produce artifacts to document how the security monitoring environment substantiates the effectiveness of controls on devices in scope. Even if another use cases is your driver, you will need some measure of ongoing reporting to satisfy compliance requirements. Now that we know what the CSM platform is, let’s take a minute to mention what it doesn’t need to be – at least today: Real time: One of the biggest confusions in security monitoring is ‘real-time’. You are aggregating data from an event that already happened, so it cannot actually be in real time. That said, the sooner you get the data, analyze it, and are able to determine whether you have an issue, the better. Compliance doesn’t require any kind of real-time response. Change control requires more timeliness, for critical devices, and the attack use case can urgently require fast reaction, so the shorter the window between event and alert, the better. But keep in mind that ‘real-time’ alerts aren’t useful if you cannot respond in immediately. If you have a limited triage/investigations staff (and who doesn’t?), that minimizes the relevance of ‘real-time’ response. Big data centric: Big data is all the rage in all sorts of security discussions. But for compliance and change control big data is generally overkill. And depending on the capabilities of your adversaries, advanced analytics may not add value to your efforts. Eventually you may need a true security analytics platform with pseudo-real-time data collection to drive your CSM process. If you are facing truly advanced attackers you might need much more robust searching and forensics capabilities (perhaps including big data analytics). But if you are starting with compliance or change control advanced analytics are likely to be overkill. Doesn’t the SIEM Do This? You could certainly make a case that the SIEM/Log Management product you probably already have in place is in a good position to become the platform for CSM. SIEM does a good job with most of the requirements above. And SIEM already consumes most of the data sources needed for our use cases, with the exception of endpoint forensics and network packet capture… and a number of SIEMs are gaining the ability

Okay, I’m just throwing this one out there because the research is far from complete but I really want to hear what other people think. As I spend more time flying around meeting with security professionals and talking about the cloud, I find that security teams are generally far less engaged with cloud and virtualization projects than I thought. It seems that large swaths of essential enterprise security are almost fully managed by the cloud and virtualization teams, with security often in more of a blind role – if not outright excluded. I’m not saying security professionals are willfully ignorant or anything, but that, for a variety of reasons, they aren’t engaged and often lack important experience with the technology that’s required to even develop appropriate policies – never mind help with implementation. To be honest, it isn’t like most security professionals don’t already have full plates, but I do worry that our workforce may lose relevance if it fails to stay up to date on the ongoing technology shifts enabled by virtualization and the cloud. The less involved we are with the growing reliance on these technologies, the less relevant we are to the organization. I already see a ton of security being implemented by DevOps types who, while experts in their fields, often miss some security essentials because security isn’t their primary role. Not that security has to do everything – that model is long dead. But I fear lack of experience with virtualization and the cloud, and of understanding how fundamentally different those operating models are, could very negatively affect our profession’s ability to accomplish our mission. Share:

Let’s wrap up our use case discussions for Continuous Security Monitoring by digging into how CSM can contribute to your compliance efforts. We know the way we staged these use cases (first attack, then change control) is bass-ackwards from how most folks implement monitoring. Compliance is typically the first use cases implemented, mostly because PCI-DSS mandates it. Regardless of how you adopt the technology, what you want to do is make sure whatever monitoring infrastructure you put in place will be extensible and relevant to all your use cases. We described the compliance use case as: Compliance 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. Dissecting the language above, you see that the goal of compliance is to document and substantiate the controls you have in place to pacify an auditor. It is not to solve actual security problems. Yes, that is a nuance, and if you adequately protect information assets you are likely be able to prove compliance. But the converse is clearly not true. Just being compliant does not mean you are secure. In terms of frequency of monitoring, you have a lot more leeway in this less-stringent use case. In the attack and change control use cases, you need to constantly monitor critical assets to identify dangerous situations. But to be compliant you basically need to assess devices quarterly or so. As long as you are collecting and parsing event logs on protected devices in a secure fashion (PCI Requirement 10), you’re good. Well, in terms of compliance, but not necessarily actual security. To be clear, logging is good. It helps when you have this information during incident response or investigation, so we are happy that PCI and other compliance hierarchies mandate it. PCI also specifically requires assessment after ‘significant’ change (Requirement 11.2.3), but what does that mean? That kind of nebulous verbiage both gives you the leeway to assess and monitor the devices when you want to, and it also gives the PCI council (and card brands) the leeway to string you up during a breach. Compliance mandates like PCI may also specify a more ‘continuous’ monitoring approach such as an IDS (Requirement 11.4), which is also a good practice. But remember – this use case isn’t about being secure – just meeting the base requirements expressly mandated by regulation and/or guidance. So putting up an IDS to monitor your perimeter and fire one alert meets the requirement. Compliance is great, right? We will get down off the soapbox now. Smart security professionals realize that compliance is a means to an end. They can use the compliance mandate to free up budget for equipment and processes that also assist with the attack and change control use cases. Data Sources The data sources you use for compliance tend to be pretty consistent with the attack use case, though without the more sophisticated telemetry and forensic data to really figure out what happened: Assets: Your asset base is the fundamental data source for all use cases. At least that’s consistent – you need an ongoing discovery capability to detect new devices on your network, and then a mechanism for profiling and classifying them. Events & Logs: Pretty much everything can and should be logged as part of the compliance use case – including security gear, network infrastructure, identity sources, data center servers, and applications, among others. This is helpful to demonstrate that the controls in place work, which is the goal of this use case. Patches: Keeping a device up to date is typically mandated by compliance regulations, so you need to generate reports showing which devices were updated when. Configurations: Another aspect of compliance is implementing and maintaining secure configurations. You will need to document the posture of protected devices periodically. Differentials and history are less important because compliance is based on a point-in-time view at your infrastructure. Vulnerabilities: Mandates also require periodic vulnerability scans of protected devices. So you need to document what was scanned, what was found, and eventually what was fixed, if the scan showed clear deficiencies. Other Documentation: Some mandates also require periodic penetration tests and other less automated functions. So you need the ability to store this unstructured data in the CSM repository as well, if it will be used as a compliance automation platform. Preparing for the Audit As opposed to a more action-oriented decision flow, as you saw with the attack and change control use cases, compliance is all about using data to prepare for assessment. You know when you need to be ready – it’s not like auditors show up as mystery shoppers to surprise you. You also know the nature of the documentation you need to provide. Shame on you if you aren’t prepared for an audit, when you know exactly what’s expected and when you need to be ready to deliver it. To help you prepare for an audit and make it as painless as possible, here is a streamlined process adapted from Mike’s Pragmatic CSO methodology. Describe Your Security Program: Wait, what? What about blasting the auditor with all sorts of reports to convince them you know what you’re doing? There is plenty of time for that, but only after you provide context for your security program – specifically how your CSM capabilities provide an accurate and timely view of information needed to understand your compliance posture. Address Past Deficiencies: This is probably not your first audit, so you need to update the auditor on how you addressed previous findings. Here you can leverage your CSM platform to search for specifics and substantiate fixes for issues pointed out in the last assessment. One of the best ways to build your credibility with the assessor is to own your past mistakes and prove that you have fixed things. Substantiate Your Controls: Now you can work through the data, showing the assessor that you have implemented the necessary controls effectively. This documentation should be

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:

Silent Circle is shutting down their email service: However, we have reconsidered this position. We’ve been thinking about this for some time, whether it was a good idea at all. Today, another secure email provider, Lavabit, shut down their system lest they “be complicit in crimes against the American people.” We see the writing the wall, and we have decided that it is best for us to shut down Silent Mail now. We have not received subpoenas, warrants, security letters, or anything else by any government, and this is why we are acting now. Two things: Mail hosting is a bitch. Parsing their words, it appears they were not pressured like Lavabit. We smell a little publicity hunting in this announcement. However: Based on what we are seeing, any data stored on any service anywhere on the Internet is subject to government scrutiny. If you store it they will come. Silent Circle or any provider that stores or processes data is subject to subpoena, National Security Letters, and other local equivalents. This isn’t a US-specific issue, and I think globally we are in for some very interesting conversations as societies attempt to determine what privacy really means in the information age. 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: