v1.2

tools.6seconds.org Security protocols

The document describes the security standards we have adopted and procedures that govern our Tools application and associated servers. Six Seconds have taken preventive measures to optimize security with systems, architecture, and policies to minimize security risks for our clients and partners.

Systems for tools.6seconds.org information security

Servers are located within with AWS US West (Oregon). Servers can be migrated to other regions during disaster recovery.
Our data center is ISO 27001 certified.
We are PCI compliant and audit code for OWASP Top 10 vulnerabilities.
Data is encrypted at rest using AES-256.
The connection to the tools app is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_ECDSA with P-256), and a strong cipher (AES_128_GCM).
We use Cloudflare to provide a relay layer through which user’s access to our apps deployed on AWS (Amazon Web Services) secure servers.
Valid HTTPS Certificates from a Reputable CA (Certificate Authority) are being used on our servers; these certificates are signed by a reputable certificate authority.
All components of infrastructure that support our application are configured according to security best practices and hardening guidelines including but not limited to firewalls, operating systems, web servers, application servers, databases, and application frameworks.

Architecture for tools.6seconds.org information security

Our single sign-on (SSO) implementation is based on OAuth 2.0 and OpenID connect security standards which is also capable for multifactor authentication was released in 2017 for our tools, EVS and EQ.org application - the SSO system is a centralized login at https://accounts.6seconds.org.
We show generic error messages, to not reveal details about the internal state of the application. For example, file system path and stack information isn’t exposed to the user through error messages.
Tools app doesn’t utilize browser caching to keep all the data on our secure end points.
The app is not allowed to have unhandled exceptions, we test to prevent an unhandled exception to occur. Error handlers have been configured to detect unexpected errors and gracefully return controlled output to the user.
Framework Generated Errors are suppressed and replaced with customized error messages as these messages may reveal sensitive information to the user.
We log errors for internal auditing; all sensitive data is unencrypted and only available to authorized personnel.
Logs are stored and maintained appropriately on secure area to avoid information loss or tampering by intruder.
HTTPS is used for our entire application including public and secure pages. All sensitive information is submitted through authentication and secure socket layer (SSL).
HTTP Access for All Protected Resources is disabled, like all pages requiring protection by HTTPS, the same URL isn’t accessible via the insecure HTTP channel.
User Passwords are stored using a Strong, Iterative, Salted Hash.
Tools App has strong password reset system which only provide access to new password to tools real account holder.
Messages for authentication errors are clear and, at the same time, written such way so that sensitive information about the system is not disclosed. For example, log-in error messages do not reveal if the attempted userid is valid (which would confirm to an attacker that the account does exist on the system).
Session tokens are generated by secure random functions and with sufficient length so as to withstand analysis and prediction.
When the user logs out of the application the session and corresponding data on the server is destroyed. This ensures that the session cannot be accidentally revived.
We have placed Logout links on every page so that, once a user is authenticated, the user can log out to end their secure connection.
The Tools app uses principle of least privilege where, when a tools account is created, rights are specifically added to that account by business team to grant access to limited resources.

User & Personnel policies for tools.6seconds.org information security

All users are required to agree to Six Seconds’ Terms of Use (6sec.org/terms) including requirements of password security and privacy.
The application data, logs, and encrypted personal data are not available to third parties.
All Six Seconds’ IT team members with access to secure data are trained in the security protocols outlined in this document and operate with signed nondisclosure agreements.
Individual personal computers and backups of confidential data are required to be stored on secured archives using a minimum of 256-bit encryption algorithm encoding along with a password.
Tools data access is locked down using passwords and authorized to only few company resources.
Secure Key management processes take care of keys stored in our system and only accessible to the appropriate staff on a need to know basis.
We conduct security focused code reviews to find security bugs. There is a regular review code to investigate common issues like SQL Injection and Cross-Site Scripting.
We conduct security testing both during and after development to ensure the application meets security standards and vulnerabilities did not get introduced during the update process.
The development team periodically take software security awareness training from available trainings resources to make sure tools application is compliant with security standards.

Note: This document does not replace Six Seconds' Terms of Use, and in the event of a conflict, the Terms of Use take precedence.