2
Building Security In Editors: John Steven, [email protected] Gunnar Peterson, [email protected] JANUARY/FEBRUARY 2011 1540-7993/11/$26.00 © 2011 IEEE COPUBLISHED BY THE IEEE COMPUTER AND RELIABILITY SOCIETIES 91 RICHARD BEJTLICH General Electric JOHN STEVEN Cigital GUNNAR PETERSON Arctec Group Directions in Incident Detection and Response this makes IDR much more dif- ficult and what these new targets mean for IDR. We, in turn, offer tactics on how application secu- rity teams can help. — John Steven and Gunnar Peterson Richard Bejtlich: As the leader of a commercial computer incident re- sponse team providing services to my company, I fear that industry’s IDR model is inadequate. One way IDR fails involves the identification of application-level compromises. Application misuse and abuse, which aim to access data, differ from intrusions, which aim to gain persistent control of the target OS. In attacks on applications, intruders likely seek unauthorized access to data and in some cases might desire unauthorized alteration of data. In contrast, traditional IDR models tend to assume that attackers seek to compromise the target platform, with the primary objectives be- ing the deployment of a persistence mechanism, remote command and control, and access to privileged ac- counts. With this in mind, I make four assumptions concerning the application-centric-security world. First, organizations expect their security teams to increasingly expand their expertise beyond humanly possible levels. Teams probably don’t possess the deep domain knowledge necessary to understand one or two applica- tions, never mind the dozens, hun- dreds, or thousands operating in the enterprise. So, security teams probably don’t understand applica- tions, let alone effectively identify subtle attacks against them. Second, teams must understand subtle activity; failing to do so might cause them to miss the only precursor to actual exploitation of an application. Assuming exploi- tation takes the form of a massive dump of data from the application, security teams might identify a successful attack. However, by the time a team recognizes the mas- sive dump in progress, the attack might have progressed too much to effectively stop. In the end, the security team has a chance to re- alize an attack happened, but only after the fact. Third, instrumenting appli- cations to provide information on subtle activity poses differ- ent challenges than instrument- ing network-connected devices in general. Suspicious and malicious access to an application might manifest itself only as slightly ab- normal interaction between the T his issue, Richard Bejtlich leads a conversation on how incident detection and response (IDR) teams’ focus on detecting and preventing attacks has moved from targeting OSs to unauthorized- access-application functionality and data. He discusses why attacker and application, within the application’s established pa- rameters. For example, an attacker probing or exploiting a Web appli- cation might access it via HTTPS- encrypted traffic, which might be opaque to traditional network- based sensors. Logs might prove more important than other infor- mation sources, but understand- ing logs is a tall order. The need to rely on different instrumentation methods puts analysts in a new, uncomfortable position. Finally, learning to understand application-level attacks will like- ly frustrate IDR teams. Analysts who share log details might ex- pose sensitive information. They might also be forced to understand a unique instance of an applica- tion and not find peers who can help interpret the output. Analysts probably aren’t going to find class- es that teach how to interpret the logs on which they rely. If these assumptions prove at least partially correct, organizations will have more difficulty defending their systems in a world where intruders care more about accessing and ma- nipulating data than about seeking to control OSs. This seems coun- terintuitive, because controlling the OS affords the intruder greater freedom of maneuver compared to application misuse or abuse. How- ever, if the intruder cares only about interacting with data on his or her terms, and succeeds, why should the intruder care about whether he or she “owns the box”? What can we do about this sce- nario? I don’t believe we can equip security analysts with much more
