Firewall, IDS, IDP, WAF, API Gateway: Choose Your Shield

To long a read? Feel free to jump to the bottom for the exciting conclusion!

Often in US Federal we see different requirements and use cases arise than our commercial counterparts. Quite often I might get asked to provide insight into security, identity, and compliance queries in the same way I might ask for insight on team development or CICD requirements from my commercial focused brethren. It just so happens that this week I have provided some insights on three of four discussions around the role of our API Gateway in enterprise security. The role of an API Gateway in enterprise architecture in general always seems to bring up interesting discussion points (can it replace my load balancer?), but none more so than enterprise security. I have often heard of API Gateways jokingly referred to as a 'Swiss army knife' because you can really do so much with them. Often I find myself saying to both customers and colleagues that 'It's not what you can do with it, it is what you should do with it.', and this applies I think most heavily to the security discussion.

One of the conversations I had revolved around an RFI response one of my colleagues was preparing, where I was asked to weigh in on some of the requirements. It is always interesting to see exactly what might appear in an API Management RFI under the security section. As organizations have started to migrate away from some of the classic architectures, while at the same time there are greater asks of IT without necessarily seeing a larger budget allocated to facilitate the new functionality, we start to see more and more requirements getting piled into RFI/RFPs. The resultant outcome often hosts a large and eclectic bunch of requirements that I have lovingly dubbed the 'shotgun security questioner section', where we get everything fired at us and see what sticks. Paraphrasing and abstracting selections from several instances, you can see some examples here of the sort of queries one might get to organize a response to:

• The ability to provide delegated controls around the viewing, consuming, and administration of APIs.
• The ability to throttle API traffic per API, per client, or per application.
• The ability to detect threats based on signatures of vulnerabilities.
• The ability to use heuristics to identify threats.
• The ability to perform OWASP controls such as SQL Injection, CSRF, XSS, etc. protection, antivirus protection, url reputation protection, etc.
• The ability to provide DoS and Distributed DoS (DDoS) protections, including from a high number of unique IPs, and against different types of of DoS attacks, such as Slowloris, SYN floods, etc.
• The ability to secure services with a variety of authN/Z type controls (ABAC, RBAC, JWT, SAML, etc.).
• The ability to combat transmission threats such as SSL/TLS downgrade, compression, cipher attacks and more.
• The ability to do schema based analysis of incoming requests.
• The ability to security establish network security zones based on IP, Port, Host, etc.
• The ability to enable certificate management, mutual authentication, and SNI for TLS connections.
• The ability to detect insecure protocols and ciphers being used for connections.
• The ability to securely aggregate and offbox logs.

So we have web application consumption security, machine learning, embedded application security functions, protocol security, secure network zones, signature based threat protection repository maintenance... basically anything and everything from layers 2-4 and 7 of the OSI hierarchy are game. Queue the word 'quixotic', one of my favorites that I generally boil the definition down to mean 'unrealistically idealistic'. In my youthful exuberance, among other hats wearing one as presales escalation and technical proving grounds for a pre-IPO, I may have well dived headlong into attempting to prove out every one of the requirements with that quixotic 'what can it do' attitude. Of course hacking together a solution to prove out its functionality is one thing, owning the implementation and maintaining it long term is another. One of the values of working heavily with product management in more recent years has been adding the 'what should it do' mindset to how I approach problems, tempering that quixotic attitude into something more realistic.

(I can hear my colleagues in the future laughing as they read those words after I publish this, knowing full well that while I may temper that quixotic flare for customer facing discussions, internal discussions around roadmaps and innovation still can see that untempered unrealistic idealism for how we can push the boundries and change the world in its full glory. Of course... that is for resultant productized and supported functionality, not customization in the wild, but I digress!)

What you end up with is a request for a solution that can do everything, with account executives who would very much like for it to do everything (I joke, I joke!). With that in mind, I started to write up a response on one of these requests for insight, and did a bit of GoogleFu around the wording to describe where some of the functionalities might better lie and how we might describe the functionality enabled by our API Gateway. Ultimately I decided that the discussion should revolve around four different technologies: Firewall, Intrusion Detection System (IDS), Intrusion Prevention System (IDP), Web Application Firewall (WAF)... and of course the API Gateway, but we will revist that here in a bit. I quickly found defining these tools was more of a challenge than I originally thought it would be as some of my definitions were overlapping, and it was hard to draw the line on what functionality lay with each component. I shortly found myself in one of those situations where you go down a technical research rabbit hole and have 15 tabs open before you know it. With solutions unifying complimentary capabilities, marketing language obfiscating the underlying technologies, and the rapidly evolving requirements in the space, it seemed like a lot of definitions I was finding were somewhat more subjective than pure, hard fact. After what likely equated to massively overanalyzing the topic at hand, I resolved my thoughts into the following definitions:

Firewall - A set it and forget it tool, often used to define security zones/domains by blocking or allowing only specifically identified traffic at a port/protocol/IP/Subnet level with static rules at provisioning time. Generally, it is not interested in payloads or traffic patterns, and does not look to identify threats it has not been configured to protect against or dynamically rewrite its own rules. Rules will generally not be iterative after the protected resource is running, with only global policy changes that effect many/all services or changes to the backend resource access requirements resulting in rule modification. Firewalls traditionally work against layer 3 and 4 of the OSI hierarchy, and are mostly yes/no checks without major issues around false positives once the backend resource has been tested and deployed into production. Often used to protect against threats such as penetration scans and network recon.

With that one knocked out, I set out to define the difference between a Firewall and an IPS, or was it IDS? Were they the same thing?

IPS - An IPS prevents intrusion, keyword being prevents. Unlike the set it and forget it rules of the Firewall, and IPS looks at traffic differently, and should be have a dynamic rule base that is continuously tuned to prevent false positives and prevent new threats (often rule bases are programmaticly updated by vendors). Protections are set as rules and often works off signature based comparison to block known attacks. Primarily works off traffic from Layer 2 of the OSI model to find and prevent malicious data within traffic from getting into the environment by interrogating all network traffic, protecting against things like malware.

IDS - An IDS detects intrusion, keyword being detects. This tool is mostly used for visibility, network forensics, analysis. Where an IPS has rules put in place to prevent intrusion, and IDS uncovers security policy violations, information leakage (spyware, keyloggers), etc. in a more passive manner, often reporting findings to a SIEM tool for manual analysis and remediation decisions. Legitimate findings can then be transferred to policies and rule updates on the IPS. All encompassing blocking of discovered findings would cause many false positives, which is why an IDS does not simply act to what it discovers.

Unsuprisingly, part of the diluding of definitions comes from these solutions often being packaged hand in hand, leading other other terms of confusions such as a passive IPS or active IDS. This leads us to the final category, the WAF.

WAF - A WAF works at layer 7 to analyze application layer traffic, often operating as a reverse proxy. It is similar to an IDP is that it has a rules engine set to prevent malicious traffic, with a rule base that may change less, but also benefits greatly from vendor updates (regexes, injection pattern updates). Where a WAF really starts to differentiate itself is how it examines the requests and responses. Rather than simply looking at the sum of the network traffic, its analyzes traffic against the logic of the application, rather than pure signature based checks, before passing messages. Should this service allow special characters? Does it pass SQL commands? This inspection looks deeper at the specific message than an IPS to protect against threats like SQL injection, cross-site scripting (XSS), session hijacking, parameter or URL tampering and buffer overflows.

With this research done I was ready to analyze the functionality against the API Gateway, first by answering the question: "Can an API Gateway replace any of these other tools or components." To the majority of these I would say 'no' without a second thought, but the hard one to analyze is the WAF functionality. Looking more in depth at how a WAF operates (a reverse proxy like an API Gateway) and the protections it provides, there are a fair number of crossover capabilities. With that said, what it really comes down to is level of effort and COTS support. Can you write regexes for example on an API Gateway to protect against SQL Injections? Sure - But honestly, who is going to do it, and properly encompass nesting, white space, etc. to ensure full mitigation, and keep it constantly updated. This type of challenge of course is what has lead the company I presently work for, Axway, to embed the modsecurity opensource WAF into our API Gateway. That we felt there was value in that addition alone should speak to if an API Gateway on its own should be used as a WAF.

Of course the discussion can never just be that simple though. The question arises, if the Axway API Gateway embeds a WAF, should we use it in place of or as a replacement for another enterprise WAF? This can be a very tough question to answer. Is it a question of if modsecurity is enterprise grade? Is it a question of if you should encompass both WAF and other security functionality on the same system, going against well received concepts like 'defense-in-depth'? Is it a question of COTS solutions vs an opensource solution like modsecurity? Would I recommend using the embedded WAF to protect an enterprise?

To answer this I started to think of the implications around the solution architecture, the perscribed usage of an API Gateway, and best practices. Generally when I think WAF, I think DMZ protections. It's always interesting having a conversation where someone may wish to encompass several layers of functionality within an API Gateway such as:

• Threat Protection: Schema complexity checks and validation, positive field validation, certificate revocation checking, digitial signature validation
• Token Services, ABAC/RBAC enforcement, SLA/contractual limitations - throttling
• API, WS, and application hub and single point of administration for communication protocol controls, visibility, and communication auditing. API, operations, service call orchestrations.
• Backend data vault connections and transformations.

Often I ask them about the functionality on its own and where it might normally sit within the tiers of their architecture. Does it make sense to intentionally design an architecture where a tool that is doing DMZ type protections in a layer that is by definition facing a comprimised field of play (external connections) also is working on sensitive data such as customer PII, internal IP, financial data, etc.? Often this leads me to recommending a multitier architecture to handle different communities of interest around the different functionality. With that in mind, my first thought would be to analyze the use cases and where they might lie, and determine if it would make sense to enable the capabilities, or if they are effectively trying to make a square peg fit in a round hole.

The next thing I thought about was how the API Gateway worked in conjunction with the other technologies I defined. I often talk about how an API Gateway can be used to enhance security as part of a defense-in-depth solution, enable more agile development by changing the paradigm around security controls, and enable a better end user experience. The challenge with global policies is that when they become too strict they cause false positives, and when they become too lax, you open yourself to security threats. Recently a former colleauge of mine wrote an article on the value of an API Experience Mediation Layer (http://nordicapis.com/api-mediation-why-you-need-api-experience-layer/), which I would encourage anyone reading this post to read as well, where he says "organizations must consider an application architecture and integration strategy that embodies flexibility and agility". Where a WAF extends an IPS by examining message and processing logic, an API Gateway extends this down to a per endpoint level and can put the control of this into the hands of each developer without compromising global security rules. For example, positive field validation is a much easier and less error prone way to examine messages, but try getting per element checks put in place by the team that might run an enterprise level WAF. Using an API Gateway as a mediation layer for exposing endpoints and the communication between internal applications and APIs allows a more granular control of security, without the global security change request cycles. Of course with that said, the WAF as embedded in the Axway WAF allows for both global and more granular control. Maybe some services would benefit from special character checking, where others would need to allow it. As a result, this still does not provide the silver bullet to answer the question.

Ultimately I found myself stepping back and asking, if I had to purchase a WAF and deploy it, would I choose to go with an API Gateway, use an embedded WAF as part of an API Gateway for the flexibility it offered, or look to go with a dedicated WAF? I found myself leaning on the side of the dedicated WAF ultimately. While the grainular functionality that the embedded WAF offers is great, it also is an opensource WAF that requires a level of knowledge to configure, and perhaps more attention over time to maintain than other COTS WAFs. The value of COTS solutions support also very much comes into play. Now this does not minimize in my eyes the value of the embedded WAF for more granular, endpoint level security controls and protections, but when it comes to replacing an enterprise WAF that is already in place or purchasing it solely for WAF functionality, I believe there are better options out there, much the same as I would not recommend our embedded load balancing functionality or identity stores within the API Gateway as a replacement for enterprise grade COTS products.

With that said, it can never be that easy. Having this discussion a customer came back and said 'We need the API Management capabilities now and don't have the funding for another COTS WAF. Would it be better to run without a WAF or use the API Gateway to provide those capabilities as well'? This of course is the million dollar question, perhaps not even figuratively given the potential IP or reputation losses a breach can bring. If an API Gateway is handling other use cases in an app tier and there is no WAF in front, should the WAF functionalities be used to provide that capability? My answer is yes. At that juncture all external defenses have been passed and the end user has connectivity to the box, so the segmentation of security duties does not really come into play. The option to use the embedded API Gateway WAF vs another dedicated COTS WAF is off the table, so no choice there. Ultimately, you are adding protections at zero cost, other than potentially a little extra processing time, and gaining WAF security.

In conclusion (tldr):

• Is an API Gateway by itself a WAF replacement? Absolutely not.
• Does the Axway API Gateway implementation give enhanced security capabilities? Definitely.
• Should it be used as your enterprise WAF in place of or as a replace to another COTS WAF if its role reflects one that is contained and traditionally resides in the DMZ? Maybe, depends on if you are willing to put the investment into configuring and maintaining the modsecurity WAF that is embedded. It may not be my first choice, but it's not something I would object to if the risks and challenges were understood, and the savings of acquiring a COTS WAF outweighed the effort to use it in place of another option.
• Should it be used if the API Gateway is connecting to other tiers and/or processing internal application traffic? If its the only option you have for a WAF, its better to use what you have than nothing at all.