Account Takeover Controls
This is an ATO post. I want to share with you, as a security architect, which security controls work and which drive more hype than results.
- MFA — the most obvious one. Two scenarios:
A) Workforce — Works well in stopping scaled ATO; however, falls short in spearfishing. If an attacker is able to get compromised credentials from the dark web, then MFA becomes a single FA. Then attacker can find a way to compromise the second factor, either sim swapping or trick an employee to verify the second factor, while being in possession of the first one. See Uber breach from 2022 how an attacker exhausted an employee and made his click on a verification link.
B) Customer — MFA works when implemented and adopted. Adoption is the Achilles heel here. There are very few organizations that made MFA mandatory for their customers — I know only one. In this case, if there is MFA deployed with 20% adoption rate, there are 80% not covered with it. Other security layers are needed to protect customers.
2. Strong security policies — here the obvious is to modify the existing password policies that are already in place. See NIST800–63b or my LinkedIn post on the subject. The main changes you need to make is to:
A) remove mandatory password reset rules or extend them to 180 or 365 days. The main reason is users choose predictable passwords when they need to change them often. If your auditor is uncomfortable, you can overlay that extended policy with password screening — see C) below.
B) remove password complexity but require longer passwords. If you look at a password security meter, you’ll find a longer password is more difficult to brute force. Also, users tend to use easily guessable patterns when coming up with complex passwords or copy them on a piece of paper.
C) Screen passwords at the time of usage — account creation, login, password reset, against known compromised credentials. This security control checks each password for compromise and launches a remediation control such as identity verification (MFA, security token, link to email, etc.). After the user validates his/her identity, the user is sent for password verification. This control could be a fully automated process, which takes no toll on the security team.
Finally, if you haven’t done that so far, audit all existing password policies and make sure you understand them, and they don’t conflict with each other. I know sometimes those policies could be overwhelming, but there is no substitution for that work. I had a conversation with a post-breach CISO who told me I didn’t know we didn’t have that policy or our other policy didn’t work.
3. Anomaly detection and risk — here you can use a vendor or build your own capabilities. The three data streams that come together to give you visibility are: your org’s logs, IP geolocation intelligence, and compromised credentials intelligence. The list of controls that can be created is too long to be added to this post. I’ve listed some of those that usually don’t come preconfigured with security tools, and I consider them a must-have. Based on three sources of data, you can create your own security controls:
A) suspicious successful logins — sometimes it is not reasonable to block users or to ask them to reset their password just because they connected from a different IP, different machine, in the middle of the night or even because their credentials have been found in the criminal underground. There are many reasons for that. The most often is that there might be a negative business impact, and we might be called for that. You need to have a report that identifies all of those suspicious successful logins and think of new policies that can help you make those successful logins a small number. For example, if you see many logins with compromised credentials, send the users to identity verification. If you see many users logging in from different locations, see the list with locations and block or challenge those from suspicious countries. The goal is to address most of the reasons for suspicious successful logins.
B)Firewalls — they have many rules. There are so many rules that some of the firewall vendors offer “analysts as a service” to help you set them up. One rule you might not know about is a check for logins with compromised credentials. Some advanced firewalls can “see” the login flow of services they protect and check if the user logging in has compromised credentials. Then, those firewalls can address the issue by notifying or challenging the user.
C)access revocation after authentication. The average session duration is 8 hours. What happens if you have an authenticated user and then the user gets compromised at a 3rd party service? You might think this is not your problem, but if you have many of those users and the message gets to the media, your org will have a hard time placing the blame on the users. OpenID SSF workgroup has thought about this use case. They have put together two protocols that allow organizations to exchange security signals, which can revoke access to authenticated users. Watch this short demo of what Cisco has done — https://vimeo.com/manage/videos/724619608.
This post’s goal was not to become an exhaustive list of controls that can be implemented for ATO but to show some of the less-known ones that give significant ROI on the cybersecurity investment of time and resources.
