A few months ago a customer asked me about how to integrate custom applications and SIEM. The customer developed a Java application using a Tomcat container and the question came from an insurance company.

Custom applications

Any service-oriented enterprise I know develops business applications by itself. I would say that most of them are still using Java EE with Tomcat and/or JBoss. All applications I reviewed used logging for diagnostic: application event/error logs are used to troubleshoot transactions and user behavior. In other words, logging is used to find out issues and bugs.

Hardly anyone takes care of writing security events. That’s a cultural problem: considering the history of ICT, Cyber-threats are a recent phenomenon that most stakeholders are unaware of.

Identifying threats

For the sake of this post, the question is not about how to modify the application, but about which events we should log. This is not a new topic at all, and speaking about application security we should mention OWASP.

OWASP AppSensor is a framework used to develop Java-based “self-defending applications”. Even if the project is outdated and unmaintained, the guidelines are a good starting point to identify events that should be logged. The OWASP AppSensor Guide describes 8 case studies identifying useful events that should be logged.

On page 35, for example, an e-commerce B2C application is described as finding three objectives:

1. Identify attacks as soon as possible and track how they evolve.
2. Identify attacks against the application logic (catalog, cart, payments).
3. Identify attacks against the database logic (SQL injection).

The guide continues suggesting how to improve the application visibility: each event type must have a threshold beyond a security exception should be raised.

There to start from

Changing enterprise core applications is a critical topic: adding or changing functions could add an unsustainable latency which could badly impact the user experience. Moreover, most enterprise applications cannot log everything because the amount of logging will be soon unmanageable.

A risk-based approach, once again, helps to identify which events should be accounted for: a financial application has different requirements than a CMS.

Chapter 14 helps us to develop a self-defending application. We can see on page 51 some events we should consider:

• failed authentication (I failed to login);
• failed authorization (I’m trying to access a content I do have not the privilege of);
• invalid user input (I’m typing something I should not);
• code injection (e.g. SQL Injection);
• high usage (I’m exceeding the expected page/function rate within 5 minutes).

In my opinion, the above 5 events should be logged on any application.

Finally, logs are useless if they cannot be correlated: logging must use a specific format supported by SIEM. Otherwise, nobody will manually read them line by line.

RASP solutions

RASP (Runtime Application Self-Protection) is the ready-to-be-used framework that adds security and visibility features: a custom library should be added to the application to automatically enable self-defend capabilities. OWASP AppSensor was a good open-source example.

RASP is not WAF (Web Application Firewall): WAF analyzes user-application interaction, RASP verify also the impact on the application itself. In other words, RASP can also see how the application behaves.

A SANS pager compares WAFs and RASP AppDefend from HP.

Honestly, I place WAFs and RASPs into two different security layers: they use a different logic and require a different approach. Speaking about RASP I see pros and cons:

• Pro: implemented quickly and wide SIEM compatibility.
• Cons: expensive and (small) latency.

Serverless and PaaS applications

There is a new emerging interesting topic: PaaS or serverless based application. Referring to applications delivered via PaaS or serverless functions, I can see that cloud providers are embedding many security features by default. Starting from logging, AWS and GCE embed a lot of logging functionalities by default. The problem is not about logging in a SIEM-compatible format, because this task is fulfilled by the cloud platform.

The open problem is about log monitoring (threat detection): even if some SIEM platforms are starting to integrate cloud platforms, I expect that cloud providers will offer soon ready-to-be-used SIEM with actionable insights (i.e. Google Chronicle ).

Conclusions

In my daily work, I see that Cybersecurity awareness is increasing. Maybe months ago Cybersecurity was a topic confined to CISOs and Cyber-specialists; nowadays I see many non-tech organization units questioning me about Cybersecurity: OT managers and developers are asking how to make the world more secure. Not only because security is necessary, but also because it’s a competitive value.

References

• OWASP AppSensor Guide