OARtech

1. OARtech Logging, evidence, and network management Brian Moeller, CISSP 10APR2002

2. 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

3. 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.

4. The basics • The 3 Layers • Network • Operating System • Application

5. The basics • Authentication • Authorization • Accountability

6. Authentication • Most common authentication – Passwords • Authentication – the process of matching a user to an account

7. Authorization • After a user is authenticated, the permissions, connections, access, and quotas assigned to a user.

8. 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?

9. 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

10. What should you log? • What happened? • Application logs • File access/change logs • Keystroke logging/activity logging

11. What should you log? • Where were they located? • An updated network map is important • Naming conventions/Addressing policies

12. What should you log? • When did it happen? • Time synchronization between logs is an issue

13. What should you log? • How was it done/How much was used?? • Network traffic logs • Transaction logs • Access logs

14. 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

15. 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….)

16. 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…..

17. Building a case • An example: • But…..telephone records show phone calls….

18. 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

19. 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

20. 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

21. 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