Failure to Lognch
The requirements of engineers often roll downhill to the developers, where there's a lot of discretion.
Join the DZone community and get the full member experience.Join For Free
I had to fight tooth and nail to get this blog title. I hope it made you shoot air out of your nose with a little more thrust than usual.
Let’s spare a moment in solidarity with the VPs of Engineering out there. They have a crucial role to play in software security. Unfortunately, they are often asked by security to deliver a policy requirement X, such that:
- X is not well-specified
- X is not practically testable
- X is not part of stakeholder functionality
- X is not used by engineering
- X is not reflected in KPIs for engineering
- X does not come with budget
This is exactly the issue with security and audit logging. The requirement simply rolls downhill to the developers, where there’s lots of discretion applied. Thousands of policies don’t have the same effect as one line of code.
Obviously, there are huge gaps here. Many security-relevant events and actual attacks will be missed for the following reasons:
- The developers don’t know about that type of attack
- The attackers evaded the developers’ simple approach to attack detection
- The developers didn’t think an event was important
- The developers couldn’t possibly log it (i.e., it happens in library or runtime)
There are also more cynical reasons, like failure to care, or failure to prioritize. Developers aren’t incentivized on this in any way, so we’re really just hoping on goodwill.
Let’s talk solutions.
Automatic Log Enhancers
Instead of trying to teach developers about how to detect attacks and get logs regarding their security, Contrast Protect’s RASP technology just does it for you. Isn’t that better than arguing about it with security?
Contrast ships out of the box looking to instrument many core APIs with logging. Don’t you want to be alerted when a new .DLL or .so is loaded into your JVM process? How about when your end users authenticate with Spring library?
Here’s an example from the product. This Log Enhancer will automatically weave a message into your logs if the developer chooses to override how SSL hostnames are verified! Pretty cool!
As shown, you can control what the log message looks like and include the parameters, instance, return value, etc.
You can also add your own log enhancers to our product. You know what your APIs are, and chances are, some of them don’t do enough logging. You can use this feature to enhance the logs without requiring a code deploy.
Published at DZone with permission of Arshan Dabirsiaghi, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.