Current revision updated by rgilbert39 on
Originally created by rgilbert39 on
Definitions

Security event:  A security event is a change on a network or device that creates a risk of a breach or attack by a malicious hacker. 

 Security Incident: A security incident occurs when an event is exploited, or a breach occurs.  

False Positive:  A false positive is when tooling catches an event or Incident that is not occurring. Do not confuse with an event or incident used as research as the tool is performing as expected and the alert could require additional actions such as policy exceptions as the risk must be accepted. 

 Risk:  A Risk is based on the chance of an adverse action happening to Information systems such as Confidentiality, Integrity, and availability. There are differences in managing risks such as creating a Policy Exception to determine if the risk outweighs the benefit and will be accepted or not allowed and mitigated.  An example of an everyday risk is creating new accounts for users or services as every account created is one more that can be compromised. 

When to Complete Log

The log should be completed any time an event or incident occurs. This includes malware on a PC, compromised accounts, reports of COC endpoints performing attacks, ETC.  These should be accompanied by Cases in RT and Service now. GT SOC has tooling, so it will create cases when something is found or reported to them.  COC end users may create tickets based on observations or other reasons. 

Please Note that although Vulnerabilities are a Risk, they have their own program and definition, so it would not be an event but, if exploited, would become an incident.  

Phishing is common and many times will be reported directly to cyber or disregarded. They should be cataloged if escalated conditions occur such as opening tickets in the ticketing system, coming from GT accounts, and anything else that raises the risk of someone opening. These escalated attempts could be the result of an incident occurring such as a compromised account. 

Field Definitions and Instructions
  1. Incident/Event 
    1. Provide a name for the Incident/Event to make it identifiable when looking at the log.
  2. Incident/Event Description 
    1. Describe the nature of the incident/event with enough information to explain what happened to stem the case.  The ticket numbers are in other fields that can be utilized for more detailed info and timelines.  
  3. Type 
    1. Dropdown list. Select if it is an incident or event.  
  4. RT Ticket Number 
    1. The ticket number of the incident/event in RT is being used to track interactions between TSO and end users. Data validation keeps a number only.  
  5. GT Service Now Ticket Number 
    1. No data validation as the tickets may have different prefixes. This is the ticket number of the service now ticket for interactions between TSO and OIT. All Incidents require a ticket to OIT.  
  6. Reported By 
    1. The person or group reporting the Incident/Event.  
  7. Date Reported 
    1. Date reported to TSO.  
  8. Endpoint affected /Hostname 
    1. The hostname or hostnames affected by a single Incident/Event.  
  9. Endpoint IP(s) 
    1. IP of affected endpoints from a single Incident/Event  
  10. Endpoint tools installed 
    1. Dropdown yes or no  
  11. Username if applicable 
    1. If a username is compromised or the source of the Incident/Event is; enter it here  
  12. TSO Managed 
    1. Dropdown for yes or no  
  13. TSO POC 
    1. If TSO it is managed, use dropdown for the group responsible for the device(s).  
  14. Faculty or other POC 
    1. Faculty or others using the device(s)  
  15. False Positive 
    1. Dropdown yes or no. If yes, it will turn the row blue.  
  16. Caught by what tooling 
    1. List tooling that signaled there was an Incident/Event. If nothing did enter None.  
  17.  Initial action? 
    1. State initial actions taken to control or contain Incident/Event  
  18.  Date of initial action 
    1. Date the initial action was performed. Data validation is in place. Can list as 1/2/23 or 1-2-23 as an example and it will format to yyyy-mm-dd.  
  19.  Time of Initial Action 
    1. The time the initial action is performed. Data validation is in place. Can use 24-hour time and will convert to 12 hr. Also, can enter 12 hr. with a space and AM or PM  
  20. Resolved 
    1. Drop down. Yes, Turns row Green, and No turns Row yellow.  
  21. Description of resolution 
    1. Describe steps and actions taken to resolve the Incident/Event  
  22.  Resolution accepted by 
    1. List the person or group accepting the resolution. Sometimes, all steps requested will not be performed, which poses a Risk, and appropriate people will need to accept. GT Cyber closing their case could indicate they accept while COC does not and takes extra steps, which means the case was not resolved until those steps were made, making a COC group or person the acceptor or the resolution. 
Identifier Categories
Specific categories