Security Incident Reporting


In the fields of computer security and information technology, computer security incident management and reporting involves the monitoring and detection of security events on a computer or computer network, and the execution of proper responses to those events. Computer security incident management is a specialized form of incident management, the primary purpose of which is the development of a well understood and predictable response to damaging events and computer intrusions.(c) A security incident is defined as any security problem arising from known, unknown or suspected threats and can include, but is not limited to, a single virus occurrence to a hacker attacking many networked systems, or such things as unauthorized access to sensitive data and loss of mission- critical data.

IT security incidents to be reported and tracked can be categorized as follows (these types of acts are not all-inclusive):

(a) Circumvention of IT security controls, safeguards and/or procedures;

(b) Unauthorized access, use, disclosure, alteration, manipulation, destruction, or other misuse of data and IT resources;

(c) Theft, fraud, or other criminal activity committed with the aide of IT resources;

(d) Theft, loss or vandalism of IT hardware, firmware, software or apps;

(e) Issues affecting confidentiality, integrity and availability of data and IT resources;

(f) Unauthorized downloading or copying of sensitive information.

Examples of specific reportable incidents which must be reported under the six categories of incidents include (but are not limited to):

(a) Unauthorized access to or use of sensitive data for illegal purposes;

(b) Unauthorized altering of data, programs, and IT hardware;
(c) Loss of mission-critical data (financial, benefits, personal, proprietary, legal etc.);

(d) Environmental damage/disaster causing loss of IT services or data or which may
have affected the College office's capabilities to continue day-to-day functions and operations;

(e) Infection of sensitive systems or software by malicious code (malware, virus, Trojan Horse etc.);

(f) IT perpetrated theft, fraud and other criminal computer activity;

(g) Telecommunications/network security violations (including local area networks (LANs),wide area networks (WANs), Wireless Networks) which experience service interruptions that cause an impact to an indefinite number of end users;

(h) Theft or vandalism of IT hardware, software or firmware whose
loss affects the College's capabilities to continue day-to-day functions and operations;

(i) Unauthorized access to data when in transmission over communications media;

(j) Loss of system availability impacting the ability of users to perform the functions required to carry out day-to-day responsibilities;

(k) Unauthorized access to and/or unauthorized use of the Internet.

Reporting Procedures

Information Technology security incidents will be reported to the Information Security office by the person observing or discovering the occurrence. The Information Security Office is responsible for recording and reporting security incidents for the purpose of tracking and reconciliation of the suspected incident. Suspected IT security incidents will be reported to the CISO immediately of their occurrence by phone or email.

Information security incidents shall be recorded on the Security Incident Report Form, available on the Information Security web portal ( Essential information about the security incident should be identified in as much detail as possible, at the time of occurrence. Some information may need to be added at a later time based on the investigation/closure of the incident. The following minimum information about a security violation or incident shall be entered on the form:

(a) Department filing report;
(b) Location of incident
(c) Reported by (Name, Title, Location and Department);
(d) Date and time of report filing;
(e) Date and time of incident;
(f) Details of incident (description of the who, what, when, where, how, and why);
(g) The name and title of the person to whom the incident initially was reported to;
(h) Identification of whether appropriate law enforcement organization has been notified; (i) Incident impact on day-to-day operations;
(j) Action taken to contain the incident (note what vendors have been contacted);
(k) Short-range corrective action, such as discontinuing the use of an infected computer; (l) Long-range corrective actions, as necessary;
(m) Additional information, as appropriate.

(3) The information collected on the form shall be reported to the ISO in a confidential manner, which may include, but are not limited to, the following methods:

*Initial reports of serious incidents or violations may be reported by telephone.

*Reports may be sent by encrypted email, secure facsimile or secure file transfer ( .

Follow-up contact will be established with the reporting department or office by the ISO, and tracking for each incident will be continued until final closure.

Incident Categories 

In order to clearly communicate incidents and events (any observable occurrence in a network or system) throughout the College of Charleston and supported organizations, it is necessary for the incident response teams to adopt a common set of terms and relationships between those terms. All elements of the College of Charleston should use a common taxonomy.

Below please find a high level set of concepts and descriptions to enable improved communications among and between departments and security teams. The taxonomy below does not replace discipline (technical, operational, intelligence) that needs to occur to defend College of Charleston computers/networks, but provides a common platform to execute the mission. Utilize the following incident and event categories and reporting timeframe criteria as College of Charleston reporting taxonomy.




Reporting Timeframe


Exercise / Network Defense Testing

This category is used during exercises and approved activity testing of internal/external network defenses or responses.

Not Applicable; this category is for each internal deprtmental use during exercises.


Unauthorized Access

In this category an individual gains logical or physical access without permission to a college network, system, application, data, or other resource

Within one (1) hour of discovery/detection.


Denial of Service (DoS)

An attack that successfully prevents or impairs the normal authorized functionality of networks, systems or applications by exhausting resources. This activity includes being the victim or participating in the DoS.

Within two (2) hours of discovery/detection if the successfulattackis still ongoing and the college is unable to successfully mitigate activity.


Malicious Code

Successful installation of malicious software (e.g., virus, worm, Trojan horse, or other code-based malicious entity) that infects an operating systemor application. NOT required to report malicious logic that has been successfully quarantined by antivirus (AV) software.


Note: Within one (1) hour of discovery/detection if widespread across campus.


Improper Usage

A person violates acceptable computing use policies.



Scans/Probes/Attempted Access

This category includes any activity that seeks to access or identify a college computer, open ports, protocols, service, or any combination for later exploit. This activity does not directly result in a compromise or denial of service.


Note: If system is classified or contains PII, report within one (1) hour of discovery.



Unconfirmed incidents that are potentially malicious or anomalous activity deemed by the reporting entity to warrant further review.

Not Applicable; this category is to categorize a potential incident that is currently being investigated.

Incident Reporting Guidelines 

A computer incident within the College as defined by NIST Special Publication 800-61 is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard computer security practices.

Reports of computer incidents should include a description of the incident or event, using the appropriate taxonomy, and as much of the following information as possible; however, reporting should not be delayed in order to gain additional information:

  •  Department

  •  Point of contact information including name, telephone, and email address

  •  Incident Category Type (e.g., CAT 1, CAT 2, etc., see table)

  •  Incidentdate andtime, includingtimezone

  •  Source IP, port, and protocol

  •  Destination IP, port, and protocol

  •  Operating System, including version, patches, etc.

  •  System Function (e.g., DNS/web server, workstation, etc.)

  •  Antivirus softwareinstalled,includingversion,andlatestupdates

  •  Locationofthe system(s)involvedintheincident(e.g., Communication,Library,Computer Lab)

  •  Method used to identify the incident (e.g., IDS, audit log analys is, system administrator)

  •  Impact to the College of Charleston

  •  Resolution

    All incident responders should utilize this schema when reporting incidents to the College Chief Information Security Officer. Depending on the criticality of the incident, it is not always feasible to gather all the information prior to reporting. In this case, the incident responder should continue to report information as it is collected. 

Incident Reporting Form


Incident Response SC Guide

  1. 11.200  Incident Management: Each agency must ensure that information P1 security incidents occurring within the agency are appropriately

  2. 11.201  Each agency must develop, document, and internally publish an P1 incident response process that addresses scope, roles, and responsibilities, internal coordination efforts, and compliance.

  3. 11.202  Each agency incident response plan must include the following: P1 • Compatible interaction with the state level incident response
    process published by DIS.
    • Types of information security incidents to be reported.

    • Establish metrics to ensure incident response capabilities remain effective.
    • Define resources, such as technology and personnel, required to effectively support incident response capabilities.
    • Roadmap for implementing incident response capabilities.

  4. 11.203  Each agency must review and update the incident response plan P1 on an annual basis.

  5. 11.204  Each agency ensures that information security incident handling P1 processes include preparation, detection and analysis,
    containment, eradication, and recovery.

  6. 11.205  Each agency must ensure the implementation of incident P1 response tools such as intrusion detection, firewalls, and incident investigation tools, to effectively respond to security incidents.

  7. 11.206  Each agency must ensure that personnel are required to report P1 suspected information security incidents to the incident response
    team or agency leadership.

  1. 11.207  Each agency ensure that monitor information systems are P1 sufficiently monitored to detect attacks and/or signs of potential
    attacks, including unauthorized network local or remote

  2. 11.208  Each agency must ensure that monitoring devices are deployed P1 strategically within information technology environment to
    collect information security events and associated information.

  3. 11.209  Each agency must ensure the protection of information obtained P1 from intrusion-monitoring tools from unauthorized access,
    modification, and deletion.

  4. 11.210  Each agency must ensure the monitoring of inbound and P1 outbound communications traffic from sensitive information
    systems for unusual or unauthorized activities or conditions.

  5. 11.211  Each agency must ensure that information system monitoring P1 activity is appropriately adjusted for new and increased sources
    of risk.

  6. 11.212  Each agency must provide incident response training within one P2 (1) month of personnel assuming incident response roles or responsibilities.

  7. 11.213  Each agency must provide training to incident response personnel P2 upon significant changes to information systems and/or changes
    to the incident response plan.

  8. 11.214  Each agency must establish a formal process to test incident P2 response capabilities on a yearly basis to determine the incident response effectiveness and adequacy.

  1. 11.215  Each agency must document the incident response test results P2 and update incident response processes as applicable.

  2. 11.216  Each agency must ensure malicious code protection mechanisms P1 are employed for information systems, to detect and eradicate
    malicious code.

  3. 11.217  Each agency must ensure malicious code protection mechanisms P1 are updated whenever new releases are available.

  4. 11.218  Each agency must ensure malicious code protection mechanisms P1 are configured to perform periodic scans at defined time

  5. 11.219  Each agency must ensure malicious code protection mechanisms P1 are configured to send an alert to information appropriate
    personnel, to initiate appropriate actions in response to malicious
    code detection.