TL;DR: There is a common belief that when it comes to uncovering bugs in the DevSecOps cycle, catching things early on is often better. While this approach certainly works well for Software Composition Analysis (SCA) and Static Application Security Testing (SAST), it doesn’t really apply to Dynamic Application Security Testing (DAST) in modern environments.
Many security teams have thousands – if not hundreds of thousands! – of known assets and unknown assets that they continuously monitor for vulnerabilities and risks. Viewing large volumes of assets can be cumbersome, particularly when observing a specific characteristic of an asset, such as the technologies it’s hosting or its DNS record type. That’s why we’re adding additional customization to the All Asset view.
Security teams know, bug bounty hunters, and ethical hackers know it: Large attack surfaces are hard to manage. In this day and age, if you’re a medium-large organization without a comprehensive External Attack Surface Management (EASM) program in place, there’s a pretty good chance that you have some hosts on the Internet that you’re not aware of. Despite this, the concept of EASM is still new to many.
Conversations about basic cybersecurity hygiene often start with a lecture on effective patch management. While proper patch management is certainly recommended, much more can be done. Say you’ve locked the doors of your house before leaving for vacation – an opportunist might only check to see if the doors are locked, but a persistent thief might try the windows or look for other ways in. Similarly, CVEs and CVSS serve a purpose, but they still leave you with many untreated risks. Why?
Gunnar Andrews discusses how ethical hackers can look to EASM techniques to help increase their ethical hacking skills. For organizations, this article gives insight into the methods and types of information that ethical hackers or even malicious attackers will collect to increase knowledge about an organization’s assets.
Security teams have more data about their attack surfaces than ever before. Today, Detectify continuously monitors over 3 million domains (up from 700k around this time last year). As the attack surface grows, so does that amount of data that security teams have to manage. And security teams are feeling the pinch. We’re excited to announce Groups, a more intuitive approach to grouping assets across your attack surface.
Keeping track of what technologies are being utilized across your attack surface has become virtually impossible as a result of the pace of innovation, developer methodologies, and many other factors. Questions such as, “Where am I hosting all of my WordPress sites? Or “What 3rd-party software is it using?” often go unanswered because of the sheer number of domains organizations now have to monitor.
“Shifting Left” has long been thought of as a silver bullet of sorts for security. Conducting security testing earlier in the development cycle to catch vulnerabilities in staging rather than production environments is certainly worthwhile and can significantly lower an organization’s risk profile.
In October, we launched a new feature called Attack Surface Custom Policies for Surface Monitoring customers. Attack Surface Custom Policies makes it possible to set, enforce, and scale customizable security policies so you can focus on the issues that matter most. Since launching this feature, we’ve generated thousands of alerts on potential risks for our customers. For some customers, it was particularly difficult to view these reports.
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.
