full-disclosure - Things that make you go "Hmmm"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c2573e05030407081682b87b@mail.gmail.com>
From: smp.repicky at gmail.com (Matt)
Subject: Things that make you go "Hmmm"

Actually the point of policy is not to determine HOW the person who is
investigating the response will do their job, but how the machine that
is held suspect will be treated.

Some sample policy guidelines will include whether the machine is to
remain on until a forensics expert can look at the machine and make an
active backup of it while it is running...  Or if it is to remain on,
but not connected to the internet thatway no damage can be done to
other machines through the suspect machine...  Or if the machine is to
be immediately turned off.

Forensics investigation is not something that can be controlled by
policy.  It can be very different on each machine you study.  There
should only be a 3 part policy restricting IR professionals.

1.  Document everything.  From the time you get the call that
something is wrong, to when you arrive at the machine (including the
presence of physical security around the machine), until you are
completed with your investigation and are ready to give your report.

2.  Do not let other people influence your work...  Because someone
always has an agenda, whether it's to find A problem or put the blame
on A person, don't let that direct the way you go about your
investigation.  You might find out they're trying to pin it on someone
who was someplace they weren't supposed to be, but really the machine
was hacked by someone else long before that which allowed that person
to get to where they shouldn't have been.  And if you let them
influence your work you might not have found the original breach.

3.  Make backups of EVERYTHING before you even start.  If you can
avoid changing something, don't make the change.  Think of it in the
way your parents taught you how to behave... "Look, don't touch."

--

On Thu, 3 Mar 2005 23:15:15 +0000 GMT, Jason Coombs <jasonc@...ence.org> wrote:
> Matt wrote:
> > In a good company Incidence
> > Response isn't dictated by any of
> > what you said above.  It's dictated
> > by policy.
> 
> Good point. Even in a good company, though, incident response often occurs outside of policy.
> 
> An incident response professional who works for clients during emergencies is presented with variables and circumstances with which to contend, not a policy playbook to follow.
> 
> I agree that it would be nice if we could schedule and plan all of our emergencies according to policy. :-)
> 
> Cheers,
> 
> Jason Coombs
> jasonc@...ence.org
>