1 / 43

Security Audit

Security Audit . Prabhaker Mateti. What is a security audit?. Policy based Assessment of risk Examines site methodologies and practices Dynamic Communication . What kinds of Security Audits are there?. Host Firewall Networks Large networks . Security Policies & Documentation .

omer
Download Presentation

Security Audit

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related