How identity became the most important cyber control

Good morning, afternoon or evening, depending on where you are. We will give everyone a few more minutes to join and then get going promptly. It is very hot in the UK today, so I would not blame anyone for deciding not to join. It is about 32 degrees here, and most of us do not have air conditioning.

In the meantime, where is everyone tuning in from? It is about 6 p.m. local time here, so I am interested to see where the audience is based. I can see the UK and Colorado in the chat. If you are in the UK, you are probably also suffering in the heat today.

The format of this session is that we will talk about identity security, why it became important, and then I will introduce myself properly. We will go through the slides, leave time for Q&A, and if you want to ask general cybersecurity questions or talk about inforcer, we can do that as well. You can ask questions throughout in the chat, and I will do my best to respond as we go. The session should run for around 30 to 40 minutes, depending on how much I ramble. This call is also being recorded, so you can view it later if needed.

Welcome, everyone. Let us get started. My name is Lewis and I work at inforcer. This week is actually my one-year anniversary here. I come from an MSP background. I have worked in three MSPs, and I also tried to run my own for a while before realising that running a business is difficult and not quite as much fun as working in the technology. I decided to move back into tech and try working for a vendor, which I am very much enjoying.

My focus and specialism is Microsoft security, particularly Intune. That is where my MVP award is focused. I am also interested in Defender for Endpoint and Entra ID.

Today, we are going to talk about how identity became the most important cybersecurity control. When inforcer started looking at building a TDR solution, and when we looked at how security reached its current state, it made sense why identity is so important right now. Identity did not become critical by accident. You may have heard the phrase that identity is the new perimeter. I prefer to say it is the not-so-new perimeter, because logging in has been the way people access systems for quite some time. The important part is that there are now many more things we can do to protect that login.

Let us go on a journey through what cybersecurity is and where it came from, because once you have that context, it becomes clearer why identity matters so much. I have not gone down every possible rabbit hole, and I have not gone back as far as the era when computers were the size of refrigerators. Instead, let us go back to the mid-1980s: a great time for music and a good time for cybersecurity to start becoming a recognisable discipline.

In the early days, the focus was mainly on the endpoint. Early computer viruses were often created and distributed manually, for example on floppy disks. A threat actor, although that term probably was not widely used then, could create something malicious, put it on a floppy disk, and distribute it by leaving disks in places where people would pick them up and use them. Today, we say you should never pick up a USB stick in a car park and plug it into a machine. The same principle existed then, but with floppy disks.

That was cybersecurity for the most part: protecting single machines from malicious files that found their way onto the endpoint. The market needed software to detect and prevent those threats.

One of the first big names in endpoint protection was John McAfee. He was one of the earliest major figures in cybersecurity, especially endpoint protection, with products such as McAfee VirusScan. I am not old enough to have used the earliest versions properly, but thanks to the internet, we can look back and understand how they worked.

Endpoint security was largely signature-based. Every file has a hash, and those hashes could be correlated with known malicious signatures. You would buy software, load it onto the machine, and it would contain a list of known bad signatures. When you inserted a bad disk, the software could match the file to a known malicious signature and flag it.

Over time, detection evolved into behaviour-based approaches. Instead of only asking whether a file matched a known signature, the software started looking at what malware-like behaviour looked like. That might include modifying system files, deleting many files in a short period, or changing protected areas of the system. It was not perfect. Sometimes legitimate scripts from a software vendor could look suspicious, especially in older systems that carried out bulk file operations. But it was a start.

In the early days, the focus was mainly on the endpoint. Early computer viruses were often created and distributed manually, for example on floppy disks. A threat actor, although that term probably was not widely used then, could create something malicious, put it on a floppy disk, and distribute it by leaving disks in places where people would pick them up and use them. Today, we say you should never pick up a USB stick in a car park and plug it into a machine. The same principle existed then, but with floppy disks.

That was cybersecurity for the most part: protecting single machines from malicious files that found their way onto the endpoint. The market needed software to detect and prevent those threats.

One of the first big names in endpoint protection was John McAfee. He was one of the earliest major figures in cybersecurity, especially endpoint protection, with products such as McAfee VirusScan. I am not old enough to have used the earliest versions properly, but thanks to the internet, we can look back and understand how they worked.

Endpoint security was largely signature-based. Every file has a hash, and those hashes could be correlated with known malicious signatures. You would buy software, load it onto the machine, and it would contain a list of known bad signatures. When you inserted a bad disk, the software could match the file to a known malicious signature and flag it.

Over time, detection evolved into behaviour-based approaches. Instead of only asking whether a file matched a known signature, the software started looking at what malware-like behaviour looked like. That might include modifying system files, deleting many files in a short period, or changing protected areas of the system. It was not perfect. Sometimes legitimate scripts from a software vendor could look suspicious, especially in older systems that carried out bulk file operations. But it was a start.

Working from home looked very different. You might have had an early Windows XP or Windows 2000 machine, and just getting onto the internet could involve manually adding network hardware. Even then, there were not many business systems available remotely, especially for SMBs. Remote access was expensive, complex and often locked down. In many computer-based jobs, your options were to be in the office or not do the job.

There were early attempts at offline working, such as the Windows Briefcase feature, where you could copy a file to your local machine, take it away, work on it and then sync it back later. It was a very different world. We were not socialising online in the same way; we actually went outside and did things.

Then came the hybrid era, roughly 2005 to 2015. I entered IT towards the end of this period, so this environment feels familiar to me. At some point, the internet became good enough to support working from home. Companies still had office buildings, firewalls, servers and applications inside those buildings, but now VPNs made remote access more realistic.

You saw technologies such as PPTP VPNs, where users needed an IP address, username and password to connect. It often required complex software, but for users who needed remote access, that was the route. You also saw the internet being used to connect networks and satellite offices together into larger organisations.

A VPN connects private networks over the public internet. A home computer or satellite office connects to company servers over an encrypted tunnel. In the early days, not all of this was encrypted, but the attack surface was not yet monetised in the same way. As remote work expanded, threat actors began targeting VPN access.

In many small businesses, it was common for administrators to share company VPN details. If a threat actor had the IP address, username and password, they could access the company network, and it might be difficult to detect that they were in there. Market players included Cisco, Check Point, Fortinet and Microsoft's Routing and Remote Access Service. Around this time, there was also a shift from PPTP to IPsec as encrypted connections became more important.

That means identity is the weak spot. My resources are in the cloud, and access to those resources is often controlled by a laptop, username, password and identity.

This is why many cybersecurity companies, and Microsoft in particular, have focused heavily on identity in recent years. Microsoft's Digital Defense Reports repeatedly emphasise MFA, passwordless authentication and identity protection. The statistics around privileged accounts without MFA are still worrying. The phrase "hackers do not hack, they log in" may sound slightly cringe-worthy, but unfortunately it is true.

Another issue is that reconnaissance is easier now. Because so many organisations use public cloud services, it is easier for attackers to identify what services a company uses. For example, you can discover mail security providers, certificates and public-facing services. If a known vulnerability exists in one of those services, attackers can target it. Before, public exposure might have simply been an office IP address with internal systems hidden behind it. To enable remote work and SaaS, we have made more services public and accessible, which means the risk of identity compromise is even greater.

Identity is the gate to your castle in the cloud. Many MSPs have recommended that customers move from on-premises apps to SaaS platforms because responsibilities such as infrastructure, operating systems and physical data centre security shift away from the MSP. But the MSP still needs to say: here is your login, we have connected it to Entra single sign-on, and we have secured it. In some ways MSP life became easier, but identity became far more important.

That brings us to how inforcer helps with this challenge. Fun fact: the "in" in inforcer stands for Intune. The product started with policy management for Intune. Since then, the platform has expanded to help with posture management across Endpoint Security, Entra, Defender, Teams, OneDrive, SharePoint, Purview, Exchange, Microsoft 365 and Copilot.

One slide I often show is the attack timeline, which comes from the Microsoft Cybersecurity Reference Architecture deck. On the left side of the attack are the things we can do to prevent it. I would argue that almost every cyberattack can be prevented with basic controls. When you look at the news and break down what happened in many major attacks, the root cause is often basic: a director's account without MFA, a login from another country with no blocking controls, port 3389 left open, or an Exchange server that was not patched.

Examples such as the Disney Slack hack or the Okta breach are often described as sophisticated, but the reality is usually poor configuration. The word sophisticated can soften the blow, but in many cases the basics were not done properly.

Now that inforcer supports posture management across these Microsoft areas, we want to make it easier for partners to cover both sides of the attack timeline. On the right side, inforcer TDR can help detect, respond and recover. On the left side, the signals from TDR can inform which preventative controls should be applied.

For example, if we see issues around access and identity, one protection could be blocking legacy authentication. Legacy authentication does not support MFA, so you can create a conditional access policy that targets all users, all resources and legacy client apps, and blocks access. A note on conditional access policy creation generally: you should usually apply policies to all users and then work out the exclusions. If you start by targeting groups, you risk missing users when new accounts are created or circumstances change.

In this example, we create a conditional access policy that blocks legacy authentication and add it to a baseline tenant. We recommend customers have a baseline tenant. That baseline can include controls across Intune, Entra, Defender, SharePoint, Teams, Purview, Exchange, Microsoft 365 and Copilot. Using inforcer, you push those configurations down to customers and track drift between the baseline and customer tenants.

The initial signal does not have to come from having a complete baseline. It can come from day one with TDR. The signal from TDR tells you what needs attention, and then you use inforcer to make it evergreen. If the baseline contains a control, you can check whether it has been deployed to all customers and tenants.

Today, we relaunched the Align by Policy feature. This lets you look by policy to see whether a policy is missing from customer tenants. That is powerful for identity. For example, if you decide that blocking legacy authentication or blocking unsupported operating systems would reduce risk, you can pick that policy in inforcer, see which tenants are missing it and push it out at scale.

The takeaway is that TDR can protect you on day one, but it also informs you forever. You receive signals, use blueprints and baselines to understand what good looks like, and then deploy protections across tenants. As you scale and consolidate with Microsoft, we will continue adding TDR features that support Microsoft XDR and the broader Microsoft security stack.

Instead of seeing inforcer as only the middle of the attack timeline, you can now start on the right with inforcer TDR and move left by improving preventative controls, hopefully reducing the chance of the "boom" ever happening.

That is everything I had prepared. I am happy to answer any questions, including general Entra topics.

One question in the chat asks when TDR is being released to test and public GA. I believe the public GA timing is around September. It was important to give this recap because we did not get to identity becoming the central control by accident; there is a lot of context that led us here.

Another question asks what I would recommend enforcing in every tenant for Intune security. Within inforcer, we have Blueprint baselines, including templates around endpoint protection core and advanced. My personal core recommendations, especially for a Business Premium environment, would be to use Business Premium with Intune and Defender properly configured.

That means making sure Defender has an antivirus policy and that attack surface reduction rules are used. If you are not ready to block with ASR rules immediately, put them in audit mode for a few weeks and then move them to block mode. ASR rules prevent many common exploits. You should also make sure devices are patched, and consider using Autopatch and Hotpatch. Disable legacy technologies such as SMBv1 where possible.

Browser management is also important because a huge amount of work now happens in the browser. Have the conversation with customers about limiting the number of browsers in use and using the protections available in Microsoft Edge, such as SmartScreen, typo-squatting protection and scareware protection. With Entra ID single sign-on, you can strengthen access to cloud apps as well. Extension management is also important because malicious browser extensions are a growing issue. Do not allow users to blindly install extensions without control.

You can also continue these discussions in the inforcer Discord community. I will close the call now. Thanks for joining, and I will see you next time.