In this two-part post, we wanted to give our SANS prospective students as well as our broader info sec community, a peak into the story of one of our course authors, John Hubbard, who recently launched a new course, SEC450: Blue Team Fundamentals – Security Operations and Analysis.

In case you missed it, go back to part one, and learn more about John: his early career aspirations, insights from his career journey with GlaxoSmithKline, how he got introduced to SANS and began teaching.

In part two, we’ll dive into a bit more details about the course, who it was designed for and a walkthrough of each day in the course, what tools are covered and what students can expect to come away with. John also explains briefly, the differences between SEC401 and SEC450 and whether someone who has already taken a 500-level course, should still consider taking SEC450.

PART TWO

9: Tell us a little bit about the course – SEC450: Blue Team Fundamentals – Security Operations and Analysis.

The course [SEC450] is meant for people who are new to the analyst position and are working in a Security Operations Center (SOC) or want to understand how a SOC is going to work. The subtitle in there gets a little bit more into the specifics of what's in the course –

Blue Team Fundamentals speaks to - it’s for newer people.

Security Operations and Analysis -

The Operations part is trying to convey what people are going to be doing and thinking on a day to day basis. You sit down, you're in front of a SIEM, you're in front of an IDS. There's a list of alerts, there's logs coming in. What is it that you should be seeing and what mental model should you have when you're looking at this data to try to understand what's priority? What could be an attack? What's maybe not an attack? And how to put those things on a spectrum of ‘this is the most important thing I need to deal with right now and here's the options of what that could be’ in terms of a type of attack. Is it targeted? Is it an opportunistic attack? What might the adversaries want and how do the different adversary groups break down and what is their interests?

And then there's the Analysis portion of the title - which is how do we do thorough cognitive bias free analysis in terms of looking at the data you're presented and not falling into the trap of trying to come up with a theory and then prove that theory. When people sit down and try to do analysis, it feels like a very intuitive thing to do. You have the data, come up with what you think it is, and then you look for evidence of that and you're done, right? Well not exactly. You have to look for other things that it could be. You have to come up with multiple different hypothesis and understand what are the differentiating factors that could tell you whether it's one specific situation or another. I wanted to put that process in the course as well. Because that's a lot of things.

I talked about that actually when I taught the courses throughout the years. And people were always like, "Wow that stuff is really interesting. I never really thought about it like that." And so I was like, yeah this definitely needs to go into the course. Because even people that were in SEC511 and otherwise seemed very interested in that. Day Four specifically is actually focused on the whole triage of analysis bit. And so that's where that piece comes from in the title.

10: Who exactly was the course designed for?

It's designed for people getting their first Security Operation Center (SOC) job or they've maybe been in a year or two, and they're trying to up their skills in terms of getting to that next level of maybe senior analyst or just want to understand and very, very quickly hit the ground running, what they should be looking for and what to think about and how to look at their data.

I also have a lot of interest from managers who had come up not the way I did, from being an analyst, but had maybe come from a different route. They were managers for other groups and now put in as managers of a SOC. They want to understand the new tools of the SOC and how it all fits together and what their analysts are doing, right. Obviously, everyone wants to have a manager that understands what their job is and the struggles and all that. I've seen managers sign up for it and look for that sort of perspective as well. I would say those two are the main groups.

11: Could you give us a high level walk through of each day of the course.

Sure. Day One is the initiation to the Blue Team. It explains ‘Here’s why we're here. Here's what we're doing,’ at a high level. I'm framing out the course, explaining the mindset you need to have as a defender, and understand that you are here to provide a service for a company that's ultimately sort of like loss prevention. You're going to have a non-ideal set budget and tools and things to work with and you're going to have to make the best of it. You're also going to have to work with management to understand what the concerns are and make sure your tools and things are aligning with those.

That's how the class starts and setting the mindset of this is what the job is. And, yes, we all want to come in and tear everything up and make the most perfect security, right. But then we find out that's not something that can happen in a lot of cases. I love the energy new analysts come in with, "Oh, we're doing all this stuff and we need to fix it." And I'm like, "Yes, I get that, but we also have to make sure things continue to get done around here." So it's really about finding the balance of what's the best that we can do while still hitting budget and the goals of the threat model or whatever it is that the company is worried about. We talk about that just in the first part of the first day to set the stage for what we're doing and why we're doing it.

Then we start talking about the tools of the SOC. The threat intelligence platform, SIEMs, automation tools, ticketing systems. We talk about alerts versus events versus incidence, and how all the data flows together and what the big picture is. I try to take a systems level view of abstracting things. And say like, "Here's a box for SIEM, here's a box for the threat intel platform. And this is what's going between the two." And the same thing for your incident management system and logs and other stuff. I just explain at a high level how data is collected, what type of data it is and how it flows in between all the tools.

Once we get into Day Two, we go into some deep technical detail on network protocols. And stuff that I want new analyst to definitely know. Covering the main things you see in almost every alert - DNS, HTTP, HTTPS, SNTP protocol. How to understand what it's doing. How to take apart an email. Look at all the headers. Understand if it's spoof That one's the really difficult one. I see a lot of analysts struggle with that. SNTP is very confusing. I made sure to cover that in some pretty good detail there. We have some really cool labs that go with that too. One where we actually send a spoof email and see all he headers and various other things. And set up your own mail server. And then also talk about some of the other stuff like FTP and SSH and SNV. And how those are levers in attacks. When you're looking at these normal otherwise network services, how you do differentiate between good HTTP and bad HTTP. And what are the things you're going to be looking for in terms of headers and methods and stuff like that.

Day Three is more endpoint focused. We're talking about what is it that you're looking for to happen on the endpoint that would indicate that something malicious is occurring. When malware installs, what kind of stuff is it doing? How is it changing the endpoint? How can you collect that data and bring it into your SIEM and then understand what it's telling you? And pick out something good versus something bad. I have a little about log collection and how Windows logging works. How Linux logging works. And then how to interpret those events. And then how your SIEM is going to normalize them and categorize them and make them better.

The whole thing that a SOC is doing is we're collecting a whole bunch of data, right. And then we're filtering it, funneling it down into events of interest. And then we're doing triage on those events and then we're doing investigation of what we're triaging. A lot of analysts live at the end of that. Where we're triage and you look at the events and investigate them. But I really like analysts who know the whole spectrum of - What is a window's log format? Why is it coming in the way that we're seeing it? And what are the options to make it better? Because a lot of times it's really hard to catch an attack if you don't know what the possibilities are for Windows logging and you have a suboptimal configuration. I wanted to teach everyone the whole back to the front of how we manufacture data on an endpoint and ultimately get it to us and what happens along the way.

Day Four we also go into the triage and analysis stuff - when you have those alerts, now popped up from your IDS or from your antivirus or whatever, how do we understand which one is the one you need to go to first? How can we read between the lines on the alerts and say like, "Oh this one is a near disaster." This is at the end of the server kill chain. We need to address this very, very quickly. Or maybe this one looks like a targeted attack and this one does not. And then how to make the right choice in that situation. Because that's something we do basically all day every day.

And then the analysis part. How do we do cognitive bias free analysis? We talk about some structure analysis, not bids and how to make sure that you are coming to the right conclusion and not moving to fast. Documenting stuff thoroughly. How do we check ourselves? How do we have analyst review processes to make sure that we are keeping a high quality of an investigation as we go over the time?

And then Day Five is continuous improvement analytics and automation. And what that is, is they learn to be focused. The highest level is - How do we make this job fun and engaging and take out the parts that are painful. Continuous improvement I speak to... I found some actual research done by some investigators that were looking at how SOC burnout happens and what are the factors that cause it. I wrote that into that day. And I start the day talking about that and then use that as a framework to steer where the rest of the day goes in terms of addressing those specific items. Talking about growth and empowerment and the various factors that keep people happy in their job. And how do we make sure the SOC is running processes that do that.

We talk about false-positive reduction. That's another thing that people hate about working in the SOC. Just too many false positives. What is the process you can actually go through? And what causes false positives? And how can you look at all the alerts we had and reduce those things. And then obviously automation plays a big part of that as well. It's a big buzz word right now in sub security, but for good reason. One of the things people hate, one of the things I hated, was manually doing things that there was no reason for me to be doing as a human. If we can script something, right. If we can make a computer do it, a computer should be doing it. And there are things that people are good at: analysis, judgment calls. And there are things that computers are good at: filling in text, shuffling data. And so how do we make sure that we have the optimal mix of those things so that people enjoy their job.

And then ultimately it all culminates on a Day Six challenge like many of the others courses. I have a set of data ingested into course tools that we've been using along the way. Which is a threat intel platform and all of that kind of stuff. A SIEMs and a full P-CAP engine and we fix some of that data and we investigate a set of alerts and other various challenges in finding the things that I was talking about along the way. So typical CTF for SANS.

12: What are some of the key tools that you cover in SEC 450?

I've picked out what I believe to be the best of breed of all of the open source SOC tools. And they're actually shockingly good at this point. I remember, five or six years ago, you probably wouldn't have wanted to use the open source solutions for a lot of this stuff that we do in a SOC. But honestly, right now some of the open source that's free is maybe some of the best. And it's incredible where it has come over the years. I picked out some of those tools and put them all together so that people could see the mindset of someone who is maybe using those tools as a senior analyst or whatever.

We have a course lab where we go through and we do a whole analysis of a situation. And I have them read what I would've put down in that given scenario as an alert. And we say like, "Here's something that happened." And I say, "Here is what I'd like to see kind of an alert." I go through and I say, "This is how the delivery method happened. This is the exploited records. The command and control." We work through all the tools and chase it down.

So the tools we use for that. We have a SIEM, which I'm using the Elastic Stack for. We have a threat intel platform, which I'm using MISP. Which is basically a large database you can throw all your malicious indicators whether they're hash values, or IP addresses, or domains or anything. And that's integrated with the Hive, which is the ticketing solution. And so those are the three main things we use and use that as the main set of tools a SOC would have. We have where we're recording our incidents, how we rake out the details, where we're looking at the data in the SIEM and then how is that being supplemented by the stuff we already know is bad. From a thread intel platform and everything that we've collected from vendors and internally throughout time.

There's a bunch of other supplemental stuff that goes with it as well. We use a DNS server. We use a Pi Hole. Which a distribution DNS server that is meant to be run on a Raspberry Pi. But we use it in a [inaudible 00:34:32] [container 00:34:31] and some other stuff. Just so people can see what it's like for a DNS server to be services DNS requests. What kind of logs it can make, things like that. I have people run Apache and see the logs that come out of that as you access that. And show what the views of the logs of those kind of things would look like.

We use an automation platform that looks like a lot of the stuff that's out there right now, called Node-RED from IBM. Where you're dropping boxes and you're connecting them. And making data flow where we say, "This is a thing that kicks off something that happens and then a bunch of stuff falls through. And emails get sent and things get blocked and stuff like that." We use Suricata as an IDS. We run some P-CAPS and other various tools. And Molelock is a full P-CAP engine to look at actual network data as it's been captured over the wire. And pull stuff out of it, try to investigate the situation. Whether it was a data breach and show how the full P-CAP engine can expose that for us very quickly and identify that kind of stuff.

I tried to throw literally one of everything that I could fit into the course. Mail service, use Postfix and in other things to send the spoof email and stuff like I was talking about previously. I tried to pack every single thing in that I could easily use so that everyone has a perspective of, "Oh this is what this tool is. Here's what is sees. Here's the data that it outputs." And that was my goal with that.

13: At the end of the course, what do students come away with?

They're hopefully coming away with a new perspective on how to look at the world as an analyst. A lot of people come in understanding what DNS is and what HTTP is, and maybe a passing familiarity with how it works on the inside. But I want to give them that view of an analyst who has been doing this for years. And say, "Okay this is what I should be looking for in these protocols to say, this is something odd and not normal." You have to know normal to understand what un-normal is, right? So that's one of the things.

I also want to make sure people know how all the data flows. What kind of data is being produced? Where is that data being sourced from? Whether it's from the network being extracted over the wire or whether it's coming from an endpoint. What are the options for that data? What are the considerations for formats? How can we add more stuff to it once we collect it? What do you expect to see in terms of an alert queue? And then, how can we make that better? How can we integrate that well with the SIEM? How should all these tools make your job easier by the interactions that you have with them in terms of making it easy to pivot from one tool to another? How to do false positive reduction? How to write rules? How to do analysis? The whole spectrum of what I would love to see a new employee of the Blue Team to have as a base skill set.

14: Do you think we'll eventually see SEC 450 carry a certification?

I'm very optimistic about that. The authors don't really have any control of that. That's all GIAC sitting the course and deciding whether they think it's a course that can be turned into a certification. And then coming up with all the test questions and everything behind that. It's a little bit hands off for me, but if I were to guess, with the way that this job is and the volume of people involved in it, I would think that it would be something that would be easily turned into a certification. And I believe they are going to be sitting the course either the first or second run. And hopefully we’ll know soon. But my answer would be an optimistic hopefully, yes.

15: How does someone determine whether 401 or 450 is best suited for their needs?

SEC401 is a very broad reaching course, and if you're very new to security as a whole, that might be the thing to do. But if you know you're going into a Security Operations Center (SOC) position, I would say the more directly applicable course would be SEC450. In that class, we're talking about a specific job role, how to do it and what we're going to be using.

Whereas SEC401 is the full spectrum of - here's how Windows works, Linux works, and network stuff, and all the way across the board. General concepts for security, and that's an outstanding class. There’s tons of material there. It goes from 9:00 a.m. to 7:00 p.m. all six days. There's not even a contest on the sixth day. It's a giant wealth of information. People call it a bootcamp for a reason, right? It gets you off to speed very, very quickly. For those who are looking for that broad level view, SEC401 is probably the right match for them.

For those who are jumping into a blue team position, SEC450 offers more of a targeted set of the tools and workflows and data that we interact with and would probably be more applicable in that case.

16: If someone has already completed other 500 level courses, should they still give thought to taking 450?

I would say yes. SEC450, I actually picked that number for a reason, right. I tried to place it in between the 500s and the 401. I was trying to mentally position it there for people. And that being said, SEC503 and SEC504 are major courses for SANS that a lot of people have taken. In some ways they are more advanced, but they're also very different in terms of what they cover.

If you were to take 503 and 504, 503 is tearing very closely into packets and looking at IDS’ and network data. Whereas my course looked at that data as a SOC analyst and how we implement the analysis, the triage and everything else. And all that other part.

If you want to be a packet surgeon, right. 503 an outstanding course for that. But to give it the broader context of a security analyst, I can still see that being a very useful thing to take a SEC450 with.

For those who have taken the courses, lots and lots of 500 level courses, and have been an analyst for a long time, maybe less so. But for those who have maybe taken one or two 500 level courses, I think it still offers a lot of stuff that is not necessarily found anywhere else in the SANS curriculum. I think it would definitely still be of value.

For More Information:

In case you missed part one of this feature, click here.

Visit our course page: sans.org/sec450

Visit John Hubbard’s bio: sans.org/instructors/john-hubbard

Connect with John on Twitter: twitter.com/SecHubb