MSSP Services: Critical System Availability
One of the interesting by-products of using a SIEM to monitor for security threats is that MSSPs can also offer availability monitoring of critical systems as part of the services bundle. Security is about protecting confidentiality, integrity and availability, so there is an obvious crossover with the network and system monitoring traditional managed services providers offer, but there are advantages to MSSPs offering it from a security point of view.
Security Overlaps with Service Management
Many large and mid-sized businesses outsource their IT to a service provider rather than try and maintain the systems using staff on the payroll. It’s much more cost effective to outsource to get the experience and ensure the service levels are maintained. Part of the reasoning for outsourcing is that the service provider offers several guarantees regarding availability that the organisation wants to ensure in order that they can continue their mission; IT is there as a business tool to use when it’s needed.
A cyber-attack can negatively affect these service levels as much as any hardware outage or failed patch update, especially from an availability perspective. Security’s purpose is to ensure business continuity; making sure an organisation’s information is available when its users need it and that access is only provided to those who have permission and the information is as its intended (i.e. nothing has been altered).
Figure 1 MSSPs should emphasise their support of IT service management as a value add
This intersection between what the MSSP and MSP (Figure 1) offer should be emphasised as a value-add to the customer, since availability is often the most important outcome requested in both contracts, at least from the point of view of its immediate impact on customers.
Take a ransomware attack, for example, where a user opens a malicious attachment and important business data on the fileserver is encrypted. The business has lost access to its vital business data and may struggle to meet its objectives if access cannot be restored. The customer will look to the MSP to recover the data and restore availability. In this case, the MSP is responsible for recovery, more than likely restoring the data from the last good backup. However, there is still a loss of service and potentially a loss of revenue for the customer, even if the recovery process works seamlessly.
In this scenario, the MSSP supports the business’s availability requirements, since monitoring for this ransomware threat and alerting the business (and the MSP) prior to the user clicking on the malicious attachment means there is no loss of service. This is the most obvious kind of supporting use case where security supports service management in meeting the business goals. However, there is another less-obvious use case that MSSPs should build into their sales pitch.
System Availability Monitoring
MSPs use enterprise monitoring tools to check for system uptime, application availability and responsiveness and ensure users have access to necessary cloud services. The events they receive from systems and applications are, in many cases, the same events MSSPs ingested into the SIEM tool to detect cyberattacks.
In some cases, where the log sources are system or application logs, the same events are analysed in slightly different ways: For an MSSP, monitoring the availability of log sources serves as a useful measure of whether a system is under attack. Loss of chatter from a log source doesn’t, of course, mean it’s under attack, but it could. It may be due to a simple hardware issue or scheduled maintenance by the MSP to install application or operating system updates, but equally could be because a sophisticated hacker has switched off event logging to cover their tracks.
When a log source goes dark, the SIEM should have the logic built into it to wait a given time and then raise an alarm with the security team. The incident response process should then begin with playbooks having the MSSP contact the MSP to see what’s going on. The MSP can then coordinate the response, with the MSSP providing support and assistance from a security point of view.
Integrate MSSP and MSP Services
MSPs and MSSPs often deploy monitoring agents (software installed on endpoints) onto the platforms they are looking after. MSP agents are used to monitor system performance and behaviour, but oriented towards understanding whether a system is suffering under stress of some kind that could result in a loss of availability.
MSSPs deploy tools onto endpoints that look for indicators of compromise or indicators of attack. By integrating the two organisations’ services together, the MSP and MSSP can signal each other when certain conditions are met, to ensure they react to incidents in a coordinated way.
An agent deployed by an MSSP may monitor system configuration files (such as the Windows registry) for unexpected changes, reporting this as a potential attack. If the MSP is running an application upgrade and it writes to the registry, the last thing they want is the MSSP alerting the customer they are under attack. This is not a good look for either organisation.
Rather the MSP should inform the SOC of their intended activities, so the agents deployed on site can be tuned to either ignore that behaviour through a given time window, or the MSSP can channel all alerts (and supporting information) to the MSP during that activity to allow them to vet what their own updates are doing.
Two Heads Are Better than One
There is no doubt that MSPs and MSSPs provide valuable and complementary services, and the different foci between the organisations means customers should be considering having both bases covered. MSSPs should get on the front foot and build integration with MSP services into their sales messaging and provide an onboarding guide for MSPs so both organisations understand their service boundaries. Service integration provides the greatest value for the customer, which should always come first.