Secure by Design has been launched by the UK Government and is already creating a lot of noise by challenging existing security norms, especially in the Ministry of Defence (MOD) and more recently, the Central Digital and Data Office (CDDO).
Previously, we have explored what Secure by Design is and why it’s important to go beyond compliance. This time, we offer insight into how to start your Secure by Design journey.
This article is focussed on project or product teams implementing Secure by Design. It assumes that the necessary organisational structure to enable good security outcomes is in place, albeit it is recognised this is often not the case.
Beginning your Secure by Design journey
Understanding a different approach to security can be daunting. It can also be frustrating, especially if you are used to a compliance centric approach based on writing specific documentation and using specific control sets from specific standards.
A good place to start is recognising that Secure by Design is different than accreditation and compliance. Whilst Secure by Design uses well know security analysis techniques, the overarching focus is to deliver a system that enables an organisations mission or business objectives to be delivered securely. Whilst it may seem obvious that this is also the purpose of security, the reality is that often the focus of security compliance is to gain compliance.
Secure by Design requires security to be considered at the very outset of any technology project. Not just to examine risk and potential negative consequences but also to identify opportunities. Often security is cited as a reason why something cannot be done, whereas if considered early and designed correctly, there is potential for good security to enable the delivery of a superior product that delivers better outcomes to organisations and their end users.
Due to the unique nature of projects and capabilities, and thus varying levels of complexity there are many ways to implement Secure by Design, there is no single approach. However, there are generic steps that can be followed and then tailored accordingly to specific industries and context. As such, here are a few things to consider when starting with Secure by Design.
Consider the mission
One of the first things to do is to think about your mission; what you do, why you do it, how you do it and what value you bring. Understanding the fundamentals is key as it allows the system that is being developed to be placed within the context of the mission.
This may sound a bit odd if, for example, it is an internal HR system or a system that seemingly has no relationship to your mission. However, regardless of application, understanding its importance helps to focus on the potential impact on the organisation if something goes wrong, and how much security is needed. Take the HR system example- while on the surface it may seem to have only a vague link with organisational missions, ultimately a security breach may result in employee’s personal data being exposed, leading to reputational damage and negative press, and undermine customer confidence in other areas, all of which could impact the ability of achieving the organisations overarching mission.
The more complex the mission, the more abstract the system may seem from it. Recognising how the system helps to achieve the overarching mission is critical, especially in a Defence or Government context, as often it is the loss of a seemingly inconsequential part of the ‘system’ that can have a devastating effect.
Identify context and constraints
Every system has constraints, stemming from its use-case and consisting of the regulations and legislation it needs to meet, the legacy systems and interconnections it needs to interface with, existing infrastructure it needs to use or rely on, user needs, user ability, etc.
The earlier these constraints are understood the better we can plan how to manage them and any related risks and opportunities we identify. This provides us with the ability to account for these constraints early in our design, maximising the likelihood of developing the most optimal solution.
We can also understand internal constraints such as delivery schedules, which will drive the development timescales and by default the security work. Awareness of the constraints is critical if security is to have a positive influence and support development teams in making good decisions. As is often the case, security teams are only involved once a system is designed, or to meet a ‘compliance’ timescale, missing the opportunity to influence system design and direction.
The other benefit of this approach is it allows us to plan our programme more efficiently. It is likely there will be multiple internal processes to adhere to and external regulation to achieve, many of which consume the same or similar evidence, documentation, and information. By understanding the demands early, we can begin to plan this evidence to meet all regulatory requirements without starting from scratch every time. Our planning can consider both delivery and through-life support, as we want to design for ease of use, not only for the end user, but also for supportability and maintainability, as this maximises our ability to maintain the required security posture.
Understand the risks
Risk has been central to every security standard ever produced and it is no different when applying Secure by Design. Risk management helps us to understand what events can lead to mission failure and business loss and gives us the information to enable decisions to be taken. The earlier risks are identified the earlier we can consider strategies to do something about them within our system design.
There are many techniques and standards that can be applied to identifying risk. However, care needs to be taken to not solely rely upon security centric risk analysis that can auto generate a large number of risks, since these can become unwieldy, unmanageable and drive separation between security and the rest of the organisation. What is needed is to develop mission focussed risks that uses formal risk methodologies to inform the risk analysis.
One technique is to develop a risk appetite statement as advocated by the National Cyber Security Centre (NCSC). This helps to focus the risk analysis, supports communication with stakeholders inside and outside of the organisation and enables development teams to make informed decisions.
This approach also helps to identify the system or data losses that could lead to mission failure. This becomes increasingly useful when conducting risk analysis as it helps to create and maintain a ‘golden thread’ between the mission objectives and the implementation of technical solutions within the system. This helps stakeholders understand why security investments are needed, and product teams link technical decisions to potential loss event. The NCSC Risk Appetite guidance, based on elements of System Theoretic Process Analysis (STPA), forces consideration of the ways that loss, and the conditions that could lead to loss, could occur, using common threat analyse techniques. From here we can iteratively analyse the system design as it evolves, using risk analysis to provide information that helps with security design decisions.
Design for security
Often in security we talk about applying controls. But in Secure by Design, we don’t just want to apply controls from a control set; this could be unnecessary and expensive and could potentially ignore the critical aspects of the system that need protecting.
The other challenge with simply applying controls from a list is that it often creates conflict with other parts of the system, resulting in hard trade-offs between security and other system functions. This leads to the perception that security is a blocker or is a non-functional requirement that reduces or restricts system features and usability.
A Secure by Design approach is to analyse and understand the processes that successfully deliver the mission and then understand the functions that deliver these mission critical processes, whist using design principles from standards or respected bodies to help guide design choices. This approach helps us to secure the functions that deliver the process, since this is the area of maximum integration and provides multi-layered defence in depth security together with lower through-life costs. As we are proactively addressing security as part of the system design, rather than adding it once the system is designed it also allows us to develop a much more elegant solution where security is tightly integrated throughout all aspects of the systems lifecycle.
What does good look like?
Throughout the development and build stages of a system you will want to provide confidence to stakeholder’s that security risk has been considered and there are controls in place to manage that risk. This should then continue through-life so there is confidence that the security posture of the system is being maintained so that the mission can be successfully delivered. Ultimately, providing evidence of compliance and assurance is an indication of good business and engineering processes and design.
There are many ways of doing this and will largely be driven by the needs of the organisation and associated regulations and standards that need to be achieved. However, there are two things to consider when providing assurance. The first, is to plan for assurance and understand the needs of the stakeholders, so that information presented to them is relevant and actionable i.e., it enables them to make decisions.
The second is provide ‘assurance in depth’ through an assurance case; a structured body of evidence that argues why a system is secure (as it needs to be). The assurance case will identify how the system has been designed, how assurance has been gained through the supply chain, how decisions have been taken, how testing has been conducted, and how the security posture is maintained through-life, through meaningful metrics and measurements.
To help to construct the assurance in depth approach, the NCSC is building Principles Based Assurance (PBA) to allow businesses to gain the confidence that their technology is increasing their resilience and security. This will help construct the layers of assurance needed for the product and its supporting processes.
As with everything there are limitations which stakeholders need to consider, most notably a positive bias to such assurance cases and over-hyped marketing claims, remember – there is no such thing as absolute security. Additionally, assurance cases are rarely ever established by an independent party which could lead to bias even if unintentional. Regardless, an assurance case is a useful concept that enables stakeholders to understand, consider and take decisions on operational, security and business risk.
Summary
Secure by Design doesn’t need to be a minefield, and we can continue to use the excellent standards and guidance we have traditionally used. We don’t need a scorched earth policy on recognised good practice! What is needed is a change of focus, and largely a change of mindset. Recognising that security doesn’t live in a vacuum and needs to be involved from the outset and deeply integrated in people’s consciousness if a product or system is to be well designed and secure. Hopefully the guidance here has been helpful to get started and start conversations within the team about “how secure do we need to be” and “what does unacceptable loss look like for us?”. This should help you consider security needs in the context of the mission and the system being designed and then analysing this as the design evolves or changes.
Ultimately, much of this stems back to a positive security culture and the need to want to make something secure, because if it isn’t, it is likely to have a much bigger impact than simply holding an out of date certificate in filing cabinet.
How we can help
As a leading cyber security consultancy that has helped to develop Secure by Design, Logiq can assist you on your journey to continual risk management and allow you to implement security from top to bottom. To speak to a member of the team, contact us via email contact@logiqconsulting.co.uk or call 0117 457 7463.