If you don't know what you're exposing, how can you protect it? [Q&A]

The move to the cloud has meant the days of external exposure being defined by the set of IP ranges in your firewall are gone. Today's attack surface is made up of many internet-facing assets with exposure being controlled at the domain level.

This means web applications have fast become an attractive target for attackers, particularly unknown and forgotten assets -- which are plentiful in modern environments. So how can businesses defend themselves?

We spoke to Rickard Carlsson, CEO and co-founder, Detectify to find out about best practices for exposing an organization's entire external attack surface, providing actionable advice for uncovering DNS properties and gaining complete inventory of web-facing applications and their security status.

BN: What enterprise IT trends are driving the expanded external attack surface?

RC: Enterprise attack surfaces are getting more complicated and harder to manage every day. A rise in multi-cloud strategies is a major contributor, as different clouds have different controls and set-up, with one default aspect in AWS working entirely differently in Azure, GCP, etc. In addition, rapid cloud adoption has taken corporate assets out from behind legacy firewalls, forcing security teams to adopt new practices for securing them. Remote work support is another factor, as 'work' devices are being used for more personal use cases, often visiting less secure sites and spreading infections from infected IoT home devices.

Every organization has multiple attack surfaces and must consider individual factors driving the expansion of each. When looking at the external attack surface, the growing number of Internet-facing applications and nuanced software development practices in modern enterprise environments are heavy influencers. The majority of today's new business value is generated through new digital business or the digitalization of old business, placing a premium on development speed – organizations can no longer afford lengthy release processes. This is accelerating organizational pace of innovation (which is great), but teams need a new toolbox to ensure speed does not sacrifice security.

BN: Why are organizations struggling to define their external exposure?

RC: Long gone are the days of servers in office basements and exposure being defined by the set of IP ranges in their firewall. Today's infrastructure is filled with web-facing applications and exposure is controlled at the domain level (DNS), with pointers to both internal and third-party services. As a result, organizations are simultaneously expanding their attack surface and inviting potential cyber threats. Organizations must monitor hundreds and hundreds of domains, and even more subdomains to get a complete view of external exposure.

Compounding matters is the fact that organizations regularly add assets or technologies to the attack surface without alerting the security team, eliminating any guarantee that the assets meet corporate security standards. This leads to policy breaches that can go undetected for days, months, or even years, representing massive risk to the business. If you don't know what you're exposing, how can you protect it?

BN: What role do internal security policies play in securing the external attack surface?

RC: Security is not one-size fits all. Every organization has its own security workflows and different criteria for determining acceptable risk. Compliance framework urges teams to patch everything based on the CVSS criticality, but the CVSS model is flawed. Things might have a high CVSS but the actual impact/likelihood of the vulnerability being exposed would be lower due to business context. In reality, very few CVEs present legitimate danger. And while there's no shortage of new CVE discoveries, they focus on traditional software components. Many modern cloud/AppSec issues come from misconfigurations, combinations of tools, or developer mistakes that are not covered by CVEs.

Product security and AppSec teams need to apply their own unique policies for corporate assets based upon business context. Proactive resolution of policy violations is often a more effective approach than reactive hunting for vulnerabilities, as violations can easily lead to assets being exposed without protection. The challenge is, most vulnerability management vendors offer one-size-fits-all solutions, forcing customers to choose from a menu of pre-set conditions that often don't apply to their business.

Today's teams require truly custom policies that automatically identify violations as soon as they are brought online. These capabilities are hard to come by, but we're working to change that.

BN: What is 'shifting left' and what impact has it had in enabling effective DevSecOps?

RC: Shifting left refers to the agile software development methodology of moving security testing and controls earlier in the application lifecycle to detect vulnerabilities as soon as possible. The problem is, the notion of shifting left is dependent on a standard linear development process, and those days are over.

In years past, the software development lifecycle was defined by sequential phases on the waterfall model -- requirements gathering, design, implementation, testing, deployment, and maintenance, with the next stage beginning only after the previous one is completed. Today, software development moves practically at the speed of light, in a nearly continuous loop with no separate stages. The lines between pre-production and production, and every line in between, have practically vanished.

BN: What are best practices for testing apps through their full development process and product lifecycle?

RC: It is critical to do pre-production testing, but the majority of hacking happens after deployment, and production is what matters. Teams need to focus their efforts on shifting both left and right, implementing controls at every stage, continuously. A virtually real-time security strategy tightly integrated into DevOps pipelines as transparently as possible is the best way to keep up with today’s lighting-fast development cycles, without slowing them down.

To achieve this, organizations need to get security information to software engineers as fast as possible, following a few key principles:

• Understand that new vulnerabilities arise constantly, and speed is what makes organizations safer. The best way to expedite identification and deployment cycles is to expedite the feedback loop.
• Limit reliance on manual procedures with continuous, automated technology that doesn't slow down development cycles.
• Position security teams within the organization as enablers instead of blockers. Automated technology is allowing security professionals to team with developers (instead of slowing them down) for real-time exploratory testing instead of finding and remediating individual vulnerabilities.

Image credit: fotogestoeber / Shutterstock