The modern threat landscape and expanding CISO challenges

Prior to starting Signal Sciences, its founders were running security at Etsy, and growing frustrated with existing legacy technology. So they built their own.

For this interview with Andrew Peterson, CEO at Signal Sciences, we dig deep into hot topics such as modern CISO challenges and application security visibility. Prior to co-founding Signal Sciences, Andrew has been building leading edge, highly performing product and sales teams across five continents for +15 years with such companies as Google and the Clinton Foundation.

Information security has evolved quite a bit in the past decade. Based on your experience, what are the most significant security challenges for modern CISOs?

CISOs have a huge responsibility to continually assess the security tools and processes they’ve put in place in their organizations to prevent a breach or cyber attack. That’s a tall order in any organization: persistent attackers are constantly looking to find new vulnerabilities to exploit. With over 40% of all successful breaches caused by attacks at layer seven, the application layer, effective protection in production is no longer a “nice-to-have”—it’s a must-have part of any security plan.

That said, the following challenges are the most relevant to embedding security within any organization’s application development process to prevent an attack at the web layer:

• Establishing visibility into how your apps are being attacked in production is paramount: you can’t defend against what you can’t see. It’d be great if developers made perfect code but the reality is no code is perfect or ever will be. So living with bugs and live vulnerabilities is the normal state for all security and engineering teams. Knowing where and how you’re being attacked and if those attackers are succeeding is the only way you can mount an effective defense. Empower your team with this information so they can be proactive in responding to attacks before and as they occur.
• Security should be an enabler and not a blocker to development and operations teams. Once you establish reliable visibility into attacks, leverage it to help your teams prioritize their limited defensive resources instead of setting up security choke points in your SDLC. You’re using tools like static and dynamic code testing and programs like bug bounty and penetration tests to generate lists of potential vulnerabilities and bugs. But instead of requiring developers to fix them immediately (which doesn’t happen), evaluate where attackers are focusing their attacks and use that information to prioritize what bugs you ask your developers to prioritize. They’ll more clearly see the need and urgency, you’ll more effectively address real risks, and you won’t be a blocker for launching new code. Everyone wins.
• Leveraging the cloud and the opportunities to scale the business while securing the digital assets that will reside there is another issue many CISOs face. Whether you are transitioning legacy apps to the cloud or design and building cloud native apps, you’ll need to put tooling in place to secure those applications that are the gateway to valuable data. The tool you choose for application security should also be flexible enough to protect apps run in legacy environments so you’re not stuck with a point solution. While deploying apps to the cloud allows for scaling quickly, and thus serving a larger set of customers on an ongoing basis, it also widens the attack surface. A next-gen WAF or RASP like what we offer can protect web apps against account takeover, bad bots or business logic attacks where the attacker seeks to maliciously penetrate or otherwise leverage an app.

The fast-paced threat landscape is driving plenty of innovation in the cybersecurity industry, but businesses can struggle with the rate of technological change. What advice would you give to information security leaders that need to keep up with new developments but feel overwhelmed?

Industry news sources like Dark Reading and SC Magazine provide informed opinion and product reviews but can be limited in depth. I’d recommend subscribing to conversational style content like podcasts that can take the time to dig in on details and have the convenience benefit of being listened to at any time (commutes are my favorite). The Security Weekly podcasts hosted by Paul Asadoorian is a good example of high-value content that address specific subjects CISOs care about going beyond the surface level. Podcasts like Enterprise Security Weekly, Application Security Weekly and Risky Business are worth subscribing to and digesting for current trends and situations security teams have to deal with (disclaimer: myself and Zane Lackey of Signal Sciences have participated in these podcasts, but Paul has a variety of industry folks on to capture different point of views).

Outside of on-demand media sources, face-to-face meetups and local chapter meetings of industry groups like ISSA (Information Systems Security Association) can put a CISO in touch with folks with similar roles and concerns. We recently hosted the monthly ISSA-LA chapter meeting at Signal Sciences where a panel of experts shared their stories on how to establish security programs using the NIST and ISO frameworks.

Lastly, Gartner has a great tool for enterprise software evaluators and buyers called Gartner Peer Insights. It’s like a Yelp for enterprise software where those who have evaluated not only the product but the organization behind the product leave reviews in their own words. We’re in the web application firewall category and I’m glad to say we’ve done incredibly well by our customers as shown in those reviews.

What do you see your customers most worried about and how do your products help address their concerns?

It’s a cliched word in security, but visibility into how and where adversaries will try to attack an organization’s apps could mean the difference between a breach occurring and having to send out a breach notification: no CISO wants to do that. Those that have tried to use legacy WAF products repeatedly tell us they get little value from them—or that the maintenance burden does not justify such little return on the investment. In short, they want an appsec tool that both works and tells them what is happening so they either automatically block malicious requests or otherwise take action.

We provide visibility into what’s happening at the application layer wherever our customers deploy their apps. We recently participated in the Cloud Native Security report where an astonishing 73% of the nearly 500 survey respondents said they lack actionable, real-time insight into threats and ongoing attacks in their production environments, including their apps in production.

We provide the necessary visibility at the application layer with both visual summaries and real-time alerts broadcast via popular DevOps tools like Slack and PagerDuty. We show the volume of attacks blocked and where in the app flow they are trying to maliciously manipulate customers’ apps, APIs and microservices. For example, financial and e-commerce customers monitor key app interaction points like account registration, login and password resets. If traffic requests come from known-bad IP addresses or are associated with known indicators of compromise we collect from across our customer base, we can automatically block them. We can also alert customers on other request anomalies, log and alert on them and let the customer decide if they want to start blocking those as well.

You say your Next-Gen WAF and RASP is designed to protect the modern web. How does it differ from other offerings out there?

Legacy WAF offerings were not built for today’s faster, more complex software development and deployment options. They offer protection, but due to the high maintenance and false positives, our customers who migrate from those legacy WAF offerings tell us they hardly run those products in blocking mode in production. Our technology eliminates dependency on legacy WAF rules tuning while leveraging the code-layer instrumentation of RASP to gain detailed request and response data. We provide the best alternative to legacy WAF while offering the insights gained at the code layer with RASP. We have a video about the nuances of RASP approaches that goes into this more.

The web application firewall market is very competitive. What makes the Signal Sciences WAF unique?

We designed and built our offering based on first-hand experience with legacy tools that didn’t do what we needed them to do: protect the application where it resides without major maintenance overhead, all while providing the visibility I mentioned earlier. That’s another problem with legacy WAF products: many are black boxes that tell you they found a matching pattern, but provide no context.

At a high level, legacy WAF products were designed around static regexs—or pattern matching—to determine if a web request is good or bad. To expand the capabilities of a legacy WAF, the customer must dedicate full-time staff to developing, maintaining and testing rules on an ongoing basis to ensure they are still valid and work without breaking an app each time new code is released to production. And even with that dedicated person, the attack techniques vary over time, requiring an ever-growing ruleset. Now think about how many times per week and month a fully agile software team releases new code to production across various pieces of infrastructure—cloud, on-premise or a hybrid of the two—and you start to see the costly complexity required.

With Signal Sciences, there’s none of that. We take a threshold approach to blocking so our customers can run our solution in full, automated blocking mode in production with virtually no false positives: 95% of our customers trust us to do just that.

With threshold blocking, we don’t make a decision on each request like other legacy WAFs and RASP products, but instead look at suspicious payloads over time and with context to determine whether an actual attack is occurring. Our patented approach analyzes over 200 billion weekly production requests with no noticeable performance impact on the applications and APIs we help our customers protect.

Many of our customers tell us they do not dedicate a full time staff person to our product. Instead, they rely on the out-of-the-box protection capabilities our technology provides that automatically protects their apps. Signal Sciences effectively becomes a reliable tool in their security arsenal dedicated to monitoring and detecting bad web requests and blocking them.

Our more advanced customers can utilize Power Rules that can be setup in our product console interface to provide more advanced protection. With Power Rules, they can enable rate-limiting rules around abusive behavior like content scraping and eliminate serving up content and resources to malicious users, potentially saving on infrastructure costs. And the same threshold-based approach can prevent malicious automated attacks via bots deployed to perpetrate application DDoS and account takeovers.

At the end of the day, we embed with our customers apps, APIs and microservices wherever they deploy them to provide this level of protection.