Personal Identifiable Information (PII) matters to all of us. It’s what helps make up our digital identity and we want it to be only in the hands of those we give it to; data privacy is a fundamental human right. But, as application programming interfaces (APIs) continue to become an ubiquitous way for data to be exposed to the digital applications and services we all use, there’s a growing threat of API attack.
Enterprises are responding by securing, encrypting, and masking data in APIs in production, but as we’ll discuss in this article, this is not enough. To effectively tackle this threat and ensure data privacy as a differentiator, shift left and add in a design-time approach to data protection.
PII data in APIs: a growing threat
Every organization, regardless of size, deals with sensitive data embedded in applications. Digitization brings systems together with APIs as standard integration patterns. Modern integrations leverage various ontologies and taxonomies that support a range of information models in areas such as:
- Cognitive
- Artificial Intelligence
- Business Intelligence & Analytics
- Search
- Data Lakes/Warehouses
- Records Management
- Knowledge Graphs
- Predictive Analytics
- Deep Learning
- Client Relationship Management
- Information Tagging
- Sentiment Analytics
All APIs transfer data within their schema (request, response, and parameters), and this can include PII data. Specifically, PII becomes visible at two points:
- In API payload field names
- Once the API is deployed and running
And this PII data is a high value target for cyber attacks. In a recent report, Spirion found that a sensitive data attack happens every 10 seconds, and in January 2021 alone, 878.17 million data records were compromised (more than the entirety of 2017 to put this into perspective).
And the issue of sensitive data is an industry-wide problem, affecting sectors including (but not limited to!):
- Accounting Firms
- Manufacturing
- Banking and Financial Services
- Facilities
- Investment Management
- Health Insurance
- Hospitality
- General Insurance
- Legal Firms
- Government
- Medical Administration
- Medical Devices
- Public Services
- Retail
- Telecom
- Travel
- IoT
It’s no surprise then, that regulation around data protection is ever-tightening. Both at the legislation level (e.g. GDPR in the EU and CCPA in the US (plus similar regulation in Canada, Australia, and New Zealand to name a few)), and at the industry standard and data security framework levels (e.g. HIPAA in the healthcare industry, the ISO 27000 family of standards, and PCI DSS for branded credit cards in banking).
Data privacy is likely a high priority for you. Get it wrong and it’s not only potential fines from the regulators; it’s damage to your brand, competitive stance, and customer loyalty.
Production-only API security is not enough
You may well be focusing on securing PII data in APIs in the runtime only. Standard tactics include encryption and tokenization, access controls, and masking for the APIs, often with standalone tools.
However, there are challenges for enterprises with this approach:
- PII is a moving target. As discussed before, changing and tightening regulation and security frameworks and standards are ongoing. But the actual definition of what’s considered to be PII is changing too. It’s hard to keep up to date.
- The APIs that are handling the PII data (as well as the data itself) are stored across many vendors and platforms. It’s hard to know what’s running where at any given time.
- We can’t expect API provider developers to all be PII experts all of the time! While compliance and security teams can help, it’s developers that are creating the APIs that will be handling the sensitive data. It’s hard to ensure APIs that expose PII are well-designed and secure.
These challenges mean that perimeter-based, one-time masking, and production-only API security are not enough.
The solution – add a design-time approach to securing PII data in APIs
We recommend you look to shift left and ensure API data security is enforced across the API lifecycle. The target state is a design-time approach that’s integrated to runtime, to enable monitoring of PII data transfer as it flows across your entire organization (data in motion).
2 tactics to get to the target state
Track PII from one holistic catalog
If all your APIs (plus Services, Events, and more), both in-flight and in-production, are captured in one centralized catalog, you create a single pane of glass for where PII data is handled via APIs across all your landscape.
You can also track your entire catalog against industry standards and security frameworks, to gain an accurate view of what’s in and out of compliance. And, when regulation and standards change, you can easily find out which APIs need to be changed to remain compliant.
Leverage configurable API governance and lifecycle management
This can be used to provide guardrails and enablement to help API designers know which schema fields are classed as PII as they design new APIs (or update/extend existing ones). You can provide automated checks to ensure API governance and regulatory thresholds are met – before APIs move through lifecycle states and before they’re deployed to the runtime.
This approach also allows you to ensure that APIs are not just encrypting sensitive data, but they’re designed properly too with the correct policies (e.g. authorization, logging, monitoring) applied upfront. This adds to your overall API security maturity and moves closer to the goal state of “security by default”.
Utilizing these tactics as part of a design-time approach ensures PII and other sensitive data handled by your APIs is secure. Done right, data privacy can be a differentiator!
Book a demo today to learn how the ignite Platform can support your design-time (integrated to runtime) approach to API security.
