What is a good Security Action Plan

A security plan needs to have a clear objective on what it is expected to achieve and be used for. Action parties identified to be accountable should follow up on operationalising the plan. However, most of the time, people rush into writing it. The plan gets incoherent objectives and becomes fragmented, leading to more queries than clarity. That's an example of a poorly written plan. 

Security Plan

A good plan should consider taking on a "SMARTER" means to have it concise and relevant to the audience. Explicit,

actionable, identifying the right custodian and clear responsibilities are the traits of a good plan. 

So start off by visualising the big picture in the security plan that will be covered. Draw it out. An example below depicts an overall high-level coverage in a comprehensive security plan. A good appreciation on the scope and each area needs domain expertise. Augmented with the subject matter expert insight make the plan more realistic - not just a high level pitched document. 

Do not be ambitious trying to cover everything in one go. With context to the organisation, prioritise and ranking key domains to deliver first. Divide and conquer. Identify the leads in charge of each domain and run through their deliverability expectations. You have to lead the way in the reconciliation of the final plan. My suggestion is a constant reminder and to sync up on SMARTER strategies in their development journey. One incident plan template here.

"SMARTER" Approach

Be Specific - Identify the problem statement in the domain assigned and outline the intent of a plan. 

• For example, under Operation Management, you need an incident management plan to take care of security incident (e.g. unauthorised access by a contractor) in the organisation. Outline the task force to lead and see through the resolution of the issue and validate that controls are in place to prevent future recurrences. 

Be Measurable - Set key performance indicator (KPI) on what is considered a successful execution of the plan. It can be benchmarks that management can better appreciate the usefulness of the plan - how well it is implemented. 

• For example, in handling an incident, cost of damage incurred due to recovery efforts versus time to incident closure and incident count (monthly/quarter/annual) can formulate as a baseline in a scorecard report for management.

Be Actionable - Layout action to be taken and if possible, list out the discrete step. Action party is a necessity. No point having a plan that cannot be understood or instructed on what has to be executed. Clear steps and action are critical. 

• For example, gap assessment of the incident determines the list of measures to be taken address the root cause. List out affected asset. Report the damages and impact to affected parties. Take up the remediation and mitigation measures expediently. Observe the stability of the affected asset over a period. Ensure closure of each incident is done diligently.

Be Realistic - The plan has to be in context and well balanced on complexity and implication involved in executing the plan. Resource availability and organisation policy enforcement are typical bugbear constraints.

• For example, during the "firefighting" of an incident, there may be a need to activate more resources if the incident gets out of control or gets worse (like a malware infection in a client machine spreading into backend servers). A ready pool of resource and escalation protocols has to be in place, and these need to be part of the plan.  

Be Time-bound - This is the toughest part as no one like to be chased by a deadline, but it is a necessity taken in a positive light. A limited time actually "forces" us to prioritise what can be done within the agreed timeline. Covert the important, address the urgent, and shelf the "good to have" to a subsequent revision of the plan. 

• For example, in the incident plan, there are many types of incidents (e.g. malware infection, DDoS attack, unauthorised access, hacking, phishing, identity theft etc). To develop a complete playbook for each incident is challenging if given a short (let's say) 2 weeks. The quality of the plan is not assured. Either ask for more time or cover the common threat faced by the organisation.

Be Engaged - Put yourself in the reader's shoes and address the audience expectation, or at least hear out what they see is needed in the plan. Run workshops and conduct an interview to get a good sense of the list of requirements and expectations. Adopt the agile approach - run iterative cycles in engaging the stakeholders. 

• For example, always check out any parent incident plan in place, do not reinvent the wheel but align and drill into specifics of what can further develop in your organisation. Like handling a new type of threat called ransomware (under the malware family mentioned in the parenting plan). List out concise steps and step through the response procedures.

Be Reviewed - No point having a plan that only you can understand. Avoid confirmation bias. Reflection is key to stay open on what is the optimal change in enhancing the plan. Conduct peer reviews. Compile reviews and changes into the overall plan and seek as a submission for approval. Give a sufficient buffer for doing all of these activities. 

As a whole, show empathy in engaging with the stakeholders and action parties. They need time to ingest and provide feedback. Stay positive, the journey to complete the whole plan needs resilience to manage the various team dynamics. And always look forward to a SMARTER plan!