In the art of writing, time gets condensed. For example, a play may take a couple of hours to act out but a quarter of the time to read. This visualization technique occurs all the time in writing, allowing the reader to soak in much information in a short sitting.

This time variance also takes place in reading about securing one’s organization. The way the documentation is written is necessarily more condensed than the real-life actions needed to enact it. Those words, even if the documentation is long, belies the fact that securing anything in an organization takes consistent and detailed effort and requires much more time than reading and checking some boxes.

Below are several items to consider to improve your API security posture. In the process, realize that these items take more than just a 30-minute meeting and some brainstorming. There are innumerable potential corporate scenarios, budget allowances, documentation, training needs, and so on to consider when securing APIs. In this post, I’ll follow the People, Processes, and Technology (PPT) principle to present ideas.

People

Personnel is number one in securing APIs. Whether they work on the APIs directly (e.g., developing private APIs) or are involved in some form of vendor and contract management to ensure API maintenance (e.g., selecting partner APIs), people are on the front lines of the architecture, implementation, maintenance, and security of APIs. Because every organization is different in size, revenue, industry, and technology, determining the appropriate number of personnel may adjust over time.

At least one person within an organization must take the lead on API security. That someone needs to understand various API topics to lead the team(s) and manage all the details. To avoid conflicts of interest, this person should be someone who doesn’t do the work and can advocate for obtaining the proper resources, which incorporate budget, training, time, and the appropriate number of people to perform the job.

Another role, not necessarily requiring a dedicated individual, needs to determine and enact data classification and protection. What data goes over the wire? What is stored where, and by whom? With the ever-growing and changing international landscape of privacy regulations, data that goes over, in, and through APIs may have compliance restrictions.

Processes

Before a security program is fully developed and implemented, an incident response plan is necessary. My family and I recently moved. Amid all that goes on with packing, driving, and feeding people, one of the first things to do when moving is to find the nearest hospital in the new area. It’s not a legal requirement nor a joyful item on the to-do list. But part of living somewhere is to be ready for emergencies. It’s much the same with improving an organization’s security posture — have a plan for emergencies. This is also required by programs and regulations such as ISO 27001 and 23 NYCRR 500 (aka New York Regs).

Understanding your Software Development Life Cycle (SDLC) is a must. Whether all-inclusive or referencing other policies, this is likely where the preponderance of your programming details — including API guidance, though probably not the actual API documentation — will live. Many aspects should be easily accessible here, including:

• The model used (e.g., continuous or shift-left),
• Data classification
• Business fit and purpose
• The need for separation of test and production environments
• Types of testing (e.g., stress, regression)

The SDLC is one of those time-warp sections in writing. While it only takes up a paragraph here, in reality, it could take many months to determine and document.

Determining the document repository is part of the process. Whether it’s pre-existing online documentation (e.g., Twitter developer documentation) or maintaining one’s own, keeping API documentation readily available is vital for developers to keep the details consistent. This should be referenced in the SDLC, but because it’s so detailed, it would be a corollary.

Having separate test and production environments and independent test data is vital to security and customer trust. In my work with Request for Proposal (RFPs) from customers, almost every RFP has a question about separate environments to ensure that real customer data isn’t used for test purposes. If actual data is used, it must be protected with the same rigor as the production environment, which can be cost-prohibitive.

Technology

Of primary importance are access control and all the elements and acronyms involved — this encompasses 2FA, least privilege, IAM, PAM, and other concepts. This includes who has access to the behind-the-scenes work and the public-facing APIs themselves. Does the API verify who or what is performing the call? Does the IAM authenticate and authorize the requested transaction?

Related to authentication and authorization is protection from DDoS, brute force, and credential stuffing attacks. A normal user will not attempt authentication thousands of times in a few seconds. Thus, implementing API throttling or rate limiting goes a long way toward API protection. Of course, thousands of people may access an API at once, so throttling is not a cut-and-dry situation. But it’s an important technology to put in place.

In the same vein as protecting from access attacks is the overarching idea of detecting and stopping most any kind of attack. Not all attacks can be prevented. Low-and-slow attacks that rely on minimal yet prolonged attempts — a trickle effect — require advanced technology to detect. But many attacks are common and can be seen and stopped at the point of entry.

You can’t protect what you don’t know about. It’s hard to say what’s the most critical cybersecurity practice, but having an automated inventory is near the top. The CIS Controls place keeping an inventory of enterprise and software assets as a top recommendation. Many other professionals, including myself, would similarly rank this as a high priority.

What’s Next?

In a communication seminar I attended several years ago, the presenter shared many terrific concepts and specific action steps. But his last point was the most memorable — “make just one change.” Don’t do all of it at once — just do one new thing at a time.

There’s plenty to do, but don’t let “paralysis by analysis” set in. Get moving on your API security initiatives by starting with one positive change.