Five Ways Cribl Helps Enterprise SOCs: Check It Out Live at RSA

I recently spoke with recovering SOAR founder JP Bourget, founder of BlueCycle, a SOC/MSSP Advisory Service. JP and his team have worked with more than 250 organizations, advising on SOC best practices, optimization, and improving security data pipelines and processes. As he’s logged more than 20 years in cybersecurity, I wanted to chat with JP about observability trends in security, what he’s hoping to see as we enter #hoteventsummer (RSA, Gartner Security and Risk, CriblCon, Black Hat, and DEFCON 30) with conferences shaping up to have huge attendance and lots to cover! The TL:DR: You can connect with JP in Cribl Slack, on Twitter, or at BlueCycle.net, and if you’re a hacker AND a cyclist, you should check out Cycleoverride.org. You can hear the whole discussion in your podcast player, but I’ve excerpted some of the highlights below, mostly around how JP and co have delivered better security outcomes for MSSPs and enterprise SOC organizations using security data pipelines powered by Cribl. Cribl helps MSSPs scale operations. They can spend less time managing tools and data and more time detecting, analyzing, and remediating issues to better protect customers. Even though many security teams use the same technologies and tools, no two are the same in terms of the way they’ve configured and formatted the logs, meaning MSSPs have to reinvent the wheel every time they onboard a data source for a new tenant or customer. Cribl and Cribl Packs gives JP’s team the ability to apply the same logic across all customers without writing, managing, and maintaining custom code and parsers just to get data into a SIEM. Splunk, QRadar, Sentinel, Exabeam, or a homegrown SIEM–doesn’t matter, Cribl makes it easy to build and reuse data pipelines. Cribl helps enterprise SOCs and enterprise security teams. Like MSSPs, individual organizations also benefit from the streamlined data onboarding process. In addition to onboarding the data more easily, data formats are normalized and enriched with valuable context, so there’s greater accuracy and less work to do in the SIEM or analytics system. In some cases, JP has seen customers reduce SIEM ingest cost by up to 60-65% by taking the approach of sending everything to cheap storage and sending only what they need to the SIEM. But wait…isn’t ALL data security relevant? If we’re talking about reducing the amount of data going into the SIEM, how does that jive with this notion of the more data you have in your security analytics platform, the more “secure” you are, or the more likely you are to effectively reduce risk? All data is security relevant, but not all data needs to go to your SIEM to get the assurance you need. It turns out, that reducing the amount of data doesn’t impact the efficacy or change the risk profile for your organization. If you know your log sources, (or get some help from someone like JP) and, more importantly, what’s required to feed alerting logic, you can make smart decisions about what should go into your SIEM and what should go to S3. Customers can send the data they need, enriched in the stream with additional context like IPs, geolocation, user ID, all normalized before it hits the SIEM, so you get much cleaner data, with a lower initial time investment to get data in. We see customers able to bring in additional data sources, but only the relevant fields, so they still get the correlation they need to feed detection rules and alerting. And there’s an insurance policy–using Cribl’s Replay feature, you can pull data in from S3 for deeper investigations over longer time horizons. Security analysts can focus on core competencies. In JP’s view, the SOCs core competency is and should be handling and figuring out how to deal with alerts; SOCs Core competency is not data ingest. Similarly, for SOAR the goal is not to be writing integrations but to be focusing on complex investigations. “My mission in life is to build the cyber data pipelines to make it easy for the SOC operators to focus on investigating, responding and remediating to protect the business. Our team and Cribl facilitate the plumbing. Security analysts can focus on core competencies and do incident response--ultimately providing greater protection and insights for the business.” Note that with the challenges in recruiting, training, and retaining security talent, part of the problem is that we’re asking them to do 5+ jobs. Context switching is hard. Focusing on core competencies makes it easy to onboard new analysts faster and helps them focus on a core area of expertise. You should be able to own your own data. We talked a bit about Cribl’s vendor-agnostic vision for observability. JP got passionate again: “Here’s the thing, you should be able to own your data and not have break the bank to retain that data. And secondly, you want to be able to ask questions in future even if you don’t know the questions you want to ask today.” More organizations are moving to the cloud and deploying multiple SIEMs, but still need to maintain some sense of cost control or cost reduction. Most well-funded cloud SIEMs, have some strategy to ingest logs, but that strategy does not include the reduction or processes and tooling to only bring in what you need to pay only for what you need. Cribl gives teams control of their data to send it the relevant bits to the relevant destinations where it will be most efficient to analyze and economical to store. Thanks to JP and all of our customers who are helping us to build a great Cribl Community! If you’re just getting started with Cribl, you can check out our sandboxes, a guided experience with demo data at sandbox.cribl.io. There’s also a wealth of information, tips, tricks, and use case ideas on our blogs and Slack. We have user group meetings on the 2nd Tuesday of the month, and we just launched our Q&A forum curious.cribl.io. And of course, we’ll be at RSA in booth 5469 June 6-10 in San Francisco. Hope to see you there!