Integrated Application Security Logging?
The taosecurity blog has an interesting post regarding application instrumentation. In it author Ricard Bejtlich argues that all applications should be able to defend themselves. This defense, according to Bejtlich, is defined as the ability to tell us “when they are abused, subverted, or breached”. Now I wouldn’t call this defense per se, but the I understand where he is coming from. Visibility into an application’s behavior or misbehavior is essential to properly respond to each situation. So, we’re all in agreement here, almost. Bejtlich writes:
I would like to see the next innovation be security application instrumentation, where you devise your application to report not only performance and fault logging, but also security and compliance logging. Ideally the application will be self-defending as well, perhaps offering less vulnerability exposure as attacks increase (being aware of DoS conditions of course).
While this is excellent, I think it fails to recognize one of the fundamental barriers to implementing such a system. The idea that an application has the ability to report information about security events, violations or what-have-you is great. The problem, however, is that because this functionality is found within the application’s runtime we may have some integrity issues. If that application is attacked and ultimately compromised the ability for that application to effectively communicate security event data with any sort of integrity is quite low. So low, in fact, that that function is useless. And this is exactly when we don’t want it to be.
This particular problem isn’t that new. The reference monitor, while not quite analogous, does provide some insightful parallels. In a nutshell, we cannot place the reference monitor-like functionality within the application’s runtime environment. If we do this, we seriously limit the effectiveness of its primary function. Now, the reference monitor concept isn’t a silver-bullet either, but the decoupling of that function from that of the application provides some compartmentalization and some level of non-bypassability (you can’t bypass the reference monitor by attack the application itself). Yes, you can attack the reference monitor and then attack the application, but you must do so in two discreet steps. This sounds strangely like an IDS doesn’t it?
So, I agree, we need the information, but is building it into every application the most effective way to do this? I don’t think it is.
Richard Bejtlich on 14 Jun 2007 at 12:45 pm #
Hello,
I’m glad you liked my post. Did you read this part?
So why isn’t security application instrumentation sufficient? The problem is one should not place one’s trust entirely in the hands of the target. One of Marcus Ranum’s best pieces of wisdom for me was the distinction between “trusted” and “trustworthy.” Just because you trust an application doesn’t make it worthy of that trust. Just because you have no alternative but to “trust” an application doesn’t make it trustworthy either. Trustworthy systems behave in the manner you expect and can be validated by systems outside of the influence of the target.
For most of my career my mechanism for determining whether systems are trustworthy has been network sensors. That’s why they sit at the top of my TaoSecurity Enterprise Trust Pyramid. In a host- and application-centric world I might consider a second system with one-way direct memory access to a target to be the most trusted source of information on the target, followed by a host reporting its own memory, then other mechanisms including application state, logs, etc.
You can’t entirely trust the target because it can be compromised and told to lie. Of course all elements of my trust pyramid (or any trust pyramid) can be compromised but the degree of difficulty (should) increase as isolation from the target is achieved.
roodee on 14 Jun 2007 at 1:04 pm #
Yes, I agree. I wanted to ensure that there was no confusion about the shortcomings and difficulty of building security instrumentation into applications for the purpose of detection and/or prevention. Sure it can be done and works perhaps in many cases any yet there is this uneasiness with that solution because it is so tightly coupled to the application.