Security & Privacy Controls
Below is a list of security processes, technological controls and compliance details currently implemented in the StellaService Platform.
Data Center Security
The Stella Connect software platform is hosted on isolated cloud-based networks protected by firewalls and several layers of access control. The platform is hosted primarily by Amazon Web Services (AWS) in the northeastern United States. Details of physical and software security systems in place for AWS are here: https://aws.amazon.com/security.
Parts of StellaService are hosted on Google Cloud Platform (GCP) in its northeastern United States data center. Details of physical and software security systems at GCP are here: https://cloud.google.com/security.
Only authorized personnel have credentials to access the StellaService AWS and GCP accounts. Authorized personnel each have a separate account with different levels of permissions. We use Identity Access Management (IAM) services to manage roles at a granular level based on the position of the engineer, with minimal access granted in each case, and access levels are reviewed at least quarterly. Changes to permissions are audited by AWS Cloudtrail and GCP’s Cloud Audit Logging. Multi-factor authentication is required to log into the accounts on AWS and GCP.
Database field encryption
Due to the sensitive nature of end customer information, PII of end customers is stored encrypted at rest with AES-256 symmetric encryption. The encryption keys are stored separately from the data and vary by client. This means exfiltration of the database will not allow a hacker to access end customer PII. Distinct client-based keys means that access controls force a logical separation of client data.
Security Patching Policy
Patching and updating of the underlying systems are performed and coordinated by our devops and security team. All changes to infrastructure assets are reviewed by qualified personnel before applied to systems. The StellaService tech team periodically applies OS patches to our EC2 servers. Critical security patches are applied promptly to all servers. Before applying OS patch releases to the live environment (accessed by customers), we first automate the process and run it in a testing environment to cover edge cases and prepare. Patching a server is considered a system upgrade, similar to the release of code. Patches are evaluated by the tech team and the appropriate level of testing is applied prior to releasing to production.
Once a patch is cleared for release, scheduling of the release follows the general StellaService Release Management Process. Each patch is classified based on severity of impact and potential for service disruption. Client notification on patches follows the risk classification of each patch, according the the StellaService Release Management Process. StellaService provides support for releases to ensure the platform is online to our clients after applying OS security patches to our servers in AWS and for other support needs.
Managed services such as S3, Lambda, databases and GKE are patched regularly by Amazon as part of the AWS SLA or by Google as part of the GCP SLA. Details of their patching policies can be found in their respective security policies.
Vulnerability Management and Web Application Security
StellaService runs a web application vulnerability scan of all of our applications on a quarterly basis and analyses the report in order to identify new vulnerabilities.
On an annual basis StellaService employs an outside penetration testing firm to do a deeper penetration test involving trained hackers who have access to the site’s source code. This test involves a wide range of attack vectors, from the network to the web application to the business logic and permissions systems.
Our software release process includes an automated scan of the codebase for vulnerabilities.
As part of the SDLC, an architecture review is initiated by a committee for infrastructure-changing features, and security impacts are considered. If there are material impacts to the security or handling of data, the change is accompanied by a Data Privacy Impact Assessment.
We have documented standard security configurations for each system type that are reviewed annually and as needed.
We have a tiered classification structure for vulnerabilities discovered through the above process, and there is a prioritization process for mitigation based on that structure. High risk vulnerabilities
are addressed immediately without delay. Medium risk vulnerabilities are addressed within 1 month.
We review audit logs quarterly.
We have a formal plan in place for determining incident scope, building the correct response team, isolating the incident, gathering evidence, mitigation, and notification.
StellaService servers are virtualized and are managed via a container system. This means that our anti-malware activities are adjusted to the containerized architecture. All configuration is checked against our approved configuration. Source code changes are automatically scanned for malware. Libraries are analyzed for malware before being added to a container configuration. Container activity is monitored for malware signatures.
A combination of systematic safeguards and following security best practices as well as continuous monitoring of logfile output are used to guard against unauthorized access.
Intrusion Detection
StellaService servers are ephemeral containerized servers that run on top of a highly secured server subsystem that runs intrusion detection systems (IDSs). The IDSs use a range of signature-based detections that involve known malware signatures and heuristic processes for discovering new types of infiltration. We are alerted immediately if an intrusion is detected.
Separation of Access Levels for Source Code and Non-Privileged Configuration Information
Only named designated engineers and administrators authorized and responsible for making changes to the code and configuration of the Connect system are permitted write-access via source controls systems and configuration and deployment management systems.
Other designated engineers and administrators are provided with read-only access to source control systems and configuration management systems via specific read only roles within such systems.
Data Access Policy for StellaService employees
In order to maintain the confidentiality and security of customer and consumer data, StellaService has implemented a variety of access roles to balance the need to support and service customers and retain necessary security of information. The following levels of access exist for StellaService employees:
Designated Engineering and Infrastructure Personnel | Can Access and Maintain All Data | |||
Designated Client Service Personnel | Access All Data | Alter Client Configuration | Grant Similar Access | |
All Client Service Personnel | Access All Data | Alter Client Configuration |
| |
Client Account & Sales Personnel | Access All Non-PII Data |
|
|
|
Exceptions to these access roles must be requested, granted and recorded in an internal management system.
Access to the production database store and backend systems is limited to the developers maintaining the system and our devops team.
Access to the Connect web interface is via https authentication, and is controlled via roles determined by the Connect administrators and Company administrators. Roles specifically restrict the ability to access and export sensitive data, to select accounts with specific business needs for it.
All personnel with access to the Connect platform have the following security measures enabled.
Two factor authentication required for email and domain services
Workstation hard drive secured using up-to-date industry standard encryption practice
Workstations configured to require re-authentication if left unattended no more than 5
minsInventory management system that includes the ability to remotely wipe the storage
For shared documents, any document or data containing raw or line item client data is shared via google drive shared folders, with explicit access granted only to authorized recipients.
Passwords must not be shared with anyone. All passwords are to be treated as sensitive information.
Any user suspecting that his/her password may have been compromised must report the incident and change all passwords.
We require the use of password managers with strong passwords as best practice internally, and we recommend them for our clients.
We believe that enforced password expiration encourages easy-to-crack passwords and we do not require password rotation. Therefore, we do not have a policy around limiting password values based on originality.
Within the application, passwords are never transmitted or stored in plain text, and are salted and hashed in our database, and once lost they can only be reset, not recovered.
Separation of Production and Staging (Testing/Development) Environments
The Production infrastructure is kept separate from other infrastructures and access to each is distinct and uses unique credentials for each individually.
Additionally, only sanitized / anonymized data as opposed to full copies of production data is used in non-production environments.
Log Management and Event Consolidation
Logging of all production systems is centralized, and access is restricted similarly via 2FA https account-based logins. Alerting of infrastructural problems and abnormal access patterns is provided via integrations with several hosted services which receive event and error logs that have been stripped of customer data.
For server access, security events are logged (e.g. logon, logoff, timeout, changes to privileges, etc). Security logs are also sent to ELK and follow the same backup procedures and retention policies as our server logs.
The system also logs to our database the audit log with changes to any entities in the system (users, roles, data changes, etc.).
Lastly, for Enterprise Service Management, we use AWS CloudTrail which records any access and changes to our AWS account, either via AWS console or API.