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
• 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
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
 RFC 1244
``Site Security Handbook''

• Defines security policies & procedures

• Policy violations
• Interpretation
• Publicizing
• Identifying problems
• Incident response
• Updating
 Other Documentation
• Hardware/software inventory
• Network topology
• Key personnel
• Emergency numbers
• Incident logs
 Why do a Security Audit?
• Information is power
• Expectations
• Measure policy compliance
• Assessing risk & security level
• Assessing potential damage
• Change management
• Security incident response
 When to audit?
• Emergency!
• Before prime time
• Scheduled/maintenance
 Audit Schedules
• Individual Host 1224 months
• Large Networks 1224 months
• Network 12 months
• Firewall 6 months
 How to do a Security Audit
• Preaudit: 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
 Verify your tools and
environment
• The golden rule of auditing
• Bootstrapping problem
• Audit tools
• The Audit platform
 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
 The Bootstrapping Problem
• If the only way to verify that your auditing
tools are ok is by using auditing tools, then..
 Audit Tools Trust?
• Write them yourself
• Find a trusted source (person, place)
• Verify them with a digital signature (MD5)
 Audit Tools the Hall of Fame
• SAINT/SATAN/ISS
• Nessus
• lsof /pff
• Nmap, tcpdump, ipsend
• MD5/DES/PGP
• COPS/Tiger
• Crack
 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
 Choosing a security audit
platform: Hardware
• laptop computer
• three kilograms or less
• graphics display
• MB memory
• MB disk
• ethernet (as many connectors as possible)
 Choosing a security audit
platform: Software
• Unix / Linux
• Secured OS
• OS source code
• Audit tools
• Development tools
 Unix / Linux
• BSD: FreeBSD, SunOS/Solaris, OpenBSD ?
• Source code
• A good development platform
• Large body of available literature
 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
 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
 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
 Are the security configs
comprehensive?
• Details are important!
• Addresses specific technical problems
• (COPSlike 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!
 Examine dissemination
procedures
• Policies are worthless unless people read
and understand them
• Ideally it is distributed and addressed when
people join org
• Email is useful for updates, changes
• Written user acknowledgment necessary
 Gather audit information
• Talk to/Interview people
• Review Documentation
• Technical Investigation
 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?
 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?
 Review Documentation
• Hardware/software inventory
• Network topology
• Key personnel
• Emergency numbers
• Incident logs
 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
 Technical Investigation (cont.)
• Check extra network services (NFS, news, httpd,
etc.)
• Check for replacement programs (wuftpd, 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.)
 Run Static Tools

• Nmap
• SAINT/SATAN/ISS
• Crack
• Nessus
• COPS/Tiger
 Follow Startup Execution
• Boot (P)ROMS
• init
• Startup programs (rc.* like files)
 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.)
 Search for privileged programs
• Find all SUID/SGID programs
• Look at all programs executed as root
• Examine:
– Environment
– Paths to execution
– Configuration files
 Examine all Trust

• rhosts, hosts.equiv
• NFS, NIS
• DNS
• Windowing systems
• User traffic and interactive flow
 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.)
Check for replacement programs

• wuftpd
• TCP wrappers
• Logdaemon
• Xinetd
• GNU fingerd
Code review ``home grown''/non
standard programs

• Network daemons
• Anything SUID, SGID
• Programs run as system account
• CGI's
 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
 Actively test defenses
• packet screens
• TCP wrappers
• Other defense programs
 Safeguard Data & Report
• Save for the next audit
• Do not keep online
• Use strong encryption if stored
electronically
• Limit distribution to those who ``need to
know''
• Print out report, sign, and number copies