Keeping with todays theme of working through a backlog, I’ve had two ISC diaries flagged for several months, Dealing with Security Challanges and Making the most of your runbooks.
The first is more a question of how to handle security incidents and requirements with minimal resources. This seems to be a common theme, with lots of in-house security teams complaining that resources are too tight and that priority (rightly or wrongly) is given to other business units. The summary of tips provided is too generic for my liking as most should be obvious or common-sense issues, although I’d definitely like some advice on how to actually achieve some of them. For example:
- Set priorities, don’t waste resources on unimportant or nonconsequential tasks.
- Get buy in from other business units (especially management)
- Stay calm
- Request assistance if workload is too much
The second article provides more concrete advice on planning for, and managing security incidents and boils down to three goal markers within an incident handling framework:
- If you don’t have written procedures or steps for handling an incident, then write some.
- Centralised, digital procedures are more useful than paper records. Allowing for easy access and colloboration by multiple members, with a specific recommendation of using a wiki.
- Automate as much of your procedures as possible. For example if one of the procedures is to search web server logs for specific entries, add a button or page to the wiki that automatically searches the specific logs and returns the information. Less steps for responders remember/work through, and less chance of making a mistake when under pressure
Finally the diary entry makes two points to make the case for why you want these systems in place.
- Compliance; logs from wiki based procedures can prove to auditors that the specified and pre-approved actions were taken during incident X.
- Management; logs and records from past incidents can prove the value of security and incident handling teams within an organisation, or prove SLA compliance with internal and/or external clients.