Nabeel-Saeed

Nabeel is a product marketer focused on all things security and identity. He has contributed to publications like Wirecutter, Information Age, and Professional Security. He has also been a guest speaker at the Bay Area Cybersecurity Meetup, and delivered talks on IAM across the US, Canada, Israel, and Singapore. He is passionate about helping build secure auth experiences that amaze users and delight businesses.

Product Marketing

Nabeel Saeed

New feature provides real-time monitoring of potential identity security events and threat response efficacy

Okta Customer Identity Cloud (powered by Auth0) today announced the general availability of Security Center, a new feature that helps enterprise customers optimize their identity security posture by leveraging insights from Okta Customer Identity Cloud to provide a single view of authentication events, potential security incidents, and threat response efficacy. It includes real-time data on companies’ current state of attack protection, out-of-the-box threat monitoring on major identity attack vectors, and application-level visibility into authentication traffic.

Determining whether an organization’s identity security posture is too restrictive or too lax is not trivial. Customers currently need to parse through logs 3rd party tools or build their own, which requires expert-level experience to effectively identify attacks and be ready to respond to them. Security Center provides an improved way to visualize this type of data directly from the Okta Customer Identity Cloud. 

Security Center leverages Okta Customer Identity Cloud security insights to provide CISOs, Security Operations Professionals, and Identity teams a faster way to detect and respond to identity threats. It provides a streamlined view of authentication events, potential incidents, and threat response efficacy, allowing them to optimize their security posture without having to risk their bottom line after going through the learning curve themselves.

![Attack Protection](https://images.ctfassets.net/cdy7uua7fh8z/2hyZMfdrGwVZxKtuV4ZOR3/f1795066d12eb02550da8f4eb0f00fd5/Threat_Behavior.png)

“Accurate detection alone doesn’t ensure threat response is appropriate to the level of risk, given other business objectives like customer acquisition, retention, and growth,” said Jameeka Aaron, Chief Information Security Officer, Customer Identity at Okta. “As attacks against identity flows get more sophisticated and evolve to bypass detection, security teams often have to go through a learning curve on their own production environments, which can mean delayed detection of attacks and consequent business losses. Security Center leverages our focused expertise in identity security and packages it in a way that security operations professionals can understand and take action.”

Account takeover attacks targeting everything from sensitive healthcare data to loyalty points are one of the most common and costly cyber threats. Verizon’s 2022 Data Breach Investigations Report (DBIR) found that 80% of corporate breaches involve compromised identity solutions*. Security Center takes the work out of building your own tooling to identify and be able to respond to identity threats in a timely manner. Customers can understand their identity security landscape with summary visualization of major attack types, authentication events, and threat monitoring.

Security Center also allows companies to measure user experience impacts of Attack Protection features. Consumer-facing apps must balance security with user experience by minimizing friction while maintaining appropriate protection against identity attacks. Security Center shows app owners in near-real time UX effects of defense tactics, allowing them to adjust security and friction as appropriate to their situation. Companies can fine-tune their attack protection strategy by seeing in near real-time how defense tactics like MFA, rate limiting, and CAPTCHA affect their applications.

Security Center is available for all Enterprise customers. Learn more about implementing Security Center [here](https://auth0.com/docs/secure/security-center).

### About Okta

Okta is the World’s Identity Company. As the leading independent Identity partner, we free everyone to safely use any technology—anywhere, on any device or app. The most trusted brands trust Okta to enable secure access, authentication, and automation. With flexibility and neutrality at the core of our Okta Workforce Identity and Customer Identity Clouds, business leaders and developers can focus on innovation and accelerate digital transformation thanks to customizable solutions and more than 7,000 pre-built integrations. We’re building a world where Identity belongs to you. Learn more at [okta.com](https://www.okta.com/).


Okta Customer Identity Cloud Adds Security Center to Enterprise Plan

johnathan-campos

Johnathan Campos is a Senior Product Marketing Manager at Okta focused on platform infrastructure and scalability. Johnathan is responsible for helping customers and partners understand the value of the Okta platform. Prior to joining Okta, Johnathan was a Senior Product Marketing Manager of the Observability Practitioner team at Splunk. During his time at Splunk, he helped practitioners understand the details of why Observability is the new necessary for native cloud deployments. When not focused on platform infrastructure and scalability, John enjoys tinkering in his garage, learning new things, spending time with family, and is an avid motorcycle fan.

Senior Product Marketing Manager, Global Platform Service

Johnathan Campos

With our new UK Region, we can enable local subscribers to achieve compliance and benefit from the quickest login response times available.

**TL DR;** The UK joins our available public cloud regions across EMEA to help with compliance requirements, data residency, and performance for our subscribers based in the UK.

We are thrilled to announce the launch of our newest region across our Customer Identity Cloud (Powered by Auth0) service in the UK. This new offering will provide a high-performance and secure way to manage customer identities while helping subscribers comply with UK data privacy regulations. As our first public cloud region on our converged platform architecture, this brings the latest cloud-native design and employs cutting-edge tools and fully automated operations to enhance business agility, developer productivity, scalability, reliability, and security for both our subscribers and platform teams. We encourage you to check out our blog series [here](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/) to learn more about our converged platform, and if you want to double-click even further on architecture, check out this blog [here](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/) by my colleague, Leonardo Zanivan.

This public cloud region is also a major milestone in supporting UK customers with data residency needs. UK-based data centers will enable subscribers to store their data within the UK, helping ensure compliance with UK regulations for those that need it. This is particularly important for businesses that operate in heavily regulated industries, such as finance or healthcare, where data residency requirements can often be strict. To choose their preferred location, subscribers can easily select from a menu when creating their new tenant where the UK is now available. 

![UK](https://images.ctfassets.net/23aumh6u8s0i/7oWDzK3Dj7HVHwHlQ8XuoV/4f01fd4cb8bdaa926b07ab83c9009419/UK.png)

In today's constantly connected environment, where numerous users - from staff to customers - need access to mobile applications, websites, APIs, and portals from any location and device, we are proud to provide our subscribers with an IDaaS solution that delivers the essential scalability, reliability, and accessibility organizations require. Our goal has always been to simplify identity management for developers and IT professionals worldwide. 

With the new launch, users in and around the UK can experience reduced latency while logging in and solve many challenges faced with data privacy regulations. Don't hesitate to contact us for any questions or help regarding the newly launched UK Region. We are always here to help!

The UK Joins Existing EMEA Regions for Public Cloud Deployments!

500x500

I'm a software engineer, but I prefer to call myself Technology Bishop. Spreading knowledge through writing is my mission.

Software Engineer

Antonello Zanini

Learn why you may need custom error responses on 4xx errors, what a good custom format looks like, and how to apply it to your error responses in Express.

How To Implement Custom Error Responses in Express

Chitra Dharmarajan

A motivated CyberSecurity professional with a specialization in IIOT, Cloud Application & Infrastructure Security, Web Application Security, Product Security, and Solutions Architecture. An innovative technical leader, who has efficiently managed cross-geographical teams to successfully deliver Secure Development Lifecycle, Incident Management, Penetration Testing, Product Development & Release Management initiatives. Excels in translating strategic objectives into actionable plans and solving complex problems while delivering high-quality business results. 

Senior Director, Product Security

Confirmation that no action is needed for Auth0 customers

On July 19, 2022, a security consultancy firm released a blog post with claims related to the security of specific features for the Okta service. The areas of concern highlighted by the security consultancy firm are not vulnerabilities specific to the Okta service. Refer to the [Okta blog](https://www.okta.com/blog/2022/07/okta-response-to-security-report/) in response to the security report for further details. Product & Security teams at Auth0, an Okta product unit, conducted a thorough review and determined that the risks in the referenced report do not apply to the Auth0 product.  

To use SCIM with Auth0, our customers are expected to contact professional services to securely configure and deploy custom SCIM solutions as referenced [here](https://auth0.com/docs/authenticate/protocols/scim).

Additionally, Auth0 enforces HTTPS in all Auth0 controlled data transfer channels. 

### What to do if you are an Auth0 customer

At this point, no action is needed for Auth0 customers. We advise the following best practice recommendations, which you should consider in the context of your specific configuration.

1. Always use HTTPS to ensure the secure transmission of data.
2. Enable MFA for all user accounts. MFA should be enforced for all dashboard users that have privileged tenant access. Auth0 encourages all users, not just admins, to require MFA on their accounts.
3. Utilize Auth0’s [Dashboard Role-Based Access Control](https://auth0.com/docs/get-started/manage-dashboard-access/feature-access-by-role) to provide finer grain access controls to dashboard users. 
4. Perform periodic [access reviews of dashboard role assignments](https://help.okta.com/oie/en-us/Content/Topics/Reports/admin-role-assignments-report.htm) and ensure access is limited to authorized personnel.
5. Monitor and periodically review the actions performed by dashboard users recorded in [the tenant logs](https://sec.okta.com/articles/2022/06/unlocking-mystery-700-okta-system-log-events).

If you are an Auth0 customer who is looking for security best practices, you may find additional information in these links:

- [https://auth0.com/docs/secure](https://auth0.com/docs/secure)
- [https://auth0.com/docs/customize/rules/rules-best-practices/rules-security-best-practices](https://auth0.com/docs/customize/rules/rules-best-practices/rules-security-best-practices)

Auth0 Response to Security Report

jameeka_aron

Jameeka has over 20 years of Information Technology and Cyber Security experience. She is a versatile leader, successfully leading teams as both a CISO and CIO across various industries including; Aerospace & Defense, Apparel, Retail, and Manufacturing at both Fortune 100 and privately held companies and many spaces in between. <br>
She is highly skilled in Business Engagement (International and U.S. based) Audit, Compliance, Vulnerability, Risk and Identity Management, Digital Transformation, Mergers, Acquisitions, Divestitures, and leading Cross-Functional and Matrixed teams.

CISO

Jameeka Aaron

CISO Jameeka Green Aaron on Auth0’s actions around this insidious vulnerability

On Thursday, December 9, 2021, a vulnerability in the Java logging library Log4j was disclosed and assigned the CVE ID [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228), also nicknamed Log4Shell. The Cybersecurity and Infrastructure Agency (CISA) also released an [alert](https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce) on the 10th of December.

This is an incredibly serious vulnerability that has had security teams in every industry on high alert, working around-the-clock to ensure that their systems are secure. At a high level, Log4J allows Remote Code Execution (RCE) on an affected server, granting an attacker full control. A detailed explanation was published by [LunaSec](https://www.lunasec.io/docs/blog/log4j-zero-day/).

Security is our top priority at Auth0 and we recognize the critical role our platform plays for our customers. Since the vulnerability came to light, Auth0 teams across Engineering, Product, Customer Success, and Security, led by our Detection and Response team have been all hands on deck to evaluate any potential impact on our platform. This is one of the most dangerous vulnerabilities that our industry has seen and we have treated it with that level of seriousness. It also has the potential to be very widespread and takes time to methodically review code and systems. We started with our most critical assets and worked outwards, gaining more assurance as we progressed.

As we stated in our tweet last [weekend](https://twitter.com/auth0/status/1470086301902721024), we did not see direct impact then, nor do we now, after continuous assessment and monitoring. We can confirm that there were no signs of exploitation, and the Log4j library is not used in our core service code base. 

Auth0 does use a very small number of third-party components that were vulnerable to Log4Shell. We have been working closely with our partners throughout the incident response process, firstly to apply patches as soon as they are released, and secondly to identify if they could have been used as a potential path to compromise our service. Again, our review has not shown any signs of abuse from the vulnerability.

The speed of response from our teams and our existing security architecture was essential here. Using our existing security tooling, we were able to scan our entire code base and containers for the affected library and quickly get assurance that we were not affected. We also deployed WAF rules on our edge for an extra layer of protection and then focused our efforts on assuring our supply chain. Finally our Red Team has been trying to actively use the vulnerability against the Auth0 platform, further increasing our levels of assurance through offensive testing.

This vulnerability is very serious. We recommend that all of our customers continue to closely review and monitor their own systems and third-party components for the vulnerability and any signs of compromise. And critically make sure you are running the latest versions of any impacted software (please see [Okta’s blog](https://sec.okta.com/articles/2021/12/log4shell) for details of the impact to the Okta products).

Subsequently other vulnerabilities have been reported in Log4j ([CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) and [CVE-2021-45105](https://nvd.nist.gov/vuln/detail/CVE-2021-45105)) and we expect there to be more as the library gets further attention from security researchers. We will continue to closely monitor and investigate the situation, and provide prompt notification if the situation changes.

Auth0’s Response to Log4J

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Why Naranja and Wabi turned to Auth0 to ensure identity expertise and scaling

The market in Latin America is growing faster than ever, with new venture capital deals nearly doubling to 488 between 2017 and 2020, according to [Bloomberg](https://www.bloomberg.com/news/articles/2021-03-16/latin-american-startups-had-record-venture-capital-deals-in-2020). Beyond VC, a [study by IDB lab](https://publications.iadb.org/publications/english/document/Tecnolatinas-2021-The-LAC-Startup-Ecosystem-Comes-of-Age.pdf) revealed that the tech-enabled startup market hit a valuation of more than $220 billion USD in 2020.

![LATAM](https://images.ctfassets.net/23aumh6u8s0i/Gz6t31FLxbPc7r8T996gE/caed742f057acf90192df17560dbf527/Latam11.jpg)

Globally, the pandemic has [accelerated digital road maps across industries](https://auth0.com/blog/how-brick-and-mortar-approaches-improve-digital-experiences/) and businesses now have to respond to changes in digital expectations and buying patterns.
<include src="QuoteCard" body="Companies cannot predict exactly what their business and customers will need tomorrow, especially in response to today’s rapidly changing digital environment." name="Gabriel Camargo" title="Product Director" team="" company="CLM" />

Partnering with [CLM](https://auth0.com/blog/auth0-expands-global-partner-network-in-latin-america-with-clm/) on distribution in Latin America (LATAM) extends Auth0’s reach into Brazil, Colombia, Ecuador, and Peru.

Over the years of working within Latin America, we’ve learned that [identity expertise](https://auth0.com/blog/building-an-identity-solution-quantity-doesnt-equal-quality) and [scalability](https://auth0.com/blog/can-your-identity-solution-grow-with-your-company) are two critical areas of concern for businesses in the region. You can check out our earlier posts in this series for details, but here, we wanted to look more closely at how we were able to help two companies within the region.

## Naranja — From Leading Credit Card Issuer in Argentina, To Complete Consumer Ecosystem

[Fintech leader Naranja](https://auth0.com/case-studies/naranja/) has been providing credit cards to the Argentinian market for over 30 years. In that time, they’ve grown to cover over 5 million customers by keeping those customers’ needs their top priority. As they grew, Naranja also began to integrate additional verticals into their business model. Pretty soon, they were offering payment services, financing, travel, media, and other services beyond their credit card programs.

As they added these verticals, Naranja’s head of engineering Javier Voos soon realized they would need to consolidate their identity solution to cover all aspects of their growing ecosystem. He knew that in order to continue putting the customer experience first, they would need to find the right IDaaS provider that would be able to scale along with their planned expansion.

[link to video](https://www.youtube.com/watch?v=kqouiuVk07Q&feature=emb_imp_woyt)

<iframe width="560" height="315" src="https://www.youtube.com/embed/kqouiuVk07Q" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

<include src="QuoteCard" body="The main idea behind the Naranja ecosystem is to provide the best experience to our customers, making sure that our digital platform provides all the resources that an online business needs for success, and hence support the ecosystem evolution." name="Javier Voos" title="Head of Engineerin" team="" company="Naranja" />

Voos’ priority was to find a platform that provided secure APIs for identity so they could focus their expansion efforts on B2B services alongside their expanded consumer offerings. Finding Auth0 meant that his team could implement one identity solution that would allow both B2B and B2C customers access to the platforms they needed access to while ensuring data privacy and a low-friction user experience.
<include src="QuoteCard" body="Auth0 gave our company the tools to secure the access to our API for first- and third-party consumers, in a way that can scale through time and put us in a better position to ally with new partners and work our way to a fully functional Naranja API Market." name="Danilo Asis" title="Solution Architect" team="" company="Naranja" />

## WABI — South America’s E-Commerce Portal

With a half-dozen offerings already on offer, [WABI](https://auth0.com/case-studies/wabipay/) is looking to the future. Their ambitious goal is to become Latin America’s go-to e-commerce portal. Their offerings already include WABI, a smartphone-based grocery service; Wabipay, an e-wallet app; and four additional applications. The end-goal WABI envisions is for customers to log in one time and have access to a complete, end-to-end e-commerce experience. They’ll be able to shop, pay, and track delivery all in one place.

Juan Manuel Mingo, former WABI Business Manager, sums up the hurdle they faced when it came to identity and customer authentication, “We had different platforms with different user registration processes,” he says. “Our aim was to unify all the user registration of the different platforms in order to get a better user experience and to have a more organized user database.” The disjointed customer experience was the first thing WABI knew they would have to solve before they could continue growing and expanding their e-commerce ecosystem. 

<include src="QuoteCard" body="Our endgame is that you enter the ecosystem through Wabi. You log in to Wabi, order your things, and when you want to pay, you simply go to WabiPay, and you’re already logged in." name="Frederico Galli" title="General Manager" team="" company="WABI" />

Like Naranja, WABI has always had a customer-first attitude. That meant that customer-facing features like single sign-on were top priorities. As Frederico Galli stated, their endgame is for customers to sign in once and have access to the entire ecosystem of WABI offerings. Not only that, but with further expansion plans in the works, they needed an identity solution that was with them for the long haul. Juan Manual Mingo put it like this, “WABI is scalable, and we need a partner that is, too. We believe Auth0 will support us in getting there.”

![LATAM](https://images.ctfassets.net/23aumh6u8s0i/P45m9X6Z8ag9oOTv8R4kW/cc92f6325cb89fd84f233aa6c6992218/Latam12.jpg)

## Learn how Auth0 can help your business

[Argentinian talent Eugenio Pace and Matias Wolowski](https://www.forbesargentina.com/editorial/la-increible-historia-auth0-cliente-us-27-quinto-unicornio-hoy-vale-us-1100-n1352) founded Auth0, so we know the ins and outs of the South American market. When you’re ready to bring your identity solution in line with your broader organizational expansion goals, reach out to our [market experts](https://auth0.com/contact-us) to start the discussion about how we can help.

<include src="asides/AboutAuth0" />

LATAM Response to Rapid Digital Change

T025590N6-U48JV4JQ3-c1e97676ac13-512 avatar

T025590N6-U48JV4JQ3-c1e97676ac13-512

General Counsel

Jeremy Freeland



## Schrems 2 Ruling 
The European Court of Justice (ECJ) ruled on July 16, 2020, that the EU-US Privacy Shield framework is no longer valid as a means of ensuring adequate protection for transfers of personal data from the European Union to the United States, on the basis that US national security requirements do not meet EU privacy standards.
 
Importantly, the ECJ also decided that the Standard Contract Contractual Clauses (SCCs) are a valid transfer mechanism.
 
The ECJ deferred to national EU data protection supervisory authorities to determine the lawfulness of transfers to countries such as the US where the ECJ has determined there is a conflict between national laws and EU data protection laws.
 
This post advises Auth0 customers who process EU personal data of the likely immediate effects of the Schrems 2 decision on their use of the Auth0 Platform.
  
## European Customer Data is Stored in the EU 
Unless a European customer has opted to establish its Auth0 tenant(s) in an AWS region outside the EU, the data of Auth0's European customers is stored on AWS infrastructure located in the AWS EU region (Germany, with failover to the Republic of Ireland). This means that this data is not transferred out of the EU – in other words, the Schrems 2 decision has no effect on this data, and customers will not need to make any changes. This applies both to Auth0's public cloud customers and private cloud customers.
 
As disclosed in our contracts with our customers, Auth0 conducts some limited processing of personal data outside the EU. This involves:

* _Management dashboard:_ For public cloud customers, Auth0 may temporarily process tenant data in the US for display on the Auth0 Management Dashboard. Dashboard web servers are located in the US. This data is not automatically transferred but is only served up when a tenant dashboard administrator requests it for viewing. When this occurs, the data itself is ephemeral, is not permanently stored on these systems, is fully encrypted during transit, and is only used to display information on the dashboard to the requesting administrator. This data can include any information that can be viewed through the Auth0 Management Dashboard, which typically includes the user's e-mail address or other UID and basic metadata about that user, such as creation date, last login time, user agent, and the identity provider used. Note that this dashboard processing occurs within the AWS region the customer has selected for its tenant for private cloud customers.
 
* _Support tickets and logs:_ If a customer includes personal data in a support ticket, then this may be viewed by Auth0 support personnel outside the EU. In order to resolve the ticket, Auth0 personnel may review activity logs to help understand the underlying error. Personal data in those logs typically consists of a user ID (e.g., e-mail) and IP addresses. 
 
## Auth0's DPA has Triggered the SCCs 
For transfers of personal data from the EU to the US, the SCCs will now apply.

Auth0's form of Data Processing Addendum (DPA) anticipates the invalidation of the EU-US Privacy Shield framework as a transfer mechanism. Under Section 6.1 of the Auth0 DPA, Auth0 and customers who are a party to the DPA have agreed that the SCCs will apply in these circumstances. Thus, although Privacy Shield has been invalidated, transfers by Auth0 of European customer personal data are now subject to the SCCs.

Although the DPA contemplates that no further action should be required for the SCCs to apply, we expect to post a pre-signed set of SCCs for customers to countersign early next week. Auth0 customers looking for additional assurance beyond the DPA may use this method to apply the SCCs to transfer their data.

## Next Steps
This is an evolving situation, and we will be monitoring developments closely. In particular, we expect the cloud service provider sector to consolidate on an approach to the invalidation of the EU-US Privacy Shield framework over the coming weeks. We expect national EU data protection supervisory authorities to begin to communicate their position on determining the lawfulness of transfers to countries such as the US, where the ECJ has determined there is a conflict between national laws and EU data protection laws.
 
We will update this blog to reflect key developments – please check in regularly.

<include src="asides/AboutAuth0" />


Schrems 2 – EU-US Privacy Shield Ruled Invalid

eugenio-pace-new-avatar

Pace co-founded Auth0 in early 2013 with CTO and “brother-in-arms” Matias Woloski while living 7,000 miles apart from each other. Since then, Pace has played an instrumental role in growing Auth0 into a leading identity management company that is loved by developers and trusted by global enterprises. He loves traveling and has visited more than 35 countries for business and pleasure. He currently lives in Redmond, Washington with his wife, two sons, and their labrador retriever. In his spare time, he enjoys the outdoors, rowing, riding bikes, spending time with his family, restoring his 1970 Karmann Ghia, writing his blog, and reading history and philosophy.

CEO and Co-Founder

Eugenio Pace


At Auth0, we care deeply about ensuring that our employees, customers, partners, and their families are safe. This does not change during times of uncertainty, it only becomes a stronger commitment. We also know that Auth0 provides critical functions for all of our global customers, and we hold our responsibility with the utmost business ethical importance.

In light of COVID-19, Auth0 is taking all necessary precautions to conduct and maintain business-as-usual during this tumultuous time. We are closely following guidelines set forth by national and local government agencies, and have internally put actions into place to ensure our employees limit their risk of exposure. 

Auth0 has maintained a Business Continuity Plan for many years that details steps for comprehensive action in the event of any emergency or crisis – including this pandemic. This plan is reviewed and updated regularly. This pre-planning enables us to be vigilant and focused no matter the circumstances, and provides concrete action to ensure the security of our business and customers. 

One of the biggest disruptions being felt at the moment across the world is the transition to remote working. Thankfully, Auth0 has been designed as a remote-centric company since our inception in 2013 (Matias Woloski and I were building the business while living 7,000 miles apart), and we have a robust and tested infrastructure in place to support a fully-remote workforce for all 650+ Auth0 employees, if need be. This ensures that every employee and team is able to operate at the same level of responsiveness and service that our customers are used to. 

Additionally, intentional cross-training of staff means that there will always be more than one person to handle key tasks or escalations without any disruption to our customers’ business. From an infrastructure perspective, all of our primary services are cloud-based and should not be impacted by COVID-19, ensuring that the same level of performance, innovation, customer support, and partnership will be maintained regardless of how long we are impacted by this virus.

Finally, we have prepared an [FAQ](https://info.auth0.com/coronavirus-customer-FAQ.html) that contains answers to a range of questions. If the answer to your question isn’t included, then please contact us directly at [bcp@auth0.com](mailto:bcp@auth0.com) and we will help find it. We are ready to tackle any challenge with our customers and will always put our extended team first. 

These are not easy times, but that’s why we prepare for them. We are deeply committed to taking care of our employees, customers, and partners, especially in times of uncertainty like these. 


Business Continuity at Auth0: Our Response to COVID-19

alejandro-ortuno

Alejandro is a Security Engineer in Auth0's Detection & Response team with a passion for automation and the cloud. Initiated as a software developer, he has experience working on AppSec, network security and cloud security for startups and enterprise companies such as Cisco or Rackspace. He spends his spare time learning newer technologies, playing padel and breaking things.

Security Engineer

Alejandro Ortuno

Discover how Auth0 uses security automation to respond to GuardDuty events at scale and our learnings in the process



Cloud adoption is occurring at a rapid pace and so are the risks and challenges in maintaining those secured environments. Doing it at scale requires the extensive use of automation and tooling. DevSecOps methodologies can also be applied to the detection and response of threats, decreasing the time to respond and preventing potential breaches. Logging pipelines, Slack bots, orchestration tools, and serverless technologies empower operation teams in a way that traditional security operations centers (SOC) can’t. Services such as AWS GuardDuty provide indispensable threat detection to continuously monitor for malicious activity and unauthorized access on cloud resources.

At Auth0, we have embraced the cloud since our inception, and with cloud resources in numerous AWS accounts in our organization, strong defenses and timely response to security events in the cloud are an absolute priority for us. That is why our Detection and Response team has embraced technologies to automate the response to security events in the cloud to scale for our [future organizational growth](https://techcrunch.com/2019/05/20/auth0-billion-dollar-unicorn/).

In this blog, we will provide an overview of the implemented architecture for the alert analysis, triage, user notification, and automated response of the AWS GuardDuty security findings on all of our AWS accounts.

## AWS GuardDuty Service

[_Amazon GuardDuty_](https://aws.amazon.com/guardduty/) is a threat detection paid service that continuously monitors for malicious activity and unauthorized behavior on AWS accounts and workloads. The service consumes CloudTrail, VPC Flow, and DNS logs and then enriches them with threat intel from AWS and other third-party services (such as CrowdStrike). GuardDuty also uses machine learning techniques to detect malicious activity on an AWS account. The service is regional (needs to be enabled on a per-region basis) and has a 30-day free trial. GuardDuty findings, if any, will start populating just a few minutes after the service is enabled.

At Auth0, we enable the GuardDuty service at account creation in all regions. Configuration follows a [_master/member_](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html) setup where every new AWS account becomes a new member of the master GuardDuty account.
From there, a combination of regional CloudWatch event rules and AWS Lambda functions ships all GuardDuty events into our security information and event management (SIEM) system.

We also monitor the health of this ecosystem closely as any failure would mean a critical gap in our alerting systems. As an example, we monitor specific [_GuardDuty API calls_](https://docs.aws.amazon.com/guardduty/latest/ug/logging-using-cloudtrail.html) (such as `Disassociate`, `StopMonitoring`, `DeleteDetector`, and many more) that could tamper with our infrastructure resulting in a page notification to our team.

Also, we have subscribed to the [_GuardDuty Announcements SNS Topic_](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_sns.html) and integrated the alerts with our bot, so we get Slack notifications when there are new GuardDuty findings or updates to the existing ones that require our attention.

## SecurityBot

At Auth0, we rely heavily on Slack as our main communication channel. On top of it, [we have created Slack Bots](https://auth0.com/blog/auth0-internal-dev-tools-unleashing-engineering-potential/) that can automate our common tasks and help us scale and better respond to security events.

One of those bots is the SecurityBot, developed by the Detection and Response team on top of our Security Orchestration, Automation, and Response (SOAR) system. Auth0’s SecurityBot was inspired by the awesome work of the security teams at both [_Slack_](https://slack.engineering/distributed-security-alerting-c89414c992d6) and [_Dropbox_](https://github.com/dropbox/securitybot).
The SecurityBot helps us in two main tasks:

- As a ChatOps function, we can ask the bot to create an incident response channel, add all necessary members to it, initiate the documentation for an incident, or perform an investigation on specific IPs and Domains.

- As our main channel to communicate with employees. The bot can send notifications or inquiry messages (that require a confirmation) to our employees, ask for MFA confirmation, or even page our team if an employee responds negatively to a specific event.

![A message notification from SecurityBot](https://images.ctfassets.net/23aumh6u8s0i/3heWkQLOzq6ehvjVSDE5a1/967048353b36f46ce89be46c3ea7be00/a-message-notification-from-securitybot)

## AWS Incident Response Tool (aws-ir)

Especially important when dealing with an incident is to have a timely response. For that reason, our team has developed an internal tool to make investigation and response on AWS a much easier and repeatable task.

AWS IR is an API built on a serverless infrastructure that allows our team to take necessary forensic artifacts and response options on a specific machine in any of our AWS accounts. Those actions are mainly:

- Take a snapshot of the instance volume.

- Run a set of [_osquery_](https://osquery.io/) commands.

- Take a memory dump.

- Take a `tcpdump` of the network traffic.

- Isolate an instance.

We have integrated this tool with the response to GuardDuty events so we can collect artifacts and perform response actions depending on the severity of the alerts.

## The Hive Project

Keeping records for the actions taken and the artifacts collected is sometimes a “boring” but necessary task to do while performing a response to an incident. [_The Hive Project_](https://thehive-project.org/) is our main ticketing and artifacts collection platform that we use to perform our investigations.

We rely on its APIs to create alerts, promote them to cases, and to upload the artifacts that we automatically collect.

## Automating the Response Like a Pro

Now that we have explained all the different elements that compose our architecture let’s see how we glue them together.

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, Phishing, or custom tooling we’ve built, first goes through Tines where it is enriched, prioritized, and ticketed. We also use Tines to automate the response to the GuardDuty alerts.

One of the most common observations after enabling GuardDuty is that it can be daunting at the beginning and that it requires a significant amount of time to tune it to make it serviceable for your environment. Let’s take a look at a few examples of what this tuning looks like and some associated caveats:

### Network Load Balancer: Port Probe Alert False Positives 

Receiving a GuardDuty event of an instance which have a random port that is being probed by a malicious IP from the internet can be concerning. But the story changes if the instance has no public IP, and is behind a load balancer which has port 443 open to the internet. The reason for this is that the Network Load Balancer, by default, offers "Source IP Preservation" and the source IP addresses of the clients are preserved and provided to your backend applications. This is documented in the following [_public article_](https://mysteriouscode.io/blog/dont-panic-false-positives-from-guardduty-and-network-load-balancer-nlb/) as well. Later we will discuss how we have overcome this limitation when making changes on the load balancer is not an option.

### Alerting on harmless customer provided domains

If your service takes or ingests domains supplied by your customers and queries them (as is the case for us), GuardDuty can flag some of this legit activity as malicious. We encountered false positive "Backdoor and Trojan" alerts that happened due to customers providing flagged domains into our service.

### Detecting anomalies while employees are on the move

Machine learning is great, and we definitely believe in this technology for detection purposes (we want to further expand on this technology for our own sake). Still, it doesn’t cope well on a remote-friendly company where employees are on the move, continuously changing their locations and source IPs.

### GuardDuty events for already terminated EC2 Instances

We have received GuardDuty events where the instance state is “terminated” (this information is contained on the GuardDuty event). On an ephemeral infrastructure where instances are spun up and torn down on demand, and there are no long-running services, this can limit our capabilities to respond to incidents or to perform live investigations.

### Visibility gaps in cloud environments

There is a lack of visibility for Digital Forensics and Incident Response (DFIR) with GuardDuty for containers/microservices, especially if they are running on the same EC2 instance. Alerts will come from the same EC2, and additional logging/tooling will be needed to respond to those alerts.

<include src="TweetQuote" quoteText="Learn how to tune GuardDuty to make it serviceable for your environment and the associated caveats."/>

So let’s dig deeper into how we have automated the response for those GuardDuty findings and overcome some of those challenges. We have grouped the different GuardDuty events and their responses mostly into four different categories:

1. EC2 PortProbe alerts

2. IAM User non-critical alerts

3. IAM User critical alerts

4. EC2 Other alerts

Let's go over the response for each of them.

## PortProbe Alerts

The first group of alerts involves inbound port probing, which means potentially malicious IPs probing ports that are open on the internet. We do have PortProbe type of events (_Recon:EC2/PortProbeUnprotectedPort_) and also SSH and RDP brute force events included in this group.

Initially, we filter out common ports that we know are open and are commonly attacked (for example, port 443). Also, as mentioned before, we do not want instances that are behind a network load balancer to trigger events if the load balancer is opening common ports such as 443. For that reason, we have built an [_AWS Step function_](https://aws.amazon.com/step-functions/) that maps network load balancer ports against instance ports and dumps this information on a DynamoDB database. From Tines, we query the database to filter out alerts on instances behind a network load balancer from which the listening port is 80 or 443.

![AWS Step function to collect network load balancer information](https://images.ctfassets.net/23aumh6u8s0i/6ApTwxb12qBo36xQ3tlpVc/a22e10551f48604894d5ef8326394160/aws-step-function-to-collect-network-load-balancer-information)

Finally, if the event is not filtered and has not been notified before, we send a notification via SecurityBot to the resource owner (based on Instance tags).

## IAM User Non-Critical Alerts

In this group, we cover GuardDuty `IAMUser` events that we have deemed non-critical. These events typically suggest suspicious API calls made by AWS principals. Our main action with those alerts is to first automatically determine the mapping of the Principal to an employee and their endpoint machine. From there, we check their device IP and compare it to the IP in the alert. If there is any mismatch, we trigger a SecurityBot Inquiry message to ask the employee for confirmation that they made the AWS API call.

![SecurityBot Inquiry Message](https://images.ctfassets.net/23aumh6u8s0i/3urYXdOgk6xG4F2nOp2L1B/53a2bf233268ff3b2f95a9c14ee28ab2/securitybot-inquiry-message)

## IAM User Critical Alerts

In this group, we cover the GuardDuty IAMUser events that we have deemed critical, and as such, they trigger a PagerDuty alert to our team. These events include modification to CloudTrail, password policy changes, credential exfiltration, or the [_latest S3 specific alerts_](https://aws.amazon.com/about-aws/whats-new/2019/10/amazon-guardduty-adds-three-new-threat-detections/) among others.

We also enrich the alerts with the following information:

- List of employees seen under the same offending IP over the last 24 hours

- CloudTrail API calls made by the offending IP

## EC2 Alerts

Within this group, we have the following event types:

- EC2 Outbound network connection

- EC2 DNS request

- EC2 PortScanning

There is an important filtering layer that we needed to implement for our network scanner, and also for services that query customer provided domains which caused false positives to trigger. We initiate the AWS Incident Response tool to collect specific artifacts on the instance so we can better perform timely forensics investigation on the machines.

<include src="TweetQuote" quoteText="Dig deep into how Auth0 has automated the response to GuardDuty events and the associated challenges."/>

## Conclusions

We have no doubt as to the incredible value and visibility the AWS GuardDuty service provides to our team. Enabling it is incredibly simple, and we have decided to include it on each of our AWS accounts.

Automating our response to the GuardDuty alerts has helped us focus on what is important to us, filtering out some of the noise it generates and customizing it to our environments. We have evolved from processing hundreds of GuardDuty events per week (that would completely consume our team’s time to review and respond to these alerts) into just a few events per week needing our manual review. To add to this, with SecurityBot, we empower our employees to provide valuable real-time data relating to potential security incidents, making them aware of the alerts and also adding them to the front line of our security team.

For future work, we will continue to improve the automation for our incident response process. We also want to include other sources of information into our alerts, such as the events provided by agents like [_osquery_](https://osquery.io/) or information specific to containers and Kubernetes infrastructures. On top of that, we will expand our threat model to include attacks vectors such as compromised employee machines, malicious insiders, etc.

<include src="asides/AboutAuth0" />


Guardians of the Cloud: Automating the Response to Security Events

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

sam-judson

Former Auth0 Employee

Samuel Judson

Duo Security announced the discovery of a new class of SAML response vulnerability affecting SSO. Auth0 is not vulnerable to this issue.



On February 27, 2018, [Duo Security](https://duo.com) announced the discovery of a new class of vulnerability affecting SAML-based single sign-on systems. This flaw can allow an authenticated attacker to fool SAML systems into logging in as a different user, even without knowledge of the victim’s password. Note that this type of attack can be prevented by Multi-Factor Authentication, even if software used is vulnerable.

Malicious impersonation of this type can have a broad range of risks, including (but not limited to) compromising the victim as well as the system. An attacker could potentially impersonate a user with greater permissions, as well as elevate their own privileges.

Researchers from [Duo Labs](https://duo.com/labs), Duo’s security research team, identified several vendors affected by this class of vulnerability. You can read more information on SAML, details of the exploit, and affected vendors in Duo’s announcement here: [Duo Finds SAML Vulnerabilities Affecting Multiple Implementations](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations).

## Auth0 is Not Affected by the Vulnerability

As [cited in Duo’s disclosure](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations), all three of the following items are needed in order to enable this vulnerability:

1. SAML Responses contain strings that identify the authenticating user.
2. XML canonicalization (in most cases) will remove comments as part of signature validation, so adding comments to a SAML Response will not invalidate the signature.
3. XML text extraction may only return a substring of the text within an XML element when comments are present.

The library that Auth0 uses internally to parse SAML responses prevents the third requirement for exploitation. This prevents the vulnerability being exploited when  Auth0 is used as a SAML Service Provider (SP).

## Am I Affected?

Auth0 is not vulnerable to this issue, therefore, Auth0 customers do not need to take any action if using Auth0 as a SAML SP. However, if you are using Auth0 as a SAML Identity Provider (IdP) and are _processing SAML responses in your own code_, you will need to verify whether the libraries you are using are vulnerable as per [the original disclosure from Duo](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations). If you are using a vulnerable library, you must ensure that **any affected software is updated to patch the vulnerability**.

Auth0 provides the [passport-wsfed-saml2](https://github.com/auth0/passport-wsfed-saml2) Passport strategy as open-source software. This strategy is **not vulnerable** to this SAML security vulnerability reported by Duo. If you or your company are using this strategy, you do not need to take any additional action.

If you have any further questions or concerns, please [open a support ticket](https://support.auth0.com/) or [ask in our community forum](https://community.auth0.com/).


Auth0 Not Affected by SAML Vulnerabilities Identified by Duo Security

667b1c82b6cc2241ff176d50c65da603?s=200 avatar

667b1c82b6cc2241ff176d50c65da603?s=200

Guest Author

Eugene Kogan

Security is a challenge at most startups. Here's some advice on how to create a data breach response plan for the worst case scenario, a large-scale data breach.



A serious data breach can have massive negative repercussions for any organization, including the loss of customers, revenue, reputation, even intellectual property. For a startup, it can mean the end of your business. 

## Security for the Lean Startup

Unfortunately, startups are often completely unprepared to deal with a major security incident that involves a breach of sensitive data. Unlike larger, more mature organizations, startups have no choice but to be lean and spend their limited resources carefully. Startups are also worth much less than bigger companies, and all of their energy is focused on growth and proving a business model. So it’s no wonder that they tend to spend less time and money on issues like security, let alone data breach response.

On the other hand, no one wants to see their fledgling company go out of business because of a security breach. So how much time and money does it make sense for a startup to invest in preparing for a breach? I think of planning for the worst as somewhat of an insurance policy. You hope that a data breach doesn’t happen to your company. You put some effort into preventing one through reasonable security controls. But just in case something goes wrong (like if that small security incident suddenly becomes a breach of your credit card database) you want to be prepared.

Now that I’m responsible for security at Auth0, issues like this are increasingly on my mind. It’s my first time working at a startup, having spent the last 15 years working security at huge organizations like AT&T, Amazon.com, and the US Department of Defense. These folks are seriously prepared for anything, from a laptop with malware to a major natural disaster. But when you join a startup, you quickly learn how to pave the road as you’re driving it. Auth0 is a rare startup, since security has been a core part of our business from day one. But even for us, it can be hard to find enough time to plan for unlikely (yet potentially devastating) scenarios like a data breach.

## Data Breach Response Plan is sort of a Big Deal

Let’s assume your startup has enough valuable intellectual property, a growing user base, and increasing amounts of customer data. It’s likely that you’re already dealing with security incidents on a regular basis. You have a decent incident response plan that is sufficient for the common security issues that small companies face, and it’s probably not a big deal to quietly take care of these in-house.

A data breach is not a run of the mill security incident. What I’m talking about here is a major “oh crap” moment when you realize your entire user database was posted on Pastebin, along with those passwords you meant to [hash](https://crackstation.net/hashing-security.htm) with something better than SHA-1 but didn’t quite get around to doing. (It’s ok, we’re a startup, right? No! Bad startup! That’s what [Auth0](https://auth0.com) is for.)

## Planning for the Worst

So how would your company respond to such a breach? Do you know the legal requirements for notifying your customers? Should you contact law enforcement? Who do you call first and how long can you wait? Every data breach is different, so I’m not going to attempt to provide specific answers to these questions. A lot will depend on how big your business is, how many users were impacted, where they live, what kind of data was lost, and so on. 

** My goal is to help startups prepare for a data breach and to come up with a simple response plan without spending too much money. **

For a small company trying to respond to a major security incident like a data breach, the best thing to do is to ask for help. It’s just not practical or realistic to have all the necessary expertise in-house, at least not until your business can justify having a very large (and expensive) information security organization.

** I recommend having the following relationships in place _before_ you need them: **

* Cyber liability insurance
* Legal council with data breach experience
* Public relations (PR) firm with data breach experience
* Incident response (IR) and digital forensics consulting firm

Having these vendors under contract prior to an incident occurring is critical. I hope it’s obvious why you’d want cyber insurance in advance, just like you’d want car insurance before getting into an accident. But there are several good reasons for lining up the rest of your response network in advance. First is the issue of timeliness. It takes time to negotiate a contract with a new vendor, even at a startup. But when you’re responding to an incident, you don’t have any time to spare. You’re already late! Also, a lot of the best vendors will be booked up for weeks in advance, working for their current customers. If your plan is to call an IR firm and hope that they can come help you later today, you will be sorely disappointed (or shocked by how much they want to charge you).

## The Costs Involved

Speaking of cost, there are ways to help reduce the upfront expense of being prepared while simultaneously reducing the cost of an eventual response. Lawyers are expensive, and I don’t have any tips on fixing that problem just yet. So pick a good lawyer with a track record of working on major data breaches, and sign a contract to have him or her on a retainer. You should be able to do this without paying much (or anything) up front.

A public relations firm will be a major asset when it comes time to communicate with your customers. The way a company handles a data breach in the public eye can have a huge impact to how people react. You want to provide just enough details but no more, be accurate so you don’t have to issue a correction later, and take responsibility when appropriate. A PR firm with experience in dealing with data breaches will be able to help you get the right message across. That can go along way to mitigating the damage to your reputation and hopefully reducing the number of lost customers. Once you have a PR firm finalized, it may be worth paying them to draft up some boilerplate press releases for potential breach scenarios, just to save time later on.

Something to keep in mind is that even if you already have a PR firm that your startup uses for standard PR needs, they might be totally clueless when it comes to security incidents. You need to ask them the right questions to find out. If your current firm isn’t up to speed, it’s worth having a second PR firm on board just for breach response. Remember, you want to take responsibility for what happened and be honest in your communications, so don't let anyone try to talk you into denying everything or shifting blame.

## Using an Incident Reponse Firm

Do you really need an external IR firm to help you respond to a data breach? If you’re a startup, the answer is almost definitely _yes_. First of all, it’s unlikely that you have a security team with deep technical expertise in digital forensics. You need that expertise to be certain that the cause and extent of the breach has been accurately identified. And if you can’t be sure of that, then you can’t be sure the breach has been fully contained. This is especially true if the cause is an intentional intrusion by an attacker, who may be actively evading your response efforts. For a serious breach that involves law enforcement, you’ll be grateful to have security consultants with LE backgrounds helping you out.

Even with a team of experts, there is never a 100% guarantee that everything has been found and cleaned up. But you stand a much better chance of doing this correctly if you engage an experienced IR firm. Also, when it comes time to do a press release, having a well-known firm on your side will help your users feel like you’re taking the incident seriously.

When choosing an incident response firm, reputation goes a long way. The firms with better reputations attract better talent, at least on average. As always, it pays to ask around for recommendations from people you trust. The bigger firms are generally all decent, and will have several advantages over the smaller firms. First, all major firms offer a zero cost retainer option, so you can sign a contract and have them ready to go without spending any money upfront. Second, they will probably be quicker to respond than a smaller firm, simply because they have more consultants available at any given time.

Another advantage bigger firms have (not just IR, this goes for PR and legal as well) is their breadth of experience. This can be especially important if your startup has customers in foreign countries with strict privacy laws or notification requirements, or if you’re using a complex or niche technology stack. Is your product built with OpenBSD, Scala, and Spark, hosted on Oracle’s cloud? You should probably make sure the IR firm has people with experience using those technologies. Startups tend to be on the bleeding edge and most security consultants simply can’t keep up.

## You Need Insurance

Up until now I’ve mostly avoided talking about cyber insurance, partially because I hate the word “cyber.” But the reality is that every significant business should have some cyber liability coverage to help absorb the financial burden of a large-scale data breach. You will need a policy that’s tailored to your company, its projected growth, and the risks associated with your industry.

The first step to getting cyber insurance is to find a knowledgeable broker. It pains me to say this, since we techies generally don’t enjoy dealing with middlemen like brokers, but that’s really the only way to go at this point (until a startup comes along and successfully disrupts this model). Again, ask your industry peers for recommendations on a cyber insurance broker, and don’t assume your regular business insurance guy will know anything about this stuff. If you start this process with the wrong broker, you may end up with an inappropriate policy that will fail you when it comes time to file a claim.

Selecting a cyber insurance policy should actually be one of your first steps, once you have a clueful broker and a basic incident response plan in place. The reason for this is that almost all agencies will have a list of approved vendors that you’re strongly suggested to use in the event of an incident. They have pre-negotiated rates with these vendors, and they are (allegedly) vetted and deemed competent. It’s usually possible to get an exception to use a vendor that’s not on your insurance agency’s list, but that means jumping through more hoops to get them approved. If you go down this road, your broker should help you out and provide advice. So if you have a particular PR or IR firm in mind that you really want to work with, you should let your broker know before you start shopping around for a policy. I don’t recommend signing any contracts until you are sure that your cyber insurance policy will allow you to work with the vendor in question. This includes legal council and other vendor categories that I haven’t even mentioned, such as credit monitoring and notification service providers.

## The 8-Step Plan

** Here’s my recommended action plan for getting your startup in a good place, ready to respond to a large-scale data breach: **

1. Think about security, work on improving it, and have a decent incident response plan.
1. Document some potential data breach scenarios that your company might face, including the kinds of data that might be impacted, the number of users you have, where they’re located, and so on.
1. Contact a few cyber insurance brokers, ideally from trusted recommendations. Pick one who is knowledgeable and willing to work with startups.
1. Work with your broker, CFO, and security team to find a policy that meets your requirements.
1. Be aware of the agency’s approved vendor list, and ask for exceptions (if you have any in mind) before buying a policy.
1. Carefully select vendors to help you in case of a breach. That includes at least legal, PR, and IR firms.
1. Sign a contract with these vendors so that they are ready to help you respond at a moment’s notice. Go for zero cost retainers if that makes financial sense for your business.
1. Review all of the above as your startup grows and changes over the year. If your revenue explodes, you will need to increase your insurance coverage sooner rather than later.

<include src="TweetQuote" quoteText="Think about security, work on improving it, and have a decent incident response plan."/>

You can never be too prepared when it comes to security. So what are you waiting for?


"response"