Incident Preparation & Responce

Incident Preparation(few words)

In order to complete the preparation for an incident , there should be a good knowledge of the following in advance:

Good knowledge of the OS that we administrate
Understanding of what we are protecting
Confirmation of securing all possible "entrances" (deamons/services)
Confirmation of defence preparation in all levels
Defence monitoring for early signs of an incident

The above should be supported by strct security policies as well as from strict firewall and Access Control Lists rules.

Incident Response

There is a part missing that analyses the tools that are needed for an incident(maybe in another blog).

In incident response we document our every move, so that the precess can be repeated, so that we can prove what was the process followed and that the process followes the international standards, in order to answer to a question in a court of law , etc...

The best way to collect and document evidences and at the same time avoiding any errors during the execution of a forensic analysis is via implementing the whole process as a methodology.

Researching the internet for such methodologies , I noticed that many sysadmins do not often have a specific procedure that follow in such cases.

Also , it has been identified that in a case of a successful break in, the administrator just reinstalls the operating system from a safe medium.

This move however , is bound to faiilure ...

Since there was no Root Cause Analysis, that is the reason that someone penetrated the system in order to secure it, then it is certain that it will happen again.

Also I have to mention that in the case where no forensics are applied to the system which was hacked, there are no proofs of what happened, how, when, from where and whom. Ussually this leads to estimations of what has happened to fill in the gap.

When we are gathering evidences in an incident we must ASSUME NOTHING.

Decisions should be taken based on facts and strong clues and evidences.

Unfortunately when we talk about security there is not such software or golden rule that will keep a system unbreakable...

EVery command and basically everything else that takes place in a system analysis shoudl be logged. Every command, with its exact parameters, should be logged for reasons of verification(if needed)

In this way , there is a log created that allows in anyone to follow your steps with detail

For example, instead of declaring : "Audit settings check", it should be declared as ,how did the check was done, including all the commands tht were used, their parameters, or even which GUIs where used.

Tools located on the suspect machine should NOT be trusted for obvious reasons. You should be use the equivalent programs from a secure read only medium.
During the incident response , you have to be very careful not to write anything on the suspect machine hard drive, but this can be subject to each company/organisation policy. If the purpose of this policy is to keep the integrity of the system while at the same time minimising its offline time, then nothing should be written on the hard drive and you should seek other ways to maintain and transfer of (to be collected) data.

Furthermore, it is important to know what appliciations, services are running on the system as well as what was its initialisation/configuration.
In this way we might spot easier suspect applications and services .

When we check/open any file on the system we alter their date(last accessed) destroying in this was valueable data.
During the initialisation of a system ,the best practices urge you to remove any unwanted and/or unused services as well as executable applications from the system.
Furthermore, the system should be fully patched and have proper security settings as well as proper security policies.
The steps that follow the suspect machine analysis are the following(documentation):

Current Date/Time and suspect machine date / time
connected users to the suspect machine
applications runnning per user
Analytically what resources is each application is using?
What libraries/modules are loaded
what ports are open by which application
what are their initialisation parameters and time that the applications is running
Network information, such as routing, connection statistics, ip , dns, dhcp, subnet
promiscuous mode detection.

-->Memory dumps(either per process or full memory dump)

-->HD Image(for analysis)

That was a methodology analysed :)
Do you think is not good? Do you have a better proposal? Let's discuss it...