Imagine you’re on ICQ one night, and you see this dude jumping into your chat room. Before long the two of you start to argue like a couple of schoolgirls and the “dude” says that he’s gonna burn you, so you challenge him to bring it on!
All of a sudden, your super rad Windows95 box is crashing, leaving you with the blue screen of death. “What the @!#$!@#$?!” comes spewing forth from your scorched lips.
So what just happened to your computer? Did your box crash because of that other lamer? How did he cause that blue screen? While the BSoD was an all too common sight, the timing was just too perfect to think it wasn’t him.
This was my first experience with Cyber Security. Having power over someone halfway around the world, all while comfortably sitting behind a keyboard, was exciting. I wanted to know more, and thus I entered the wonderful world of Cyber Security and never looked back.
Since my early days, Cyber Security has grown up quite a bit. I’ve seen many sides from Unix to Active Directory authentication solutions, to running Global Identity Management projects for Fortune 100 companies, and spending late nights with customers under advanced application attacks from nation-states.
Throughout history security was all about the wall at the edge of your castle and how big you could build it. The higher and broader the wall, the more secure you were. However, there was a gate so that others could visit you and conduct business. So, attackers focused on the gates because that’s where the holes were. Times changed and in the early world of technology, it became about how big your edge firewall was to protect your business.
And now applications have created the holes in your firewall. As soon as a perimeter firewall is deployed, port 80 and 443 are opened. Today it’s not only your employees and preferred partners that need access to applications but customers need access to your applications and data too, and their browsers must be allowed in.
With more and more applications and more and more data being shared we needed a way to inspect the visitors coming through our perimeter to make sure we were safe. This led to the advent of Web Application Firewalls (WAFs), a new gatekeeper of sorts that looks deeper to examine web traffic and look for malicious content before allowing it through.
As web-based applications became more prevalent the WAF became a necessary component of your security stack. Without this gatekeeper, it would be a matter of minutes before an unprotected application was discovered and attacked.
WAFs have become very good at using signatures to identify and stop known attack types such as SQL Injection (SQLi), cross-site scripting (XSS), and cross-site request forgery (CSRF). In addition, most WAFs now offer Rate Limiting policies to keep your applications protected from distributed denial of service (DDoS) attacks.
However, in the never-ending cat and mouse game, as solutions have evolved to protect our applications, attackers have also evolved to bypass them and find new ways into your environment. These days a moderately sophisticated attacker can avoid detection with ease. They can use proxies and bot networks to attack from specific countries and multiple IP addresses to obscure their presence.
The most significant difference today is that applications are no longer the same. In the past, every page you clicked or every page refresh would reload the page from the web server. All the heavy lifting and most of the vulnerabilities attackers would target were in the datacenter. Today with millions of visitors and 100s of millions of requests (not to mention our dwindling attention span), application developers need a way to present data faster without returning to the data center for the complete page on every request.
Just because I still use a browser to visit a website, does not mean that the site responds with legacy HTML. With this shift, the vulnerabilities and attacker focus has also moved.
As I have worked with various industries and customers, I noticed a trend. Applications became more API driven, and mobile platforms were developed first before the browser. This lead to some gaping security holes in the traditional application security stack. Holes that WAFs didn’t do much to plug.
The expanded use of APIs in applications prevents these critical security features from being used, and my customers experienced an increase in attacks and increased difficulty in detecting malicious traffic.
I came to realize that a new form of application security was needed specifically to solve the API problem. WAFs and signatures can not identify API attacks because those APIs are unique to each organization and each application. A standard set of signatures and policies will not work from customer to customer. The APIs at the center of today’s applications are as complex and unique as the environments to which they connect, and attackers take advantage of this by looking for vulnerabilities in the unique logic of each API.
As I looked beyond the WAF I came to Salt Security, the only Patented API Security solution that takes a behavior-based security approach to protect modern web applications. Salt then uses application profiling to provide a clear understanding of how users interact with your APIs and how those users normally behave. Salt then adds Data Classification to determine the overall risk of that user’s behavior and correlates that activity into a single alert. Pretty powerful stuff.
More specifically, this means Salt Security has an understanding of the unique logic of each API at a granular level to identify potentially malicious behavior and stop attacks. Even better, it doesn’t require configuration or the care and feeding (i.e. updates) that you might associate with your current security solutions.
Modern Web Applications require a Modern Security solution. It is time for you to add some Salt to your security stack and secure your enterprise. I’m super excited to be part of the Salt Security team and look forward to talking more about our approach to protecting modern applications.
It’s extremely important to make sure your OAuth implementation is secure. The fix is just one line of code away. We sincerely hope the information shared in our blog post series will help prevent major online breaches and help web service owners better protect their customers and users.
We want to thank our customers, partners and friends for the calls and messages to our team showing your concern and support.