Introducing Dynamic API Scanning
Application environments are more complex than ever, with APIs forming the critical connective tissue. But this proliferation has created a vast, often invisible, attack surface. …
Victor Arellano
Not everything on your attack surface is a vulnerability. Every organization has their own internal security policies that align with the risk tolerance of their business context. While industries like SaaS are often deploying several daily releases to production from multiple geographies, other industries might not tolerate this level of risk due to internal or external factors like complex regulatory requirements. This means that every company has a unique set of internal security policies that requires a solution to be flexible and resilient, something that didn’t exist until now.
But how do security teams validate that their internal security policies are being followed? In this article, we’ll cover how you can set up your first Attack Surface Custom Policy, other custom policies for you to try, and what’s ahead for this new feature.
Setting up your first Attack Surface Custom Policy is simple and should only take you a few moments. We are using “IF-THEN” logic which many security teams are accustomed to when working with rules-based systems.
And that’s it! When a policy is created, we will start monitoring any changes to your attack surface and create an alert if the conditions are met by any asset. We do not assess if these conditions are currently met by your attack surface. If you want to see that, you can do so on Surface Management, on the Attack Surface view by filtering on ports.
If you’re responsible for security in your company, then you know how useful it is to have clearly-defined security policies that are simple to implement, scale, and verify. Product and AppSec teams know that great security policies empower teams to work autonomously so that work moves forward as it should. But, it’s not always clear which Attack Surface Custom Policies you should set up. So, we’ve added a brief list of Attack Surface Custom Policies that we think every security team should set up.
Please note that Surface Monitoring is required to access Attack Surface Custom Policies. If you’re not using Surface Monitoring, check in with your CSM or book a demo to try it.
This Attack Surface Custom Policy ensures that any other port will end up in the alerts list and can be verified by the security team.
You’ll now receive alerts in the tool if any ports other than 80 or 443 become open after you create this policy.
This Attack Surface Custom Policy ensures that you can catch any open ports that your security team has decided should not be open. For the following example, we’re using ports that are often used for relational databases.
Today, security teams can use Attack Surface Custom Policies on open ports. In the coming weeks, we will begin rolling out additional functionality. Future improvements include scoping custom policies to specific domains, technologies, and much more. If you’re interested in trying Detectify, book a demo or sign up for a 2-week free trial and start testing your web apps with Detectify today.
Application environments are more complex than ever, with APIs forming the critical connective tissue. But this proliferation has created a vast, often invisible, attack surface. …
The average organization is missing testing 9 out of 10 of their complex web apps that are attacker-attractive targets. To address this, we’re launching new …