Welcome to the third and final part of our blog series on API Data Security. This blog series will cover details regarding the API-First Mindset in today’s tech world and the Importance of API security. Read part one of the blog here. You will be able to access our whitepaper titled API Data Security here. On that note….
The API-First Mindset Traditional API Data Security Solutions
API data Security has been a concern since its inception. A single breach could expose all the data that is being transmitted by an API. However, traditional API data Security solutions have a reputation of being complex, poorly implemented, rigid and often ineffective, when considering many of the modern risks and threats.
Many of the traditional solutions:
Sit inline - they require extra software agents, sensors or sidecars.
Have limited deployment and integration options.
Introduce complexity and risks.
Are usually ineffective in finding and blocking malicious activity.
As technology evolves, hackers are also coming up with innovative ways to tap into any possible channel for procuring data. This means that API data Security experts also need to up their game by coming up with a fool-proof strategy to nip security issues in the bud.
Methods For Ensuring API data Security
The F.A.S.T Security Strategy
We at eXate subscribe to the F.A.S.T. security strategy with four simple, yet powerful steps to ensure API data Security. The four pillars of F.A.S.T. are:
Find
Analyse
Solve
Test
Pillar 1: The ”F” - FIND
The Find (or discovery) phase is for understanding what you have and what are the potential risks you may have, using your API catalogues, code repositories, documentation and data dictionaries will enable you to understand the scope of the security strategy. It’s highly likely that you will discover services that may not be well documented or rogue services – this is all part of the aim, understanding your whole estate and consequently your whole risk.
Some of the aspects that need to be unearthed or found out are:
What type of data are your APIs interacting with?
Which parts of the data being used is sensitive?
How is it routed (internally, externally, public or private)?
What are the associated physical resources (instance ID, server name etc.)?
Which application or business unit does it belongs to?
Who is the owner?
What is an APIs actual usage?
Who or what are the consumers of the APIs?
Pillar 2: The ”A” - ANALYSE
The next step in the four-phase process is to Analyse the information we generated in the Find stage. Analysis must inform us if and how our services are protected and if they are being misused or open to misuse. There are many common misconfigurations that lead to API data Security vulnerabilities.
Common problems we are looking for are:
Internal APIs that are accidentally open to the internet.
APIs with no rate limiting.
APIs with either no or inappropriate authentication.
APIs with no payload injection checks.
Incorrect or inappropriate consumer access to data attributes.
Ineffective monitoring or analytics.
Hosting and infrastructure vulnerabilities.
A good and thorough analysis will greatly depend on the quality of the existing documentation. The process of documenting and analysing all the APIs could be a daunting one, however the work will pay dividends. The analysis will produce a much-improved picture of your API estate. It can be subject to inaccuracies due to a number of reasons – documentation issues, source code inaccuracies etc. But without this information it is impossible to understand any risks you have.
Pillar 3: The ”S” - SOLVE
An organisation’s ability to Solve API problems is only as effective as its ability to Find and Analyse them. But what do we need to do, and which are most important? There is no magic wand, and the solutions will vary based on the identified issues.
Core API issues such as lack of rate limiting or incorrect authorisation will need remediation, often code remediation. Others will be configuration issues which can be quickly remediated at the infrastructure or gateway layer.
It is important at this juncture to look at your governance processes. You may have now resolved the known problems, but how will you stop it happening again? What are the API quality gates and how will they be enforced moving forwards?
Our aim is to make API creation and consumption as simple as possible with patterns and automating the ecosystem as much as possible from design to implementation to deprecation. Baking in governance and security is a sure way to increase delivery speed, without compromising quality or increasing risk.