Subtitles section Play video
Did you know that you can be part of the lucrative cyber security industry?
Even top companies like Google, Microsoft, Amazon, IBM, Facebook, and Dell all hire cyber security professionals.
The cyber security industry has a 0% unemployment rate.
The average salary for an entry level cyber security job is about $100,000 per year in the United States.
Furthermore, you don't need to know coding and learn from your home, and you get a scholarship to kick start your career.
Apply now.
EC Council is pledging a $3.5 million CCT scholarship for cyber security career starters.
Scan the QR code on the screen to apply for the scholarship.
Fill out the form.
Hello everyone, and welcome to today's session, Effective Soft Management and Incident Response.
I'm Shilpa Goswami, and I'll be your host for the day.
Before we get started, we would like to go over a few house rules.
For our attendees, the session will be in listen-only mode and will last for an hour, out of which the last 10 minutes will be dedicated to Q&A.
If you have any questions during the webinar to organizers or our speaker, use the Q&A window.
Also, if you face any audio or video challenges, please check your internet connections or you may log out and log in again.
An important announcement for our audience.
As a commitment to closing the cyber security workforce gap by creating multi-domain cyber technicians, EC Council pledges $3.5 million towards CCT education and certification scholarship to certify approximately 10,000 cyber professionals ready to contribute to the industry.
If you want to know more, kindly visit our website given in the chat section.
Also, we would like to announce to audiences about the special handouts.
Take the screenshot of the running webinar and post in your social media LinkedIn, Twitter tagging, EC Council, and hashtag CyberTalks.
We will share free handouts to first 15 audience.
Our speaker for today's session, Randy Thomas.
He is responsible for the SOC security product development, which includes detection as code,
DIFI, incident command, vulnerability management, threat intelligence, driven security operations, threat hunting, and offensive security at Syntex, a leading managed cloud provider.
He has over 21 years of experience in enterprise cyber security in a wide range of environments, including the US military and intelligence, commercial e-com, detail, and MSSP, MSSSP markets.
He leverages his combined 28 plus years of enterprise IT experience and 18 years of experience in DevOps, DevSecOps, SOC, security engineering, and software development to deliver high quality security products and solutions.
Without any further delay, I will hand over the session to you, Randy.
Thank you, Shilpa.
Good day, everyone.
Thank you for taking this time to join the webinar, either live or later recorded.
Today, we're going to talk about management and leadership in security operations.
As with all things cyber security, it is iterative and you're always learning, regardless of your role and position inside of a SOC.
Overview of what we're going to discuss, we're going to talk about what is a SOC, that varies.
What are the business cases that you're using to defend your organization?
What's the role of a leader?
How do you plan and organize your team?
Give an example and talk through a threat intelligence driven SOC lifecycle, something that can be done regardless of your maturity.
Go into some measures of effectiveness so you can know where you're at and know where you're going.
And give an example of iterative growth of a SOC.
And this is from a personnel progression, personnel growth standpoint.
And then have some further research for you that are interested, either are in a leadership position or interested in it, or just want to know how leaders in operations think.
So I've seen SOCs that have been everything from a SIM tool in an IT shop of one person to actually being responsible for not only the security operations, but the digital forensics, incident response, the threat intelligence work, the hunt work, building cyber threat intelligence products, offensive security, vulnerability management, SIM operation, and maybe engineering.
And likewise for EDR and other platforms.
In my background, I've had to do the extremes there.
So it comes across.
So understanding what your responsibilities are, very important.
So another area that you want to look at as a security operations leader is at some point to create a charter and write down your roles, your responsibilities, and really the limits of what the SOC can do.
And that can cover a lot of things, and you want that to be an iterative and a learning or a living document, and not just let it sit on a shelf.
It should be something you come back and look at, whether it be during exercises or during actual incidents.
And it should be communicated across your organization with IT, with legal, with corporate communications, what have you.
These are important.
They help reduce ambiguity where it exists, because as a security operations professional, you will deal with lots of ambiguity, lots of events that you cannot plan for.
So when you can plan and can organize, do yourself a favor in your team and do that.
And that always is something you iterate on.
It's never stagnant, never stale.
So again, wherever we can, being proactive, being responsive is very important.
Be intentional where you can.
As a leader, it's important when you give directions and intent that you are not changing that constantly.
You have a good path.
You have a good plan.
Obviously, you have to be able to adapt.
We'll talk more about the OODA loop later, you know, observe, orient, decide, and act.
That is a helpful tool in the process.
It's also important to either, one, establish, or two, take what is there and curate it so you look at your responsibilities, your roles.
A RACI matrix is a very good way to do that.
It would go across your organization.
If you're in the MSP, Managed Service Provider, Managed Security Service Provider space, such as
Syntax is, we have to have those with each of our customers.
That way, it's understood.
You also should build workflows that are accurate and reflect not only the RACI, but how that actually works in practice.
It's very important that you take these things in mind and you always have the iterative life cycle development process.
Everything you do affects other aspects of the organization.
You know, think of it as throwing a boulder in a pond and the ripples in the water.
So, you have to be intentional about what you do.
Train how we fight.
Use exercises.
Definitely do tabletop exercises, TTXs.
Also, highly recommend operational exercises in the environment.
Do OPEXs and do them often.
Internal to start with, internal to SOC, you know, expand it to security engineering if there is a security engineering organization.
Expand it from there.
Include aspects of your enterprise IT.
That could be different departments, different divisions, and then look at doing it with customers as well, especially if you have customer environments, particularly in MSSPs, where there is split roles and responsibilities across not only the customer, but inside the SOC as an MSSP as well.
Okay.
A SOC is going to be in an organization that already exists.
The organization does what the organization does.
Perhaps it's an e-commerce company and they sell retail products online.
Perhaps there's a mix with brick and mortar as well.
Perhaps you're a governmental organization, what have you.
That exists.
So, you need to understand things such as what are the business cases for the SOC.
You have to focus in and understand where the SOC fits in the larger organization.
It's also important to build and, again, curate an understanding of crown jewels.
It's often called a crown jewels analysis.
It's exactly what it sounds like.
These are the top 10, the top 100 important things to the organization.
Again, to go back to what's why, this is what the organization is doing.
That typically would include not just technical, but personnel aspects as well.
If you've been in the industry for long, most breaches tend to occur via email, business email compromise, or BEC, huge, huge vector.
What are some of the aspects of that?
Not only do you get the supply chain side attacks that are becoming more common, you also have the old but good attacks on invoice and wire fraud.
So, your finance department could be a CFO.
So, all of these people, your C-suite, your board, you have your HR department.
We're out of, in the U.S., income tax season.
That's also an issue as well with W-2 fraud, for instance, things like that.
You want to identify those, not just the identity and access management IAM pieces, which, of course, you want to include, you know, endpoint, detect and respond, EDR, things such as that.
Boundary protection is fine.
That's not a panacea, of course.
Hence, other technologies such as zero trust, network access, CTNA coming about.
So, you leverage this work you do as a leader putting this together to prioritize what you work on, whether it's adding new capabilities to the SOC, such as detection engineering, or how you respond.
And this deserves mentioning because, unfortunately, I've been in environments that have done this.
You can only actually have one number one priority.
You cannot have A through Z.
You cannot have 26 number one priorities.
You need to make choices.
The resources are always limited.
Doesn't matter if you have a budget of $20,000 U.S. or $20 million.
You have severe limitations on what is achievable.
Also, some aspects to consider in a more holistic manner are words have meanings.
So, anything the SOC gets in from systems that are instrumenting, such as a SEM or other tools, is an event.
The event came in potentially based upon an alert or as an informational feed.
So, the SOC has to determine whether it's manual or with automation, hopefully the latter.
That's a growth area, right?
You have to build contextual reference and relevance to the event.
What does that mean?
If you're in the retail space, for instance, or hospitality, your enemy number one is threat actors such as FinCET.
This is how they act.
This is their tools, techniques, procedures, their TTPs.
So, you look for things like that.
So, once something comes in as an event, the SOC, whether manually or automatically, either clears the event, the alert, or it's elevated to be a probable incident.
So thus, thus comes into play your incident handling process, which is a process if you don't have, definitely should make.
There's plenty of references.
I have some at the end we can go over.
And one other point of note, particularly in more mature organizations, they will have an information technology information library, ITIL, based IT service management process.
Those define incidents at the ITSM level.
That is not necessarily a security incident that comes in as an event and or an alert to the SOC.
In the SOC, we then, therefore, have to process that.
Okay, being a SOC leader, we can manage our processes, manage our metrics, we can manage our timesheets and expense reports.
When you're managing people, in my view, you've got some challenges to work through.
So, leadership is important.
Again, as I mentioned earlier, from a resource standpoint, it's always limited.
You must be pragmatic.
You cannot, nor should you really want to solve 100% of anything because when you start that process and when you finish it, it takes some period of time.
There's periodicity in there.
And the threat landscape typically evolves.
So, whether it's cyber hygiene or full coverage, that can always be a challenge.
Now, obviously, full coverage of something like EDR, of other advanced authentication mechanisms such as MFA or other tools such as CyberArk, most certainly, those should be employed.
But you want close to 100% coverage.
That's not the, of course, the intent of the discussion point there.
But understand that it's always evolving.
We always have to iterate.
So, as a leader in SOC, when everything else is on fire and there's chaos abounds because that's what a SOC has to deal with, right?
We deal with challenges from our customers, whether they're internal or external or both.
So, be calm, be consistent, do your best, learn, you know, have the sixth step in your six phases of incident response is your lessons learned, your after-action report, as many of us like to call it.
So, get better afterwards.
And again, everything we do has consequences, ripples in the pond, as I said.
As a leader, it's particularly important for you to either learn or continue to hone soft skills.
So, interpersonal communication is huge.
Body language is a huge part of that, even in video.
You know, you need to have empathy for what the affected victim or victims are having to deal with and what the ramifications they will have to deal with with countermeasures.
You know, if you have an environment with 80,000 associates and there's no MFA, you can't just turn MFA on instantly because that goes back to crown jewels.
If they're an e-com environment and nobody can get in to do the work, you can't sell anything.
So, it takes balance.
Crucial conversations happen.
Those are difficult conversations.
There is a course on that, which I took years ago.
It's very good.
And human psychology.
It's a great hobby to have, not just for self-growth, but in general, and particularly as a leader in cybersecurity.
So, even as a director or as a C-suite, if you are responsible for operations and or engineering in the space, it is very important that you maintain some technical acumen.
So, have a lab.
Spin up VMs in AWS, Azure, DigitalOcean, what have you.
You know, and I like the example of can you do packet analysis?
I can.
You know, it's something that is good to have as a basic fundamental skill, and doing protocol analyzer work, too, with Wireshark is also good.
Lastly, on this point, one of the important things we need to know is how we learn as an individual.
Only we can do that for ourselves.
You know, as an instructor for university courses, I can't force you to learn anything.
You have to go, and you have to have enough drive to be able to figure it out.
So that's important, because you go on vacation, you're behind.
The point is not to feel like you have to catch up, because you can never catch up.
That's, again, going back to being pragmatic.
Understand the environment of what you need to focus on.
And that skill takes time, and it's a constant skill to work on.
Okay, some basics on organization.
So I'm a strong believer in honing individual strengths of your members.
Obviously, you have diversity of background and thought in the team.
That is very important.
As a team grows, it's good to have people that have a non-cyber IT background.
They have a different perspective, somebody with a finance background.
I've worked with those.
They've worked on my team.
It's great.
You get different perspectives.
And you mitigate weaknesses as best you can.
Going back to part one, what is your SOC?
If you don't have that answered, it's really hard to organize your team.
And how do you organize your team?
Into sub-teams.
Do you do squads if you're an MSSP?
Do you separate out and have a six-person cell for 15 customers, and you just multiply that out?
Or do you break it up into current operations and future operations?
Current operations is what's happening right now and in the next two weeks.
Future operations is things that are further out and take more resources, such as detection engineering, detection as code, things like that.
Or do you just have a big pool of personnel, and you just look at the queue?
There's reasons to do all of those, and they don't have to be a static point or place in time.
And again, going back to crown jewels, that should be your priorities.
That should go into how you divide your team up, how you handle on-call, how you handle nights and weekends.
Do you have follow the sun?
Do you have a Panama-type schedule?
Or do you have something else?
Or are you eight to five?
So do you have an incident response plan for the organization?
Do you have an incident commander?
And it really doesn't matter the size.
It's not an excuse.
It can be a one-pager if you're a five-person company.
It should be more than that if you're 500,000.
And as I tell my mentees and students, the R in incident response is not react.
We have to do enough of that.
So plan and develop accordingly.
And always remember, we are attacked at machine speed.
It's not just a guy sitting in his basement like I am at the unofficial Rocky Mountain
Syntax Cyber Operations Command Bunker doing things.
So pivot your team and grow at a more machine-responsive rate.
Okay.
This is an eye chart, and it's best to talk through it.
So this isn't a course on OODA loops, but the idea is you quickly iterate, you look, you figure out where you are contextually, you make choices, and you act.
It should not be 42 steps that take three days.
It should be, again, minutes, hours, because we are under attack at machine speed.
So and in a more mature organization, not saying a larger organization, again, this could just be a few people, you need to start incorporating threat intelligence to focus the limited resources that we have on the largest threat profiles.
And you can put this together using open source intelligence work, OSINT.
So you have some process in place, and there is incident handling that escalates, and you now have an incident to respond to.
So as we mentioned earlier, it didn't clear out, so it got considered a potential incident.
Okay.
Well, what work have you done to contextualize this with threat data against the organization's threat profile?
Build a threat profile.
Start out with what market verticals you're in.
Go through your board of directors, your C-suite, your other important parts of the organization, and critical infrastructure.
It could be your credit card data environment.
If you have to do PCI DSS type of work with credit card information that's not encrypted or hashed, and it could be anything else along those lines.
So you should have a process of doing threat hunting against that threat intelligence data to better understand and build a threat product so you know what your environment is and or your customers.
So you can, again, rapidly focus in on what are the latest indicators of compromise, IOCs, the latest known campaigns, and the previous campaigns.
Just because it's an old campaign doesn't mean it's not a good campaign and won't get used again or reused by other actors.
Call them copycats.
That's also common.
Do some pen testing, whether it's third party or internal red teaming or purple teaming.
Use real threat-based work that's been observed or researched.
And the idea is you already have some detections in place.
And if not, this is a process where you identify those.
You do threat analysis work based on that to help understand how to process that information and have the analysts work it.
And then you follow that up by doing detection engineering to create a new detection or you tune existing detections based upon changes in the threat landscape as it does change.
And for this example, for each of those phases, you need to rapidly go through effectively the OODA loop process.
One caveat that a lot of people fall into, it's a trap, is they'll go straight from observe to act.
Spend a few minutes, a few hours, orienting and deciding.
Again, everything has impacts to the target organization for any kind of countermeasures or detections.
So all part of being organized and responsive and not reactive.
So if you do not measure it, you cannot manage it, do not know who wrote that, it was not
Peter Drucker, although he gets attributed with it often.
So what are some things as a leader you can do?
At the highest level, I would call them OKRs, your objectives and key results.
I like to have them as quarterly goals, generally speaking.
We're going to work on initial detection as code, pipeline deployment using SGMA rules in a quarter.
And it may be nascent, it may be a 0.5 version of it, that's okay.
What's the next quarter going to do to that, right?
Have these as goals.
If you work in a large environment that is doing Agile safe, scaled Agile framework, that can very easily feed into your program increment, your PI planning as well.
Have the process work for you as much as possible, as challenging as that can be at times.
So service level agreements, SLAs, that term gets abused.
So SLAs are high level, relatively speaking, objectives that we agree to meet whether internally or in the case of an MSP, MSSP environment, it's going to be tied to contract documents or it should be anyway.
An easy example building off that is after the SOC identifies an incident from the EDR within five minutes of that escalation, an alert goes out to the customer or to the SOC to work it depending on what the construct is of the SOC and the contractual requirements.
But it's not, this is not atomic level indicators.
That would be a bad place to put them, having done many, many contracts.
So next level you take internally, it wouldn't go in the contract normally, would be service level objectives, SLOs.
Okay.
So the SOC has to meet a five-minute SLA.
How do we do that?
Well, we want to get a two-minute alert process to make it an incident in two minutes based upon those atomic indicators.
What are and where do atomic indicators live?
They should live at the SLI, the service level indicators level.
That would be things you cannot break down anymore.
That could be something such as an IOC, hashes, domain names, IP addresses.
The point is to contextualize event data and to feed that back up through the process.
So these are things we can do irrespective of all the chaos that can and will often come with security operations.
So this picture I pulled from Twitter from hacking articles, I like it as a baseline.
I would say tweak it for your organization.
But, you know, here's an idea for what we call job qualification requirements, JQRs, for a SOC analyst one.
You should be able to do these types of things, understand what the diamond model of intrusion analysis is, and be able to give descriptive analysis work.
And as a leader, one of the things you want to do with areas such as this is you want to establish a baseline, whether it's style guides or something along those lines.
You want it to be consistent and repeatable.
You don't want to have everything to be special, you know, special snowflake, as we like to say.
You should understand the basics of threat modeling.
Depending on your organization, you should understand the basics of the frameworks, PCI-DSS,
NIST, HIPAA, sometimes all of those, and their importance.
With frameworks, regardless of what the framework is, you should also recognize that they're not straitjackets, they should be adapted to the organization.
That is an entirely different talk.
So you should understand the fundamentals of vuln management.
The difference between vuln management and enterprise patch management, to me, is you have threat overlay for that.
Just because you're patching the top vulnerabilities does not mean you're doing vuln management.
Because as you get more into threat-related work and you dig into it, you'll realize that the bad guys, the more sophisticated bad guys, tend to use a lower level of vulnerabilities.
They tend to string them together and do their compromises, drop their mal-doc, do the business email compromise, take your session cookie for your ZTNA access, et cetera.
It sells well to talk about zero days, but the reality is typically not that.
We have to deal with the more mundane.
We'll talk about that on the next slide a bit.
So understand the differences between risk and threat and vulnerability.
Again, packet analysis.
Understand the basics of the SIEM that you should be using.
And understand how you're supposed to respond.
And understand as a Tier 1 how you are to support incident handling.
As a Tier 1, at least from my perspective, it's unfair and unreasonable to have a Tier 1 analyst be conducting, leading the IR process.
Supporting it?
Absolutely.
Doing aspects of it.
But understand where you fit in the picture.
Understand events.
Understand incidents.
And the breach word, the B word, is not a SOC term.
It is a legal term.
Just for the U.S. at below federal levels of state, territories, and districts, there are at least 54 laws on the books at that level that define what a breach is.
That's not water cooler talk anymore.
So when your legal department says it's a breach or your customers, then you call it a breach.
And again, soft skills are important for everyone.
We deal with customers.
And it's important to hone those skills.
All right.
So as all things are with cyber, it depends on your personal drive and ambition.
So here are some areas, some breadcrumbs, if you will, to go after.
Or to, as me and others often do, we knock the dust off of these.
So if you've ever searched for how to stop ransomware on Google, I'm sorry.
Because most of it is regurgitated information, and it's not useful.
So what actually causes it are what would be characterized in the CIS top six.
What are your physical virtual assets, your hosts?
What applications do you have?
What level of access?
How do you control it?
Do you have your active directory?
Do you have your file share internet exposed either directly or indirectly?
That's how those things happen.
Do you have it really easy for your admins to get to the domain controllers or other domain attached servers?
Or do you have a process, you know, be it a bastion host type of setup or something along those lines?
Again, defense in depth.
So that affects your business email compromise as well.
And by the way, your wire and invoice fraud.
So there's no magic in it.
There's just work.
So a recent book is the new version of building a world-class cybersecurity operations center for MITRE.
It's fantastic.
I know Carson personally, he's one of the authors of this one.
He authored the first book solo about nine years ago.
Fantastic reference, highly recommend it.
If you're not using for incident response, characterization, contextualization, and sharing
Veris, go learn about Veris.
You should understand diamond model of intrusion analysis as well and how the cyber kill chain framework works in there.
And last but not least, even though it gets mentioned first a lot, how do you employ the
MITRE ATT&CK framework?
My favorite way to start that is at the enterprise level.
What are they after?
Are they after data or are they trying to burn it down, your environment down?
Or both?
Or can they potentially do both?
And then you work from there.
You take the information from doing your intelligence profile, that dossier, and then you go work
MITRE ATT&CK framework to see what they're doing.
Again, no magic, it's just work.
And with that being said, Shilpa, back over to you.
Thank you so much, Andy.
Thank you very much for an informative session and our attendees share the same sentiments.
Before we begin with the Q&A part, I would like to inform all the attendees that this session is in sync with EC council certification, CSA, maps to the SOC analyst role, and even with the CSA certification is eligible for $13,000 plus job with an average salary of $85,000.
If you're interested to learn more about our programs, do let us know in the poll that's going to be conducted now.
Let us know your preferred mode of training and we will reach out to you soon.
So Randy, shall we start with the Q&A?
Absolutely.
Okay.
Our first question is, what is the RACI matrix by Shivaraman?
So the RACI or the RACI, it's a matrix of who's responsible, who is accountable, who is consulted and who is informed.
And you basically break down processes that you have to work.
Something as basic as incident response, who is responsible for that?
The SOC is.
Who is accountable for that?
The SOC is.
Who is consulted?
Other groups could be IT, could be legal, et cetera.
And informed could be the CTO as an example.
There's lots of examples online for that to give you some ideas, but it's important to have that.
If anything taught us that it was the conviction of the former Uber CISO last summer.
Thank you, Randy, for answering that question.
Next question is, when we say five-minute SLI, is it at first level incident responder or like Tire 1 by Gullen?
Well, that was an example.
It can be anything.
Your SLA could be, for the same thing, it could be 15 minutes or an hour.
There tend to be various types of SLAs and that really gets into contract discussions and that varies from, or potentially contract discussions, and it varies from customer to customer.
But the idea is either if it's internal at the organizational level across departments, directorates, and the C-suite, there's an understanding of how we respond and that's communicated or it's with customers and that's communicated as well.
Thank you, Randy.
Our next question is, would love to have some guidance on open source SIEM, EDR, XDR, NDR tools, as well as some affordable options by Gerhard.
Product discussions.
I'm not going to have a great answer for that because I get to focus on operations for the first time ever here at Syntax and not engineering.
I have a fantastic engineering counterpart director and I am not completely up to date on giving that.
There are a few options.
You just got to dig into the, and see where the, some of those have gotchas as far as how potential licensing goes.
But if it's on GitHub, chances are, yeah, it takes some research, but you will come away after probably several hours with the basic answers.
You'll have it narrowed down to a few options for EDR or for SIEM, because there are not a lot of options.
Thank you, Randy, for answering that question.
Our next question is, what is your suggestion on creating an incident ticket in ITSM for every alert triggering in SIEM?
Do you think it's the right approach or do we have to log on, log an incident ticket only for those alerts which are investigation worthy?
Secondly, what metrics do you suggest we prepare to showcase SOC performance to CISO?
Okay, so, and I've dealt with and encountered extremes.
So sending any alerts as an ITSM incident from SOC is not really beneficial.
So that's, and that's why I was specific in saying the SOC escalates anything that comes in, whether it's from ITSM or from the instrumented enterprise environment.
The SOC must characterize it, whether manually or automatically or some combination thereof, as a security incident.
That should most certainly be an ITSM incident, preferably automated.
So that, because what you end up with is you end up with alert fatigue rapidly, particularly from security devices.
If anything, security devices tend to be, shall we say, chatty.
We don't want to send 100,000 events per day to ITSM as alerts, for instance.
That's very easy to do even in fairly small environments.
So you want to process it.
So one of the things you have to consider during the lifecycle maturity of your SOC and looking at the SLAs, whether contractually or internal agreements, they need to be reasonable.
Five minutes may be completely unreasonable if you have a SOC of three people working eight to five.
Maybe it's six hours, maybe it's 12 hours, probably not five minutes.
So there has to be a process in there.
And again, it's not fair to a tier one analyst to say this is an incident versus it is a probable incident and then escalated internally to a tier two SOC, for instance.
So that comes with maturity.
That's a nightmare, sending all of your alerts as tickets.
And the second part, totally lost my train of thought.
What was the second part?
Thank you, Randy, for answering the question.
Our next question is, could you please tell us some SIEM tools and techniques used at industry level so that as SOC L1 must be learned before entering into the industry by Pradeep?
Okay, I will tell you like I tell my students when I teach different courses.
Learn one of the following in any order.
Learn Azure Sentinel, learn Splunk, learn Elastic.
Learn one of them well enough to do queries, to build a dashboard, do enough qualitative analysis to build a representative dashboard.
Perfect example I also give is build a dashboard and, you know, it's for your customer, this fictitious customer, and have a VM fire off something that is or looks like PSExec.
That one always makes the hair on the back of my neck stand up, regardless if it's legitimate or not.
So that is a tool that is either actually PSExec, which is basically a remote administration Windows tool, or it is something masquerading as that.
That is a common TTP that is used by bad guys.
So that's an easy thing to dig into, and you'll learn a bit about a SIEM.
You'll learn a bit about doing queries, such as, you know, SPL and Splunk, build a basic dashboard, and contextualize so you understand.
So as a hiring manager, it's important to me to understand that you know why you did something, and the so what of what was done.
You can talk through that, not just make a pretty dashboard.
So great question.
Thank you, Randy, for answering that question.
Our next question is, what is your opinion on having an incident severity calculator?
What would be the right criteria to be considered for developing this calculator by Amir?
Well, that is going to be something that needs tuning continually, just because, again, such as PSExec FireResolve doesn't mean it's actually an incident.
It could just be an alert.
So you have to dig into things such as detection engineering.
Are they obfuscating the fact, are they just saying, oh, it's this process, but it's running from your Chrome browser?
That's not PSExec.
That's malware, fileless malware.
So something as simple as that.
And again, this goes back to doing a basic OSINT, open-source intelligence-based investigation.
And it could just be on yourself, your own organization, to say, I'm in these market verticals.
These are my NAICS codes.
I'm in manufacturing, and I'm in healthcare.
Okay, well, these are the actors that tend to operate in there.
So I want to prioritize alerting and eventing and potential incident processing on these lower-level CVEs.
Maybe you have Qualys or Rapid7 or any other vulnerability scanner.
You enrich that event processing with more contextualized data to say, oh, well, this CVE is lower-level.
It's a low, but it's higher for us because, contextually, this is how things tend to look based upon actor campaigns.
So you don't have to have an Intel team to do this.
As a leader, spend a weekend, do some research, and come up with a basic set.
You don't have to try and solve all your problems and go for 80% Pareto principle at play always.
Great question.
Thank you, Randy.
Our next question is, what is the best recommendation MSSSP SOC can give to client for brute-force attack on accounts even having MFA applied?
Bye, Valit.
Well, that landscape constantly changes.
You have a lot of different vectors.
Let's say you're using Azure Active Directory.
There are controls you can put in place, and some of those vary depending on the level of service.
Is it a P1, is it a P2, et cetera, to help with that?
You know, the unrealistic travel is useful.
Geoblocking, in general, is not very useful.
There are these things called VPNs and zombies and the Tor network.
So that has limited runway, if you will.
Other things that you can do and should look at are advertisement networks, ad networks.
They're also called malvertisement networks for a good reason.
There is not really much vetting on the provenance and pedigree of the code that is uploaded there.
So it is a common transport for malware.
Has been for years.
That has not changed.
So how do you handle that?
Something as simple as blocking ad networks as well.
So there's quite a lot, and you always have to look at different ways to do it.
But depending on your environment, there are definitely ways to do it.
You know, obviously, you have to look at your supply chain.
I mean, I showed you the Okta breach from last summer, the LastPass breach.
The list goes on and on.
It's not a question of if but when for compromises and breaches.
Again, pragmatic, how do you do the best you can?
So great question.
Thank you.
Thank you, Randy.
Next question is, would you say that diamond model of intrusion analysis may probably be suitable in the establishment of SOC?
At least in a basic form, you don't have to devote a whole lot of time to it.
It helps you characterize what's going on at the initial stages.
Before you dive into something such as the kill chain and or going directly into MITRE ATT&CK.
There's reasons to do any of those, but from an organization standpoint and building processes on how you do things, yeah.
Just do the basics and just characterize those few key points as best you can.
Thank you, Randy.
We'll take last two questions for the day.
Our next question is, any best open source threat intelligence for SOC?
Yeah, I'm trying to remember any of them off the top of my head.
As far as threat feeds go, data feeds, they exist.
I know Alienware got bought out.
That's the only one I can think of, not Alienware, but AlienVault, I think it is.
They got bought out, I think, by Dell, but that's an available source.
The important thing about threat intelligence is it's not information, it's data.
The SOC is responsible for building threat products, just as it's responsible for building any other security operations-related products.
We have to process it.
We have to contextualize it, and frankly, we have to filter it because we get a lot of not necessarily useful information.
I wouldn't say it's bad information, but contextually irrelevant.
That happens more often than not.
So sifting through that is something that you have to do on an iterative basis.
Everything I've talked about today, I didn't use the A word, agile.
This is all DevSecOps.
That's what all of this conversation has been today, so good question.
Thank you, Randy, so much for answering that question.
We'll take the last question for the day.
Can you explain more on SOC playbook and SOC runbook?
Can I see a sample SOC playbook and a sample of SOC runbook?
I unfortunately do not have the time to show examples.
So the basic difference between a play and a runbook and how you would want to construct them is the playbook you want to build out as the overarching response to how you handle, let's say, just a campaign.
You know, this APT group is doing this particular campaign.
We're bucketizing all of the intelligence and detections and automations in this, and the associated runbooks are go pull this information in, enrich from this source.
It's the discrete tasks that you want to go do.
Go shell into this console and scrape this information back and bring it in.
Pull this data feed, that kind of thing.
That way, the idea is you have consistency in your runbooks, and as you build out the playbooks, you can pick and choose.
You know, I'm going to the automation and organization store.
I'm going to put these things in my playbook, you know, basket, and I'm going to build this product.
That way, you can scale.
Everything we do has to have an idea and thought to scaling, whether it's scaling up or scaling down.
Typically, it's not down, so it lets us be more agile and try to be more proactive in defending at machine speed.
But hopefully, that gives you at least a basic breakdown of how to go and approach that.
Thank you so much, Randy.
Thank you again to our wonderful speaker for answering those questions and for the great presentation and knowledge shared with our global audiences.
It was a pleasure to have you with us, and we are looking for more and more sessions with you.
Before we conclude the webinar, would you like to give a small message to our audiences?
Yes, and thank you, Shilpa.
I've enjoyed it.
So, again, it's important to be pragmatic, plan where you can, understand you have to react often, and from vectors that we often don't know, sometimes we do.
So, and as a leader, it's very important that we work with our team, we regulate, and don't, as far as not burning our folks out, you know, we're trying to solve problems, and it's very important as a leader to work with your team and really set them up for success, empower them, and part of that comes from defining what they do and what they don't do.
Thank you so much, Randy, for the message to our audiences.
Before we end the session, I would like to announce our next CyberTalk session, Incident Response Planning, Preparing for Network Security Bridges, which is scheduled for July 5, 2023.
This session is an expert presentation by Mez D. Guzman, cybersecurity leader.
To register for the session, please do go visit our website, www.eccu.edu, CyberTalks.
The link is given in the chat section.
Hope to see you all on July 5th.
With this, we end the session.
You may now disconnect your lines.
Thank you.
Thank you so much, Randy.
Thank you.
Pleasure having you.
Thank you.