Time For a Change

The FBI recently released a public advisory regarding a sharp rise in deepfake videos being used by scammers when applying for remote positions. Combined with identity theft, these criminals are able to convince their would-be remote employers that they are who they claim, and often get positions that have access to sensitive data.

HR, recruiters, and other hiring professionals can no longer use only the techniques they used even a year ago when hiring for remote positions. Those in a hiring position need to be able to pick up on potential clues, such as lip movement that doesn’t coordinate with the audio. It’s not a matter of “this isn’t your parents’ world;” it’s “this isn’t even last year’s world.”

In the same vein, securing web applications isn’t the same as it was even a year ago. Even saying “web app” doesn’t mean what it used to. With the rise of APIs and mobile apps, the use of a website presence is taking a backseat to mobile apps and IoT. Protecting corporate assets has moved on from thinking about protecting the network perimeter. One needs to move from a web presence idea to an internet/interconnected concept.

For years, the way to protect one’s web presence was a WAF (Web Application Firewall). Like network firewalls, WAFs are configured with rulesets based on threat signatures, with an admin or two in charge of keeping up on the latest infosec news, adjusting the rulesets as needed (this always comes with staying up late multiple times a month to keeps things updated).

One look at a threatmap of cyber threats and attacks will give anyone a reason to reflect on how infeasible the complete manual approach is today. With the multi-pronged increase in 0-days, attack surfaces, automated attack tools that run 24/7/365, and threat actors (not just criminals, but disgruntled employees and hacktivists), the processes of manual updating, upgrading, and securing don’t work anymore.

The Threat against Threat Signatures

With the increase in technologies available – including what attackers can use – any protection that relies solely on signatures needs to be replaced or improved. Many, if not most, WAFs rely on ModSecurity. ModSecurity, or Modsec, has now been released to the open-source community, specifically to OWASP, for development and support. OWASP continues to develop the Core Rule Set (CRS) to be used for updating ModSecurity firewalls. The CRS was designed specifically for Apache and IIS/Nginx web servers. While it’s impossible to determine how many sites are powered by these, it’s estimated that Apache and Nginx run nearly 2/3 of the web.

What’s the danger of signature-based technology? One danger that vexes traditional WAF technology is 0-days. Zero days are more common, and not addressed by threat signatures, at least not in a timely manner. Signatures for any threats might be made available every 15 minutes, or perhaps even take as long as 6 months. However robust threat signature technology may be, 0-days alone give one pause to rethink the security strategy, especially considering how much of the internet potentially runs on older appsec protection methods.

Some Recent Threats

According to Cloudflare’s report on DDoS attacks, Q1 2022 saw over half of the DDoS attacks lasted up to 20 minutes, 40% were over in 10 minutes, and the rest 20 minutes and longer. Signature-based protection alone couldn’t handle this.

In the 2018 memcached attack, port 11211 needed to be blocked, a defensive maneuver that can only be handled reactively, and perhaps too late to prevent damage, if performed manually. While this is an older attack, the advantage here is that the time elapsed has given professionals time to analyze and consider the repercussions of A) signature-based protection and B) not relying on a multi-layered approach.

More recently was the Log4j vulnerability. On December 9, 2021, the 0-day exploit that affected Apache was discovered. It took until December 13 for any patches to be delivered. This article is by no means an attempt to discredit the enormity of the vulnerability or the great work done to mitigate the issue. The Log4j vulnerability brings to the front again the need for more than straight-ahead rulesets.

What Are We Looking For?

Along with application security, organizations also need specific defenses to protect APIs. Collectively, we need to protect against:

• Brute forcing APIs to obtain sensitive IDs or tokens
• Account Takeover (a.k.a. Credential Stuffing)
• Targeting sensitive APIs (e.g., gift card and credit card validation) and attempting to validate stolen cards
• Malicious automation and bots
• Malicious or disallowed traffic sources – e.g., Tor or VPN
• Insider Threat (user management APIs abused by insiders for privilege escalation)
• Performing a high number of permissions changes
• APIs using outdated or unpatched third-party frameworks or libraries, and injection issues (command execution, XSS, SQL Injection)
• High velocity requests leading to stolen content or resource exhaustion
• DDoS

The technological approach also needs to adapt and update automatically and intelligently. Mark Bowen at ‘Intelligent CIO’ said: “Attackers don’t handcraft malware; they modify existing malware just enough to throw off signature-based defenses. Malware signatures work by creating hashes of known bad files, so the smallest modification prevents a match.” API attacks don’t even rely on pre-defined malware in the first place.

AI and ML

Modern web app and API protections require the benefit from AI-led and machine learning (ML) models to better protect customer and corporate assets. These advanced and improving technologies are viable alternatives to signature-based threat protection, including protecting the Nginx servers that are so ubiquitous.

They also reduce the barrier to entry for security professionals. This a boon for organizations because they do not have to hire experts on the implemented gear. And current employees do not have to master new tech in order to manage and maintain.

An organization wants to have these devices (physical or virtual) run like a fridge – one wants to buy it and have it simply work, without having to be an appliance expert. And only if something goes wrong (let’s face it, everything breaks) does the expert need to be contacted.

An issue with plain ML is that it lacks the ability to determine context (e.g., upside down images, similar outlines). This deficiency has led to Contextual Machine Learning (CML). While this hasn’t been an issue so much with the wider world of ML, it’s a critical aspect of application security.

While CRS and other signature-based tools provide flexible rule sets, CML provides real-time changes to better protect web apps and APIs.

What’s Next?

In practice, one may have to maintain outdated – or soon to be outdated – appliances and technology, primarily because of lack of budget, but also because of lack of other resources, such as trained personnel. Looking ahead and planning are vital factors in application and API security. The attack and security landscape changes quickly and often, so the threat knowledge base changes multiple times a day, and older defenses – while they had their time and new technologies stand on the shoulders of giants – are either no longer applicable or soon will be.

In the appsec field, it pays (and provides job and employment security) to keep up with the rapid pace. Leveraging modern technologies, such as AI and CML, will make it possible for an org to either reduce or maintain its costs by shifting the maintenance burden to the equipment and leave space for personnel to do the higher-level work of developing, engineering, planning, training, and protecting the data and reputation of their business.