Imagine that you are arriving at your office and you look through the window. Inside the building you can see someone burglarizing the building. What would you do?
You have a few options, you could (1) call the police; (2) you could ignore the burglary and go get a cafe' latte double mocha espresso and hope that the burglar leaves before anyone sees him; (3) or you could open the door to the office, and shout, "Hey! Get out!", wait for the burglar to leave.
In the real world, people routinely choose the first option. They do not run the burglar out of the house and then lock the door to preserve the scene before the police arrive, but for some reason, when it comes to cyber-crime, almost everyone chooses the third option. The burglar is long gone by the time the investigation starts. Evidence has been walked over, looked over, deleted and operating systems re-installed.
The "information assurance" community does a lousy job of ensuring that intrusions are handled appropriately. In my experience there is a community wide knee jerk reaction to intrusions that starts with looking at logs (rather than preserving them), moves into damage control (patching and re-instllation) and then, as an afterthought, calling in people who are qualified to respond to the incident. Harlan Carvey wrote recently that he had only conducted two live acquisitions for clients, and both of those were after operating systems were reinstalled, so I assume that my experience is not unique.
This is usually a response based on emotion, not logic. I know that I'm largely preaching to the choir here, but hopefully someone will wander in during this sermon - so here's what you need to do if you have been hacked:
1. Don't panic
2. Call someone qualified to investigate the incident.
3. Let the investigators investigate, image, analyze what's happen(ing/ed).
4. Develop a plan that will allow you to mitigate damage, determine the extent of the intrusion, catch the bad guy with your incident responders/law enforcement.
5. Implement the plan.
Thursday, July 19, 2007
Friday, July 6, 2007
Vista event IDs
An interesting note on Vista event logs in Eric Fitzgerald's blog.
He notes that event log IDs in Vista are "old" event id + 4096. There is also an explanation as to the reasoning behind using 4096 (as opposed to say, adding 1000 and keeping things simple).
He notes that event log IDs in Vista are "old" event id + 4096. There is also an explanation as to the reasoning behind using 4096 (as opposed to say, adding 1000 and keeping things simple).
Thursday, July 5, 2007
Moxie, Best practice and the Greek cell-hack
IEEE's Spectrum has a very good article in this month's edition that is worth taking the time to read. The article discusses the 2004-2005 hacking of Vodaphone. During the intrusion, the attackers were able to intercept the cellular phone calls of a number of people in Greece. People like the Greek Prime Minister (how do you say "ouch" in Greek?) and senior government officials .
From the article (emphasis mine):
[W]e can only speculate about various approaches that the intruders may have followed to carry out their attack. That's because key material has been lost or was never collected. For instance, in July 2005, while the investigation was taking place, Vodafone upgraded two of the three servers used for accessing the exchange management system. This upgrade wiped out the access logs and, contrary to company policy, no backups were retained. Some time later a six‑month retention period for visitor sign-in books lapsed, and Vodafone destroyed the books corresponding to the period where the rogue software was modified. . .
[D]ue to a paucity of storage space in the exchange's management systems, the logs were retained for only five days, because Vodafone considers billing data, which competes for the same space, a lot more important. Most crucially, Vodafone's deactivation of the rogue software on 7 March 2005 almost certainly alerted the conspirators, giving them a chance to switch off the shadow phones. As a result investigators missed the opportunity of triangulating the location of the shadow phones and catching the perpetrators in the act.
The all to frequent reaction of system administrators and managers to pull the plug on intruders.
Now I'll grant you that I am drastically oversimplifying the matter - I'm sure that having your government's head of state, Naval general staff and others played a significant role in the decision, but this response is not containment - it's often a knee jerk reaction to perceived liability. If a hacker has been in your system for a month, a week, or a year, is watching him for a day or two so you can determine the extentent of the penetration a bad idea? If you were investigating this incident, would you rather have a couple of days where the hackers were inside your system where you could track (and possibly identify them) or would you rather just close the door before you had figured out how they got in in the first place?
It is like being asked to choose between gathering volatile data while a system is still running and yanking the cord out of the wall - I'd choose the former every time. In an intrusion case, I'd argue that not gathering volatile data is tantamount to malpractice; and if presented with the opportunity to determine the full extent of an intrusion, you ought to take the opportunity, or you risk the same argument being applied to your actions.
Best practice in intrusions is to contain the intrusion so that the attacker is isolated, but allowed to continue to access the systems that he's accessing. If there are data that you can not allow out (classified or personally identifying information come to mind), part of the containment strategy should be to come up with either bogus data or a reason why the data can no longer be reached (i.e. "The server crashed, but we're working on it."). There are going to be cases where this will not be realistic, but it should be the starting point for any intrusion investigation. You will learn a lot more, a lot faster this way. This more moxie than just cutting the attacker off, but in the long run it is better for the investigation and ultimately for the victim to know all that there is to know about the intrusion by observing a "live patient" than would ever be discovered through an autopsy of a dead one.
From the article (emphasis mine):
[W]e can only speculate about various approaches that the intruders may have followed to carry out their attack. That's because key material has been lost or was never collected. For instance, in July 2005, while the investigation was taking place, Vodafone upgraded two of the three servers used for accessing the exchange management system. This upgrade wiped out the access logs and, contrary to company policy, no backups were retained. Some time later a six‑month retention period for visitor sign-in books lapsed, and Vodafone destroyed the books corresponding to the period where the rogue software was modified. . .
[D]ue to a paucity of storage space in the exchange's management systems, the logs were retained for only five days, because Vodafone considers billing data, which competes for the same space, a lot more important. Most crucially, Vodafone's deactivation of the rogue software on 7 March 2005 almost certainly alerted the conspirators, giving them a chance to switch off the shadow phones. As a result investigators missed the opportunity of triangulating the location of the shadow phones and catching the perpetrators in the act.
The all to frequent reaction of system administrators and managers to pull the plug on intruders.
Now I'll grant you that I am drastically oversimplifying the matter - I'm sure that having your government's head of state, Naval general staff and others played a significant role in the decision, but this response is not containment - it's often a knee jerk reaction to perceived liability. If a hacker has been in your system for a month, a week, or a year, is watching him for a day or two so you can determine the extentent of the penetration a bad idea? If you were investigating this incident, would you rather have a couple of days where the hackers were inside your system where you could track (and possibly identify them) or would you rather just close the door before you had figured out how they got in in the first place?
It is like being asked to choose between gathering volatile data while a system is still running and yanking the cord out of the wall - I'd choose the former every time. In an intrusion case, I'd argue that not gathering volatile data is tantamount to malpractice; and if presented with the opportunity to determine the full extent of an intrusion, you ought to take the opportunity, or you risk the same argument being applied to your actions.
Best practice in intrusions is to contain the intrusion so that the attacker is isolated, but allowed to continue to access the systems that he's accessing. If there are data that you can not allow out (classified or personally identifying information come to mind), part of the containment strategy should be to come up with either bogus data or a reason why the data can no longer be reached (i.e. "The server crashed, but we're working on it."). There are going to be cases where this will not be realistic, but it should be the starting point for any intrusion investigation. You will learn a lot more, a lot faster this way. This more moxie than just cutting the attacker off, but in the long run it is better for the investigation and ultimately for the victim to know all that there is to know about the intrusion by observing a "live patient" than would ever be discovered through an autopsy of a dead one.
Subscribe to:
Posts (Atom)
Posts
