Introduction
anDREa is committed to protecting the security of its business information in the face of incidents and unwanted events and has implemented an Information Security Management System (ISMS) that is compliant with ISO/IEC/27001:2013, the international standard for information security.
The purpose of this document is to describe anDREa’s Contingency Procedure. This procedure encompasses the Business Continuity Plan as well.
This document will be updated at least annually and when significant change happens.
Contingency Procedure
Scope
anDREa’s operations are running on Microsoft Azure and are all tied to the same Azure Active Directory (AAD). The AAD provides access to assets needed to run the business, the assets required to run and access the Azure DRE Shared Tenant, and the Workspaces at the Tenants.
anDREa’s Contingency Procedure deals with any threat or incident that has a major impact on an ANDREa's customers or anDREa itself. The Contingency Procedure includes but is not limited to the Business Continuity.
The prioritized scope of the Contingency Procedure is:
- The operational Core of anDREa including the AAD
- The Subscriptions and their Workspaces
- Github with the anDREa code
- Development, Test & Acceptance environment
- ZoHo Desk
- Office 365
Assumptions
The viability of this Business Continuity Plan is based on the following assumptions:
- That a viable and tested IT Disaster Recovery Plan exists and will be put into operation to restore data center service at a backup site within three working days.
- That this plan has been properly maintained and updated as required.
See: Support and Escalation Contacts in the different departments in
support.mydre.org
General procedure
When this procedure must be applied, the situation is by far from normal. Emerging findings and observations will dictate how to proceed. The procedure described below is therefore more of a guideline than strict and detailed procedure that must be followed.
- Establish if the threat is ongoing
- Block and contain the threat
- Apply the appropriate hand-brake(s) if needed to contain and/or protect: Workspace, Subscription, Shared Tenant
- Shut down and isolate compromised (Workspace) VMs
- Explicitly keep monitoring all resources for strange behavior or other vectors of attack
- Keep the logs safe
- Scramble a team
- CTO, IT architect, senior devs, ops
- Inform (C)ST, users and other relevant stakeholders
- Establish if the cause is a network attack, an authorization attack, or rogue internal application
- When possible isolate the services involved in the threat for deep investigation and possible forensic investigation, if not destroy the services
- Establish what has been (potentially) compromised
- If applicable develop and deploy hotfixes
- Restart or redeploy services
- Inform (C)ST, users and other relevant stakeholders
- In case of (possible) compromised workspaces or data leaks: Data Breach Procedure
- Root cause analysis & Resolution