April Mardock, Chief Information Security Officer at WASIPC, joins the podcast to analyze the primary entry points targeted in K-12 ransomware incidents. The discussion offers actionable guidance on multi-factor authentication, vendor risk management, data retention policies, and using gamified tabletop exercises to prepare school leadership for cyber incidents.

• April’s LinkedIn profile and email address
• Cybersecurity tabletop simulation game (Gemini Gem), step into the hot seat of a live cyber attack and lead your team to safety
• I Asked 24 Ransomed School Districts How the Attackers Got In - There Were Only Three Answers, LinkedIn article that April authored
• K-12 SIX (K-12 Security Information Sharing and Analysis Center), threat intelligence community providing free K-12 cybersecurity guidance, checklist guides, and standards
• WISPC, public, non-profit agency in Washington state that provides technology solutions, data management, and cooperative purchasing services to K-12 schools
• Cyberforce|Q service from WISPC, building and implementing cybersecurity programs for organizations of all sizes
• Bluum service from WISPC, helping educators leverage technology to create a more effective and engaging student experience
• Cybersecurity & Infrastructure Security Agency (CISA), from the U.S. Department of Homeland Security; as the national coordinator for critical infrastructure security and resilience, CISA works with partners at every level to identify and manage risk to the cyber and physical infrastructure that Americans rely on every hour of every day. CISA works with partners to defend against today’s threats and collaborate to build a more secure and resilient infrastructure for the future.
• Secure Cloud Business Application (SCuBA), CISA project providing tailored cloud solutions guidance and secure configuration baselines (SCBs) for Microsoft 365 and Google Workspace applications. SCuBA’s guidance aims to protect information that organizations create, access, share, or store in cloud environments.
• Backdoors and Breaches, incident response card game

Welcome to Talk Technology with Atlas, the show

that plugs you into the important topics and trends for

technology leaders, all through a unique independent school

lens. We'll hear stories from technology directors and other

special guests from the independent school community,

and provide you with focused learning and deep dive topics.

Kevin Warenda, TLIS: Hello, everyone, and welcome to Talking

Technology with Atlas. I'm Kevin Warendo, Director of Information

Technology Services at the Hofstra School in Lakeville,

Connecticut,

and I'm Bill Stites, the Director of

Technology at Montclair Kimberly Academy in Montclair, New

Jersey,

and I'm Hiram Cuevas, the Director of

Information Systems and Academic Technology at St. Christopher

School in Richmond, Virginia.

Kevin Warenda, TLIS: All right, gentlemen, I made it. The

training wheels are off. Peter finally let me open the show by

myself. Well, it's good to be rid of Peter. I think that's

what we can say about that. Anything that pushes Peter to

the side, I am all for.

I'm speechless. I'm actually a big fan of Peter,

so you know.

Oh, I'm Peter's biggest fan, and he knows it. I

just like giving him grief. Hiram and I, you and I, just

spent so much time with Peter. I don't even know where to begin.

Kevin Warenda, TLIS: Indeed, we did. Well, I'm preparing for a

totally new experience myself next week. At the end of the

week, my family, including our dog, will be piling into an RV

or rented to travel to the Midwest. My older daughter is

going to be competing in gymnastics at the Junior

Olympics.

Oh, awesome! Good for you. We've got campgrounds

mapped out. We've got a chartered fishing trip, and then

everything else is going to be quite the adventure. So, I'm

actually curious, Bill and Hiram, you have any epic road

trip memories worth sharing? So many people may know I've seen

all 30 baseball stadiums in the United States. We've generally

flown into different areas and mapped them around, and I will

tell you as far as a road trip goes. One, I'm extremely jealous

of what you're doing. I always wanted to get a camper and do

that because my retirement goal is to live the van life. I want

to get something kind of just be able to travel around like that.

Teach a chum van-that's what you want,

exactly. But but based on the travels that I had,

the one thing I would highly recommend people to do: we flew

into Seattle, we drove over to Cannon Beach, Oregon, home of

the Goonies, where that was filmed, and then we drove down

the Pacific Coast to San Francisco, and that is a road

trip that I would take time and time again, some of the most

beautiful landscape, beautiful scenery, and one of the best

drives that I had. We were amazed because when we were

inland on one side, it was like 100 degrees, and as we made our

way back to the coast and over the mountains and came back

down, we literally saw a 50 degree switch in temperature

when we went from one side to the other, so prepare for all

and enjoy yourself. But it was a great road trip.

I'm very jealous as well. Grace and I we drove

across the country many years ago, did Bryce Canyon, Kings

Canyon, and Sequoia, and then for our honeymoon we camped for

two weeks out in the Pacific Northwest in Montana. So we knew

we were going to get along after two weeks camping together. I

think what you'll probably love the most is when you pass

Kentucky. That's when the humidity starts to drop. It

really is fascinating, and the dry air of the Midwest and the

further west you go is just fabulous compared to the East

Coast.

Kevin Warenda, TLIS: All right. Well, speaking of going places,

I'm excited to see where the podcast takes us today. Our

guest is a veteran K 12 cybersecurity leader with more

than 20 years of experience. She's nationally recognized in K

12 cybersecurity risk management and governance. Currently

serving as the Chief Information Security Officer for WASIPSE,

which is a Washington School District cooperative. It's my

pleasure to welcome April Mardach to the show. Please tell

us more about yourself and your journey that brought us here

today.

Sure. So I've been in K 12 a long time. I

originally actually started as a var doing support for back in

the day Solaris, Novell, Netware, a lot of old tools, and

slowly migrated to supporting Macs, which ended up with a lot

of K 12 customers. That time, I supported over 100 different

companies, small, medium, and large. So I got a lot of field

engineer experience, hands on, you know, setting up the whole

set stuff and troubleshooting and training users and all of

the things. And eventually, I ended up taking a position with

a local ESD, which is like a regional area that supports

school districts. So, like Washington has nine ESDs, and

the ESDs are partially state funded in a tiny way, like 5% of

their budget, and then the rest of their income comes from their

local school districts as they provide services. And so, I

provided regional services to K 12 s in my region, and since

basically '99, and in fact was involved in a bunch of Y2K

stuff. So I've been doing cyber for a long time. Did firewall

audits and configurations. I was on the techy side of things,

right? Doing an awful lot of support for soup to nuts, a

district that has no techs or one IT person. Who might also be

the science teacher? So you've got the small districts, the

medium districts, and the large districts. And eventually, I

ended up getting hired by the largest district in the state

here in Washington, Seattle. Worked for Seattle 15 years ish,

and then now I'm back at the state level, K 12, working for

WASI as their chief information security officer. And what's

cool about my job here is I am 50% internal facing, doing

cybersecurity and CISO work, helping with incident planning

and response, all of the normal kind of create a cybersecurity

program from scratch. But I'm also doing 50% external facing,

which allows me to do some of the national work with K 12 six,

and to work with districts across my state in helping bring

everybody to a higher degree of cybersecurity stability and

include postures. So, for instance, one of the things that

I think I'm about to get kicked off, I'm actually participating

as a lead in the state's cyber incident response team, so I'll

probably be heavily involved in K 12 support in that space, and

I'm also working with the state on putting together a

vulnerability management process where we will get an email and a

flag when a district has essentially-I don't know-you've

seen how many districts have gotten taken over by way of

exposing an Exchange server or a SharePoint server or something

like that that didn't get patched in a timely way, or just

didn't get removed because it was end of life. Right? Those

are kind of threats, and the state's going to work with me.

Maybe it's looking really, really likely on allowing WIC to

sort of coordinate that notification and helping

districts figure out what to do to mitigate their

vulnerabilities for those sort of extraordinary all hands

remote takeover risk kind of things. So super excited! It's

been a long journey, and I'm in a place where I can really move

the needle, both at the state and the national level. With the

K 12 six side, the technical working group there is a group

of K 12 geeks, security geeks from across the U.S. as well as

some folks that are not geeks, that help us with making sure

the messaging is understandable for any district. And that group

has come up with some amazing resources that are free to

anybody who wants to use them. Things like the "What to Do If

You're Compromised" checklist, where you can basically go

through and if you get a compromised account, it reminds

you of all the things to do-not just reset the password or flush

the sessions, but look and see if somebody connected an

application. Right? Look and see what rules might have been

configured. Look to see what else may have been done, because

as we all know, the attackers are getting more sophisticated.

So, that's a group that also came up with a 14 question

cybersecurity assessment that's really easy for small districts,

independent schools to do. That gives you like your top marching

orders for the top one or two things you should really focus

on for the year. Doesn't take a rocket scientist. Really

approachable. So that's been kind of one of my big goals: is

to try to make cybersecurity approachable for everybody, all

the districts, tiny or huge. Oh,

Kevin Warenda, TLIS: that's such important work. I saw recently

you posted an article on your LinkedIn feed. I think it was

you've interviewed 24 school districts who've been victims of

ransomware, and you kind of boiled that down into a really

approachable lens to think about this through like the three

doors that attackers come through. Maybe you could talk a

little bit about your findings there and how easy it is

actually to maybe think about securing those doors.

Yeah, when I was with my very large district, I

did not want to be next in the ransomware parade, and to do

that, I started asking folks at conferences and other places.

You know, after they presented about their event, you know how

did bad guys get in? You know, in the very beginning, the camel

got their nose under the tent. Where'd they poke their nose,

right? And it turned out that it was really only three answers,

and three answers that aren't rocket science. The first one

tends to be when, like I mentioned earlier, there's a

device or a system that's exposed to the internet and is

not patched in a timely way, whether that's a server like an

Exchange or SharePoint server, or it's a VPN appliance, it's a

firewall management port. Please tell me you've removed all the

management ports from internet. They should not be facing the

internet, but that's a different discussion. But anything that's

basically exposed to the internet that wasn't patched in

a timely way, or is end of life and doesn't have patches

anymore, right? So that's number one. It's keep those things

patched really quickly. And it used to be we said 30 days. Now

it's 14 days. I'd say if you can patch it within 48 hours, you're

in a better place. If there's a big announcement that says

people can take over your whole system through that device is

probably a good idea to patch it, especially those CISA known

exposed vulnerabilities are also known as CEVs. So that's door

number one. Door number two is where basically remote access is

possible, and it's either VPN or. Some kind of remote desktop

service, but there's no MFA required, meaning you don't have

to put in an authentication token. You don't get an SMS.

There's nothing other than a username and a password that

gives you full remote access to that district or that

organization, and that includes vendors. We're really bad about

letting vendors use the same account for all their texts, and

we don't make them use MFA because well, there's phone

issues, right? And we're terrible about enforcing our own

rules when we get pushback. And what that means is that vendors

have some bad habits too. They like to, for instance, reuse

password across clients. And so, if a password gets compromised,

whether it's a staff person's password or a vendor's password,

and that username and password can be used to log into that

district and have full remote access, that's a pretty big

hole, right? And so that's number two. The other one that

happens is phishing, which we all see phishing every day. We

run into that, but phishing grows legs and takes over your

organization if the user who gets the fish and responds to

the fish also has local administrator rights, because

what happens then is the fish lands, and the user's machine is

then taken over and used to crawl across and take over the

rest of the network, and sometimes the hygiene of that

organization is bad enough, where they've also used the same

administrator configuration password on all the devices. All

the staff devices get a password. All the student

machines might get a different password. But the problem is

when that password then gets compromised, it can be used to

take over every machine very quickly.

You mentioned working with Solaris and with

Novell, and I think at least Hiram and I-I'll leave Kevin out

of this-but Hiram and I are the old gray beards in the room.

We've been at this for a while. When you said that Hiram and I

are both heard Novell, it was like ding ding, remembering from

years past. And I just remember walking into our network room,

our network closets and just the number of tools that we had that

were on prem to deal with all of this patching that you're

talking about, you know, and everything that was going on

with that, the number of servers you were maintaining, so on and

so forth. I want to get your thoughts on how that model, how

that mode has changed with so much moving to the cloud now,

and so much of what's out there going into the cloud, and what

your thoughts are there, and what that means for, I'll say

the due diligence that we need to do on our parts to make sure

that our cloud services are configured properly, or our

cloud providers are doing their due diligence, and I want to

thank both K 12 six and CISA because I saw this on a K 12 six

email just like I think yesterday or the day before that

there's a new set of tools that were put out called Scuba. That

is for those that don't know the acronyms because it's like

acronym soup when we talk about this stuff. That is a secure

cloud-based application. It's a set of tools and recommendations

that they put out to help you evaluate these cloud services.

So, with that said, what are your thoughts in everything that

I mentioned there?

Okay, so I'll start with, although you've

probably pushed 75 or even 80% of your stuff to the cloud,

don't forget you still have on-prem entry points like the

firewall and like the firewall management ports. Make sure you

stay on top of keeping those patched. We don't think of them

as servers, right? We don't think of them as something that

needs to be patched, but they do. So that's stage one. Stage

two, vendors make mistakes too, and sometimes the vendor

defaults are terrible. And a case in point on this would be

if you guys saw what happened with Clark County Schools, one

of the attacks that they dealt with was somebody taking over

the student passwords. And at the time, the student passwords

were based on birth dates. And I will say a lot of school

districts use birth dates or something like it to configure

those initial passwords, and they don't always force password

changes when they do it. Here's the problem that makes a student

account easy to log into, easy to guess because you get the

user account, you get the password, which is their

birthdate, and you log in. Now here's where it gets ugly.

Everybody should be doing this who's a school district IT

manager, which is you need to log in as a student account and

look around and search for things like SPED or IEP or

discipline or all of the sensitive words right from a

student account and see what's been overshared, because what

happens with Clark County, as I understand it, is there were

Google work groups that a student could add themselves, or

a criminal using a student's account could add themselves to,

but either way, it's a problem. If a student can do this, it's

also problematic, and get access to all the content in that work

group. What that means is, if you can break in with a student

account and can search for all of that sensitive. Content you

can steal that sensitive content, and the default

configuration was problematic. I'll use a Microsoft example.

Microsoft made it so that when you shared a file in the earlier

days, it would share with everyone, whether they were

on-prem or in the cloud. And so you created this link. If that

link got out, it was visible. But here's where it gets ugly.

The AI search engines can now expose files that were shared

with everyone, internet access that you didn't intend to ever

share. Now, just because the person has privilege, because

you said allow it to either everyone or allow it to everyone

in the organization. Okay, think of this from a teacher point of

view. I want to share a file with the kids in my class, and

I'm going to share this file. And I'm not going to name all 30

kids that I want to send this file to. I'm going to share it

with everyone in the org. Right? That makes sense for a teacher.

Same thing happens for say somebody in IT. They want to

share something out to all the staff. They'll share it with

everyone in the org. Well, here's something that often

happens in K-12: the students and the staff are in the same

organization. When you share a file with everyone in the org,

it gets shared to everyone, staff and students. Sometimes

those files are sensitive. You don't intend it to get in the

wrong hands, but if you've shared it with wide open

privileges, now anyone with an account, and that means

criminals with accounts, can get to that file. So those are

mistakes kind of made in the early configuration where the

default sharing was too open, or the default for that group

membership is too open. It allows people to inject

themselves. All of those kinds of defaults in your tenant, your

Microsoft or your Google tenant can bite you because a it's

easier to steal accounts because the passwords are sometimes

either already know or easy to guess, and b those accounts if

you start searching for sensitive content will reveal

things you'd really rather they not reveal. So that's part one.

Part two is our vendors and the vendor stuff? Couple things

there. So make sure that when you're contracting with vendors,

if you give PII to vendors, this is one of the things I worked on

with K 12 six in the technical working group.

We actually created a document that you guys should have access

to. That is what I call lightweight vendor management,

and there's low risk vendors, medium risk vendors, and high

risk vendors, and we consider the high risk vendors vendors

that either have really sensitive student data, or are

operationally critical. If this thing goes down, we have trouble

teaching, or we have trouble keeping the buildings open, or

we have trouble bussing kids-it's something that will

really create a showstopper kind of situation. So those are the

high-risk vendors, and for the operationally high-risk vendors,

I ask questions like, "What kind of redundancy do you have if

there's a Microsoft outage in this region? Can you fail over

somewhere else? Or Amazon outage in this region? Can you fail

over somewhere else? Here's the sneaky part: Amazon and

Microsoft will charge you for that extra resiliency. So some

companies don't pay it. If they're an operationally

critical vendor, you want to start asking those questions.

We actually felt some of that when the incident

in the Strait of Hormuz occurred. About 22% of all data

traffic apparently goes through that area, and a lot of folks

were complaining at my school and a bunch of other schools.

You know what's going on with our SaaS applications, and I've

reminded them, hey, there's a lot going on, a lot of rerouting

of traffic, and sometimes that kind of stuff is out of our

hands, and we can't even control that because it's such a main

trunk of data.

Yeah, for sure. And outages, if it's

operationally critical to your org, you want to make sure that

that software that you are subscribing to has some

resilience built in, so that you have less outages as a result. I

have seen cases where, for instance, the West Side Amazon

West drops, or maybe some of their DNS functionality drops,

and all kinds of things break. Right. So, what you want is to

make sure that the vendor that you're putting your money in for

operationally critical stuff has resiliencies built in. Whether

it's incident response stuff, they have disaster recovery and

can come back. They have resiliency in their services.

You just want to make sure that's covered. And then on the

flip side of that, where it's sensitive data, those are

different questions, right? Number one, I want to make sure

that they can delete my data when I'm done, and that they

don't force me to send them a certified letter to say you must

delete my data because vendors see data as a long-term money

source, and they really don't like deleting it. They don't

like getting rid of it. They don't like purging it. They like

to feed it to their AI models and learn from it. And I really

want my data back when I'm done. The other thing that I'm

thinking about with vendors is: Do you really have to give them

all the data they're asking for? As an example. I stopped giving

vendors birth date data. Why? Most of the time, they can get

by with the graduation year. They don't need a birth date.

They just need basically a rough idea of what range the kid is

in. It's not always the case, right? I can't do that with

every vendor. There are a few cases where that's an exception.

But in general, why are we giving, for instance, vendors

parent home address information just because they ask for it? If

they don't have a legitimate reason to mail the parents, I

don't think they should have home address information. Maybe

email if the parents legitimately interacting with

them or registering with them or whatever for a portal, but do

they really need a home address? And I start asking that question

Is why are you asking for this content? Maybe

we used to give this to you, but maybe we shouldn't anymore.

There isn't a reason to give vendors content that they really

don't need for the purpose that we're hiring them for.

Kevin Warenda, TLIS: Yeah, and it strikes me as you're asking

your vendors about how resilient they are. I know we go the extra

step too to ask for a software bill of materials. Like that

understanding of their service is probably not just one thing;

it's probably also reliant on their own third-party vendors.

And so, if they're hosting their application in AWS West, it's

good to understand. All right, then if you're tied to that

region, that if that goes down, this service may also go down. I

actually spend a lot of time having to educate my community

when things stop working, as to why that's down. It's like,

well, why is Canvas down? It's like, well, because Canvas is

hosted on a third-party cloud that was down today on DNS

issues. Like, so yeah, Canvas's issue is actually the

infrastructure they're reliant on. So I think that's an

important call out that you made there. It's like ask your

vendors to describe their solution, what it's built on,

and how it's configured. Not just from a resiliency and a

data security or data residency perspective, but also just in

terms of what makes up your service. What are you also

contracting with, and what are your agreements with those

vendors too? Because this is where we get into data residency

or controllers and processors too, right? Depending on who

that goes to, like if you're signing a contract with vendor

A, well, if there's a sub processor involved there, like

that data may actually go into that other third party, and that

agreement survives that. So I think that's great that you're

asking about that, and I would say expand that even to all

aspects of that service offering to them. The

one thing I will add to what you just said is

that Hiram and I have been spending a lot of time working

with one of the groups that partner with ATLIS a lot is

nine, and what you're talking about is that vendor vetting,

those sub processors. It's amazing when you get into that,

you start looking at that not only from the resilience

standpoint, but where's all that data going? And April, you said

something that really resonated with me. When you start working

with a lot of these vendors, you know how much information are

you giving them? I think one of the things that often happens,

and I can remember distinctly saying no to one of our vendors,

was when they were asking for API level access to our

information systems because they were connecting things that was

providing direct service. It was like if we wanted to use this,

this how it went in, and they were like, "Well, just give us

API, you know, read write to all these scopes. And I'm like, "No,

I'll give you read access, and I'll give you read access to

these because you need to tell me why. And a lot of times, what

I found is not for nothing. It's laziness on the part of the

vendor to really work to only ask for what they need. They're

like, you know what? Just give me as much as you can, and I'll

figure out what I'm going to do with it later. With no thought,

or maybe there is thought, and I'm just being naive to what

they're actually requesting and what that actually opens up from

that risk standpoint.

Well, there's another layer to that too: is

how long are they allowed to keep the data? And I know for

districts, we have a tendency to keep stuff as long as we

possibly can because at some point that turned out to be a

valuable thing. I'm going to argue the calculus has changed,

and keeping data, especially sensitive data like discipline

data longer than you need to is a liability, and so when you're

working with a vendor and you're giving them sensitive content,

you really ought to have a retention and archive and

removal process in place so that all the data doesn't stay there

forever. Case in point, a lot of us use payroll systems, right?

Payroll systems have like bank account information. How many

years of bank account information is in that system?

If it gets compromised, they might be going back 2030, years.

That becomes a problem if you don't have the ability to purge

the content safely and get rid of the content you aren't

legally required to keep, and you don't have a process for

managing that, whether it's in house or with a vendor. That

creates a big liability because when you are compromised, you're

going to have to go back and notify decades of employees and

or students if you haven't archived that content and pulled

it, especially out of the live systems. They do tend to

compromise the live systems first. They may eventually get

around to archives if you have to keep it for some legal

reason. It doesn't necessarily have to be in the live load,

right? You could put it in another database that you zip up

and tuck away for when you need it for something else, and maybe

that's password protected or some other way less accessible

to the attackers. But if it's all in your live system and it

goes back decades, you're going to be notifying decades of

people, and that's expensive. And it's not fair that it's not

their fault that you decided to keep data longer than you needed

to.

What's interesting about that is I don't know many

folks that actually ask vendors to delete their data. Schools,

in particular. I mean, when you have the transition of employees

coming in and out and in and out and in and out, how many of us

actually have done that due diligence of saying, "Hey, I

need to contact all my vendors within my tech stack to

eliminate these people or this group of students or whatever.

It's a massive undertaking, but it certainly is one that we need

to keep a top of mind,

and I would think of like a phase one, phase two

approach. Maybe you don't do it on a micro level for everyone

who leaves. There's often, at least in the state of

Washington, there's stuff we have to keep seven years after

they leave, or

correct,

however long it is. But you set up something

where all the records that are discipline records that get to a

certain age that have aged out can get pulled together, right?

You don't manage it as an individual, but you start

tagging and classifying data, and asking the vendors to do the

same so that they can appropriately dispose of data

without you micromanaging and saying, "Well, this person left

seven years ago. Let's go purge their stuff. I can't imagine a

small district taking that on, it's a big lift, but there are

ways we can still push the vendors to delete content in a

timely way. And the other thing is, when you change vendors and

you move data from System A to System B, don't move all of it

if you can avoid it. Use those opportunities when you're

changing vendors or doing upgrades to purge content you

don't legally have to keep. Whether that's the vendor doing

the work or you doing the work, I think it's something we need

to be more intentional about.

So, April, we've been looking at this at a very,

very high level, at 50,000 foot level, and I'd be curious if you

wouldn't mind opining on a situation that I think many

schools are dealing with this summer. I had a faculty member

come back to me after attending a conference, all sorts of great

ideas come out of conferences, and one of them had to do with

his interest in using App Scripts to develop an extension

for him to use with his students. And when I took a step

back, I was like, "Okay, App Scripts is open by default, and

I didn't realize it was open by default on the Google domain. So

that the first thing we did was we shut that down,

turn that off.

Yeah, and I'm curious what your opinion is in

general about the whole access to app scripts by anybody to

your Google domain, for better or for worse. I mean, this

teacher wants to do the right thing. He wants to try and reach

kids a certain way, and I think it's a great idea. I'm trying to

develop a sandbox, but we don't have the resources in order to

try and figure all that out when it just appears in the middle of

the summer. Be curious what your thoughts are.

So generally, it's one of those where I turn

off the ability for folks to enable it by default, and they

have to go through a vetting process, and most of the

districts I'm dealing with now have to legally review software

for accessibility anyway, and that includes stuff that you

would expose in a classroom, like your extension that you're

talking about, because the district I worked for was the

first district in the U.S. to get sued for not having a math

tutoring program that was intended for the student use was

not accessible by a blind parent at home, and it turned out some

of the district web pages also weren't accessible to blind

parents, and what it meant was that the district had to do a

formal intake process to avoid further lawsuits to make sure

that software met a certain minimum standard, and all

software had to go through that process. And the rule was

anything that the district purchased or anything that the

district deployed or allowed to be deployed, right? Like this

application that you're talking about, had to go through a

formal review process, and that has a checklist of things to

look at, whether it's accessibility, whether it's the

cybersecurity configuration, whether it's the privacy

concerns that might come with it, like any other extension

that you would deploy, you run it through the same process. If

that teacher wants to submit their custom written application

and go through the same vetting process, I would expect the

process to allow fair treatment of that in the same way they

would if they wanted to bring in a third-party tool. The problem

I run into is a little more esoteric. Is yes, I want to turn

it off and vet everything that I turn back on, and I want to have

an intake process to cover legal. But you're going to run

into CTE classes and other places where they want to do

that kind of programming and learn. Those skills and become

capable of doing this kind of work, and so what you'll end up

doing is creating special sandboxes for that, where you're

going to have to find a way around just saying no. And so I

understand it's a complicated ask.

Kevin Warenda, TLIS: I think it's ironic. I spent almost a

decade in public school supporting technology as well,

so there's definitely that angle of if there's a regulation or a

law or legal reason to do something, you can leverage that

as the excuse of why you're doing it to try to maybe deflect

the responsibility of that choice from the IT director. And

I find myself doing that now, even with our cyber liability

provider, right? So as independent schools, maybe we

don't have so much of that regulation or public school

requirements based on statutes and such, but I'm not above

using the cyber liability policy requirements to say no. Like the

reason we have MFA for everyone is not because I want to make

your lives harder; it's because it's required by our insurance

provider, or we have a vetting process for software and

applications because it's required by our cyber liability

provider, so it's ironic we have to use that as the tool to try

to deflect from why we're doing that. But it's for the right

reasons, and I think it's tough sometimes to try to educate

users as to why that's so important. I want to come back

to something you said earlier about the oversharing of

information. I think this is especially relevant now. I've

heard lots of talk. You were also talking about classifying

or categorizing data sets. This all speaks to this question now.

With these AI tools, especially generative AI tools that now can

work at machine speed, they are uncovering all this stuff that

is shared. And what I'm hearing is the recommendation is you

really have to get your data house in order before adopting

these types of tools for any kind of use, because otherwise

it's just going to find all those corners where you're

hiding stuff. And if it's not labeled, if it's not

categorized, I know Microsoft has a tool for this called

Purview. Right, you can actually classify and categorize what's

public, what's internal, what's confidential, and these tools

then can actually utilize those tags and classifications to

properly put things or expose where there might be issues.

They can

Kevin Warenda, TLIS: maybe you could talk a little bit of any

experience you have in that area or why this is so important in

the age of AI.

Two things I do recommend turning off those AI

search tools until you've done at least some searches and clean

up on your own. But the second layer to that, one of the

districts I work with did tag documents using the Microsoft

tools that were sensitive, and then use the DLP controls to

block the sharing and the emailing of those sensitive

documents out, and so that can prevent theft and overexposure

of content that probably shouldn't be shared. I will say

sometimes staff have I would call it semi legitimate reasons.

They might be in working on their doctorate in education and

they want data. They should be asking for that data formally

instead of just taking it. It's interesting to see who flags

that data loss prevention tool, but tagging that content is

getting easier and easier. You can give it examples of the kind

of content, especially if it's a form type content like a

transcript, a discipline form, all of those kinds of things.

You can teach the system, and it will actually automatically go

out and flag them, find them, and tag them for you, and then

you can treat them as appropriate. So yes, those tools

are getting better. I will say, two years ago, it was a real

pain to try to do this, and it's getting cleaner and cleaner as

you move along. I don't have enough experience in the Google

environment to know how easy that is to do in that space. I

suspect the tools are coming if they aren't already there to be

able to automatically flag content and prevent it from

being overshared, prevent it from being misused in that way.

I'll go back to that piece with the Scuba Tools.

I just literally got off a call yesterday because we went

through a full audit of our Google domain

with Scuba.

Well, Scuba Tools is what I'm going to use

actually to validate what we did in our audit, we used another

vendor that we've used, and this is now our third audit with them

to go through all of that. And it really highlighted a bunch of

the things that you mentioned with regard to the oversharing,

the DLP controls. You know what you need to turn on and off, how

you need to go through that type of audit, and I found that

that's incredibly helpful for me and for my team because, as you

mentioned, you're not as familiar with the Google

environment, so you couldn't comment. Well, we don't live and

breathe in these areas every day, and your role as a CISO is

one that we hear coming up in schools whenever they talk about

this vetting, they say, "Well, talk to your risk committee,

talk to your CISO and your risk person. And I'm like, "That's

just another hat that we put on over the course of our day, and

we're trying to make the best guess in terms of." How we can

go about doing that, and one of the things I'll credit Hiram for

getting me started on is using AI to actually help with some of

that work, whether that be in the evaluation or vetting of

services, whether that be in some of the search work that

you're talking about there. What would you recommend to people

listening to have as their common tool belt of either

partners or tools or things to consider as they put on that

CISO hat that they are interchanging with their

database administrator hat, their mobile device management

hat? You know all those things. What can we put in our tool belt

to help us with this work that we're doing to level it up a

little bit for us?

So I'd go at a couple different angles. One

would be working with their local regional support agency if

they have one, like an ESD educational service district or

equivalent. If they have a state department of education that has

a cybersecurity focus. Sometimes some states have cybersecurity

resources at the state level. For the independents and the

smaller districts that don't have that support structure, you

can look to something like K 12 six that's providing guidance

around vendor management. I'm the chair of the technical

working group, and one of our next tasks after the Essentials

reboot will be that scuba report is amazing, but it's like 20

pages long and there's hundreds of entries in it that are red,

green, and yellow. And I find that a lot of the smaller

district folks are just overwhelmed by that report and

they don't know where to go next. And so K 12 six is going

to work on sort of a top 10 Microsoft tenant and top 10

Google tenant things to look for that are kind of urgent that we

need to make sure all districts are taken care of. So there's

sort of a crawl, walk, run approach to that, where you can

basically start with the simple stuff and work your way up.

Obviously, there are also vendors available that can help

even the smaller organizations that can do the number crunching

and give you something actionable. I don't have

specific vendor recommendations available, but I can say that

there are a number of them out there that are targeted to

helping small K 12 s do what they need to do. They realize

that K 12 s not just don't have a CSO. It might be the science

teacher who's doubling as the IT admin. It's a pretty constrained

environment, and they don't have the time or the resources to do

all the things a big district can do, even though they're

asked to. And so, how do they offload that? There are some

virtual CISO stuff out there as well. I will say, Security

Studio has a virtual CISO class for folks who want to bump up

their skill sets, and there's also folks who specialize in

like nonprofit support CISOs. So they're not looking to make a

dime on you; they're looking to help because they're in it for

the social benefit and the social good reasons, rather than

just you're another customer that can pad the dollars. That's

something I like to see as folks that are in it to try to make a

difference and provide resources at cost or just over cost that

help with both the assessment and the training and the support

to help folks get where they need to go.

Kevin Warenda, TLIS: Jeff, what I find so impressive is that the

scope of what you are responsible for supporting now.

It is very large, 750,000 people. All these districts, but

you really do maintain a focus on what makes that up is a lot

of small schools in some cases too, and that those don't always

have the resources. So I really appreciate that approach and

that focus that you have. I think you've even developed some

of your own tools to contribute too, right? Like I think you

have a AI chat bot that helps with tabletop exercises. Can you

talk maybe a little bit about what you're building yourself as

you're seeing the needs and the need for things that are free?

So I'm a gamer, and I came from a DND Dungeons

and Dragons kind of background, and I also am an emergency

operations center volunteer. I'm actually OxCom certified in ham.

I'm a ham extra, so I spent a fair amount of time in emergency

response work and getting like FEMA certified for all the ICS

stuff. And so what it means is I have a really strong background

in both gaming and in emergency response, and I combined that

with cybersecurity, and I created essentially a

facilitated game. It's more of an interactive cyber attack

story that you can interact with as a school district, or really

as anyone. It's a Gemini gem that will actually ask you some

questions. So it'll start out by saying, "What kind of org are

you? How big are you? Do you have an incident response plan?

Was it tested? When was the last time you tried restoring your

backups? All of those kinds of questions, right? There's like

six questions that ask for setup, and then it drops you

into a scenario where you've been attacked, and as you

respond, it will then respond in kind and provide. Options. It

rolls dice on success or failure. It'll give you bonuses

if you have a good approach, and it will give you a summary of

your performance at the end. And so, it's something that I can do

in person, and I've done it in person. I did it at the K 12 six

conference for somebody from I think I had about 30 states

represented at that session, and I did an interactive session

with the whole room pretending to be supporting one district,

and they would make decisions. and It goes through six injects,

and then at the end, it will give you a summary report. And

what's neat about that is it's adaptive; it never plays the

same way twice. It is intended to be a bit more strategic, so

it's going to ask questions about your communications and

how you would make a legal decision, and how transparent

you want to be as a district about the attack, and maybe some

of the extortion methods that the attackers may be using. Like

sometimes they'll call parents, right, and tell the parents

about what they've stolen. And it's fairly realistic. I will

you'll have a little bit of PTSD if you've been

through an attack, but I think it's a great learning

opportunity and it's free. It's on my LinkedIn. I'll reshare it,

and I think you have it in the links that you can provide for

the podcast. It's useful for any size organization, but I built

it for the little ones that really don't have anyone to do

this for them, and they can't afford a consultant to come in

and do it for them. You can also, if you want to stack the

deck a little, because IT directors, as a whole, myself

included, like to know what we're getting into before we

walk into an executive session. You can run through the scenario

once, figure out what all the injects are, get it to where you

like it, and then tell it to replay the same game. And so the

variability is less at that point, and you kind of know what

you're going to get into. So if you want to run that session

with your executive cabinet, you can. You can also ask it to be

more technical. You can adapt it on the fly and use it with your

IT teams. The other tool that I set up with permissions from our

friends at Black Hills Security is they have a backdoors and

breaches game that is great for IT teams to practice their

here's what I'm being presented with and here are the tools I

can do cybersecurity response with.

I turned it into a game where I set up a storyline where I walk

through what the attackers are doing over a period of time, and

then I line that up with the backdoors and breaches game,

where you have basically how does the attacker get in, how

does the attacker pivot and move to other machines, how do they

establish persistence, and how do they do exfiltration, how do

they steal stuff? There's an online version that is free that

you can play with your teams, and it's a great way to get the

IT teams practicing without having to deal with a real

event. So I kind of have both approaches. The Gemini Gem is a

little bit more strategic in its approach, and then if you do the

back doors and breaches thing, it's more tactical.

So April, in this entire conversation, you're kind

of preaching to the choir in terms of what we need to do,

let's say your audience is for CFOs and heads of school in

independent schools. Explain to them the challenges of the

staffing model that you currently see in independent

schools when it comes to cyber.

So most schools are what under 2500 kids. It's

like 75% or more. Those school districts and independent

schools really don't have the ability to tag somebody to be

cybersecurity full time. In fact, many of them don't even

have like a network tech that's formally trained in

cybersecurity, and so the risk is rarely elevated to the

boardroom. It doesn't make it into executive session, except

when maybe they go to renew an insurance policy if they have

one. And unfortunately, it doesn't get raised to the level

of risk that I think it represents to small districts

and independent schools. You are potentially at risk of not just

going offline, but potentially going under. There's a

significant percentage of districts and small businesses,

especially that literally stop operating after this happens. I

can give a case in point. I know of a you know the 403 Bs. It's a

retirement savings for educators. So one of the 400 3b

operators that was used in my region got ransomed. All the

systems were shut down. They didn't have adequate backups,

and they went under and didn't come back. It happens when a

ransom event happens. The business may cease to function.

You lose trust. You lose reputation with your community,

and potentially you lose your ability to function. You can't

do assessments. You lose your bus routing. I mean, think of

all the things that could go sideways if your systems were

all offline. And it's worth having that business continuity

conversation with. Anyway, because there's other reasons

stuff could go offline. It could be an extended power outage, but

you need to help them understand the consequences of systems

going offline in terms of availability, and then the

consequences in terms of lost trust and lack of enrollment as

a result, and the other pieces of that where maybe they can't

get it back. What if they can't get their bus routes back? What

if they can't get the payroll working? Payroll goes offline.

They can't pay folks. There's just so many high risk things

that come about as a result of not having eyes on this ball

that they either need to contract for that support and

make it a regular part of their process, or they need to train

somebody up, but they really do need to spend some amount of

resources on risk managing this. Otherwise, if they choose to

ignore it, unfortunately, you guys I think introd with it, or

I saw it recently. Maybe it was actually a K 12 six thing. It's

like one out of five has seen a cyber incident, so we're next.

It's another one of those. It's not if it's when, and so if they

don't pay attention to this, the risk just gets amplified. One

of the things that I want to take this out of the

boardroom and out of like the sea level, and I want to bring

it down to how do you have these conversations with your staff,

because we'll talk a lot about the COVID hangover, which was

the wild west of apps and tools and things that everyone were

signing up for. How do you have this conversation with maybe

just below sea level, or when you get into the operational

aspects of school, and then when you get into the classroom? How

do you make it clear to them that I think, Kevin, you said

this earlier. We're not saying no to simply say no. We're

saying no for X, Y, and Z reasons. How do you suggest

having those dialogs, those conversations with those groups?

That's sometimes a harder conversation because

they're trying to teach and they're under resourced and

scrambling to make do with the resources they have as well, but

part of this is they now know. For instance, MFA. MFA was a big

problem for a lot of schools, and MFA. There was a lot of

pushback of I don't want to get interrupted in the classroom. I

have little enough time to train my kids as it is. I don't want

to do it, but they realize everything that's important,

like their bank stuff, requires MFA, and then you pull it down

to brass tacks. Well, if you don't MFA, then anyone can log

in with your account and change where your paycheck gets

deposited. Right, employee self-service, and so all of a

sudden you make it relevant. It's a what's in it for me

approach. So then they realize, oh, if I don't have MFA, then my

paycheck could get redirected, and it has happened. I know of

districts where paychecks get redirected because they didn't

do MFA, and people have a tendency to reuse the same

password in multiple places, so it can get stolen from lots of

places. The example I used was it doesn't even require a

mistake on your part. Evite got broken into, and when Evite got

broken into, the bad guys stole the passwords in clear text. Do

you know how many district folks use their same username and

password from the district on the Evite site? Now the bad guy

knows your username and your password. If there's no MFA,

then they can use that username and password on every system

you've used that same password for, and so that means they can

redirect your paycheck. They can log in and steal your student's

data. They can log in and do everything you can do, and so

then they start to realize, oh yeah, maybe I should be thinking

about that differently. Applications are similar risks.

You can show them that the consequence of that loss is

significant enough to impede their ability to teach. It's a

cause and effect thing. It's a what's in it for me thing.

Kevin Warenda, TLIS: It seems like the theme of this podcast

today has been it's not rocket science, right? You're talking

about basic hygiene. You're talking about common sense

approaches. You're talking about things that don't require a lot

of technical expertise to pull off, and yet we all still need

to hear it again and again to internalize that and to put

these things into practice and to check these doors. April, one

of the things that you were talking about was the MFA piece.

One of the questions that I had that often comes up. I mentioned

the audit that we had done, and it came up in terms of part

of that audit. I've read a lot that says frequent

password changing is often more harmful than having a strong

password that meets a certain character length has certain

things in it, and then on top of that, having MFA is MFA and a

strong password enough, or is there more needed? That

frequency of password change. Is really what I'm curious about

because I think you need to change your password every 30

days, or you need to change your password every X number of days

has diminished, and I want to know if that's true or if that's

a falsehood that's just getting perpetuated out there, and that

you should be changing password and have that MFA piece done.

So as much as I'd like to wave a magic wand and

make all the software that districts use single sign-on,

where there's a password that's managed in that way, that's not

happening. So if you think about it, 90% of the applications you

use are single sign-on, and that password rotation-let's say it's

once a year-that password rotation is fine. And in fact,

I'd even downgrade the MFA protected passwords and make

them simpler, make them fairly straightforward. And length

matters more than complexity, in my opinion. By the way, you

know, if it's a 14 character password, but you don't do the

crazy symbols, because all they're going to do is put $1

sign or a one at the end anyway. You know it. But here's the

problem I'm finding, and this happened with School Dude, so

School Dude got compromised, and again, clear text passwords were

stolen. And it was not at the time single sign-on. District

employees have a tendency to use, and school employees the

same username and password for all work things, and they'll

change it, and they change it everywhere that they use the

password. So I use J Smith, and I use Totem 223, and that gets

used everywhere. And the single sign-on systems, when I change

my password, let's say there's a compromise, you force folks to

change their password. It gets changed, but it doesn't get

changed in those things that are not managed by the single

sign-on. And as IT directors, we know some of the systems we have

aren't quite the single sign-on yet, whatever it is, HVAC, the

Access Badging system. I don't know what it is, but often there

are systems that are not single sign-on yet, and so I believe

you need to rotate passwords at least once a year, regardless of

MFA or not, because those passwords are reused elsewhere.

That's my argument. So I would suggest once a year, not every

30 days, but annually I think is important because single sign-on

and MFA is not in all the places.

Kevin Warenda, TLIS: Bill, it's worth noticing that NIST did

finally update their guidance on this topic. For a while, they

were stuck on the constant rotation, but finally realized

that you can rotate less often when there are additional

securing factors in place, and only change when there's

indicators of compromise or on a longer schedule. And that was

based on field work they did to say, yeah, what we're finding is

that kind of as April said, humans just put one extra

character at the end if there's no complexity requirement.

They're not making better passwords. They're more likely

to then write it down on a sticky note. So even NIST did

finally adjust their recommendations. But I think

April has a good balance there of still do it, especially if

there's an indicator of compromise. But I think what

April's pointing out is it's not that system that's actually the

issue. It's the reuse of that in other systems. If you're not

encouraging the use of a password manager, where you're

getting a unique password for every single different service,

which would obviously be the ideal, but not everyone's going

to do that. So I think that's good advice.

And I disagree with this. I think that you do

need to rotate at least once a year, and not just when it's

been compromised because of that fact that MFA really isn't in

all the places.

Kevin Warenda, TLIS: That's solid recommendation from the

field, from someone who's seen and talked to many districts

being compromised. That we'll take your word for that one for

sure. Are there any topics, programs, things that you wanted

the opportunity to talk about that we didn't ask about?

I would just say also look for cooperatives like

Waspsy in your region that can get you software and services,

whether it's cybersecurity services or some of the amazing

software tools out there for incident response or EDRs or

even managed service providers. I worry about the 24 by seven

problem. Most small orgs can't cover night, weekend, and

holidays when attacks happen, and the bad guys are even timing

nights, weekends, and holidays. So figure out how you can do

after hours response. And I strongly suggest folks think

about allowing their tools to automatically isolate either a

user or a machine. If it flags as compromised, shoot first, ask

questions later, check it in the morning. But you really need to

be thinking about isolating proactively, especially off

hours. But let the system isolate the user or the system

and follow up, rather than follow up, verify, and then

isolate. Because the bad guys are moving faster; they are AI

assisted, and if you leave that thing sitting for a whole spring

break, you may be in real trouble. So that's one of the

other things I want folks to think about: is being proactive

in those and look to your regional service agency, your

WISIPs of the world, for the tooling for that because they

often get amazing prices for that kind of stuff.

Kevin Warenda, TLIS: And it's a lot of great partners and

vendors. Work with the Atlas community, or the Atlas

community itself too, has a lot of that. So certainly, we are a

resource for independent schools to connect with those types of

vendors as well.

I want to thank April. As I mentioned before, we

came on every day. I've got emails, whether it's from K 12

six or CISO or our New Jersey cybersecurity cell, and it can

be drinking like a fire hose, and having her on to be able to

talk about some of these really practical pieces that we focus

in on really helps.

I'm really glad I made it to this episode because

the beach is calling my name, but this was definitely a

conversation that needed to be had, and I was grateful for the

opportunity to speak to you, April.

Kevin Warenda, TLIS: And I'll echo what Bill and Hiram said,

"Thank you, April, for joining us today. I think we'll maybe

wrap with a softball question: Is there a book or a podcast or

a white paper that you've read this summer or listened to that

you think is worth a share for our community?

I will have to say on the entertainment side of

things, because of the gaming influence, I'm enjoying the

Dungeon Crawler Carl series. It's giving me a perspective on

how to troubleshoot things in novel ways and thinking outside

the box. So, if you haven't already seen it, there's an

audio book and a regular book series that's becoming almost

viral, but it's worth a chance to step outside of yourself and

think outside the box, because some of the solutions that we're

asked to come up with, especially in small orgs, we

have to be really creative. And sometimes I need a little bit of

encouragement in that space.

Kevin Warenda, TLIS: I appreciate that, and thanks for

encouraging all of us, Bill Hiram. What's on your summer

reading list? Anything worth sharing? To be honest with you,

I'm just

getting back off of a two week break where I

did

absolutely nothing. I didn't even

read.

I just kind of like laid in the sun. Hiram, hopefully you're

going to get a bunch of that. My reading list consists of about

200 emails that have piled up over the course of the last two

weeks of being out.

I'm similar boat there, except I'm reading terms

of service agreements with different vendors.

Kevin Warenda, TLIS: All right, quite a lively bunch here.

April, thanks so much for joining us today and sharing

your expertise. If anyone wants to connect with you, what's the

best way to find you online or find what you're writing?

Catch me in LinkedIn and connect me there.

And then also anybody in the Washington areas, welcome to

ping me at cybersecurity at wasipsy. It's w sipc.org if they

want assistance in my state.

Kevin Warenda, TLIS: All right, thanks everyone for joining

another episode of Talking Technology with Atlas. See you

next time.

This has been Talk Technology with Atlas, produced

by the Association of Technology Leaders in independent schools.

For more information about Atlas and Atlas membership, please

visit theatlas.org. If you enjoyed this discussion, please

subscribe, leave a review, and share this podcast with your

colleagues in the independent school community. Thank you for

listening.