Incident management isn’t too far from most CISOs’ minds in any given day.
If you read the news, any news, you’d be forgiven for thinking incident equates to some kind of catastrophic breach. Well, that is an incident of course, but the reality is that in the IT management world, an incident is any kind of unplanned activity as it relates to IT infrastructure.
It can cover the newsworthy major security breaches, but more often, incidents are equipment failures, corrupted applications, incomplete backups and damaged end user devices. They can also be unauthorised data leaks, theft of equipment, computer viruses, breaches of internet usage policy or the intentional destruction or theft of data.
It’s a bit of a laundry list and you can see why policies and security management frameworks have become critical for dealing with them. Not all incidents are of equal importance to any one organisation and the process for dealing with them will always vary.
The over-arching standard most organisations work to is ISO27001/2. Actually, it’s a whole series of standards under the ISO27000 umbrella with some 45 documents going from high level to very detailed areas – but if you Google it you’ll get the gist.
Give or take a few sub points, the IT security management standard (ITSM) lays out a framework to assess an incident (What sort of incident is it? How serious is it?), respond to it, eradicate it, restore whatever function was disrupted by the incident and finally, review what happened and how the incident was dealt with to see if there are learnings and improvements to be made.
There are additional standards and regulations that different organisations will lay on top of this more general ITSM approach. For example, if you need to comply with PCI DSS regulation because you access, store, transmit or manage card holder data then you need to run at least an annual incident test to see how well your systems, policies and processes stand up in the case of a breach.
Likewise, banks and other large financial institutions can be required by regulators to prove their disaster recovery systems will stand up in the event of primary site failure.
An interesting side-note here. Policies also form part of an ITSM system. These are those extra documents you sign when you join an organisation, and cover areas like agreeing that you won’t use company-owned equipment to host Call of Duty games, or you won’t email data to a personal account, or comment about confidential company information on social media. Breaches of policy are also incidents, and the consequences are usually laid out in the agreements you sign on joining a firm.
Logging is good
Logging tools have an important role to play in not only flagging incidents as they happen, but also in providing an audit trail of events leading up to the incident. That might be a technical malfunction or a deliberate attempt to hack into the corporate network.
Logging tools like the ones we offer at Snare have a small footprint, are extremely durable and can be dialled in to the specific characteristics of different kinds of networks and end user activities. If you don’t use logging across your system now, it’s definitely worth considering and will improve your ITSM significantly.
Managed Security Service Partners – where black and white turns grey
Last but not least, it’s worth quickly touching on the additional complexity that comes when your organisation signs up with a managed security service provider (MSSP).
It seems kind of obvious, but make sure you really have a handle on exactly where your responsibilities end and the MSSP’s begin. Often MSSPs will be tasked on edge security, but core security is up to you. Or they’re focused on enterprise systems, but not end user devices.
Make sure you map out exactly who is responsible for what and build detailed service level agreements to suit. It’s an increasingly common story (more so in mid-to-small sized firms) that a lack of clarity about responsibilities between parties led to significant, expensive and sometimes company-ending incidents. Don’t assume the MSSP has got you covered unless it’s in writing.
If you want to know more about our logging tools you can find more information at https://www.snaresolutions.com/resources/ and you can find some great resources on ISO27001 here
https://www.snaresolutions.com/wp-content/uploads/2018/05/Snare-for-ISO-27001.pdf.
For specific areas on incident management NIST publish a great guide, it’s 70 pages of goodness and not a difficult read and also contains some other links to good references for any security teams.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
