Account Takeover (ATO) Maturity Model
The introduction of a financial fraud maturity model allowing organizations to assess preventative capabilities of an account takeover. The intention of this model is to fit fraud techniques within a larger capability mapping such as software, cloud, or incident response.
Capabilities and Frameworks
The idea of a Capability Maturity Model (CMM) is not a new concept, it was created in 1986 at the U.S. Department of Defense with the intention of optimizing existing software development processes. Subsequently additional models such as the Building Security In Maturity Model (BSIMM), NIST Software Security Framework (SSF), and OWASP Software Assurance Maturity Model (SAMM) were released with the intention of maturing software development.
In 2006 Carnegie Mellon University released the Capability Maturity Model Integration, further broadening maturation of capabilities from software specific optimizations into general processes. This allowed for more specialized models such as the NIST Cybersecurity Framework and ISO 37004 Governance Maturity Model. Much of the information technology landscape began to follow the one through five characterization of activities into models that defined domains in terms of capabilities.
While Cybersecurity was a natural progression from Software Security, the logic surrounding adversarial pressures and organizational defenses was largely developed outside of the constructs of maturity models. Rather than focusing on building security, incident response sought to measure maturity of attacks and defenses. First to demonstrate this outside of United States Army Field Manuals was the Lockheed Martin Cyber Kill Chain in 2011. Subsequently this model was largely superseded by the MITRE ATT&CK Framework in 2013.
Organizationally most Cybersecurity or Incident Response teams sit apart from Application Development teams, with a few flat and arguably less mature exceptions. From a business perspective this ensures delineation in terms of responsibilities and performance measurements, which is vital. While from a security perspective this ensures those building security are apart from those defending it, which leads to gaps in our overall program. To combat this, there has been a recent movement of DevOps and DevSecOps which seek to combine these capabilities into the agile development methodology. The concept of Chaos Engineering has also popularized this effort, and largely aims to fulfill the feedback loop between organizational groups, by incorporating real-world attacks into engineering practices.
Commonality of Account Takeovers
Business fraud prevention operates with the intent to stop or thwart the use of stolen credit cards, identities, limit chargebacks, and most importantly stop account takeovers. Account takeovers are a commonality among internet fraud prevention and the security teams we discussed earlier. Control mechanisms for the fraud prevention teams often rely upon the same technical mechanisms that application and cybersecurity teams use, such as device fingerprinting, API rate limiting, and multifactor authentication. More than likely the maturity activities of an account takeover are currently embedded within your SDLC and incident response processes, without any consideration given to the type of fraud perpetrating them.
Financial fraud and fraud prevention capabilities largely sit within product specific groups or customer service departments. Much like the earlier discussed separation of application security and enterprise cybersecurity teams, the fraud team and security teams can benefit from a feedback loop. Both groups have threats which are often detected, degraded, disrupted, or denied by corrective actions. At the center of these events is account takeover, and more often than not the type of fraud and scams are often lost by the technical teams which engineer security controls. All this spite the prevailing threat within the cybersecurity landscape being criminal.
Let’s first look the financial fraud avenues to consider, because regardless of the non-financial nature of the “Account” within our product, a malicious actor is intent on perpetrating financially motivated fraud. The banking and loan servicing industry have fraud scenarios which involve falsification of identity or asset allocation. Marketplaces, market makers, and other intermediaries such as clearing houses have the addition of accounting and financial advisor (agent) fraud scenarios. And finally, the retail banking and payment card industry have a host of consumer fraud scenarios involving billing, dispute resolution, and the list goes on.
Taking a pragmatic approach to fraud let’s define the overlap of exploitation in Fraud and Cybersecurity incidents:
- The instrument — A device or session used to provide confidence in a transaction
- The process — Business logic which ensures diligence is performed on underlying assets
- The verification — Mechanisms to validate behaviors and actions are performed in good faith
- The trust relationship — Handoffs between partners often via system integrations and APIs
These would be a great beginning to a control mapping or ATO threat modeling exercise, which may have inspired this work to begin with, but what if we wanted to mature the capabilities leading to creation of those controls? We would need to identify the Scams perpetrated by a Fraud which lead to an Account Takeover.
Scams, Fraud, and ATOs
Scams are the result of an appeal or incentive toward our basic human needs. Maslow’s hierarchy of needs is a well-known and accepted psychology model categorizing these needs. Focusing on the lower levels of this model we can ensure that the scammers desired effect or appeal of human need is tracked with known and unknown threats. Starting with Safety and Security an attacker would try to impose fear toward the victim. Moving up to Love and Belonging an attacker might try to appeal or impose fear toward the victim. And finally Esteem and Prestige would be attacked through a fear of embarrassment or appeal towards status.
A breakdown of scams organized by hierarchy of need would look like this:
- Esteem and prestige — Respect, Self-esteem, Status, Recognition, Strength, Freedom
- Love and belonging — Friendship, Intimacy, Family, Sense of connection
- Safety and security — Personal security, Employment, Resources, Health, Property
Now that we have defined a model to categorize scams, lets now look at the fraud types perpetrating an ATO.
1st party fraud — a person or group falsely identifying themselves or providing incorrect information
Examples of first party fraud include fake IDs, false credit scores, diplomas, or citizenship documents.
2nd party fraud — a person agreeing to give their personal information to their family member or a close friend to commit fraud
Second party fraud is also known as friendly fraud, and includes scenarios such as cashing a deceased relatives social security check.
3rd party fraud — a third party uses an innocent person’s information to take over or create an account without consent
In third party fraud there is an innocent victim unlike first or second party fraud. There are endless permutations of third-party fraud, but for our model we want to focus on third party fraud which results in an account takeover or creation of a synthesized account.
Scams fall into two categories, persuasion tricks meaning the exploitation of judgement, or impersonation tricks which exploit someone’s trust in a person system or process. Scams may also involve the combination of these two categories.
Conclusion
My proposition is to include this fraud logic into our existing Capability Maturity Models, and for the very first iteration of this capability I wanted to specifically capture financially motivated threats. I welcome feedback and additional input to make this a cohesive financial model applicable across institution types and industries.
I have formatted the model in MarkDown format and CSV format on my GitHub repository.
Thanks for reading!
