Always-On or Always-Exposed? Rethinking Point-in-Time Security

Brian Moody: You know, we've always said that security is not a set it and forget it type infrastructure. And so many companies today implement security tools, and then what they do is they do the annual pen test. Or they'll do, you know, the annual check and they get that report back that says "you're good," and it creates a definitive false sense of security.

Shahin Pirooz: Yeah, in a previous role we used to help customers build out security operations. And we'd go in and we would help evaluate technologies, implement tools, implement the SIEM, train the SOC, put SOPs together, all the things that you would do to build a security operations.  

And then six months to nine months later, we'd get a call saying that our tools that we helped them build suck because they just got hacked. And we'd have to go back and look, and as we did investigations, we would almost always find that the bad actor was... the dwell time was four to six months.  

They were sitting in the logs, in the tools, and there was just nobody paying attention and there was no new correlation rules, no fine-tuning of the SIEM. It was the set it and forget it mantra, and, you know, if we have any problems, we'll catch it at the pen test next year.

Brian Moody: Well, I think the other aspect, and, and for our audience, think about your environment today. It's not static. I don't think there's any compute infrastructure, application infrastructure, cloud infrastructure, I mean, name it. I mean, we've been having a lot of talks about carbon-based entities versus our digital entities. If you went back or or you were with us watching our January/February SoundBytes, you know, we talked about digital entities. Think about how many of those go in on a day-to-day basis.  

And we have so many examples that we can bring to you from our SOC with respect to how companies get attacked and you mentioned it, right? The SIEM wasn't tuned. The one company he just mentioned, and I know the example that he's thinking of, you know, the hackers were in for six months. We knew they were in, but you know what system they came into? They came into the the Linux system that was added two months after the pen test was done. The new Linux system went in, password wasn't changed, and it was an easy target for the hackers.

Shahin Pirooz: So, I think that we don't even have to modernize technology for this to be a problem. We used to be at a time, you know, the going back in time, my early days of tech 30 years ago, it used to be fine to consider that you have this walled garden and it's protected, the traditional castle and moat approach, and the firewall is protecting anybody from getting in and the people inside are trusted. And in that point in time, you can set firewall rules and kind of forget about it. And so pen testing once a year was something that was normalized in that mindset, in that timeframe.  

Fast-forward to the last 20, 10 years, and last 5 years, we now had situations where in order to do this project, we need these servers and we need this application. And so you spin up this infrastructure right after the pen test is finished that checked everything and made sure you were protected, and what does everybody do when they spin up a new application? Open up access. Because we're gonna come back down and clean it up after, and we're gonna get rid of all the test environment, we're gonna get rid of all the ports we opened up, we're gonna get rid of all the protocols. We do any-any just so that we can get the application up and running and miss, not miss any deadlines.  

Impact? Nobody comes back and cleans up until the next pen test. And you're like, "Oh, my God, I forgot to shut that thing down. Let me go clean it up now." And you rush to clean it up so that you can get better marks on the pen test and pass your audits for whatever compliance you have.  

That model has become exasperated today. So, it is much more accelerated timeframes to technology launches. The edge is gone. There is no such thing as a wall garden anymore. So, as we think about what's the impact of a static testing, and this is a conversation we have with partners and customers all the time, annual pen tests don't mean anything. They're great. They don't mean anything. They're a checkbox on a sheet.  

So, if all you want is to do an annual pen test to validate that you have run a pen test in order to meet compliance, whether that's government, industry, whatever, whoever is regulating you, whether it's internal or otherwise, that's fine. An annual pen test meets that check mark. But does it do anything to improve your security? Only for that point in time.

Brian Moody: Yeah. Well, I think that I would say to our audience as well is as you evaluate your environment, you know, we have been talking for years now about the tool-centric mindset, right? And I think so many of us look at our environment in kind of stovepipe approaches, right? We've got the network, we've got the endpoint, we've got identity, we've got mail, right?  

So what we're doing is we're kind of, we're slicing up our environment and then we're applying a tool to it, and then what we're doing is then we're testing that tool or taking... So, but what we're not really looking at... And, and I love that you and the team have created our attack surface management platform because this is really kind of what this is about, is how do we manage our attack surface, right? It's not siloed, right?  

There's interoperabilities and interaction across those silos and every time, as Shahin just brought up, we add a infrastructure, add an appliance, we continue to grow our attack surface. How are we protecting it, right? Well, my XDR tool says I'm fine. Really? That's one aspect.  

And, so, bring up your your car analogy. I don't wanna steal it from you. You brought this car analogy up right before our talk, and I think it's a really good one.

Shahin Pirooz: I mean, it's as simple as if the only measure you had for the oil level in your car was a dipstick, in the engine compartment, and there was no gauges or meters that told you the engine temperature, the oil pressure, the things that are warning signals that say there's something we gotta go check out. If there was no check engine light, if there was... And you only checked your oil once a year, I guarantee you, you would burn out your engine. Because I don't know about you, but as cars get older, my daughter's car is every week checking her oil and telling me, "Dad, I need more oil."  

So it's important to be able to have the things, the monitors, the measures, that are giving you a... I don't wanna call it KPIs, but giving you a measurement that says here's what's going on in my environment, understanding the configuration and what has changed. So, what's new? There's new assets that showed up on the network. Those assets have the following ports. There's new operating systems that showed up. And those types of things come up not in a tool that you install on a machine, because if somebody spins up something without telling IT about it, if there's shadow IT happening, they're not gonna install your EDR tool on it. They're not going to install your segmentation tool on it. They're gonna do everything they can to simplify and accelerate their timeline for their project without involving IT.  

So the only way to get visibility is to take that pen test, and every time there's a change in the network, do a pen test again. If you were doing that, you might be doing that every month, you might be doing it every week, you might be doing it depending on the scale of your company.  

So the reason the attack surface stuff is critical from our perspective, there's a lot of XDR players out there, and XDR is just one of the portfolio solutions we have for partners, but those XDR solutions are endpoint focused and focused on installing tools to get visibility. None of them are doing attack surface management.  

Our MDR, our XDR, and our DeltaDR portfolio all include attack surface management and it starts with the very entry level attack surface management of external and internal all the way up to all five layers of the attack surface: email, DNS, endpoint, identity, and network.  

And if you're not collecting from all of those different attack surface analysis, what is wrong with the network and what things you need to put energy into and what has changed from a configuration perspective, you don't have control of your environment. You're literally waiting for the bad actor to find it or the next pen test.  

And that's literally what the topic is today. Let's avoid having any gap time between discovery of something and that thing being up and running for a period of time.  

So for example, if you were running attack surface management continuously, which everything we do is continuous. The idea behind the entire concept of our attack surface management is if you're monitoring continuously, you're gonna see changes as they happen. And when those changes happen, they bubble up to the surface and allow you to say, "Oh, we forgot to shut down that test server, and the project's not even done yet." So, that's really the key distinction in this dialogue.  

If you're sitting and waiting for a point in time to do a pen test or an evaluation of your network, your servers, your infrastructure, your identity, all of that, that point in time freezes the moment it's done, and then all the changes that happen after it don't come up until the next point in time you do it. So, you could have anywhere between, some companies run their tests quarterly, some run them half biannually, some run them annually.  

But whatever your frequency is, if you're running it quarterly, that's still three months of exposure that the bad actor could take advantage of. Most bad actors can do stuff within three months before they're identified and cause you a lot of grief.

Brian Moody: So, we've had a lot of conversation about reactive versus proactive. And I think this is the one thing, and again, and I would address the audience, if you think about your environment today, and... we just engage so many customers that have this toolset mindset. I think it's just how the industry has driven the way in which you've kind of bought and deployed and selected security tools. And, you know, we talk all the time about how security tools are reactive, and if you think about the core tools, now, we use reactive security tools because they're part of the foundation--

Shahin Pirooz: You need them.

Brian Moody: --of a security infrastructure, right? They're part of the maturity model. But the net is is that if you're not doing kind of the additional, as you just said, that continuous monitoring, the tools are reactive, and hackers know how to get around these tools. I mean, we see evidence of that on a day-to-day basis, right?

Shahin Pirooz: As much as it is the white hat's job to detect anomalous and malicious behavior, it is the black hat's job to evade detection ... and, and identification. So, as hard as we're working to find, to try to detect them, they're working just as hard to avoid detection.

Brian Moody: And I think the unique aspect about that is that what we do is we utilize the tools within our infrastructure, but as you said, that continuous monitoring, I think the unique thing about our toolset is that we're looking for behaviors.  

You and I, again, we've touched on this topic many times with respect to UEB and entity behavior, you know, entity and user behavior from a standpoint of what's happening in your environment. So, from a standpoint of that network constant evaluation, what's happening in the environment, wait, where did this, shadow, you know, IoT devices. Why did this IP just suddenly pop up on the network? What is it?

Shahin Pirooz: And why is it talking to these servers?

Brian Moody: And why is it talking to these servers, right? So, oh, well, that's the guys over in application marketing, and they just spun a new environment up. So, in many cases in your environment, it's valid, right? I mean, the dynamics of our enterprise today, that's valid action that occurs in our business. But you want to know about it.

Shahin Pirooz: And if that happens, here's a perfect scenario. Like, if we go back to the story I shared in the beginning, if that happens, this application team spun up this IoT device, and this IoT device is behaving a certain way, and let's say that you aren't getting visibility into it until pen test time.  

When it comes to pen test time, now you come to the conclusion that this is a valid thing, we're okay with it, we're gonna let it run. But the bad actors have observed this behavior if they're sitting inside the network and how it's acting, and now they can mimic that behavior to do detection evasion.  

So, they can mimic that IoT behavior and talk to those ten servers and start acting the way the IoT device does, and none of your tools, even if you fine-tune them to catch this kind of behavior, will see it.  

So, it's more important to understand what's happening and understand what's going on immediately and then fine-tune the SIEM or whatever you're using. I've also talked repeatedly about the SIEM being dead, but fine-tune whatever you're doing for aggregation of data, to identify which behavior specifically, which ports, which protocols, and from which applications are allowable.  

And if something new pops up, trigger it again. Don't wait for another year and say, if new executable shows up on a machine and starts behaving the same way the old executable did, doesn't mean it's acceptable. It means that somebody is mimicking, and you need to be able to identify those things.

Brian Moody: And I think the other piece, I mean, I think it's net-net today in security is, how quickly you can respond to these things. So, we do the point-in-time tests. We do the pen tests. We do the external pen tests. We do the internal pen tests, right? You know, you've heard of purple teaming. So we got the red team going after the blue team, and from a standpoint of, you know, what are we looking at and how fast can react to it?  

And I think that is one of the biggest pieces is if you're just running these tests today in your environment and you're getting that report, you're reporting that to executives or to the board and saying, "We're good." You're not good.

Shahin Pirooz: You may be good at that point in time. You won't be good for much longer.

Brian Moody: For a few minutes.

Shahin Pirooz: Yeah, yeah. But it's also important.. So we've said attack surface management will fix this, but it won't. And I mean that in this context. Configuration management is something that is also continuous. It can't be something, when you get the data that says we've got a problem, there needs to be an initiative that identifies that as a risk and classifies the risk. And then you need to put an action plan together for how you're going to address that risk.  

One option is we're gonna accept it, and we're gonna let it run the way it is. But there are a multitude of other options, including we're gonna patch it, we're gonna take it out of the network, we're gonna block it, whatever the thing may be. So I can't tell you in previous lives how many pen tests I performed, and the next year, we would come and do the pen test and the exact same vulnerabilities would still be there. Nothing had changed. Maybe one or two of the 20 or 30 would be fixed, and we would lay out, here's what you need to do to fix this.  

We recognize that IT teams are taxed and are being pulled in every direction, and more so now than the examples I'm giving which are you know, 10, 20 years ago. But it's important to prioritize if you are taking the time to evaluate your network, in that point in time, be sure that you've allocated resources to be able to close those gaps as quickly as possible.

Brian Moody: Well, I've talked about this with several customers. You know, we've got customers that are running, you know, manufacturing plants, right? Customers that are running doctors offices, right? And they're running, you know, Windows 3.0 or something, right? So you're running an old operating system.

Shahin Pirooz: Because you have to.

Brian Moody: You have to.

Shahin Pirooz: Because the application vendor will not update their application and it won't run anything.

Brian Moody: Or I'm running an old piece of equipment that's in the warehouse.

Shahin Pirooz: It's embedded.

Brian Moody: And it's embedded and it only talks on port XXX.

Shahin Pirooz: Right.

Brian Moody: You know, but wait a minute. There are definite vulnerabilities around access to that port, but I've gotta leave it open.  

The key aspect is understanding the vulnerabilities that exist in your environment. And I think that's one of the other key things that we bring to, to the table with our security operations center is, that in evaluating the behavior, in evaluating the environment, understanding the attack surface, we understand that that port's open.  

We understand that that operating system exists within the environment. We've mapped it. So, we're mapping your norm, you're understanding what your norm is, but this is where the continuous monitoring is so critical, is that if we start to see IOCs or we start to see things that are directed at that port or at that operating system or at that application, WhiteDog security operation centers react in that a little bit differently.

Shahin Pirooz: Yep.

Brian Moody: That's gonna get escalated.

Shahin Pirooz: Yeah, there's a lot of key things we do that are distinctly different than other players. And one of the key components in our stack is being able to identify a vulnerability on a system, identify the behavior from the user and entity behavior analysis, and determine is this tactic or technique something that's gonna take advantage of this vulnerability because this behavior is targeting this machine. And if it is, that's an escalation.

Brian Moody: So I'm gonna drive you down another path. So, we've talked about kind of point-in-time testing. We've talked about isolation. As I said, we're isolating the different areas of our business, and we're applying a tool to it. Talk about, and we talk about this often with WhiteDog, is layered approach. The protection that's associated with layered approach.

Shahin Pirooz: Yep.

Brian Moody: And then the normalization of that telemetry and then the correlation of that telemetry, which really brings, I think, escalates the maturity model from that. How do those layers protect us?

Shahin Pirooz: So, it's important to recognize the tool-centric approach here because that's where things break down when you're looking at layered approach. Oftentimes, there's tool manufacturers that will say, "We cover these different things."  

So there's a lot of EDR players that pull telemetry in from sensors. They pull telemetry in from Office 365. And they give you the false sense that they are protecting those environments they're collecting telemetry from. All they're really doing is enriching the data associated with the asset that is their focus. In many cases, that asset is the endpoint. So pulling in telemetry from Office 365 to the endpoint data, all it does is enrich the endpoint to say, I believe that this machine belongs to Bob, and and I think there was a malicious behavior against Bob's account, and I see some funky things happening from Bob's perspective.  

But they don't do anything to address the account takeover that happened. They don't alert on the account takeover. They're only enriching the data on the endpoint. So the layered approach says don't rely on a single tool in your network even if it says it can collect telemetry for multiple things.  

You need to be able to have detection and response at, in our opinion, five layers of security. Those five layers, and we repeat this every week, so hopefully this becomes the standard in the industry. DNS, email, identity, endpoint, and network. And at the core of it, you gotta have 24 by 7 security operations to monitor the telemetry from that. If we just focus on those five layers, at a minimum, minimum, minimum, the smallest of organizations should have five tools. Not one, not two. Five.  

In reality, there's about three tools in each of those categories, so a decent sized organization of, let's say they start at 100 and work our way up to 1,000, is gonna have 15 to 30 tools in their stack. And the reality is it's hard to manage configurations, fine-tuning, and all of that across all of those tools.  

What WhiteDog brings to the table is become a consumer of that stack. Don't become the provisioner of that stack. You don't have to worry about the fine-tuning. You don't have to figure out which tool is the best tool at that point in time to solve the issue. You consume the benefits of having this multi-layered approach across all five layers of security at a fraction of the cost of developing and building it yourself.

Brian Moody: So one of the things that I'm super excited about, and what I'm seeing today is our partners, several of our partners now are getting super excited about this, and that's Open XDR. So we talk about this point in time, we talk about the toolsets, so here now we talk about the relationship across the toolsets, having the layers. But I don't have this, right? So today I have an environment that's tool-centric. I'm isolated, I've got multiple tools, I've got multiple paths and telemetry coming in.

Shahin Pirooz: Let's say you've invested in and figured out the 20 tools that make up your layered approach.

Brian Moody: Right. Well, I have 20 tools, I have 20 consoles, I have 20 different levels of data that my team's trying to manage.

Shahin Pirooz: And you may even have a SIEM in that stack, which is aggregating and correlating the information, but do you have a SOC looking at that SIEM?

Brian Moody: So, from that application, talk about our Open XDR, why you and the product team developed this and really what that now brings to the table for our customers.

Shahin Pirooz: So, Open XDR is really the exposing externally how we operate on our own tools.  

So imagine you build an infrastructure that is a Fortune 50 security infrastructure. So you build a SOC that can support a Fortune 50 company, and you build a security operations team and the security devops to do all of the things associated with that.  

Now, narrow that back down and what you have is WhiteDog. We've integrated all the technologies that would support any size organization, and what we used in order to be able to do attack surface threat hunting, management, detections, and response, so identify, detect, respond, that's the key mantra any security company is gonna look to, was we built a framework for how to take data from all these different tools, the telemetry from all these different tools, and normalize it down to a point where we understand the behavior, the communication paths, the vulnerabilities, all the aspects of that endpoint and user. That's how we look at the world, is IP addresses and email addresses, and be able to enrich that data so that we can take quick decision-making based on the things that we've seen coming from all the tools.  

The difference between what we did and what the traditional, like I mentioned earlier, I think the SIEM is dead. SIEMs fundamentally do nothing but take raw logs and pull them into a central repository. And then run correlation rules to find similarities in IP addresses and behavior, in connections and so on and so forth, but it's a lot of analysis. It at the end of the day is nothing but a log aggregator with some rules associated with security. What our approach has been is different.  

Our approach is focusing on an IP asset and a user asset and enriching from all of the tools the data that are IP related, the data that are user related, onto those core assets. And now we have a very enriched node that we can make decisions about. We decided to take and expose that internal monitoring and management, we call it our management console, to our customers. It is very SIEM-like. It is really designed to do the log aggregation and API connections and plug-ins, but at the end of the day, it really is just a management interface, which is why it's an Open XDR platform and not a managed SIEM.

Brian Moody: And I think the coolest part about that is, is that it's not our tools, so if you have this kind of tool-centric deployment, is that we can overlay our XDR platform on top of your environment, no net changes needed for you.

Shahin Pirooz: Our Open XDR approach, to be clear. Our platform includes all the tools, so if you're evaluating, should I refresh tools? Should I take out tools? Do I wanna own tools? Do I wanna refresh the tools? Then our XDR portfolio will solve that, and our DeltaDR portfolio.  

But if you have spent the time and investment and built the team to build out your own security stack and really now need to do better threat hunting and threat intelligence and attack surface management across that, then our Open XDR is made for you. It's designed specifically to bring what we've learned over the past nine years to market over the tools you own.

Brian Moody: That's what I love about this. Don't ever say anything wrong after the founder, 'cause he's gonna come and tell you how the right way to say it. So let's kind of wrap this around from a standpoint of the mindset shift. So what would you recommend today? So, if for our audience members, if your environment is kind of point-in-time, right? If you do have that tool-centric kind of approach, if you're doing kind of point-in-time type approach, what would, what should they focus on, let's say, in the next month?

Shahin Pirooz: There's one word. Continuous. So find an answer to be able to continuously understand your configuration.  

In a previous life, we created a platform called Continuous Configuration Management. And we will likely bring continuous configuration management back to the table at WhiteDog over this year. But the implication of continuous configuration management is, number one, same thing, identify it, understand it, and respond to it.  

So identify the fact that you've got a configuration that has drifted from what you expect it was from that point-in-time snapshot, understand whether it's a risk or not, and then determine how you're going to treat that risk. So what's your treatment gonna be? And that approach fits every scenario, whether you're regulated or not, but especially if you're regulated.

Brian Moody: And I would say too, you know, we talk about, like you said, five, I mean, at a minimum, there's five key areas. And I would say, at a minimum, pick one. I mean, don't try to boil your ocean right out of the chute because it can be incredibly overwhelming. Pick one core aspect to try to move that from point-in-time or to continuous monitoring in your environment. That'll help you kind of kickstart and begin so that it doesn't feel like such an overwhelming task.

Shahin Pirooz: Yeah. And some folks, there's a lot of, there's a lot of technology companies out there that are doing external posture. That's a great starting point, as long as they're actually looking at exploits and not just vulnerability scans. Vulnerability scans only go so far. Pen tests are finding the exploits and identifying if they're exploitable.  

So look for solutions like our external posture management that does exploit identification, and then our internal posture management, which is, there's a ton of players in the market that do vulnerability scanning on the network. It's that, but again, not just vulnerability scans, but also exploit identification. Those are the core components.

Brian Moody: So interesting topic. So if you find--

Shahin Pirooz: Stop doing point-in-time.

Brian Moody: Stop doing point-in-time. So we'd love to keep this conversation going. Let us know in the comments if this is helpful... do you feel your environment's point-in-time? Are you experiencing a similar feeling to this? Do you feel secure but then not? Because you should question everything. But we'd love to keep this conversation going with you. Reach out to us. We love the conversation and appreciate you joining WhiteDog SoundBytes for March 26th.

Shahin Pirooz: One last thing I'll say before we say goodbye is, when I reshared our post about this SoundByte, there was a handful of people who commented. I never saw a comment that was, "I think you're blowing smoke."  

All the comments were, "This is on the right track. This is the way people should think about it."  

I wanna challenge anybody out there who thinks we're blowing smoke, please let us know. Let's talk. Let's start a dialogue. Always open to new perspectives. If you agree with us, feel free to high-five and let us know.  

But if there's an alternative viewpoint out there, if there's a different way to think about this, we would love to hear from you. With that...

Brian Moody: With that, we'll close. So thanks for joining us today, SoundBytes, March 2026. We look forward to coming back at you again next month. Have a great day.

‍