Application-level monitoring and SOC

Background

Before we can even talk about how to deal with monitoring applications at a security level, we need to address a difference between an on-premise SOC and a managed SOC.

Modern security monitoring is very good at understanding hosts, identities, and infrastructure.
It is far less effective at understanding what applications are actually doing.

An on-premise SOC has a dedicated staff and budget to handle one organisation and one organisation alone. They understand the landscape fully - every little detail.

Managed SOC are spread across a number of different organisations and strive towards delivering detection and incident response in a uniform way with as few customisations as possible. This is to ensure that one can rotate analysts between clients and maintain the same level of diligent monitoring and response 24/7.
Of course, the benefit here is that because the managed SOC handles multiple organisations they are able to benefit from a larger dataset to create detections from.

The problem

First: Why do we even want application-level monitoring?

Isn't it enough that we detect malware on the host the application is running on?

No, because an application may be the early warning sign that you needed before it all went to hell. Or! The application itself is executing commands on behalf of a threat actor - they may seem benign at a OS-level, but in fact someone else is in charge.

If the SOC cannot determine if an application is operating normally or maliciously then there is a blind spot in the detection.

Applications are a special area when it comes to security. They do not follow a standard when it comes to logging or monitoring.
In fact, they are pure chaos - there are probably as many different formats of logging and auditing as there are applications.

Each application:

• Logs differently
• Uses different terminology
• Encodes business meaning in ways only the development team understands

This means SOC needs to understand every single application to know what is relevant in a detection scenario.

For a managed SOC, it can work if there are dedicated personnel that know the specific client and their applications. But that breaks the scalability - you are suddenly depending on key-personnel.
An on-premise SOC will have a broader understanding of the application and how to analyse any incidents, but will also face scaling issue as more applications are onboarded.

Onboarding applications

First I would like to emphasise that before you add a ton of work on the already heavy loads your cyber security and SOC people carry - consider this:

Of the hundreds or thousands of applications that are running in your organisation, which ones are critical for your business continuation?

The reason why I ask is that onboarding an application is not easy - it is actually quite costly.

Why?

Let us base the scenario on the worst case.

You have application AcmeApp - AcmeApp does not provide any kind of direct integration with your security monitoring solution.

AcmeApp does, however, provide a way of configuring its logging (lucky - there are applications that have almost no logging).

Because there is no provided integration from AcmeApp's side, here is where the problems begin:

Because AcmeApp does not have a vendor-provided solution for security monitoring - one has to be made.

In short what needs to be built (using Microsoft Sentinel as an example):

• Data connector to ensure the data is available for SOC
  • This can be a simple codeless connector if AcmeApp has an API that delivers structured data
  • Or it can be a more complex coded connector that runs on the host and integrates more deeply into AcmeApp.
• ASIM parsers where applicable so that the data is normalized and can be included in already established detection rules
  • For example: Sign-in logs - if the application logs this and you create a ASIM parser for the application, it can be included in the normal detections on sign-ins alongside Entra ID and other providers.
• Analytic rules to do the actual detection
• The data coming in through the data connector needs to be understood by SOC - it is domain knowledge. Understanding what the application is logging is key to create detection rules.
  • Again, if ASIM parsers can be used then the work is easier - but it depends on the data coming in.

If you want to see an example of what is needed, have a look at my BeyondTrust data connector.

The DevSecOpsSOC

The naming is a bit of a mouthful and is subject for renaming, but I have a thought that I think might merit a second of consideration.

Many companies have numerous developer teams pumping out applications and whatnot that drive value within the company.

The development is fast; pushing out changes every day. And the reality is that most of these teams are under the pressure of deadlines and budgets and who knows - security is a best effort kind of deal.

My thought is that the traditional SOC could benefit from a tight integration with the DevSecOps-teams. DevSecOps-teams do a great job of ensuring the supply chain is monitored and secured, credentials are safe, code analysis is in place and so on.

What is missing is this: Guidance how to enable the SOC to do great detection. Someone needs to tell the developers how to log security events and make them available for ingestion.

At a company level there should be a policy that states how security logging is to be implemented in any software developed. It should also state requirements for third party applications in this regard.

Additionally, as previously mentioned, it is important that the SOC understand the signals coming in which this addition would be able to help with.

This understanding can only come when the DevSecOps teams and SOC talk together - so how about we start making that happen?