Security
Security processes at Security Compass
Security Compass is certified against ISO 27001:2013 Information Security Management System (ISMS). Security Compass ISMS is designed to implement and continually improve organization-wide information security. It has helped us to formalize and standardize our security measures and align with industry leading best practices.
We have a dedicated Information Security Manager and Information Security Analyst leading all internal security and privacy initiatives. The Information Security team works with various internal teams to ensure implementation of security controls.
We believe in defense in depth and have three lines of defense for information security and governance:
-
On-ground implementation of security controls by operational teams.
-
Risk monitoring and oversight.
-
Regular internal and external assessments and audits.
We are also audited against SOC 2 Type 2 annually by external auditors. Please get in touch to request a copy of the report.
How is SD Elements secured?
We undergo a few different steps for securing SD Elements, which are categorized below.
Security in the development process
-
We "eat our own dog food" by modeling the development of SD Elements in SD Elements itself for each release of the application.
-
The development team actions on security tasks compiled for each release and the QA team uses the test requirements to validate that the requirements are met before release.
-
An external security consulting team of pentesters performs a manual and automated assessment of the product regularly (at least once a year).
Security through architectural design (applies to On-Site Deployments)
The following is a non-comprehensive list of security controls used in SD Elements application.
If you have any questions about a specific security control, or need a more comprehensive list, please contact SD Elements support at sdesupport@securitycompass.com.
-
The SD Elements application follows the standard three layer segregation model in its architectural design. SD Elements has separate Web service, Application server, and Database layers.
-
Although all layers reside in the same server/virtual-appliance, all processes and data files are segregated by the underlying operating system control access rule. Each layer’s processes are executed within a different user space and the files are owned and restricted to the same user space. The three layers only communicate through local sockets.
-
SD Elements has a minimal attack surface. It only listens on ports 80/TCP for HTTP, 443/TCP for HTTPS, and 22/TCP for SSH that allows for remote administration.
-
All unneeded ports (except for the ones listed above) are blocked, and all unneeded services are disabled on SD Elements servers.
-
All communication with SD Elements is encrypted using HTTPS (TLS) and the HTTP port is used solely to redirect the user to the secure protocol.
-
All transactions are logged according to industry best practices, such as all requests being logged along with the IP of the requester.
Security of our SaaS platform
-
Our SaaS infrastructure is SSAE-16 compliant (replaces SAS-70).
-
Access to production systems are on a need-to-know basis and restricted to the IT administration and support teams.
-
SD Elements servers are behind a locked down firewall.
-
Administrative access to SD Elements servers are restricted both by source IP (limited to IPs owned by SD Elements IT) as well as individual user authentication.
-
All communication to the SD Elements server goes through an Intrusion Prevention System (IPS), which filters the traffic for known attacks before reaching the application code.
-
Development teams do not have access to production servers.
What is your policy for addressing vulnerabilities?
SD Elements has the following policy for dealing with published or known vulnerabilities:
-
The Security Compass team continuously monitors for vulnerabilities in its software.
-
For critical vulnerabilities, we publish an update, patch, or a remediation plan out of band with a target of availability of 15 days since discovery.
-
For high severity vulnerabilities, we publish an update, a patch, or a remediation plan within 30 days of discovery.
-
For medium and low severity vulnerabilities, we publish an update, a patch, or a remediation plan within 60 and 90 days respectively.