Securosis

Research

Resolve 90% of Cloud Incidents with RECIPE PICKS

As any long-time readers know, I constantly abuse my past experiences and hobbies to try and make my current work sound WAY more interesting than it probably is. Or maybe it’s just an ego thing, I don’t want to think too hard about it. But, on occasion, lessons from my parallel lives actually inspire some original work. As a paramedic and a pilot I have had to memorize many dozens of mnemonics, and I’ve forgotten many more. Mnemonics are proven to be highly effective memory devices even in the midst of intense stress, like flying a plane or working a 9-1-1 call. For example, I learned “SAMPLE” for taking a patient’s history probably 30 years ago and I still use it today because in the insanity that is some calls it can be easy to lose track and forget a fundamental. This I always remember to ask about Signs and Symptoms, Allergies, Medications, Prior medical history, Last oral intake, and Event (why did they call us today?). Having issues ventilating an intubated patient? Use DOPE. Accidentally put your airplane into a spin? Use PARE (Power, Aileron, Rudder, Elevator). The more you drill these the better they work. I memorized RAKETS for my private pilot checkride but I definitely need to look that one up (it’s used to figure out if you can still fly a plane with a broken part). We don’t really use these in infosec, and I think it’s time to change that. Thus I present to you RECIPE PICKS for cloud incident response. This one hit me yesterday on an internal dev review call in one window while finishing my paramedic recertification in an open browser tab. For 4 years now here is how I’ve taught what to look for first in a cloud incident: I have the students leave that one up when we start the scenarios and live fire exercises. But standing in the shower I came up with a much better way to remember what to do. NOTE: the order doesn’t matter, as with SAMPLE it’s to make sure you don’t miss anything (the format breaks a little at the end due to this sites rendering, sorry):               Resource (current config/state)               Events (api call(s) on that resource)               Changes (diff plus associated API calls)               Identity (who made the triggering change or API call)               Permissions (of the identity; informs the blast radius)               Entitlements (of the resource: e.g. it’s IAM role or managed identity)               Public (is it public?)               IP (all API calls from that IP address)              Caller (all other API calls from the calling identity) tracK (look for indications of a pivot; e.g. role chaining) forenSics (on a resource, or digging into resource logs) These steps shouldn’t be done in order, except the last two probably need to be the last two (especially the forensics). This is all based on the process I’ve figured out over the years and I estimate you can probably close 90% of incidents relatively quickly by pulling this data. I’m definitely going to start trying to build more of these into my trainings, and I’ll do some more blog posts in the coming weeks on how to use RECIPE PICKS. I’d also be remiss if I didn’t link over to a work blog post on how our platform does most of this automatically on every incident. Let me know what you think and if I missed anything. Just email rmogull@securosis.com since I have comments turned off due to all the ridiculous spam. Share:

Share:
Read Post

Check out the shiny new Cloud Security Maturity Model 2.0!

I’m pretty excited about this one. We are finally releasing version 2.0 of the Cloud Security Maturity Model. This is the culmination of nearly 9 months of research and analysis, a massive update from the original released in 2020. The tl;dr is that this version is not only updated to reflect current cloud security practices, but it includes around 100 cloud security control objectives to use as Key Performance Indicators — each matched 1:1 (where possible) with a technical control you can assess (AWS for now— we plan to expand to Azure and GCP next). You can download it here — no registration wall, and it includes the spreadsheet and PDFs. The CSMM 2.0 was developed by Securosis (that’s us!) and IANS Research in cooperation with the Cloud Security Alliance. Version 2.0 underwent a public peer review process at the CSA and internal review at IANS. We will keep updating it based on public feedback. The model includes nearly 100 control objectives and controls, organized into 12 Categories in 3 Domains. IANS released a free diagnostic self-assessment survey tool. You can quickly and easily generate a custom maturity report. FireMon added a free CSMM dashboard to Cloud Defense, which will automatically assess, rate, and track your cloud maturity using the CSMM! It’s really cool. But I’m biased because I pushed hard to build it. Okay, that’s what it is, but here’s why you should care. When Mike and I first built the CSMM we designed it more as a discussion tool to describe the cloud journey. Then we started using it with clients and realized it also worked well as a framework to organize a cloud security program. Two of the big issues with cloud governance we’ve seen in the decade-plus we’ve been doing this are: Existing security frameworks have been extended to cloud, but not designed for cloud, which creates confusion because they lack clear direction. Those don’t tell you “do this for cloud” — they tell you “add this cloud stuff”. We saw need for a cloud-centric view. Security teams quickly get tossed into cloud, and while tooling has improved immensely over time, those flood you with data and don’t tell you where to start. We don’t lack tools, but we do lack priorities. Version 2.0 of the CSMM was built directly to address these issues. We reworked the CSMM to work as a cloud security framework. What does that mean? The model focuses on the 12 main categories of cloud security activities, which you can use to organize your program. The maturity levels and KPIs then help define your goals and guide your program without the minutiae of handling individual misconfigurations. What’s the difference between the Diagnostic and the Dashboard? The IANS diagnostic is where you should start. It’s a survey tool anyone can fill out without technical access to their deployments. The objective of the diagnostic is to help you quickly self-assess your program and then, using that, determine your maturity objectives. Let’s be realistic — not all organizations can or should be at “Level 5”. The diagnostic helps set realistic goals and timelines, based on where you are now. The FireMon Cloud Defense CSMM Dashboard is a quantitative real-time assessment and tracking tool. Once you integrate it with your cloud accounts you’ll have a dashboard to track maturity for the entire organization, different business units, and even specific accounts. It’s the tool to track how you are meeting the goals established with the diagnostic. It’s self-service and covers as many AWS accounts as you have (Azure will be there once the CSMM adds Azure controls). You can also just use the CSMM spreadsheet. Options are good. Free options are better. Finally, please send me your feedback. These are living documents and tools, and we plan to keep them continuously updated. The usual disclosure: I’m an IANS faculty member and I manage the Cloud Defense product. But both of these are available absolutely free, no strings attached, as is the model itself. Share:

Share:
Read Post

I Broke the 3-2-1 Rule and Almost Paid The Price!

This post isn’t about some fancy new research. Consider it a friendly nudge to floss. I’m pretty Type A about backing up and have data going back 20+ years at this point. I’m especially particular about my family photos. Until yesterday (this is called foreshadowing) my strategy was: Time Machine running on a Drobo for my main Mac Drobo as a company is dead, but this is a direct attached 5D, which has worked well and has enough capacity that I can lose drives and recover (which has happened). The Drobo as mass storage for the large files I don’t store on my SSD. Archives, VMs, videos. A WD MyBook with 12 TB, also directly connected to my Mac. Data replicated from there using Carbon Copy Cloner. Backblaze for cloud backups. With a personal encryption key. iCloud (I’m on the 6TB plan) for all my photos and related iCloud stuff. iCloud is synced across multiple systems. Box for Securosis corporate documents. Some older S3/Glacier archives. Probably more. I’m old and forget things. My entire house could burn down and I shouldn’t lose anything. But I broke the 3-2-1 rule. The 3-2-1 rule of backups is 3 copies of everything, at least 2 of them local, and 1 offsite. My Drobo died. Completely and suddenly. Not a single drive, but the entire thing. And the moment it happened I couldn’t remember whether I was backing up ALL of the Drobo anywhere else. It was RAID — what were the odds of losing the entire device? I knew I needed to replace it soon because the drivers weren’t being updated, but I kept putting it off. Well okay, I should be fine with my CCC backups… except that wasn’t set as a scheduled job, and I was only replicating one of the Drobo partitions. The other partitions? Well, one of them had my in-progress CloudSLAW video for next week and a demo video for the new CSMM feature we are releasing at work (remember, foreshadowing). Two time-sensitive things I REALLY didn’t want to recreate. Cloud/Backblaze to the Rescue and My New Strategy It turns out I really was sending everything from every drive to the cloud, and keeping versions for a year. It cost me just over $100 (for a single machine). I’ve never thought much about it, but all the data was there. The clincher was fast, selective restore. I was able to directly what I needed, including the video files, and download a .zip in less than an hour. Then I ordered a Synology, and I’ll go through the longer restore process once that arrives. Does this mean I can skip keeping 2 local versions on separate devices? And doesn’t RAID count as 2 devices? Nope and nope. But here’s my strategy and reasoning: an evolution of the 3-2-1 rule: Family photos and things I never want to lose are stored on 2-4 local devices and at least 2 different cloud providers, with occasional archives to a third provider. My iCloud Photos sync to my Mac. That’s backed up to via Time Machine and to the (soon to arrive) Synology. It also goes to Backblaze, and a couple times a year I archive to S3. All critical business documents are in 2 cloud services. That’s Box, and since I sync the files locally, they also land in my cloud backups of my local drive. Code and other documents are in places like GitHub and OneDrive, depending on which hat I’m wearing. I just make sure there are 2 of everything at 2 different services. A bootable image of my working Mac. I use Carbon Copy Cloner for this. I’m not as religious about it because I can fully work off my laptop when needed. Archived and media files are single copies on the RAID, but the RAID is backed up to cloud, from where I can selectively restore. These are the things I am okay with not having right away. UPDATE: I will now keep my working video files on a second local drive. This will be directly attached to my Mac, and backed up to both the cloud and the new RAID (Synology), which will be network attached instead of directly connected. So, 3-5 copies of all files. 1-3 local based on priority, 1-3 in cloud, also based on priority. Baby pics are 3 local, 3 in different cloud services. Full system is 2 local, 1 bootable. Work documents at 2 cloud services, at least one with versioning. Large “working” (media) files are 2 local, one on fast storage and the other RAID. Mass storage is 1 local (RAID) and 1 versioned copy in cloud. All critical work applications should be on 2 systems (laptop/desktop, and for me I do a ton on iPad). I lucked out this time. I really did not remember sending the Drobo files to Backblaze, and had a brief panic attack. And I hadn’t used selective restore previously, which helped me rapidly find and download the working files I needed. I’m gonna go floss now. Share:

Share:
Read Post

Regression to the Fundamentals

After 25 years in technology, mostly in security, I recently realized I’m regressing. No, not in terms of my mental acuity or health (although all of you would be better judges on my brain function), but more in terms of my career. And no, I don’t mean I’m going back to the Helpdesk… and according to my children and most of my family I never really left anyway. Not that I’m paid for it. Well, sometimes with some cookies. But never enough cookies. It’s just that the longer I do this the more I realize that it’s the fundamentals that really matter. That as much as I love all the fun advanced research, all that work really only addresses and helps a relatively small percentage of the world. The hard problems aren’t the hard problems; the hard problems are solving the easy problems consistently. We mostly suck at that. What’s fascinating is that this isn’t a problem limited to security. I really noticed it recently when I was working on my paramedic recertification. As a paramedic I can do all sorts of advanced things that involve drugs, electricity, and tubes. In some cases, especially cardiac arrest, the research now shows that you, the bystander, starting good quality CPR early is far more important than me injecting someone with epinephrine. In fact, studies seem to indicate that epi in cardiac arrest does not improve long term patient outcomes. CPR and electricity (AEDs) for the win. Advanced clinicians for myself? Useful and necessary, but useless without the fundamentals before we get there. Back to security. As a researcher (and a vendor) we are drawn to the hard problems. I’m not saying they don’t matter — they very much do. As much as AI is in the hype machine right now it’s there for a reason and we need experts engaged early, even if most of what they’ll do will fail because AI is a truly disruptive innovation. If you don’t believe me just re-read this sentence after the 2024 election. And some basic problems need new innovations instead of banging our heads against the wall. Passwordless is a great example of attacking an intractable problem with hard engineering that is invisible to users. As much as I’d like to be doing more leading-edge research, I keep finding myself focusing on the basics, and trying to help other people do the basics better. Let’s take cloud incident response, my current bread and butter. Will Bengtson and I keep coming up with all sorts of cool, advanced cloud attacks to include in our IR training at Black Hat. The reality is those are mostly there so people think we are smart and to keep the rare advanced students interested. Nearly all cloud attacks a student working on a real IR team will encounter are the same two or three “simple” things. Lost or stolen credentials used for crypto, ransomware, or data exfiltration, or hacking a vulnerable public-facing instance for… crypto,  ransomware, or data exfiltration. Instead of spending my time on leading-edge research I’m building training for people with zero experience. I’m working on simple models which hopefully help people focus better. On the product side I’m focusing more on basic problems that seem to slip through the gaps. Chris Farris and I are working on a new talk and threat modeling approach to focus consistently on the fundamentals which really matter, not all the crazy advanced stuff in your inbox every day. Researchers and research teams mostly publish on the fun, interesting and advanced things because that’s more intellectually interesting and gets the headlines. There’s nothing wrong with that — we need it — but never forget that the basics matter more. I still get FOMO from time to time, but in the end I can do a lot more good at a much larger scale focusing on helping with fundamentals. Simple isn’t sexy, but without plumbers we’re all covered in shit pretty damn quickly. As a paramedic the one thing we are exceptional at is facing utter chaos, identifying what will kill you, and keeping things from getting worse. Maybe I biased my career from the start. Chris says he objects to being called a simple problem. Please humor him. Will just asked that I spell his name correctly.   Share:

Share:
Read Post

Is This Thing Still On?

I started a blog in 2006. This blog, to be precise. I kinda just wanted a blog. Blogs were cool. Twitter wasn’t really a thing yet. YouTube was only like a year old. The iPhone was hiding in an engineering and design lab. I didn’t expect securosis.com to be around 18 years later. I certainly didn’t expect it would become my full time job for 15 of those years. I most definitely didn’t expect to take on partners, spin out a product startup, have kids, lose my hair, grow… other hair, lose a partner (to a bank, not the grave, if there’s a difference), and, as of last weekend, migrate the entire site to our fourth hosting provider and third new software stack without losing any significant content. And most embarrassing of all, I didn’t expect to not write on my own site for… 3 years. But that’s what happens when you build a startup that gets acquired (and I still work there full time), your consulting customers keep you super busy with hands-on technical projects, and you spend a chunk of the pandemic running around playing paramedic. Oh, and when your kids hit the age where you and your wife effectively become unpaid ride share drivers. Now it’s time to come home. I’m still working and writing at FireMon and other places, but thanks to the success of CloudSLAW (my lab a week newsletter/blog/YouTube channel) I have the itch to just start blogging about random non-day-job security stuff again. I also have some new research on the way, and maybe some friends will be dropping in. Securosis (the company) is just for side projects now, and weirdly I think that gives me a freedom in my writing I forgot about. We just moved the site and I’m slowly updating things. In the coming weeks I also plan to pull some old posts from the 18-year history of this site and rip them to shreds with my modern knowledge and sensibilities. I hope some of you stick around for the ride, but I plan to have fun no matter what. Share:

Share:
Read Post

The THIRTEENTH Annual Disaster Recovery Breakfast: Changing of the Guard

What a long, strange trip it’s been over the last 3 years. In fact, the last time I saw many of you was at the last Disaster Recovery Breakfast in 2020. Within two weeks of that event, the world shut down due to COVID. Well, a lot has changed since then. DisruptOps was acquired by Firemon in September 2021. In early 2022, Rich decided he wanted to see our cloud security vision through and dedicate his full-time efforts to the Cloud Defense product. In July of 2022, I decided to partner with Alan Shimel and Mitch Ashley and join Techstrong as head of the research business. We still do cloud security training and house our cloud security content in Securosis, but we’ve both moved on. Our long-time venue for the DRB, Jillian’s (then TableTop Tap House) in San Fransisco, didn’t survive the pandemic. They went out of business in early 2022 and took our deposit for the 2022 DRB with them. Ouch. But given the lack of venues and the rescheduling of the RSA Conference to June 2022, we couldn’t pull off the breakfast last year. But this year, we are back. But it’s different. We have a different venue, which is The Pink Elephant (142 Minna St). We have a different organizer, which is now Techstrong and our Security Boulevard site. We have mostly the same sponsors, so we need to thank our pals at IANS, LaunchTech, and AimPoint Group. Their support is critical. So yes, we’ve had a changing of the guard. But what isn’t different is breakfast. It’s still a place where you can grab some breakfast and see some friends without the pomp and circumstance of a major conference. We hope to see you there. Share:

Share:
Read Post

Heading to Techstrong

The phone rang. On the other end, I heard a booming voice many of you are familiar with. “Hey Mikey! What’s shaking? What’s your plan now that Rich is with Firemon?” It was Alan Shimel, my good friend and head of Techstrong Group. It was maybe 10 minutes after Rich’s announcement had hit Twitter. I told Alan I would stay the course, but he had other ideas. “We should do something together. Think about it.” So I did. We had a call a few days later and started sketching out what it would look like if I joined Alan and the team. I’d want to build a research team since that’s what I love to do. I’d also like to have a hand in developing the corporate strategy. Alan said that sounded great; when can I start? I wasn’t there yet. I needed to know more about the business. I needed to spend some more time with the team. So I made the pilgrimage down to Boca to do a working session with Alan and see what we could work out. I learned that Techstrong is at the center of some pretty disruptive technology shifts, like DevOps (yes, DevOps.com is ours), cloud-native computing, containers (containerjournal.com), microservices, and of course, security (securityboulevard.com). There is an excellent events business with tons of virtual events. I’ve been a guest on TechstrongTV more times than I could count, so I know about their video capabilities. And the company has a top-notch customer list. So there is an exciting platform to build on. But could I have an impact? Next, I dug into the research business that another old friend, Mitchell Ashley, created. There are some short reports and they did some speaking gigs, but Techstrong Research didn’t have a point of view about where the markets are heading. So it was “research,” but not the kind of research I do. So yeah, I can have an impact on Techstrong Research. The timing also felt right. My youngest kids are off to college in August, so it’s a good time to make some changes. It’s not like my partners at Securosis haven’t done a similar thing. Adrian headed off into corporate cloud land a couple of years ago. Rich made a move to Firemon earlier this year. As much as I loved the 12 years with Securosis, I’m ready to tilt at another windmill. Though it had to be the right situation, and I found that with Techstrong. I’m happy to say I’m taking my talents to ~~South Beach~~ Boca. I’ve taken the role of Chief Strategy Officer of Techstrong Group and General Manager of Techstrong Research.   The intangibles made this an easy decision for me. It’s about working with my friends. It always has been. I have been fortunate to work with Rich and Adrian for the past 12 years. When we spun out DisruptOps, I was able to work with Jody Brazil, Brandy Peterson, and Matt Eberhart. And now I get to work with my good friends Alan, Mitch, and Parker. I have no illusions about how much work lies ahead. I’m back to building a research business, and it’s very exciting. Ultimately I’m a builder, and I’m lucky to have the opportunity to build with another set of good friends. Securosis is still a thing. Rich and I will continue to run our cloud security curriculum and training activities here. But Securosis will no longer function as an analyst firm. I’ll continue to support existing clients, but that work will transition to Techstrong Research when it makes sense. I’m not sure if this is good or bad, but you’ll see a lot more of me. I’ll be visible across the Techstrong network, writing, speaking, and interviewing exciting companies. I’ll be publishing trends and forward-looking research and ensuring that Techstrong has a strong point of view about where technology is going. I’ll be at Black Hat, so if you are there, let me know. It’ll be great to meet up, and I can fill you in on all the cool stuff we do at Techstrong.   Share:

Share:
Read Post

SOC 2025: Operationalizing the SOC

So far in this series, we’ve discussed the challenges of security operations, making sense of security data, and refining detection/analytics, which are all critical components of building a modern, scalable SOC. Yet, there is an inconvenient fact that warrants discussion. Unless someone does something with the information, the best data and analytics don’t result in a positive security outcome. Security success depends on consistent and effective operational motions. Sadly, this remains a commonly overlooked aspect of building the SOC. As we wrap up the series, we’re going to go from alert to action and do it effectively and efficiently, every time (consistently), which we’ll call the 3 E’s. The goal is to automate everything that can be automated, enabling the carbon (you know, humans) to focus on the things that suit them best. Will we get there by 2025? That depends on you, as the technology is available, it’s a matter of whether you use it. The 3 E’s First, let’s be clear on the objective of security operations, which is to facilitate positive security outcomes. Ensuring these outcomes is to focus on the 3 E’s. Effectiveness: With what’s at stake for security, you need to be right because security is asymmetric. The attackers only need to be right once, and defenders need to defeat them every time. In reality, it’s not that simple, as attackers do need to string together multiple successful attacks to achieve their mission, but that’s beside the point. A SOC that only finds stuff sometimes is not successful. You want to minimize false positives and eliminate false negatives. If an alert fires, it should identify an area of interest with sufficient context to facilitate verification and investigation. Efficiency: You also need to do things as quickly as possible, consuming a minimum of resources due to limited available resources and the significant damage (especially against an attack like ransomware) that can happen in minutes. You need tooling that makes the analyst’s job easier, not harder. You also need to facilitate the communication and collaboration between teams to ensure escalation happens cleanly and quickly. Breaking down the barriers between traditional operational silos becomes a critical path to streamlining operations. Every Time (Consistency): Finally, you need the operational motions to be designed and executed the same way, every time. But aren’t there many ways to solve a problem? Maybe. But as you scale up your security team, having specific playbooks to address issues makes it easy to onboard new personnel and ensure they achieve the first two goals: Effectiveness and Efficiency. Strive to streamline the operational motions (as associated playbooks) over time, as things change and as you learn what works in your environment. Do you get to the 3 E’s overnight? Or course not. It takes years and a lot of effort to get there. But we can tell you that you never get there unless you start the journey. Defining Playbooks The first step to a highly functioning SOC is being intentional. You want to determine the proper operational motions for categories of attacks before you have to address them. The more granular the playbook, the less variance you’ll get in the response and the more consistent your operations. Building the playbooks iteratively allows you to learn what works and what doesn’t, tuning and refining the playbook every time you use it. These are living documents and should be treated as such. So how many playbooks should you define? As a matter of practice, the more playbooks, the better; but you can’t boil the ocean, especially as you get started. Begin by enumerating the situations you see most frequently. These typically include phishing, malware attacks/compromised devices, ransomware, DDoS, unauthorized account creation, and network security rule changes. To be clear, pretty much any alert could trigger a playbook, so ultimately you may get to dozens, if not hundreds. But start with maybe the top 5 alerts detected in your environment and start with those. What goes into a playbook? Let’s look at the components of the playbook: Trigger: Start with the trigger, which will be an alert and have some specific contextual information to guide the next steps. Enrichment: Based on the type of alert, there will be additional context and information helpful to understanding the situation and streamlining the work of the analyst handling the issue. Maybe it’s DNS reputation on a suspicious IP address or an adversary profile based on the command and control traffic. You want to ensure the analyst has sufficient information to dig into the alert immediately. Verification: At this point, a determination needs to be made as to whether the issue warrants further investigation. What’s required to make that call? For a malware attack, maybe it’s checking the email gateway for a phishing email that arrived in the user’s inbox. Or a notification from the egress filter that a device contacted a suspicious IP address. For each trigger, you want to list the facts that will lead you to conclude this is a real issue and assess the severity. Action: Upon verification, what actions need to be taken? Should the device be quarantined and a forensic image of the device be captured? Should an escalation of privileges or firewall rule change get rolled back? You’ll want to determine what needs to be done and document that motion in granular detail, so there are no questions about what should be done. You’ll also look for automation opportunities, which we’ll discuss later in the post. Confirmation: Was the action step(s) successful? Next, confirm whether the actions dictated in the playbook happened successfully. This may involve scanning the device (or service) to ensure the change was rolled back or making sure the device is not accessible anymore to an attacker. Escalation: What’s next? Does it get routed to a 2nd tier for further verification and research? Is it sent directly to an operations team to be fixed if it can’t be automated? Can the issue be closed out because you’ve gotten the confirmation that

Share:
Read Post

SOC 2025: Detection/Analytics

We spent the last post figuring out how to aggregate security data. Alas, a lake of security data doesn’t find attackers, so now we have to use it. Security analytics has been all the rage for the past ten years. In fact, many security analytics companies have emerged promising to make sense of all of this security data. It turns out analytics aren’t a separate thing; they are part of every security thing. That’s right, analytics drive endpoint security offerings. Cloud security products? Yup. Network security detection? Those too. It’s hard to envision a security company of scale without analytics playing a central role in providing value to their customers. As a security leader, what do you have to know about analytics and detection as you figure out how the SOC should evolve? First, it’s not about [analytics technique A] vs. [analytics technique B]. It’s about security outcomes, and to get there you’ll need to start thinking in terms of the SOC platform. Defining the SOC “Platform” The initial stab at the SOC platform already exists with some overlapping capabilities. You already have a security monitoring capability, maybe an on-prem SIEM. As discussed in the last post, the SOC platform should include threat intelligence. Currently, some organizations use a separate threat intel platform (TIP) to curate and prioritize the incoming external data. The third leg of the SOC platform is operations, where validating, verifying, and ultimately addressing any alerts happens. We’ll have a lot to say about security operations in the next post. Though it may seem the evolved security operations platform is just bolting together a bunch of stuff you already have, we are advocating for an evolutionary approach in the SOC. You certainly could ditch the existing toolset and start from scratch, and as liberating as that may be, it’s not practical for most organizations. For instance, you’ve spent years tuning your on-prem SIEM to handle existing infrastructure, and you have to keep the SOC operating, given the attackers aren’t going to give you a break to accommodate your platform migration. Thus, it may not make sense to scrap it. Yet. Although you do have to decide where the SOC platform will run, here are some considerations: Data Location: It’s better to aggregate data as close to the originating platform as possible, so you keep cloud-based security data in the cloud, and on-prem systems go into an on-prem repository. That minimizes latency and cost. In addition, you can centralize alerts and context if your operational motions dictate. Operations Approach: Once the alert fires, what then? If you have an operations team that handles both cloud and on-prem issues, then you’ll need to centralize. The next question becomes do you consolidate the raw security data, or just the alerts and context? Care and Feeding: How much time and resource do you want to spend keeping the monitoring system up and running? There are advantages to using a cloud-based, managed platform that gets you out of the business of scaling and operating the infrastructure. The long-term trend is towards a managed offering in the cloud, but how quickly you get there depends on your migration strategy. If you’ve decided that your existing SIEM is not salvageable, then you are picking a new platform for everything and migrating as quickly as possible. But we see many organizations taking a more measured approach, focusing on building the foundation of a new platform that can handle the distributed and hybrid nature of computing in the cloud age while continuing to use the legacy platform during the migration. Analysis Once you have internal and external data collected and aggregated, you analyze the data to identify the attacks. Easy, right? Unfortunately, there is a lot of noise and vendor puffery for how the analytics actually work, making it confusing to figure out the best approach. Let’s work through the different types of techniques used by SOC tools. Rules and Reputation: Let’s start with signature-based controls, the old standard. You know, the type of correlation your RDBMS-based SIEM performed for decades. Adding patterns enumerated in the ATT&CK framework (which will discuss later in this post) helps narrow the scope of what you need to look for, but you still need to recognize the attack. You’ll need to know what you are looking for. Machine Learning: The significant evolution from simple correlation is the ability to detect an attack you haven’t seen. Advanced analytics can be used to define an activity baseline, and with that baseline defining normal behavior within your environment, your detection engine can look for anomalies. Getting into the grungy math of different machine learning models and cluster analyses probably won’t help you find attackers faster and more effectively. Continue to focus on the security outcomes during your evaluation. Does it find attacks you are likely to see? How much time and effort will it take to isolate the most impactful alerts? What’s involved in keeping the platform current? And ultimately, how will the platform’s analytics make the team more efficient? Stay focused on ensuring any new platform makes the team better, not on who’s math is better. Use Cases You may be bored (and maybe frustrated) with our constant harping on the importance of use cases in detecting attacks. There is a method to our madness in that use cases make a pretty nebulous concept more tangible. So let’s dig into a handful of use cases to get a sense of how a SOC platform will favorably impact your detection efforts. Ransomware Ransomware doesn’t seem to get as many headlines nowadays, but don’t be fooled by the media’s short attention span. Ransomware continues to be a scourge, and every company remains vulnerable. Let’s examine how an evolved SOC handles detects ransomware? First, ransomware isn’t new, particularly not the attacks — it typically uses commodity malware for the initial compromise. Attackers are more organized and proficient — once they have a foothold within a victim’s network, they perform extensive reconnaissance to find and destroy

Share:
Read Post

SOC 2025: Making Sense of Security Data

Intelligence comes from data. And there is no lack of security data, that’s for sure. Everything generates data. Servers, endpoints, networks, applications, databases, SaaS services, clouds, containers, and anything else that does anything in your technology environment. Just as there is no award for finding every vulnerability, there is no award for collecting all the security data. You want to collect the right data to make sure you can detect an attack before it becomes a breach. As we consider what the SOC will look like in 2025, given the changing attack surface and available skills base, we’ve got to face reality. The sad truth is that TBs of security data sit underutilized in various data stores throughout the enterprise. It’s not because security analysts don’t want to use the data. They don’t have a consistent process to evaluate ingested data and then analyze it constantly. But let’s not get the cart before the proverbial horse. First, let’s figure out what data will drive the SOC of the Future. Security Data Foundation The foundational sources of your security data haven’t changed much over the past decade. You start with the data from your security controls because 1) the controls are presumably detecting or blocking attacks, and 2) you still have to substantiate the controls in place for your friendly (or not so friendly) auditors. These sources include logs and alerts from your firewalls, IPSs, web proxies, email gateways, DLP systems, identity stores, etc. You may also collect network traffic, including flows and even packets. What about endpoint telemetry from your EDR or next-gen EPP product? There is a renewed interest in endpoint data because remote employees don’t always traverse the corporate network, resulting in a blind spot regarding their activity and security posture. On the downside, endpoint data is plentiful and can create issues in scale and cost. The same considerations must be weighed regarding network packets as well. But let’s table that discussion for a couple of sections since there is more context to discuss before truly determining whether you need to push all of the data into the security data store. Use Cases Once you get the obvious stuff in there, you need to go broader and deeper to provide the data required to evolve the SOC with advanced use cases. That means (selectively) pulling in application and database logs. You probably had an unpleasant flashback to when you tried that in the past. Your RDBMS-based SIEM fell over, and it took you three days to generate a report with all that data in there. But hear us out; you don’t need to get all the application logs, just the relevant ones. Which brings us to the importance of threat models when planning use cases. That’s right, old-school threat models. You figure out what is most likely to be attacked in your environment (think high-value information assets) and then work backward. How would the attacker compromise the data or the device? What data would you need to detect that attack? Do you have that data? If not, how do you get it? Aggregate and then tune. Wash, rinse, repeat for additional use cases. We know this doesn’t seem like an evolution; it’s the same stuff we’ve been doing for over a decade, right? Not exactly as the analytics you have at your disposal are much improved, which we’ll get into later in the series. Those analytics are constrained by the availability of security data. Yet you can’t capture all the data, so focus on the threat models and use cases that can answer the questions you need to know. Cloud Sources Given the cloudification of seemingly everything, we need to mention two (relatively) new sources of security data, and that’s your IaaS (infrastructure as a service) providers and SaaS applications. Given the sensitivity of the data going into the cloud, over the seemingly dead bodies of the security folks that would never let that happen, you’re going to need some telemetry from these environments to figure out what’s happening, if those environments are at risk, and ultimately to be able to respond to potential issues. Additionally, you want to pay attention to the data moving to/from the cloud, as detecting when an adversary can pivot between your environments is critical. Is this radically different from the application and database telemetry discussed above? Not so much in content, but absolutely in location. The question then becomes what and how much, if any, of the cloud security data do you centralize? What About External Data? Nowadays, you don’t just use your data to find attackers. You use other people’s data, or in other words, threat intelligence, which gives you the ability to look for attacks that you haven’t seen before. Threat intel isn’t new either, and threat intel platforms (TIP) are being subsumed into broader SOC platforms or evolving to focus more on security operations or analysts. There are still many sources of threat intel, some commercial and some open source. The magic is understanding which sources will be useful to you. That involves curation and evaluating the relevance of the third-party data. As we contemplate the security data that will drive the SOC, effectively leveraging threat intel is a cornerstone of the strategy. Chilling by the (Security Data) Lake In the early days of SIEM, there wasn’t a choice of where or how you would store your security data. You selected a SIEM, put the data in there, started with the rules and policies provided by the vendor, tuned the rules and added some more, generated the reports from the system, and hopefully found some attacks. As security tooling has evolved, now you’ve got options for how you build your security monitoring environment. Let’s start with aggregation. Or what’s now called a security data lake. This new terminology indicates that it’s not your grandad’s SIEM. Rather it’s a place to store significantly more telemetry and make better use of it. It turns out this new fangled data lake doesn’t

Share:
Read Post
dinosaur-sidebar

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.