Okta Sample Prompt
For the second time in a year, Okta has had a breach related to their customer support system. This is a great opportunity for other companies to learn about both vendor and process security. In my mind the best means to convey this to key stakeholders is through an incident response training. Here is a sample scenario you can adapt for your company.
Setup
First, talk to your customer support team to get details on their processes when working with your customers:
How do they verify the identity of who they are talking to?
What channels do they talk to the customers over? Just phone or is it also email?
What information do support agents have access to? Are there different sets of data accessible by different roles?
What is the escalation process for someone to move beyond frontline support?
Are customer interactions ever monitored or reviewed?
Are frontline agents trained to report suspicious behavior?
Based off those questions you can begin to find potential holes in their processes. Ask yourself and your team some questions like these:
If a scammer doesn’t know some identifying piece of information, could they fall back to something else? For example, not having access to an email account, would customer support fall back to the phone number?
Could a rogue frontline agent access data undetected?
Is there any info given out that could be accumulated into a more believable fake identity?
Are verification processes reliant on information that could be gathered via OSINT?
By answering those questions you can build up a more plausible prompt. I suggest layering the security holes together to create a more nuanced and complex scenario. You will also be able to figure who outside the core IRT needs to be present. I always include a few people from around the company in relevant departments. In this scenario, you could include a customer support agent or two. They are your subject matter experts who can help fill in the gaps in the narrative.
Scenario
Use this initial prompt to get the scenario going. Give it to the person who would normally receive customer complaints (I’m going to name them Sam the Agent) and make sure that they know not to broadcast it to the training participants. They should let individuals know as they would in the real world.
You’ve received a few complaints from high profile customers that their account info has changed. In particular they all see that the email addresses associated with the accounts have been changed to something they do not recognize.
Sam the Agent should be familiar with the escalation procedures for their department. If not, take this opportunity to remind them, after all that is what this training is for.
From here, your customer support team and technical staff should work together to determine the details about the account information changes. They will ask you for what they find, give them this:
You see that all of the changes were initiated by frontline customer support agents. The changes were made by multiple agents. It appears that there are records of several calls for each affected account for similar issues. There is a strong similarity for the sequence of issues for each account.
Depending on how incidents are handled at your company, it is likely that at least the core IRT would be notified. If the people in the know decide to notify the team, you can broadcast everything to the wider training audience.
At this point in the training, I will usually throw in a red herring. These serve to remind the IRT that there will be a lot of noise to sift through when responding to a real incident. For a more non-technical scenario like this one, I suggest using technical evidence. In the past, I’ve gathered screenshots from AWS GuardDuty of alerts that look scary but are really not.
Where your team takes it from here is heavily dependent on your particular company. In all of your answers to your training audience, tailor them towards continuing the discussion and investigation. The goal here is not to solve the puzzle, it is to fully explore the bounds of your incident response.
Post-Mortem
Just as with a real incident, reserve some time to discuss what was uncovered in this incident. At this time, everyone who was in observer-only mode can participate. Encourage that group to share their thoughts on how they might have responded differently.
Here are some discussion questions to help move the discourse forward:
Are there tools we could have in place to detect this before a customer notices?
Are there authenticated methods for verifying a customer’s identity at the start of the agent interactions? Do we have a mobile app that could use push notification verification?
Was everyone aware of the escalation processes and designated alternates?
Since requests across multiple customer accounts showed strong similarities, is there any knowledge sharing among customer support agents that could have spotted this sooner?
If your customer support team is outsourced, should that support vendor update their own internal policies as well? Would it be worth looking at alternative vendors?
Could this have been done by a recently terminated employee if their access was not revoked in a timely manner?
Finally, you should reassure your audience. They might be a bit shaken and worried about the state of the company. Ask them to concentrate their anxiety towards productive uses. They should take a look at their own departments to see if there are corollaries from this scenario into their work.