Anne Ellegood

Anne is our Social Impact Product Marketer with extensive experience developing & delivering marketing programs for products, services, and partners that enable sales and build brands. In addition to being an amateur archaeologist, Anne is a self-professed data-hoarder fueled by curiosity & the quest for inbox zero zen.

Product Marketing Director

Nonprofit staff are the first line of defense you have, so here's what they need to know

As a leader of a mission-driven organization, you know that all nonprofit, non-governmental, and charitable organizations count on every stakeholder to help bring their mission and programming to life. The one tool they all have in common?

**Data.**

It doesn't matter if this data is being actively used or waiting for its turn to influence a crucial decision; it's always of measurable value.

It powers nearly all of a nonprofit's business functions; and contains critical information from organization programs and finances to the financials, identities, and personal information of every person in the organization's ecosystem. In ill-equipped, improper, untrained, or ill-intended hands, mishandling of this data can cause unpredictable damage to an organization and its stakeholders. 

## Data Protection – the Fundamentals

Although the responsibility of a nonprofit's data protection and security may fall to a designated individual person or team, even they can't monitor the thousands of actions stakeholders take with their data every day across the organization.

When it comes to keeping data safe, the best defensive measure is an educated and security-aware workforce. However, this is not always the case with nonprofit employees, who can often lack the general awareness and ongoing involvement necessary to play a more active role in safeguarding data. It is essential to include everyone in building an environment where personal responsibility contributes to the organization's cyber well-being.

So what are three fundamentals that can empower your people?

## Fundamental 1: Communicate Policies & Procedures Regularly

As part of staff onboarding, review any data protection and security policies and procedures in place across your organization. All contributors should know what is expected of them. Leaders should make sure this information is kept current and that all staff, and any non-internal parties, are informed and provide an acknowledgment that they've reviewed your policies and procedures as they're made available and updated.

> ⇒ Unsure of where to start with creating policies and procedures for data protection and security, or looking to review what your org has in place?

 

> Check out [Cyber Essentials from CISA](https://www.cisa.gov/cyber-essentials), which is an excellent resource for building a culture of cyber readiness within your organization and CISA's [Cybersecurity Framework](https://www.nist.gov/cyberframework); a gold-standard in helping org's understand and improve their management of cybersecurity risk.

Individual contributors should expect to review this information upon onboarding and throughout their tenure with your organization. If this hasn't been the case, then just ask. Everyone plays a part in keeping data protected and secured. If you're an individual contributor on some (or every) level of the organization, YOU are the best line of defense. Review security policies and procedures and frequently refresh, at a minimum, twice annually.

## Fundamental 2: Ensure Compliance

PII (Personal Identifiable Information), GDPR (General Data Protection Regulation), HIPAA (Health Insurance Portability and Accountability Act), CCPA (California Consumer Privacy Act), and PCI DSS (Payment Card Industry Data Security Standards) — are just a few of the many regulations and standards regarding data usage, protection, and security compliance a nonprofit may encounter and be responsible for adhering to. And what's more, these rules and regulations vary greatly. 

To give you an idea of just how vast protection and privacy laws are around the world, check out this [interactive map](https://www.dlapiperdataprotection.com/) from the global law firm, DLA Piper.

All staff and vendors supporting your organization's mission should understand the compliance regulations and standards regarding the data they have access to and work with. Staying up-to-date on changes in regulations is paramount. Failure to remain current and comply with these regulations and laws may result in heavy fines and/or legal action being taken against a nonprofit.

If your organization relies on vendors who have access to your organization's data, request their most current privacy and security policies and audit reports. Review them and ask for clarifications on anything that may be unclear. It's important to understand the measures they're taking to protect and secure _your_ potentially sensitive data. 

For example, visitors to Auth0, a product unit within Okta's online properties, can learn more about our trust and compliance policies through the information we've provided here:[ https://www.okta.com/trustandcompliance](https://www.okta.com/trustandcompliance)

## Fundamental 3: Access Accountability

Working remote, working from work, or some variation of the two? In order to access data needed for work, connectivity to a network and login credentials are needed. No matter what your role is at a nonprofit organization, there are some basic measures you can take to safeguard access to the nonprofit's data:

* When connecting, ensure the network is PRIVATE and SECURED. (Public wifi isn't recommended)
* Using unique, random passwords preferably created by a password manager with the longest character count possible (ideally at least 16 characters at the minimum) will help ensure your login credentials are not easily guessed
* Enable [Multi-Factor Authentication](https://auth0.com/docs/secure/multi-factor-authentication) on all your important work and personal accounts. Multi-Factor Authentication, MFA for short, can reduce the likelihood of cyberattacks from stolen credentials. MFA works by requiring additional verification information (known as factors) when they log in using a username and password, providing further proof of identity
* Avoid sharing your account credentials information with anyone in any format (written, electronic, verbal, etc.) 
* Leaders should enforce the _principle of least privilege_ when it comes to who has access to the organization's data at all levels based on their individual role and need. This should be reviewed often and updated whenever there are changes in people or technology 

> **_⇒ The principle of least privilege is a concept in security limiting a user's access rights to only that which is required to do their job_**

These are just the three basic fundamentals for mitigating data risk in a nonprofit at the staff level across the organization. **All staff could benefit from the helpful information we've compiled to create Auth0's resource, [Your Personal Cybersecurity Checklist: Workplace Edition](https://auth0.com/resources/whitepapers/personal-cybersecurity-checklist-workplace-auth0dotorg).** The checklist covers basic workplace cyber hygiene, personal cybersecurity, and advanced workplace cybersecurity actions every staff member can follow. It's a great place to start your organization's journey to being more secure and assured in 2022 and beyond. 

<include src="asides/AboutAuth0" />

3 Fundamentals in Data Risk Mitigation for Nonprofit Staff

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

Inaugural report reveals insidious trends and provides mitigation strategies for security professionals.

**BELLEVUE, Wash. – June 16, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced the launch of its inaugural security report: [The State of Secure Identity](https://auth0.com/resources/whitepapers/state-of-security-identity-report). This detailed report highlights key areas of concern for security professionals responsible for managing digital identities, including the exponential rise of credential stuffing attacks (automated attempts to compromise a large number of user accounts with stolen credentials), fraudulent registrations, and the widespread use of breached credentials. 

Recent headlines and high-profile cyber attacks give today’s security professionals a wide swath of serious threats to worry about. The primary goal of cybercriminal activity is to access critical resources, systems, and personal data, yet systems that can be put into place to minimize the risk of attack — like identity management — often get deprioritized. Lack of budget, resourcing, or attention on managing digital identities give threat actors a prime opportunity to take advantage of these discrepancies and surreptitiously execute their attacks. 

Research into Auth0’s global customers over the past year found these key facts and figures: 

* In the first 90 days of 2021, credential stuffing accounted for 16.5% of attempted login traffic on its platform, with a peak of over 40% near the end of March — all of which Auth0 detected and prevented. 
* Travel & leisure and retail are the top two industries most affected by credential stuffing attacks. 
* The number of fraudulent registrations vary by industry vertical, but roughly 15% of all attempts to register a new account can be attributed to bots.
* In the first 90 days of 2021, the Auth0 platform detected breached passwords at an average of more than 26,600 per day, with a minimum of just under 7,300 and a high on Feb. 9, 2021, exceeding 182,000.

“Securing customers’ identities is made more difficult by industry-wide failures to protect data. The prevalence of breached passwords and the availability of automated attack tools makes the humble password a protective measure from the past,” said Duncan Godfrey, VP of Security Engineering, Auth0. “The State of Secure Identity Report is designed to share our unique identity security insights and recommendations with the industry so that application builders and developers at any organization can take the steps they need to improve their overall security posture and make things more secure for end users.” 

The most prevalent threats detailed in the report include Credential Stuffing (the most common threat observed by Auth0); Fraudulent Registrations; Multi-factor Authentication Bypass; Breached Password Usage; and other common identity attacks. The complete Auth0 State of Secure Identity Report, which includes additional key findings and recommendations on how organizations can improve their identity security posture, can be downloaded **[here](https://auth0.com/resources/whitepapers/state-of-security-identity-report)**. Auth0 will also be hosting an online meetup to examine these insights in greater detail on **[Thursday, June 24 at 8:00 AM PDT](https://auth0.com/resources/upcoming-webinars/state-of-security-identity-report-session-one)**. 

[Auth0, recently acquired by Okta](https://auth0.com/blog/okta-acquisition-announcement/), provides a modern identity platform that helps organizations meet the security, privacy, and convenience needs of their users. Please visit the [Auth0 Identity Platform](https://auth0.com/identity-platform) to learn more.

<include src="asides/AboutAuth0" />
### Media Contacts
Global Communications 
Auth0 
[press@auth0.com](mailto:press@auth0.com) 

Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Auth0 Releases State of Secure Identity Report, Highlighting the Most Pervasive Threats to Digital Identities

joan-pepin

As CSO, Joan is responsible for the holistic security and compliance of Auth0's platform, products, and corporate environment. She brings 20 years of experience to the role, with a career that has spanned a wide variety of industries, including healthcare, manufacturing, defense, ISPs, and MSSPs. Previously, Joan served as Business Information Security Officer (BISO) at Nike, Inc, CISO, and VP of Security at Sumo Logic, and held different positions at Guardent/Verisign/Secureworks organization. Joan holds a patent for developing the methodology to assess whether a communication contains an attack. She is also is a well-recognized thought leader and has spoken at major events, such as RSA, WhiteHat Security Summit, and Forrester Security Summit, and is frequently called upon for her expertise and commentary in Cloud Security and Compliance in large-scale and DevOps/CI environments.

Chief Security Officer (CSO)

Joan Pepin

On July 31st 2019, at 5:11am, we received an email from Insomnia reporting a service vulnerability. By 11:00pm the same day, we had fixed the issue in production.


On July 31st, 2019 at 05:11 UTC, Insomnia Security responsibly disclosed a JWT validation bypass issue to Auth0 while performing a penetration test for one of our customers. **A lone path of one of our older, stable versions of our codebase was not using our standard baseline JWT implementation, which allowed a case-insensitive JWS algorithm to match an "unsigned" verifier. This affected a very small subset of our endpoints.**

After receiving the disclosure, we fixed the vulnerability within hours on the public cloud, and through logging, verified it was not being exploited in any way. We have seen **zero** signs that the vulnerability was discovered or exploited in the wild, and have recorded **zero** attempts to abuse the vulnerability.

We worked closely with Insomnia Security to immediately rectify the issue. As they state: 

_"Auth0's public platform was quickly patched and they rolled out patches to their private platform over time. Overall, the response from Auth0 was swift and pleasant. They quickly remediated the issue and appreciated the vulnerability report."_

We take great care in our public libraries so that a vulnerability like this isn't available in our customers' or library users' code. Unfortunately, for this specific code path, we didn't rely on our own module, be assured we do now. Since this disclosure, we have: 

-   Conducted an exhaustive exercise with Auth0 Engineering and Product Security to review our libraries.

-   Launched a Bug Bounty program to accelerate the identification and remediation of existing vulnerabilities.

Transparency is one of our core values and permeates throughout our company, including the way in which we communicate about issues. We appreciate the continued feedback from the security community-at-large to ensure we are providing the most secure platform for our global customers.

## Timeline

July 31st, 2019 at 05:11 — UTC Email sent to the security team by the Insomnia researcher

July 31st at 08:30 UTC — Security Incident Channel created by Auth0 IR Team

July 31st at 13:18 UTC — Vulnerability confirmed and fix started

July 31st at 21:34 UTC — Fix deployed to our stable environment

July 31st at 22:45 UTC — Fix verified by the Auth0 Security Team

July 31st at 23:00 UTC — Fix validated in production and by security researchers




Insomnia Security Disclosure

jeff-moss

Jeff is a Product Security Engineer that is passionate about security and privacy-first software. He has experience in secure engineering in the public and private sectors and has developed and secured security software used to protect critical infrastructure. Jeff leads the Product Security Team in making our identity platform secure and trusted. When not building and breaking things, he can be found playing with his two dogs, hiking or bicycling.

Lead Product Security Engineer

Jeff Moss

How to create a great experience while taking a security-minded approach to user data design.

I love shopping for tools. You may have heard the saying “you can’t have too many tools.” It is quite frustrating when you don’t have the right tool for the job! In the software world, developers have the propensity to look at data in the same way that I look at buying tools; i.e., “I might need this in the future.” In this article, I hope to convince you to dispel this gobble-up-all-the-data thought process.

Let’s visualize your application as a ship. The data you use serves as the ship’s ballast, a heavy material, such as water or sand, placed low in a vessel to improve its stability. Just enough ballast keeps the boat stable and maximizes your cargo. Any more ballast than the minimum required adds unnecessary risk to your journey (and also reduces the cargo that you can carry).

![User experience becomes dangerous when data is overused](https://images.ctfassets.net/23aumh6u8s0i/21njlcdHsbFf8qAFcEBPAV/0d9295882c0312d5f6e2bfdddc3d114a/ux-made-dangerous-with-data-overuse)

Too much data may translate into a poor experience and lose user trust. Your users may ask themselves, "Why do I have to share my location on this Solitaire app?"

![User experience is made dangerous when data is underused](https://images.ctfassets.net/23aumh6u8s0i/7MSOOj8MoDefqIGoZeGaKd/eda09e9277c6a4641cd933f93bd5e57e/ux-made-dangerous-with-data-underuse-)

Too little data may translate into poor user experience because you may not be able to tailor and personalize the UX for your users.

![User experience is stable and true with the minimal amount of data](https://images.ctfassets.net/23aumh6u8s0i/1yzlXuut85Vc3n8AZkhin8/8fbfc5f0415f6647545020d5d7549c06/ux-stable-and-true)

Having the right (minimal) amount of data should maximize the user experience. Every piece of data must serve a purpose for the user and bring value.

Developers want to provide the best experience for their users. Often, providing a great user experience means collecting their data. For example, in an application, a developer may use location data to set a geofence to improve the user’s experience while they visit a physical store. What data should they collect and how should they handle it?

For each piece of user data collected, there are hidden costs of that data in the form of:

- Compliance (GDPR, HIPAA, PCI, etc)
- Security
- Privacy

Each of these topics are entire disciplines, and there is a lot of literature — valuable or otherwise — covering them in heavy detail. We will be focusing broadly on reducing our risk across these areas.

## Real example: Abusing Data From Open Sources and Breaches

Let’s consider a real-world attack where attackers were able to abuse data from open sources and recent data breaches, such as Equifax and other smaller ones, to create ~$25k in credit card charges

Someone I know was directly affected by a breach in security controls through data gathered through Open Source Intelligence ([_OSINT_](https://en.wikipedia.org/wiki/Open-source_intelligence)) and likely information purchased on the dark web obtained through data breaches.

We’re going to call this person Candice (fake name to protect the innocent). One day, Candice opens her credit card statement and notices that there's ~$25,000 on the card that she didn't spend and a new account was added.

Candice and I did a little research, and here’s what we think happened.

Candice is your average consumer. She turns on multi-factor authentication (MFA) for her banking accounts when it is required and she is also moderately successful at using different passwords for each of her accounts.

Like many of us, Candice’s information, including her Social Security number, was exposed in the Equifax breach and some smaller breaches. She probably also re-used her password elsewhere. With some [_credential stuffing_](https://auth0.com/blog/credential-stuffing-is-a-persistent-threat-to-your-users/), where attackers use previously breached passwords on other sites in an attempt to gain access, attackers were likely able to gain the first step of authentication but were not able to get past the multi-factor authentication challenge.

However, with a little extra OSINT to obtain her address, phone number, age, family members, pets’ names, etc., the attackers were able to build a whole profile on Candice and use it for social engineering and identity theft. Armed with the right combination of details about Candice, attackers were able to bypass the security controls enforced by the bank through customer support. The bank eventually flagged the fraudulent charges and, luckily, Candice’s credit ended up fine.

As a savvy user of the internet, it is always a best practice to consider the information that you share could be used for other purposes. For example, some Facebook memes included lists of first or important life events, such as “where did you first meet your spouse.” This is a gold mine of OSINT for attackers that are trying to access websites that still use security questions as additional factors.

Each individual will need to consider their own threat model on the information they share. It isn’t easy to anticipate where OSINT data can be collected and how it could be abused, and this is where developers come in as first defense. As Vanderbilt University James Hazel told the Business Insider [_in this excellent piece on anonymized DNA data_](https://www.businessinsider.com/privacy-security-risks-genetic-testing-23andme-ancestry-dna-2019-2), "Data is data — once it's out there, it's very hard to control." Treating user data as a liability protects your users by making it more difficult to obtain and be used maliciously in other places you might not expect.

<include src="TweetQuote" quoteText="Real-world example: Equifax breach + smaller breaches + OSINT = ~$25K+ credit card charges. Find out how @auth0’s security-minded approach to user data design could have helped."/>

Back to our geofencing problem. Let’s say your company wants to know the following information:

- **Adoption rate:** how many people are using the application in the store

- **Conversion rate:** whether a person used the app and then went to the store within a certain period

There are a lot of inputs available to answer these questions:

- GPS location
- Nearby WiFi
- Nearby Bluetooth
- IP Address
- Unique ID of the device
- User ID
- Items searched
- Timestamp

We could store all of this data as a single record and send it to the server every time the user logs in the app. If the record is within the geofence, we can process whether or not it was a conversion and increase the adoption count. This seems like a lot of information for a couple of reasonably simple questions (resist that feeling of “but we may need this data in the future”). Don’t forget to call in compliance and security on this one. In other words, we’re carrying a lot of ballast in this ship.

Instead, what if we stored a record that included the following in the client application:

- `lastLogin` (timestamp)
- `inGeofence` (boolean)

These two data points represent the condition whether the user within the geofence the last time they logged in. To determine if the user is within the geofence, our application would store the geofence boundary and request permission to use location services when it is running. In this case, we don’t really need to save the `lastLogin` or `inGeofence` information on the server, we can store it temporarily and use it to determine whether the next request is a conversion.

> Side note: Let’s acknowledge that client-side calculations are not always appropriate, make sure to consider your threat model.

When the user logs in to the application, the application can check the previous `inGeofence` record as well as calculate a new one. Then, if the user is within the geofence, the application could send the following to the servers:

- `uniqueId` (random string)
- `isConversion` (boolean)

UniqueId would serve as a way to uniquely identify our new data point. In this case, we could choose to use a random string.

`isConversion` is inferred as true if the last login was not geofenced and occurred within our specified timeframe. We’ll increment our adoption count as aggregated data based on the number of unique requests. We have managed to take rich real-time user data and only transfer and persist the results that we want to measure. We have accomplished our business needs while minimizing risk, and can follow this same process when new features are needed. This process will help us purposefully select the data that we need rather than use whatever we can collect.

The design scenarios that you encounter will likely be much more complex than the geofencing example above. Consider the following user data security principles to kickstart the discussion on your next project remembering that each piece of user data you collect is a liability:

- Clarify your objective and identify the minimum amount of data necessary to meet it

- Design the use of data in your applications to address only the specific need

- Consult compliance, security, and privacy experts on your data choices

- Transfer and store aggregated, calculated or inferential data over raw user data

 - **Aggregated:** adoption count vs sending the user’s identifying data

 - **Calculated:** `inGeofence` vs sending the user’s GPS location

 - **Inferential:** `isConversion` vs sending the user’s login history, timestamp and GPS location

- Resist the urge “because I might need it”

- Consider how the data could be abused when combined with other sources, such as what happened to Candice

<include src="TweetQuote" quoteText="Treat data as a liability. Find out how designing for only the data you need can protect your end-user and your company."/>

On your next design, take the engineering challenge of minimizing user data just like you would consider scalability or performance. Throughout the design process sometimes you won’t be able to reduce your user data liabilities. At a minimum, incorporating the security principles above helps you identify those liabilities and handle them appropriately (some boats need a lot of ballast just to stay afloat). The next time you are ready to “ship it”, check your ballast and you will be better prepared for rough waters. If you'd like to learn more about how Auth0 can help you securely collect only the authentication and authorization data that you need, please reach out to an [_Auth0 resource._](mailto:%20sales@auth0.com)

<include src="asides/AboutAuth0" />

Avoid Sinking Your Code by Treating Data as a Liability

brandon-maxwell

Brandon is a Senior Security Engineer in Auth0's Detection & Response team. As a proponent of automation, he enjoys automating as many tasks as possible to spend time focusing on solving difficult security problems.

Senior Security Engineer

Brandon Maxwell

Learn how Auth0 uses security automation to generate phishing response at scale

Phishing continues to be a popular attack vector used by attackers with all sorts of motivations — from [_political_](https://www.fireeye.com/blog/threat-research/2019/03/apt40-examining-a-china-nexus-espionage-actor.html) to [_financial_](https://www.wired.co.uk/article/hr-email-scam-phishing-impersonating-employees) ones. According to Verizon’s [_2019 Data Breach Investigations Report_](https://enterprise.verizon.com/resources/reports/dbir/), 32% of the investigated breaches involved phishing. Most organizations deal with this threat on an almost daily basis, which makes automating the triage for these events an important part of maturing a security program.

In this post we talk about the approach Auth0 has taken to automating phishing in the hopes that it will help other organizations tackle this near-universal threat vector.

## phishing@auth0.com

Auth0 uses the email address `phishing at auth0 dot com` as an "abuse" inbox. We encourage customers and members of the public to report any suspicious Auth0-related emails they receive to this address. In addition, all Auth0 employees are trained to report suspicious emails they receive to this abuse inbox.

In Auth0’s infancy, every email that was sent to the abuse inbox was analyzed manually. A security engineer would review the email body and headers, copy URLs from the body of the emails and analyze them in various intelligence tools, and upload suspicious attachments (or their hashes) to various sandboxes. If the reported email represented a real threat, a remediation process was performed.

This worked great; however, as Auth0 started to grow, the volume of reports to `phishing at auth0 dot com` increased. Email analysis work became time-consuming and was detracting our attention from other higher-impact activities. In other words, it was a perfect use-case for security automation.

## Security Automation

At Auth0, we rely heavily on security automation to ensure we’re not wasting valuable cycles performing repetitive, manual tasks. We partner with the [security automation company Tines](https://tines.io/) in this regard. Every alert from our detection stack, whether it’s from SIEM, GuardDuty, or custom tooling we’ve built, first goes through Tines where it is enriched, prioritized, and ticketed. We also use Tines to automate phishing responses.

## Automated Phishing Response

For the most part, our automated phishing response story maps directly to our previous, manual process and consists of the following high-level steps:

1. Fetch email data and extract indicators
2. Create tracking tickets
3. Analyse indicators
4. Determine if the email represents a real threat
5. Close case if benign
6. Remediate if true positive

### Step 1: Fetch email data and extract IOCs

The first step is to read all emails sent to our abuse inbox. We do this with GSuite’s Gmail API. Once we have the email content, we can extract all URLs and attachments and begin to analyse them. We also recursively open and extract Indicators of Compromise (IOCs) from EML files attached to the originally reported email.

![Flowchart to fetch email data and extract IOCs](https://images.ctfassets.net/23aumh6u8s0i/4kB2PfHEaRZZswUn4bRU6M/d71c7ec982dcde9f05fd943244b2ed13/how-auth0-automates-phishing-response_3Afetch-email-data-and-extract-iocs)

### Step 2: Create tracking tickets

We track and record every single email that’s reported to our abuse inbox in our case management system. Not only does this allows us to track the volume of emails reported over time, but it also allows us to store indicators for future reference and later threat-hunting.

### Step 3 - Analyze indicators

One of the key benefits of automating analysis of indicators is that we can leverage many different intelligence sources without having to worry about wasting an analyst’s valuable time. In our phishing automation story we analyse URLs in:

- VirusTotal
- Urlscan.io
- URLhaus
- PhishTank
- Phish.AI

> **Protip**: When submitting URLs to public sandboxes, remember to first [_redact sensitive information_](https://tines.io/blog/automated-information-leakage/) from URL parameters and never submit links that could be used to reset passwords, etc.

Tines allows us to easily add and remove intelligence sources and experiment with different combinations of sandboxes, without having to change the core flow of the automation story.

![Flowchart to analyze indicators](https://images.ctfassets.net/23aumh6u8s0i/4XqCWGvVyGwl1ttZ140Y7C/8d4b825d58a6cf9b2f4e89089cdf2758/how-auth0-automates-phishing-response_3Aflowchart-to-analyze-indicators)


### Step 4: Determine if the email represents a real threat

Once we have analysed a URL or attachment in all the various intelligence sources and sandboxes, we use the combined results to determine whether the URL represents a legitimate threat and should be remediated/escalated to a human engineer or whether it’s a false positive and we can ignore it. There’s some secret sauce involved in making this determination and we regularly change the criteria used as our requirements adapt.

### Step 5: Close case if benign

If we have determined that all indicators associated with an email are benign, we update the ticket in our case management system and no further action is taken.

### Step 6: Remediate if true positive

If, however, we have determined that the reported email represents a real threat, we perform a number of automated remediation actions. Again, these actions change regularly but include the following:

- Purge the email from all employee inboxes
- Sweep endpoint logs to determine if any employees visited the malicious domain/URL, or downloaded/executed a malicious file
- Proactively share indicators with trusted peers in the InfoSec community
- Quarantine the devices we believe may have been infected
- Contact users who visited and/or interacted with malicious content and provide them with the next steps needed to mitigate any damage
- Reset potentially compromised credentials

Again, for every step that’s taken, evidence is collected and added to the relevant ticket in our case management system. This ensures a complete paper trail is available for every action that’s taken.

## Summary

Security awareness, email sandboxes, and strong multi-factor authentication all play a part in our *defense-in-depth* approach to phishing response. However, an abuse inbox, where employees and customers can report suspicious emails, is an indispensable resource, providing vital insight into on-going and emerging phishing attacks.

By automating triage of our abuse inbox, our security engineers can focus on higher-impact activities such as threat hunting and refinement or detection logic.

<include src="asides/AboutAuth0" />

How Auth0 Automates Phishing Response

A security researcher claimed that an attacker could perpetrate a phishing scam that could target a company using the Auth0 platform based on domain. Learn about this attack, the prevalence of phishing in the industry, and how to mitigate these scams.

A security researcher working for another company recently published a blog post stating that they could potentially perpetrate a phishing attack targeting users of a website that uses Auth0 authentication. Note that phishing is not the same as hacking a code vulnerability, and therefore, no software patches can be applied because no flaw exists in Auth0's system. Let’s explore the mechanism behind this theoretical phishing attack, the prevalence of social engineering scams in today’s tech industry, and what companies and their users can do to better protect themselves.

## What is Phishing?

[Phishing](https://www.csoonline.com/article/2117843/phishing/what-is-phishing-how-this-cyber-attack-works-and-how-to-prevent-it.html) is a type of social engineering cyber attack that has been around since the 1990s and is still extremely prevalent today. Phishing typically begins with email. Emails are sent to target individuals, and these emails contain links or attachments that have malicious intent: either to install malware on the user’s device, or get them to enter sensitive data into a website that masquerades as legitimate.

Phishing attacks are [growing increasingly sophisticated](https://www.menlosecurity.com/blog/from-your-account-is-deactivated-to-oauth-the-evolution-of-phishing) in the modern landscape of the internet, and the intent is to deceive people into providing protected information, often credentials. Regardless of sophistication, however, the premise of phishing is still very straightforward.

Consider this sequence of events, for example:

1. A user of Service A (`service-a.com`) is sent an email that appears to be from Service A. The email tells the user they need to log in using a link in the email.
2. The user clicks on the link, which takes them to a login page at `malicious-service-a.com` (_not_ the real website at `service-a.com`).
3. The page has been styled to look like a legitimate page from Service A, so the user enters their credentials into the login form.
4. The credentials have then been given to the attacker, who can now access the real Service A with the victim’s stolen login information. In addition, due to the common practice of [password reuse](https://www.troyhunt.com/password-reuse-credential-stuffing-and-another-1-billion-records-in-have-i-been-pwned/), the attacker may even have access to other accounts that the victim holds on other sites.

This is just one possible example of a phishing scam flow. The attacker could just as easily ask for other kinds of personal information, or request that the user download a malicious email attachment.

## Phishing with Auth0 Subdomains

The specific idea behind the security researcher’s phishing scam was a way to target a website that uses Auth0 authentication. Auth0 supports regional subdomains: `auth0.com`, `eu.auth0.com`, and `au.auth0.com`. A bad actor could potentially attempt to scam users of a website or application that uses one of the subdomains by registering any of the other regional subdomains while using the same name. The attacker could then set up a custom page on their subdomain and, _assuming that they had access to the email addresses of users_, send them a link and attempt to solicit secure information from them. Similar scams could be attempted using _any_ domain that users could mistake for a legitimate one.

<a href="https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)">Cross-Site Scripting, or XSS</a>, was not used in the exploration of a phishing attack that could use Auth0 regional subdomains to trick users. [XSS describes the injection of malicious scripts into a vulnerable web application](https://www.incapsula.com/web-application-security/cross-site-scripting-xss-attacks.html). This exploration relied on using a custom Auth0 page in a subdomain in another region, but [no malicious cross-site code could be injected](https://auth0.com/docs/hosted-pages#why-use-hosted-pages). The ability to include JavaScript in custom pages is a feature available to Auth0 customers to enable necessary flexibility. However, _cross-site code_ cannot be executed from these pages.

## This Attack is Not New and Not Unique

As stated previously, phishing attacks have been around for decades: almost thirty years, in fact. They have become more sophisticated and insidious in their execution, but they rely on tricking people into divulging confidential information: these kinds of attacks are referred to as <a href="https://en.wikipedia.org/wiki/Social_engineering_(security)">social engineering</a>. In these scams, it is common for malicious actors to use domains that look very similar to the target domain to make their phishing attempt more convincing. This is still true now, as well as historically.

> "It's unclear why the researcher used Auth0 as a common example of phishing targeting Auth0. There are no vulnerabilities here and their research doesn't show anything new. It is simply another example of possible phishing. The same could be done with the `anycompany.com` website by using a look alike domain and then setting up a login page same as this one `https://www.anycompamy.com/Login`."
>
> –Cesar Cerrudo, globally recognized security expert and CTO at [IOActive Labs](https://ioactive.com/)

**No company that has users with email addresses is impervious to phishing scams.** There are thousands of ways to perpetrate the [same kind of phishing attempt](https://auth0.com/blog/all-you-need-to-know-about-the-google-docs-phishing-attack/) [on any company](https://www.justice.gov/usao-sdny/pr/lithuanian-man-arrested-theft-over-100-million-fraudulent-email-compromise-scheme), aside from Auth0, [making the attacks quite prevalent](https://www.tripwire.com/state-of-security/security-data-protection/three-quarters-organizations-experienced-phishing-attacks-2017-report-uncovers/) in the tech industry.

## Phishing Relies on Tricking Users

[Phishing is not the same as hacking a code vulnerability](https://blog.varonis.com/whats-difference-hacking-phishing/), and therefore, no software patches can be applied because no flaw exists in Auth0’s system. The particular phishing attack described by the security researcher is not being actively used. Auth0 provides security measures to help prevent credential harvesting via phishing, such as [Single Sign-On](https://auth0.com/docs/sso/current), [Multifactor Authentication](https://auth0.com/learn/get-started-with-mfa/), and [Passwordless](https://auth0.com/passwordless). In addition, [Breached Password Protection](https://auth0.com/breached-passwords), [Brute Force Protection](https://auth0.com/docs/anomaly-detection#brute-force-protection), and [Anomaly Detection](https://auth0.com/docs/anomaly-detection) can help mitigate the potential outcomes of phishing attacks. Auth0 also supports the use of [Custom Domains](https://auth0.com/docs/custom-domains), which removes `auth0.com` (or regional `auth0.com` subdomains) from your application and replaces with a domain of your choosing, which completely eliminates the ability of an attacker to perform this scam using Auth0 subdomains.

However, it is important to remember that **phishing scams are quite common and easy to execute if an attacker already has your users’ email addresses**. Although using an Auth0 Custom Domain or registering all regional Auth0 subdomains eliminates the attack avenue described in this specific case, an attacker could still register any other Top Level Domain name that is similar to yours and attempt to deceive your users. For example, if your company’s login domain is `login.real-company.com`, a phishing attack could be perpetrated from a similar domain, such as `login.rea1-company.com`. In addition, a bad actor could just as easily send a malicious email attachment to your users instead.

## Protecting Your Company and Users

The safety of companies and their users should be the paramount concern when discovering and sharing information regarding security. Not committing to thorough research can negatively impact customers, users, and the general technology community.

Any company implementing authentication of any kind — proprietary or using an Identity and Access Management platform such as Auth0 — should have security practices in place to mitigate phishing attacks. These practices should include regular internal anti-phishing campaigns and training, as well as Multifactor Authentication or Passwordless. Monitoring for lookalike domain names is also recommended. With the proliferation and increasing cleverness of phishing scams, the importance of awareness and training cannot be understated.

Phishing Attacks with Auth0? Facts First

Learn how responsible disclosure of a cybersecurity vulnerability made the risk mitigation process safe for Auth0 customers and vendors.

On October 5, 2017, security company [Cinta Infinita](http://www.cintainfinita.com) contacted Auth0 to report a vulnerability in our Legacy Lock API ([CVE-2018-6873](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6873)). Cinta Infinita discovered the issue while conducting independent research. In specific cases, Cinta Infinita was able to bypass password authentication when logging into Auth0’s Management Dashboard by forging an authentication token. After verifying the vulnerability, we responded immediately, pushing a patch to our cloud service within four hours of initial notification. Our engineers then worked around the clock to patch our Private SaaS Appliance customers over the following two weeks.

During our investigation it became clear that the vulnerability was a special case of a deeper structural problem. The attack exploited an underlying Cross Site Request Forgery (CSRF/XSRF) vulnerability ([CVE-2018-6874](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6874)). CSRF vulnerabilities are a common structural flaw when embedding a login widget into a web application due to the nature of cross-origin authentication (one of the reasons we’ve been pushing for [Universal Login](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/)).

To fully remediate this issue and protect our customers, we needed to make a significant change to our [Lock login widget](https://auth0.com/lock) and its [supporting library](https://auth0.com/docs/libraries/auth0js/). Unlike the fix for the special case discovered by Cinta Infinita, this issue could not be solved without forcing our customers to upgrade the libraries/SDKs on their end, a much more significant undertaking.

We worked with Cinta Infinita to allow us time to address the issue prior to their public release. Neither party wanted the vulnerability to be exposed for a lengthy period of time, so we agreed on an aggressive schedule that still provided ample opportunity for all of our customers to upgrade.

With Cinta Infinita’s support on the timing, we moved forward with a strategy to mitigate the vulnerabilities by rewriting the affected libraries and releasing new versions of our SDKs (auth0.js 9 and Lock 11). This was an all-hands-on deck effort that included our Engineering, Customer Success, and Security teams as well as many individuals from across Auth0. Our goal was to provide a seamless upgrade. We achieved that for customers who were on Lock 10 and auth0.js 8.

We launched a multi-touch communications plan to all customers announcing the deprecation and removal of the vulnerable endpoints, giving them notice to migrate to the new SDKs. Customers on Enterprise plans were contacted and given the opportunity to speak directly with the Security and Professional Services teams to work out individually tailored migration plans.

Understanding that the upgrade would be cumbersome for many customers, our Engineering team continued to work on the underlying issue and was able to develop a mitigation strategy that could be implemented on the server side. This strategy not only decreased the burden to our customers, it also significantly reduced the <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Verifying_Same_Origin_with_Standard_Headers">severity rating of the API vulnerability</a>. This occurred three weeks before planned public disclosure.

With server-side mitigations in place for our Cloud Customers, users are now much better protected even prior to migrating to new software versions. Due to the heavily downgraded severity, we are able to provide customers with three additional months to upgrade, with the **vulnerable endpoints removal of service now taking place on July 16, 2018 instead of April 1, 2018**.

<include src="TweetQuote" quoteText="Due to the heavily downgraded severity, vulnerable endpoints removal of service now taking place on July 16, 2018."/>

Security is a top priority at Auth0, and we’ve invested heavily in building up our program over the last year.

* We have implemented a new Secure Software Development Lifecycle process that encompasses all new development efforts.
* All of our developers take part in regular secure development training.
* We have embedded Product Security engineers into the various engineering teams to focus on the internal code and processes, while building out our Application Security team to focus on external interfaces and component security.
* We perform regular penetration tests and code reviews executed by industry-leading third parties, as well as automated vulnerability and component security scans.

With these people, processes, and tools in place, a project to review and refactor our code base is already underway. This project will make the introduction of vulnerabilities even more unlikely in the future.

<include src="TweetQuote" quoteText="Security is a top priority at Auth0, and we’ve invested heavily in building up our program over the last year."/>

Vulnerabilities are a part of life in software development. We would like to thank Cinta Infinita, an excellent partner in this process. Cinta Infinita has worked responsibly with us to protect our customers. We encourage anyone to report potential vulnerabilities to us through our [Whitehat responsible disclosure program](https://auth0.com/whitehat). We take all such reports very seriously as part of our commitment to providing the best security for our customers.

Migration guides are available to help customers upgrade to [auth0.js version 9](https://auth0.com/docs/libraries/auth0js/v9/migration-guide) and [Lock version 11](https://auth0.com/docs/libraries/lock/v11/migration-guide).

If you have any questions or feedback, please reach out to us. You can contact your CSM, open a [support ticket](https://support.auth0.com/), or chat with us in the Auth0 community forum on the [deprecations roadmap topic](https://community.auth0.com/t/upgrade-reminder-changes-to-deprecation-roadmap/9552 ) and the [migrations FAQ topic](https://community.auth0.com/t/april-1st-migrations-deprecations-faq/9723).

"mitigation"