Security

Your SOC Easy Button

Managed Security Service Provider

Orion

Time is money & talk is cheap

100% Uptime Guarantee

Travel on your Cloud Journey at the Speed of Light

Network Connectivity

Desktops as a Service

Why move desktops to the cloud?

The smart, secure way to never deal with PCs again

Orion Cloud Desktops

Your Virtual Private Data Center at the Highest Altitude

Infrastructure as a Service

Consulting

DevOps & App Development

Networking Architecture

Systems Engineering

Dedicated IT Services

Consistent, always available & professional support

Help Desk as a Service

Blackhole Community

Community Export

Peer Local Preference

Prepending Order

AS Prepending

BGP Communities

Update Frequency

IP Address Ranges & URLs for Stellar Services

IP Ranges

Peering Policy

Definition

Routing Policy

AS14525 Interconnection Policies & Documentation

Interconnection

Affinity Rules

Required Option

Learn how to protect your highly available applications on Orion

Anti-Affinity Rules

1-help.png

Firewall Requirements

Jump right into Orion Cloud Backup Powered by Veeam

Quickstart

Backup Encryption

Creating a Local Backup Job

Orion Cloud Backup

P0 Events

P1 Events

P2 Events

P3 Events

P4 Tasks

Definition: Point of No Return

Find out how Stellar manages internal and customer-facing changes

Change Control Procedures

Encryption Keys

Learn about how Stellar protects customer data

Data Management

Service Level Agreement

Policy & Procedure

About

What makes us so stellar?

Contact

Master Services Agreement

Privacy

Company

Cloud Desktops

Data Protection

Cloud

Managed Infrastructure

Services

Managed Detection & Response

Vulnerability Management

Managed Security Services

Free Security Demo

Docs

This Standard Operating Procedure ("SOP") document establishes change processes and procedures related to cloud infrastructure services provided by Stellar Technologies Inc. ("Stellar").

Stellar categorizes cloud internal infrastructure changes in the following manner:

Even though it is rare, unplanned outages can happen. During such an event, changes made to troubleshoot or mitigate active problems or to restore services are categorizes as a "Critical Change" or P0 Change, generally correlated to a P0 event. Due to the nature of major infrastructure outages, it is unlikely that a customer will be notified of a P0 Change until after the event has ended. We make every effort to document all changes made during such an event, in order to provide our customers with as much transparency as possible.

Some unplanned outages can be avoided, and we make every effort to ensure they never happen. Occasionally, our internal monitoring and analytics systems alert our operations team of critical events, which we correlate to potential high-impact outcomes. If it is determined that an active alert or event has the potential to significantly impact our infrastructure or customer uptime, an "Emergency Change" or P1 Change may be internally approved and implemented without prior customer notification. While this is rare, it may be necessary to make a service-impacting change in order to prevent a much larger outage or event.

As is not uncommon in the current security landscape, critical security vulnerabilities are sometimes discovered an announced by infrastructure vendors whose equipment we use to deliver our services. In the event that a security patch or update is released in order to address a critical vulnerability on an affected system of ours, our operations team may perform a "Security Patch" or P1 Change if it is deemed vital to the continued security posture of our services. Depending on the severity of the vulnerability and the potential impact of implementing the patch, the patch may be internally approved and implemented without prior customer notification.

In order to maintain our performance, uptime, and availability commitments to our customers, our infrastructure may require occasional maintenance. Maintenance events are usually related to important but non-critical fixes that need to be put in place in order to prevent a critical event in the future. We engineer our infrastructure to be as redundant and highly available as possible, so a "Maintenance" or P2 Change may be necessary to restore an element to a fully redundant state in the event of a minor hardware failure or similar event.

As cloud engineers determined to offer the fastest, most reliable enterprise-native cloud platform, we are always trying to improve our services and give our customers the best cloud experience we can offer. We sometimes decide to implement new technologies, or take what we are continuously learning from the industry and improve our existing architecture, or perform a software upgrade on internal infrastructure in order to take advantage of new features. Once we decide to move forward with a new technology or architectural change after rigorous testing, our engineers meticulously plan the change deployment process and submit an "Improvement" or P3 Change to Stellar's senior engineering leadership for review, approval, and scheduling.

Many of our cloud applications and managed security offerings are self-updating, which means they follow a predefined schedule for implementing minor updates such as security definitions (for detecting vulnerabilities, malware, new applications, etc.) and application dependencies.

Security definitions are automatically downloaded and installed according to the following schedule:

For internally developed or SaaS applications supporting 

-level versions via Continuous Integration (CI) tooling for internally developed applications, and vendor-provided tooling for SaaS applications.

-level version changes are hand-reviewed by an engineer for any potential breaking changes, but are treated as a standard P4-level dependency update once the upgrade is approved in CI.

-level version changes are treated as a P3 event and follow the guidelines described therein.

Non-Provisioning changes are tracked via Stellar's service desk system as a change control ticket. Change control tickets requiring approval are not released to the engineering team for execution until a member of engineering leadership systematically approves the change.

For changes requiring approval, the following process is followed:

For changes that afford prior customer notification, the following process is followed:

This Standard Operating Procedure (“SOP”) document establishes the Data Management policies and procedures pertaining to the services provided by Stellar Technologies Inc (“Stellar”).

The following illustrates the difference and impact of RPO (Recovery Point Objective) and RTO (Recovery Time Objective).

rpo-rto.svg

Production data storage equipment meets the following specification:

Customer-defined "production" data is encrypted at rest using AES-256 encryption via either self-encrypting drives or VMware Virtual Machine Encryption.

Data is isolated on a per-customer basis by volume(s) and/or Logical Unit Number(s) (LUN). No two customers ever use the same storage volume or LUN.

Customer-defined "production" data resides on all-flash storage arrays. Storage IOPS policies are implemented to guarantee customer performance.

Customers may elect for backups of any offering provided by Stellar. Backup services are consumed based on the number of machines protected 

 the total aggregate storage consumption.

Data backups are stored on high-performance enterprise storage to ensure the lowest possible customer data restoration times.

Stellar utilizes the following RPOs and RTOs by default:

Customers may define custom RPO & RTO targets if needed.

Backups are encrypted at rest via Veeam Encryption Keys. Customers subscribed to backup services may set their own encryption key, or use a randomly generated key provided by Stellar.

Stellar-assigned keys are created on a per-tenant basis, and no key is reused. Automatically rotated keys are available upon request.

Data backups are isolated on a per-customer basis by volume(s) and/or Logical Unit Number(s) (LUN). No two customers ever use the same storage volume or LUN.

Backup restoration from source data located within an Orion facility to a target within the same Orion facility has been proven to perform at a rate of at least 1 TB per hour.

Backup restoration from source data located within an Orion facility to a target within a different Orion facility can perform at variable rates, due to differences in available bandwidth or round trip time, depending on the facilities in question. In general, customers can expect a performance rate of at least 400 GB per hour in this scenario.

Backup restoration from source data located within an Orion facility to a target located at the customer premises can also perform at variable rates, depending on the available bandwidth at the customer premises, round trip time, and other congestion factors.

Customers must provide an email address for the purpose of delivering backup success/failure notifications. To request backup notifications, please 

The maximum potential loss of data for Stellar-initiated data recovery events as a direct result of hardware failure is 24 hours (the maximum amount of time between volume copy jobs), and the minimum is 1 hour. Customers impacted from any data recovery event are subject to the maximum credit per Service Level Agreements.

Customer VMs may be replicated asynchronously with a maximum RPO of 1 hour, and will be ready to power on within the customer's Orion cloud environment.

Disaster Recovery as a Service customers can expect near real-time recovery by establishing a virtual standby instance of critical VMs in their DR environment.

Customers may conduct up to two failover tests per month, as long as the total compute runtime does not exceed two hours.

Customers may declare a disaster at any time. Disaster declarations must be provided to Stellar via Phone or Email by a pre-defined authorized contact.

A customer's environment may run in the failed over state for up to 30 calendar days at no additional cost to the customer. If the environment needs to operate in a failed over state for more than 30 calendar days, the customer will be charged a predefined rate per day, per VM.

This Service Level Agreement establishes deliverables and availability thresholds related to cloud infrastructure services provided Stellar Technologies Inc ("Stellar"). These guarantees may be collectively referred to as the “SLA”. This SLA is provided as a supplement to the Master Services Agreement agreed to prior to becoming an Stellar customer, which is hereby incorporated by reference as an indispensable part of this SLA. The Stellar customer may be referred to as “Customer” or “the Customer”.

Stellar offers a 100% uptime guarantee relative to cloud and network infrastructure availability. This uptime guarantee is applicable on a per-service-item basis. For example, if a Customer has fifty (50) servers, and one (1) of those servers experiences downtime, any credit due to the Customer under this uptime guarantee would be proportional to that one (1) server's downtime and not the entire service inventory on the Customer’s account.

This uptime guarantee does not apply to the accessibility of Stellar's website, DNS servers, API, or cloud management portal.

Stellar does not, by default, proactively monitor the packet loss or transmission latency of individual customers. Stellar does, however, proactively monitor the aggregate packet loss and transmission latency throughout its internal and external networks.

In the event that Stellar discovers (either from its own efforts or after being notified by the Customer) that the Customer’s services are experiencing sustained packet loss in excess of one percent (1%) between a given service instance and one hop from Stellar's edge router(s) (i.e., the relevant egress provider’s router) and the Customer notifies Stellar via a support ticket (or Stellar has notified the Customer of an event), Stellar will take all actions necessary to determine the source of the excess packet loss or transmission latency.

The Customer is not entitled to a credit if they are in breach of their services agreement with Stellar (including the Customer’s payment obligations to Stellar) until after the Customer has cured the breach. The Customer is not entitled to a credit if the outage is caused by misuse of the services (intended or otherwise). Customers are not entitled to any credit for outages resulting from denial of service attacks, malware/virus activity, hacking attempts, or any other circumstances that are not within the control of Stellar.

This uptime guarantee only applies to cloud service and network availability during normal operations. The uptime guarantee does not apply to server-side software uptime. Any outage due to server software, operating systems, improper configurations, denial of service attack against a Customer service instance, service suspension, or any other non-network, non-compute node, or non-storage fabric outage, whether or not such outage is caused by Stellar due to critical patching, troubleshooting, or performing tasks/changes requested by the Customer, is not subject to this uptime guarantee.

The guarantee does not apply when a scheduled maintenance occurs with a minimum of twenty-four (24) hour notice or in the event a time critical patch/update must be applied as long as the outage/packet loss does not exceed fifteen (15) minutes.

Furthermore, none of the guarantees in this SLA may be combined. For example, a hardware outage that also disrupts network connectivity does not qualify the Customer for two (2) separate credits. If for example, a hardware outage was the cause of the connectivity loss, the entire event is considered a single outage for the purpose of determining applicable credit.

If Stellar determines that an eligible outage has occurred, credits are calculated as a percentage of the fees for the eligible service instance for the current monthly billing period during which the outage occurred (to be applied on the following billing cycle). The following table outlines the credit amounts on a per-service basis:

In order to receive any credit offered under this SLA, the Customer must submit a support ticket within thirty (30) days following the end of the event and specifically request that a credit be applied to the Customer’s account. Customers should not assume that Stellar is inherently aware of the Customer’s outage, as a given outage or disruption may be wholly unrelated to Stellar’ services or control and should be validated by Stellar.

Customers may submit a support ticket via email to 

, or via the Stellar cloud management portal. After a support ticket requesting a credit is submitted along with supporting evidence of disruption, Stellar must still determine, in its sole discretion, whether or not an eligible outage has occurred.

In the event that Stellar was aware of the outage prior to the Customer, Stellar may notify the Customer of the outage. In such an instance, the Customer must still submit a support ticket associated with the outage along with details relative to the affected service instances, and to request any credit.

The Customer agrees and acknowledges that all other terms, limitations, exclusions, disclaimers and requirements contained in Stellar's Master Services Agreement apply to this Service Level Agreement.

Legal and procedural documentation that may be useful or required for partners, vendors, customers, or prospective customers of Stellar Technologies Inc.

Policy & Procedure

Learn More about What We Do