The way your product development process is set up has a big, but sometimes poorly visible, impact on the security of your product. It sets the context for all decision making and both influences and reflects the security culture within your development team. A well-designed development process will enable people to make better decisions while encouraging the right behaviours for your organisation.
Speeding-up feedback loops
Collaboration within your development process is one aspect that can greatly influence the quality of your product or service. How does your development process open up communication channels between everyone working on the product? Another element might be how your organisation deals with learning and feedback loops. If you only find bugs in your code six months after writing it, what are the developer’s chances of remembering the code? Is the developer still on your team? If you can speed-up these feedback loops you’ll have a much better chance of understanding what went wrong the first time round, and how to avoid it happening again.
The intent behind agile techniques like frequent demos, continuous integration, or pair programming, is reducing the length of time of feedback loops. Some techniques increase the rate of human feedback by encouraging communication between the people working on (or using) the product. Other techniques rely on testing, which can be automated. Even if the well-known agile approaches (like Scrum or Kanban) aren’t suitable for your type of development, you can still use the principles and philosophies behind them to help your team learn from their experiences.
This is not the time for Chinese Whispers
All methods of getting feedback about your product are potential security learning opportunities. Reducing the number of systems or people that feedback travels through – before it gets to the person that needs it – will improve the usefulness and timeliness of this information. This is especially true for your approach to user research, which should inform the security aspects of your product. No system can be deemed secure enough without considering the people using it. Everyone in a development team should at some point get involved with the user research, to find out:
- what exactly users need to achieve
- how systems are being used in reality and why
Speaking to people or observing people directly is important to make sure you get the information that you really need, and to avoid others’ interpretations and biases. This also goes for communication with all the other people involved in developing your products or services that you may or may not consider to be part of your team.
Example #1. A penetration test of your product will improve security in the long term if your developers can talk directly to the tester. They could even sit with them during the test to learn about their mindset, and gain a better understanding of how they can detect such issues for themselves sooner in the future. Bonus points if people work together to fix the issues quickly afterwards.
Feedback loops can be formal or informal. What’s important is that feedback means something to the person receiving it, and is specific enough for them to act on it. Team members also need to be empowered to make any adjustments where necessary. In essence, allow people to take responsibility for aspects of quality like security, but don’t leave them on their own if they need help.
Example #2. Good static analysis tools can be an effective way for developers to learn about coding flaws in a way that’s relevant and specific to them. If you put these checks in before code gets committed, developers can deal with any issues while they still have the code in their heads and without necessarily flagging them up to the rest of their team. Having a team culture where people are comfortable asking security questions is important for learning, but so is allowing developers to try tackling issues themselves first.
Taking a step back
The feedback loops we’ve been discussing so far are predominantly examples of single-loop learning. That’s what most people think of when they think about problem-solving; identifying and fixing issues based on their own mental model of how the world works. Double-loop learning (pdf) questions that mental model, and helps you make sure that the mental model you think you use is the one you actually use. It involves reconsidering and adapting your goals or decision making rules in light of the outcomes you’ve had so far.
Getting feedback from a security test, and fixing the vulnerabilities, is an example of single-loop learning. Re-examining how you test, or who does it (or your development, or anything else) based on the results of those tests, is an example of double-loop learning.
Given that double-loop learning involves questioning your underlying assumptions and beliefs (and even examining how you may be contributing to the problems you are facing), it doesn’t usually come naturally. It is human nature to get defensive at this point, but defensive reasoning is probably the biggest blocker to learning. This is why it’s so important to have a way to reflect on how you do things in your team. Whether that’s agile retrospectives or after-action reviews (as developed by the US Army), just make sure you get some practical actions out of it, so you can actually improve things.
The good news is that you don’t have to change everything at once. Small, incremental changes will help you test out your ideas quicker, get that feedback, and probably encounter less resistance.
This is about more than just security….
If you can get feedback loops working quickly and smoothly, not only will you improve security, you’ll also improve your product and the environment you work in. This is about thinking about security in terms of general quality, rather than whether or not a specific type of incident has occurred yet. I think we all theoretically know this, but it’s still tempting to say ‘Well, we haven’t seen any incidents yet, so we must be doing something right’. Instead, if you’ve ever thought to yourself ‘Wow! I could have done with knowing that a lot earlier’, then that’s a sign you need to tighten-up your feedback loops to make sure your team are all working together in an effective way.
In such a fast-changing world, the ability to learn lessons quickly is far more important than any particular lesson learnt.
Nicola B.
Sociotechnical Security Researcher
Source: National Cyber Security Centre
