Making the RIGHT Security:  Adopt a RISK based approach.

Many a time, as a security professional, you are challenged with questions that put you on the spot - asking why the security controls introduced into the project or design jack up the overall budget required significantly. Do you encounter this and a hard time explaining and getting buy-in from the user? It is an ugly side that we have to deal with.

Security cannot be an afterthought.

How do we go about solving this or at least alleviate the situation? We just have to show proof to justify these controls are critical to keeping the system deliverable secure and safe. However, we need to wear their shoes and ask ourselves if the exorbitant price tag is worthwhile and importantly, will these become a white elephant.  Such grumble is unnecessary and groundless as long as you are well justified that due diligence is taken to tailor to their project needs.

Education is needed. Incident can happen if the controls are not well handled and there is no response plan in place. For example, misconfiguration of the controls (e.g. enable guest account etc), acting negligently (e.g. forget to remove test accounts), and abuse authorisation rights (e.g. giving more privileges to certain user accounts). It boils down to having the RIGHT security in place.    

A conventional approach to security

Security is not about putting in best of the breed security control and product. In fact, such products are a waste as most of the time they are introduced as opportunistic fixes to quickly reduce damage during an ongoing incident. Any quick fix will go regardless of the cost. The gut feel implementation of a security solution will not work out and is totally wrong. 

We have to take a proactive assessment of our security posture and focus on mitigating risk on a constant basis. Hopefully, this article (a two-part series) can enlighten and address concerns collectively. Adopt a RISK based approach. Go for Quick security wins.

This is not a new thing. Risk assessment is already advocated by a standard body like NIST. For example, NIST SP 800-30 provides guidance for conducting risk assessments of federal information systems and organizations.

Go for a simplified RISK approach that you find comfortable and still adequate to achieve the same effect. Do this systematically. The approach continues to be part of the early threat risk assessment in the whole system development lifecycle. You do not need to be a scientist or security guru to do this. Non-security folks like the project team can pick it up to conduct such self-assessment. Security folks can still be consulted for help to chip in. You can lead in the self-assessment. 

Ultimately, do the first thing right. It need not be complex. Make the assessment exercise simpler to adapt. 

Adopt the RISK approach

Review - Understand clearly what is the target for this assessment. It can be an IT system, project, or process of concern. Describe its relevance to the potential threat that can cause harm to it. The threats could be IT (e.g. protection of data) or project (e.g. schedule, budget etc) related. Think about also who are the possible threat actors like hackers and third-party entities like vendors. Wear a blackhat and expand more threat scenarios where possible. More is not necessarily merrier. Do not go out of scope during the brainstorming of threat cases and select only relevant ones.

Identify - With a clear appreciation of the selected potential threat use cases, next is to assess and tag a level of the threat likelihood - Measure the expected frequency of a risk occurring. Same applies to impact level - Measure the expected level of effect of a risk occurring. With both likelihood (L) and Impact (I) levels identified, a risk score level can be calculated. It is a simple multiplication of both levels (e.g. L * I). Alternatively, refer to map below for a quick mapping of the risk level.  

Scope - With the risk level identified, it is time now to make sure the appropriate mitigation measures are taken, i.e, bring the initial risk level to a lower level where possible. To ease in scoping in the necessary security measures, you can actually categorise them into preventive, detective and response (contingency) based controls. These are normally aligning to your organisation security defence strategy (your security folks will know better). The final risk level derived can then seek acceptance from the risk control owner (typically your senior management). Sometimes, we also allude this as residual risk acceptance by these stakeholders.

Knowledge -  Going through the above processes without any recording and proper documentation will end up with all the effort down the drain. The loss of such risk knowledge is real in the long run. So maintain a knowledge base. It need not be so complex, have a risk register (below). It is simply a tabulated record. Go simple first and when more experience and more buy-ins are obtained, you can then start looking into technology such as a database or get some GRC (Governance, Risk, Compliance) type of solution, if really need to. 

Regardless, this assessment exercise should never be a "one-off" or "do and forget" attempt. The stakeholders (owners) need to be regularly apprised of the changes to the risk level. Henceforth, in due diligence, maintain the currency of the risk register. Check the controls' adequacy regularly and in the event, the system or the project undergoes any technology refresh or major upgrade changes. 

Reflection of RISK exercise

Diligence and Discipline are crucial.  The exercise needs to involve more than the project team. End-user and provider delivering the service need to be consulted. They are potential threat actors.  A comprehensive exercise needs a more deliberate effort to constantly keep this RISK process running. Start small and go simple. Build up momentum as you engage stakeholders actively. Take it as one of a mean to make the security action plan "smarter".  

Organisation policy enforcement is crucial. Institute exercise as a standard regime mandate for all development projects. Without which, this regime will fade and be forgotten. Continue to preach RISK approach as a necessary phase for the project team to aid in justifying the security budget required. Use the register as evidence to show prudence in selecting the adequate controls. 

No longer risk assessment is based on a prediction or a "cherry picking" exercise as perceived by the naysayer. Till now, with diligence and constant oversight efforts, earlier grumbles will slowly disappear. Greater awareness and appreciation of RISK approach will put you on vantage ground, and importantly in the direction of getting the RIGHT security. 

Stay tuned for the next series on how to have quick security wins.