Did you know that one of the first ever recorded security breaches occurred in 1903? The setting was a room in the Royal Institution Hall filled with press and VIPs where Guglielmo Marconi was about to demonstrate his long-range radio telecommunication system. While making preparations for the demo, an unexpected sound suddenly came from the machine. It was sent there by an outside individual that managed to send his own information to the device while physically being miles away from it. The audience initially didn’t have a clue that an intruder was sending information, as it was Morse-code which was heard and not everybody understands Morse-code. But, the hosts of the demonstration certainly understood very well that they should do some explaining as their claims of having a private messaging channel between two entities immediately collapsed. It is understandable that the press loved and scandalized such a scandal.
The more services you offer, the higher the risk for data breaches
Fast forwarding to today we regularly hear about data breaches. In just 2019, there were more than 5,200 data breaches reported, a staggering 33% increase compared to 2018. Intruders are on the lookout for new data entry points which they can get their hands on every minute of the day. In several cases, these data breaches resulted in thousands of sensitive data-records to be exposed and be an embarrassment to the victim-company.
Data as commodities
Companies have become more transparent. Data is exposed to a broader audience than ever and company-internal data is more widely shared with business partners and consumers. The outreach of data is growing by the minute. Companies have learned that there is value in their data considering there are companies that do just that, sell their data, like Amazon, Tesla, Microsoft, Facebook, Google and many others. As we can see from The Economist post in 2017: “The world’s most valuable resource is no longer oil, but data”.
As data is exposed through APIs the risk in seeking the public with company-APIs is that it’s like sugar to flies and thus attracts both wanted as well as unwanted guests. How often do we hear about a company opening up their API that very soon is breached as their security was not up to par? An example of this is when the French government released their private chat app TChap in April 2019. They touted it to ‘be more secure than Telegram’… Two days later the first breach report appeared on twitter.
API usage has grown significantly in the last few years. It’s booming business. Many companies have been able to make their APIs their biggest revenue channel. According to F5 Networks, over 40% of companies has an API gateway implemented and 27% was planning to do so in 2019.
Change is challenging for governance
The IT-enterprise is becoming more complex by the day. The uprising of SaaS, Cloud and self-managing development teams has put pressure on the ability to apply governance by IT departments. It is becoming increasingly difficult to apply and enforce security policies on all aspects of the IT-landscape as it changes in a rapid and decentralized way. Development teams look for readily available data exposed through APIs and will consume them when needed. This means that external data is coming into the organisation with potentially less strict security policies applied. Also, these developers develop APIs themselves and make them available as soon as their product owner requests it. New potential data-risks are added to the organisation on a daily basis.
Embracing hybrid clouds and containerization puts stress on the in-place security perimeter within the infrastructure. Its fading and scattering throughout the IT-landscape. Security governance must change from providing a single perimeter boundary to having multiple and securing services individually rather than through a centralized access-layer alone. You can no longer rely on just a single component in your infrastructure to protect it all against intruders and data-attacks.
Coming to the key of this story; I have hopefully been able to make clear that you have an obligation to protect your company data in the best way possible to prevent it from seeping, or gushing maybe, out on the internet highway. Exposing new or changed APIs on a daily basis increases the data-leakage risks and you need to make sure you get your API-security up to professional level to prevent it. Having this in mind, we started working with 42Crunch to help solve just that.
The 42Crunch API Security platform offers three services to protect your APIs. The entry level service performs a security audit on your API. You load the OpenAPI Specification of that API, which describes what information goes into and comes out of your API, into the platform and it will perform many security checks against it. This audit service checks the API for common pitfalls and insecure specifications of your API. You get a report from the scan that summarizes the API-security score. Defining a company-minimum score for the API-security is the first step in securing your APIs.
Once you have graded the API through the audit-check the next step is to validate whether your API actually does what it says it does by sending malicious data into it and validating its response. This is done through what 42Crunch calls the ‘Conformance Scan’. This scan will send various messages into your API, using authentication information to access that API, and inspects the response. Does your API handle incorrect and insecure data sent into it well? Again, an API-security score report is generated indicating the security score. This is the next KPI to measure your APIs and which allows to define a minimum threshold before the API can be deployed to production.
The first two security measures require your API-developers to develop several validation-layers in their code to make sure that no insecure data-requests can be performed, nor will unintended data be exposed. If you stop here, then you rely solely on the two aforementioned security audits to validate your API-security. To become truly secure, you should make sure that no developer can forget about any of the security concerns by separating the responsibilities between API-security and business-logic implementation.
Inject an API-firewall in front of your API to do the security-checks on incoming and outgoing messages for you continuously. This will alleviate your developers from having to implement various security related checks by themselves on each API they develop. API-security will ‘just be there’ when the API is deployed into your environment.
The API-firewall service is provided as a Kubernetes sidecar concept or can be installed as a gateway-function in your infrastructure. Each and every API-call that is done to your API will be validated, scanned and allowed or denied access to your API. Even error messages returned by the API-firewall are secure in that they consist of a UUID that hides the true reason that the request or response was stopped. The 42Crunch API Security platform allows the API-operator to inspect the UUIDs and find the root cause of the failure. Even exposing the reason behind a request or response failure is risky as it exposes the internals of your API which can be used by introducers to find flaws it in implementation or architecture.
Download also our Advanced API Management Guide to learn more about API aspects and where we also discuss API Security.