Is Your Risk Assessment Authentication & Access Ready?
In August, the FFIEC released new guidance titled “Authentication and Access to Financial Institution Services and Systems”. Because the guidance...
2 min read
News this week brought us word of something very disappointing, a breach in a large player in the identity services company, Okta. If I’m being 100% honest here, it was an unfortunate eventuality given the mass role out of multifactor authentication in the past couple of years. Hackers never give up and they won’t let multifactor authentication get in their way.
Interestingly enough, I read this morning that the group responsible for the breach, Lapsus$, relies heavily on disgruntled employees by offering financial gain in return for credentials or sensitive information to get into victim networks.
As the week went on several statements were released, including news that about 2.5% of Okta’s customers have been compromised. Events may still unfold and whether you are impacted or not, here are recommendations in this or a similar scenario.
- Review activity logs beginning in January to the current date- The compromise was to a third-party customer support engineer who could reset passwords and the device used for multifactor authentication. In this activity, suspicious indicators would include logins from unusual IP addresses, password changes, multifactor resets, such as adding a new device to authenticate or changing the verification method. If you have any reason to believe suspicious activity occurred, or just want to play it safe, you should consider a global user password change to effectively kick out any unauthorized users.
- Treat password and multifactor resets with suspicion- While the breach has been said to be contained, diligence should still be used as downstream impacts may still be unfolding. Ensure that for each request, the identity of the requestor is being verified, outside of passwords and multifactor verifications, even if this change has occurred in the past as this would be one of the initial steps of the attack.
- Users should communicate any suspicious activity- The universal truth here is that users make or break security. Continue to communicate this and other threats to employees and encourage them to report anything suspicious, this can include anything with their account on systems and their multifactor verification.
- Third-Party Management- Recall, the compromised engineer worked for a third party in this case. We must ensure that we are including incident reporting procedures and requirements in the third-party onboarding process. Require and keep an eye on controls reporting for signs of trouble and follow through with the vendors on any weaknesses identified. If necessary, bolster protections to your network that would prevent and detect any compromises coming from their end.
- New incident reporting rule- Beginning in May 2022, banks are required to report certain incidents to their primary regulator within 36 hours of discovery. Further, any service provider to a bank must do the same. While it is unclear that it would have made a material difference, in this case, we need to be prepared to take swift action in these cases. Hopefully, the impact of this new rule will help us be better informed about malicious activity and take actions to protect ourselves and our customers sooner.
Sources:
https://www.theverge.com/2022/3/22/22990637/okta-breach-single-sign-on-lapsus-hacker-group
Backups vs. Retention
We often run into situations where different staff in an institution have different understandings of the goals and operations of their backup...