I received a letter the other day. Very polite letter, not lecturing me in anyway shape or form, but it was from my bank. It provided lots of information about dealing with debt relief and charities that I could talk to about assisting me in my debt crisis.
I received the letter because I had only paid the minimum payment for my credit card that month and this got me thinking. It was obviously generated by a routine which checks if someone only makes a minimum payment, informing them that it’s not the most efficient way to use a credit card and was trying to be helpful. But a routine that generates a letter like this for one minimum payment highlights to me how automated processes and procedures which are used to make sure an organisation is compliant with regulations or company policy etc, can’t sensibly cope with life’s little changes and doesn’t take into account a host of other factors. I have, like most people, been affected by the Corona virus and its effect on the economy. But the bank’s process doesn’t know that or take this into consideration.
The same is true for a number of processes and procedures that are recommended to help organisations stay compliant or monitor compliance with standards or regulations. The example above is just one of many I could use to illustrate the point.
If your compliance regime depends upon scripts or automated processes and procedures, are they able to:
- Take into account changes in circumstances?
- Changes that are outside of your organisations’ control?
- Or do you have the flexibility to be able to change them when required?
Generating a report on a monthly basis to show who has access to a system or the number of new accounts that have been created or been deleted is fine in normal operations, but they need to be able to cope with issues outside of those controls.
We are all aware in the current situation that we are going through events very few people have ever anticipated and certainly never planned for. If you have to recover a system and recreate a whole bunch of accounts for example, or increase the level of access because of everybody remote working, then your standard reporting processing and procedures won’t meet the requirements of compliance. Yes, you do need to report on those increased levels of access and activities, but the report should not be ignored just because they’re reporting on a very unusual situation. But from a compliance point of view you need to back up those reports with additional evidence of the change of circumstances. Providing a report to your auditors that only states 70 accounts were created this week may meet the letter of the standard, but it doesn’t meet the intent behind the control.
Does Automation have a place in compliance?
I’m certainly not saying that automation doesn’t have a place in compliance. Like all tools there is a right time and a wrong time to use them. Many regular tasks can be turned into automated processes, but you should not lose sight of why you are doing that process and what the information collated by it, is needed for. Unfortunately for us all, information security controls are not set and we forget. They need to be managed, cared for, cajoled even sometimes to provide the level of protection that you need. How many times have you had to dig into the spam folder to find that important email that somebody sent the week before? There are no hard and fast rules in information security. Adaptive procedures all not unheard of but the complexity of them means they are difficult to manage and to modify.
Firewall rules
It was all very easy in the early days to open up a port for a particular application. But then we had to limit that connection to access from certain target systems or to specific systems. Then next generation firewalls came along and we had the ability to monitor traffic and build rule set based on the traffic it was seeing. The issue always was with this process; how did you know for certain during that monitoring phase, that illegal traffic wasn’t occurring. All types of access control are based on allowing the normal traffic but protecting against the abnormal traffic, but how do you know what normal is? My biggest issue with all automated monitoring tools has always been Its ability to define the normal. Of course, the problem is with multi layered access is that even we as users don’t know what is normal. We rely on the knowledge built into these monitoring tools but by the same degree, the monitoring tools can only look for the type of behaviour that they believe is abnormal or that they believe could lead to a threat. Yes, intrusion detection systems do look for a sequence of events which could indicate a potential attack, but they are sequences of expected events.
So, where is the balance between automation and human activity in compliance? What we need to focus on is that compliance isn’t just about event management. Compliance isn’t the SEIM, the SEIM is a tool to help demonstrate compliance. Let’s breakdown an example: ISO27001:2013 Appendix A Control 12.4 control objective is “To detect unauthorised information processing activities”.
Simple enough, turn on event auditing, forward the logs to a SEIM which runs a set of rules and flags anything that’s unusual, right? Well maybe not.
The sub controls define that the logs should be protected, additional event data to be collected for privileged access and all timestamps should be synced. And control A16.1.2 defines that security events should be reported to management as defined within the security incident management policy. So, it’s not just a case of management being sent a report when an event occurs, we all know they will be filed in a sub-folder somewhere. It’s the human procedure of dealing with the event, defining if an action is required to address a re-occurrence and the implementation of that change in the control.
Information security will never be “plug and play”. Yes, use tools, automation and even AI to help you achieve compliance, but it will not meet the true requirement of the standard or regulation unless there is human oversight.