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.
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.
Day-to-day responsibility for checking that process/procedures for information
security are followed/met belongs to the The Data Controller
("DC").
DC is the person in the organization who is registered/named with the Information Commissioner's Office (UK) and responsible for ensuring that Data protection principles are followed.
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.
- 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!)
- Where PII is required for the functionality of the App, Encrypt as much as possible/practical.
- Never store PII in a session token (JWT) or
localStorage
(where it can be "stolen" by an "XSS" attack) - Always use strong passwords for all systems & services.
- 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.
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.
All the components of our application are run on the Amazon Web Services (AWS) "Cloud" Computing Platform-as-a-Service (PaaS).
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/
We have 3 desktop computers.
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 to prevent unauthorized access to critical systems.
- at the end of the useful life of the device is must be reset to factory settings
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 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.
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
- at least one special character e.g. punctuation or symbols (!@?)
## Security Awareness Training
all employees and contractors are required to watch the following security awareness training videos:
- Malware: https://youtu.be/cKlRc1_f5NY
- Phishing: https://youtu.be/WpaLmeHTp3I
- WiFi Safety: https://youtu.be/T5HCy3udooo
- OWASP Top 10 - Cross-Site-Scripting (XSS) Explained: https://youtu.be/ksM-xXeDUNs (the most common vulnerability in web applications)
### 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 for the morning of May the 4th 2017 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 3rd 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.