Security intelligence, threat intelligence, cyber threat intelligence, or “intel” for short is a popular topic these days in the Infosec world. It seems everyone has a feed of “bad” IP addresses and hostnames they want to sell you, or share. This is an encouraging trend in that it indicates the security industry is attempting to work together to defend against known and upcoming threats. Many services like Team Cymru, ShadowServer, ThreatExpert, Clean MX, and Malware Domain List offer lists of known command and control servers, dangerous URIs, or lists of hosts in your ASN that have been checking-in with known malicious hosts. This is essentially outsourced or assisted incident detection. You can leverage these feeds to let you know what problems you already have on your network, and to prepare for future incidents. This can be very helpful, especially for organizations with no computer security incident response teams (CSIRT) or an under-resourced security or IT operations group.
There are also commercial feeds which range anywhere from basic notifications to full-blown managed security solution. Government agencies and industry specific organizations also provide feeds targeted towards specific actors and threats. Many security information and event management systems (SIEMs) offer built-in feed subscriptions available only to their platform. The field of threat intelligence services is an ever-growing one, offering options from open source and free, to commercial and classified. Full disclosure: Cisco is also in the threat intelligence business
However the intent of this article is not to convince you that one feed is better than another, or to help you select the right feed for your organization. There are too many factors to consider, and the primary intention of this post is to make you ask yourself, “I have a threat intelligence feed, now what?” Read More »
Tags: cisco sio, CSIRT, csirt-playbook, cybersecurity, incident response, infosec, operational security, security, security intel
Every year in Scottsdale, Arizona, there’s a unique Information Security conference created by Joyce Brocaglia at ALTA, supported by a who’s who of InfoSec companies like Cisco, RSA, and Symantec, and attended by hundreds of some of the brightest people I’ve ever met. It’s no coincidence that they are all women because this is the Executive Women’s Forum (EWF) and always a highlight of my year.
A special treat for me this year was the presentation by Edna Conway, CISO for Cisco System’s supply chain and, as it turns out, a brilliant and inspiring woman.
A few weeks earlier, after reading that Edna was to be a keynote speaker at the event, I sent her an email just to introduce myself, say “hello,” and let her know that I looked forward to hearing her presentation. Not what I expected, Edna responded with a warm welcome for me to Cisco (yup—I’m a Cisco newbie after almost 30 years with HP!) and said that she was looking forward to getting some help from me on her current focus: securing Cisco’s supply chain. Great! Love to help, let’s keep in touch. However, when she presented to the EWF audience the strategy that she’d already developed and implemented, I was humbled by what an amazingly thorough job she’d done. The other women in the audience recognized the value in her strategy as well, as they lined up to speak with her after her address, and to ask for her help at their own companies. I saw the undeniable admiration in the eyes of these successful women executives—and those aspiring to be successful women executives—and something remarkable occurred to me. Read More »
Tags: Cisco Security, cisco sio, cisco supply chain, CISO, infosec, women in tech
CSIRT, I have a project for you. We have a big network and we’re definitely getting hacked constantly. Your group needs to develop and implement security monitoring to get our malware and hacking problem under control.
If you’ve been a security engineer for more than a few years, no doubt you’ve received a directive similar to this. If you’re anything like me, your mind probably races a mile a minute thinking of all of the cool detection techniques you’re going to develop and all of the awesome things you’re going to find.
I know, I’ll take the set of all hosts in our web proxy logs doing periodic POSTs and intersect that with…
You shouldn’t leap before you look into a project like this. Read More »
Tags: CSIRT, csirt-playbook, incident response, infosec, logging, logs, playbook, security, SIEM
The Great Correlate Debate
SIEMs have been pitched in the past as “correlation engines” and their special algorithms can take in volumes of logs and filter everything down to just the good stuff. In its most basic form, correlation is a mathematical, statistical, or logical relationship between a set of different events. Correlation is incredibly important, and is a very powerful method for confirming details of a security incident. Correlation helps shake out circumstantial evidence, which is completely fair to use in the incident response game. Noticing one alarm from one host can certainly be compelling evidence, but in many cases it’s not sufficient. Let’s say my web proxy logs indicate a host on the network was a possible victim of a drive-by download attack. The SIEM could notify the analysts team that this issue occurred, but what do we really know at this point? That some host may have downloaded a complete file from a bad host -- that’s it. We don’t know if it has been unpacked, executed, etc. and have no idea if the threat is still relevant. If the antivirus deleted or otherwise quarantined the file, do we still have anything to worry about? If the proxy blocked the file from downloading, what does that mean for this incident?
This is the problem that correlation can solve. If after the malware file downloaded we see port scanning behavior, large outbound netflow to unusual servers, repeated connections to PHP scripts hosted in sketchy places, or other suspicious activity from the same host, we can create an incident for the host based on our additional details. The order is important as well. Since most attacks follow the same pattern (bait, redirect, exploit, additional malware delivery, check-in), we tie these steps together with security alarms and timestamps. If we see the events happening in the proper order we can be assured an incident has occurred.
Read More »
Tags: CSIRT, csirt-playbook, incident response, infosec, logging, logs, NCSAM, ncsam-2013, playbook, security, SIEM
Security information and event management systems (SIEM, or sometimes SEIM) are intended to be the glue between an organization’s various security tools. Security and other event log sources export their alarms to a remote collection system like a SIEM, or display them locally for direct access and processing. It’s up to the SIEM to collect, sort, process, prioritize, store, and report the alarms to the analyst. It’s this last piece that is the key to an effective SIEM deployment, and of course the most challenging part. In the intro to this blog series I mentioned how we intend to describe our development of a new incident response playbook. A big first step in modernizing our playbook was a technology overhaul, from an outdated and inflexible technology to a modern and highly efficient one. In this two-part post, I’ll describe the pros and cons of running a SIEM, and most importantly provide details on why we believe a log management system is the superior choice.
Deploying a SIEM is a project. You can’t just rack a new box of packet-eating hardware and expect it to work. It’s important to understand and develop all the proper deployment planning steps. Things like scope, business requirements, and engineering specifications are all factors in determining the success of the SIEM project. Event and alarm volume in terms of disk usage, and retention requirements must be understood. There’s also the issue of how to reliably retrieve remote logs from a diverse group of networked devices without compatibility issues. You must be able to answer questions like: Read More »
Tags: CSIRT, csirt-playbook, incident response, infosec, logging, logs, NCSAM, ncsam-2013