After about a decade of running product marketing programs for various security companies, it looks like I got my seat at the table. Which table? The Bot Defense Council.
What is the Bot Defense Council?
The Bot Defense Council (BDC) is a group of IT practitioners and technically adept business leaders committed to the goal of making the Web more secure by eradicating automated threats. Their expertise spans many verticals but tends to be focused on sites that serve massive amounts of consumer traffic, and is thus highly dynamic in nature; or online business with unique, original content. Members of the Council come from a host of companies including:
Fallout from Ashley Madison
The conversation started with a discussion of the current state of the bot problem on the internet and quickly turned to war stories. One incident in particular appeared to be a catalyst for several bot-related woes. The source of pain? Ashley Madison.
What does the Ashley Madison breach have to do with bots? Ashley Madison was one of the largest and most complete username password list dumps in recent history with over 11 million account credentials already released into the wild.
Many people reuse their login credentials on multiple websites. The fastest way for cyber criminals to test these credentials is by using a bot to perform brute force login attacks. Bot Defense Council members saw a huge increase in bot-driven account takeover attempts and transaction fraud attempts since these passwords were released.
WAFs vs Bots
I firmly believe that WAFs are an important web application security tool; equal in importance to a traditional network firewall. This sentiment was largely echoed by the members of the Bot Defense Council - most, if not all of whom - have at least one, if not multiple layers of WAFs deployed to protect their web environments. But they also have Distil Networks. Why?
Regardless of which WAF they were deploying the consensus was that while technically able to block basic bots, WAFs do a poor job identifying and blocking advanced bots like Selenium or Phantom JS. WAFs are also time consuming to use as a bot mitigation solution. One member remarked “We used to spend 2 or 3 hours every day messing with whitelists and blacklists on our WAF. Find a bot, blacklist it. Find a partner, whitelist it. We maintain multiple layers of WAFs and with the partners moving blocks of IPs and attacks shifting their origin IPs it was a lot of work to maintain.”
Opinions were that not only does this approach require a lot of manual effort, it’s always going to be one step behind the bad guys. Attacks need to be identified before they can be blocked. Since most WAFs lack the ability to identify many kinds of advanced bots such as those posing as humans, using browser automation, or performing distributed, low and slow attacks these tools don’t really solve the bot problem.
APIs still vulnerable to attack
Another attack vector that the Council found worthy of discussion was APIs. Although there are several API management solutions on the market, they are typically used for key provisioning, policy management and providing very basic security functionality like rate limiting. The consensus was that existing API security tools are expensive, time consuming, and offered little security value. One member remarked “We were using a solution which crashed constantly and had over 100 patches last year. We spent over 1,000 man hours maintaining the solution with little value add as a result.”
When asked what the ideal API security tool might look like, members replied:
Protection against malicious and accidental threats – Sometimes attackers are inadvertent. Developer errors, or scripts-gone-wild may result in service degradation or instability without malicious intent. Solutions should be able to identify and limit these “attacks”.
Correlate attacks with a known violator database – Attackers or fraudsters may point the same bot infrastructure at websites or at web APIs, thus it’s helpful for API security solutions to share attack origin IPs, and device fingerprints with other security solutions.
API Security as part of application security – Being able to include the security of public APIs in the same tools and processes that govern other parts of an existing security operation would be a boon security practitioners and would reduce operational complexity.
Include mobile API Security – the tool should be versatile enough to extend its protection to cover mobile APIs.
Rate limits on a per-segment basis – throttling API access based on the profile of the requestor.
Low maintenance – the ideal tool should be able to be deployed before, during, or after an API goes live and be maintained with little or no involvement from the development team.
It was a pleasure to learn from the guys on the Bot Defense Council, and I’m looking forward to hearing new insights and strategies at the next Bot Defense Council Summit this coming Spring.
About the AuthorMore Content by Orion Cassetto