From the Blogosphere
First Steps in Computer Forensics: Securing Your Network
No matter how secure your infrastructure is, sooner or later you will become a victim of a computer crime
May. 18, 2012 12:30 PM
No matter how secure your infrastructure is, sooner or later you will become a victim of a computer crime. Someone may point a DDoS (Distributed Denial of Service) attack at your services, may sniff your network, or may copy/delete confidential information. You may not even realize such a thing has happened. However, in an organized and secured network, you will be notified at the first signs of an attack. Now what? Your first normal reaction would be to stop the attack with whatever means possible. However, that may not be the best response. If you don’t possess the needed knowledge yourself, it might be a good idea to leave the crime scene as it is and let a computer forensics investigator deal with it. Let’s focus on the steps that the investigator would take. You may choose to take these steps alone but you will most likely not have all the necessary support tools and systems for that.
- Document the system – name, date, time, purpose, hardware, software, it all matters.
- Collect evidence – all the information about the attack should be securely taken off the target system. This is usually done through specific software that hashes all the information. This way, the information is legitimate and can be used as formal evidence for prosecution. The evidence that is usually collected includes active network connections, processes loaded into memory, and a copy of all the information on the disk with the respective creation, modification, and access values. The collector should be confident about the security of the system used for storage and analysis of the copied evidence. Only after this step, is it beneficial to unplug or shut down the affected system. If the affected system is saving logs on a remote server, copy them as well, although they are less likely to be compromised by the attack. In Linux, programs could still be running even after their files have been deleted. You can search for such programs with the command: file /proc/[0-9]*/exe|grep “(deleted)” . If you want to make a copy of this list use: /bin/dd if=/proc/filename/exe of=filename .
- Recreate the timeline of the attack – once all the information is copied on a secured workstation, the timeline of the attack can be recreated from the times of creation, modification, and access of all the files. This should be done before anything else, because the other steps can change the original times of the files. The timeline will show the last executed file, the last created/deleted folder, executed scripts, etc.
- Deeper analysis of the affected system – using the information collected in the previous steps, a deeper analysis can be performed of the system in order to find suspicious installations, creation or deletion of folders, and the like. Forensics investigators have specific tools for this step.
- File information restoration – the slack or unallocated space can be investigated for parts of files that, when combined, may indicate the time of deletion of files. It can be useful for the recreation of the steps of the attacker.
- Search – use all the information gathered so far to search for specific names, IP addresses, and file names, that can point you to the intruder.
- Report – no matter if the compromised system is your company’s or another’s, it is always good to document all your findings during the investigation. If it’s done right it can even be used in court.
Don’t make the mistake of not taking computer crimes seriously! In today’s digital world, computer crimes are just as serious as any other ones. Don’t hesitate to call a specialist if you’re not sure you can handle the investigation process alone. If your organization is big enough and your budget allows it, think about creating a Computer Security Incident Response Team which will be prepared for computer crimes and will have procedures and resources in place to handle them properly.
Read the original blog entry...