The purpose of this document is to clearly define our Information Technology Security Policies, ensure they are kept current with relevant legislation and ensure they are available to all relevant stakeholders.

If you notice a typo/error/ommission or area for improvement/clarification,
please notify us by opening an issue on GitHub.

Roles and Responsibilities

The following roles have been identified in our organization.

Management/Leadership team

The Management/Leadership team is ultimately responsible for the information security in the organization; it is not “outsourced” to anyone else.

Data Controller

Day-to-day responsibility for checking that process/procedures for information security are followed/met belongs to the The Data Controller (“DC”).

Application Developers

The Application Developer(s) (“Devs”) are responsible for implementing the code and systems which have the protection of people’s personal data at heart.

Additionally Devs should make reasonable efforts to keep their knowledge and skill current and keep track of security reports/advisories which are relevant to the code which has been included/used in the application.

Developer Security Checklist

1. Minimise the amount of sensitive Personally Identifiable Information (PII) stored by the application/database (e.g: if you don’t need Social Security number don’t ask for it!)
2. Where PII is required for the functionality of the App, Encrypt as much as possible/practical.
3. Never store PII in a session token (JWT) or localStorage (where it can be “stolen” by an “XSS” attack)
4. Always use strong passwords for all systems & services.
5. Always use multi-factor authentication for Gmail, GitHub & AWS to limit the risk of a malicious user gaining access to these mission-critical systems.

Under no circumstances should a developer merge her/his own change/feature/bugfix. Segregation of duties should exist wherever practical to ensure accountability.

Quality Assurance

The Quality Assurance (QA) person (or team) is responsible for checking/testing features of the application while they are being built and before they are released to the “live” environment. QA is the “gate keeper” between application developers and end-users.

Wherever possible/practical there should be a segregation of duties between the people who write the code and those who review it.

QA should not write code unless the team is small and the QA/developer roles are being alternated.

Technology

Hardware & Devices

Server/Infrastructure

All the components of our application are run on the Amazon Web Services (AWS) “Cloud” Computing Platform-as-a-Service (PaaS).

Restricted Access

Access to the “Production” AWS account is restricted to the Data Controller (DC). The DC grants access to the DevOps person as required to perform their tasks (e.g: updating the certificate on the server cluster) and once the task is complete access is revoked.

A full audit trail of actions performed in the AWS Console is recorded in case an involuntary (or malicious) negative action is performed.

For detail on AWS’s compliance with relevant security standards see: https://aws.amazon.com/compliance/soc-faqs/

Production data

Production data of client will never be used in staging or other test environment of the Ambassify platform.

Desktops, Laptops, Tablets & Mobile Devices

The following applies to company owned and “Bring Your Own Device” (BYOD) equipment.

We require that all devices:

• use full-drive encryption to protect any browser history data stored on the device.
• never leave the device unattended in a public space
• never connect to insecure Wifi networks
• screen lock is enabled when ever the user is away from the keyboard in the office (CDCS policy) to prevent unauthorized access to critical systems.
• at the end of the useful life of the device is must be reset to factory settings
• installation of spyware and virus protection

Theft or Loss

All members of staff and contractors are required to notify the Data Controller immediately in the event of loss or theft of any device.

In the event of loss or theft the passwords for all accounts should be reset as a precautionary measure and the incident should be reported to the policy (or other relevant authority).

Removable Media

Removable media is not permitted in the organisation. Where files need to be shared they are done through Google Drive which has good access controls, audit logs and encrypted transmission.

The only exception for using removable media is for making backups.

File Encryption

In the event any file has to be transfered over an insecure channel (email, local network, …), at least AES-256 encryption should be applied and the password transfered over a different communication channel as described in the data-protection policy. Any software supporting AES-256 encryption may be used to apply the encryption.

Access Control

Password/Passphrase Policy

We have the following password/passphrase policy:

• Length: 8 characters
• Complexity:
  • at least one Upper case character
  • at least one lower case character
  • at least one Number

Security and Privacy Awareness Training

all employees and contractors are required to watch the following security and privacy awareness training videos:

• Malware
• Phishing
• WiFi Safety
• OWASP Top 10 - Cross-Site-Scripting (XSS) Explained: (the most common vulnerability in web applications)
• Privacy and data protection

Policy Review

Annual (Planned Interval) Review

The policies and procedures contained within this document will be reviewed annually in the first week of May. A 2 hour block time has been scheduled on an annual basis and calendar invite has been sent:

Note: Any additional people who are relevant/interested/available will be invited closer to the time.

Ad-Hoc Review

The policies may be updated in response to a change in systems or service providers.

When a new technology or system is introduced into the company e.g. a new piece of hardware or 3^rd party service provider is being considered we will review the requirements of the policies contained herein and ensure compliance.

Where an amendment is required it will first be discussed in a Github “issue”

• if a formal meeting is required it will be scheduled - and the outcome of the discussion will be recorded/reflected in this policy document.