What we do
Over the last 18 months, Softcat have offered its customers an Incident response service. We’ve recently looked back at the different interactions we’ve had with customers in this service, and we found a raft of lessons learned, as well as a single common denominator across incidents: Office 365.
Now to be clear, this common denominator is not the platform itself. Although not without its own vulnerabilities, the root cause of the issue consistently found across incidents was the user configuration of O365. Looking over the array of customers, industries, and incidents, we found our customers usually fall into 1 of 3 categories when it comes to security incidents within Office 365.
Being transparent, configuring Office 365 for optimum security is easy for me to say, and not simple to do. These customers will initially migrate to Office 365, and, for the most part, stick with default settings, owed either to diverted attentions, or lack of expertise. Unfortunately for these customers, the chances of survival in an incident, if they’ve not configured baselines, or additional controls is close to zero. Here’s why.
One of the first steps an attacker will take is called reconnaissance, and before O365 this meant understanding which version of exchange, Active Directory, etc. you were using, to then understand the potential vulnerabilities available to them for exploit. In the days of Office 365, any attacker with a credit card and a keen attitude can spin up an instance and for these first customers, the reconnaissance is done. Attackers are standing up instances just like you, they know what will and will not work if enabled by default. Of the incidents we’ve seen, 70% of customers fall into this category.
Here we are regularly seeing some simple steps being missed such as multifactor authentication (MFA) not being deployed. To reiterate – deploying MFA is a security must, and has been shown to block 99.9% of account compromise attack. The number one reason for not deploying this control is concern about potential user disruption, or concern over systems failing. Whilst a legitimate concern, with the right preparation and the correct amount of user training, MFA can be deployed relatively painlessly and mitigates a huge amount of risk.
These customers build on the above – after migrating to Office 365, these customers get the basics right – deploying MFA, some security controls, and even some of the solutions provided within E5 licencing. Additionally they may have one or two other security controls deployed, such as switching
on advanced logging. These customers make up approximately 30% of incidents we see. The challenge here is that customers are lulled into a false sense of security under the belief that “the controls in E5 are good enough.” Sadly, defence in depth architecture, and in our own experience of dealing with incidences you ideally need two- three additional layers to survive email-based attacks. Whilst having steps such as DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) are both good controls, these only look at the header – the envelope of the message. To survive email-based attacks the key is content based email security inspection.
Another trend we’ve found in the ‘intermediate’ customer is that of visibility. Whilst the deployed controls are all well and good, it only works if solutions are available that raise alerts, and that technicians are actively looking at and acting on those alerts. Broadly the key visibility can be grouped into three areas:
This customer has everything switched on and optimised, and operate, for the most part, a reasonably secure infrastructure. Unfortunately the challenge now presented is that of business email compromise (BEC) between trusted organisations. Unfortunately this one is really difficult. The focus here is all about supply chain security, which is an issue that cascades. Whilst you may be happy your supplier is secure, the supplier of your supplier, could be vulnerable.
For these customers, the key comes down to the devil of Active Directory. As mentioned before, if you have not configured MFA across the domain you have a very large attack vector exposed, but we’ve seen attackers go further even when MFA is deployed. Active Directory Federation Services (ADFS) essentially serves as the proxy between active directory and the web. Some attackers, when realising you run MFA in Office 365, will look to find an intranet site, or portal etc. that uses ADFS, but doesn’t use MFA. Then it is just a question of brute force, credential stuffing etc. until the account is exposed. We’ve even seen attackers going after outlook web app, and other sites, to this effect.
For our customers, this doesn’t have to be the case. For Softcat customers (and I’m pleased to say, the customers that have utilised our incident response services) when it comes to security, and specifically Office 365, you have oodles of support available to you, detailed below:
If you’d like to discuss this in more detail, please contact your account manager, of If you’re new to Softcat, via the button below.
We would love to hear any comments you have about this article!