Security and AI Safeguards

Introduction to Totem™ Security and AI Safeguards

At Totem Tech, we take the security of our application 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 application 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™ Cybersecurity Compliance Management (CCM) application users with the knowledge and tools they need to keep their data safe.

We use our Privacy Policy as a guiding principle while incorporating security safeguards into the Totem™ CCM application (what we will simply refer to as “Totem™” going forward).  The bottom line: we only collect the minimum amount of your and your organization’s data that is absolutely necessary to ensure Totem™ functions properly and securely.  Your data is never shared with other Totem™ customers or any 3rd parties.  

Totem Tech employees understand the need for security, as collectively we 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 reduce the risk of insider threat.  Totem Tech staff receive continual security training to help them follow best practices and to be able to identify threats to systems, software, and organizations.  We also contribute regularly to Defense Industrial Base (DIB) community events, such as webinars, conferences, and workshop. 

To secure Totem™ 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.  To secure the AI integration we follow the applicable Amazon Web Services (AWS) “Security, Guardrails, and Observability in Amazon Bedrock” guidelines.

Key Totem™ security and AI safeguards include:

Artificial Intelligence (AI)

• Totem™ 6.0+ includes an integrated Large Language Model (LLM) chatbot we refer to as “Aurora”.
• Aurora is integrated individually into each Totem™ instance.  There is no central “AI server” processing data.  Data is not shared between instances.
• Non-administrator users may only engage Aurora in the scope of their organization.  
• Only instance Administrators may engage Aurora in the scope of the instance, but even then Aurora can only process a single organization’s information in any given query session.
• Training:
  • Aurora is trained only for short durations during Totem™ release development; the training window is closed once the Totem™ version is released.
  • Aurora is only trained on trusted Totem™ content, as well as on pertinent CMMC-related source documents (e.g. CMMC Scoping Guides, NIST 800-171 revisions, NARA CUI Categories).
  • Aurora is never trained on user data. 
• We’ve enabled AWS Bedrock “Guardrails” to ensure Aurora does not “learn” from customer data.  
• We restrict prompt evaluation and response to the user’s scope within the Totem™ instance, and only for specific allowed “tasks”, such as find-and-replace, listing non-compliant controls, summarizing organizational status, etc.
• We’ve enabled Zero Data Retention, ensuring no data processed by Aurora can be retained or transmitted back to the LLM vendor.  The lone exception to this policy is for inputs and outputs that match “abuse classifiers“.  For example, AWS Bedrock will detect apparent child sexual abuse material (“CSAM”), block any requests, and store and review the flagged content for up to 30 days.  Bottom line: Aurora is a simple tool to help manage cybersecurity compliance; don’t be a knucklehead.  

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 identity provision (IdP) and 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.
• Multifactor Authentication (MFA) is required by default for all users.  Totem™ supports, and we recommend, establishing hardware-based Authentication Passkeys.
• Instance Administrators must authenticate again to gain access to any privileged user consoles.   
• 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.

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™ applications 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™ 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 applications. Operating systems and application modules are patched on a weekly basis.
• All Totem™’s supporting components 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 Totem™ access 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 applications that allow access to system.
• No encryption keys are used directly in the application, only on the infrastructure. Totem™ uses an infrastructure-level 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 Totem™ pages 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.
• Logged in users can access the logout button on every Totem™ 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.

User Responsibilities

• Encourage your users to enable the strongest Multi-Factor Authentication they can. Multi-Factor Authentication (MFA) limits the chances a non-approved user can use stolen credentials to access an account.  All users are required to enable MFA.  Encourage them to use the Passkey option if you can, otherwise use a secure phone- or password-manager-based MFA OTP generator. 
• Train your 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 the Totem™ application 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, OWASP, and AWS Bedrock best practices, and by providing mechanisms users can add additional security layers, Totem Tech is proud to say Totem™ securely protects your sensitive information.  We are happy to provide more detail and evidence of security feature implementation; contact us for more information.