Figuring out and minimizing your attack surface

Once you have something worth stealing, attackers are likely going to start probing your defenses. Usually, the first step is mapping out what kind of digital presence your product has and whether you have appropriate safeguards in place. This post will focus on your product’s attack surface and email protections.

An attack surface is defined as the total number of possible entry points for unauthorized access into any system. This can be a lot for a typical SaaS company running in the public cloud with a fully remote team. Having a smaller or larger attack surface isn’t necessarily a bad thing. It’s all about risk and knowledge.

The key here is that you have the knowledge of what’s out there and can then make a risk-based decision about whether to do something about it. But it definitely makes life easier if you have a smaller attack surface because you spend less effort protecting that smaller surface.

Things to think about include public-facing URLs, public-facing IPs, anything that would bypass a load balancer, management ports like SSH, DNS entries, open S3 buckets, and the list can go on. The more of this out there, the more you have to think about protecting.

Let your team know the importance of not making everything publicly available for ease of use. If the service is meant for internal company uses only, then try to restrict it in a way where only company users can access it.

Basics to get started? Ask your team. It sounds painfully manual, but asking the simple question “what’s on the public internet” will at least start the conversation. Check your DNS records for more hints. Lean on open-source tools to see what attackers can see about you, such as DNS Dumpster, Knock, or Subfinder. Also, check out Project Discovery which develops a collection of related tools and the Attack Surface OWASP Cheat Sheet. There are a lot of fun free tools out there to help with this. Documenting the endpoints or services that can be reached from outside will bring more into the known, which will then let you make decisions on what to protect and how to protect it.

Close down or restrict anything that’s not necessary for business or may present a larger risk such as management ports. Don’t forget about direct IPs to the services you run. While a customer may go through a CDN and load balancer, an attacker may still be able to find the direct IP of the web server itself. And being specific to AWS, public-facing RDS instances and S3 buckets set to public access are ripe targets. Remove any services that aren’t being used because it’s just more effort to protect.

What’s next? Automate the scanning with scheduled jobs or by using a commercial option. Tools like Subfinder can hook into the APIs of commercial tools to provide merged search results across different vendors’ intelligence. Set these up to alert you at the end of the week when there’s a change. Something looks strange? Maybe that new test service was accidentally exposed to the internet.

What does Kinde do? We occasionally run the open-source tools DNS Dumpster, Knock, and Subfinder to see what attackers can see about us. There’s also been quite a bit of discussion internally about how we ensure that non-production services aren’t directly accessible from the public internet, so the mindset is to block public access by default.

Email is critical to how a brand communicates to the world. Sales intros, newsletters, and support messages are just a few of the many types of emails that will go between companies and customers. The unfortunate side is that scammers are also trying to send emails pretending to be you, known as email spoofing. Protect your brand by implementing the open standards SPF, DKIM, and DMARC on your DNS to help prevent spam and attacks like phishing and business email compromise. I’ve added in references from two players in the market that have good info related to this.

Sender Policy Framework (SPF) is used to authorize a mail server to send emails on your company’s behalf. More info from Dmarcian and Postmarkapp.

DomainKeys Identified Mail (DKIM) creates a signature on the email being sent so that a receiving email service can verify who the original sender actually is. More info from Dmarcian and Postmarkapp.

Domain-based Message Authentication Reporting (DMARC) is used to create rules around how to deal with emails that fail authentication checks in SPF and DKIM, such as putting mail into the junk folder or blocking outright. More info from Dmarcian and Postmarkapp.

Basics to get started? All three of the recommended settings need someone who can access your DNS records and has information from your mail service. I’m linking in guides from Google Workspace and Office 365 since they’re the most common for customers we come across. For record generation and verification, MXToolBox has a great set of tools to help. While SPF and DKIM can be set straight out of the box, DMARC should be phased in slower by working your way through the policy settings from monitor to quarantine to reject.

What’s next? A few of the vendors referenced can provide monitoring services to check how many spam or phishing emails are being sent out. This requires DMARC to be set up with at least the “ruf” and “rua” settings enabled. Large providers such as Google and Microsoft will send DMARC reports and failures to those addresses for reporting. Analyzing the reports is a lot easier with a tool, such as one from MXToolBox. If you have the budget or need, you can have these reports sent to a third party for automated analysis and advice on how to improve the results.

What does Kinde do? At the time of writing, we’ve implemented both SPF and DKIM based on recommendations provided by Google and validated using the MXToolBox reports. We’ve set DMARC to quarantine with 100% of messages being included in the policy. We’re holding off for now on setting it to reject until some more of our product gets built out to ensure that we don’t accidentally break system messages being sent.