Security

Security processes at Security Compass

Security Compass has developed an information security management system in line with ISO/IEC 27001:2013. This system 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 completed a Stage-1 and Stage-2 compliance audit and received certification in Q4 2020.

We have a dedicated Information Security Officer leading all internal security and privacy initiatives. The Information Security Officer 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:

  1. On-ground implementation of security controls by operational teams.

  2. Risk monitoring and oversight.

  3. Regular internal and external assessments and audits.

We also plan to initiate a SOC 2 Type 2 assessment in Q4 2020 to further strengthen our security stance and showcase our commitment to ensure internal and client data 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.

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

results matching ""

    No results matching ""