purpose-built for web application and API traffic, but WAFs were designed
in a time when web applications were largely static. As design patterns
evolved and applications became more dynamic and API-centric, some
vendors began including signatures and rules to cover APIs. However, such
rules are based on per-transaction analysis and pattern matching, and rules
are typically too generic to cover the unique business logic that most
organizations build into their APIs. Use IPS, NGFW, and WAF if you must, but
expect a low-bar of protection that mainly covers common injection attacks
like XSS and SQLi. JSONi and XMLi may be covered, but it is not a given and
could fall to your API gateway. You must also ensure that they support the
API protocols in use in your organization. If a WAF only supports SOAP APIs,
and you’re creating REST APIs, it’s useless as an API protection. Ultimately,
your runtime protection approach should go beyond these traditional
technologies and make use of AI/ML and behavior analysis to detect API
attacks.
2.
Use threat protection features of your API gateways and APIM if available:
similar to WAFs since they are both network-based proxies, ensure that you
are enabling the threat protection rules and message filters within your API
mediation technologies. It’s still a low bar for API protection, but it is more
API-focused than WAF. Unlike WAFs however, these rules are likely not as
well maintained by the vendor. Signature updates are relatively rare. To be
effective, they also likely require tuning based on a given API schema to
control allowable parameter values within API requests. Because this
approach is difficult to scale operationally, organizations will sometimes
leave threat protection mechanisms with default settings or disabled
entirely.
3.
Dostları ilə paylaş: