Security Overview

StormSource Security Overview

Note that this document provides a high-level view of StormSource’s security environment and approach. Details may be provided under NDA.

PUBLIC

Version 3.5

Objectives

The objectives of our security policy are:

Ongoing System Hardening

We have an ongoing hardening process whereby all systems and applications are constantly monitored and assessed to identify hardening opportunities. Unnecessary software is not allowed to be stored on any servers, whether production or development. An annual review of server software is undertaken each December as part of the overall annual security assessment to ensure no extraneous software exists on servers. Automated systems are enabled to review installed software and reset nodes out of compliance to the accepted “standard” when differences are detected automatically. This automated system is focused on Operating Systems and Server Software only.

Internal Reviews

Company security policies and procedures are formally reviewed on an annual basis in December of each year. However, updates and changes are made on an on-going basis, as needed. If during the review, any significant changes are deemed to be needed, plans are devised for addressing them in the following year.

These reviews include the following:

Additionally, disaster recovery procedures are formally reviewed on an annual basis, including conducting a mock recovery.

Security Team

Ultimate responsibility for maintaining and carrying out our security policies and procedures lies with the Chief Security Officer. Day-to-day audit of policies is carried out by the staff with the roles defined for the security team. Day-to-day execution of security policies is the lies with every employee.

The structure of the security team is as follows:

Security Officer

The Security Officer has responsibility for planning, carrying out and enforcing all security policies in the organization. Their responsibilities include:

Systems Security Administrator

The Systems Security Administrator carries out most of the day-to-day security tasks for the company, including:

Policies and Procedures Security Administrator (or analyst)

The Policies and Procedures Security Officer maintains security policies and procedures. Their responsibilities include:

Software Development Life Cycle (SDLC)

Products

Software development at DaySmart Appointments is Product dependent, but all software projects follow essentially the same Software Development Life Cycle, but adaptations are made to fit the project goals when necessary. These adaptations require approval from the Executive in charge of Technology.

The SDLC outlines all aspects of development:

  1. Preliminary Analysis
  2. System Analysis, Requirements Definition
  3. System Design
  4. Development / Unit Testing [Development Environment]
  5. Integration Testing [Development Environment] and [Quality Assurance Environment]
  6. Regression Testing [Quality Assurance Environment]
  7. User Acceptance Testing [Release Preview Environment]
  8. Release / Deploy [Production]
  9. Maintenance [Production]

Maintenance activities are used for critical releases, hot-fixes, patches and minor changes. Those activities may not perform each step, based on procedures developed by the VP of Technology.

The full SDLC is public information, available upon request.

Servers/Hosting

Hosting Partners

As a SaaS provider, we utilize world-class data centers for our server environments. Our partners include Rackspace, and Amazon. All provide best-of-breed security and redundancy.

Rackspace is a world-class hosting provider with data centers in several countries. We utilize both Rackspace Cloud Servers and Managed Hosting. We currently utilize Rackspace data centers in the U.S. and the U.K. for secondary hosting. For detailed data center specification, please refer to www.rackspace.com.

StormSource makes extensive use of AWS for primary application hosting.

AWS Single Sign-On, aws access management
CloudFormation, templated infrastructure automation
CloudTrail, aws governance and compliance auditing
CloudWatch, resource monitoring and observation tool
CodePipeline, automates the build, test, and deploy phases of the defined release process
ElastiCache, scalable in-memory data stores
ELB, elastic highly available and dynamic load balancing
IAM, Identity access management within AWS
Lambda, serverless compute
RDS, scalable relational databases
Route53, elastic, scalable, DNS and load balancing EC2, elastic, scalable cloud computing
S3, object storage
WAF, web application firewall

Network Topology

Although our network topology is considered proprietary and confidential, the diagram below provides a general overview of the current design.

Hardware security

Hardware firewall

We use two levels of firewalls. We utilize IP Tables for our host-based firewall on each server. We also use Cisco ASA 5510 hardware firewalls, in HA mode, as the primary endpoint security device.

The role of a firewall, within AWS, is managed by a combination of SecurityGroups and TransitGateway ACLs – enforcing a default deny policy.

AWS Security Groups – Acts as a virtual firewall for instances to control inbound and outbound traffic. Instances launched without a defined Security Group are assigned a default deny Security Group.
Transit Gateway ACLs – Inter-VPC communications, again with a default deny rule.

IDS

We utilize the Alert Logic Threat Manager IDS on production servers, as well as open-source software solutions like Snort, for non-production environments.

WAF

We utilize the AWS:WAF on production servers, as well non-production environments – to some capacity.

Separation of network layers

Network segregation is accomplished via physical and logical separation of the software application. The front-end has no access beyond the application tier to the database tier, and vice versa. There is no administrative access from the public side of the application.

Web/Application Layer resides in one network segment, and the data layer exists in a separate segment. Within each segment, Security Groups are used to effectively firewall access between different application layers and services. In addition, local firewalls exist within the application servers, set as “Default Deny” with known/allowed services allowed through.

Remote access controls

Remote access for administrative and maintenance purposes is controlled by the endpoint firewall, requiring pre-configured and pre-approved remote site access. The firewall requires a VPN connection, using industry approved encryption levels, and strong two-factor authentication – a company provided software key, and the secure passphrase. In addition, all users are provisioned by the IAM service, which has pre-configured rules allowing access to resources based on job function. Two factor authentication is required for all users.

Service Level Agreement (SLA)

In general, the SLA is provided on a contract-by-contract basis for each Client. It is based upon the SLA’s provided to us by our providers, as outlined below.

Network SLA

Our network SLA is that of our hosting partners. Both Rackspace and Switch offer 100% uptime guarantees. The Amazon SLA guarantees 99.95% availability. All exclude scheduled maintenance.

Hardware and Application SLA

Our hardware and application SLA are based on our standard terms and conditions. For enterprise clients, SLAs may be negotiated as part of the agreement.

Availability

We provide clear guidance to staff on how to identify and maintain commitments to clients, service-level agreements, contractual requirements, and public access for customer portions of the application. 

We maintain a comprehensive Disaster Recovery and Backup policies and procedures to ensure recover data and continuing service in the event of a failure. RPO and RTO are defined, and general procedures are defined to ensure commitments are met.

Full RestorationPartial Restoration
Recovery Point Objective (RPO)No more than 15 minutes prior to disasterData as of the last night’s full backup
Recovery Time Objective (RTO)48 hours or less8 hours

Antivirus

We utilize ClamAV virus/malware protection on our servers.

Monitoring and alerting

We utilize New Relic and Nagios for server monitoring and alerting, and MRTG for statistics including CPU load, network utilization, and database performance.
Our operations staff receives automatic chat, email, and text alerts for:

Auditing and System Logging

All systems utilize centralized logging mechanisms in addition to any local logging performed. The centralized logging solution is strictly controlled, with access restricted to the Chief Security Officer or any designee appointed by the Chief Security Officer.
Executive Management has access to a one-time use passkey for access, should it be necessary to bypass the Chief Security Officer for any reason.
All production and development systems utilize command-history auditing, which is reviewed by the Security team on a monthly basis. History is kept indefinitely and is not removable.

Port security

Only business approved TCPIP ports are permitted to be open on systems, based on a functional need. Those ports can only include:

Application Security

Data in transit

Our application utilizes 256-bit TLS to protect data in transit.

Input validation

Input fields are validated against SQL injection and data type, based on known use cases.

Access controls

Our applications have user access levels, providing companies the ability to segregate users by grouping. Granular, field-level controls are also available as needed.

Authentication/Passwords

StormSource account authentication requires a unique login and password. Passwords must be strong and pass additional validation. Password standards are published, and tailored to general use cases such as employee password, system/application password, and administrative passwords. Each have differing complexity requirements, escalating as privileges increase.

Data Security

Database

We use AuroraDB as our application database. AuroraDB is a core component of the application stack architecture. AuroraDB provides strong security including:

Encryption

Access controls

Access to production data is strictly controlled and limited to the Engineering Leadership and IT Operations group on an as-necessary basis.

Test data

Production data is not used for development or testing. However, scrubbed production data may be used by QA to replicate a client’s account for research purposes. In those cases, the copy application scrubs the data and removes all sensitive data, including email addresses prior to shipping the data to the Quality Assurance Environment for use. Credit card numbers are not stored in our database, ever.

Backups

Our backups are stored at an off-site, separate data center location. They are kept for 14 days, and then destroyed. All backups are stored in an electronic format and encrypted when not in active use. Access to backups is limited to specific personnel.

Destruction/Disposal policy

All sensitive data marked for deletion is overwritten at a block level, using industry standard file wiping techniques.

System Confidentiality


We communicate confidentiality and related security policies, including any changes or updates, to internal and external users, vendors, and other third parties whose products and services are part of the system. Confidentiality and related security policies are communicated during initial approval and annual renewal of contracts and service level agreements, as well as, appearing as a link on the AppointmentPlus website and the internal Confluence resource section.
In the event that a confidentiality practice is discontinued or changed to be less restrictive, procedures are also in place to protect confidential information.

Vendor Confidentiality


We request all vendors and other third parties, whose products and services are part of the system and have access to confidential information within this system, to provide written assurance or representation that the policies of these vendors and other third parties are in conformity with StormSource policies. Vendors and other third parties are required, at a minimum, to provide StormSource with annual updates regarding their policy compliance with confidentiality commitments and system requirements.
All services level agreements and contractual requirements with vendors and other third parties must be maintained at all times and any exceptions must be noted and remedied immediately.

Change Management Process

Organizational Change Management

Organizational Change Management addresses the importance of managing change at the people-level. Our Organizational Change Management process consists of the following steps:

Project Change Management

When requests for system changes are received from any source (clients, internal staff, partners, etc.), they flow through the same process. The process is as follows:

  1. Request
    1. Change request is received.
  2. Analysis
  1. Feasibility analysis
  2. Cost/Benefit analysis
  3. Priority analysis
  4. Value/Impact analysis
  5. Risk analysis
  6. Approval/Disapproval
  7. The Change Management Committee approves or disapproves the change based on the analysis and discussion.
  8. Plan
  9. Develop project plan for change
  10. Development
  11. The change flows through the standard SDLC (systems development life cycle)
  12. Testing
  13. The change is tested by the QA Department.
    1. In the development environment
    2. In a simulated production environment
  14. Change Communication
  1. Documentation and help text are updated or created
  2. Training materials are created
  3. Training is conducted
  4. Release
  5. Release change to production
  6. Verify
  7. Monitor change and verify change is working properly.
  8. Close
  9. Close change request.

QA security/vulnerability testing

As part of our development methodology, all changes or new features are run through a vulnerability scanning process. This includes:


All changes must pass these tests before being moved into production.

Separation of environments

We operate a clear, distinct set of environments, each with separate access controls and purposes. Environments include:


As noted, production data is not used in development or testing. A scrubbed version of a client’s production data may be used by QA for research and analysis.

Segregation of duties

Key IT duties are segregated to decrease the likelihood of errors and/or security breaches. The primary segregated duties include:


This separation of duties is in addition to the standard separation of duties among areas within IT (development, operations, database administration).

Internal Controls

Access

All accounts require strong passwords, with at least 12 characters containing a mixture of at least four (4) of the following elements:

Asset inventory controls

All company owned hardware is tagged with tamper-resistant labels with a unique serial number. These numbers are centrally stored in an internal database storing information such as:


All physical assets undergo a hands-on inventory once per calendar year, with random spot checks occurring once a quarter.

Internal user software and data controls

All internal software utilized to operate day to day business is allocated on a business need basis. Any licensing is controlled centrally, in the same manner as hardware inventory.
No employee is permitted to copy, store, or manipulate client data outside of the production server(s) used to store the client data, except in the case of normal operations pursuant to our BC/DR and general backup operations.

Ongoing education

All employees and contractors must go through a one-hour security awareness training session. The session includes:


Additionally, all technical staff must go through BC/DR (Business Continuity/Disaster Recovery) Training, pertinent to their business function. Sensitive parts of the BC/DR plan are tailored to each employee, based on a business need evaluation.

New staff receives security training as part of their orientation. All staff members are required to attend an annual security and data privacy training session and re-sign the security training documentation.

NDAs

Employees are required to sign a Non-Disclosure Agreement, which covers any customer data that employees encounter during their term at the company.

Employee screening

All employees or contractors must pass a background check as a condition of engagement. Background checks are conducted through EmployeeScreenIQ.

Physical access

Data Centers

Only IT Operations staff have physical access at our Switch data centers. Those with business need are granted access by the Chief Security Officer. Access is only granted after a specific training session going over facilities available, rules, and procedures has been completed by the employee.

Building Access

Only key employees are provided key access to the physical building. An access alarm system with immediate key employee alerts and police dispatch is used to secure the building. No production data is housed at our office, so potential client data privacy issues are minimized should there be a building security breach.

Passwords

In addition to application password controls, internal systems are subject to a similar level of security. The following are the password guidelines all employees and contractors agree to uphold:

Employee termination process

The employee termination process includes immediate revoking of access to the following:

Telecommuting

Telecommuting computing has inherent risks. The following safeguards must be taken when using a laptop remotely:

Mobile access

When accessing system via a handheld device, such as a smart phone, the following policies are in effect:

Email

Virus Protection

All anti-virus software is automatically kept up to date. Anti-virus software is set to automatically download virus definitions and to automatically scan emails.
The following guidelines are used when reading email:

Prohibited Use

The company email system shall not to be used for the creation or distribution of any disruptive or offensive messages, including offensive comments about race, gender, hair color, disabilities, age, sexual orientation, pornography, religious beliefs and practice, political beliefs, or national origin. Employees who receive any emails with this content from any company employee should report the matter to their supervisor immediately.

Personal Use

Using a reasonable amount of company resources for personal emails is acceptable, but non work-related email shall be saved in a separate folder from work related email. Sending chain letters or joke emails from a company email account is prohibited. Virus or other malware warnings and mass mailings from the company shall be approved by the CIO before sending. These restrictions also apply to the forwarding of mail received by a company employee.

Monitoring

Employees shall have no expectation of privacy in anything they store, send or receive on the company’s email system. The company may monitor messages without prior Notice.

Enforcement

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Sensitive information

Information is considered sensitive if it can be damaging to the company or its customers’ reputation or market standing. Information is also considered sensitive if it describes, states, or implies any information classified as private, confidential or sensitive. Any information described above is not to be distributed via email at any time.

Unauthorized Disclosure

The intentional or unintentional revealing of restricted information to people, both inside and outside the company, who do not have a need to know that information is strictly prohibited.

Clean Desk/Clear Screen Policy

Contractors

We may occasionally use contractors for technical work, such as web site development, application development, or support system administration.
All contractors are required to sign NDAs, undergo the same security training as StormSource employees, and maintain an acceptable level of security on equipment and tools used during the course of their work.

Third-Party Compliance

Standards

PCI-DSS

We achieved full PCI-Exemption in Q2 of 2011 as we currently do not store, transmit or capture credit card information for our clients that process credit card sales transactions. All credit card transactions are carried out via hosted pages, provided by the financial institutions processing the transaction. The transaction does not take place within, or on, StormSource infrastructure.
HIPAA
Recent enforcement changes have extended HIPAA compliance to business associates (BAs) – those partners used by the covered entities. By default, our application systems are HIPAA-compliant. However, covered entities can take themselves out of compliance by changing certain system settings that allow PHI (protected health information) to be passed via email, for example. By being cognizant of HIPAA regulations, covered entities can remain in compliance while using our systems.
SSAE16
Because were fully PCI-Exempt as of Q2 2011, our focus on internal controls auditing will be on SOC Type II. We currently maintain an annual SOC II Type 2 certification, periods between July 1st and June 30th of each calendar year.

ISO Data Security certification
There are plans to become ISO certified. No date has been set, but this will be updated once scheduled. Most certification requirements for this standard are covered by the PCI, HIPPA and SSAE compliance certifications, so many requirements are already in place. StormSource relies on elements of the ISO standard to create and maintain all standards in use.
US Privacy Shield
StormSource participates in the US Privacy Shield, or its successor, complying with all requirements.

Vulnerability testing

StormSource regularly conducts our own third-party vulnerability testing, and many enterprise clients have ordered and conducted third-party vulnerability testing at their own direction and expense. As we are under NDA with these clients, we may not share their test results. StormSource, as a matter of course, does not share any customer testing results with anyone except the 3rd party auditors for SSAE16 certification.

Annually, StormSource conducts a full assessment, using a 3rd party. The annual assessment summary created from this assessment is provided to clients and prospects interested in the security posture of the application.

Disaster Recovery/Business Continuity

Objectives and Key Points


The primary objectives of this plan revolves around Return To Service (RTS) within 8 hours and a Recovery Point Objective (RPO) of 15 minutes or less.

To accommodate these service levels, when an incident occurs we will quickly evaluate the situation to determine whether to enact this plan, or if they proceed as if it is a normal recoverable incident.

Main criteria for declaring a disaster:

Declaring a disaster requires at least one item from the list of consolidated disaster criteria.

The primary objectives are:


Another key component is to keep clients informed as to what has happened, what the next steps will be, and what the estimated time frames are. This is done via email to the main contact person on each account, or via our status page found at DaySmart Appointments Status. Updates are provided as often as possible during any incident. Communications of this nature may not provide all details, but will clearly indicate when the disaster has been declared.


The restoration process is led by an incident commander and involves the entire IT team. The incident commander will appoint one person for communications. In addition, one additional leader will be identified as a reserve “commander” for the duration of the disaster, trading off with the primary until the process completes.

The person responsible for communications will provide an update in the incident communication channels every 15 minutes, even if there is no update. That information is intended to be consumed by the business and distributed to internal and external stakeholders as often as necessary. All internal and external inquiries go to the communications person, and they will in turn, work with the commander to answer.

Process


In the event of an actual disaster, the following general process is followed:

Incident Tracking and Communication

Incident Reports

Incident reports are created for every incident impacting the ability for clients to access the system, or their data.
Incident reports include the following:


Incident reports are accessible by all staff.
There are several types of incident reports:

  1. Network/Hardware Incident Report (created by the IT Operations Manager)
  2. Security Incident Report (created by the Security Officer)
  3. Application Incident Report (created by the QA Manager)

Incident Communication

Internal Communication

During an incident period, the responsible party (ie: IT Operations Manager, Chief Security Officer, or QA Manager) will communicate to the managers based on the following guidelines:

External Communication

For issues taking more than 15 minutes to resolve, clients will receive the following communication:

Also of Interest