How is SD Elements secured?

We undergo a few different steps for securing SD Elements, which are categorized below:


Security in development process:

  • We "eat our own dog food" by modeling the development of SD Elements in SD Elements itself in each release of the application.
  • The dev team actions on the security tasks compiled for each release and the QA/test 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 on 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 via Architectural Design (applies to On-Site Deployments as well):

The following is a non-comprehensive list of security controls used in SD Elements application. If you have any question about a specific security control, or need a more comprehensive list, please contact SD Elements support at

  • SD Elements application follows the standard three layer segregation model in its architectural design. SD Elements have separate Web service layer, Application server layer, and Database layer.
  • Although all layers reside in the same server/virtual-appliance, all the processes and the data files are segregated by the underlying operating system control access rules and 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 via local sockets.
  • SD Elements has a minimal 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 un-needed ports (except for the ones listed above) are blocked and un-needed services are turned off 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 (e.g. all requests are 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 recently.
  • The access to the 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 SD Elements server go through an Intrusion Prevention Device (IPS) which filters the traffic for know attacks before reaching the application code.
  • Development teams do not have access to production servers.



Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request