Signal Sciences is looking to further DevSecOps adoption by adding support for a Power Rules user interface to its web application firewall (WAF) through which security teams can define, monitor and act on any web application or transaction involving an application programming interface (API).
In addition, Signal Sciences is adding a Network Learning Exchange (NLX) that provides access to a data feed of confirmed threats to give IT security teams advanced warning on new and emerging threats. NLX eliminates the need to rely on signatures that often generate false positives. Instead, NLX delivers alerts when malware is confirmed to be present on a customer’s website.
In contrast, Signal Sciences CEO Andrew Peterson said rival WAFs generate alerts that don’t provide enough context to be considered actionable intelligence. That creates a large amount of alert fatigue that invariably results in critical security breaches being missed or ignored, he said. In fact, much of the general frustration with WAFs as a security technology can be traced back to the number of alerts generated by products that do little more than prevent run-of-the-mill SQL injection attacks as defined by the Open Web Application Security Project.
Because Signal Sciences is relying on trusted sources, organizations that make use of the Signal Sciences WAF run it in full blocking mode 95 percent of time, Peterson noted, adding Power Rules enable IT security teams to tune WAF rules without having to construct overly complicated rules or learn a scripting language.
Peterson said these latest extensions to the company’s security platform advance the company’s position as a leading advocate of DevSecOps enabled by runtime application self-protection (RASP) security software, which allows developers to embed into their applications agent software that responds to cybersecurity attacks in real time. Rival approaches based on legacy firewall technologies running on top of a virtual machine fail to provide developers with a true programmatic approach to securing their applications, he said.
Reliance of that RASP approach has increased dramatically as organizations continue to shift application code to public clouds, where the security made available is limited to the IT infrastructure being made available, he said. In addition, he noted a RASP approach also eliminates the need for a raft of point security products to address requirement spanning everything from account takeover to fraud and bots.
There’s no doubt in the age of the cloud that interest in DevSecOps processes is rising sharply. Naturally, debates about how best to accomplish that goal tend to fierce. In general, developers are assuming more responsibility for implementing the security policies that still tend to be defined by IT security specialists. Developers, of course, are going to favor application programming interfaces (APIs) to implement policies within their code, while IT security personnel still require access to a GUI largely because most of them have limited programming skills.
It may take a while for organizations to fully embrace DevSecOps processes. Many of them are still struggling with defining the separation of duties between developers and cybersecurity professionals. But as those processes mature it’s now only a matter of time before applications become more secure than they have ever historically been.