Security in our Process
Secure By Design
Policy
Our aim within OPG is to make our products as secure as possible while maintaining usability for end users.
All central government departments and arm’s length bodies (ALBs) must incorporate effective security practices and be moving towards meeting the Secure by Design policy when delivering and building digital services and technical infrastructure.
Note that where products existed before this policy, we will attempt to bring them in line but there may be historical gaps (for example where it mandates security is part of an original business case).
As outlined in the MOJ Security Guidance, this policy requires that cybersecurity considerations are incorporated at every stage of the project lifecycle. From the development of business cases through to service design, development, deployment, and ongoing maintenance, security must be embedded as a core element. This ensures that potential vulnerabilities are proactively addressed, aligning with best practices to protect data, systems and services from evolving threats throughout their entire lifecycle.
This proactive approach not only aligns with broader government cybersecurity mandates but also enhances trust and safety for users interacting with digital services. The requirements described in this policy will help government organisations achieve the required security outcomes in the NCSC Cyber Assessment Framework (CAF).
Secure by Design is a continuous assurance discussions that should complement the ongoing security work within a team. Adherence to the policy is checked by using the Secure By Design Assessment Tracker. Whilst technical team members (usually a technical architect) will lead with completing these assessments, delivery managers should integrate completion of the tracker into regular activities involving the relevant team members.
Teams should also review the GDS service standard, consult the MOJ Security Guidance for help with specific policy issues at an MOJ level and follow the National Cyber Security Centre for updates at a government level.
How we will work
General principles
- We will automate as much as we can
- We will build security into the process, rather than tag it on via external checks
- We will actively fix, and where issues occur improve the process to prevent them happening again
Development culture
As part of our local development culture all our products should aim to have the following as a minimum in their process, build pipelines and GitHub setup:
- Security to be considered as part of ticket prep and refinement, with reference to OWASP Top 10.
- Write automated tests to verify code and infrastructure security
- Do Threat Modelling of your product every 6 months or after a major change.
- Have an ITHC or Pen Test once a year or after a major change. Changes that could require a re-test include:
- A major change in the type of data held, volume of data or privacy of that data
- Authentication / permission system
- Infrastructure technology
- Integration boundaries with internal or external services
- Significant dependency
- Enable dependabot security updates on all repositories
- Enable container vulnerability scanning (either ECS container scan or a tool like Trivy)
- Require pull requests to be reviewed before changes are merged to the main branch
- Enable Pre-commit hooks to prevent secrets being added to version control
- Static analysis of code run in IDEs, pre-commit and pipelines (using the appropriate tooling for the languages used).
- Maintain Architectural Decision Records of security related decisions
- Follow the github actions security processes outlined in this guide.
You may also want to look at:
- Adding a pull request template with expectations for checks specific to your product
Responsibilities
As a Developer or WebOps Engineer you should
- Be aware of common vulnerabilities and how to code to prevent them
- Pair with colleagues to be a 2nd pair of eyes for potential security issues
- Raise security concerns if you identify a risk (chance that something might happen) or issue (something has happened).
- Use the incident process for urgent issues
- Actively build an understanding of the security posture of your product over time
- Actively monitor your product for security issues
- Regularly rotate secrets used within your service
As a Technical Architect you should
- Work with delivery managers to complete secure by design and CAF assessments as required
- Organise regular threat modelling for your teams
- Ensure security tickets are prioritised in backlogs
- Coordinate incidents if they occur
- Liase with stakeholders and security around security issues
- Highlight potential risks on product and OPG Digital Risk registers
Asking for help/Raising issues to security
Sometimes you need to make a call between a security fix and a business or user requirement. Or you may not know the best way to handle or fix a security issue in your code base.
Where you are unsure of how to proceed, you can get advice or raise a concern with the Security team.
As outlined on the intranet, all cybersecurity incidents should be reported by contacting the Service Desk on 0800 917 5148
For advice or guidance you can either:
- Post a message in their slack channel for #security
- Email their inbox at security@justice.gov.uk
What to include
If possible, supply them with as much context in regard to the issue.
- CVE (if available)
- OS/Environment
- Description of issue
- Any business context
- Any recorded conversations around the security issue
- What data could be comprimised if attacked
If a security issue cannot be fixed, then Security will add it to their risk register with the details provided. This is to ensure MoJ have visibility of all threats and weaknesses across their estate.