An insight into my role as a SISO

In part one I talked about some of my role as a senior information security officer, and if you've not read that post it makes sense to start there. Following on from that, I'm going to talk about some other areas, starting with incident response.

Incident response

A feature of the role that I love and hate at the same time. There's a bit of an adrenaline rush when coordinating incident response, but at the same time there's a feeling of "oh no!" that comes with it. Once the problem is resolved my involvement doesn't end though.

Throughout the incident I'm logging what happens on a timeline, and often sending updates to the rest of the business. Depending on the situation, I'll also be directly giving advice or making changes in order to restore the system to normal operation. If the problem is a significant data breach [1] I'd be more actively involved in determining what's happened and performing containment. Fortunately this is not something I've had to deal with.

When the problem is solved I interview colleagues to find more details, and to help determine what happened. The goal is to learn from the incident, not blame someone, so these conversations are casual. If a mistake's been made and my colleague is apprehensive, I'll share tales of my own mistakes (I took down a council data centre once, for example) to help put my colleagues at ease. We all make mistakes!

Working out the root cause of the problem (something I've written about before) is not always easy, and speaking to colleagues that were more directly involved is crucial. When necessary I'll log remediation tickets to help prevent a repeat of the problem, for example if the issue was caused by a bug or configuration issue, but sometimes all that's needed is a conversation.

If you wanted to run an incident response exercise, I wrote about this in a previous three part series - start at part one 🙂.

Outages

Outages count as security incidents as they impact the availability component of the CIA triad (Confidentiality, Integrity, Availability), so I end up involved. Most of the time my role is to coordinate the incident response side of things, letting the technical teams do what they need to do without being hassled by people wanting updates all the time. There's nothing worse than trying to fix something and being bothered by people every few minutes - as I once put to a former colleague, "I can save the patient, or I can send comms, pick one".

Malware reports

Generally these are automated from the anti-malware system (think Sophos Endpoint & Control or Microsoft Defender) but need to be checked. Malware could potentially impact the whole CIA triad, so it's better to be safe than sorry. Quite often the anti-malware protection will have prevented a major problem, which is what I like to see.

What can be interesting though is how the malware reached the system, and this can lead to interesting discoveries. I've talked in the past about how malware was brought in because a colleague wanted to open a .rar file, so understanding what happened can help identify other problems that aren't necessarily security events (in that case, the problem was procedural).

On some occasions the problem has actually been a false-positive - the anti-malware system incorrectly classified something as a problem when actually everything was fine. I remember one time receiving a ransomware alert only to, fortuantely, find the issue was down to how an in-house tool had been behaving. I was very pleased when I was able to show that was a false positive, and very grateful to my colleagues who were graciously patient while I held them up to check everything out!

Investigations

I can be called on to conduct investigations inititated by my colleagues (for example HR dealing with a disciplinary) or by customers (usually when a behaviour they've seen in the system doesn't look right to them). I'm trained in digital forensics, although don't normally have to go further than log reviews when looking into these things.

For internal investigation, I might be asked to look at the logs to determine when a colleague was working. This is usually in response to a suggestion that someone hasn't been working when they claim to have been. As a starting point I look at the Microsoft 365 logs and see what logon events are present, plus checking what emails were sent and what documents were created, edited, or accessed.

When performing any investigation it's really important to be clear on a number of things. Firstly, the logs can only tell me what account performed an action - I can't say "it was definitely this person" because they may have allowed someone to use their account or stepped away from their computer and left it unlocked (they shouldn't do either of those things, but it happens). I'd only be able to say which person performed the action if there was a camera looking at the person, keyboard, screen, and mouse, and all the times matched up. Even then, there's probably a way to defend against that evidence (deepfakes spring to mind).

For internal investigations, I'm also very quick to highlight to the manager and HR that the best way to handle this is by speaking to our colleague. Sure, the colleague could lie, but there may be a perfectly good explanation. If it's a question of "were they working?", the colleague might be able to tell you they were in last minute meetings, or on long phone calls (which I possibly cannot track). I could also be asked to investigate why a colleague went to a particular website, and again there could be very reasonable explanations (including a malicious link).

Sometimes customers will request an investigation because what they've seen in the system doesn't meet their expectations, or because they have a colleague they are investigating and need information from us. I'm not usually involved in the latter, as the support teams will just pull the logs and issue a report. For more in-depth investigations I produce a report that gets sent to the customer that (hopefully) answers their query.

There was a case recently where an action appeared to have been carried out by an account that shouldn't have been able to perform that action. This was interesting to investigate because I and colleagues had to look into multiple data sources (user activity logs, web server logs, API logs, etc.) to see what was happening. We concluded early on that there was no data breach. We also determined the person that owned the account in question hadn't performed the actions (logs showed an automated process was responsible, and the person didn't login on that day). It took a lot more investigation by colleagues to locate the bug and rectify it. I'm pleased they told me the solution - we all agreed it was a bug, but it was bugging me (sorry! 🤦) not knowing where the bug was.

Next time...

I've covered a lot again, so there'll be a third post (maybe the final post) in this series. Next time I'm going to talk about the software development life cyctle, customer relationships, and keeping up-to-date.

Banner image: "Computer Programmer - colour", from OpenClipart.org, by j4p4n.

[1] I say "significant data breach" here to separate these from situations where a colleague has just accidentally emailed the wrong person.