(ISC)² Security Congress 2022 - day three

The final day of the conference is shorter, so I'm able to hit publish on this before bedtime!  Today featured two keynotes and two talks.

Keynote: Why Political Risk and Cybersecurity Collide in Times of Crisis

It's known that the geopolitical landscape has an impact on the cybersecurity landscape.  In times of political tension, we see increased brute force attacks from related countries in our logs, for example.  Unfortunately, this session seemed more like a political rant to me.  I didn't see any actionable cybersecurity take aways (or reference to the collision hinted at in the title), so I shan't write any further here.

Keynote: Lessons in Leadership

While not specifically cyber security related, this keynote was probably my favourite one.  Carey was incredibly motivational speaker and used a good amount of humour to put her point across.  Something that stuck with me, that I've paraphrased, is "you don't have to get everything perfect before you move on to the next task, just remember to keep taking action".

I didn't take too many notes on this session, as it seemed more important just to listen.  Thanks Carey.

The Day After: Managing Post-Incident Hardening & Resiliency

Tony and Jake ran a very interesting session with a very information heavy slide deck - they were aware of that and invited us to look at the slides for the full details.  A lot of good points were raised during the session and there's definitely more reading I need to do.  A good quote from the Q&A:

"The most damage your company will suffer from a cyber-attack is reputational."

One of their slides showed the incident lifecycle model (shown below), and we were walked through the lifecycle.

Having a plan and being able to communicate are both important during any incident.  When it comes to your plans and playbooks it's important to review those regularly to make sure they're up to date.  If your plan says "contact Ben Teeson to shut down the server", but Ben left the organisation a year ago, incident responders won't know who to talk to now.  Reference a job title rather than a named individual.

Containment is an important step to reduce the impact of an incident, but it's not without challenges.  If you decide it's necessary to isolate a system (or a whole network), do you have the authority to make that decision?  Is an authorised person available to say "yes, push the red button"?  Personally, I'd always rather make the wrong decision for the right reasons ("I did that because the evidence at the time pointed that way") rather than make no decision and have the organisation undergo a full ransomware lockout.

Remediation could take months, so be prepared to not have everything fixed within hours.  During the initial response, you may have had an intense burn for a few weeks to get operable again but be careful to not take your foot off the accelerator altogether after that.  You may find management is keen to invest in protections (that maybe you've said you need before), so "don't let the crisis go to waste".

And don't forget to learn from the incident!

Emerging threats against cloud application identities and what you should do about it

"Application identities" and "workload identities" are non-human accounts such as apps and services.  Often such accounts cannot participate in MFA and may have an entirely different account lifecycle.  As such we need to protect and monitor them.

Threats in this space include compromised applications, malicious applications, and misconfigured applications.  For a compromised application you will want to bring it back to a healthy state, eject the bad actor, and return to production.  Remediating a misconfigured application is similar.

Malicious applications should never have been in the organisation and may have taken hold because a user gave consent.  An example application would be a tool that "provides enhanced search for your mailbox", that the user consents to reading all their email.  If the application later turns out to be malicious it's essential to eject it from the organisation's environment.  Some tools, like Azure AD, can limit the consent users can give to such applications or can set approval to administrators only.

To detect the issue logs, are as always, your friend.

While these talks are supposed to be vendor neutral, this presentation quickly became a Microsoft advert.  That's understandable given the speakers' employer.  Knowing about these features was useful to me, but this was the only talk to push (and then go over) the limit.

Congress next year - would I attend?

Overall, I think this has been a useful conference and I've certainly found it both interesting and educational.  Next year's conference is in Nashville, Tennessee, so I'd almost certainly have to attend remotely if I chose to attend.  Given the cost of living seems to be going up across the board, it would depend on the cost.  Ultimately, I would like to attend, but it needs to be financially viable.  I do find value in attending the conference, particularly with the ability to watch additional sessions after the event.


Banner image: Screenshot of the virtual conference venue landing page.

Text from the incident lifecycle model graphic:

  • Detection and Escalation
    Reports from multiple departments within the company, several large scale outages reported with significant impact to day-to-day operations
  • Analysis and Triage
    Becomes clear that the company has suffered a significant attack, as multiple teams engage to respond
  • Containment & Response
    Response teams attempt to stop the bleeding, save uninfected sites, and determine how to stop the follow-on waves
  • Recovery & Hardening
    The enormity of the event is revealed. Recovery operations commence to rebuild the estate from an enterprise-wide disaster
  • Remediation & Transformation
    Lessons learned from the incident are used to inform transformation efforts to protect the company from similar future attacks