Episode 29 · · 36 min
Nick Vissari Engineering Dropout to Math Tutor to Security Architect/Engineer
Data architect and security manager at a large Maryland school district
Episode summary
Nick Vissari went from being an engineering dropout (he didn't like creative writing) to a tech consultant to a math tutor. His penchant for fixing things homed him back into tech, where he is now responsible for security in a large school district. He recently went back to school and received his cybersecurity degree as well.
Notes
At 10-years-old, his Dad had problems putting the computer together, so he helped his dad
Family never stifled any inquisitiveness he had
Started as a math tutor at the school system
How he initially had the wrong attitude in security
Quotes:
"Once you get into a position somewhere, do whatever you can to make yourself invaluable. Find the things people don't want to do and do them. The hard problems are the ones most rewarding."
"If you're not automating right now, it's probably because you have more resources than you know what to do with."
"There are a lot of people that are security professionals, but they really don’t know about how a system works."
"Just got to have that passion for wanting to learn and you can definitely jump into security."
"My grandmother always said: 'Those who don't make mistakes, don't do much.' So get out there a make a bunch of mistakes."
"Don't be that guy that says 'No' to everything."
Before infosec: Engineering school dropout, small-business IT owner and school math tutor
Chapters
- 0:00
Cold open and intro
Ayman previews Nick's tinkering, early honeypot and lessons on attitude.
- 1:27
Nick's role and early start with computers
He describes his Maryland school district role and building computers from age 10.
- 5:59
Engineering dropout, small business and a math tutor job
Nick left engineering, ran a small IT business and found his way into the school system.
- 8:46
What DevSecOps means
He explains cross-team collaboration, recommends The Phoenix Project and shares an sslstrip demo.
- 14:38
The Rube Goldberg email migration
Nick migrated 9,000 mailboxes by scraping a web interface with PHP.
- 18:06
Automation in school district security
He says automation and a custom identity management system define his day-to-day work.
- 19:32
Switching into security and imposter syndrome
A server job led to a security analyst role, and he advises on imposter syndrome.
- 22:27
Pop culture inspiration and scripting hacks
The movie The Net and an AutoIt-style script that pulled thousands of records.
- 25:12
Security culture: do not be the person who says no
Nick builds trust by solving problems first and then asking security questions.
- 27:28
Incident: direct deposit fraud in the ERP
Attackers changed payroll deposits and Nick added a second question and geo-IP blocking.
- 33:49
Parting advice: small incremental change
Make small changes, make mistakes and do not be afraid to break things legally.
- 35:10
Closing plug for Ayman's community
Ayman invites listeners to join the new community linked in the show notes.
Key takeaways
- Once you are in a role, make yourself invaluable by taking on the hard problems that others avoid.
- Be the person who says yes and asks questions, rather than the person who says no to everything.
- Automate repetitive work wherever possible, using scripting tools like PowerShell, PHP or AutoIt.
- Push for small incremental change, because people resist large monolithic plans.
- Do not let imposter syndrome stop you; passion to learn is the most important requirement for jumping into security.
- Make mistakes and break things safely and legally to learn how systems really work.
Notable quotes
Find the things that people don't want to do and do them because the hard problems are the ones that are the most rewarding.
if you have any kind of imposter syndrome, just know that there are people out there making a lot of money that really don't know about security either.
don't be that guy that just says no to everything
Questions answered in this episode
- How did Nick Vissari get into cybersecurity?
- Nick took a math tutor job at a school, began fixing broken computers and became a technician, then a server specialist. When the district wrote its first security policy he applied for a security analyst role, and he has been there 15 years.
- What is DevSecOps according to Nick Vissari?
- Nick describes DevOps as developers and operations learning each other's work so software runs reliably. DevSecOps adds security to that same pipeline so teams work on one shared solution instead of throwing work over the wall.
- Do you need a degree to work in cybersecurity?
- Nick had no degree when he moved into security and earned a cybersecurity degree later, which he calls just a piece of paper. He says street cred increasingly matters, and passion to learn is the key requirement.
Show notes and links
Show the original episode notes
Nick Vissari went from being an engineering dropout (he didn't like creative writing) to a tech consultant to a math tutor. His penchant for fixing things homed him back into tech, where he is now responsible for security in a large school district. He recently went back to school and received his cybersecurity degree as well.
Notes
- At 10-years-old, his Dad had problems putting the computer together, so he helped his dad
- Family never stifled any inquisitiveness he had
- Started as a math tutor at the school system
- How he initially had the wrong attitude in security
Quotes:
- "Once you get into a position somewhere, do whatever you can to make yourself invaluable. Find the things people don't want to do and do them. The hard problems are the ones most rewarding."
- "If you're not automating right now, it's probably because you have more resources than you know what to do with."
- "There are a lot of people that are security professionals, but they really don’t know about how a system works."
- "Just got to have that passion for wanting to learn and you can definitely jump into security."
- "My grandmother always said: 'Those who don't make mistakes, don't do much.' So get out there a make a bunch of mistakes."
- "Don't be that guy that says 'No' to everything."
Links
- Nick on Twitter: https://twitter.com/nickadam
- sslstrip by Moxie: https://github.com/moxie0/sslstrip
- Firesheep plugin: https://en.wikipedia.org/wiki/Firesheep
Getting Into Infosec
- Checkout My Book: Breaking IN: A Practical Guide to Starting a Career in Information Security: https://www.amazon.com/dp/B07N15GTPC/
- T-Shirts, Mugs, and more: https://gettingintoinfosec.com/shop/
- Sign up for sneak peeks, updates, and commentary: https://pages.gettingintoinfosec.com/subscribe
See omnystudio.com/listener for privacy information.
Mentioned in this episode:
Full transcript
Transcribed from the episode audio. Spoof ads (Ayman's parody commercials poking fun at the industry) are marked.Download .txt
Do whatever you can to make yourself invaluable. Find the things that people don't want to do and do them because the hard problems are the ones that are the most rewarding.
Welcome to Getting Interned for Sec. I'm your host, Ayman Elsawah. My guest this week is Nick Visari. Nick is the main person responsible for security at a very large school district. Earlier in life, Nick was never satisfied with the status quo.
I remember my creative writing teacher, she had this assignment where you had to complete a statement in some poetic way, and it was like, the sun burns. And my response was, the sun burns is a false statement. It's fusion.
A tinkerer, Nick wanted to see security in action firsthand.
I would leave my horribly unpatched system online overnight and I would just connect it to the internet and just leave it there. And then the next morning I'd wake up and I'd say, okay, who did what to my machine, right?
He also shares with us some incredible wisdom he has learned over the years from others as well as from his own career evolution as well.
I used to kind of hide behind my email a lot and I would send people a lot of emails and just say, okay, good, I've got the documentation. I was that guy that had my binder full of possible solutions and I would just say, oh, we need this and we need that. If we don't have the budget and we don't have the tools, then we're never going to have these things. And that was just the wrong attitude.
Man, Nick really knows how to put it well. All right. On to the show.
Hey, Nick. Welcome to the show. Hey, Eamon. How are you? Good. How are you doing? Fantastic.
Awesome. Well, so Nick, maybe you could let folks know what you do today in security world.
Sure. So my name is Nick Visseri. My official title is data architect and security manager, and I work for a large school district in Maryland. We have 60,000 students, 12,000 staff, about 80 sites, and 30,000 devices that I have to take care of.
Wow, that's like a large enterprise, basically.
Yeah, it's a lot of fun. And I'm the only designated security person for the school system. And I just love my job. I really have a lot of fun every day trying to come up with really unique and inexpensive solutions.
Okay. And how did you get involved in the security role for that?
So before I got into security, I was a computer technician and I was kind of delving into managing servers. And the school system hired a manager for the server team. And at the time there was like two people on the server team that really weren't interested in managing servers. So I ended up kind of inheriting that role as a technician and I really enjoyed it a lot. And it was very hacky, kind of like allowed me to exploit a lot of the skills that I had acquired just by being a dumb teenager playing around on the internet. Okay.
Let's talk about that a little bit. How did you build those skills when you were younger or just get into technology when you were younger?
Yeah, so the big change for me was, I guess I'd always been interested in computers from like just pop culture and sci-fi and different things that I'd read or whatever. And my dad was actually building a computer when I was about 10 years old. We had some IBM green screen machine that was, you know, it was fun to play around with, but it really wasn't like a modern computer. So anyway, he was building something that actually ran like DOS and had VGA graphics and it was really cool. And I was really anxious. I was like, oh, when's it going to get done? Did you buy all the parts yet? And he was having a lot of trouble with it. So he had this thick book that he was using to figure out how to put it all together.
And he just handed it to me. He said, well, here, you know, you're home all day. You read it. Yeah. Awesome. I read this book in a couple of days and I came downstairs to take a look, you know, and I said, oh, look, you got the cable flipped around for the hard drive. And I turned it around. That was back in the old 40 pin days where you could actually flip them over. Right.
Yeah.
Yeah. So that's kind of what got me started with computers. And then from there, my family had really been very, well, they hadn't stifled any kind of inquisitiveness that I had. So if I wanted to do something, they didn't stop me. So I wanted to be an electronic engineer. That's what I went to school for. And at like 12 years old, I had a workbench and I had just components just all over the place. At 12 years old? Yeah. I'd harvested a bunch of components from a bunch of broken stuff that people would just throw out. I don't know if you ever had these, but like RadioShack, they used to sell these like 301 kits.
Yeah.
Which was really just a bunch of components on springs. And there was a nice big fat book in there of circuits. So that's kind of where I got a lot of the initial passion for electronics. And from there, it kind of evolved into the things that you put together in a circuit is a lot similar to putting together software. Yeah. Rather than dealing with different voltages and simple signals, you're now dealing with strings and, you know, authentication and just similar kind of situations. Yeah, that's amazing. And input output, right? That's right.
Yeah, that's awesome. And so having that computer really kind of helped kickstart your curiosity, I guess, for technology.
Yeah. Actually, when I was young, I purchased my own phone line so that I could have dial up all the time.
Oh, nice. Yeah.
And one of the things that I did was I would leave my horribly unpatched system online overnight and I would just connect it to the Internet and just leave it there. And then the next morning I'd wake up and I'd say, OK, who did what to my machine? Right. Oh, you did it on purpose. Oh, yeah. Yeah. OK. It was like a little honeypot. Right. But it was also a learning experience for me to see, like, what kind of cool viruses I could capture from the Internet.
Mm hmm.
And then I would just wipe it out and start over again. So it was a lot of fun. I mean, now I wouldn't recommend anybody do that now, but back then it was a little bit less dangerous to do stuff like that.
What was the most interesting quote-unquote virus that your computer found out?
Oh, I really enjoyed the registry hacks where people would change what Windows would do to an executable. Like if you launched an executable, it would hook another program.
Mm-hmm.
So that was my favorite kind of technique that came from that. And I remember years later reading an article about this is some kind of horrible thing and it's revolutionary. It's really hard to beat. And I'm like, well, that's been happening for years. I saw that on my dial-up machine ages ago.
Yeah, that's amazing. So fast forwarding into the future, did you go to school in computer science? How did you get your first tech job?
Yeah, so I went to school for electronic engineering, and I dropped out because I just couldn't handle some of the garbage that you have to do when you're just getting through a program. So I really did not enjoy creative writing at all. I remember my creative writing teacher, she had this assignment where you had to complete a statement in some poetic way, and it was like, the sun burns. And my response was, the sun burns is a false statement. It's fusion. Yeah. Awesome. Awesome. Yeah. She did not like that.
That is hilarious.
Yeah. Actually, I just got back into school. I graduated back in March. So that was just a few months ago.
Oh, congratulations.
Yeah. So now I have an actual bachelor's degree in cybersecurity. Okay. But that's really just a piece of paper. I've just always kind of thought, oh, I need to get this someday. And someday has finally come.
Okay. And so when you dropped out of engineering, did you just... You just went to work. What did you end up doing during that time?
For a little while, I had my own business. It was a small business that helped other small businesses with computer problems. Okay. And I was living with my girlfriend, now my wife, and I didn't really like doing the small business stuff. I really hated trying to chase people down, people that don't pay their bills, and doing the whole contract negotiation part just wasn't for me.
Oh, yeah.
Mm-hmm. So she suggested just get some job in the school system because it's a great place to work. They have fantastic health benefits. And, you know, once you get your foot in the door, you'll just work your way up. So I said, OK, you know, I'll find something. I found a math tutor position at a middle school that was like just as entry level as you can get. And I was like, well, I like math, so why not? So I took that job. And as I was there, I saw a bunch of broken machines laying around. You know, there's all these open tickets and they would put little post-its on the computers that said like, oh, this computer is sick. Like nobody can use it right now. And so I just started walking around going, well, what's wrong with them?
You know, so I power them up and take a look at them. And I started fixing them and closing out these tickets. And the computer technician that was assigned to the school, she was on like one week rotation or something like that. She's like, well, who has been closing out all of these tickets? You know?
Yeah.
And so the person who was managing that introduced me and she said, you have to come work for us. So I didn't have that math job very long. And then I went to be a computer technician. And sure enough, my wife was right. She said, just get your foot in the door and you'll work your way up. So I've been there ever since. Since then, I've been there for 15 years now. Pretty cool. It's been pretty awesome.
So you saw a problem and decided to fix it, right? Nobody told you to go ahead and do it.
Yeah. Yeah. That's kind of always my dad a long time ago. He said, once you get into a position somewhere, just do whatever you can to make yourself invaluable. Find the things that people don't want to do and do them because the hard problems are the ones that are the most rewarding. Wow.
Yeah, that is great. Very good wisdom. That's awesome. And so now fast forwarding, you're kind of doing DevSecOps, right? Maybe explain to the audience what DevSecOps is exactly.
Sure. So, I mean, I can tell you kind of what, from my perspective, what DevSecOps is. Yeah, of course. Because there are so many different interpretations of what it means. Thank you for that. Yeah. That is true. Yeah.
Sure.
Yeah. From my perspective, we'll just talk about DevOps in general before we throw the security in there. Yeah. DevOps is really kind of this evolution of development where you started with this time when you would have developers and they would make a piece of software and they'd kind of chuck it over the wall to a bunch of operations folks. And the operations folks, they try and figure out how to get it to run in production. And that's where a lot of tension, a lot of chafe lines would occur because, you know, hey, it works on my laptop. And they're saying, yeah, but your laptop isn't anywhere near production and you're horribly insecure and blah, blah, blah. And there's just a bunch of finger pointing going on.
Yeah.
So DevOps, it's easy to kind of think of it as a suite of tools because there are so many tools that help you achieve these goals, but it's really about developers accepting the operations side of the house and operations accepting some of the development side of the house. So it's this, what I like to call a cross-mogenization approach. Of different departments. So they learn about each other's stuff. And it's really about maintaining interfaces between systems and departments. So as an operations side of the house, they'll say, well, you know, we have Docker. And if you can run it in a Docker container, then that's fine. We can get it running in production. It's not really all that new because the same kind of happened with like Java, right?
If it worked in Java, then we can get it to work in production. That was kind of Java's big thing.
Yeah.
Is you could write once and run anywhere. So anyhow, it's really just about the different sides of the house learning each other's trade. And security, of course, now gets infused into that. Mm-hmm. Where people are used to writing software and they're used to now writing it in a specific type of environment so that they'll know with some confidence that it runs in production. But is it secure? So how do we infuse security into that same development pipeline? And we can use automated tools to do that, but it's really, again, just that cross-mogenization. I have to talk to the operations people about security. They got to talk to me about the operations stuff and vice versa for development. So we can all kind of contribute to the same problem or contribute to the same solution, I should say.
Yeah. Because at the end of the day, we're all trying to solve the same problem.
Yeah, I guess maybe a little historical context is before security used to be telling folks, hey, this is what you need to do to secure XYZ. Where now in the DevSecOps model, they need to be part of the solution. Would you say that's correct?
Yeah, yeah, absolutely. And meeting with them, I used to kind of hide behind my email a lot. And I would send people out emails and just say, okay, good. I've got the documentation. I was that guy that had my binder full of possible solutions. And I would just say, oh, we need this. And we need that. If we don't have the budget and we don't have the tools, then we're never going to have these things. And that was just the wrong attitude, you know? So I've read a couple of books about DevOps that I recommend. The primary one would be The Phoenix Project. That's a fantastic book. And it's not really about security. The guy that wrote it, he's very much into security. But the security kind of ends up as a small chapter towards the end.
I see. Which I think is pretty funny. But regardless, it's a really good book. It steered me in a different direction. It solidified some of the things that I had learned trying to implement security in different areas of the house and the operations side of the house and the development side of the house. Okay. It really doesn't work if you just come down with regulation and say, well, you must do it this way. You know, you really have to be part of the solution. You have to walk them through it and show them why it's a problem. I remember when SSL stripped a really cool tool, Moxie Marlinspike came out and what was that other tool? It was the plugin for Firefox. It was really when SSL started to become like the standard where everybody said, well, you have to be SSL by default.
Fire Sheep. Fire Sheep. Okay, cool. So I remember when SSL strip had just come out and I was trying to explain to people that you really have to have SSL on by default. You can't have this port 80 redirect to go from unsecured to a secure connection because someone could just sit in the middle and downgrade the connection back to HTTP.
Yeah.
And i had a boss at the time he was a gray beard and he was like oh that's nonsense it's never gonna happen i said okay well that's fine you know so i fired it up and i said go ahead type in your password and he's sitting on the gmail login page and just like everyone else he didn't bother to check to see whether it was a secured page so he typed in his credentials and i said well there you go there's your password and he said oh my gosh i'll be damned you know yeah And after that time, like we had turned off port 80 on almost everything. Right. This was before HSTS had come out. Yeah. So there really wasn't a good way to prevent somebody from having an in the clear connection.
Yeah. What do you think about HSTS? I like it, but I think the industry has started moving away from it because of deployment problems. Yeah.
Yeah, so with HSTS, that's a pretty good example. You know, DevOps now all have to kind of gel well together because HSTS will work perfectly if your development team knows about it, right? If there is some type of a redirect that relies on it going back to an unencrypted channel, then HSTS is never going to work. Yeah, that's true. So because your browser will throw an error and the developers have to realize that like their connection needs to be encrypted all the time. I mean, it can be unencrypted the first time.
Yeah.
That somebody goes to it but after that it has to accept encrypted connections yeah and the real trouble with it is that software is always changing so you might have it working one day and then some patch comes out that fixes a problem and all of a sudden it breaks hsts because hsts becomes this edge case that barely gets tested so that's part of why you really have to have you know a development pipeline that includes testing and testing all these edge cases and So that whenever the new version does come out, you can say, oh, no, it's not my deployment that's broken. It's your implementation, right? You're supposed to be supporting HSTS and you dropped support for HSTS and you didn't put that in your release notes.
Yeah. Cool. So any interesting stories in your days of security?
Okay. So one of the nicknames that I've acquired is Rube Goldberg, which originally it was meant to be a kind of an insult because some of the solutions that I proposed just seemed to be really backwards and hacky. But I took it as a badge of courage because the problems that were coming up were really from the professionals, quote professionals, they were just unsolvable problems. It was just impossible, right, to solve these things. And I said, well, no, it's not impossible. If we really contort your mind and you can come up with a solution, it might not sound very clean, but it works, right? And one of the Rube Goldberg solutions that I'm pretty proud of was we were migrating email providers.
So we had an old email provider that was really kind of off the wall, just weird. It was a client server architecture. So people actually had to install a client and to get to kind of the email, but the email, it really wasn't like an email system. It was more like a wiki. Okay. Where there was a folder for your email. It was really a bizarre system. But the school system had it for years and everybody was used to it by now. Everybody enjoyed it. And we were switching to Exchange. So we had hired some vendors to come in and propose a solution. And there was only one vendor that actually said that they had a solution to migrate. And it was the vendor that we were working with to kind of support the software.
So we already had a relationship with them. So they came in and they fired up their solution and it was just abhorrently slow. It just was never going to work. It took hours to migrate a single mailbox and the solution was single threaded. So we had at the time 9,000 mailboxes to move and it was just going to take years to get everything migrated. Wow. So we went back out and we asked a bunch of people, nobody would come up with a solution for this thing. And I was just sitting there thinking like, I'm kind of mulling over the problem as well. I'm like, I don't know how we can get this mail migrated. And then it dawned on me that they actually have like a web interface where you can check your mail.
And I just thought, well, I mean, I know how to scrape web pages and of course the web interface is meant to run in parallel. So I wonder how fast we can do this if we did it over the web.
Oh, that's hilarious. Yeah.
Yeah, so, and I had like read a book years back about PHP. So I thought, well, you know, it's not really the best scripting language, but I know how to use PHP. I'm comfortable with it. So I'll just see what I can put together with PHP script. So I wrote something and I was able to get a mailbox migrated in six minutes. And of course, because it was over HTTP, it could be as parallel as I wanted it to be. I could just keep on spinning up more servers because they're just web servers. You know, they're not like this weird client server architecture where you can only have one session.
Mm-hmm.
So it worked really well. It took me about six months to get everybody migrated. And that was like, you know, working overnight, calling up a location saying, okay, you're going to be migrated on this day. And it was a huge coordinated effort. I mean, it worked great and everybody was pretty happy with the solution. I can't say it was like perfect on the first go, which is also part of the DevOps culture is that you have to kind of get started with something that mostly works. And then as the requirements come, you just be nimble and be able to change them. So the first couple of locations, they said, oh, we got problems. Like, you know, I think one of the problems was people expected their mail to be unread from like ages ago.
And I was like, that's really weird, but OK, we'll figure out how to support that. So I put a flag on there to make sure that if the message was unread, it stayed unread. Wow. Yeah. It was some fun times. So, and that was a pretty big Rube Goldberg solution. Yeah. It worked out really well and people were really happy with it. Wow.
That's pretty good.
Yeah.
Cool. Nice. So tell me about managing security in a school district. So how do you deal with either just managing things day to day from an internal perspective or restricting access to certain websites?
How does that work? So it's really all about automation. I mean, you've got to automate as much as possible. And I wouldn't say that's necessarily most important for school systems, because if you're not automating things right now, it's probably because you have more resources than you know what to do with. So you just have people do jobs that really could be automated. And sometimes I find point product that they really should be automated. But there's just enough of an interface that somebody has to log in and click something. And you're kind of looking at it like, well, why? Like, why isn't it just fully automated? And then you start asking about APIs and things like that. So for my day-to-day is really just what can I automate?
The biggest kind of daily interaction that I have is with the identity management system. So that has been fully automated for, geez, probably about 10 years now. Mm-hmm. And it's on a custom solution that I wrote and I currently maintain. I've been working with other people to try and get them to migrate over to the operations department and say, hey, it's just a PowerShell script. I'm sure you guys can learn a thing or two about PowerShell. I'll be your SME and, you know, we can really kind of get this thing off the ground or at least in your wheelhouse. So that's been a lot of fun. So I spent a lot of time kind of mentoring them and teaching about how to maintain that system and improve it because there's always new requirements coming.
Okay. And, you know, I don't think we actually got to talk about it, but how did you actually switch into security? You started off in, I guess, in IT, but then how did you transition into security like officially?
Sure. So I had a pretty good mentor at the school system and he had hired this server team. So I applied for the position as just a server support specialist because I didn't have a degree. I really couldn't get a better position than that.
Was that because of requirements?
It was really just because of the norm of, you know, if you're going to have a security professional, they really have to have a degree at the time. I think that's kind of dwindling a little bit where, you know, you don't necessarily have to have a degree. If you have street cred, that'll pass. But yeah, at the time, it was just like any kind of security position was just not going to happen. So I got the job as a server specialist, and we had deployed a couple hundred servers during a pretty short timeframe. It was about a year and a half. Mm-hmm. And that worked out really well. And we were done with that project. So it was just kind of a maintenance at that point. It was keep Active Directory running, keep all the file shares running.
So it was really boring for me. And the next kind of thing that was coming around the corner was security policy. So as a school system, you know, we didn't have a security policy and we were just kind of looking at like what the state had as a security policy. So that was a new initiative, was that we were going to have a security policy. We were actually going to put down some requirements and then start holding people to it. So another position was made available as a security analyst, and I applied for it and got it. That's mostly through my experience. I knew everything about how the systems were deployed and all the vulnerabilities that were there. Some of them I might have put there myself.
By accident? Yeah, right. Wink, wink. Yeah. So yeah, I got the position as a security analyst and just huge imposter syndrome after that. I think everybody kind of gets imposter syndrome when they first get into security. And that abates as you learn about others in the security field. I talk to a lot of people that are Really just kind of security on paper. They're more about audits and what kind of audit requirements are there with not a whole lot of understanding of the system and the vulnerabilities themselves. And I always look at that as being like a kind of a personal barrier that people just put up for themselves. I think I hear a lot of people say like, oh, I don't know about computers or I don't know about this or I don't know about
That. And it's like, well, when you put that barrier up that you just say like, you don't know about it. Yeah. I mean, of course you don't know about it, but you can look, you know, you can read about it. It's not like it's unattainable knowledge. And there are a lot of people that are, they're security professionals, but they really don't know about how a system works and how a vulnerability works, how an exploit works. And so, you know, if you have any kind of imposter syndrome, just know that there are people out there making a lot of money that really don't know about security either. Gotcha.
Gotcha.
And you really just have to have that passion to want to learn and you can definitely jump into security. That's really the most important thing.
Yeah. And what made you want to go for the security position?
Oh, I think it was probably pop culture and sci-fi. I remember the movie, The Net, Sandra Bullock. Okay. I really love that movie. I love like, I remember watching it for the first time being like, wow, she's ordering a pizza on her computer. Yeah. It's really cool. And then, of course, they ruined her life just by, you know, making some changes and some databases somewhere. And it was like, that's amazing. You know, it's really cool. So that was one of the things that really got me kind of turned on to security. I've just always enjoyed, you know, this kind of hacky stuff, mostly for utility, but also just kind of novelty, right? It's like seeing what somebody can do with a system and it's really not supposed to do it.
So that's kind of what got me started with security or really interested in security, I should say.
Do you have an example of a life hack maybe that you did from your inner years? It could be a technical or non-technical, but just kind of a life hack that you used to get out of a situation or improve a situation. Yeah, I know something. Okay.
There was this user interface that required lots of clicks to get through. Okay. And it was just some automated process of, you know, let me click and right click edits and then hit space a few times and type some numbers. Right. And then move on to the next one, increment the digit, move on to the next one, do the same thing, type a few other numbers. So that was like my introduction to or when I saw that problem, I looked at auto it or auto hotkey. It was one of the other. I can't remember which one. Yeah. But when I found that on the internet, I was like, oh, this is perfect. Like I can automate key clicks. So I wrote just a simple little tiny script that just did that one thing for me where I could just type a hot key and then it would run a string of characters.
And I used that for a lot of little stuff. And then I had something like really important that had the same type of flavor where it was like, we really have to get this data off the system. And all it is, is a bunch of clicks and a GUI and it's old archaic system that nobody understands the backend to. And we know it's an Oracle database, but nobody has the schema for it. They can't really reverse engineer this whole application. So I applied the same solution. It was just like a GUI click and, you know, it would click on a certain field and it would take a screenshot and then it would compare the MD5 of the two screenshots to say, oh, has this little square of the screen, has it changed from what it was before to what it is now?
And Anyway, it was fantastic. Like I put all that together and the application ran for like three weeks and it pulled down thousands of records off of this system. That to me was like, wow, like even something from ages ago where I just did it to organize my music collection. Now I can apply this to like a real concrete problem that somebody's having that's costing them like $30,000 a year. That's really awesome.
Just putting your mind to something, right? Getting it done.
Yeah, a lot of it just comes from experience. I know my grandmother always said, those who don't make mistakes don't do much. So get out there and make a bunch of mistakes.
There you go. That's awesome. I wanted to track a little bit and kind of talk about, I guess, how you handle security from a culture perspective, either in your day-to-day job. How do you teach security culture at your school or the district? It's just you, it seems, at least the main security advocate. How do you deal with people who want to just block all the things, right? Or handling that, how do you deal with that?
Yeah, so I think the most important thing is to first don't be that guy that just says no to everything, right? You have to be somebody that says yes and or yes, have you considered and really be engaging and helpful because nobody wants to go to the person that they know they're just going to come back and say, oh, no, you can't do that. It's risky. Yeah. Well, of course, it's risky. Everything is risky. The question is, how risky is it? Right. So you really have to be the person that is approachable. And I've become approachable by just helping people solve their problems. That's where I started, you know, as a technician and moving up through a server support person. It's just I'm always solving people's problems.
So they just come to me and they say, hey, I have this problem. And as they're describing their problem to me, I'm like, I've got this little tally list in my head of like, oh, yeah, that could be exploited. Oh, boy, I wonder how you're handling passwords here. Oh, geez. And I just keep those in the back of my mind. I don't stop them. I let them continue. I let them play out the whole thing. And then I'll say, OK, cool. First, let's solve your problem, you know, blah, blah, blah, whatever it is. And then as we're doing that, have you considered like how are you handling out these passwords? You know, and I'll just ask questions like that. And it gets us on the same page, right? They're getting what they want by me helping them solve a problem.
But also I'm getting what I want by implementing security or trying to inject security into the system. And it's worked out really well for me because I've seen the other side. I've seen where people just say, oh, no, you know, you can't do that. It's impossible that we could allow NTP out of our network because I've heard that it could be hacked. Yeah. It's like, of course, yeah, it could be hacked. But how risky is it?
Right. That's awesome. I couldn't have said it better. That's really good. Just to the last part, like threat modeling, right?
No, you're right. It is threat modeling. It's just I don't go through the formalities of writing it down as a threat model, which is probably some of my failings on my side because when the auditors come around and they ask, hey, do you do these things? It's like, yeah, we do. But unfortunately, I didn't bother to write any of it down. So I guess I'll make a note for next year.
Well, no, I mean, you are threat modeling in the sense that what you just said about blocking NTP blindly because I've heard, et cetera, et cetera. Right, right. But for your environment, does that apply to your environment, right? Yeah, you're right. Yeah. Cool, man. So do you have any juicy incidents that you can talk about anonymously? I mean, we all know where you work, so I know that limits it. But any incidents from the past, security incidents that... Sure. Yeah.
One big incident that we had a few years ago, I think a lot of people have experienced this because the FBI actually published a notice about it, but there's this, I mean, everybody knows about business email compromise, right? The phish email will go out and they'll get your credentials. And what we were seeing a lot was like, yeah, they would get the credentials and then they would take over your email and they would just start spamming other people. And we were like, okay, yeah, that's really bad. We'll go around and shut them. And there's even some automated tools that prevent that from happening, right? They see a flood of outbound email, they'll just shut the account down for you. And that was kind of the way that we were handling them for a while until all of a sudden we found out like, hey, a bunch of people didn't get paid one pay period.
And we're looking at this problem like, well, what's going on? And it turned out that a whole bunch of people had their direct deposit modified in our ERP. So looking at that problem, I was like, oh, this is different. I haven't seen this before. And thankfully, like when the attacker had gotten in and started changing the direct deposit information, we were already in the midst of a payroll run. So I think that there were 15 or so accounts that were changed, but only six or seven of them actually applied before the payroll run had actually occurred. So it was just like a timing thing that it didn't turn out as bad as it could. Wow. I mean, it was still pretty small numbers, but just the fact that occurred, it was fascinating to me because I had never thought like, oh yeah, like you could just go change the direct deposit on somebody's ERP login.
Wow.
And so they were moved to different accounts, right?
Yeah, yeah. The direct deposit money was moved to a different account. Exactly. Wow. So, you know, we lost a little bit of money from that. And even then, I think insurance had taken care of it or something like that. It wasn't a whole lot of money. But there was the question of what do we do about this now? Like, what kind of solution can we actually apply to this problem? And the ERP system has a single sign-on component, which I maintain. And the ERP system is a SaaS solution. We really can't do anything to modify it. And the solution didn't have real time logging that we could really kind of respond to an attack that was already in progress. So I was really left with this like, well, what do we do here?
So I could get the authentication side because of single sign on. And I thought, well, you know, I can't do multi-factor authentication. I just know I can't. Not enough of our people have devices and I can't really force them to use a device. And we don't have the money to purchase fob keys for everybody. So, you know, what can we do?
You couldn't implement it through even SMS or even Google?
Well, if I did, there would be significant resistance. And that was really the problem. I know that there's enough people that would say, I shouldn't have to use my cell phone to log into a system. I shouldn't have to use my cell phone or my cell carrier or my text messaging or whatever. You have to provide everything that I need in order to use the system. So I just thought, is there a solution that we could come up with where there wouldn't be so much resistance? And it's not multi-factor authentication, but it's just a second something you know. So the first something you know is your password. And then if it is a computer that I've not seen before or a browser that I've not seen before, all of a sudden you get this second question posed, right?
Of some question and answer that you choose. And you've probably seen these in like your bank. Your bank probably has one. My bank had one, but they got rid of it, which I think is kind of interesting. But yeah, so if I've never seen your browser before, you have to answer a security question. So we put that in place and knock on wood, we haven't had that type of attack. And I can't imagine that people haven't gotten into the ERP system since then. Because, of course, there's been credential compromise since then. And they probably did log into the ERP system, but they just got hit with a second question and then they just move on from there. So it's that old adage that, you know, you don't really have to outrun the bear.
You just have to outrun your friend.
Gotcha. That's funny. And then would you add some sort of like detection system to look for logins from IPs that were never like, you know, is there anyone?
Yeah. So there was a solution that was put in place kind of immediately after the attack where we were actually looking at the source IP address and seeing, okay, what geolocation is associated with this? And if it wasn't anything within the region, we just dropped the connection. And we sent out a notice and said, okay, if you're traveling, you're not going to be able to get on the ERP system.
Oh, cool.
And we can do that because we're local and we kind of make sure that everybody that works for us is also local. They have to drive to their location every day. But I know that's not the case for some. If you have remote workers, that's not a real solution for you. Plus, if we supported IPv6, which maybe someday we might, I don't know, maybe never. That wouldn't be a solution either. So it was in place. And actually later it came back to bite me because I was chasing after this problem. I was like, why can't people log in? Like, what is wrong with this thing? And I was like, oh, it's because I put that thing on and I forgot about it like ages ago. Wow.
And it's really interesting to see in the private sector, it's totally fine to use your personal device for like second factor. But the different mentality, I guess, of a government institution, we're like, hey, I'm not going to use this for, you know, you have to provide everything. The different things. I think we've only scratched the surface about security life in the school district versus private sector.
Well, I also think some of it is balancing. I can't think of a nice PC way to say this, but there are people that just love to be resistant. Where if they see that there is some challenge that they can say, oh, you know, here's the thing. This is how they're going to get us, right? They're going to be resistant to that. So they're just constantly looking for those issues that they can bring up. And that's the kind of thing you have to respect that they're coming from a certain position where like, that's how they've gone through life, right? They've gotten to this point where they are now by being this way. So you kind of have to respect that. I remember a long time ago, I was talking to a teacher who was really interested in having her classroom set up a specific way.
And I mean, it was about something completely inconsequential, but it turned out she was like a flower child from like the 60s. And she was just always about fighting the man, you know? So anything that come up that was a problem, she was like, oh, it's the man again, you know? Gotcha, yeah. So I kind of had to respect like, okay, yeah, you know, we're not the man. We're not trying to get you or anything like that. You know, you kind of have to come to some middle ground. And that's really challenging to find that middle ground.
It is. That is exactly right. Cool. Well, Nick, thank you so much for your time. Any advice for folks out there looking to get in security? What are your parting words?
Well, there is only small incremental change and elaborately planned failures. So make small incremental change. Don't plan a lot. You can plan a little, but don't plan a lot.
So when you're trying to implement change, you want to come up with a plan. You know, you want to say, okay, we're at this point in our journey and we want to be at this part way out in the future, right? Like five years from now, we're going to have all this amazing stuff. Well, you can plan a little bit of that, but if you start getting lost in the minutia and you start making these really big elaborate plans, you're going to fail. The only kind of change that you can affect is small incremental change. People can accept small incremental change. They can't accept big monolithic changes. You'll just have so much resistance and it'll be a failure. You might still call it a success, but there'll be a lot of angry people.
And what about advice for folks looking to get into the security industry? What advice do you have for them?
Just go out there and make a lot of mistakes. Don't be afraid to break things. Cool. Without breaking the law, of course.
Yeah, of course.
Cool. Well, Nick, thank you for your time today. It's been really enlightening and I look forward to meeting in person one day.
Awesome. Thanks, Eamon. All right. Thank you.
Hey, thanks for listening. So I built a lot of things and I'm building something new. I'm working on a new community. I want to bring everyone together with all the things that I've done into just one space. So I'm really excited about it and would love to stay in touch and get some early adopters or feedback. So check out the link below in the show notes and send me a hello. And that's about it. I hope you're having a wonderful day. Thanks. Talk to you soon. Thank you.
