October 9, 2018
Wouter ‐ Security Specialist
Security is important in every stage of your project. From the Discovery Phase to the Deployment Phase, and everything in between. This post focuses on the second project phase: Design.
At WORTH, we use the word Design to describe a range of activities that we do to create concepts / journeys / wireframes for our digital solutions. Based on activities in the Discovery phase, we know who the end user is, and what problem we will be solving. Often we also create a prototype that we test with the end user to validate our design decisions. We also focus on the architecture of the solution - how are we technically going to deliver the required functionality?
Knowing a bit more about what the solution may look like (functionally and technically), we can extend the risk analysis we’ve completed in the previous phase and do a more in-depth threat analysis.
What you missed in the previous Security blog
Organisations must change in order to ensure future growth and success. To do this, we have to maximise digital service potential to connect organisations with the outside world. While doing this, we must keep security in mind. Sometimes this makes you feel vulnerable, as though being connected to the outside world compromises security. However, this doesn't have to be the case.
What does it take to make your digital services accessible, without sacrificing security? In our previous post we identified that it takes structural attention on security throughout the software development life cycle.
Most projects at WORTH follow a four-step life cycle. First, we go into Discovery, followed by the design or, “Alpha” phase, then on to the Development phase, and finally the Deployment/Running phase.
When a project reaches the design phase a high level design is drafted which will be used to collect information needed for the initial threat model.
Often the security team starts this phase with a pause. We’ll wait till the required design prerequisites are in place. Once they are in place, we’ll start with a design intake.
When a conceptual technical design starts to take form, we’ll check to see if the design contains sufficient detail to create a Data Flow Diagram. Once this is the case, we start the threat modeling preparation by creating the data flow diagram including the threat boundaries.
The Data Flow Diagram (DFD) allows us to create a model of our application using the data collected. It contains the most important assets, data flows and trust boundaries. The DFD is can also be used to create a visualisation of potential threats. An example data flow diagram is shown below.
Next step is to engage in the threat modeling - and use the output to determine actions to implement security controls but also to improve the design.
Engage into Threat Modeling
As mentioned in our previous blog post, threat modelling aims to increase awareness of how the potential system operates, and in doing so, identify potential vulnerabilities.
We see threat modelling not only as an activity to find threats, but a broader exercise that has benefits on the front of people, risk and development. We achieve this by doing the following:
1. Getting the complete team on board
During one of our threat modelling exercises we focus on people. We need the entire team to be present, including Product Owner, business analysts and the development team. This is to create and verify common understanding of the working of the system and the data flow within.
2. Engage the team into an attacker mindset
Through a quick workshop we provide the entire team insight into how attackers think. This provides the basis to guide the team a during a brainstorm on what could go wrong from a security point of view. This results in a list of threats and potential controls.
3. Determining what is important
A threat model can reveal a lot of potential risks to the system. It can be hard to determine what should be in an MVP or not. Prioritizing the list of threats is essential for a product owner or business analyst to identify what is required and what is not.
4. Setting actionable security requirements
The threat modelling result provides the team actionable controls in the form of technical requirements or process requirements. This helps the team develop secure software from the start.
Design revisions and backlog creation
Often the threat modelling output will have impact on the system’s architecture and design. Maybe journeys will be adjusted because of risks involved (functional impact) or architectural decisions are made to be able to accommodate the required controls (technical impact). This prevents security of having to be ‘bolted on’ later - it's in the foundation of the system.
After the design stage, the product owner will have a good overview of the threats this system may be exposed to. We’ll have a list of controls to mitigate threats and the required actions to deliver these controls. These prioritised actions will be included into the product backlog. The development team will use the updated backlog and the adjusted design to start to build in design from sprint 0 and onwards.
What's coming up next
In the next post we will cover the Development stage. We use the output of the Design phase to deliver features in an Agile manner. Of course, with security built in.
PART II: SECURITY IN THE DESIGN PHASE (You're reading it!)
PART III: SECURITY IN THE DEVELOPMENT PHASE (Coming soon)
PART IV: SECURITY IN THE RUNNING PHASE (Coming soon)