As we approach the end of 2025, even with speculation of an impending AI bubble burst, no one wants to be left behind. AI FOMO (fear of missing out) is at an all-time high.

Has AI finally moved beyond the realm of novelty? Can it add real value to your product? Or is it still just another box to check to stay relevant in the market?

Let’s explore this with a focus on IT and Cybersecurity products.

AI vs traditional programming

In some ways, AI can be seen as an evolution of programming languages.

In the early days of computing, you had machine code. Writing software, or “programming” the computer to complete a specific task, required highly specialized knowledge. This evolved into low-level programming languages (Assembly), which added a layer of abstraction. These languages were a little easier to learn than machine code but still required very specialized knowledge.

Over time, more layers of abstraction were added, eventually leading to the high-level programming languages (C++/Java/etc.) that most people use today. High-level programming languages still require some specialized knowledge but are easier to learn and far more accessible compared to their predecessors.

With each iteration, it moves further away from a language only the machine and a select few humans can understand, to a language many humans can understand.

AI, specifically the Generative Pre-trained Transformer (GPT)/Large Language Model (LLM) variety that launched the current AI hype train, adds yet another layer of abstraction to the human-machine interface. It removes the requirement for specialized knowledge and allows interaction between the human and the machine to occur in the human’s native language.

This could be seen as the next evolution of high-level programming languages.

Is AI right for my product?

To answer this, there are several questions to ask yourself first. The answers may be different depending on what your product is, and what your product does.  For our purposes, we’ll focus on IT and Cybersecurity software products.

Does it add value?

Any new feature added to any type of product must add value. If adding AI to the product does not increase the value proposition for the end user, what’s the point?

If you can’t answer this question confidently with a “yes”, do not add AI to the product, do not pass go, do not collect $200.

There are several ways AI can potentially add value, so let’s break this down even further.

• Speed: Does it significantly reduce the time it takes to complete a task (i.e. triage an alert or write a script)? If I still have to double-check every single output, I haven’t saved any time.
• Accessibility: Does it allow a junior employee to perform tasks that usually require a senior employee? This is the “abstraction” benefit I mentioned earlier.
• Insight: Can it find patterns that a human would miss? We are drowning in data. AI is good with large volumes of data. Humans are not.

If the AI feature is just a “chatbot” that acts like a glorified search bar, it probably isn’t adding enough value to justify the cost.

Is it the right tool for the job?

When people say “AI” right now, they almost always mean Generative AI (GenAI) or LLMs, but that is just one piece of the puzzle.

GenAI is great for creating content or explaining complex topics. It is not always the best tool for analyzing massive datasets or spotting trends.

If you are trying to detect network anomalies or catch a brute force attack, an LLM is likely the wrong choice. It is often too slow and too expensive for that kind of math.

This is where traditional Machine Learning (ML) shines. ML has been the backbone of cybersecurity products for years. It is excellent at crunching numbers to find the needle in the haystack.

An LLM may add value when used in combination with other tools, such as an orchestrator in an Agentic workflow deciding which tool calls to make to accomplish the desired results or summarizing complex output from another tool.

Don’t force GenAI into a problem that ML (or even a simple regex script) can solve better. Use the right tool(s) for the job, not just the one that is currently trending on social media.

Is it accurate?

This is the big one. In the world of GenAI, we call mistakes “hallucinations.” In the world of Cybersecurity, we call mistakes “incidents.”

If I ask an AI to generate an image of man outstanding in his field, and it gives him an extra finger, nobody gets hurt. If I ask an AI to write a script to remove a user and it hallucinates a command that deletes everything from my Identity Provider, we have a major problem.

You have to ask if the AI model is reliable enough for the task at hand. If the user has to spend 20 minutes prompt engineering and fact-checking the AI to get a simple answer, the tool has failed. It needs to work, it needs to be efficient, and it needs to be right.

Is it transparent?

AI output can’t be a “black box.” In security, we need to know the why behind an answer. If AI presents a finding, it should cite the specifics that triggered the conclusion. If there’s no trail back to the source, how do we know we can trust it? Transparency is key. You must be able to “trust but verify” all output.

Is it secure?

We can’t talk about AI in the enterprise without talking about data privacy.

To get a good answer from AI, you usually have to feed it data. In our industry, that data is often sensitive. It might be proprietary code, customer PII, or some other form of sensitive data.

Where does that data go? Is it being used to train a public model? If you paste a strictly confidential file into a public AI tool, you might have just leaked your company secrets to the world.

If your product introduces AI, you must be able to guarantee that customer data stays with the customer. The moment data leaves the safety of the tenant; you introduce a new risk vector.

Is it cost effective?

Even if your chosen form of AI has checked all the other boxes so far, you must still ask “is it cost effective?”.  If adding AI to a product blows up your operating budget, it becomes a non-starter. If the same results can be achieved through cheaper traditional methods, what value is AI really adding to your product?

The Verdict

AI is an incredible tool. It has the potential to change how we interact with technology fundamentally, but it is not a magic wand.

Don’t just add AI because everyone else is doing it. Add it because it solves a specific problem. Add it because it makes your users’ lives easier. Add it because it makes them more secure.

If you can check those boxes, you are on the right track. If not, you are just adding noise.

The post A Product Manager’s Guide to Meaningful AI first appeared on Fix The Exchange!.

Now with 100% more containers and an all-new look!

Where have I been?

Busy with work mostly. After I last posted in 2019, I got very busy launching a proactive lateral movement risk assessment tool called “Impact” at Tanium. Then the pandemic hit, which put my public speaking adventures on pause, but didn’t make things any less busy. I, along with several colleagues, successfully launched Impact in June of 2020, and I transitioned from the Director of Product Management role I had at the time, to a Senior Director SME Lead role.

2020-2023

For the next couple years, I’d be responsible for as many as 6 products at once (Impact, Integrity Monitor, Reveal, Comply, and Risk), plus 4 shared services/components (Criticality, Directory Query, Index, and Recorder). As you can imagine, that much responsibility leaves little time for things like blogging.

Fast forward to November of 2022, a reorg changes my title to Director of Technical Product Management, and along with it my workload. Fewer products, but different responsibilities. For most of the next year, I’d manage only 2 products (File Integrity Monitor and Reveal), and 2 shared components (Index and Recorder).

2023-2025

In the 4th quarter of 2023, I, along with 3 other colleagues would finally be awarded a patent for Impact that was filed back in 2019 when we first started working on it (#brain4life). Another reorg brought yet another change in responsibilities. I helped launch Tanium’s newest product at the time, called “Investigate”, and became the Product Manager for Impact once again.

After another reorg in February of 2025, “Technical” was dropped from my title, changing it to just “Director of Product Management”. There was never any distinction between “TPM” and “PM” at the company anyway, everyone had to do the same work no matter which title you had.

Halloween morning, October 31st, 2025, brought the biggest change yet. After 7.5 years at Tanium, I was unexpectedly laid off. There’s a surprising number of things that have to get done after a layoff. It’s a busier time than you might expect.

Getting back online

A series of odd coincidences took my blog offline the first week of November. First there was a Cloudflare outage, then something happened with my ISP that prevented inbound traffic from reaching my network. After several weeks of back and forth trying to figure it out, the ISP issue was resolved, inbound traffic was finally hitting my router, but still not reaching my webserver.

After a little more troubleshooting, I discovered that a recent update to my Unifi Dream Machine Pro SE had migrated firewall policies to their new Zone Firewall feature. My webserver was connected to a Unifi Aggregation Pro switch (a Layer 3 switch) and set to use it as its router. Apparently, Ubiquiti didn’t think to support Zone assignments when using one of their Layer 3 switches as a router. After changing the network configuration to use the UDM Pro SE as the router, I was able to assign the network the webserver was on to a zone.

Goodbye LAMP, Hello Docker!

When I first started my blog way back in 2011, I built it on a LAMP (Linux, Apache, MySQL, and PHP) VM, based on CentOS 6 with Drupal. After an upgrade to CentOS 7, and the famous “Drupalgeddon” vulnerability, I moved it to WordPress.

The LAMP VM migrated between various different physical hosts and hypervisors over the years and underwent several upgrades. Even though I wasn’t actively posting, I was trying to keep it online and up to date, as it’s always had a steady flow of traffic. Its final iteration before containerization was a CentOS 9 running on TrueNAS SCALE 25.10.

While troubleshooting the series of coincidences that took the blog offline, I decided to migrate it to an “App” (Docker Container) on my TrueNAS SCALE server. This should greatly simplify maintenance. I also decided to update the look and feel.

Unfortunately, images failed to migrate, so some older posts may have broken image links. I still have the images and will manually fix them as time permits. However, because it mostly posts that don’t get a lot of traffic that have broken image links, I’m not in any rush.

What’s next?

Jobwise, I don’t know yet. As of the time of this post, I’m still unemployed, which is a strange new thing for me. I have some interviews in-progress, but between end of year financials and the holidays, it’s very slow going. I expect things to pick up after New Years. I’m also exploring the possibility of founding my own startup.

As far as the blog is concerned, expect to see more posts, but on a new variety of topics. I’ve been away from Exchange for quite some time, so there will be less of that. Instead, you can expect to see more on Cybersecurity, Product Management, Automation, and Artificial Intelligence, so stay tuned!

The post Time for another revival. first appeared on Fix The Exchange!.

I recently had someone reach out to me on Twitter and ask if I still had a copy of the slides from this series. After some searching, I was able to locate them. Slides for all 7 sessions are now available here below:

The post Defending Active Directory Against Cyberattacks first appeared on Fix The Exchange!.

This talk has evolved over the last few years. I originally came up with the idea for this talk in 2016 after some friends and colleagues of mine from Microsoft’s Global Incident Response team (now called Detection and Response Team) reached out to me for help analyzing a webshell they’d found at a customer. By this point I had analyzed a few different webshells targeting Exchange Servers, and thus the original version of this talk, titled “Hunting Webshells on Microsoft Exchange Server” was born and delivered at the 2017 SANS Threat Hunting Summit. At the time I had no idea what to call this webshell.

Shortly after SANS released the recording of that talk, Palo Alto’s Unit 42 released a blog post by Robert Falcone, who called this webshell “TwoFace”. Robert and I started talking and decided to combine our research and co-present the next version of this talk. It was accepted by and delivered at the 2018 SANS Threat Hunting Summit. Video and slides from that version can be found below.

In 2019, we decided to update this talk again. We ended up delivering it at DerbyCon 9: Finish Line. Video and slides from this version can be found below as well.

If you would like this talk presented at your event or conference, please contact me on Twitter or LinkedIn.

The post Hunting Webshells: Tracking TwoFace first appeared on Fix The Exchange!.

The post The ABCs of Containment, Eradication, and Recovery first appeared on Fix The Exchange!.

This talk was original presented at the 2019 SANS Enterprise Defense Summit. Slides are available below.

If you are interested in having this talk delivered at your event or conference, please contact me through Twitter or LinkedIn.

The post Best of Both Worlds: Blending Tactics from the Public and Private Sectors first appeared on Fix The Exchange!.

This talk was given at the 2017 SANS Data Breach Summit, and the 2018 Camp IT Enterprise Risk / Security Management conference to audiences of Executives and Legal Council. Recently a few people expressed interest in seeing the slide deck from this talk, so I’m making it available here.

If you are interested in having this talk delivered at your event or conference, please contact me through Twitter or LinkedIn.

The post The Hitchhiker’s Guide to Data Breaches first appeared on Fix The Exchange!.

I had always intended to get this document published publicly, but for one reason or another, it never happened. With KB4490059 being released in response to @_dirkjan‘s #PriveExchange vulnerability, I’ve decided it’s beyond time to just share it here on my blog. KB4490059 is a step in the right direction. You can add these mitigations on top of it for even further protections, or perhaps find a more compelling reason to switch to the Active Directory Split Permissions model.

Removing Exchange’s ability to impact Tier 0 and Tier 1

Exchange is tightly integrated with Active Directory. When Exchange is installed, the Active Directory Schema is extended, and several highly privileged groups are created. These privileged groups are granted rights to a large number of objects within Active Directory.  A compromised Exchange Server can easily lead to complete control of Tier 1, and in many instances Tier 0.

For more information on the Tier model, see “Securing Privileged Access”.

In Exchange 2010 and later, there are two options for mitigating this risk. Both should be evaluated carefully before implementation. It is only necessary to implement one of these two options.

Mitigation Option 1 – Implement the Active Directory Split Permissions Model

Starting with Exchange 2010, there are three Permissions Models available. Of the three, the Active Directory Split Permissions Model, is the only one that can mitigate this risk without additional modifications to Active Directory. Because this model does not allow Exchange to modify security principles (i.e. create/delete/reset password) or group membership (i.e. add members to security groups that may grant access to other systems), compromise of an Exchange Server is contained to the Exchange environment when running under this permissions model.

This permissions model isn’t for everyone. You should carefully consider the impact switching to Active Directory Split Permissions may have on your organization. It may require a significant change in user provisioning, business practices, or workflows that revolve around Exchange. It is also important to note that while this permissions model is fully supported by the Exchange Product Group, it does not receive the same level of testing as the default Shared Permissions model.

If you’ve determined that the Active Directory Split Permissions Model is right for your organization, you can switch to it by running the following setup command:

setup.com /PrepareAD /ActiveDirectorySplitPermissions:true

For more information on configuring split permissions, see “Configure Exchange 2010 for Split Permissions”.

Implementing the Active Directory Split Permissions model both removes Exchange from Tier 0, placing it in Tier 1, and reduces potential impact to Tier 1.

Mitigation Option 2 – Reduce privileges granted to Exchange in Active Directory

If your organization needs to use the default Shared Permissions Model, the RBAC Split Permissions Model, or still has legacy versions of Exchange present, modifications to permissions in Active Directory are required to mitigate this risk.

To remove Exchange’s potential to impact to Tier 0, permissions granted to Exchange’s privileged groups must be removed from the Access Control List (ACL) on the following groups and their members in all domains within the Active Directory Forest Exchange has been installed in, to include any nested groups and members of those nested groups.

• Enterprise Admins
• Domain Admins
• Schema Admin
• BUILTIN\Administrators
• Account Operators
• Backup Operators
• Print Operators
• Server Operators
• Domain Controllers
• Read-only Domain Controllers
• Group Policy Creators Owners
• Cryptographic Operators
• Other Delegated Groups

With the exception of the last 3 entries above, these groups should already be protected by AdminSDHolder, which prevents them from inheriting permissions that would allow Exchange’s privileged groups (Exchange Trusted Subsystem, Exchange Windows Permissions, Organization Management, etc.) to take control of them. Members of these groups should have the same protection. However, since Account Operators, Backup Operators, Print Operators, and Server Operators, can be excluded from AdminSDHolder protection, it is worthwhile to take the extra step of removing Exchange’s permission to all of the above groups (if present).

Because the permissions are inherited, the easiest way to accomplish this, is to place all Tier 0 users and groups into the same OU, block inheritance on that OU, and restrict permissions on the ACL for that OU. Full Control (GenericAll), Write (GenericWrite), Modify Permissions (WriteDacl), Write Member (WriteMember), and Change Password (note that Change Password permissions should NOT be removed from “Everyone” or “SELF”), are the permissions that should be removed from any object that should not have the ability to manipulate Tier 0 OUs/users/groups. In most cases the entire security principal can be removed from the Tier 0 OUs/users/groups.

To remove Exchange’s potential to impact Tier 1, a similar approach to the above must be taken.  Exchange’s permissions on the ACLs of users and groups with privileged access to Tier 1 assets.

Because the permissions are inherited, the easiest way to accomplish this, is to place all Tier 1 privileged users and groups into the same OU, block inheritance on that OU, and restrict permissions on the ACL for that OU. Full Control (GenericAll), Write (GenericWrite), Modify Permissions (WriteDACLl), and Write Member (WriteMember), are the permissions that should be removed from any object that should not have the ability to manipulate Tier 1 privileged users/groups. In most cases the entire security principal can be removed from the ACL on the Tier 1 OUs/users/groups.

For example, Exchange should not have permissions to an account or group that grants privileged access to a SQL server.

Privileged accounts and groups should NOT be mail enabled. Therefore removing Exchange’s permissions from them should have no negative impact on operations.  If an account with, or a group used to grant privileged access to, any system, regardless of what tier it resides in, has been mail enabled, privileges should either by removed, or they should be mail disabled. Either way, it may be necessary to create unprivileged accounts/groups for mail use, or non-mail enabled accounts/groups for privileged access use, in order to avoid disruptions.

This approach is not tested by the Exchange Product Group. Failure to exercise caution when implementing this approach could result in damage to the Exchange environment.

Additional Considerations

Service Packs and Cumulative Updates in Exchange often include Schema updates to Active Directory. Because Schema extensions and Active Directory preparation require Schema Admins and Enterprise Admins privileges, this portion of updating Exchange is a Tier 0 operation. Schema extensions and Active Directory preparation must be performed from a Tier 0 Privileged Access Workstation (PAW).

Schema extension and Active Directory preparation performed during an update to Exchange may overwrite some Exchange related settings in Active Directory. It is recommended that permissions on Tier 0 and Tier 1 set according to the guidance above are validated after every Exchange update install.

The post Reducing the Exchange and Active Directory Attack Surface first appeared on Fix The Exchange!.

This talk was originally presented at the 2017 SANS Threat Hunting and Incident Response Summit. A recording of this talk and the slide deck from it are available below. If you would like an updated version of this talk presented at your event or conference, please contact me on Twitter or LinkedIn.

The post Hunting Webshells on Microsoft Exchange Server first appeared on Fix The Exchange!.

My session abstract:
“Microsoft Exchange Servers are a high value target, making investigation of them during Incident Response vital, but where do you start? What should you look for? Backdoor implants in the form of webshells hiding in OWA are on the rise. Find out how to hunt webshells and differentiate between legitimate use and attacker activity, using default logging available on every Exchange Server, through real world examples. It’s easier than you might think, and these techniques can help up your DFIR game in environments containing Exchange Servers!”

Full agenda: https://www.sans.org/event-downloads/45247/agenda.pdf

More details: https://www.sans.org/event/threat-hunting-and-incident-response-summit-2017

If you can’t make the summit, a recording should be available afterwards.  I’ll post a link to the recording and a detailed blog on this subject when available.

The post Join me at the 2017 SANS Threat Hunting and Incident Response Summit – April 18th and 19th first appeared on Fix The Exchange!.