Security Standards

[legendary-jld]

This document is to provide a baseline and reference for security practices. For both PanaMia and the users of our services, we should be making an effort to protect their data.

Internal Security

• Protection of Passwords and Access Keys
• Limited Access

Protection of Passwords and Access Keys: Any accounts and/or their related credentials should be recorded and stored in safe locations. These locations should not be available on public documents or websites, and preferably stored with encryption (using Password Managers). Any account that has 2FA functionality should enable this feature, using either Text, Email or an Authenticator app. This is especially important for services with access to finances (Stripe, Auxilia) or user data (MongoDB, Hubspot).

Limited Access: Where possible, roles should be assigned to users to limit their access to only the necessary permissions. This helps prevent breaches as a compromised account that has already been limited by their role will have less access and potentially cause less damage. As such, Admin accounts should aim to be the most highly protected accounts and limited to as few people as possible.

User Security

• PII data
• Passwords

PII data: Personally Identifiable Information (PII) outside of information that users have explicitly given consent to share, should be kept under lock and key. Currently, most of our data is intended to be publicly available, but user contact information and any payment information should be stored in protected locations.

Passwords: Account Passwords that we store for users should always be 1-way hashed up to the current standard available. We can provide functionality to reset user passwords and help them gain access, but at no time should we be able to see or access Account Passwords that users have created. Providing 2FA authentication would also be a great feature to add for our users.

Spam Security

• Verifying Submissions
• Verifying Users
• Private Emailing

Verifying Submissions: Where applicable, public facing forms should use Captchas or a verification technique to prevent bots or crawlers from spamming forms with false/malicious submissions.

Verifying Users: At a minimum, we should confirm a user's email address is valid. This will also help users track down initial emails from us and remove them from Spam and flag us as valid senders.

Private Emailing: Public facing features that allows users to contact us or other users through emails should prevent direct emailing or provide the email indirectly. This prevents email addresses from being displayed on the website and prevents this data from being crawled by bots/spammers.