Security
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.
-
We periodically run Nessus and HP WebInspect against the application (bi-weekly) and the results are reviewed and actioned before the next release.
-
Our security consulting team, which are independent of the development team to avoid conflict of interest, perform a manual assessment on 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 support@sdelements.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), which has been audited and certified by Deloitte.
-
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 2 days since discovery.
-
For all other vulnerabilities, a patch is packaged into the regular product updates, which is available every 6 weeks.