Your SOC Nuclear Triad [BACKUP FROM DEAD GARTNER BLOG]

 NOTICE: after Gartner killed ALL blogs in late 2023, I am trying to salvage (via archive.org) some of the most critical blogs I've written while working there, and repost them with backdates here, for posterity. This one reminds the world that I invented the "SOC visibility triad" model back in 2015.

Let’s talk modern SOC tools. The analogy I’d like to use is that of a “Nuclear Triad” – a key cold war concept. The triad consisted of strategic bombers, ICBMs and missile submarines (strictly speaking, submarine missiles – SLBMs) and sought to “significantly reduce the possibility that an enemy could destroy all of a nation’s nuclear forces in a first-strike attack.”

Your SOC should have its own nuclear triad of visibility:

1. SIEM – if I need to explains this, please read something else instead 
2. Network Forensics (NFT) – tools that can capture all network traffic (full packet capture), extract metadata (including application layer, L7 metadata such as HTTP user-agent, DNS query response, FTP username, email subject, etc) and payloads, retain some raw traffic and metadata, enable searching and analysis. There are several commercial tools, and then there are moloch and OpenSOC; Bro sort of fits in as well. [See more details here and in this GTP document]
3. Endpoint Detection and Response (EDR, formerly ETDR) – typically agent-based tools to capture execution, local connections, system changes, memory activities, etc. There are a lot (A LOT!) of commercial tools, and then there are GRR, MIG (update: not really MozDef, as I mentioned in the previous version)  as osquery, sort of. [See more details here and in this GTP document]

Similar to the above, your “SOC triad” seeks to significantly reduce the chance that the attacker will operate on your network long enough to accomplish their goals.

Of course, your SOC will make use of other tools and capabilities, such as threat intelligence (TI) data, malware sandboxes and reversing tools [to push the above analogy a tad too far, maybe this is like a suitcase nuke? Very much an auxiliary weapon, but also very cool? :-)] as well as some workflow system to organize all your work [strategic forces underwound command center?]. However, I always think of SIEM + NFT + EDR as “SOC nuclear triad” of visibility!

There you have it! Enjoy!

How to Use Threat Intelligence with Your SIEM? [BACKUP FROM DEAD GARTNER BLOG]

 NOTICE: after Gartner killed ALL blogs in late 2023, I am trying to salvage (via archive.org) some of the most critical blogs I've written while working there, and repost them with backdates here, for posterity. This one is about SIEM and TI.

SIEM and Threat Intelligence (TI) feeds are a marriage made in heaven! Indeed, every SIEM user should send technical TI feeds into their SIEM tool. We touched on that subject several times, but in this post will look at in in depth. Well, in as much depth as possible to still make my future paper on the topic a useful read :–)

First, why are we doing this:

• Faster detection – alerting on TI matches (IPs, URLs, domains, hashes, etc) is easier than writing good correlation rules
• Better context – alert triage and incident investigation becomes easier and information is available faster
• Threat tracking and awareness – combining local monitoring observations, external TI and [for those who are ready!] internal TI in one place.

What log data do we need?

• Most common log data to match to TI feeds: firewalls logs (outbound connection records … my fave logs nowadays!), web proxy logs
• Also used: netflow, router logs or anything else that shows connectivity
• NIDS/NIPS (and NBA, if you are into that sort of thing) data (TI matching here helps triage, not detection)
• ETDR tools can usually match to TI data without using a SIEM, but local endpoint execution data collected in one place marries well to TI feeds.

Where would TI data comes from (also look for other TI sources):

• SIEM vendor: some of the SIEM vendors are dedicating significant resources to the production of their own threat intelligence and/or TI feed aggregation, enrichment and cleaning
• Community, free TI feeds: CIF format comes really handy here, but CSV can be imported just as well (some lists and information on how to compare them)
• Commercial packaged feeds from the TI aggregator (it may even have pre-formatted rules ready for your SIEM!)
• Commercial TI providers of original threat intelligence.

Obviously, using your SIEM vendor TI feeds is the easiest (and may in fact be as easy as clicking one button to turn it on!), but even other sources are not that hard to integrate with most decent SIEM tools.

Now, let’s review all the usage of TI data inside a SIEM:

• Detect owned boxes, bots, etc that call home when on your network (including boxes pre-owned when not on your network) and, in general, detect malware that talks back to its mothership
• Validate correlation rules and improve baselining alerts by upping the priority of rules that also point at TI-reported “bad” sources
• Qualify entities related to an incident based on collected TI data (what’s the history of this IP?)
• Historical matching of past, historical log data to current TI data (key cool thing to do! resource intensive!)
• Review past TI history as key context for reviewed events, alerts, incidents, etc (have we seen anything related to this IP in the past TI feeds?)
• Review threat histories and TI data in one place; make use of SIEM reports and trending to analyze the repository of historical TI data (create poor man’s TI management platform)
• Enable [if you feel adventurous] automatic action due to better context available from high-quality TI feeds
• Run TI effectiveness reports in a SIEM (how much TI leads to useful alerts and incidents?)
• Validate web server logs source IP to profile visitors and reduce service to those appearing on bad lists (uncommon)
• Other use of TI feeds in alerts, reports and searches and as context for other monitoring tasks

So, if you are deploying a SIEM, make sure that you start using threat intelligence in the early phases of your project!

Posts related to this research project:

• On Internally-sourced Threat Intelligence
• Delving into Threat Actor Profiles
• On Threat Intelligence Sources
• How to Make Better Threat Intelligence Out of Threat Intelligence Data?
• On Threat Intelligence Use Cases
• On Broad Types of Threat Intelligence
• Threat Intelligence is NOT Signatures!
• The Conundrum of Two Intelligences!
• On Comparing Threat Intelligence Feeds
• Consumption of Shared Security Data
• From IPs to TTPs

Our Team Is Hiring Again: Join Gartner GTP Now!

It is with great pleasure that I am announcing that our team is HIRING AGAIN!

Join Security and Risk Management Strategies (SRMS) team at Gartner for Technical Professionals (GTP)!

Excerpts from the job description:

• Create and maintain high quality, accurate, and in depth documents or architecture positions in information security, application security, infrastructure security, and/or related coverage areas;
• Prepare for and respond to customer questions (inquiries/dialogues) during scheduled one hour sessions with accurate information and actionable advice, subject to capacity and demand;
• Prepare and deliver analysis in the form of presentation(s) delivered at one or more of the company’s Catalyst conferences, Summit, Symposium, webinars, or other industry speaking events;
• Participate in industry conferences and vendor briefings, as required to gather research and maintain a high level of knowledge and expertise;
• Perform limited analyst consulting subject to availability and management approval;
• Support business development for GTP by participating in sales support calls/visits subject to availability and management approval;
• Contribute to research planning and development by participating in planning meetings, contributing to peer reviews, and research community meetings

In essence, your job would be to research, write, guide clients (via phone inquiries/dialogs) and speak at events. Also, we do list a lot of qualifications in the job req, but you can look at my informal take on them in this post.

So APPLY HERE!

P.S. If the link above fails, go to https://careers.gartner.com and search for “IRC26388”

P.P.S. If you have questions, feel free to email me – I cannot promise a prompt response, but I sure can promise a response.

P.P.P.S This is cross-posted from my Gartner blog.

Related posts:

• On Being An Analyst or WHO Are We Hiring?
• Our Team Is Hiring Again: Australia Only [position filled]
• Our Team Is Hiring Again: UK/Europe Only [position filled]
• Our Team Is Hiring [position filled]
• The Last Blog Post! (when I joined Gartner in 2011)

What is Your Minimum Time To Patch or “Patch Sound Barrier” [BACKUP FROM DEAD GARTNER BLOG]

 

My time this quarter is not only occupied by the exciting realm of big data, but also by the less exciting – but waaaaay more common – problem: security patching.

Here is a thought: every organization on this planet has an upper limit to their patching speed. For example, even if you threaten every sysadmin with torture upon failure and/or offer to pay them a $1m each upon success, there is no way (for example) to patch every Windows system at a large global bank in 3 days. The real situation is of course more nuanced and different systems have different time limits. Patching all Oracle databases within a week of patch release date is as unrealistic as patching all Windows desktops within one day, etc.

So, think of this as a “patching sound barrier”- you can try to break it, but your craft may well shatter to pieces. The knowledge of your limit is important since if your patch management is tied to risk reduction (as it should), and you are trying to reduce risk further by reducing your patching window, there is a point at which you really should stop trying… Also, if you can work *really* hard and shrink your patching window from 90 days to 30 days, meanwhile the attacker gets in within 3 days of patch release date, is your work really justified? Maybe other safeguard should be considered instead.

What factors affect this “patching sound barrier”? They include:

• Size of an organization
• Utilized system types (legacy, traditional, virtual, etc)
• Type of technology being patched (stock Windows desktop vs complex distributed application)
• System Admin/system ratio
• Degree of automation acceptance
• Change management process maturity
• Available patch management tools
• Desired risk balance (risk of patch crashing the system vs risk of unpatched system exploitation).

This limit needs to be taken into account when security recommendations and practices are considered and implemented.

Related blog posts on patching:

• Patch Management – NOT A Solved Problem!
• Next Research Project: From Big Data Analytics to … Patching
• On Nebulous Security Policies (featuring “we patch all systems within 30 days” boondoggle)
• All posts related to patching
• All posts related to vulnerability management.

On “Output-driven” SIEM [BACKUP FROM DEAD GARTNER BLOG]

NOTICE: after Gartner killed ALL blogs in late 2023, I am trying to salvage (via archive.org) some of the most critical blogs I've written while working there, and repost them with backdates here, for posterity. This one reminds the world that I popularized the term "output-driven SIEM"

Here is a great term I picked from another SIEM literati: “output-driven SIEM.” This simply means deploying your security information and event management tool in such a way that NOTHING comes into your SIEM unless and until you know how it would be utilized and/or presented. Thus, only existing/planned reports, visuals, alerts, dashboards, profiling algorithms, context fusion or whatever other means of using the data can make a SIEM implementer to “open the floodgates” and admit a particular log type into a tool. If a process exists outside of a SIEM tool that will make use of the SIEM data, that qualifies as well. In this model, goals drive security requirements, requirements drive use cases, use cases drive functionality and collection scope. By the way, this model is as well-known and effective … as it is, sadly, uncommon among the organizations deploying SIEM tools today. “Now that we have all this data [and now that our SIEM is very slow], how do we use it?” is much more common….

For example, if your goal is to make it possible to detect when your users abuse access credentials (or when somebody steals their credentials), requirements will call for login-counting correlation rules, user activity profiling as well as associated reporting on user access data. Thus, various types of authentication records (Unix syslog and Windows event logs, access control and remote access server logs, VPN, etc) need to be collected.

Now, this is dramatically different from an approach one should take with broad scope log management, aimed at general system troubleshooting or incident response support. This is where being “input-driven” and getting every possible bit of data in would be admirable. Collect “100% of all logs,” pile them in Hadoop, have them ready for use, etc  works brilliantly there – pick the data now and sort it out later, don’t dwell on choosing collection-time filters. However, doing the same with a SIEM is a great way to turning your deployment into a quivering, jumbled mess of barely performing components and oodles of “crap-ta” (a hybrid of “crap” and “data”, as you can guess). “Big” or “small”, unused data just does not help the SIEM perform its security mission well.

How does such difference matter in real-world deployments?

Every log line going into a SIEM tool “costs” (and sometimes actually costs – i.e. in dollar and not just in computing resource terms) much more than a log line dropped into a log aggregator.  $50,000  for an appliance system that does 100,000 EPS sounds like a great log management price, while SIEM deployments where 100,000 log messages are actually analyzed by a SIEM every second are both rare and really expensive (likely well into 7 digits territory).

Admittedly, “output-driven SIEM” is hard work. It makes soooooo much sense to “just collect it for now” and then “figure out how to use it later.” In many cases, however, this means that your deployment will be stuck. Sometimes it may work for you – but please be aware that for many people who thought that “it would work for them," it actually did not. At this point, it should be obvious to most readers that combining “input-driven” log aggregation and “output-driven” SIEM analysis is still the best way to go for most organizations. And, yes, as with every great useful rule, it has great useful exceptions …

On the architecture side, if your SIEM includes log management components (like most do today), the same logic applies: that aggregator component will see all of the data, while core SIEM analysis components and dashboards will only see the data that needs to be there. For two distinct tools, this “magic” is achieved via filters that are deployed between a log management system and a SIEM.

So, think about using the data before you admit it into a SIEM!

Related SIEM posts:

• On SIEM Maturity Scale and Maybe On CMM Too
• My SIEM Workshop / SAS Day
• On SIEM Deployment Evolution
• On People Running SIEM
• My SIEM Workshop / SAS Day
• On SIEM Processes/Practices
• On Large-scale SIEM Architecture
• Some of the Big SIEM Questions
• My Upcoming SIEM Research
• Our SIEM Futures Paper Publishes!
• All posts tagged  SIEM.

“Big Analytics” for Security: A Harbinger or An Outlier? [BACKUP FROM DEAD GARTNER BLOG]

 NOTICE: after Gartner killed ALL blogs in late 2023, I am trying to salvage (via archive.org) some of the most critical blogs I've written while working there, and repost them with backdates here, for posterity. This one reminds the world that I popularized the term "output-driven SIEM"

• You have 10 petabytes of security data in your Hadoop cluster.
• You count RAM in terabytes and CPU cores in dozens.
• You speak HiveQL better than you speak English.
• You collect literally and unquestionably every timed record of activity in your organization – including transaction logs, IM messages, flows, anything.
• You run queries over 13 months of data – and you do not have to take a vacation before the results come in.
• You outgrew your market-leading SIEM product … 5 years ago.
• You have statisticians (data scientists) on speed-dial – and on staff.
• You run statistical models on volumes of security data before your morning coffee – and get good results.
• Your organizations’ BI team thinks you are actually cool… despite being in security.

So….

are you a HARBINGER or an OUTLIER?

Is this the way information security will be done nearly everywhere in 3, 5, 10 years? (good arguments for this)

Or is this a case of “there are only 10 organizations in a Top 10 list”? (some arguments for this)

Is this the way we all need to learn to succeed with current and future threats?

Or is this the way to the top of the mountain that only the enlightened gurus will ever tread?

In any case, let’s keep this discussion going!

 

P.S.  By the way, remember that:  “If at first you don’t succeed, skydiving may not be for you.”  [by unknown] –> “If you keep failing with small data now, BIG DATA isn‘t for you!” [by Anton Chuvakin]

The Last Blog Post!

This is my last blog post –for the foreseeable future. It is dated 7/31/2011 at 11:59PM. What happens tomorrow? A new life, of course!

As only very few of you know, I have accepted a position of Research Director with Gartner, Inc. Tomorrow I am joining a stellar team lead by Phil Schacter, formerly from Burton Group.

I spent two VERY successful years consulting, working with companies like Novell, RSA, LogLogic, NitroSecurity, eGestalt, ObserveIT, Tripwire, AlienVault, “Big MSSP”, “Big Insurance Company”, “SaaS Log Management Company”, “IT Management Software Company”, “SMB Security Company”, “Big Networking Equipment Company”  and others. I defined,  built, deployed, and marketed security products, mostly in the area of SIEM and log management. I helped organizations with security and PCI DSS strategy. I advised security vendor management on compliance strategy for their products. I have spoken at clients’ events and have written more whitepapers than I care to admit… as well as did a lot of other fun things!

It was fun and I loved it - and as my clients can attest, I was good at it. Also, I was more busy than I thought I’d be, and occasionally more than I wanted to be. However, at some point I started to feel that I need another step up. And so I am making that step now!

In accordance with my future employer policy, I have resigned from the Advisory Boards of Dasient, Securonix, nexTier Networks, Savant Protection, eGestalt, and Rapid.IO. Good luck to all of you!

In all likelihood, I will eventually resurface at Gartner blogs – please look for me there.  And finally, those who love my personal blogging (all 4007 of you as of today), don’t despair – I will still occasionally blog here on non-infosec subjects: think good books, laser weapons, hypnosis, skiing, travel and my other weird hobbies

Finally, I want to give very special thanks to Lee Kushner for his super-valuable career counseling that helped me make this difficult career choice.

Possibly related posts – my past “career decisions” blog posts:

• Going to Consulting
• Going to Qualys
• Going to LogLogic

On SIEM MQ 2011

As all of you know, Gartner SIEM MQ 2011 is out – you can see it here (or here) without registration. The quadrant mostly matches my recent SIEM project experience.

My observations follow below:

• CA “SIEM” and “Log Manager” are finally wiped off the face of the Earth (=removed from SIEM MQ), NetIQ is dumped down to the Niche. As they should be.
• Honestly, Symantec SSIM in Leaders is a mystery to me; must be those invisible non-competitive deals or EU/APAC deals. I’ve not seen them on an enterprise SIEM shortlist in the US for a loooooooong time. The rest of the leaders match my expectations fully (and four of them have been at some point my consulting clients)
• Splunk is now officially a [sub-par] SIEM, even though it is really not. Is that good or bad? Well, they got their “honorable mention” for the last few years and now they are in the quadrant. BTW, this example shows that you can make A LOT of money by being free and not in any Magic Quadrant!
• Visionary sector of the MQ galaxy is extremely crowded – but with very different tools, ranging from Prism to Trustwave. Many organizations will choose a tool from this sector, but need to be careful – read the related posts below for some selection ideas and pitfalls.

BTW, congrats to all the vendors who got added this year: AlienVault, Tripwire, splunk and the regional SIEM guys.

As always, apart from insight, the MQ document has a good share of unintentional hilarity, for example:

• “This company declined to provide any information to Gartner for this research” (Darwin Awards anybody?)
• “Customer feedback on product function and support is mixed.” (Anton translation: product usually doesn’t work?)
• “Non-English-language versions of XYZ are not available.” (Anton’s comment: is everything else about the product perfectly perfect?)

Finally, if anybody is wondering, I think the concept of Magic Quadrant (whoever at Gartner came up with) is brilliant. However, many wrong  SIEM purchase decisions I’ve seen made usually stem from the decision maker’s own ignorance and not from whatever document or market visualization he has in his possession. Keep this in mind…

Rocky, your turn!

Possibly related posts:

• How Do I Get The Best SIEM?
• How to Replace a SIEM?
• SIEM Resourcing or How Much the Friggin’ Thing Would REALLY Cost Me?
• How to Write an OK SIEM RFP?
• On Choosing SIEM
• "So, What Should I Want?" or How NOT to Pick a SIEM-III?
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• I Want to Buy Correlation” or How NOT to Pick a SIEM?
• Log Management + SIEM = ?
• On SIEM Complexity
• SIEM Bloggables: SIEM Use Cases and Whitepaper with detailed SIEM use cases
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• All posts labeled SIEM