1. Home
  2. Information Technology
  3. About
  4. Policies

1.02.01 Security Incident Alert Analysis

I. Purpose

This procedure documents Bradley University’s method in which the Data Security Incident Response Technical Team investigates security related alerts on secure systems and networks. This procedure shall be used to help a technical team member decide if the alert is serious enough to be escalated in status from an alert to an incident in which Security Incident Response Procedure 1.02.02 shall be executed.

Policy Supported

Supports 1.02 Security Incident Response

II. Description

The following outlines the various tasks within the scope of this procedure that may be performed by the various Data Security Incident Response Team members:

Network Administration (if necessary/as appropriate/in no particular order):
The Network Administration team investigates alerts/logs from the Network Firewall syslog, Network IDS Alerts, and other network level automated alerts that are put in place to protect data security and integrity. They may also investigate alerts of suspicious activity on the network from other people, such as someone’s virus scanner picking up a hit from a Bradley IP address, or someone receiving spam from a Bradley IP address.

  • Identify if the offending IP address is Bradley or non-Bradley
  • Use DNS, historic DHCP logs, Netreg Search Engine, ARIN, Whois, or other tools to determine who is tied to the IP address; the ISP, the organization, or the Bradley user
  • Use the Network Firewall syslogs or the Network IDS to determine the TCP/UDP port or other protocol being used as the method of entry. Identify the port number(s) and industry standard use of the port number(s).
  • Based on the time, IP address, port number(s), and documentation of past incidents, identify if the alert is a routine false positive
  • Identify the IDS signature ID number and read Cisco’s summary on what that signature ID means, and how severe of a threat it is
  • Use a network sniffer, the router cache flow command, router or firewall access lists, network firewall logs, MRTG, and other available tools to determine if the incident is still occurring or the entire timeframe in which it already occurred.
  • Using the totality of information already obtained, determine whether to block the attack/event immediately or let it continue. If there is reasonable belief that letting it continue may cause significant negative impact, block it immediately. If letting it continue may help aide in the investigation without further significant impact, let it continue until significant information is obtained, then block it.
  • Research online and see what can be determined about the offending host’s domain, and also about the type of traffic seen
  • Document all actions taken and any additional information
  • Preserve all evidence
  • Work with other technical team members as necessary
  • For false positives, make note
  • For less serious intrusion attempts, notify the responsible party and inform the intruder of our knowledge of his/her actions and warn against future recriminations if the attempt is repeated
  • For more serious intrusion from off campus, contact the ISP or organization responsible for the domain/IP address and let them know what happened, and ask them to help investigate on their end
  • For more serious intrusion from on campus, quarantine the culprit host and contact the responsible party immediately
  • Contact the Central Illinois FBI Cybercrime Task Force or other law enforcement agencies for further advisement or assistance as necessary
  • For cases in which the team member has reasonable belief or is 100% sure that there has been a breech, they shall refer to and follow Security Incident Response Procedure 1.02.02.

System Administration (if necessary/as appropriate/in no particular order*):

The System Administration team investigates alerts/logs from the local host firewalls and other host level automated alerts that are put in place to protect data security and integrity.

  • Use the local server and workstation firewall logs to determine the TCP/UDP port or other protocol being used as the method of entry. Identify the port number(s) and industry standard use of the port number(s).
  • Based on the time, IP address, port number(s), and documentation of past incidents, identify if the alert is a routine false positive
  • Analyze Windows Event viewer information on servers and workstations to identify account(s) used to gain access
  • Analyze any web log files to that are relevant obtain any information possible relevant to the alert
  • Analyze any specific application logs that are relevant in order to obtain any information possible relevant to the alert
  • Use known good copies of tools such as “netstat“, “tcpview”, “net”, “openfiles”, “logonsessions”, “depends”, “psfile”, “psloggedon”, “handle”, “tasklist” and others to determine if any suspicious activity is still occurring on the system, and determine what files on the system may be associated with the activity

*Note: analysis tools such as these should be ran prior to rebooting, shutting down, virus scanning, or any other methods of remediation

  • Use known good copies of tools such as “fciv”, “sigcheck” and others on any file that is suspected as compromised. Compare the hash of the file to good known copies of the same file.
  • Update virus/spyware/adware/malware protection DAT files and scan the system(s) for infections which may be relevant
  • Document all actions taken and any additional information
  • Preserve all evidence
  • Work with other technical team members as necessary
  • For false positives, make note
  • For less serious intrusion attempts, notify the responsible party and inform the intruder of our knowledge of his/her actions and warn against future recriminations if the attempt is repeated
  • For more serious intrusion from off campus, contact the ISP or organization responsible for the domain/IP address and let them know what happened, and ask them to help investigate on their end
  • For more serious intrusion from on campus, quarantine the culprit host and contact the responsible party immediately
  • Contact the Central Illinois FBI Cybercrime Task Force or other law enforcement agencies for further advisement or assistance as necessary
  • For cases in which the team member has reasonable belief or is 100% sure that there has been a breech, they shall refer to and follow Security Incident Response Procedure 1.02.01.

III. Scope

This procedure is for analyzing electronic alerts that are generated automatically by the secure systems themselves or the monitoring systems watching them in order to protect the security and integrity of their data. This procedure is also for analyzing alerts that are sent to the team member by both Bradley and non Bradley people via Email, phone, or other methods of communication.

Date Approved      
6/6/2012      
Dates Revised      
       
Dates Reviewed