Anatomy of a Cyberattack, from Gradient Cyber

So welcome to an amazing Atlas program today.

We are so grateful to have our friends from Gradient Cyber to help us out

today. We've got Neal, and he's going to be talking to us about a very important

topic, the anatomy of a school cyber attack.

So we're very grateful for this. I think you guys are going to gain a lot of good

information that's going to help us all feel more prepared and up to date.

So Neal, thank you so much for being here with us today.

We're so grateful to have you.

Thank you, Ashley. It's a pleasure. Appreciate it. And thanks to Atlas as well.

Can I jump in?

Go for it.

Okay, great.

Absolutely.

Well, thank you guys again for being here. I know you're all busy.

Want to make this an informative and educational share for you.

As Ashley mentioned, the topic is an anatomy of a school cyber attack, and I've got

a set of situation reports, and I'll describe what those are, that we've seen in K

through 12 organizations like yours.

We'll use those to kind of put together an attack chain that shows you what

attackers do,

what you can do at each stage of that process to defend yourselves, and we'll end

by telling you a little bit about us.

But the goal mostly is just to be educational about the topic.

Just a quick hit about me. I've been in cyber for about 20

years. About 20 years before that, I spent in networking and data communications

and high-speed networks. So I always describe myself as having spent

20 years trying to make packets move faster and faster, and then spending 20 years

trying to stop bad packets from moving at all. That pretty much sums my career.

So I am the CMO of Gradient Cyber. We are an MXDR company, which stands for Managed

Extended Detection Response. Some people in the industry call it MDR.

It's kind of a shorthand.

We just serve mid-market US customers.

K through 12 is actually a very important sector for us.

So we're happy to have a chance to speak with you today.

All right.

So here's what this presentation is about.

Let me just move the video controls out of the way so I can see.

I'm going to show you, in kill chain terms, what an attack sequence looks like.

You'll see the kinds of telemetry that gets surfaced across identity, endpoint,

network, applications, and cloud properties.

I'll give you some insight into the signals that matter and the signals that don't.

As you might imagine, there's a ton of telemetry that comes into any organization

on a

moment-by-moment, hourly, daily basis.

It's always a challenge to find a needle in a haystack, but we'll show you how to

do some of that. And in the end, how do you piece all this together and convert

that into a story that makes sense for people who don't travel in the technology of

cyber attacks on a regular basis? You may have school professionals, school

administrators who need to know, but they don't need to know all the technical

detail. You have to have a narrative for them. This is not a product pitch.

It's just an information share that I think will be useful, and certainly hope will

be useful for all of you.

Let's see here, controls.

Oops, skipped ahead. Excuse me. So just starting with a very quick poll, and I

think you may be able to-- I don't know if there's a poll that pops up or if you

just want to answer in the chat, that's fine. But there it is. Great.

Ashley took care of us here. Thank you.

So the question is, how many people on your IT team are responsible for security?

As you see, there's four simple options, and you can click this.

I'll just give a few seconds here for folks to fill it out.

Looks like they're coming in pretty quickly.

And just based on the histogram, it's pretty close to what we see with across our K

through 12 customer base. Often, it's a single person, usually two to three folks

in IT, and somebody might have a CISSP and be fairly cyber knowledgeable.

Sometimes not. But we almost always see the case that folks don't have enough

bandwidth to cover what's required here 24/7. So thanks for answering the poll.

It's always instructive to know something about the audience, and that's very

helpful to me. So thank you.

Ashley, I don't know if you want to end the poll. I'll let it run. If not...

Okay.

So let's talk a little bit about a profile of a school, who gets targeted, and why.

So there's a left side and a right side of this slide.

The left side is what you know about yourselves, and typically, an independent

school is going to have somewhere between maybe a few hundred to possibly a few

thousand students. They're often equipped with school-issued devices like laptops

or iPads.

As we just discovered, the IT team can range, but one to three is not a bad number.

It's a little uncommon to find that someone has a security title.

Usually, there are many, many other jobs that the IT team has to take care of.

So there may be security expertise, but not necessarily someone who is a devoted

cyber analyst per se. In the IT stack, and the stack that's very important for us

to see, often K through 12 is going to be running Microsoft 365, maybe Google

Workspace.

We commonly see some form of endpoint detection response deployed within the

school, usually only across staff and teaching staff,

administrators, administrative staff, sometimes across devices.

A little more expensive to do that for the students.

But the ERs will typically be anything from CrowdStrike, SentinelOne, Microsoft

Defender.

There's a host of them that are out there, and we interface with all of them.

You probably have edge firewalls at different points in your network.

You may have a cloud application or workload running at AWS or Azure.

The offices will include business functions, student advancement, admissions

requirements, residential life, different kinds of offices.

And there is a calendar that's publicly available somewhere on a website that shows

what your school looks like, your school year from a we're in school these days,

we're not in school those days. So that's how you look from a school point of view.

The right side is what an attacker sees.

He or she sees, hey, this is an organization that has money and movement, whether

it's tuition or gifts or invoices.

Happens all the time, every day of every week.

They know that there's valuable information to be had, whether it's financial aid

information with critical family privacy data or HR records.

They also know you don't have a gigantic security staff, and you probably are not

able to watch your environment from an IT point of view 24/7.

And they know a lot about when your working hours are and when your school

operating hours are, and when they're not.

So that's how they view the K through 12 organization.

A few numbers. It's pretty common to see ransomware and

business email compromise attacks in school systems of any size or caliber.

I'm sure that's not a surprise to any of you.

A couple of stats here from our dear friends over at Sophos.

22% of K through 12 ransomware attacks start net phishing.

That's probably not a surprise. The other vectors that I'm sure show up in the

survey, different forms of phishing. So we have vishing through voice.

We have smishing through SMS. Of course, we can have many attacks that come in

through non-personal touch. They may be open vulnerabilities that haven't been

patched. There's lots of doorways for ransomware to start, but phishing is a

principal one still here in 2026. If you get hit with a ransom situation,

the cleanup and recovery can run several million dollars pretty quickly, pretty

easily. And then business email compromise, I don't have K through 12 specific

numbers, but that is a thriving

space and opportunity and revenue generator for anybody from script kiddies to

organized attack crimes. So these are both important to delve into a little

bit. But the myth, and I'm sure you all appreciate this, is, "Hey, we're a school

system. We're broke. No one cares about us." The data suggests otherwise.

It's a very interesting and lucrative target, so we have to be just as

vigilant and concerned at the

K through 12 education level as we would be with any other vertical within the

country.

Now let's look at an incident, since we know something about the attack surface in

the school. I'm going to show you a seven-stage kill chain.

It's a little bit modified. And I'm going to give you real examples from SITREPs

that we wrote, situation reports.

Those of you who may have a military background will recognize that term.

It's often used in the cyber world.

I'm going to show you examples from school situations that we wrote against in

2025. And what you're going to see is not a continuous

stream of SITREPs for a single school.

This is a composite that I've pieced together from a number of different schools

just to give you a sense of what we see, but it will still paint a story around a

kill chain. So let's look at that.

Every slide that I show you, and there'll be about seven of these, will follow this

same format, so hopefully it becomes easier to digest.

But just to acclimate you, across the top is what we call the kill chain.

This is not the long-standing Lockheed Martin kill chain, nor is it the MITRE

ATT&CK kill chain. Those are the best references.

It's slightly modified on the back end just for simplicity.

But there's always a reconnaissance stage. There is an access stage.

There is a land and expand, where the attacker's trying to become more persistent

so that they don't have a single point of presence where they can be snuffed out.

Then they move to discovering everything about your environment, every asset you

have. They're looking for the gold. Where's the money?

Where are the school records? Where's the intellectual property?

And then they move into their activity where they're trying to grab that

information, whatever it may be, seal it up, exfil it, cover their tracks,

and if it's a really nasty situation, you get everything locked up from an

encryption point of view, and then someone has a bad day with a phone call or an

email message being a ransomware note.

So in this first recon stage, what we saw at this particular school was a domain

that looked similar to the school's domain popped up in the wild.

It wasn't an exact domain name, and you'll be familiar with that, but it was close

enough to be picked up by things like VirusTotal and other tools that our analysts

use. Turns out it was registered a couple of weeks ahead of

being seen. The owner was not revealed, and it wasn't caught by all the engines.

It was caught by one. So that's, for us, a flag. It's not a serious flag.

It's something we watch. When you see this from several points, you can be sure

that it has more activity and probably more life.

So we don't have any phishing going on yet.

This is just what setup happens from an attack point of view, and it often happens

in the early stages along with reconnaissance.

In the old days, reconnaissance was let me scan your network from afar and see how

much I can discover over the internet.

Modern reconnaissance now involves looking at social media, looking at local school

newspaper articles, anything they can find to build a perp board around your

school, the people who live in your school, the people who work for the school, the

students at the school, anything that will give them intel on what this

environment, this attack surface looks like.

Now, at this stage, if you can detect that there is

a close domain, the first thing to do is to confirm, does the school actually own

this or not? If not, then go ahead and put block notifications in place at both the

email and the domain name system level.

And go ahead and tell your business office, your advancement staff, and anybody

else who might need to know, "Hey, beware, there could be lookalike

messages coming from this domain." So it's a good alert mechanism to already do.

Okay.

Next up, access. Here's one where we saw an independent school.

This was October about a year ago now.

Two IP addresses are just going after staff sign-ins, so a

very high count of failed logins. Not uncommon. See it all the time.

I'm sure you do, too. But two of them were successful.

They both came from the same IP address, and immediately the attacker opened

several mailbox items. Now we know this is no longer a test.

This is not

trying to get in. Someone is in.

If you can pick this off, the first thing you should obviously do is reset the

password and revoke all active sessions for those accounts.

That revocation is really important.

As we know in the modern world, OAuth certificates are flying around the moment

you've logged into your school environment and you've accessed a number of

applications and you've traveled through different network locations.

So you really want to make sure you kill the entire active session because those

OAuth certificates can have life beyond just a password revocation and the attacker

still has a way in. Clearly, you want to put MFA, multi-factor authentication, on

the account. You want to start checking the inbox for any new rules or forwarding

capabilities that have been built in by the attacker.

And you want to look for any other accounts that might've been touched by that IP

address. These are the kinds of defensive mechanisms that you can do and should do

if you detect this.

Step three, persistence. In this case, we already saw the attacker going after

payroll. So there was a phishing email.

It did get into several staff inboxes.

It was over the course of, I believe in this case, six, maybe seven days.

And there was an inbox rule that was dropped into a couple of them.

Just

the name of the rule was a dot, which is suspicious in and of itself.

Now, anybody who has inbox, if you're a relatively sophisticated email user, you

set up rules. Teachers do this. Administrators do this.

Hey, here are educational things. Let me put this into this folder.

Here are financial things, that folder, student things, this folder.

So we all have some set of rules.

It is not always the case that we're aware of all the rules that might be running

in our particular mailbox. In this case, one of our analysts picked off that that

dot rule

was shown in a couple of email boxes.

And so one of them was saying, "Hey, any email that comes in that's associated with

direct deposit, go ahead and shunt it to a place where people will not look."

So that's a pretty big tell, but easy to miss.

So in this case, at the identity level, we had a successful phish, sign-in from a

blocklisted IP, suspicious password change, and a rule that was created in

inbox from a commercial VPN that is known to be malicious.

Those are pretty big tells, especially when you can see them all and piece them

together.

From a defense point of view, you need to kill these sessions, obviously take out

those rules,

notify anybody associated with payroll to freeze anything that might be associated

with direct deposit, and start searching mailboxes for similar rules that may have

the same name.

Just to delve into that a little bit deeper, here's an example, and this is what we

saw in this particular user's mailbox.

A rule had been set up. The gray ones were legit, not set up by us, but by the

person within the school. Move all messages from Apex Learning Support to Apex.

Standard folder move. Move all messages from this person to Letters.

Move all messages from Discovery Education to Deleted, and so forth.

The two that are in red are the ones that pop out, which are not good and were

dropped in by the attacker. In this particular case, we saw over 100 inbox

rules, SITREPs, just for this one district last year. That's a fairly large number.

Only two of them were attacker based, so you can kind of see the needle in the

haystack problem. At a grander level, I mentioned that K through 12 is an important

sector for us. At Gradient Cyber, we run MXDR for companies

and organizations in about 35 different verticals.

There's a little bit of a concentration in K through 12.

Part of that's because we're Texas-based and we're close to several of the ISDs

here in our state. But we wrote close to 5,000 SITREPs across 20

different or so school organizations, and last year we wrote a total of around

50,000 SITREPs. So you can see that if you got 35 verticals and 10,000 of them were

K through 12 related, it's a fairly active vertical for us, even with not a super

large number of accounts. So just to put it into perspective for how we look at K

through 12.

Okay, stage four of the kill chain is discovery.

The attacker is in, and now they're trying to figure out what all they have access

to, how far can they reach, what can they do?

So in this case, the attacker is probing for legitimate account names, trying to

enumerate those accounts using very traditional Windows login systems,

capabilities like Kerberos and NT LAN Manager, trying to run brute force attacks

on both of those, LDAP reconnaissance against the domain controller, and we also

saw command and control activity.

For those who aren't close to that, C2 is when the attacker establishes a presence

inside of your environment on a machine, typically it's some form of malware.

And the first thing that malware is going to do is phone home to wherever in the

world the attacker has a larger instruction set.

So that's command and control, again, pulled from military terminology.

And this phone home is revealing back to headquarters for the attacker, "What have

I found? And based on what I found, what is the weaponry or technique that I should

now use next to get where I need to go in this environment?" As you might imagine,

attackers are pretty sophisticated these days, and there is a wealth of

infrastructure that they can tap once they have a little bit of footprint in your

world and a little bit of knowledge about how your particular attack surface and IT

environment looks. Okay, from a defense point of view, if you can see this, you

clearly want to isolate any particular machine that's been picked off on LDAP

query, reset any account that it has touched.

And the fact that we were able to catch, in this case through EDR, a C2 connection

is good news. If we caught it, we can block it, so that comms channel will be shut

down. The bad news is you still don't know what originated that C2 channel.

So there's something on that machine, and it's going to beacon back out 10 minutes

later, one day later, one week later.

So it's imperative to not feel that you have victory just by seeing a C2

connection, but put an end to it. And it takes a little bit of work to do that.

Okay, pre-ransom stage. This is where, and actually,

stages four and stages five here were the same school system.

In this case, we picked up a critical alert, and there's a couple of interesting

things on the slide. This particular school system had set up a honeypot,

which is always a good thing to do. If you do set up a honeypot, which can be

discovered by attackers, the rule number one is never, ever, ever communicate with

that honeypot yourself. Leave it, very sacred territory.

Because you know the moment it's been touched, something bad is happening.

In this case, the honeypot account attributes were changed and group membership was

changed. Those are pretty obvious tells.

Second thing, there was a ransomware link picked off at the endpoint by the EDR

product, and it was marked by Microsoft as Storm-0300, which is

code for a known ransomware pattern, but Microsoft

cannot link it to a specific ransomware group.

So they use an 0300 code, which tells everybody this is what they know about this

particular attack.

In this case, you definitely want to isolate that host right away, reset

credentials, and now you need to be thinking about reviewing every administrative

account, and you need to start thinking about looking at your backups, making sure

they have prominence and that they can be recovered, because it's probably not a

far step before that's going to come into the picture from an attacker point of

view.

Okay, let's take a pause before I go through the last two stages and a little bit

more information, and let me just ask a second poll question here.

Actually, if you can hear and if you can pop this one up, but I'll read it aloud.

So if a critical alert fired in your school environment and the

setup here is that this happened on 11:00 on a Friday night before

a school break, maybe spring break or fall break, who's going to see this?

So I'll give you a few moments to put your answers in.

Well, it's good to see that a pretty high percentage, over half, it's fluctuating.

It's not just being seen by one person. That's very good news.

Just me is not a bad answer, but it means the entire responsibility is on the

shoulders of one. And, we have to get into the

specifics of what seeing means. Hopefully, on Friday night at 11:00 PM, when you're

not busy with other things, you still then take some form of action, but you begin

to see the pattern here. If the attacker knows what your schedule is and

something about your environment, they're going to pick carefully when they should

probably invoke certain steps. So actually, I'll leave it to you to end the poll.

Okay.

Now let's look at the exfiltration stage.

Now, in stages six and seven of these last two slides here,

we don't have sit reps on these two stages, not from any of our customers in 2025.

That's a good news story because we always want to catch things in stages one

through five. As I'll show you later, the goal is, as we call it, left of bang,

try to catch the attacker technique as far to the left as possible, and you'll see

why that's important in just a moment.

But what we see here is there are three things that are going to occur at exfil.

There's a gather stage. This is where the attacker is collecting the records or the

information or the accounts or anything that is of value that's going to go out the

door. It's going to get compressed, and then many times it will leave in a low and

slow fashion because they know if you're running EDR or if you've got network

firewalls or if you may have other things in your IT stack, your security stack, a

giant exfil at an odd time of day to an odd address is going to flag.

So the best thing they can do is try to make this fly under the radar, and one way

of doing that is taking a large file and breaking up into smaller chunks and

sending it out a little more surreptitiously.

From a defense perspective, it's starting to get dangerous, so speed is now the

most important attribute in order to limit damage.

If you find this, you kind of want to move to the unplug stage.

This is where you need to cut the connection, probably break your public-private

boundary connections, because you're now headed fast towards a more serious

situation. I think that's all clear.

Many school systems will have an incident response plan in place. Not all.

Many will sometimes have a cyber insurance policy, and it also involves a

step where you involve legal counsel at the right point in the process without

lighting people up too soon, but definitely don't notify them too late.

Those are all very procedural. They need to be handled very carefully, but this is

the stage where that becomes vitally important.

The last stage, impact. So what happens here is the data

has already left. Now we're going to see if this is a ransomware attack.

The attacker's going to start grabbing backups and either deleting them or

encrypting them first. Encryption is going to become pretty widespread.

It will lock up as much as it can, as fast as it can.

And then somewhere, there will be a server that has one text file that's left open,

and that's going to be the ransomware note.

And when you have an environment that is completely encrypted and your IT people

start to go in and look for, well, which servers still have life, you're going to

find one, and the note's going to be there, and that's the beginning of a pretty

hard situation. So at this point, we're no longer

worried or thinking about detection and response.

This is now a full-scale incident, and you have to invoke an incident response

procedure that's going to involve a number of parties, including the public, or at

least maybe all the families who have students in school.

You may have compliance things that have to be notified, law enforcement.

So it turns into a pretty big exercise at this point.

All right. I mentioned earlier that the goal of any detection and response approach

is to move to the left of this process as many times as

you can. And so if you can stop the attacker in his or her tracks at the

access level, that's about the best you can do.

It's really hard to stop at the recon level.

It's possible, but it's hard because not all scans that you see are necessarily

negative or malicious. But access, if you can piece together the right signals, is

an important place to really focus hard on.

Remember, though, the lower box here, there's no single signal that I've showed

above that in and of itself would've been conclusive.

The power in a solution that can look at all those signals is to be able to

correlate them, contextualize them, associate them, do that at speed, map

them to MITRE ATT&CK frameworks,

map them to other things that would give us higher confidence that this is a real

attack, and read all that quickly together as an amalgam.

If you get past stage two, it takes more time to unravel the situation, which is

more cost, more frustration. You see things move from minutes to weeks to months,

and that's a really tough situation if an attack reaches stage seven.

Okay. Let's talk about what can be provided in a school situation when there is a

hit, just a SITREP of any kind.

The first thing I'll say, and those of you who are in the IT world, and especially

if you look at alerts at the security level, you'll see commonly what looks like

the text string on the left. If you are a person who travels in alerts and you know

IP addresses and you know operations and TTPs, this is common lingo.

If you don't do this every day, it's a little bit cryptic.

So a big part of what our customers like about us is the situation report itself.

That is a document that goes to you, through different channels, that will

tell you, "Hey, here's an alert that we saw, or alerts.

Here's what they mean. Here's what you should do about it." And if you

want us to take it all the way to conclusion, if you would like for us to perform

some enforcement action, we call that active response, and we can do that in the

form of a firewall rule change, endpoint quarantine, other mechanisms that will

stop the attack progression before it completes its mission.

But the SITREP, again, is going to tell you what happened, and if we look back over

some of the

incidents that I referred to, it's going to tell you in plain English.

Somebody created a hidden mailbox rule. It was one staff mailbox.

Payroll emails are being hidden.

It matches an earlier rule on a different account. It looks like payroll diversion.

Here's what you should do next. So we try to break this down.

We've got a lot better at it through the power of natural language processing and

AI. We try to make this English language, because sometimes these are herald far

situations, and you want communication to be clear, easy to understand, and know

exactly what to do next. The picture on the left is a little harder for most people

to decode.

I'll move quickly. Here's an example that sort of goes back to the suspicious inbox

rule creation, which had a priority two mark, and the IP address has been sort of

fuzzed out. But we told the customer specifically, "This was the new inbox rule.

This is specifically who and what was affected. Here was the evidence that we saw.

This is why it matters, and here's what you should do next." So it's a real-life

case. This is not the way the SITREP looks itself, but this is the essence of

what's communicated.

Okay. If you have an incident or a progression that is noteworthy,

somebody, maybe head of school, is going to ask a few specific questions.

They're just going to want to know, "Hey, thanks for letting me know through the

SITREP that this is taken care of. But are we still at risk?

Was there any exfiltration? Who do we have to tell about this?

What's it going to cost?" So this obviously involves your collaboration with

different kinds of functional folks in the organization and outside of your school

organization.

It's really good to have these rule sets written down and have a good IR policy or

incident policy ahead of time so you don't have to figure it out on the fly.

If you don't have something like that in place, there are many organizations that

can help you with that. We can as well.

But it's good to run these things to ground because you're probably going to get

one or more of these questions.

So, what can a small team of one to three do this week or right

now based on what we've discussed?

Well,

it's not a new recommendation, but we still find that multi-factor authentication

is not deployed as broadly as it should be.

And if it is, there still is the presence oftentimes of more traditional,

more legacy authentication capabilities, which just involve passwords.

You really want to get to a full MFA, as broadly as you can.

Obviously, having the ability to alert on mailbox rules from one of the examples is

a very important one. Hopefully, everybody's running some form of endpoint

detection and response, but it needs to be deployed on all the endpoints that it

can be.

Make sure that your backups are stored offline and are tested on a regular basis.

Have an incident response plan. And number six is marked in a different color

because it's what we do.

We put 24/7 eyes on all data sources that give us insight into your IT

environment and can help us piece together that kill chain and hopefully catch

things early stage, where it's difficult for smaller teams to do that at all, let

alone after hours.

So where do we fit in?

We will bring in, if I go back just to the primary data sources that I mentioned

earlier, if you're running M365, if you're running a Fortinet firewall or Cisco

firewall, if you're running Active Directory, if you're running an EDR from

CrowdStrike or S1, or any of the others, those are all telemetry sources

that we bring in instantly through APIs. They're very easy and fast to configure.

We also like to put an out-of-band network traffic box, it's a very small

device, it's off a mirror tap port, into your environment that lets us see all

north, south, east, west traffic.

We can pull a lot that firewall logs alone can't see when you're looking at the

packet level, and you can actually study bi-flow data, and you've got rules that

fire on all kinds of threshold and behavioral conditions.

We write SITREPs for every validated finding.

We try to only send you SITREPs that are worth your attention or worth your time.

That's a big part of what we do is eliminate a lot of false positives.

We will do, if you want us to, active response through the tools that you already

have in place. We don't require that you change your stack or add anything extra.

We can invoke rules through your EDR solution, your firewall, Active Directory, so

forth.

We pride ourselves on learning a lot about the school environment.

That means knowing your IT team, by person, knowing your IT and

security stack, knowing your risk and policy and procedure profile, which

helps us serve you the way you want to be served and in a better way.

And we run 24/7. There are pretty rapid response targets around high critical

findings. We map everything to MITRE ATT&CK framework so you can see where your

holes are. We have monthly touchpoints that will tell you, "Hey, this is what we

did for you in the last 30 days. Here are some things that we caught that we think

you could improve upon to reduce the viability of your attack surface getting hit,

so forth." We don't replace anything in your stack, and we don't drop anything new

with the exception of just putting an out-of-band box for collecting network

traffic. So it's pretty seamless and transparent the way a service gets deployed

and operated.

Here is a free after-hours test. It is a 10-question

document. It's short, it's a Microsoft Word document.

If you're afraid of QR codes, there's the actual link, you can feel free to use

that. We're a security company, so hopefully you'll trust us.

It's good to run through this, will take you about 10 minutes, and just make sure

you have these sort of questions in your mind and maybe look at some of the avenues

for defense mechanisms along the way.

If you'd like to do something more involved with us, we have a free proof of value

where we'll come in and plug into your environment, pull the data sources, look at

it for 30 days, write SIT reps, give you a detailed report at the end.

And you can learn a lot from that, even if you choose not to purchase a solution or

do business with us. So that's there for the taking, if you're so inclined.

That's the end of the presentation. I've tried to keep it to 30 minutes.

I ran a little bit over. Thank you for your attention.

I'd love to answer any questions you may have.

So Ashley, however we administer that, I'm available to-

Yeah, that sounds great. Well, first of all, thank you, Neal. That was amazing.

I think our attendees are definitely going to have a lot of takeaways from today.

Attendees, I welcome you to come off of mute if you would like to have a

discussion. That's why we have this set up as a meeting.

That's a little bit more interactive.

Or if you're not able to do that, you're welcome to post your questions in the

chat. And one last thing before I, again, open up the floor to all of you, we have

some brand new Atlas resources that directly address some of the things that Neal

was talking about today. If you do not have an incident response plan in place, we

have everything built out for you, a whole template, soup to nuts, that has been

vetted by other independent schools, and it was done in collaboration with K12 Six.

It's a fantastic, brand new resource. So take a look at that. It's in the chat.

And then second one, there is an interactive tabletop exercise where it's

an AI-based, it's like a game-based thing, but it guides you through a discussion

with your admin team. If you have not tried it, I highly recommend playing with

that one. So dropped some resources there for you.

And yeah, again, I'm going to open up the floor to all of you.

What questions do you have for Neal?

Looks like there's a question in chat, Ashley, if

everyone's being shy.

Yeah. So, if they have an endpoint detection response and

they've got firewalls, what are they missing?

Oh, good question. Well,

we will always say that ideally you want eyes on your devices, so EDR does that.

You want eyes on your network. Firewall is a piece of that.

Let me come back to that one. You want eyes on any identity authentication

authorization solution like Active Directory or other LDAP-based solutions.

Those are the big three, of course.

Put eyes on endpoints, ideally every device, which is tough in a school system

because of students, but if you do drop school-owned iPads, then you can drop

agents onto those devices.

The other ones would be

the critical applications that everybody runs, Microsoft 365 or Google Workspace

are treasure troves for catching attacker activity.

And then the fifth one would be anything you're running in the cloud.

If you have an

application or a workload that's running on either AWS or Azure, maybe

something you share with students or just within the administrative realm,

ideally you want eyes on those things, too.

So the goal would be to

have something that's looking at all of those domains, not just your endpoints,

not just your firewalls. I said I would come back to the network piece.

Firewalls are prevalent. They have been for decades, of course.

And the typical placement, if you're a big school system and you have lots of

money, you might have them internally with just east-west locations.

But typically, they sit at public/private boundary points, each school's internet

connections, maybe administrative office connections.

So those firewalls are really, really good presence points to catch north-south

activity, something that's crossing a public/private boundary in either direction.

But the firewall alone will not tell you everything you need to know.

You need to kind of look at the network traffic.

So we always advocate for our customers, look, let us drop a box,

again, off a mirror or tap board. It's not invasive.

It will not impede any of your traffic or introduce any

performance issues. It just gives a full copy of north-south, east-west traffic.

We then look at packet level information, specifically biflow data.

So we can see a lot in packet headers, even if all the traffic's encrypted, that

will tell us things that are

suspicious, anomalous, maybe malicious.

So I would always say, hey, it's great to have EDR. Don't run without that.

It's great to have firewalls. Don't run without those.

But look at your network traffic and definitely put eyes on Microsoft 365.

Great. Thanks, Neal. Looks like there's another question.

Jason, I don't know if you want to come off mute or we can just read your question.

Sure.

So we've got a lot of pieces of the puzzle, which it is.

And customized obviously for our size of school.

What I found is personally, I feel like having an in-house security person

really,

it's a lot of money for 40 hours a week, whereas I could probably for that same

salary,

outsource to someone like a CrowdStrike or an Arctic Wolf or someone to do those

pieces. But what I'm wondering is, have you seen or do you have

some sort of checklist to say, okay, so we've got EDR, we've got people who are

going to be able to field that phone call at whatever hour, whatever holiday it's

on. We're looking at our configurations in Google based on NIST and

other set standards,

et cetera.

I've used consultants to help me piece this together.

Are there standards out there for schools that would help

create this ecosystem?

That's a good question. Let me answer from my vantage point, but actually,

maybe Atlas has specific K through 12 resources as well.

We at Gradient Cyber, and we look like an Arctic Wolf.

That would be the closest comparison.

We don't look like a CrowdStrike, just to clarify that, because we're not an EDR

provider. We just take the EDR information the same way an Arctic Wolf type

solution or any entire others do. So that's the world we live in.

We're big fans of the NIST framework.

I don't think you can go wrong if that is your start point if you have for whatever

amount of time you can afford, just a CISO hat on.

I will always say that is the best place to start from what should I

be doing in terms of best practice.

Obviously, the MITRE ATT&CK framework is another really good one to tell you.

These are commonly what we see from attackers, and the more

you can provide about your environment, it will give you insight into where you're

covered and where you're not. So I always see those as really strong

overview, what am I not doing that I should be doing?

To your point, Jason,

if you have the luxury of budgeting and having a full-time security analyst, great.

The problem is that's still not a 24/7 person.

They do go to the dentist. They do have off days.

We would never advocate against that for obvious reasons, but just to put math to

it for the moment, a good one, they're going to run you $100,000, $150,000 a year,

maybe more if you consider loaded labor rate.

A good MDR, MXDR service for a typical school system, let's say somewhere between

200 endpoints and maybe 1,000, somewhere in that range.

A good

detection response solution is going to run you Three to five a month.

So if you take the high side, that's five grand a month, 60 grand a year, and now

you've bought an organization that doesn't do anything but this across all kinds of

organizations, and they have just a better bird's eye view, and they're running

twenty-four/seven, and they've got a SOC in place and processes and procedures,

deep analytics. It's pretty hard.

That's not a fair fight to pit those against one another.

If you can get the best cyber guy in the world, you won't have him in six months

because he'll get a better offer tomorrow. We all know that trap.

So,

we typically see it in every vertical, but particularly K through 12, it is a

highly outsourced-based equation. That's why we come into play.

But I will always say start with NIST. You just can't go wrong.

And, not surprisingly, if you say NIST and Cloud, you

can do quite a lot by yourself.

Thank you.

Thanks, Neil. And not to put anyone else on the spot, but I saw, Steve, you had a

question in here as well. Do you want to talk to Neil directly?

Yes.

Okay, great. Thank you.

Yeah, I'm okay talking.

So our particular situation is that we have moved almost everything off-site

after a previous cybersecurity event, a ransomware event.

So there's a sense on campus that since all of our storage and all of our accounts

are run through Microsoft O365,

and then on campus, we still have our network connection and then all of our other

service connections through switches.

We don't have a very big network for anything other than just putting

network into rooms. We do happen to have, though, a camera server on site, a locks

server, and a voicemail system. And so what I'm trying to

figure out is what do we really need to be paying attention to?

Obviously, Entra ID and protecting identification for our Microsoft instance,

but what do we have to do for on-site?

Well,

let's start with that locks server, if I'm interpreting what that is, it's what it

sounds like.

Yes, it is what it sounds like.

So that's a pretty important asset.

Yeah.

For all the reasons we know. If you're running anything on-premise that is in sort

of a

building access control, that's a super important asset.

What were the other ones you mentioned?

Sounds like you've moved most of your school

operation and administrative function all to the cloud.

Yeah, most of the school operations have moved to the cloud, and I think we have a

sense of security that comes with it.

But we do have on-prem servers for security cameras and what manages our

locks and entries.

Yeah.

And then we also have all of our phone and telephony stuff on-site.

Yeah. And you've got pipes into the classroom for teaching tools, I assume,

internet access. So you still have an active network, and you've got on-prem assets

that you do not want to get hacked. I would still say, look, in that scenario, you

just can't go wrong with dropping a box that's looking at network traffic.

Even to your point, you're not running a big network.

It's not got a lot of spread to different servers because most of what is needed is

in the cloud somewhere. But you do have premise locations.

You do have public/private boundary points.

You do have critical assets on at least one premise for physical controls.

So if an attacker got into that environment, if you are looking at

network traffic, you've got a really good chance of catching anything that's

anomalous, suspicious, or worst case, malicious.

If you don't have eyes on full east, west, northwest traffic, you're running a risk

there. You can put EDR or more sophisticated forms of

endpoint detection onto the endpoints for those servers you mentioned.

But if you're only leaning on looking at the server, looking at active processes in

its sort of compute environment,

storage environment, you're missing what a network could tell you.

That's what I would say. We just always find-- And I guess the proof point here

would be if I look back at the 50,000 SITREPs that we wrote last year for our

customers, a high percentage of them were written because of things we pulled from

network traffic.

Because if something's going to get to an endpoint, it's got to go through a

network first. So if you can catch it there, you're usually better off.

It's worst case, belt and suspenders.

Best case, it finds things that endpoint

detection response does not catch or catches too late.

So that's the first thing I would advocate.

Okay. Thank you very much.

Just to tag onto that, if there is a school out there that is completely

cloud-native, and you have nothing running on-prem except just these umbilicals to

school rooms, and you've got that put into a VLAN where it's segmented off and it

can't travel outside, that's great.

But then you've got a fairly sophisticated network running in the cloud.

Everything's not on a single server. It's not on a single VPC.

Maybe it's across multi-cloud. So there are still network connection points there

where virtual firewalls belong, and there is still network traffic.

So putting eyes on that, either through AWS or Azure telemetry or through secondary

firewall rule checks and network traffic checks.

If you're 100% virtualized, you still have a network.

I know you probably know that, but a lot of people say, "Oh, we're in the cloud.

We don't have a network." Well, that's not a true statement.

Yeah, our MSP actually, it's a part of the services they provide, which is to have

firewall for the seven virtualized devices plus our Microsoft instance.

Nice. So then the only question is, so you've got the right infrastructure, but do

you have all the right eyes on that twenty-four/seven?

Because somebody's still got to look at this telemetry and make decisions.

The answer is no, in case you were wondering. Fun fact. All right.

Thank you very much. I appreciate it.

Sure thing.

Y'all, we have a few more minutes before the top of the hour.

If anyone else wants to come off of mute and try to get their question answered.

If not, I will sit and see if Neil maybe can do some asynchronously for us, too.

Asynchronous question answer, I'm happy to do that,

if that's what you meant.

I have a question for you guys. I'm in a kind of noisy environment, so I apologize.

But when it comes to

trying to get the funding to make some of these changes and get the extra resources

you need to get a stronger security posture, what are some things that we can try

as IT director level to be able to emphasize the importance

of what we need to secure our networks for the people that actually hold the purse

strings?

Well, there are

loads of stories that you don't want to have happen to your school system.

Those are not hard to come by.

We can produce assets that will tell people, "Hey, look, these are the

typical risks that we see in a K through 12 environment.

This is what it would cost you to cover or mitigate those kinds of risks through a

service like ours."

If you're asking for something that paints the picture more for just a

financially-minded person who doesn't know anything about cyber and doesn't want to

know, but they're just speaking in strict, what's it going to cost, and what does

it do?

I could have a separate conversation with you, or we could probably provide some

separate assets, but there's a lot of that out there broadly on the internet, I

think. And Atlas may have things along those lines, too.

Great. Thank you.

Yeah, I think, Neil, definitely talking about that reputational risk.

You can

talk to the CFO, what would happen if your main donors' financial information was

exposed and extorted against them, or their kid put in a compromising position with

their sensitive information? What would it look like with our school splashed all

over the news with us? And what if we're unable to have school for a long period of

time? What would that do to our school's reputation?

So that can help with some of those conversations.

The second one is really nasty. When your environment is fully encrypted and you

can't open the doors, and you're down for hours to days to weeks,

and now family lives are disrupted.

School reputation obviously takes a hit.

The recovery cost of getting out of the sling and then believing you've put the

right mechanisms in place to have that not happen again.

These are all costly things to deal with on the back end.

This is another example of an ounce of prevention is worth a pound of cure or

better than a pound of cure. So, there's a lot to consider there, but yeah,

reputation, downtime, loss of critical assets, exposure of critical

records,

financial resources gone, records in the wild, all kinds of things can

happen and do.

All right, y'all. Well, we are coming to the end of our time today, but again, we

want to thank Gradient Cyber for being with us.

This has been a fantastic and very knowledgeable presentation.

Y'all, I'm going to send out all of this in our archive.

We'll have Neil's contact information there and Gradient Cyber, if you would like

to stay in touch with them. But thank you all for being here today, and be sure to,

again, check out the Atlas resources around this.

It's theatlas.org/cyber is where we gather all of these things.

But this will be added to the archive. But Neil, thank you so much.

You were great today. We really enjoyed having you.

Thank you. I appreciate the opportunity. It was nice to speak with all of you.

Appreciate your time.

Bye, everybody. Have a wonderful day.