Genuine security benefits can only be realised when delivery teams weave security into their everyday working practices. This is true even if your organisation has an overall security strategy in place. If security isn’t embedded from the start of the development process, it can become a blocker to implementation. Effectively embedding security in the development process is likely to require cultural change.
Keep in mind the idea that security is not a destination, but a journey. There is no such thing as perfect security. The aspiration is to have enough security to reduce your risks to a tolerable level.
However, because levels of risk tolerance are variable, you can’t rely on tick boxes to tell you when an acceptable level of risk has been reached. Instead, you need to be comfortable with uncertainty, continually assessing whether your defences are sufficient. This process should continue throughout your product’s life cycle, iterating as necessary.
Integrating security
Every team needs security expertise, but not everyone on the team needs to be a security expert. Security should be considered a team effort throughout the development process.
During design and delivery, continuously ask questions, discuss and identify potential security issues and work together to deliver solutions. Embed this process within your ‘normal’ approach to product delivery.
Security mistakes, and the associated security ‘debt’ which these entail, can be avoided if security is made part of everyday practice by your whole team. If this doesn’t happen and security is considered as a ‘bolt-on’ once development is complete, vulnerabilities may be missed and customer expectations may not be met. Both of these can lead to time-consuming and expensive re-working of code.
Unfortunately, the security process is too often about achieving standards compliance and ticking boxes rather than delivering practical and pragmatic security outcomes. Developing a culture of encouraging people to ask questions and discuss potential security issues can help to overcome this.
Practical steps
Some practical steps to influence cultural change include the following:
- regularly ask the question, “Is there a security implication here?“
- encourage developers to change their working practices to include security and support them with training
- make supportive security tools available
- encourage senior team members to lead by example
- share an understanding of how individuals directly effect security
- hold workshops where you think like an attacker and try to break your systems
- challenge your team’s security practices
Software development is a community activity. A healthy community should include security expertise which is shared, grown and rewarded. Security practitioners need to understand the value they can contribute by sharing their knowledge and expertise in a way that developers can use. Ideally a peer-to-peer relationship needs to be established with open and honest conversations involving mutual trust.
Actions
-
Define and articulate the requirements for security at the start of and during product delivery
Without this, security practices are unlikely to take hold and be given the priority they need. ‘Top-down’ support should be provided. -
Security is an essential skill for every member of the delivery team
Security needs to be considered throughout the development process, but it also has to be embedded into the culture and behaviours of all members of the delivery team. Embedding security is about more than writing it into a process – it needs to be a day-to-day practice if teams are to achieve faster delivery and deployment. -
Encourage people to raise security concerns, ask questions and challenge
People should be rewarded for caring about the security of their products. -
Spending time on security should not be pushed aside for features, or delivery deadlines
Doing security retrospectively incurs a ‘technical debt’. In other words, it’s inefficient and expensive to fix security problems ‘later’ and your systems will be at greater risk in the meantime. Grow security with your product. -
There should always be some security expertise involved in the design and development of a project
Although security specialists are desirable, even a little knowledge and appreciation of cyber security in a delivery team can go a long way. -
Ask for help
The technology landscape is huge and ever expanding. Learn to recognise when your security knowledge is being stretched – and don’t be afraid to ask for specialist support. This is particularly important for components that may be security critical. -
Facilitate security
Provide training, tools and development environments that support secure development to keep your security knowledge sharp. -
Promote a ‘no blame’ culture
Even the best of us can make mistakes which result in security issues. If a negative culture surrounds the spotting and fixing of security issues, there’s a risk that these problems will be ignored until it’s too late. -
Security should support product delivery, not prevent it
It is possible for a security culture to become so extreme that it hampers delivery. People complain about security and bypass it when it’s seen as getting in the way. Security experts should be approachable, reasonable and forthcoming with practical advice.
Self assessment
These examples are intended to help you assess your own practices, and those of your suppliers. The list below is not exhaustive and should not be used as a box ticking exercise.
| BAD | GOOD |
|---|---|
| Security specialists do not consider the legitimate needs of the business alongside security. | Leadership views spotting and fixing security issues as a positive. |
| Security requirements are often postponed to meet release deadlines, regardless of their impact. | Product engineering staff review security incidents and seek to learn from them. |
| Developers hide their mistakes. | Security implications are considered at every sprint planning meeting. |
| Developers do not take ownership of their code and seek to make security another person’s responsibility. | There’s top-down support for security within your organisation. |
| Product engineering staff blame each other for security issues. | A concrete system is in place to reward the finding and fixing of security issues. |
| Recurring security issues are ignored rather than examined and learned from. | Security specialists address security needs without impeding the business unduly. |
| — | Product engineering staff quickly admit when they have made a mistake and fix things. |
Related advice
Source: NCSC
