1. Security Audit Prabhaker Mateti

2. What is a security audit? Policy based Assessment of risk Examines site methodologies and practices Dynamic Communication

3. What kinds of Security Audits are there? Host Firewall Networks Large networks

4. Security Policies & Documentation What is a security policy? Components Who should write it? How long should it be? Dissemination It walks, it talks, it is alive.. RFC 1244 What if a written policy doesn't exist? Other documentation

5. Components of a Security Policy Who can use resources Proper use of the resources Granting access & use System Administrator privileges User rights & responsibilities What to do with sensitive information Desired security configurations of systems

6. RFC 1244 ­ ``Site Security Handbook'' Defines security policies & procedures Policy violations Interpretation Publicizing Identifying problems Incident response Updating

7. Other Documentation Hardware/software inventory Network topology Key personnel Emergency numbers Incident logs

8. Why do a Security Audit? Information is power Expectations Measure policy compliance Assessing risk & security level Assessing potential damage Change management Security incident response

9. When to audit? Emergency! Before prime time Scheduled/maintenance

10. Audit Schedules Individual Host 12­24 months Large Networks 12­24 months Network 12 months Firewall 6 months

11. How to do a Security Audit Pre­audit: verify your tools and environment Audit/review security policy Gather audit information Generate an audit report Take actions based on the report's findings Safeguard data & report

12. Verify your tools and environment The golden rule of auditing Bootstrapping problem Audit tools The Audit platform

13. The Golden Rule of Auditing Verify ALL tools used for the audit are untampered with. If the results of the auditing tools cannot be trusted, the audit is useless

14. The Bootstrapping Problem If the only way to verify that your auditing tools are ok is by using auditing tools, then..

15. Audit Tools ­ Trust? Write them yourself Find a trusted source (person, place) Verify them with a digital signature (MD5)

16. Audit Tools ­ the Hall of Fame SAINT/SATAN/ISS Nessus lsof /pff Nmap, tcpdump, ipsend MD5/DES/PGP COPS/Tiger Crack

17. The Audit Platform Should have extraordinary security Submit it to a firewall+ type of audit Physical access should be required to use No network services running

18. Choosing a security audit platform: Hardware laptop computer three kilograms or less graphics display MB memory MB disk ethernet (as many connectors as possible)

19. Choosing a security audit platform: Software Unix / Linux Secured OS OS source code Audit tools Development tools

20. Unix / Linux BSD: FreeBSD, SunOS/Solaris, OpenBSD ? Source code A good development platform Large body of available literature

21. Audit/review security policy Utilize existing or use ``standard'' policy Treat the policy as a potential threat Does it have all the basic components? Are the security configs comprehensive? Examine dissemination procedures

22. Security policy Treat the policy as a potential threat Bad policies are worse than none at all Good policies are very rare Look for clarity & completeness Poor grammar and spelling are not tolerated

23. Does it Have All the Basic Components? Who can use resources Proper use of the resources Granting access & use System Administrator privileges User rights & responsibilities What to do with sensitive information

24. Are the security configs comprehensive? Details are important! Addresses specific technical problems (COPS­like tests, network services run, etc.) Allowable trust must be clearly outlined Should specify specific tools (The TCP wrappers, S/Key, etc.) that are used Must have explicit time schedules of security audits and/or tools used Logfiles must be regularly examined!

25. Examine dissemination procedures Policies are worthless unless people read and understand them Ideally it is distributed and addressed when people join org E­mail is useful for updates, changes Written user acknowledgment necessary

26. Gather audit information Talk to/Interview people Review Documentation Technical Investigation

27. Talk to/Interview people Difficult to describe, easy to do Usually ignored Users, operators, sysadmins, janitors, managers… Usage & patterns Have they seen/read the security policy?

28. Talk to/Interview people (cont.) What can/can't they do, in own words Could they get root/system privileges? What are systems used for? What are the critical systems? How do they view the security audit?

29. Review Documentation Hardware/software inventory Network topology Key personnel Emergency numbers Incident logs

30. Technical Investigation Run static tools (COPS, Crack, etc.) Check system logs Check system against known vulnerabilities (CERT, bugtraq, CIAC advisories, etc.) Follow startup execution Check static items (config files, etc.) Search for privileged programs (SUID, SGID, run as root) Examine all trust

31. Technical Investigation (cont.) Check extra network services (NFS, news, httpd, etc.) Check for replacement programs (wu­ftpd, TCP wrappers, etc.) Code review ``home grown'' programs (CGI's, finger FIFO's, etc.) Run dynamic tools (ps, netstat, lsof, etc.) Actively test defenses (packet filters, TCP wrappers, etc.)

32. Run Static Tools Nmap SAINT/SATAN/ISS Crack Nessus COPS/Tiger

33. Follow Startup Execution Boot (P)ROMS init Startup programs (rc.* like files)

34. Check static items Examine all config files of running processes (inetd.conf, sendmail.cf, etc.) Examine config files of programs that can start up dynamically (ftpd, etc.)

35. Search for privileged programs Find all SUID/SGID programs Look at all programs executed as root Examine: –Environment –Paths to execution –Configuration files

36. Examine all Trust rhosts, hosts.equiv NFS, NIS DNS Windowing systems User traffic and interactive flow

37. Check Extra Network Services NFS/AFS/RFS NIS News WWW/httpd Proxy (telnet, ftp, etc.) Authentication (Kerberos, security tokens, special services) Management Protocols (SNMP, etc.)

38. Check for replacement programs wu­ftpd TCP wrappers Logdaemon Xinetd GNU fingerd

39. Code review ``home grown''/non­ standard programs Network daemons Anything SUID, SGID Programs run as system account CGI's

40. Code review, etc(cont.) Bad signs: –external commands (system, shell, etc.) –/usr/ucb/mail –large size –No documentation –No comments in code –No source code available

41. Actively test defenses packet screens TCP wrappers Other defense programs

42. Safeguard Data & Report Save for the next audit Do not keep on­line Use strong encryption if stored electronically Limit distribution to those who ``need to know'' Print out report, sign, and number copies