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

  • 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.

results matching ""

    No results matching ""