Uprise Incident Management Policy
Uprise Incident Management Policy
This Incident Management Policy defines what constitutes a security incident and outlines the incident response phases. This policy discusses how information is passed to the appropriate personnel, assessment of the incident, minimising damage and response strategy, documentation, and preservation of evidence. The policy will define areas of responsibility and establish procedures for handling various security incidents. This document discusses the considerations required to build an incident response plan.
This policy is designed to protect the organisational resources against intrusion.
Incident Response Goals
Verify that an incident occurred.
Maintain or restore business continuity.
Reduce the incident impact.
Determine how the attack was done.
Prevent future attacks or incidents.
Improve security and incident response.
Prosecute illegal activity.
Keep management informed of the situation and response.
An incident is any one or more of the following:
Loss of information confidentiality (data theft);
Compromise of information integrity (damage to data or unauthorised modification);
Theft of physical IT assets (e.g. computers and storage devices);
Damage to physical IT assets;
Denial of service (DDoS);
Misuse of services, information, or assets;
Infection of systems by unauthorised or hostile software;
An attempt at unauthorised access;
Unauthorised changes to organisational hardware, software, or configuration;
Reports of unusual system behaviour; and
Responses to intrusion detection alarms.
Incident Response Lifecycle
Policies and procedures:
Uprise Access Control Policy is followed and associated ACL is up to date;
Appropriate backup and recovery procedures are in place and regularly checked to ensure integrity (e.g. automated backup of customer data on AWS using Tarsnap).
Train users about computer security and train staff in handling security situations and recognising intrusions.
Establish contacts – incident response team member contact information should be readily available. An emergency contact procedure should be established.
Regular testing of the process incident management process.
Discovery – Someone discovers something not right or suspicious. This may be from any of several sources:
Intrusion detection system;
A system administrator;
A business partner;
A manager; or
An outside source.
Notification – The emergency contact procedure is used to contact the incident response team.
Analysis and Assessment – Many factors will determine the proper response including:
Is the incident real or perceived?
Is the incident still in progress?
What data or property is threatened and how critical is it?
What is the impact on the business should the attack succeed? Minimal, serious, or critical?
What system or systems are targeted, where are they located physically and on the network?
Is the incident inside the trusted network?
Response Strategy – Determine a response strategy.
Is the response urgent?
Can the incident be quickly contained?
Will the response alert the attacker?
Containment – Take action to prevent further intrusion or damage and remove the cause of the problem. May need to:
Disconnect the affected system(s);
Block some ports or connections from some IP addresses.
Prevention of Reinfection
Determine how the intrusion happened. Determine the source of the intrusion whether it was email, inadequate training, attack through a port, attack through an unneeded service, attack due to unpatched system or application.
Take steps to prevent an immediate reinfection, which may include one or more of the following:
Close a port on a firewall;
Patch the affected system;
Shut down the infected system until it can be reinstalled;
Reinstall the infected system and restore data from backup (be sure the backup was made before the infection);
Change email settings to prevent a file attachment type from being allowed through the email system;
Disable unused services on the affected system.
Restore Affected Systems – Restore affected systems to their original state. Be sure to preserve evidence against the intruder by backing up logs or possibly the entire system. Depending on the situation, restoring the system could include one or more of the following:
Reinstall the affected system(s) from scratch and restore data from backups if necessary;
Be sure to preserve evidence against the intruder by backing up logs or possibly the entire system;
Make users change passwords if passwords may have been sniffed;
Be sure the system has been hardened by turning off or uninstalling unused services;
Be sure the system is fully patched;
Be sure real time virus protection and intrusion detection is running;
Be sure the system is logging the correct items.
Documentation – Document what was discovered about the incident including how it occurred, where the attack came from, the response, whether the response was effective.
Evidence Preservation – Make copies of logs, email, and other documentable communication. Keep lists of witnesses. Be aware of evidence collection (see http://www.aic.gov.au/publications/current%20series/htcb/1-20/htcb004.html).
Notifying proper external agencies – Notify the police if prosecution of the intruder is possible.
Assess damage and cost – Assess the damage to the organisation and estimate both the damage cost and the cost of the containment efforts.
Review response and update policies – Plan and take preventative steps so the intrusion can't happen again.
Consider whether an additional policy could have prevented the intrusion;
Consider whether a procedure or policy was not followed which allowed the intrusion, then consider what could be changed to be sure the procedure or policy is followed in the future;
Was the incident response appropriate? How could it be improved?
Was every appropriate party informed in a timely manner?
Was the incident response procedures detailed and cover the entire situation? How can they be improved?
Have changes been made to prevent a reinfection of the current infection? Are all systems patched, systems locked down, passwords changed, anti-virus updated, email policies set, etc.?
Have changes been made to prevent a new and similar infection?
Should any security policies be updated?
What lessons have been learned from this experience?