Security Features

Security features of the Totem™ Cybersecurity Compliance Management Software:

At Totem.Tech, we take the security of our software seriously.  We recognize that there is no magic bullet that provides absolute protection, so we approach security from a “defense-in-depth” mindset.  Security starts with our company culture that demands a security-first mindset and extends to our software development, deployment, and maintenance.  We also understand that, despite our security practices, additional vulnerabilities can be introduced by the end user.  To help protect against these vulnerabilities, we also provide Totem™ users with the knowledge and tools they need to keep their data safe.

Totem.Tech employees understand the need for security.  Not only is Totem.Tech a veteran-owned company, most of its employees are military veterans.  Totem.Tech employees individually have decades of experience on the frontlines of security, whether in the private sector or in the military.  All Totem.Tech employees undergo criminal background checks prior to employment to help ensure there is nothing in their background that would indicate they are untrustworthy or vulnerable to hostile influence.  Totem.Tech employees receive continual security training to help them follow best practices and to be able to identify threats to systems, software, and organizations. 

To secure the Totem™ software, we adopted the standards prescribed by the “SANS Securing Web Applications Technologies (SWAT) Checklist”.  The SWAT Checklist provides a comprehensive framework to build, deploy, and maintain web applications that are resistant to common threats.  Key Totem™ security features include:

Access Control

• Totem™ utilizes a custom RBAC/ABAC access control system that ensures access decisions for all aspects of the tool are based on the principle of least privilege. If not explicitly allowed, access is denied. After an account is created, access rights must be explicitly and specifically added to that account to grant access to resources. 
• The centralized access control system on the server side employs a single function to ensure access control checks are triggered, whether or not the user is authenticated.
• Access control decisions are based on the authenticated user identity and trusted server-side information. Direct references to files or parameters that can be manipulated to grant excessive access are not allowed.
• Unvalidated redirects to the Totem™ site are redirected to the login page. The login page and forgot password pages are the only pages available without user authentication. 

Authentication

• Totem™ is architected into three separate zones: data, application, and presentation. Level of trust required for access increases from presentation to application to data zones, and separate administrative credentials are employed to access each zone.  Automated processes utilize credentials that provide the minimum required privileges for process execution.
• Password reset requires the submission of a valid email address associated with an active account and is executed by following a tokenized link sent to the email address. The time delay between email address submission and Totem™ server logon feedback is randomized to prevent side channel discovery of valid email address.
• After a failed login attempt, Totem™ provides a generic failure message to indicate that the credentials were incorrect without revealing whether the failure was due to an incorrect username or password. This helps prevent username harvesting.  The time delay between logon attempt and Totem™ server logon feedback is randomized to prevent side channel discovery of valid vs invalid usernames and passwords.
• Credentials are never hardcoded in the application software, even for testing.
• Totem™ implements account lockout to guard against brute forcing attacks against both the authentication and password reset functionality. After several failed access attempts, the account is locked out and must be manually unlocked.
• The authentication credentials that allow the Totem™ application zone (business logic) to communicate with the data zone (database) are stored in a separate secured configuration file. User account credentials are encrypted by a hashing algorithm that employs a random salt and high work factor.
• Totem™ requires users in multitenant organizations to engage multifactor authentication for their user account.

Configuration and Operations

• Totem™ developers use well-respected and supported Continuous Integration and Continuous Deployment tools and practices to ensure all changes are made in a consistent and repeatable manner in all environments.
• Security requirements for the Totem™ software were defined by a team of cybersecurity experts before development began and are continuously monitored and adjusted according to risk assessments. Application penetration tests are routinely performed, the results of which our team uses to refine security requirements.  
• Members of the Totem™ development and management team are all US citizens, all of whom have or have had a DoD Security Clearance. The team regularly attend security awareness training, such as that offered by the SANS Institute, and continuously monitor cyber threat feeds, such as US-CERT alerts.
• Updates to Totem™ software are first deployed to a staging server before they are integrated into production. Totem™ maintains a rigorous change management process ensure and changes do not break existing software. Operating systems and application modules are patched on a weekly basis.
• All the components that support Totem™ are secured and hardened according to industry standard and manufacturer guidelines. These components include application firewalls, operating systems, web servers, application servers, databases, and application frameworks.
• Totem™ undergoes a rigorous third-party penetration test prior to each major release. Any vulnerabilities are discovered during the penetration test are remediated, and the remediations are confirmed by a third-party before Totem™ is released.

Data Protection

• All access to the Totem™ software is routed through secure HTTPS connections. HTTP requests are redirected to HTTPS. The Strict-Transport-Security header is engaged to ensure your browser does not talk to the server over HTTP.  Totem™ uses HTTPS certificates that are signed by AWS, one of the most reputable certificate signers. 
• Browser data caching is disabled by cache control HTTP headers and/or meta tags within the HTML page to prevent inadvertent exposure of user credentials.  
• User sessions are tokenized, as are any links to the software that allow access to system.
• No encryption keys are used directly in the application, only on the infrastructure. Totem™ uses AWS Key Management System to secure keys.  Only Totem™ employees with a demonstrated need-to-know have access to the keys.
• Totem™ employs adaptive hashing with a high work factor and a randomly generated salt to securely store user passwords.
• Weak transport layer encryption ciphers and protocols have been disabled.

Error Handling and Logging

• The Totem™ application is “fuzz” tested and resultant errors analyzed to ensure no error messages reveal details about the application nor sensitive information. All logic exceptions are handled to return controlled output to the user. Where possible, default error messages generated by the application framework are suppressed or replaced with controlled output.
• Error and access logs do not store sensitive data, whether that data is customer supplied or system generated.
• Relevant system logs can be made available to the customer for ingestion by a third-party System Information and Event Management (SIEM) system.

Input and Output Handling

• All pages in the Totem™ application have encoding explicitly defined. These features reduce the likelihood of Cross-Site Scripting (XSS) risks for the application. Totem™ also employs a templating framework that prevents XSS, negating the need to implement specific output encoding schemes.
• All user input, as well as the source of the input, is validated to prevent the introduction of malicious code. Only data that meets the required criteria are accepted and all other inputs are blocked.  No user input field information can ever be passed into a SQL query as database calls are completely abstracted by the framework behind Totem™.
• All HTML pages apply the appropriate headers as suggested by the OWASP Secure Headers Project, where relevant and applicable. These headers help prevent XSS, Man-in-the-Middle (MITM), and Clickjacking attacks.
• Cross-Site Request Forgery (CSRF) attacks are prevented by embedding a unique random CSRF protection token in each HTML request form.
• Before accepting file uploads from users, Totem™ validates the file size and file type and performs an antimalware scan to ensure the files do not contain malicious code.

Session Management

• Each user session has an associated unique session token to prevent session hijacking or other MITM attacks. User session tokens are generated by secure random functions and are of a sufficient length to withstand analysis and prediction.  Session tokens are regenerated when the user authenticates or changes privilege levels, or whenever the session encryption status changes.
• User sessions automatically timeout and log the user out after 12 hours to reduce the risk of an attacker hijacking a session left up overnight. When the user logs out or is automatically logged out after 12 hours, the session and corresponding data on the server are destroyed. This ensures that the session cannot be accidentally revived.
• Once a user is logged into Totem™, the logout button is available on every page.
• Totem™ uses session cookies to track some user activity for support purposes only and facilitate navigation through the tool. The cookie domain and path scope are set to the most restrictive settings, and no wildcard domain scoped cookies are utilized.  Cookies are set with the HttpOnly and Secure flags to ensure the session ID is not accessible to client-side scripts and is only transmitted over HTTPS.  Cookies expire at the end of the session.

• Enable Multi-Factor Authentication. Multi-Factor Authentication (MFA) limits the chances a non-approved user can use stolen credentials to access an account. Users in multitenant organizations are required to enable MFA.  Users can enable MFA under “My Profile” settings. 
• Train users to identify Phishing and Insider Threats. All credentials are vulnerable to theft, and thefts from phishing and insider threats are one of the most prevalent threats facing all organizations. Totem.Tech will never ask for your login credentials and you should never share them with anyone else. 
• Totem.Tech strives to serve our customers promptly but we may not be able to immediately restore your data.  Backup as frequently as necessary.  Although Totem™ software and databases are backed up daily, your organization should conduct your own backups as an added layer of protection. 
• Don’t use Totem™ to store FCI/CUI. Totem™ is not approved to store, process, or transmit Federal Contract Information (FCI) or Controlled Unclassified Information (CUI).  Ensure your users understand how to identify FCI and CUI and how to properly handle it according to your contractual requirements.

Conclusion

By implementing the SANS SWAT and OWASP best practices, and by providing mechanisms users can add additional security layers, Totem.Tech is proud to say the Totem™ software securely protects your sensitive information.  We are happy to provide more detail and evidence of security feature implementation; contact us for more information.