There has been a lot of delay for getting this out, and partly due to the workload coming our way. There are multiple incidents happening all around us, and I feel it is mainly because we have missed the crucial steps in putting together our defence. This series is attempting to give you the ammunition to take this forward, and I sincerely hope this has been useful to you.
Thank you for reading through this. This article is the next in the series. Your feedback means a lot and I appreciate the comments coming my way. In case you have missed the earlier articles, the links are below.
We conducted a Risk Assessment and identified the risks we want to mitigate in the previous article.
We defined policies n procedures as listed in Article 3 – http://arrka.com/index.php/2017/09/13/step-1-define-the-policy-for-both-digital-and-cyber-information-security/
We will now look at Implementation and Rollout of the mitigation actions we described.
Our implementation comprises of three major components
- Governance and changes to the policies based on what we need to mitigate
- Process and Procedure implementation
- Technical areas implementation
The governance here comprises of identifying the changes required and the updating of the policies. We did prepare some policies earlier which we now revisit. Why these changes – because we are now more aware of our risks and the threats to our environment. A simple example is related to password policy. E.g. we had an earlier policy which said that all passwords will not be re-used for 2 times, so we cannot use the password for at least 2 turns of password change. However, we have now identified that this is not enough for some applications which are internet facing. The risk is higher here because our passwords become predictable and can be guessed easier. Hence, we may make a change to the policy saying no re-use for at least 5 times. The policy now needs to roll through a change management procedure which records the why and what of the change. We may also decide to have different password policies for different types of applications and this also needs to be recorded and approved.
This policy now needs to be converted into a procedure. The procedure also needs to be communicated. The process implementation now comprises of the actual procedure rollout into operations by inserting this bit into their work instructions. By putting this in line with operations rather than having a separate line item for security enables the team to embrace and follow this easily. Else, the common refrain is “why are you adding to my work load?”. The other aspect is to make this audible and so we should go and update the audit checklist as well with the various scenarios so that the correct scenario will be tested. One last aspect is to include this into our security baseline documentation and the business continuity / disaster recovery documentation. That way, our testing and actuals during recovery does not impact the security controls during disaster. We don’t want security to be weak when things fail and we recover with lesser security than the one during business as usual.
Some of the actions for threats may relate to configuration / rule changes. This needs to be actioned as well. This is part of the technical rollout and implementation. Ensure that during the technical rollout, you test the changes in a test system and then rollout to production. Rollout to production needs to be taken very carefully. In addition, you must always have a backup set which can be used to restore the system to the last known state immediately. Don’t try to troubleshoot on the production system in case of any failure, just restore and get it working. This is true when it comes to patches to be applied to the system as well. Trying to troubleshoot the production system will only increase the time lost due to downtime, and you will panic as the time goes by. Not to mention the credibility of the team at stake. Time lost due to troubleshooting will be far more difficult to explain rather than a failed implementation. All of these are learnings which can be used to implement on the test system and check for different scenarios. The OEM may also have advisories for your scenario. Check with them, so you know you are not the only ones facing this. Have support available during these changes. And lastly, do document the final changes back into the procedure, baseline documents, bcp/drp documents etc.
Next we will explode Step 5 – Review of implementations like Log Review, Incident Review, SIEM, Monitoring of the various access, set up a helpdesk etc. All of these can be implemented via Open Source solutions.
Till then, stay safe and if you need emergency response/ help, shout out to
In case you have missed the earlier part of the series, it is at