Cyber Incident Response Plan
High Level Incident Response Process
Common Security Incidents and Responses
Common Threat Vectors
|Attrition||An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services (e.g. a DDoS intended to impair or deny access to a service or application or a brute force attack against an authentication mechanism, such as passwords).|
|Web||An attack executed from a website or web-based application (e.g. a cross-site scripting attack used to steal credentials or a redirect to a site that exploits a browser vulnerability and installs malware).|
|Supply Chain Interdiction||An antagonistic attack on hardware or software assets utilising physical implants, Trojans, or backdoors, by intercepting and modifying an asset in transit from the vendor or retailer.|
|Impersonation||An attack involving replacement with something malicious (e.g. spoofing, man in the middle attacks, rogue wireless access points, and SQL injection attacks all involve impersonation).|
|Improper usage||Any incident resulting from a violation of an organisation’s acceptable usage policies by an authorised user, excluding the above categories (e.g. a user installs file-sharing software leading to the loss of sensitive data).|
Skpr Platform Team Overview
The Skpr platform team is responsible for the operational success of the Skpr hosting product and the applications which are hosted on the solution.
The Skpr platform team is responsible for:
- Feature Development - Development of new features to increase developer efficiency, application performance, application stability, aplication security and platform monitoring/alerting.
- Maintenance - Perform routine maintenance tasks e.g. security updates
- Monitoring/Alerting - Review platform telemetry and respond to platform alerts e.g. Elevated access denied responses
- Support Services - Respond to developer support requests e.g. Interpreting logging data
- Incident Response - Respond to incidents as outlined in the Incident Discovery section
Listed below are the common ways in which the Skpr platform team is notified of a cyber incident:
- Automated Tooling - Alerts generated by the Skpr hosting platform. These alerts trigger the platform team’s on-call roster.
- General Public Reporting - Reports submitted by the general public. Reports can be submitted via the Skpr contact form.
- Private Reporting - Reports submitted by internal staff and/or clients. These comms are carried out using the PreviousNext ticketing system (Jira).
|Type||Description||Skpr Platform Team Response|
|Denial of Service (DoS) and Distributed Denial of Service (DDoS)||Overwhelming a service with traffic, sometimes impacting availability.||Reviews incoming web requests to determine bad actor(s). Applies additional rules to the WAF solution to block/mitigate malicious requests. Notifies client within the hour.|
|Data Breach||Unauthorised access and disclosure of information.||Notifies client within 24hrs. Activate Cyber Incident Response Plan. Isolate affected projects and environments.|
|SQL Injection||An attacker inserts malicious code into a server using server query language (SQL) forcing the server to deliver protected information.||Reviews incoming web requests to determine bad actor(s). Applies additional rules to the WAF solution to block/mitigate malicious requests. Skpr platform team notifies client within 24hrs.|
|Zero-day Exploit||A vulnerability is announced but before a patch or solution is implemented.||Reviews incoming access logs to determine if the exploit has been used by a malicious actor. Apply mitigations where applicable e.g. Temporary firewall rules. Monitor developments for the exploit and ship the solution when ready.|
|Password Attack||By accessing a person’s password, an attacker can gain entry to confidential or critical data.||Responds to alerts raised by elevated “access denied” responses. Reviews incoming web requests to determine bad actor(s). Applies additional rules to the WAF solution to block/mitigate malicious requests. Notifies client within 24hrs.|
|Critical||Critical systems offline
High risk to/definite breach of sensitive client or personal data
Severe reputational damage – likely to impact business long term.
|High||Non-critical systems affected
Risk of breach of personal or sensitive data
Potential serious reputational damage.
|Medium||A small number of non-critical systems affected
Possible breach of small amounts of non-sensitive data
Low risk to Client/PreviousNext reputation.
|Low||Minimal, if any, impacts
No breach of data
Negligible risk to Client/PreviousNext reputation.
Containment, Evidence Collection and Remediation
Platform Level Containment
All-access to the Skpr hosting solution will be revoked while the platform team conducts a thorough investigation.
- The Skpr platform team will disable all non-essential AWS IAM users.
- The Skpr platform team will determine scope and if certain roles/accounts can be enabled.
- The Skpr platform team will enable all AWS IAM accounts after the investigation is complete.
Application Level Containment
The application will be taken offline until a thorough investigation is conducted and remediation steps are in place.
The Skpr platform team will disable all routing rules to the application, taking the site offline.
The PreviousNext development team, in conjunction with the Skpr platform team, will deploy a static version of the site that will temporarily serve user requests. This static site will be hosted on S3 and leverage the existing CDN/Edge solution.
The Skpr platform team will enable all routing rules after the investigation is complete.
User Level Containment
User access to the Skpr hosting platform will be disabled.
- The PreviousNext development team will disable all application user accounts.
- The PreviousNext development team will determine scope and if certain roles/accounts can be enabled.
- The PreviousNext development team will enable all accounts after the investigation is complete.
An incident document will be bootstrapped using the PreviousNext Incident Report Template.
Information in this report will include:
- Incident date and time
- Status of the incident
- Incident type and classification
- Scope and Impact
- External assistance required
- Actions that were taken to resolve the incident
- Contact details of both PreviousNext and Client members leading the incident response.
Evidence Collection and Preservation
As per requirements, the Skpr platform team will be collecting and maintaining a chain of evidence throughout this lifetime investigation.
Items which will be collected include:
- Logs - All logs related to interactions with the application and/or hosting platform (CloudFront, Application, Events, Intrusion Detection).
- Screenshots - Any screenshots which demonstrate end user-facing issues as a result of this incident.
- Databases - A copy of the database which was involved with an incident.
- Files - Any files which have been added/modified as a result of the incident.
- Configuration - The platform is managed using infrastructure as code. Any changes as a result of this incident need to be documented.
Remediation Action Plan
The Skpr Platform Lead will manage the remediation of the cyber incident.
The PreviousNext development team will appoint a member of the team to be available for analysis and remediation tasks.
The Skpr team member will use the platform logging features to determine the scope of the incident.
Systems that should be prioritised
- Skpr Control Plane
- Identity Access Management (AWS IAM)
- Central logging solution (Amazon CloudWatch Logs)
- Application backup storage (Amazon S3)
Listed below are some of the systems which may be affected:
- Access to the Skpr platform API due to permissions being revoked
- Access to the Skpr console due to permissions being revoked
- Access to the application via a web request due to firewall rules being updated and/or the application being taken offline temporarily for maintenance
The following section outlines the steps which need to be taken in the event of a platform and/or application level recovery.
The Skpr Platform Lead will manage and oversee the execution of the recovery plan.
|Application Level Recovery||The Skpr platform team determines the security incident is isolated to a single project/application on the platform.|
|Solution||Ensure the application fix has been deployed. Restore the application to an appropriate point in time.|
|Time to Resolution||Hours|
|Steps||Restore the application to an appropriate point in time using the Skpr command line utility. https://docs.skpr.io/using-skpr/restore/create|
|Platform Level Recovery||The Skpr platform team determines the security of the platform has been compromised.|
|Solution||Migrate the Skpr cluster to a new AWS account.|
|Time to Resolution||Days|
|Steps||Skpr platform team provision a new Skpr platform on a new AWS account. Skpr platform team will work with customers to help migrate their applications to the newly provisioned Skpr platform. The Skpr platform team will move application data (database, files etc) to the new platform. Client will review the recovered sites for defects prior. Client will update their DNS records to direct traffic to the new site.|
- DNS - Client will need to update their DNS records to the new Skpr platform as part of the migration.
- Integrations - Development teams will need to test and ensure that the existing integrations with third-party services are still functioning post-migration.
- Static IPs - The Skpr hosting platform provides a set of static IPs for development teams to use when implementing a defence strategy and configuring external services e.g. limit requests to a set of IPs on top of an existing authentication strategy. Client will need to update these configurations with a new set of IPs that are provisioned on the new platform.