The only constant is change. Perhaps nowhere is that more true than in software and security. Ever-evolving business needs and an ever-increasing speed of innovation have come together to cause an explosion in available surface area for attackers. This comes in many forms – with an ever-increasing list of tools that have access to various pieces of business data and an increasing number of devices and complexity of networks. But there's another vector whose complexity and breadth is also ever-increasing - your organization’s external attack surface.
With constant change and increased complexity, have we really embraced the importance as an industry of securing that perimeter? We know that a secure, defensible perimeter is critical to the business and the overall security posture of our organizations. Yet, we still see organizations taking a reactionary and obsolete view of managing that attack surface.
There can still be spreadsheets or other systems of tracking "external facing assets" – even as transitions to the cloud and other SaaS models have evolved “asset” to mean much more than it used to. And even beyond such manual systems, legacy vendors have also struggled to keep pace with the rapid innovation in the way organizations deploy and manage both their software and their external attack surface.
Legacy Vulnerability Management
Legacy systems not only lack context to the exponentially more complex attack surface of today’s world, but many have business models that aren't even compatible with the way modern software is developed and deployed. What does it mean to count servers as assets in the world of serverless? How can systems stuck in the past deal with short-lived and ephemeral assets like Kubernetes pods?
And it only gets worse, it takes a lot of manual script writing, data transformation, and brittle self-managed integration to get these legacy tools to adapt to the modern attack surface. Even then, organizations must contend with a legacy view of the vulnerabilities in their vulnerability management system while the world around them continues to evolve.
At best, this represents an outdated view of the possible attack vectors and vulnerabilities – subject to the whims of those vendors to update signatures and understand the evolution of the threat landscape. At worst, it is mere compliance as the main thrust of a “security” program. Just make sure all the compliance boxes are checked, and we should be okay, right? It reminds me of the days of “No one got fired for buying IBM.” Instead of protecting our organizations from attacks, we instead protect ourselves from auditors.
Communication Complications
Perhaps you've faced the challenges outlined thus far and feel that you've worked around them – you hired a team to do your own threat intelligence research or built tooling around actual vulnerability detection on top of your “checkbox checking tools.” Even with all that, you face the next complication: prioritization and communication.
In an increasingly complex environment, prioritizing what you should focus on can be challenging to say the least. Detecting new assets spun up by disparate teams or shadow IT groups, understanding which assets are most critical, and then identifying actual exploitable vulnerabilities rather than a long list of possible CVEs is a daunting task for any organization.
Even once vulnerabilities are identified, communicating the urgency and the specific need for fixes to engineering can often be a very manual and laborious process. It's no surprise that we seem to learn of a new security breach every week. After all, attackers only need to be “right” once, while our teams have to be “right” every time.
All of this begs the question: how can modern security engineering teams focus on the right things to fend off attacks from external threats? In some ways, the answer may be simpler than all of this complexity makes it seem: To prevent attacks, we must think like an attacker.
Think like an attacker – Reconnaissance
Let's put ourselves in the shoes of a would-be attacker for a minute. How do they view your organization if they are looking to do it harm? Where would they start?
The first thing any good attacker will do is get to know their adversary. Through various techniques, they will perform reconnaissance to identify and map out the possible attack surface before diving in and trying to pry open a door.
Given that, we must also try to map that attack surface thoroughly before we even attempt to shore up its defenses. And that requires a multi-modal approach to attack surface mapping. We can't just focus on what assets we know about what DNS records we think exist, or what systems we think are externally facing. Instead, we have to combine multiple sources of data together to create a complete view of the attack surface.
This means mapping out our known assets by gathering cloud assets from our cloud vendors, DNS records from our providers, and other internal sources of external data. A multi-cloud tool that is useful in bringing all of that data together is ProjectDiscovery's open source tool cloudlist. With that data, we need to combine public sources of other possible related DNS records – looking for domains and subdomains that we may not have mapped to a cloud resource. There are many public APIs available for gathering this data – subfinder is an open source tool that allows you to search a dozen of them or so at once.
Once we have these two pieces of data, we may also want to use large internet aggregation search engines (such as Shodan) to discover what they may have that is related to our organization. This may identify further domains or assets that we didn't find by placing our “known” quantities through the first two filters. Again, ProjectDiscovery offers an open source tool to do exactly that – uncover – which can scan a number of public internet-wide search engines for previously unknown assets.
Many legacy tools focus on only one of these types of data – but our would-be attacker will not be so naive. They are going to use all the tools at their disposal to paint the widest possible surface area for them to look for weaknesses in. And thus, teams need to bring together all of this data before moving on to find what is vulnerable. If we miss a critical system or tool in this step, then we've already lost. And once we have the most complete data set possible, we need to find what an attacker will want to find next: a vulnerability.
Think like an attacker – Vulnerability Scanning
When an attacker goes to scan or probe your systems for vulnerabilities, they aren't thinking about any compliance framework. They aren't concerned about what version of TLS you're using (unless it's a particularly vulnerable one). They aren't worried about finding the most possible vulnerabilities to make auditors feel better about the depth of your vulnerability scanning program. They only care about finding one thing – an exploitable vulnerability.
And this is where many vulnerability scanning mechanisms – whether they be passive static code scanners, container scanning tools, or dynamic vulnerability scanners looking at the running application fall short. In an effort to provide breadth of scanning capabilities, many of these systems flag any possible “vulnerability” – even those we might not think of as vulnerabilities because of how little they matter to the actual security of our systems.
And what's worse is when those systems, many of which have been entrenched for years, are tuned not towards protection from attackers but protection from auditors. Time and again we hear security practitioners talk of these tools as next to useless – they provide a PDF report with plenty of checkboxes checked and the auditors like that. But the real security only comes from what our teams can do to identify and remediate exploitable vulnerabilities.
And that's where thinking like an attacker comes in – and an attacker or a bug bounty hunter is going to scan the entirety of the attack surface they identified, looking specifically for the most exploitable or critical of vulnerabilities. Those that would allow them to get a foothold and pivot into your environment. Thus, minimizing noise and decreasing false positives should be the goal of any modern vulnerability scanner – at least once that is focused on security instead of compliance.
Automation & Remediation
While those challenges we've outlined thus far can seem daunting, many modern security engineers have put in place offense-oriented security programs or red teams to address and defend against them. Additionally, running public bug bounty programs allow many eyes to make this problem shallower and can set up your overall security programs for success.
Once those programs are in place, however, the next step should be focused on getting them to be as efficient as possible. And that's where automation comes in. For every bug bounty identified, or exploitable vulnerability found, it is very possible that many instances of that same vulnerability exist inside and outside the organization's perimeter. Thus, focusing on the repeatability and automation of this cycle – from asset discovery to enrichment to scanning and remediation – can and must be the next focus for security engineering teams.
Another open source tool that can help with this is nuclei from ProjectDiscovery. Nuclei is an advanced vulnerability scanner that takes in vulnerability signatures as a YAML based file. This enables teams to create custom vulnerability scans as well as leverage the open source community for the latest CVEs and those that are currently exploitable.
In fact, some teams even make that a direct part of their bug bounty program. If you look at Starbucks's bug bounty program you'll notice they actually pay an additional bounty for any report that is submitted with a Nuclei template. This allows them to easily scan the rest of their attack surface – internal and external – with nuclei for any newly identified exploitable vulnerability that comes to them from that program, increasing the efficacy of a single bug report many times over…automatically.
And one of the last but most important steps is to make sure that the identified vulnerabilities are remediated. Unfortunately, this is another point in the chain where many teams struggle – be it with communication about or verification of remediation. Many are shocked to find that over a decade since the advent of the term “DevOps” and sister terms like "DevSecOps" that there are still security teams that are communicating vulnerabilities to engineering teams through PDFs or only at expensive meetings.
Modern security teams must integrate directly with engineering processes and systems. Vulnerability management systems should be able to have bidirectional communication with engineering ticket management systems. The investment in automation around asset detection and vulnerability scanning should be able to feed into this pipeline, ensuring that the engineering fixes correctly remediated the original issue. Additionally, that automation should be factored into CI/CD processes so that once remediated, the same types of issues don't reach production environments again whenever possible.
Continuous Security
While the term “continuous security” may seem fraught with buzzword abuse, that really is the best way to describe how to apply thinking like an attacker to your security programs.
First, you must ensure that the external attack surface is properly mapped – and that the newest or most critical parts of that attack surface can receive priority attention. Once mapped, automation should enrich what technologies and exploitable vulnerabilities exist in those assets, allowing teams to understand and prioritize their work. And that work should automatically flow into and out of engineering so that the wall between security and engineering is simpler and automatically overcome. Finally, once these automated systems are in place, security can be a partner with development and operations by enabling those systems to come earlier in the cycle, ensuring that the only vulnerabilities that make it to the external attack surface are "new" or those we haven't identified yet.
This vision is the vision of the modern security engineer, and the one we're building at ProjectDiscovery. From our more than 20 open source tools focused on thinking like an attacker to our product Nuclei cloud, our mission is to democratize security. The security processes outlined here should be available to everyone – enabling all of us to think more like an attacker than an auditor, and thus protect our systems from both.