4 Questions to Audit API Security
It's been said, "A picture is worth a thousand words." Just as true is, "A good question is worth a hundred answers."
Good questions force the inquirer to seek advice from others because one can’t answer them without more time, insight, and experience.
The following questions aren't the most erudite or wise, nor are they designed to delve into the meaning of life. Still, I hope they provide lines of inquiry that lead to a better understanding of how APIs fit into security and business.
Why apply this questioning to API security? Even in the first half of 2021, API attacks had increased by 348%. With the proliferation of APIs, there's no reason to think that the increase will slack off, and we have every reason to plan for an increase in the number and complexity of attacks.
Because customers rely almost solely on a business's reputation for its third-party integrations, those customers cannot directly vet the security and privacy aspects of the APIs used in products. This furthers the importance of enterprises ensuring each API's security and privacy.
These questions might have easy answers at the onset of an API implementation, but how will they be addressed in 2, 5, or 10 years? Are the APIs implemented in a way that paves the way for the inevitable advancement in API technology?
Who is responsible for API security and operations?
Security is often seen as separate from operations, but the two are usually inseparable. When IT Support builds a workstation, that workstation needs to follow some list that includes security at deployment, ongoing management capabilities, antimalware, and automatic updates. Security and Operations go together.
Discover who is responsible for APIs' design, architecture, implementation, and security, including inventory. While inventory seems to be more of an entry-level project, you can't protect it if you don't know it's there. The first two controls of the famous Center for Information Security (CIS) Controls are inventory and control of enterprise and software assets. If an asset is unknown or forgotten, it doesn't get secured and remains a prime target for threat actors.
This question leads to ensuring that APIs get audited to protect the CIA triad more fully.
This line of questioning also includes some form of testing. Testing needs to happen whether performed by an internal or external party, a current or new position, or a manual or automated method.
Another aspect of this question is monitoring APIs for updating, upgrading, deprecation, or decommissioning (if you wondered, security and operations are also closely related to project management). The technologies involved with APIs need to stay on one's radar.
In securing APIs, OWASP has some reliable resources for starting and maintaining, including the OWASP API Top Ten and numerous cheat sheets with plenty of details on API security and testing, such as this one that deals with GraphQL. A good starting point for security leaders is to read the Top Ten to become familiar with the concepts and terminology, then pass the cheat sheets to those who a) are dedicated to security and operations and b) enjoy diving into the details.
Another good resource is the Salt Security checklist. This is another one where the main page is suitable for a leadership overview, and those responsible for technical details will appreciate the list.
Integral to API security is documentation. For integrating APIs, read the documentation. A couple of excellent examples of API documentation are SendGrid and Stripe.
What regulations are required?
Knowing regulatory requirements helps determine how APIs get set up to handle the type of data that traverses the APIs. While securing data is always of paramount importance, the level of detail required by regulations will increase according to the regulation. For GDPR, e.g., even something seemingly trivial like a username and IP address can be considered PII and must be rigorously protected.
Some regulations will denote the need for third-party testing. Companies need to ready themselves to ensure compliance testing of any APIs that fall under the purview of regulatory needs.
What's the business plan?
Knowing where one is headed for business or compliance will play a significant role in implementing APIs. Beyond what is already required, what regulations or certifications might a company seek in the future? What market might you enter in a couple of years? Is the API architecture expected to remain for years? Knowing the path will tell what kind of data will flow through the APIs.
This is related to knowing what regulations one must follow, but it differs because one may not know now what regulations are needed. Knowing what market the business may enter will open new vistas for required regulations.
There's no way to foresee the future, but with professional forecasting, an API plan becomes a calculated risk instead of a gamble.
Knowing what's ahead is vital to implementing APIs. A business must be ready to maintain, change, and even overhaul. If the plan is faulty or non-existent, then no amount of automation or training will compensate for the day that the entire architecture needs to be revamped.
Who's the expert?
Do you have a trusted advisor to contact to ensure APIs are being done right? No one knows it all. No one is an expert at business and finance and engineering and HR and QA and security and IT and, and, and... There's no need to attempt to know it all. Just as companies hire someone to manage finance, hiring and recruiting, daily operations, IT, and every other field, a company also needs to hire someone - whether on location or virtual - who knows APIs.
“Where do we go from here?”
The better the questions, the better the answers. Going above and beyond the immediate need of customer requests and revenue will lead to a long-term reputation for considering all the facets of API use, including improved customer experience, better product reliability,
API security is more than just a technical, DevSecOps, Shift Left, or East-to-West model. APIs are business enablers and revenue generators, making it essential to have a 360-degree view of APIs.
