Introduction
This policy is part of the medDigital ISMS and must be fully complied with.
This policy outlines controls that need to be considered to ensure security is built into projects
at the point of conception and that systems are architected, developed and supported in a consistent
manner.
Security Requirements
Security requirements need to be captured at the start of any project to ensure that they are effective
and should not be considered in isolation of the functional requirements. Project leads must involve
the IG Lead, Paul Gardner, at the proposal phase of all projects to ensure
impact on confidentiality, data protection and security can be considered, risk assessed and controlled.
Security not only emphasises defence against unauthorised access but should also involve:
- Methods to backup and secure data against loss or damage and where possible, use of the existing backup systems
- Housekeeping processes that should be automated
- Disaster recovery arrangements and where possible, use of the existing disaster recovery mechanisms
- High availability
- Legal and regulatory compliance
- Security of communications
- Security awareness and training
- Auditing & Reporting
Each system should be considered for its effects on the availability, integrity and confidentiality
with other systems.
A risk assessment must be carried out during the initial phases of development with risk controls applied
where appropriate.
Security in development and support
If a new system requires changes to existing systems, these changes must be controlled using the
Change Management System as outlined in the Operations Security policy.
Development, Test and Production environments must be physically separate with appropriate levels of access control for each.
Please see the Operations Security policy for further
information.
Development standards must be in accordance with industry best-practice. Web or API applications must also give consideration
to the OWASP Developer Guide and the current OWASP Top 10.
Development environments are restricted to the official development virtual machine provided which is only made
available to developers.
Development environments must not be reachable from the Internet.
All software must be subjected to vulnerability testing before production release.
All servers should be subjected to port scanning on a weekly basis.
All software and associated configuration must be stored in a git repository and use the gitflow branching model.
Software development lifecycle
A system is broken down into a number of chunks by a software architect. We refer to these chunks as stories. These stories are described
and entered into the icebox with a sprint tag.
Every week, the development team reviews these stories and prioritises them based on business need. Stories that will be worked on in
the current sprint are moved from the icebox into the current sprint.
When the development team believe a story is complete, they mark it ‘delivered’ and release it to a staging environment for review by the wider team and, potentially, external stakeholders.
Once the wider team is satisfied, the code is then promoted to the production environments.
The release of software between development, integration, staging and production is controlled via an automatic process based on git branch tagging.
Test Data
The use of production data in a non-production system is prohibited.