Introducing Attack Surface Custom Policies
If you’re responsible for security, 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. However, validating that your security policies are actually implemented is difficult. Many Product and AppSec teams struggle to either validate or scale their security policies, like enforcing security headers or removing risky technologies. And their teams are feeling the pinch.
In a recent live survey at our Hack Yourself Stockholm event, 67% of respondents reported that they introduced only a few minutes in their development pipelines to check for vulnerabilities before code hits their production environment. When asked how similar their staging and production environments were, 78% claimed that they were either partially or completely different. This reflects a growing trend within the AppSec community that what is in production is really the only thing that matters.
To address these challenges, we’re thrilled to announce Attack Surface Custom Policies – a powerful new feature built directly into Surface Monitoring that makes it possible to set, enforce, and scale customizable security policies so you can focus on the issues that matter most.
How do you know if security policies are being followed?
New Internet-facing assets are coming online at an unprecedented rate, partly because of an increase in cloud-hosted technologies, shorter development lifecycles, and the occasional forgotten subdomain from a past marketing campaign. At Detectify, we’ve seen a 300% increase in monitored subdomains compared to 2021 (that’s over 3 million subdomains). This hockey stick growth in exposed assets is challenging existing security workflows, and even the most skilled security practitioners are wondering – how do I know if security policies are being followed?
One of the challenges we’ve learned from speaking with hundreds of security practitioners is that it’s notoriously difficult to validate internal security policies. This becomes increasingly challenging as Product and AppSec teams lose visibility of what is being exposed online and who is shipping those assets to production.
Today, security teams either rely on manual processes or simply don’t validate that their internal security policies are being followed. This lack of visibility leads to policy breaches that go unnoticed for months, sometimes even years. We’re developing Attack Surface Custom Policies to address this challenge and help security teams get a handle on several common scenarios.
What are a few of the use cases for Attack Surface Custom Policies?
Ensuring security headers are enforced
Security headers are highly recommended by security practitioners as they can harden the security of an asset, like a website or a web application. In many cases, adding security headers, such as those used to mitigate XSS, is straightforward for many teams. However, enforcing these security headers is easier said than done because continuously verifying that the security headers are used is simply too time consuming.
Spot technologies that are not approved for use
Many security teams have technologies that are either not approved for use for various reasons, such as being prone to vulnerabilities, or have past versions of the technology that are particularly risky. Today, security teams don’t have a way to enforce these policies internally and often have to rely on their teammates not using or removing these technologies as they are discovered.
Catch unintended open ports across your attack surface
Open ports are not necessarily risky; in fact HTTP/HTTPS ports like 80 and 443 are expected to be open in most scenarios. However, there are other ports that security teams should think twice about if open. For example, you might not want your ports associated with relational databases to be open because it could in some cases lead to data becoming exposed.
We’re just getting started with Attack Surface Custom Policies and are launching the feature today with support setting custom policies on open ports. Open ports often go unnoticed as many security teams infrequently scan their attack surface for open ports, something that can lead to unintended risks. Additional functionality, including the uses cases cited above, will be available on Attack Surface Custom Policies in the coming months.Not a Detectify customer? Book a demo with a team to learn how we can help cover your external attack surface.
Attack Surface Custom Policies helps security teams reduce risk
Adding Attack Surface Custom Policies to help monitor your attack surface is simple. Attack Surface Custom Policies use an “IF-THEN” structure to give users clear insights on any violations of these policies as soon as they appear on the attack surface. Policies can be of any desired specificity and will allow combinations of dimensions on port data, web technologies, hosting, domain name, or DNS records, to list a few examples.
Wondering what types of rules you can set up right now? We’ve listed a couple of examples for security teams interested in trying Attack Surface Custom Policies today.
- “Allow-list” of open ports. Many customers are already using this policy to spot unexpected open ports not on their allow-list: “If the opened port is not one of 80 or 443, then create an alert.” This ensures that any other port will end up in the alerts list and can be verified by the security team.
- “Not-allowed list” of open ports. Another approach are ports that are not typically allowed in their organization. This could be a list of ports typically used for different types of protocols, like FTP, SSH, Telnet, SMTP, SNMP, or RDP, through: “If opened port is one of 20, 21, 22, 23, 25, 162, 162, 3389, 3390, then create an alert.”
- Open ports for relational databases. To then cover relational database ports, teams can add another policy like: “If the opened port is one of 7210, 3306, 1521, 1830, 5432, 1433, 1434, then create an alert.”
- Scope open ports for specific domains (coming soon). If you have a set of domains that should be behind a VPN and therefore never have any ports open, you will in the near future be able to scope the policy on a group of domains. For example, if every domain under example.com should never have any open ports then: “If any port is opened on example.com or any of its subdomains, then create an alert.”
- Remove technologies that are not approved for use (coming soon). If you have certain technologies that shouldn’t typically be used on your attack surface: WordPress is a relatively common example. Custom Policies can be used to alert for any instance of WordPress running on any of your domains: “If any domain on my attack surface has a found technology that matches “wordpress” then create an alert.”
If you’re a Detectify customer, we encourage you to set up one of these policies today. Not using Detectify yet? Don’t worry, you can start a 2-week free-trial by signing up here.
Complete coverage for leading Product and AppSec security teams
Detectify sets the standard for External Attack Surface Management (EASM), providing 97.7% accurate vulnerability assessments. Product security and AppSec teams trust Detectify for complete coverage of their attack surfaces with real-world, payload-based attacks from its global community of elite ethical hackers.
- Rigorous vulnerability assessment. Each test includes a verified payload crowdsourced from our community of ethical hackers. These payloads ensure that every vulnerability finding produced on our tool is accurate, resulting in a 99.7% accuracy rate.
- Complete coverage. We cover your entire DNS footprint, continuously identifying and testing your Internet-facing assets for vulnerabilities and anomalies that no other EASM solution can do.
- Built for Product and AppSec teams. Our tool is scanning your attack surface everyday. This means your Product and AppSec teams get the freshest insights about your attack surface so they can resolve the issues in production that matter most to your organization.
Try it yourself. Book a demo or sign up for a 2-week free trial and start testing your web apps with Detectify today.