This past week, I got the chance to catch up with an old teammate of mine, Page Glave.
We spent about three years together on a Detection and Incident Response team, where we built out the tooling that helped our small team scale alongside a rapidly growing organization.
In this chat, we dive into why technical solutions are often the best move for security teams, how Page made a successful career pivot, and what it really takes to break into cybersecurity - regardless of your background.
Here’s my conversation with Page.
Who are you and what do you do?
Hey, I'm Page Glave and I am a Security Engineer focused mostly on detection engineering, along with incident response threat hunting. I came into the field from academia and I've been in the space for about six years now. I find the detection engineering area to be really fascinating because you get to do a little bit of everything.
What made you switch from academia to cybersecurity?
So I did the whole grad school thing - I went to college for 11 years.
It's one of those Tommy boy moments where it's like, yeah, lots of people go to school for that long. They're called doctors. And I'm a doctor - just not that kind of doctor.
They paid me to go to school, so I kept going. Got a tenure track job and did that for about nine years and felt like I did about all that you can do there - I played the game and won. And at that point I asked myself, "What does the next 30 years look like?"
I realized if I stay, it's going to be more of exactly the same: Teach the classes. Make sure you get good enough evaluations. Do the research that'll get published. Get funding. Do all the things that I've already done.
The thought of doing that for another 30 years was incredibly unappealing. I was bored. And sometimes I do crazy things when I get bored.
In addition to my PhD, I also earned a graduate certificate in statistics - so I knew I like stats. I thought of doing a second PhD in statistics (because I am that big of a nerd) and looked at data analytics. But it was way more statistics than I wanted to do.
But I knew I also liked tech. I took a Visual Basic class when Visual Basic and Java and COBOL were the things to take as a PE major. Cybersecurity was really starting to blow up at that point, and the more I looked into it, I realized there's just so much you can do. I also knew that in tech, if I ever did get bored, I could always pivot.
So I ended up kind of having a foot in both worlds for a while. I kept my job but also started networking. In a way, I OSINTed my way into InfoSec by going to the Splunk user groups, conferences, meetups.
I started applying to roles once I got Sec+ and felt like I had built a good enough foundation to make the change.
I ended up going to a K-12, which to me seemed like a good fit because I understood how school districts work. And that made it a really good combination, because I could take what I knew about academia and was learning about cybersecurity and apply it.
It was a very intense self-teaching moment, but it's worked out pretty well for me.
RYAN: I think what's amazing about your story, and something I've seen a lot in friends of mine, is people will be so unhappy in a career. But then they'll just say to themselves, "I've already been doing this for five or ten years, it's too late for me now, I can't switch." And you went from one career to a complete polar opposite. Self-taught, didn't make any excuses even with a family, and still found the time. It goes to show that if you want something bad enough, you can do it.
I won't even pretend like there wasn't a lot of luck and fortuitous timing involved, but I worked my ass off too. Knowing I had to be able to make enough to support my family, I had to have certain criteria met. I was strategic about what I learned and how I networked.
It's still an insane pivot, but it was a good decision for me.
As a specialist in Detection Engineering and Incident Response, what does your day-to-day look like?
My day-to-day has looked very similar now across several jobs, because where I've been, we never had a separate SOC.
So, triaging overnight alerts is always the first thing. I flag the things that I went to either a threat hunt on, tune, or dive deeper into. From there, I'll check email/Slack to see if there's any red flags.
I think as a detection engineer, one of the most valuable things you can do is stick your nose in a lot of places where it may or may not belong. That's looking at dev channels, other engineering threads - taking a quick look at adjacent department channels checking for availability alerts, new features, or just getting an idea of what's going on in the organization.
But usually the first hour of my day is situational awareness - a lot of the TL;DR newsletters, DevOps, AI, and CyberSec news. My goal is to look for anything trending that I need to be aware of (unless it turns into triage).
From there, I block off two to three hours for deep work, whether that is building out SIEM, infrastructure, or professional development.
Early morning is often the best time because once everybody starts coming online, you often get pulled into other things. But I try to block off at least two chunks a day for deep work so that I'm not scattered and can get meaningful work done.
One of the things I like to do towards the end of the day is have a chunk of time set aside to recheck alerts and any service requests that come in, like detection tickets, tuning tickets, or IT/DevOps work.
I finish my day by spending 5-10 minutes minimum taking some notes on what I did that day. One of the things I started doing in grad school was updating my CV monthly because you forget. And having a daily log is really big, not just for your resume but for your performance evaluations. Especially with the state of the industry right now, all of us need to do a better job tracking the value that we're bringing. That daily wrap up is really important, and also helps you set in place what you're going to do tomorrow.
Or, it can all go to hell and end up being an incident response day - but that's the world we live in.
- Today’s Sponsor -
Selecty is a database-agnostic, sidecar query assistant - built to integrate seamlessly into your workflow without dulling your edge. Generate smart, contextual queries, optimize them to your use case, break them down into plain English, and debug faster than ever - all in one sleek interface. Check it out!
Tell us about your tech stack
My general tech stack is honestly employer agnostic because it's what I want to use.
For the cloud provider, it's probably going to be AWS because that's what everybody uses, and Terraform with that. I'm not opposed to OpenTofu, but I'm also starting to use Terragrunt a little bit to manage stacks, which is a really cool tool for referencing other stacks, reducing redundancy, and pulling in infrastructure from other areas so I don't have to run as many applies.
From a language perspective, Python and SQL are my main two.
The SIEM of choice for me is Panther - which should be no surprise to anybody who has followed me for any length of time.
My dream stack would be putting Panther and Scanner.dev together. They complement each other incredibly well. Scanner does volume incredibly well and because it can handle schema-less stuff, you can just kind of dump crap in there, replay things, and use it to search ridiculous amounts of data. So it's great for investigation. And ever since they've implemented detection as code it's getting pretty powerful.
And then Panther is, in my opinion, one of, if not about the best SIEM out there. The combination of having the ability to schedule rules using SQL and use Python to write real-time detections is a great combo. Plus, the ability to use software engineering best practices and write methods that are globally applicable is incredibly powerful.
And when you don’t have these things, it gets really frustrating. There are use cases where I want to do this one time and apply it to everything. I don't want to have to make different exceptions for every log source or copy/paste the same thing in multiple locations. And both design decisions in these products just make sense for the most part.
For my auxiliary, I use Notion and Obsidian for my knowledge management. I use a tool called Reader and Readwise to keep notes in as well.
Notebook LM is a great Google tool and you can put sources in and it becomes a little study partner - Dump in a bunch of threat hunting resources and have it help you summarize, generate action items, and suggest sources.
For IDE, I use VSCode or Vim. I do use Copilot and it is handy, but there's also been a lot of times where the auto-complete is completely off and I have to undo it.
RYAN: I did want to touch on Panther more. One product choice I think sets them apart is they've positioned themselves as the SIEM for technical security teams - they don't hold your hand like other SIEMs do. And I think while technical solutions sometimes scare people away, it also gives you the most flexibility and power. What are your thoughts on opting for the technical solution, and how it has improved your detection lifecycle?
I think I've been using Panther since about the beginning of the product. But what is really interesting is it's also getting features that aren't as technical, so you can use it with less technical users. But you do need somebody who's willing to dive into the technical piece.
I'm also seeing things like the development of PyPanther where I love it and hate it in some ways. Now, instead of having the detection code right in front of you like you do in Panther Analysis (their detections), they're in a Python library - so the logic is abstracted away. You can still pull up the library, and get to the code, but it's not in your face. In some ways, I like it because there's ways to customize alert context for all of the detections for a log source and basically two lines of code. But I worry about what's getting lost behind the hood.
For somebody who's lived in detections as much as we have, it's less of a concern because we know where to go look. But I wonder what's going to happen with other users who aren't as familiar and their ability to tweak things. To me, that's what makes Panther one of the best, is I can go into any detection, look at the logic, and adjust it any way that I want.
That power is what makes it for me the SIEM of choice because I can do so much with it. It's so damn powerful to be able to tweak, change, and move things. It gives you control in your environment in ways that I think you miss out on in a lot of other products.
And I get the fear there because there is a time cost in getting stuff set up. But there's also a time cost in a lot of the more traditional SIEMs in the form of prolonged alert fatigue. In these other products, you can run into issues in tracking/verifying changes and reusing functions - which is a major benefit of the Detections as Code approach in Panther.
Those are things that you can't really do with other products in the space, and that is what gets so powerful. I think that's also where a lot of people using Panther aren't pushing it as hard as they could. We pushed it pretty hard at our last organization and, I think, pushed Panther about as hard as we could.
RYAN: Using best-practice software engineering principles in a SIEM like this enables you to get the most out of the product, and highlights how important it is to know how to code in this industry. A lot of people have the misconception you get through without learning how to code, but you're severely limiting yourself.
This also isn't that hard of coding either. It's just logic. And the more you learn, the more you can do.
For me, in detection engineering, it is absolutely critical that logic is human readable. When you look at it, there shouldn't be a question of when it's going to fire and when it's not. Because if there is, that's when you end up with false negatives that nobody likes.
What have you found to be most beneficial for your own professional development for not only your career path, but in cybersecurity in general?
I'm really big on free or low-cost tools.
Early on, I did a ton with Cybrary. It was pretty new at that point, and I was a TA with them which was a great chance for me to learn and do a bunch of different things.
I've done the AWS Security Specialty, which you can do mostly with AWS's free tools.
I've done Antisyphon, which is Black Hill's training. They have a lot of free training and webinars. I've done Blue Team, Red Team, Red Team infrastructure building. I'll just do them if the title seems interesting.
I try to do the SANS Summits too when I can because they're free, and generally they're really good topics.
I'll do TryHackMe, Hack the Box, and I love the Port Swigger Labs - if you're doing web app security, that's as good as you're going to find anywhere. Plus, they keep putting out new stuff.
But a lot of it has also just been networking with people. I really enjoyed the team we had at our last organization we worked at together because we had such a different variety of backgrounds. Anytime we were in a meeting or working on things together, it was really interesting to hear what people talked about and the things that they do because that always gave me ideas of things to look at.
I like to watch what my friends do, and when that looks cool, I look into it.
But you do also have to have a little bit of focus. I try to read a couple books a year that are related specifically to engineering, whether that be DevOps or detection engineering specifically.
I also think blogging is a really good way to keep yourself accountable and doing that. From my experience, the combination of forcing yourself to do blogs and submit for conference talks are the way to make sure you're kind of getting that minimum professional development in every year. If you're writing about it and you're talking about it, you're probably doing enough to keep up with what you absolutely have to keep up with.
But it's a time thing and you don't want to burn yourself out. I think all of us have probably gotten close to that point at some time or the other.
A Little Less Talk, A Lot More Action
Check out Page’s talk at HouSecCon 2024 on Threat Modeling for Detection below, or read her full slide deck here.
What is your opinion on certifications?
I don't know that I'm that big on certifications, but I think it depends on where you're at in your career.
For me, changing industries, certifications were critical because I was not in the mood to go get another college degree.
So getting SEC+ was critical. For the job that I was in, and because CISSP needed five years of experience and I wanted kind of the next tier cert. I did CASP+ because that's the CompTIA version of CISSP and they didn't have the experience requirements.
I actually found that cert really had a ton of information. It gave me a good idea of how to run a security program: How to handle things, what direction not to go - but that's also a lot of stuff that I knew from academia, that program management perspective.
Now I kind of look at a lot of the more technical certs as it would be nice to have, but is it worth the time commitment to do it?
For example, OSCP would be a lot of fun. But is that the best use of my time? Probably not. Is studying the material fun? Yes. But is it something that I want to spend six months dedicated to working on? No, because that's not getting me where I want to go. There's not much there for me when I focus on detection engineering.
RYAN: I've talked about this before on a couple blog posts that think certifications are proof of knowledge. If you don't have experience or a degree on your resume to prove you know something, then they're fantastic. But to get in this loop of cert chasing won't necessarily give you the edge over the person who has five years of experience building out a security program. Learning should be the goal when you're studying for personal development, you don't always have to go for that cert.
That's what I found. For example, I've done a couple of IR and threat hunting oriented courses that have certifications attached, but I don't know that I'll ever do the certs because I don't necessarily need them.
The stuff you need to pass the cert doesn't really apply to my job and probably not to any job that I'm going to get, so I don't really necessarily want to spend that time on it. The knowledge is still good, which is why I took them. But the extra time it takes to get through the test isn't isn't necessarily worth it.
It's better to spend time like going through practical threat detection engineering, writing that up, and applying that, then going after a cert. Or even doing labs like some of those Antisyphon trainings that are 16 hours and lab focused. There's a cloud security one where you build an AWS lab and do a ton of things in it, and that was one of the best ones I did early on because you get a bunch of hands-on AWS experience that you don't really get otherwise. Hands-on stuff is always better because you can answer the questions all day long, but the practical experience is where it actually sticks.
"Is that actually realistic for your environment? Can you really do that? Do you really want to alert every time this happens?" You might say yes at first, and then you realize this happens a thousand times a day in your environment.
Moments like that reinforce learning. You need to learn how to think scenarios through, which can only really be achieved with practical experience. That's more valuable than the cert.
But I totally agree - if you don't have other things to show knowledge, that's where the certifications or degrees are an absolute must. But that's where networking and showing your work comes into play for people looking to change careers. Whether it's talking or blogging, you have to do something.
I read a LinkedIn post recently that said, "Security engineers don't always get to talk about what you do every day. You can't talk about details, otherwise you're giving away too much of the secret sauce."
That's one of the things that I really love about both Panther and Scanner. The Panther Analysis Tool and PyPanther are open source. You can learn to write detections and how to be a detection engineer from these repositories. You can clone the repos and change/test the logic yourself.
Scanner has that too with their CLI tool. And with the playground, you can do the same thing with writing and testing detections. It's something where if you're looking to get into detection engineering, even if you're not contributing to their open source repos, you can use them as examples.
For example, if you find a new IOC, you could write a Panther Detection and a Scanner rule and highlight them in your GitHub.
Stuff like that gives people the ability to show what they're working on without having to buy the tool, which is really great for the community.
💬 Do you have any questions for Page? Drop them below!
What are the most influential pieces of content for your professional development?
Oh, that's hard. There's the circle of people that I know that's like you, rs0n, and others that know each other and post in our private community.
But Zach Allen's Detection Engineering newsletter is a big one. That's a must read every time.
But then the daily sit-rep stuff is SANS, internet stormcast, cyberwire, the daily news cast, tl;dr sec.
Then I'll look at the Weekend Security from Zach Whitaker on a weekly basis.
Then the stuff that the people I follow surface. That's one of the cool things about having been in the field some time - people will post articles that look cool.
What advice would you give to people just starting out?
Honestly, I think the easiest path is to download Python, download the Panther Analysis Tool, and just start testing detections in the Panther Analysis repository.
If you want a book, the practical threat detection engineering book is I think the best inclusive resource that you can go through and it's pretty well priced. Follow Zach Allen's newsletter and follow both of us and what we're doing because I think we do pretty good work.
But the main thing is to just start messing with things. Get into the Panther tooling and mess around. Get into Scanner playground and mess around because you'll pick up some practical Python and YAML. And if you know how to write detections in Python and YAML, you can go from those to just about anywhere.
It's honestly about being an imposter. If that's what you want to do, start acting like you are that. It's about making the changes a little bit at a time until you've completely switched over.
Apply to jobs before you meet everything on the criteria list, and get feedback on your resume.
Get out there and network in-person whenever you get an opportunity. And then join Slack and Discord communities to network from home in the meantime.
What’s next for you?
Right now, I'm happy with detection engineering. I really like it, so that's probably where I'm going to stick for a while.
But it's hard to say. Especially with the automation pieces and integrating AI intelligently to make it possible for a small technical team to really scale well.
But that's what I see in the future for me. I think that that's a really good specialization to have.
Where can we find you?
Securely Yours,
Ryan G. Cox
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!