Appendix A
Internal Use
Business Continuity Plan — Appendix A: Business Impact Analysis
This appendix supplements the Business Continuity Plan. It documents the Business Impact Analysis (BIA) including system criticality, resource requirements, and recovery priorities.
System Description
Dispel runs a Node.js backend server and postgres on AWS, maintained by and through Heroku. Our Node.js backend speaks to RedHat Tower to provision virtual machines for build client SD-WANs and virtual desktops. These virtual machines are provisioned in Microsoft Azure and Amazon Web Services. Unless otherwise specified for a bespoke customer deployment, our static infrastructure resides in the United States. Clients may choose which physical Azure/AWS data centers they want their virtual machines provisioned in. Dispel uses a NIST 800-160 Vol 2 resiliency model for deploying virtual machines, and our SD-WANs are build on a Moving Target Defense model. Our postgres database is backed up regularly by Heroku to an encrypted AWS S3 high availability region in the US. Please see the network architecture diagrams in our documents for visual representations of our infrastructure.
Data Collection
Data collection is performed by the CEO, working with CTO on behalf of engineering and the COO on behalf of operations.
STEP 1. Determine Process and System Criticality
Identify the specific business processes that depend on or support the information system, using input from users, managers, business process owners, and other internal or external points of contact.
| Business Process | Description |
|---|---|
| Billing | Billing includes invoicing, receiving payments, tracking customer spending, and outpayments from our payment processor (Stripe) to our corporate bank account. Billing also includes PCI compliance and all payment systems. |
| Support | Support includes Dispel’s helpdesk and support documentation portal. Support channels allow customers to ask questions of and receive answers from the Dispel operations team. |
| Online Services | Online Services includes Access Request Forms, VDI Management, Device Operations, and Resource Operations. All Online Services are serviced through the Dispel online dashboard, and rely on a backend Heroku-managed server. All Online Service functions are contained within one API. Online Services are used for account management, access control administration, and remote access initiation. |
| Network Services | Network Services includes Enclave, VDIs, and Wickets. Network Services are the SD-WAN and complementary components involved in providing the connectivity to a customer’s facility. |
Outage Impacts
Impact categories and values characterize levels of severity to the company that would result for that particular impact category, if the business process could not be performed.
| Business Process | Impact |
|---|---|
| Billing | Billing runs separately from our platform. If our billing platform experiences downtime, it will not affect our clients’ operations. Most of our billing is to large clients at a small volume, which means processing invoices after a period of downtime will not significantly impact the organization. |
| Support | Our primary support platform is Intercom. If this chat system goes down, we can still be reached by our phone support line and our email inbox (support@dispel.io). The largest impact to clients would be a process change for them. Almost all clients always contact us through our Intercom web chat portal. While frustrating to users, the impact would still be minimal. Given the other alternative channels, and that we can still monitor system health independent of Intercom, we can ensure systems are online during a support outage. |
| Online Services | Downtime in our Online Services would significantly impact our clients. They would not be able to complete access request forms, manage users, change access control lists, and complete most other functions. It is also highly likely that an outage of online services would impact the ability of Dispel application users to log in. An Online Services outage would not immediately affect SD-WAN VPN and VDI sessions ongoing prior to the outage. |
| Network Services | Downtime in our Network Services would impact the ability of a client to remotely connect to their facilities. Network Services are all single tenant, meaning that an outage event stemming from a VM failure would not affect multiple clients, nor would it affect other Enclaves. |
Estimated Downtime
Downtime factors resulting from a disruptive event will be estimated by working directly with business process owners, departmental staff, managers, and other stakeholders. The following downtime categories will be considered:
- Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time managers are willing to accept for a business process outage or disruption and includes all impact considerations.
- Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported business processes, and the MTD.
- Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or system outage, to which business process data must be recovered after an outage.
| Business Process | MTD | RTO | RPO |
|---|---|---|---|
| Billing | 2 days | 2 days | 15 minutes |
| Support | 1 day | 1 day | 1 hour |
| Online Services | 6 hours | 2 hours | 15 minutes |
| Network Services | 48 hours | 24 hours | N/A — no restorable data stored |
MTD and RTO do not include applicable travel, if the customer requires that we travel to their site for an on-premises resolution.
STEP 2. Identify Resource Requirements
Identify the resources that compose Dispel Online Services in support of business processes, including hardware, software, and other resources such as data files.
| System Resource / Component | Platform / OS / Version | Description |
|---|---|---|
| Heroku | N/A | Heroku provides the DevOps, database, monitoring, and general maintenance and availability of our Node.js backend server and postgres databases. If Heroku goes offline or experiences an outage, we lose their DevOps capabilities, as well as the entire backend system that runs Online Services, and upon which Network Services depends. |
| Amazon Web Services | Route53, S3, virtual machines | We use AWS Route53 for DNS, S3 for data storage and backups (Heroku backs up our postgres database to S3), and at times we deploy Network Services virtual infrastructure for clients to AWS. |
| Microsoft Azure | N/A | Azure provides virtual desktops and virtual machines supporting Network Services. |
| RedHat Tower | N/A | Tower handles orchestration between the Node.js backend and our cloud infrastructure providers (e.g., AWS, Azure). Commands issued by clients are routed through Tower and handled by their system. |
| Mailchimp | Mandrill | Mailchimp Mandrill sends emails to customers to notify them of new access request forms (ARF). In the event of a Mailchimp outage, ARF notifications will not be delivered to customers. To offset this risk, all ARF confirmation web pages include a link the requester can share with the recipient for manual approval. |
STEP 3. Identify Recovery Priorities for System Resources
List the order of recovery for Dispel resources, and identify the expected time for recovering the resource following a “worst case” (complete rebuild/repair or replacement) disruption.
| Priority | System Resource / Component | RTO |
|---|---|---|
| 1 | Heroku — Virtual Machines | 1 hour |
| 2 | Heroku — Postgres | P1 + 30 minutes |
| 3 | Microsoft Azure | P1 + 1 hour |
| 4 | RedHat Tower | P1 + 1 hour |
| 5 | Mailchimp | P1 + 2 hours |
Any alternate strategies in place to meet expected RTOs will be identified, including backup or spare equipment and vendor support contracts.