In the past year, we’ve shifted our infrastructure from a single Amazon Web Services (AWS) account owned by our Platform team to multiple domain-specific accounts. For each product domain and environment, we have created AWS accounts, which has allowed us to improve stability and security by reducing the blast radius. This setup also provides excellent scalability with good cost observability across the organization.
The increasing complexity of applications and networks means that it’s more important than ever to have comprehensive application scanning and attack surface management in one place. Any true and complete standalone EASM solutions should already have application scanning capabilities built into them. But how does this work exactly?
We know that managing SSL/TLS certificates across hundreds – or even thousands – of Internet-facing assets is often a manual job for most security teams. Certificates that have expired, for example, offer an excellent opportunity for malicious actors to execute a variety of hacks (in some instances, even a MITM attack) and can also put sites at risk of becoming inaccessible. We’re excited to share that automated SSL/TLS certificate assessments are now a part of Surface Monitoring.
We recently explored why developers have begun to ship more frequently to production, as well the relationship between more frequent releases and AppSec teams more effectively prioritizing and remediating threats. To further understand how AppSec teams evaluate tooling, we’ve recorded a collection of common questions that we’ve observed teams asking themselves.
At Detectify, we proudly maintain an AppSec perspective when it comes to how we handle security. But what does this mean exactly? In short, we think a lot about how both AppSec teams and developers will experience our platform and products. We know that today’s developers are feeling the pressure to get new code out to production to meet the demands of the business. These business demands have increased the need for AppSec tooling to leverage automation whenever possible.
We know that most security teams today handle a backlog of thousands of vulnerabilities. We also know that not all of these vulnerabilities pose a significant risk to your organization, whether or not they have a high severity score or are present on a business-critical asset. We’ve spoken with dozens of security teams over the last few months and have learned that filtering vulnerabilities across several factors is critical to accelerating remediation.
Today’s organizations have a plethora of tools and technologies to protect their systems and assets. While this is certainly a privilege, it can sometimes be tough to keep up with the ever-expanding lists of acronyms and tools out there.
Below, we’ll take a look at how both DAST as a methodology and DAST as a tool relate to what we do at Detectify. More specifically, we’ll explain how Detectify’s solution applies DAST methodology with an External Attack Surface Management (EASM) mindset to deliver the most value to AppSec and ProdSec teams.
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.
