Security Audit

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