Incident Response
A rapid response to incidents that threaten the confidentiality, integrity, and availability (CIA) of FundApps information assets, information systems and the networks that deliver the information is required to protect those assets. Without a rapid response, those assets could be compromised and FundApps could be in breach of legislation, our own stated policies, and the potential of of breaching the trust of our clients and users.
Information Security incidents will occur that require full participation of FundApps technical staff as well as management leadership to properly manage the outcome. To accomplish this FundApps has established an incident response policy and procedures that will ensure appropriate leadership and technical resources are involved to:
assess of the seriousness of an incident
assess the extent of damage
identify the vulnerability created
estimate what additional resources are required to mitigate the incident
It will also ensure that proper follow-up reporting occurs and that procedures are adjusted so that responses to future incidents are improved.
1. Scope & Objectives
The primary emphasis of processes and activities described within this policy is the return to a normal (secure) state as quickly as possible, whilst minimising the adverse impact to FundApps. The capture and preservation of incident relevant data (e.g., network flows, data on drives, access logs, etc.) is performed primarily for the purpose of problem determination and resolution. Strict forensic measures are not used in the data capture and retention. Forensic measures will be determined on a case by case basis.
Contingency Planning, Business Continuity and Disaster Recovery are governed by a different set of policies. An event may initially be declared an ‘Information Security Incident’ and subsequently declared to be a ‘Disaster’. In this case, the activities described below will be included in the Disaster Recovery process.
2. Information Security Incidents
An Information Security Incident is generally defined as any known or highly suspected circumstance that affect the confidentiality, integrity or availability of sensitive information managed or belonging to FundApps.
Sensitive data is considered anything classified as Confidential or Restricted by our data classification policy.
Examples of an Information Security Incident may include but are not limited to:
the theft or physical loss of computer equipment known to hold files containing sensitive client or company information
a server known to hold sensitive data is accessed or otherwise compromised by an unauthorised party
the FundApps network is subjected to a Distributed Denial of Service (DDoS) attack
a firewall is accessed by an unauthorised entity
a network outage is attributed to the activities of an unauthorised entity
2.1 Categories
For the purposes of this protocol, incidents are categorised as “Unauthorised Access” or “Unauthorised Acquisition” and can be recognised by associated characteristics.
Unauthorised Access
The unauthorised access to or disclosure of FundApps or client information through network and/or computing related infrastructure, or misuse of such infrastructure, to include access to related components (e.g., network, server, workstation, router, firewall, system, application, data, etc.). Characteristics of security incidents where unauthorised access might have occurred may include but are not limited to:
Evidence (e‐mail, system log) of disclosure of sensitive data
Anomalous traffic to or from the suspected target
Unexpected changes in resource usage
Increased response time
System slowdown or failure
Changes in default or user‐defined settings
Unexplained or unexpected use of system resources
Unusual activities appearing in system or audit logs
Changes to or appearance of new system files
New folders, files, programs or executables
User lock out
Appliance or equipment failure
Unexpected enabling or activation of services or ports
Protective mechanisms disabled (firewall, anti‐virus)
Unauthorised Acquisition
The unauthorised physical access to, disclosure or acquisition of assets containing or providing access to FundApps or client information (e.g., removable drives or media, hardcopy, file or document storage, server hardware, etc.)/ Characteristics of security incidents where unauthorised acquisition might have occurred may include but are not limited to:
Theft of computer equipment where sensitive data is stored
Loss of storage media (removable drive, flash drive, etc)
Illegal entry (burglary)
Suspicious or foreign hardware is connected to the network
Normally secured storage areas found unsecured
Broken or non‐functioning locking mechanisms
Presence of unauthorised personnel in secured areas
Disabled security cameras or devices
2.2 Criticality
Incidents assigned a criticality rating according to the actual and potential impact on the business of FundApps.
Incidents are assigned a criticality rating according to the actual and potential impact on the business of FundApps. Incident categories and response times are described in FundApps' General Terms (Schedule A).
2.3 Roles and Responsibilities
Key roles and responsibilities of those who form part of the Incident Response Team (IRT) have been defined below:
CTO or Head of Information Security
Incident response team lead (IRTL)
CEO
Participates in incident response team, leading external communications.
IT Team / Security Team / Engineering
Normally form part of the incident response team, subject to CTO approval after initial assessment.
3. Key components of our Critical Incident Response Protocol
The Critical Incident Response Protocol consists of these key components
Detection
Activation of team
Containment
Notification of non-IRT team members
Assessment
Notification of external parties
Corrective Measures
Washup & lessons learned
Closure
3.1 Detection
Timely detection of incidents is critical to containment and minimizing its impact on our business and clients. Please see our IT security policy and specific controls regarding how we detect security incidents.
3.2 Activation of Team
All suspected security incidents are reported to the Incident Response Team Lead, mobilization will be immediate and based on initial orientation and observation. Notification of the rest of the team should occur via direct communication - that is any form of communication where you get a response from the other party (ie voicemail or email are not considered direct notification). Team members should rely on usual company communication channels to ensure they have up to date information.
3.3 Containment
The IRT will determine and cause to be executed the appropriate activities and processes required to quickly contain and minimise the immediate impact on FundApps and our clients.
Containment activities are designed with the primary objectives of:
Counteract the immediate threat
Prevent propagation or expansion of the incident
Minimise actual and potential damage
Restrict knowledge of the incident to authorised personnel
Preserve information relevant to the incident
Containment Activities - Unauthorised Access
Activities that may be required to contain the threat presented to systems where unauthorised access may have occurred:
A1. Disconnect the system or appliance from the network or access to other systems.
A2. Isolate the affected IP address from the network.
A3. Power off the appliance(s) if unable to otherwise isolate.
A4. Disable the affected application(s).
A5. Discontinue or disable remote access.
A6. Stop services or close ports that are contributing to the incident.
A7. Remove drives or media known or suspected to be compromised.
A8. Where possible, capture and preserve system, appliance and application logs, network flows, drives and removable media for review.
A9. Notify IRT of status and any action taken.
Containment Activities - Unauthorised Acquisition
Activities that may be required to contain the threat presented to assets where unauthorised acquisition may have occurred:
B1. Identify missing or compromised assets.
B2. Gather, remove, recover and secure sensitive materials to prevent further loss or access.
B3. Power down, recycle or remove equipment known to be compromised.
B4. Where possible, secure the premises for possible analysis by local management and law enforcement.
B5. Gather and secure any evidence of illegal entry for review by local management and law enforcement.
B6. Where possible, record the identities of all parties who were possible witnesses to events.
B7. Preserve camera logs and sign‐in logs for review by local management and law enforcement.
B8. Notify IRT of the disposition of assets and any action taken.
3.4 Notification of non-IRT members
Designated persons will take action to notify the appropriate internal parties as necessary. All internal & external communication must be approved by the IRT Lead
3.5 Assessment
The IRT will determine the category and severity of the Incident and undertake discussions and activities to determine the next best course of action best, i.e., decide if protocol execution is required. Once the IRT is assembled, the Assessment Checklist is executed and reviewed to ensure all pertinent facts are established. All discussions, decisions and activities are to be documented.
Assessment should consist of the following at a minimum:
Incident data
The current date and time and a brief description of the Incident
Who discovered the incident, and how?
Types of information
What is the nature of the data?
Was the data held by FundApps or a third party?
How was the information held? Was the data encrypted or otherwise obfuscated?
Risk
Can we reasonably determine the risk or exposure?
To what degree are we certain that the data has or has not been released?
Can we identify and do we have contact with the party that received the data or caused the compromise? Describe what is known.
Identify the impacted clients, if possible.
What is the risk or exposure to FundApps?
What is the risk or exposure to the client?
Next Steps
Do we have enough information to establish the category and severity of the Incident?
If additional data collection data is required, assign responsibility to an IRT member for the collection
Is there any deadline or reporting requirement (self‐imposed or regulatory) we need to address?
What communications need to be established? Provide details
Are there any immediate issues that have not been addressed? Describe
Recap all work and responsibility assignment
When do we meet again to follow up? Provide details
Is this incident going to have legal impacts, requiring forensic evidence to be gathered? If so, refer to the section Gathering Forensic Evidence.
3.7 Gathering Forensic Evidence
If the incident will have legal impacts which require a case to go to court, forensic evidence will need to be collected. This should be done by an accredited Cyber Incident Response third-party company. A list can be found here.
The following rules should be enforced when interacting with potential evidence:
Save the original materials: You should always work on copies of the digital evidence as opposed to the original. This ensures that you are able to compare your work products to the original that you preserved unmodified.
Take photos of physical evidence: Photos of physical (electronic) evidence establish the chain of custody and make it more authentic.
Take screenshots of digital evidence content: In cases where the evidence is intangible, taking screenshots is an effective way of establishing the chain of custody.
Document the date, time, and any other information of receipt. Recording the timestamps of whoever has had the evidence allows investigators to build a reliable timeline of where the evidence was prior to being obtained. In the event that there is a hole in the timeline, further investigation may be necessary.
Provide third-party company with a bit-for-bit clone of digital evidence. This ensures that they have a complete duplicate of the digital evidence in question.
Perform a hash test analysis to further authenticate the working clone.
3.6 Notification of external parties
Designated persons will take action to notify the appropriate internal and external parties, as necessary. Communications may include meetings, video conferencing, teleconferencing, e‐mail, telephone/messaging, voice recordings or other means as deemed appropriate. All external communication must be approved by the IRT Lead. FundApps will endeavour to notify clients of any potential incidents impacting the confidentiality, integrity or availability of the client's data, stored in the FundApps platform, no later than 48 hours after having first detected an anomaly.
Clients - IRT Lead or CEO will establish communication with Clients, as appropriate for the circumstance
Other affected parties - IRT Lead or CEO will establish communication with other affected parties (such as hosting providers) as appropriate for the circumstance
Law enforcement - IRT Lead will establish if law enforcement is required and take appropriate action
Government or Regulatory Bodies - IRT Lead will establish if government notification (e.g. Information Commissioner) is required and take appropriate action
Media interest - The CEO will deal with any communications with the Media.
3.7 Corrective Measures
The IRT will determine and cause to be executed the appropriate activities and processes required to quickly restore circumstances to a normal (secure) state.
Corrective measures are designed with the primary objectives of:
Secure the processing environment
Restore the processing environment to its normal state
Corrective Measures - Unauthorised Access
Activities that may be required to return conditions from unauthorised access to a normal and secure processing state.
A1. Change passwords on all local user and administrator accounts or otherwise disable the accounts as appropriate.
A2. Change passwords for all administrator accounts where the account uses the same password across multiple appliances or systems (servers, firewalls, routers).
A3. Re-image systems to a secure state.
A4. Restore systems with data known to be of high integrity.
A5. Apply OS and application patches and updates.
A6. Modify access control lists as deemed appropriate.
A7. Implement IP filtering as deemed appropriate.
A8. Modify/implement firewall rule sets as deemed appropriate.
A9. Ensure the anti‐virus is enabled and current.
A10. Make all personnel “security aware”.
A11. Monitor/scan systems to ensure problems have been resolved.
A12. Notify IRT of status and any action taken.
Corrective Measures - Unauthorised Acquisition
Activities that may be required to return conditions from an unauthorised acquisition to a normal and secure processing state.
B1. Retrieve or restore assets where possible.
B2. Store all sensitive materials in a secure manner (e.g., lockable cabinets or storage areas/containers).
B3. Install/replace locks and issue keys only to authorised personnel.
B4. Restore security devices and/or apparatus to working condition.
B5. Remove and retain unauthorised equipment from the network/area.
B6. Implement physical security devices and improvements (e.g., equipment cables, alarms) as deemed appropriate.
B7. Make all personnel “security aware”.
B8. Notify IRT of status and any action taken.
3.8 Washup and lessons learned
After the incident has been dealt with, a subsequent washup session will be run in order to identify if any further lessons can be learnt or actions taken aside from the immediate corrective measures.
3.9 Closure
The IRT will stay actively engaged throughout the life cycle of the Information Security Incident to assess the progress/status of all containment and corrective measures and determine at what point the incident can be considered resolved.
Recommendations for improving processes, policies, procedures, etc., will exist beyond the activities required for incident resolution and should not delay closing the Information Security Incident.
Last updated
Was this helpful?