Consider logging with OWASP Security Logging

[javabeanz]

It could be useful for AppSensor to log via the OWASP Security Logging framework : https://github.com/javabeanz/owasp-security-logging.

[jtmelton]

@javabeanz thanks - good suggestion. I'll look into this probably for 2.4. I also need to look at the adapter approach to let those using OWASP security logging do appsensor events out of it if desired.

[spoofzu]

Today one of the security challenges with the JVM is that it operates like a blackbox from the security perspective. Tools exist for performance and diagnostics but neither support security very well. For example, performance metrics typically provide information like loaded classes, instance counts, heap/GC info. Whereas from the appsec perspective we would rather have a fully qualified file name, CRUD operation performed, etc. Diagnostics tools provide more information but are not generally designed to run in production and slow things down. Diagnostic tools also have the tendency to flood systems with information and once again most of the information is superfluous from the appsec perspective. Thinking about the events or granularity, my thought is to push the information out and try not to aggregate or correlate the information too much, unless it makes sense, and leave this to SIEM tools. I have been experimenting with code to export JVM events and log them using the OWASP Security Logging API. Some JVM security instrumentation I have been considering: tracking changes to the SecurityManager, socket operations(open/close), URL, SQL queries for different systems(JDBC but perhaps others), file operations(CRUD), J2EE web application stack monitoring (startup,shutdown), exporting exceptions (regardless if developer sinks them). There needs to be practical way to tune this of course. For example, maybe we only want file CRUD operations performed outside the applications root or anything made to /etc for example. On top of all this the security logging framework adds a watchdog thread captures and logs information like the following at user defined intervals,

20:10:10.204 [Thread-0] INFO Watchdog: MemoryTotal=64.5MB, FreeMemory=58.2MB, MaxMemory=947.7MB, Threads Total=5, Threads New=0, Threads Runnable=3, Threads Blocked=0, Threads Waiting=2, Threads Terminated=0

For additional background see, http://www.securitycurmudgeon.com/2016/03/owasp-security-logging-project-explored.html. Since it's the JVM that's instrumented, no code changes to the app are required so it works out of the box with your legacy apps. Security for legacy apps, what a concept. For the technology to do this, I experimented writing my own javaagent at Sytze's suggestion. It worked but had some limitations, instrumenting abstract and native methods for example. Seems likely there's ways to get this information but I didn't spend too much time on it. Next, I experimented with JVMTI and had some success as well. Both of my samples with each type were limited and each technology offers advantages/disadvantages. Then I discovered the BTrace framework. Following is a small BTrace Java code example to bind a socket.

@OnMethod( clazz="java.net.ServerSocket", method="bind" ) public static void onBind(@Self ServerSocket self, SocketAddress addr, int backlog) { sockAddr = addr; }

The first part identifies the class and method to bind. I believe the second is the code to inject. I'm not a BTrace expert but it seems like an interesting project to co-opt for JVM security. My reason for the post is to stimulate ideas. Share what I'm experimenting with. See who's interested in this stuff, etc. Anyone have BTrace experience? Reasonable performance? Noticed it's open source Oracle code. Next, anyone have thoughts beyond what I already provided to capture security events from the JVM? What types of JVM security information would you like to catch? I'm interested in anyone's thoughts/experiences on this stuff.

[jtmelton]

@javabeanz @spoofzu This could be useful for a generic way to capture events that are JVM specific, for sure. We've had a couple users go the route of java agents, though I've not seen anyone using JVMTI or BTrace, and I only have very limited experience with agents. This is an area I think users want, to be honest. Having said that, we've spent our time thus far on the appsensor-reverse-proxy, as it's cross platform. I think there's a lot of value in the JVM platform hooks, though, particularly as the JVM is so widespread.

[spoofzu]

@javabeanz @jtmelton FOLLOW-UP: Along the way I discovered there is a category of security tools that captures what I was trying to do, RASP. Ouch, more acronyms. RASP is an emerging technology in the security tool space. I don't have a good idea of all the tools in the space just yet. As a concept I think RASP is positive. Implementation will remain a challenge since there's a lot going on inside the JVM and extracting can easily impact performance. Unfortunately, BTrace can't help me with the heavy lifting. It turns out BTrace is not useful for security purposes. It's an interesting concept but it comes with a number of restrictions that make it impractical.

[jtmelton]

@spoofzu @javabeanz yeah, there's a few commercial tools I'm aware of: prevoty, quotium seeker (renamed something else now I think), contrast, waratek. The space is new, but growing, and all these tools work a little differently. They each have pros/cons like any other tool, and each have their place like any other tool. Google had an interesting preso in this space (https://conference.hitb.org/hitbsecconf2012kul/materials/D1T2%20-%20Meder%20Kydyraliev%20-%20Defibrilating%20Web%20Security.pdf) .