Doing Right Security - Compliance by Design or Security by Design?

I was talking to one of my peers, and we were discussing what can be the bare minimum security since it has always been a bugbear saying security drives cost up, make the project more complex, etc. The word "Compliance by Design" (CBD) came to my mind since it is what we need to do minimally. The higher order approach is going by "Security by Design" (SBD). Let's learn more in this article as I share some thoughts about making a choice for Making the Right Security.

What are CBD and SBD?

CBD (surprisingly) was already in use and is not a new term. It describes the process of developing a software system to implement a business process in such a way that its ability to meet specific compliance requirements is ascertained. Formal methods are typically involved to automate compliance rule verification. This is meeting the "base minimum" security requirements and making sure it is good enough to survive through the audit checks - doing what is necessary and not more.

SBD, on the other hand, is a familiar term to security professionals. It adopts the approach in embedding security processes such as risk assessment, (see my article titled Triage & Manage Vulnerability Gracefully) security design, security verification, and validation into every part of the IT management process. This is a higher order and critical to make sure security requirements are robust and comprehensive - doing more than just the necessary.

If I will summarizing both of them, CBD brings the business in a ready state to comply with policy and regulatory requirements. SBD goes a step further, to keep business in a constant watch over explicit risk scenarios and constantly reduce the risk level with the necessary security measures (in people, process and technology - PPT) implemented adequately. 

Below is a table summary on key differences between CBD and SBD in the domain of "PPT". 

Implementation guidance for CBD and SBD

CBD does not necessarily mean the business is secure with using those security products. SBD demonstrates an assurance that the security controls are brought in to keep the risk level to a lower level. That said, having both CBD and SBD are necessary for having to review the measures and controls in place on a regular basis and helps to maintain a high-security posture.

Below is a figure to illustrate some key differences from on control implementation perspectives. There are some technical terms introduced, though they are not going to be discussed here - they can be easily googled :)

I'd like to draw your attention to the two terms - "Zero trust" and "Microsegments". These are the elements to bring the security posture to a higher level. In gist, they aim to put a robust front against advanced attackers and sophisticated threats and activate the incident response activities timely, as explained in my article titled What's in an Incident Response Plan?

We need to adopt a "defense in depth" strategy through PPT in order to reinforce our layers of protection and together with the adoption of CBD and SBD, we would greatly reduce our attack surface and stay watch also on internal and external threats as explained in my article Know the Threat better - STRIKE out with a Threat Risk TABLET!

Food for thought

The article (or illustration) is not intended to be a cookie-cutter or be a prescriptive approach to having developing security measures in your project or system. What I hope that you can get from this sharing is that you will be able to use this knowledge to build your stakeholders' confidence in the security projects - there are the "good to have" and "need to have". 

It will help in your budgeting exercise in terms of identifying the priority requirements and plan out a subsequent phase of enhancement as part of the organization's security action plan. Such a deliberate exercise with your IT team and CISO will strengthen your rapport in an objective manner - bringing out the benefits of CBD and SBD.

Hope you found this article to be a useful read!