Research

As we wrap up our Applied Threat Intelligence series, we have already defined TI and worked our way through a number of the key use cases (security monitoring, incident response, and preventative controls) where TI can help improve your security program, processes, and posture. The last piece of the puzzle is building a repeatable process to collect, aggregate, and analyze the threat intelligence. This should include a number of different information sources, as well as various internal and external data analyses to provide context to clarify what the intel means to you. As with pretty much everything in security, handing TI is not “set and forget”. You need to build repeatable process to select data providers and continually reassess the value of those investments. You will need to focus on integration; as we described, data isn’t helpful if you can’t use it in practice. And your degree of comfort in automating processes based on threat intelligence will impact day-to-day operational responsibilities. First you need to decide where threat intelligence function will fit organizationally. Larger organizations tend to formalize an intelligence group, while smaller entities need to add intelligence gathering and analysis to the task lists of existing staff. Out of all the things that could land on a security professional, an intelligence research responsibility isn’t bad. It provides exposure to cutting-edge attacks and makes a difference in your defenses, so that’s how you should sell it to overworked staffers who don’t want yet another thing on their to-do lists. But every long journey begins with the first step, so let’s turn our focus to collecting intel. Gather Intelligence Early in the intelligence gathering process you focused your efforts with an analysis of your adversaries. Who they are, what they are most likely to try to achieve, and what kinds of tactics they use to achieve their missions – you need to tackle all these questions. With those answers you can focus on intelligence sources that best address your probable adversaries. Then identify the kinds of data you need. This is where the previous three posts come in handy. Depending on which use cases you are trying to address you will know whether to focus on malware indicators, compromised devices, IP reputation, command and control indicators, or something else. Then start shopping. Some folks love to shop, others not so much. But it’s a necessary evil; fortunately, given the threat intelligence market’s recent growth, you have plenty of options. Let’s break down a few categories of intel providers, with their particular value: Commercial: These providers employ research teams to perform proprietary research, and tend to attain highly visibility by merchandising findings with fancy exploit names and logos, spy thriller stories of how adversary groups compromise organizations and steal data, and shiny maps of global attacks. They tend to offer particular strength regarding specific adversary classes. Look for solid references from your industry peers. OSINT: Open Source Intelligence (OSINT) providers specialize in mining the huge numbers of information security sources available on the Internet. Their approach is all about categorization and leverage because there is plenty of information available free. These folks know where to find it and how to categorize it. They normalize the data and provide it through a feed or portal to make it useful for your organization. As with commercial sources, the question is how valuable any particular source is to you. You already have too much data – you only need providers who can help you wade through it. ISAC: There are many Information Sharing and Analysis Centers (ISAC), typically built for specific industries, to communicate current attacks and other relevant threat data among peers. As with OSINT, quality can be an issue, but this data tends to be industry specific so its relevance is pretty well assured. Participating in an ISAC obligates you to contribute data back to the collective, which we think is awesome. The system works much better when organizations both contribute and consume intelligence, but we understand there are cultural considerations. So you will need to make sure senior management is okay with it before committing to an ISAC. Another aspect of choosing intelligence providers is figuring out whether you are looking for generic or company-specific information. OSINT providers are more generic, while commercial offerings can go deeper. Though various ‘Cadillac’ offerings include analysts dedicated specifically to your organization – proactively searching grey markets, carder forums, botnets, and other places for intelligence relevant to you. Managing Overlap With disparate data sources it is a challenge to ensure you don’t waste time on multiple instances of the same alert. One key to determining overlap is an understanding of how the intelligence vendor gets their data. Do they use honeypots? Do they mine DNS traffic and track new domain registrations? Have they built a cloud-based malware analysis/sandboxing capability? You can categorize vendors by their tactics to help you pick the best for your requirements. To choose between vendors you need to compare their services for comprehensiveness, timeliness, and accuracy. Sign up for trials of a number of services and monitor their feeds for a week or so. Does one provider consistently identify new threats earlier? Is their information correct? Do they provide more detailed and actionable analysis? How easy will it be to integrate their data into your environment for your use cases. Don’t fall for marketing hyperbole about proprietary algorithms, Big Data analysis, or staff linguists penetrating hacker dens and other stories straight out of a spy novel. It all comes down to data, and how useful it is to your security program. Buyer beware, and make sure you put each intelligence provider through its paces before you commit. Our last point to stress is the importance of short agreements, especially up front. You cannot know how these services will work for you until you actually start using them. Many of these intelligence companies are startups, and might not be around in 3 or 4 years. Once you identify a set of core intelligence

Our Security and Privacy on the Encrypted Network paper tackles setting security policies to ensure that data doesn’t leak out over encrypted tunnels, and that employees adhere to corporate acceptable use policies, by decrypting traffic as needed. It also addresses key use cases and strategies for decrypting network traffic, including security monitoring and forensics, to ensure you can properly alert on security events and investigate incidents. We include guidance on how to handle human resources and compliance issues because an increasing fraction of network traffic is encrypted. Check out this excerpt to get a feel for why you will encrypt and decrypt more on networks in the near future: Trends (including cloud computing and mobility) mean organizations have no choice but to encrypt more traffic on their networks. Encrypting the network prevents adversaries from sniffing traffic to steal credentials and ensures data moving outside the organization is protected from man-in-the-middle attacks. So we expect to see a much greater percentage of both internal and external network traffic to be encrypted over the next 2-3 years. We would like to thank Blue Coat for licensing the content in this paper. Without our licensees you’d be paying Big Research big money to get a fraction of the stuff we publish, free. Check out the landing page for Security and Privacy on the Encrypted Network or download it directly (PDF). Share:

It was a pretty typical day. I was settled into my seat at Starbucks writing something or other. Then I saw the AmEx notification pop up on my phone. $240.45, Ben Sherman, on the card I use for Securosis expenses. Huh? Who’s Ben Sherman? Pretty sure my bookie’s name isn’t Ben. So using my trusty Google fu I saw they are a highbrow mens clothier (nice stuff, BTW). But I didn’t buy anything from that store. My well-worn, “Crap. My card number got pwned again.” process kicked in. Though I was far ahead of the game this time. I found the support number for Ben Sherman and left a message with the magic words, “blah blah blah fraudulent transaction blah blah,” and amazingly, I got a call back within 10 minutes. They kindly canceled the order (which saved them money) and gave me some details on the transaction. The merchandise was evidently ordered by a “Scott Rothman,” and it was to be shipped to my address. That’s why the transaction didn’t trigger any fraud alerts – the name was close enough and the billing and shipping addresses were legit. So was I getting punked? Then I asked what was ordered. She said a pair of jeans and a shirt. For $250? Damn, highbrow indeed. When I inquired about the size that was was the kicker. 30 waist and 32 length on the jeans. 30×32. Now I’ve dropped some weight, but I think the last time I was in size 30 pants was third grade or so. And the shirt was a Small. I think I outgrew small shirts in second grade. Clearly the clothes weren’t for me. The IP address of the order was Cumming, GA – about 10 miles north of where I live, and they provided a bogus email address. I am still a bit perplexed by the transaction – it’s not like the perpetrator would benefit from the fraud. Unless they were going to swing by my house to pick up the package when it was delivered by UPS. But they’ll never get the chance, thanks to AmEx, whose notification allowed me to cancel the order before it shipped. So I called up AmEx and asked for a replacement card. No problem – my new card will be in my hands by the time you read this. The kicker was an email I got yesterday morning from AmEx. Turns out they already updated my card number in Apple Pay, even though I didn’t have the new card yet. So I could use my new card on my fancy phone and get a notification when I used it. And maybe I will even buy some pants from Ben Sherman to celebrate my new card. On second thought, probably not – I’m not really a highbrow type… –Mike The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. January 26 – 2015 Trends January 15 – Toddler December 18 – Predicting the Past November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named 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, with our content in all its unabridged glory. And you can get all our research papers too. Applied Threat Intelligence Use Case #3, Preventative Controls Use Case #2, Incident Response/Management Use Case #1, Security Monitoring Defining TI Network Security Gateway Evolution Introduction Security and Privacy on the Encrypted Network Selection Criteria and Deployment Use Cases The Future is Encrypted Newly Published Papers Monitoring the Hybrid Cloud Best Practices for AWS Security Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Advanced Endpoint and Server Protection The Future of Security Incite 4 U It’s about applying the threat intel: This post on the ThreatConnect blog highlights an important aspect that may get lost in the rush to bring shiny threat intelligence data to market. As lots of folks, notably Rick Holland and yours truly, have been saying for a while. It’s not about having the data. It’s about using it. The post points out that data is data. Without understanding how it can be applied to your security program, it’s just bits. That’s why my current series focuses on using threat intel within security monitoring, incident response, and preventative controls. Rick’s written a bunch of stuff making similar points, including this classic about how vendors always try to one-up each other. I’m not saying you need (yet another) ‘platform’ to aggregate threat intel, but you definitely need a strategy to make the best use of data within your key use cases. – MR Good enough: I enjoyed Gilad Parann-Nissany’s post on 10 Things You Need To Know about HIPAA Compliance in the Cloud as generic guidance for PHI security in the cloud. But his 10th point really hits the mark: HIPAA is not feared at all. The vast majority of HIPAA fines have been for physical disclosure of PHI, not electronic. While a handful of firms go out of their way to ensure their cloud infrastructure

So far, as we have looked to apply threat intelligence to your security processes, we have focused on detection/security monitoring and investigation/incident response functions. Let’s jump backwards in the attack chain to take a look at how threat intelligence can be used in preventative controls within your environment. By ‘preventative’ we mean any control that is in the flow, and can therefore prevent attacks. These include: Network Security Devices: These are typically firewalls (including next-generation models), and intrusion prevention systems. But you can also include devices such as web application firewalls, which operate at different levels in the stack but are inline and can thus block attacks. Content Security Devices/Services: Web and email filters can also function as preventative controls because they inspect traffic as it passes through and can enforce policies/block attacks. Endpoint Security Technologies: Protecting an endpoint is a broad category, and can include traditional endpoint protection (anti-malware) and new-fangled advanced endpoint protection technologies such as isolation and advanced heuristics. We described the current state of endpoint security in our Advanced Endpoint Protection paper, so check that out for detail on the technologies. TI + Preventative Controls Once again we consider how to apply TI through a process map. So we dust off the very complicated Network Security Operations process map from NSO Quant, simplify a bit, and add threat intelligence. Rule Management The process starts with managing the rules that underlie the preventative controls. This includes attack signatures and the policies & rules that control attack response. The process trigger will probably be a service request (open this port for that customer, etc.), signature update, policy update, or threat intelligence alert (drop traffic from this set of botnet IPs). We will talk more about threat intel sources a bit later. Policy Review: Given the infinite variety of potential monitoring and blocking policies available on preventative controls, keeping the rules current is critical. Keep the severe performance hit (and false positive implications) of deploying too many policies in mind as you decide what policies to deploy. Define/Update/Document Rules: This next step involves defining the depth and breadth of the security policies, including the actions (block, alert, log, etc.) to take if an attack is detected – whether via rule violation, signature trigger, threat intelligence, or another method. Initial policy deployment should include a Q/A process to ensure no rules impair critical applications’ ability to communicate either internally or externally. Write/Acquire New Rules: Locate the signature, acquire it, and validate the integrity of the signature file(s). These days most signatures are downloaded, so this ensures the download completed properly. Perform an initial evaluation of each signature to determine whether it applies within your organization, what type of attack it detects, and whether it is relevant in your environment. This initial prioritization phase determines the nature of each new/updated signature, its relevance and general priority for your organization, and any possible workarounds. Change Management In this phase rule additions, changes, updates, and deletions are handled. Process Change Request: Based on the trigger within the Content Management process, a change to the preventative control(s) is requested. The change’s priority is based on the nature of the rule update and risk of the relevant attack. Then build out a deployment schedule based on priority, scheduled maintenance windows, and other factors. This usually involves the participation of multiple stakeholders – ranging from application, network, and system owners to business unit representatives if downtime or changes to application use models are anticipated. Test and Approve: This step includes development of test criteria, performance of any required testing, analysis of results, and release approval of the signature/rule change once it meets your requirements. This is critical if you are looking to automate rules based on threat intelligence, as we will discuss later in the post. Changes may be implemented in log-only mode to observe their impact before committing to blocking mode in production (critical for threat intelligence-based rules). With an understanding of the impact of the change(s), the request is either approved or denied. Deploy: Prepare the target devices for deployment, deliver the change, and return them to normal operation. Verify that changes were properly deployed, including successful installation and operation. This might include use of vulnerability assessment tools or application test scripts to ensure no disruption to production systems. Audit/Validate: Part of the full process of making the change is not only having the Operations team confirm it during the Deploy step, but also having another entity (internal or external, but not part of Ops) audit it to provide separation of duties. This involves validating the change to ensure the policies were properly updated and matching it against a specific request. This closes the loop and ensures there is a documentation trail for every change. Depending on how automated you want this process to be this step may not apply. Monitor Issues/Tune: The final step of the change management process involves a burn-in period when each rule change is scrutinized for unintended consequences such as unacceptable performance impact, false positives, security exposures, or undesirable application impact. For threat intelligence-based dynamic rules false positives are the issue of most concern. The testing process in the Test and Approve step is intended to minimize these issues, but there are variances between test environments and production networks so we recommend a probationary period for each new or updated rule, just in case. Automatic Deployment The promise of applied threat intelligence is to have rules updated dynamically per intelligence gleaned from outside your organization. It adds a bit of credibility to “getting ahead of the threat”. You can never really get ‘ahead’ of the threat, but certainly can prepare before it hits you. But security professionals need to accustom themselves to updating rules from data. We joke in conference talks about how security folks hate the idea of Skynet tweaking their defenses. There is still substantial resistance to updating access control rules on firewalls or IPS blocking actions without human intervention. But we expect this resistance to ebb

You are constantly changing. We all are. You live, you learn, you adapt, you change. It seems that if you pay attention, every 7-9 years or so you realize you hardly recognize the person looking back at you from the mirror. Sometimes the changes are very positive. Other times a cycle is not as favorable. That’s part of the experience. Yet many people don’t think anything changes. They expect the same person year after year. I am a case in point. I have owned my anger issues from growing up and my early adulthood. They resulted in a number of failed jobs and relationships. It wasn’t until I had to face the reality that my kids would grow up in fear of me that I decided to change. It wasn’t easy, but I have been working at it diligently for the past 8 years, and at this point I really don’t get angry very often. But lots of folks still see my grumpy persona, even though I’m not grumpy. For example I was briefing a new company a few weeks ago. We went through their pitch, and I provided some feedback. Some of it was hard for them to hear because their story needed a lot of work. At some point during the discussion, the CEO said, “You’re not so mean.” Uh, what? It turns out the PR handlers had prepared them for some kind of troll under the bridge waiting to chew their heads off. At one point I probably was that troll. I would say inflammatory things and be disagreeable because I didn’t understand my own anger. Belittling others made me feel better. I was not about helping the other person, I was about my own issues. I convinced myself that being a douche was a better way to get my message across. That approach was definitely more memorable, but not in a positive way. So as I changed my approach to business changed as well. Most folks appreciate the kinder Incite I provide. Others miss crankypants, but that’s probably because they are pretty cranky themselves and they wanted someone to commiserate over their miserable existence. What’s funny is that when I meet new people, they have no idea about my old curmudgeon persona. So they are very surprised when someone tells a story about me being a prick back in the day. That kind of story is inconsistent with what they see. Some folks would get offended by hearing those stories, but I like them. It just underscores how years of work have yielded results. Some folks have a hard time letting go of who they thought you were, even as you change. You shed your skin and took a different shape, but all they can see is the old persona. But when you don’t want to wear that persona anymore, those folks tend to move out of your life. They need to go because don’t support your growth. They hold on to the old. But don’t fret. New people come in. Ones who aren’t bound by who you used to be – who can appreciate who you are now. And those are the kinds of folks you should be spending time with. –Mike Photo credit: “Snake Skin” originally uploaded by James Lee The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. January 26 – 2015 Trends January 15 – Toddler December 18 – Predicting the Past November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named 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, with our content in all its unabridged glory. And you can get all our research papers too. Applied Threat Intelligence Use Case 2: Incident Response/Management Use Case 1: Security Monitoring Defining TI Network Security Gateway Evolution Introduction Security and Privacy on the Encrypted Network Selection Criteria and Deployment Use Cases The Future is Encrypted Newly Published Papers Monitoring the Hybrid Cloud Best Practices for AWS Security Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Advanced Endpoint and Server Protection The Future of Security Incite 4 U Click. Click. Boom! I did an interview last week where I said the greatest security risk of the Internet of Things is letting it distract you from all of the other more immediate security risks you face. But the only reason that is even remotely accurate is because I don’t include industrial control systems, multifunction printers, or other more traditional ‘things’ in the IoT. But if you do count everything connected to the Internet, some real problems pop up. Take the fuel gauge vulnerability just released by H D Moore/Rapid 7. Scan the Internet, find hundreds of vulnerable gas stations, all of which could cause real-world kinetic-style problems. The answer always comes back to security basics: know the risk, compartmentalize, update devices, etc. Some manufacturers are responsible, others not so much, and as a security pro it is worth factoring this reality into your risk profile. You know, like, “lightbulb risk:

As we continue with our Applied Threat Intelligence series, let us now look at the next use case: incident response/management. Similar to the way threat intelligence helps with security monitoring, you can use TI to focus investigations on the devices most likely to be impacted, and help to identify adversaries and their tactics to streamline response. TI + IR/M As in our last post, we will revisit the incident response and management process, and then figure out which types of TI data can be most useful and where. You can get a full description of all the process steps in our full Leveraging TI in Incident Response/Management paper. Trigger and escalate The incident management process starts with a trigger kicking off a response, and the basic information you need to figure out what’s going on depends on what triggered the alert. You may get alerts from all over the place, including monitoring systems and the help desk. But not all alerts require a full incident response – much of what you deal with on a day-to-day basis is handled by existing security processes. Where do you draw the line between a full response and a cursory look? That depends entirely on your organization. Regardless of the criteria you choose, all parties (including management, ops, security, etc.) must be clear on which situations require a full investigation and which do not, before you can decide whether to pull the trigger. Once you escalate an appropriate resource is assigned and triage begins. Triage Before you do anything, you need to define accountabilities within the team. That means specifying the incident handler and lining up resources based on the expertise needed. Perhaps you need some Windows gurus to isolate a specific vulnerability in XP. Or a Linux jockey to understand how the system configurations were changed. Every response varies a bit, and you want to make sure you have the right team in place. As you narrow down the scope of data needing analysis, you might filter on the segments attacked or logs of the application in question. You might collect forensics from all endpoints at a certain office, if you believe the incident was contained. Data reduction is necessary to keep the data set to investigate manageable. Analyze You may have an initial idea of who is attacking you, how they are doing it, and their mission based on the alert that triggered the response, but now you need to prove that hypothesis. This is where threat intelligence plays a huge role in accelerating your response. Based on indicators you found you can use a TI service to help identify a potentially responsible party, or more likely a handful of candidates. You don’t need legal attribution, but this information can help you understand the attacker and their tactics. Then you need to size up and scope out the damage. The goal here is to take the initial information provided and supplement it quickly to determine the extent and scope of the incident. To determine scope dig into the collected data to establish the systems, networks, and data involved. Don’t worry about pinpointing every affected device at this point – your goal is to size the incident and generate ideas for how best to mitigate it. Finally, based on the initial assessment, use your predefined criteria to decide whether a formal investigation is in order. If yes, start thinking about chain of custody and using some kind of case management system to track the evidence. Quarantine and image Once you have a handle (however tenuous) on the situation you need to figure out how to contain the damage. This usually involves taking the device offline and starting the investigation. You could move it onto a separate network with access to nothing real, or disconnect it from the network altogether. You could turn the device off. Regardless of what you decide, do not act rashly – you need to make sure things do not get worse, and avoid destroying evidence. Many malware kits (and attackers) will wipe a device if it is powered down or disconnected from the network, so be careful. Next you take a forensic image of the affected devices. You need to make sure your responders understand how the law works in case of prosecution, especially what provides a basis for reasonable doubt in court. Investigate All this work is really a precursor to the full investigation, when you dig deep into the attack to understand what exactly happened. We like timelines to structure your investigation, as they help you understand what happened and when. Start with the initial attack vector and follow the adversary as they systematically moved to achieve their mission. To ensure a complete cleanup, the investigation must include pinpointing exactly which devices were affected and reviewing exfiltrated data via full packet capture from perimeter networks. It turns out investigation is more art than science, and you will never actually know everything, so focus on what you do know. At some point a device was compromised. At another subsequent point data was exfiltrated. Systematically fill in gaps to understand what the attacker did and how. Focus on completeness of the investigation – a missed compromised device is sure to mean reinfection somewhere down the line. Then perform a damage assessment to determine (to the degree possible) what was lost. Mitigation There are many ways to ensure the attack doesn’t happen again. Some temporary measures include shutting down access to certain devices via specific protocols or locking down traffic in and out of critical servers. Or possibly blocking outbound communication to certain regions based on adversary intelligence. Also consider more ‘permanent’ mitigations, such as putting in place a service or product to block denial of service attacks. Once you have a list of mitigation activities you marshal operational resources to work through it. We favor remediating affected devices in one fell swoop (big bang), rather than incremental cleaning/reimaging. We have found it more effective to eradicate the adversary from

We are pleased to announce the availability of our Monitoring the Hybrid Cloud: Evolving to the CloudSOC paper. As the megatrends of cloud computing and mobility continue to play out in technology infrastructure, your security monitoring approach must evolve to factor in the lack of both visibility and control over the infrastructure. But senior management isn’t in the excuses business so you still need to provide the same level of diligence in protecting critical data. This paper looks at why the cloud is different, emerging use cases for hybrid cloud security monitoring, and some architectural ideas with migration plans to get there. As always we would like to thank IBM Security for licensing this content enabling us to post it on the site for a good price. Check out the landing page, or you can download the paper directly (PDF). Share:

As we discussed in Defining TI, threat intelligence can help detect attacks earlier by benefiting from the misfortune of others and looking for attack patterns being used against higher profile targets. This is necessary because you simply cannot prevent everything. No way, no how. So you need to get better and faster at responding. The first step is improving detection to shorten the window between compromise and discovery of compromise. Before we jump into how – the meat of this series – we need to revisit what your security monitoring process can look like with threat intelligence. TI+SM We will put the cart a bit before the horse. We will assume you already collect threat intelligence as described in the last post. But of course you cannot just wake up and find compelling TI. You need to build a process and ecosystem to get there, but we haven’t described them in any detail yet. But we will defer that discussion a little, until you understand the context of the problem to solve, and then the techniques for systematically gathering TI will make more sense. Let’s dig into specific aspects of the process map: Aggregate Security Data The steps involved in aggregating security data are fairly straightforward. You need to enumerate devices to monitor in your environment, scope out the kinds of data you will get from them, and define collection policies and correlation rules – all described in gory detail in Network Security Operations Quant. Then you can move on to actively collecting data and storing it in a repository to allow flexible, fast, and efficient analysis and searching. Security Analytics The security monitoring process now has two distinct sources to analyze, correlate, and alert on: external threat intelligence and internal security data. Automate TI integration: Given the volume of TI information and its rate of change, the only way to effectively leverage external TI is to automate data ingestion into the security monitoring platform; you also need to automatically update alerts, reports, and dashboards. Baseline environment: You don’t really know what kinds of attacks you are looking for yet, so you will want to gather a baseline of ‘normal’ activity within your environment and then look for anomalies, which may indicate compromise and warrant further investigation. Analyze security data: The analysis process still involves normalizing, correlating, reducing, and tuning the data and rules to generate useful and accurate alerts. Alert: When a device shows one or more indicators of compromise, an alert triggers. Prioritize alerts: Prioritize alerts based on the number, frequency, and types of indicators which triggered them; use these priorities to decide which devices to further investigate, and in what order. Integrated threat intelligence can help by providing additional context, allowing responders to prioritize threats so analysts can investigate the highest risks first. Deep collection: Depending on the priority of the alert you might want to collect more detailed telemetry from the device, and perhaps start capturing network packet data to and from it. This data can facilitate validation and identification of compromise, and facilitate forensic investigation if it comes to that. Action Once you have an alert, and have gathered data about the device and attack, you need to determine whether it was actually compromised or the alert was a false positive. If a device has been compromised you need to escalate – either to an operations team for remediation/clean-up, or to an investigation team for more thorough incident response and analysis. To ensure both processes improve constantly you should learn from each validation step: critically evaluate the intelligence, as well as the policy and/or rule that triggered the alert. For a much deeper discussion of how to Leverage TI in Security Monitoring check out our paper. Useful TI We are trying to detect attacks faster in this use case (rather than working on preventing or investigating them), so the most useful types of TI are strong indicators of problems. Let’s review some data sources from our last post, along with how they fit into this use case: Compromised Devices: The most useful kind of TI is a service telling you there is a cesspool of malware on your network. This “smoking gun” can be identified by a number of different indicators, as we will detail below. But if you can get a product to identify those devices wih analytics on TI data, it saves you considerable effort analyzing and identifying suspicious devices yourself. Of course you cannot always find a smoking gun, so specific TI data types are helpful for detecting attacks: File Reputation: Folks pooh-pooh file reputation, but the fact is that a lot of malware still travels around through the tried and true avenue of file transmission. It is true that polymorphic malware makes it much harder to match signatures, but it’s not impossible; so tracking the presence of files can be helpful for detecting attacks and pinpointing the extent of an outbreak – as we will discuss in detail in our next post. Indicators of Compromise: The shiny new term for an attack signature is indicator of compromise. But whatever you call it an IoC is a handy machine-readable means of identifying registry, configuration, and system file changes that indicate what malicious code does to devices. This kind of detailed telemetry from endpoints and networks enables you to detect attacks as they happen. IP reputation: At this point, given the popularity of spoofing addresses, we cannot recommend making a firm malware/clean judgement based only on IP reputation, but if the device is communicating with known bad addresses and showing other indicators (which can be identified through the wonders of correlation – as a SIEM does) you have more evidence of compromise. C&C Patterns: The last TI data source for this use case is a behavioral analog of IP reputation. You don’t necessarily need to worry about where the device is communicating to – instead you can focus on how it’s communicating. There are known means of polling DNS to find botnet controllers

As we looked back on our research output for the past 2 years it became clear that threat intelligence (TI) has been a topic of interest. We have written no less than 6 papers on this topic, and feel like we have only scratched the surface of how TI can impact your security program. So why the wide-ranging interest in TI? Because security practitioners have basically been failing to keep pace with adversaries for the past decade. It’s a sad story, but it is reality. Adversaries can (and do) launch new attacks using new techniques, and the broken negative security model of looking for attacks you have seen before consistently misses them. If your organization hasn’t seen the new attacks and updated your controls and monitors to look for the new patterns, you are out of luck. What if you could see attacks without actually being attacked? What if you could benefit from the experience of higher-profile targets, learn what adversaries are trying against them, and then look for those patterns in your own environment? That would improve your odds of detecting and preventing attacks. It doesn’t put defenders on an even footing with attackers, but it certainly helps. So what’s the catch? It’s easy to buy data but hard to make proper use of it. Knowing what attacks may be coming at you doesn’t help if your security operations functions cannot detect the patterns, block the attacks, or use the data to investigate possible compromise. Without those capabilities it’s just more useless data, and you already have plenty of that. As we discussed in detail in both Leveraging Threat Intelligence in Security Monitoring and Leveraging Threat Intelligence in Incident Response/Management, TI can only help if your security program evolves to take advantage of intelligence data. As we wrote in the TI+SM paper: One of the most compelling uses for threat intelligence is helping to detect attacks earlier. By looking for attack patterns identified via threat intelligence in your security monitoring and analytics processes, you can shorten the window between compromise and detection. But TI is not just useful for security monitoring and analytics. You can leverage it in almost every aspect of your security program. Our new Applied Threat Intelligence series will briefly revisit how processes need to change (as discussed in those papers) and then focus on how to use threat intelligence to improve your ability to detect, prevent, and investigate attacks. Evolving your processes is great. Impacting your security posture is better. A lot better. Defining Threat Intelligence We cannot write about TI without acknowledging that, with a broad enough definition, pretty much any security data qualifies as threat intelligence. New technologies like anti-virus and intrusion detection (yes, that’s sarcasm, folks) have been driven by security research data since they emerged 10-15 years ago. Those DAT files you (still) send all over your network? Yup, that’s TI. The IPS rules and vulnerability scanner updates your products download? That’s all TI too. Over the past couple years we have seen a number of new kinds of TI sources emerge, including IP reputation, Indicators of Compromise, command and control patterns, etc. There is a lot of data out there, that’s for sure. And that’s great because without this raw material you have nothing but what you see in your own environment. So let’s throw some stuff against the wall to see what sticks. Here is a starter definition of threat intelligence: Threat Intelligence is security data that provides the ability to prepare to detect, prevent, or investigate emerging attacks before your organization is attacked. That definition is intentionally quite broad because we don’t want to exclude interesting security data. Notice the definition doesn’t restrict TI to external data either, although in most cases TI is externally sourced. Organizations with very advanced security programs can do proactive research on potential adversaries and develop proprietary intelligence to identify likely attack vectors and techniques, but most organizations rely on third-party data sources to make internal tools and processes more effective. That’s what leveraging threat intelligence is all about. Adversary Analysis So who is most likely to attack? That’s a good start for your threat intelligence process, because the attacks you will see vary greatly based on the attacker’s mission, and their assessment of the easiest and most effective way to compromise your environment. Evaluate the mission: You need to start by learning what’s important in your environment, so you can identify interesting targets. They usually break down into a few discrete categories – including intellectual property, protected customer data, and business operations information. Profile the adversary: To defend yourself you need to know not only what adversaries are likely to look for, but what kinds of tactics various types of attackers typically use. So figure out which categories of attacker you are likely to face. Types include unsophisticated (using widely available tools), organized crime, competitors, and state-sponsored. Each class has a different range of capabilities. Identify likely attack scenarios: Based on the adversary’s probable mission and typical tactics, put your attacker hat on to figure out which path you would most likely take to achieve it. At this point the attack has already taken place (or is still in progress) and you are trying to assess and contain the damage. Hopefully investigating your proposed paths will prove or disprove your hypothesis. Keep in mind that you don’t need to be exactly right about the scenario. You need to make assumptions about what the attacker has done, and you cannot predict their actions perfectly. The objective is to get a head start on response, narrowing down investigation by focusing on specific devices and attacks. Nor do you need a 200-page dossier on each adversary – instead focus on information needed to understand the attacker and what they are likely to do. Collecting Data Next start to gather data which will help you identify/detect the activity of these potential adversaries in your environment. You can get effective threat intelligence from a number of different

Over halfway through January (already!), how are those New Year’s resolutions going? Did you want to lose some weight? Maybe exercise a bit more? Maybe drink less, or is that just me? Or have some more fun? Whatever you wanted to do, how is that going? If you are like most the resolutions won’t make it out of January. It’s not for lack of desire, as folks that make resolutions really want to achieve the outcomes. In many cases the effort is there initially. You get up and run or hit the gym. You decline dessert. You sit with the calendar and plan some cool activities. Then life. That’s right, things are busy and getting busier. You have more to do and less to do it with. The family demands time (as they should) and the deadlines keep piling up. Travel kicks back in and the cycle starts over again. So you sleep through the alarm a few days. Then every day. The chocolate lava cake looks so good, so you have one. You’ll get back on the wagon tomorrow, right? And then it’s December and you start the cycle over. That doesn’t work very well. So how can you change it? What is the secret to making a habit? There is no secret. Not for me, anyway. It’s about routine. Pure and simple. I need to get into a routine and then the habits just happen. For instance I started running last summer. So 3 days a week I got up early and ran. No pomp. No circumstance. Just get up and run. Now I get up and freeze my ass off some mornings, but I still run. It’s a habit. Same process was used when I started my meditation practice a few years back. I chose not to make the time during the day because I got mired in work stuff. So I got up early. Like really early. I’m up at 5am to get my meditation done, then I get the kids ready for school, then I run or do yoga. I have gotten a lot done by 8am. That’s what I do. It has become a routine. And a routine enables you to form a habit. Am I perfect? Of course not, and I don’t fret when I decide to sleep in. Or when I don’t meditate. Or if I’m a bit sore and skip my run. I don’t judge myself. I let it go. What I don’t do is skip two days. Just as it was very hard to form my habits of both physical and mental practice, it is all too easy to form new less productive habits. Like not running or not meditating. That’s why I don’t miss two days in a row. If I don’t break the routine I don’t break the habit. And these are habits I don’t want to break. –Mike Photo credit: “Good, Bad Habits” originally uploaded by Celestine Chua The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. January 15 – Full Toddler December 18 – Predicting the Past November 25 – Numbness October 27 – It’s All in the Cloud October 6 – Hulk Bash September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon 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, with our content in all its unabridged glory. And you can get all our research papers too. Network Security Gateway Evolution Introduction Monitoring the Hybrid Cloud: Evolving to the CloudSOC Migration Planning Technical Considerations Solution Architectures Emerging SOC Use Cases Introduction Security and Privacy on the Encrypted Network Selection Criteria and Deployment Use Cases The Future is Encrypted Newly Published Papers Best Practices for AWS Security Securing Enterprise Applications Secure Agile Development Trends in Data Centric Security Leveraging Threat Intelligence in Incident Response/Management The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Advanced Endpoint and Server Protection The Future of Security Incite 4 U Doing attribution right… Marcus kills it in this post on why attribution is hard. You need to have enough evidence, come up with a feasible motive, corroborate the data with other external data, and build a timeline to understand the attack. But the post gets interesting when Marcus discusses how identifying an attacker based upon TTPs might not work very well. Attackers can fairly easily copy another group’s TTPs to blame them. I think attribution (at least an attempt) can be productive, especially as part of adversary analysis. But understand it is likely unreliable; if you make life and death decisions on this data, I don’t expect it to end well. – MR The crypto wars rise again: Many of you have seen this coming, but in case you haven’t we are hitting the first bump on a rocky road that could dead end in a massive canyon of pain. Encryption has become a cornerstone of information security, used for everything from secure payments to secure communications. The problem is that the same tools used to keep bad guys out also keep the government out. Well, that’s only a problem because politicians seem to gain most of