My Monitor Your Routers post touched on the idea of trust. I'd like to talk about that for a moment, from the perspective of an operational security person. I'm not qualified to address trust in the same way an academic might, especially since trust is one of the core ideas of digital security. Trust can be described in extreme mathematical detail and in some cases even proven. I don't know how to do that. Instead, I'm going to describe how I decide what I trust when performing network incident response.
The diagram above shows the level of trust I have in the evidence or operation of various devices. I've broken them down into four categories. My trust decreases as the level of interaction with users increases. This is not a slam on users. Rather, it's a reflection of the idea that the level of exposure increases as one considers a device that is operated at the whim of a human.
At the very bottom of the pyramid would be a person on his/her user platform. This could be a PC with a user browsing the Web, reading email, chatting on IM, swapping files on P2P, etc. (Administrative rights worsen the situation but are not necessary to make my point.) It could also be a smart phone or other powerful portable general computing device. Because of the extreme number and diversity of attacks against this victim pool and the relative vulnerability of the platform, I hardly trust anything I see when interacting with a live victim system. An image of a victim system hard drive is more trusted than the same system viewed via a potentially compromised operating system, but memory- or hardware-resident attacks confuse that situation too.
I trust servers more than clients because servers typically offer constrained means by which users access the server. A properly designed and deployed server provides limited access to computing resources, although administrators typically interact directly with the platform. Sys admins are presumed to be more vigilant than regular users, but the level of exposure of services and the fallibility of human admins relegates the server to only one notch above client systems in my pyramid.
Next comes infrastructure. These are systems which carry user traffic, but users aren't expected to directly interact with them as they might with clients or servers. Again, admins will interact with the infrastructure, but most infrastructure is not a general computing platform with a very powerful shell. Note that users (and therefore attackers) can determine the existence of infrastructure when it interferes with traffic, as is the case when ACLs block communications. Infrastructure with directly addressable interfaces are more vulnerable to interaction and therefore less trusted than infrastructure with no directly addressable interfaces. For example, an unmanaged switch is potentially more trusted than a managed switch offering an administration interface.
At the top of the pyramid we find sensors. This being a Network Security Monitoring blog, you would expect that! The reason I trust my network sensors so much is that, when properly designed and deployed, they are invisible to users. They do not act on traffic and therefore cannot be discovered. When remote connectivity is required, my sensors do need administrative interfaces. That is a potential weakness. Furthermore, like all devices with TCP/IP stacks, they are susceptible to high-end attacks against the stack itself or the inspection applications watching passing traffic. These devices (really, no devices) can therefore be perfectly trustworthy, but they are leagues above the desktops at the bottom of the pyramid.
For a while I've held out hope that memory snapshots taken in some reliable manner might give valuable insights into the state of a victim system, thereby revealing useful evidence. I mentioned this last year. Now I read Joanna Rutkowska is demolishing this technique too. Back to the bottom of the trust heap goes the desktop!
0 komentar:
Posting Komentar