Transcript OARtech Logging, Evidence

OARtech
Logging, evidence, and network
management
Brian Moeller, CISSP
10APR2002
Why are logs important?
Performance management
Capacity planning
Cost justification
Management reporting
Security

both for integrity and for incident response –
remember, security is there to *ensure* things
go as planned, not to prevent access
Network Responsibility
It’s your job to know what’s going on with
the network!
Logs are a wonderful troubleshooting tool
when things don’t go as planned.
The basics
The 3 Layers



Network
Operating System
Application
The basics
Authentication
Authorization
Accountability
Authentication
Most common authentication – Passwords
Authentication – the process of matching a
user to an account
Authorization
After a user is authenticated, the
permissions, connections, access, and
quotas assigned to a user.
Accountability
The process of keeping records of activity
The ability to answer the questions:
- Who did it?
- What happened?
- Where they were located?
- When it happened?
- How it was done and/or How much was
used?
What should you log?
Log enough to answer the questions…

Who, What, When, Where, How
Authentication logs


Show who logged on when
Don’t show who accessed what
What should you log?
What happened?



Application logs
File access/change logs
Keystroke logging/activity logging
What should you log?
Where were they located?


An updated network map is important
Naming conventions/Addressing policies
What should you log?
When did it happen?

Time synchronization between logs is an
issue
What should you log?
How was it done/How much was used??



Network traffic logs
Transaction logs
Access logs
Building a case
Use several logs to prove the same point





Authentication log shows user logged in
Access log shows access to files-in-question
Network logs shows traffic from workstation to
servers where files are located
Application logs show activity to process files
OS logs show operating system state during
activity
Building a case
Use several logs to prove the same point

Other application logs show access to other
applications during the same time period
(helps during an interview – “Yes, I did check
my e-mail at that time, and I did run that
application, but no, I certainly didn’t change
that file….)
Building a case
An example:





Workstation cache shows suspected activity
Network traffic logs indicate suspected activity
Files not found on workstation, but are found
in a recent backup
User maintains innocence
But…..
Building a case
An example:

But…..telephone records show phone calls….
Questions…but few answers
What should I log?

Log as much as is practical for your needs.
How long should logs be kept?


Be practical…a general rule of thumb is 3
months of ‘quick’ access, then another 3
months ‘offline’
Research, government, health care,
accounting, tax, DoD, and others may have
additional requirements
Questions…but few answers
How should the logs be kept?


As safely as practical – backups, check to
make sure what you want to log is really being
logged…
On a system that isn’t likely to be
compromised…
Sometimes difficult for some OS and Application
logs
Questions…but few answers
Who should have access to the logs

Only a limited number of people – they’re not
public logs…(see your legal department, your
mileage may vary)
How much should I log?

Be practical. Log more than you think you
might need, but not so much that it causes
problems with network or system
performance. Generally plan on 10% of
system
An ounce of Prevention…
Effort used to prevent incidents is well
worth it!
Use the logs to verify that the correct
things are happening, and to know what
happened when things don’t go well