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 support@sdelements.com:
- 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.
Comments