Defense Logging Auditing Response Logging and Auditing We

Defense Logging Auditing Response

Logging and Auditing • We have discussed many a priori techniques to prevent security violations • A posteriori techniques are also important: – Logging is the recording of events or statistics to provide information about system use and performance – Auditing is the analysis of log records to present information about the system in a clear and understandable manner

Logging • Logs provide a mechanism for analyzing the system security state – Determine if a requested action will put the system in an insecure state – Determine the sequence of events leading to the system being in an insecure state • Problem: – What information/events to log?

Logging (cont) • Logs typically contain entries for successful and/or failed: – User logins and logouts – Creation of accounts – Execution of certain commands – Access to files – Starting and stopping of services or the system

Windows Logging What to log set in Administrative Tools->Local Security Settings Logs stored in binary format System logs can be viewed using the Event Viewer Demo

IIS Logging Configured in IIS Manager Log file format can be selected, but mostly plain text Logs can be viewed using Notepad (or other text viewers) Demo

Firewall Logging • Configured in Firewall GUI • Log saved in c: WINDOWSpfirewall. log (by default) • Can be viewed with Notepad (or other text viewers) • Demo

Auditing • Analysis of log records to present information about the system in a clear and understandable manner – Manually – Automated

Automated Auditing Tools • Many tools available that process log files or produce real-time audit displays – Application logs • Web logs • Database logs – System logs – Security logs (but these tend to be intrusion detection systems)

Automated Auditing Tools (cont) Splunk • – URL: http: //www. splunk. com/ – Log collection and analysis: • Organizes and correlates information from various logs, machines, applications, etc.

Automated Auditing Tools (cont) System i. Ntrusion Analysis and Reporting Environment (SNARE) • – URL: http: //www. intersectalliance. com/ – Log collection and analysis: • Collects audit data • Transfers it to a central server for analysis

Attacking Logs and Audit Mechanisms • Attackers typically alter logs to avoid detection – May delete logs entirely – May remove particular suspicious events: • Failed logins • Error conditions • Stopped services • File access/modification

Defending Log and Audit Data • Bare minimum: – Enable sensible logging – Set proper permissions on log files • A little better: – Make log files append only (can be circumvented) – Encrypt log files • Attacker cannot alter logs without the proper encryption key

Defending Log and Audit Data (cont) • Best – Use a separate log server • Hosts can be configured to redirect their logs to a dedicated log server • Logs are centralized for easier processing/ analysis • Compromise of a host does not allow the attacker to alter its stored logs – Transfer logs to write-once media (slow)

Response Passive responses Record and report the problem Active responses Block the attack Repair the damage done by the attack Affect the progress of the attack Be careful!

Passive Responses Provide information to the user Rely on the user to take subsequent action Alarms On screen alert, window, or IDS console Remote notification Send e-mail Dial pagers or cell phones

Passive Responses (cont) SNMP Traps and Plug-ins IDS designed to function in concert with network management tools Utilize the network management infrastructure to send and display alarms Provided by several commercial IDSs

Active Responses Take action based on the detection of an intrusion: Take action against the intruder Amend the environment Collect more information Take action: Automatically (be careful!) User driven

Take Action Against the Intruder Ideally: Trace intrusion back to its source Disable the intruder’s machine/network connection Prosecute the person responsible Problems: Network hopping - the “source” of the attack is probably another victim of the attacker Address spoofing – the “sources” of the attack may just be random IP addresses

Take Action Against the Intruder (cont) Problems (cont): Striking back could provoke escalation Striking back could result in: Criminal charges Civil legal action Attacks (even in in response to an attack) are usually viewed as a violation of computer crime statutes Damages caused to innocent (or even guilty) parties could result in lawsuits Disciplinary action Many government, military, and commercial, and educational institutions have policies prohibiting attacks

Taking (Responsible) Action Against an Intruder Terminate a network session by resetting the TCP connection Configure a firewall or router to block packets coming from the IP address that appears to be the source of the intrusion Send e-mail to the admin of the attacking system For persistent attacks, notify law enforcement so they can investigate

Amend the Environment System environment Identify and fix what enabled the intrusion Disable vulnerable services Configure a firewall or router to block the attack Detection environment Increase sensitivity level of IDS Increase information collected by IDS Insert rules to better distinguish certain types of attacks

Collect Additional Information Especially important if you plan to pursue legal remedies Honeypots or decoy servers (legal grey area) Collect information/evidence Determine intruder’s intent Understand threat trends and construct detection signatures Gather vulnerability information without putting sensitive/critical systems at risk

Fail-Safe Considerations Assume that an adversary will target the IDS/response component as part of the attack Monitoring response channels Searching for signs of detection Intercepting/disrupting alarms Determining response policies (and try to use them against a site)

Fail-Safe Measures Utilize encryption, integrity checking, and authentication to protect IDS communications from tampering Use redundant alarms (and multiple communications channels) Logs, audit records, and other evidence should be protected from alteration or destruction

Mapping Response to Policy Response activities should be documented in an organization’s security policy Response activities can be categorized as: Immediate Timely Long term (local) Long term (global)

Immediate Response Activities Critical actions required immediately following an attack or intrusion: Initiating incident-handling procedures Performing damage control and containment Notifying law enforcement or other organizations Restoring victim systems to service

Timely Response Activities Actions required within hours or days of an incident: Investigate unusual patterns of system use Investigate and isolate the root causes of the detected problems Correct the problems when possible Apply vendor patches Reconfigure systems Report details of the incident to the proper authorities Pursue legal action against the perpetrator(s) Alter or amend detection signatures in the IDS

Long-Term (Local) Response Activities Less critical, but should be performed regularly: Compiling statistics Performing trend analysis Tracking patterns of intrusion over time Identify areas in need of improvement

Long-Term (Global) Response Activities Notifying vendors of the problems the organization has suffered due to security problems in their products Lobbying lawmakers for additional legal remedies to system security threats Reporting statistics regarding security incidents to law enforcement or other organizations

Defense Logging – Information about what is happening on a system – Evidence Auditing – View and search log files to find important information Response – Passive – Active