devopsy.kinsta.cloud

Tag: API security

  • The Evolution to Cloud-Native Applications and APIs

    The Evolution to Cloud-Native Applications and APIs

    If you’ve spent any length of time in application development, you’re familiar with change. It’s the only constant.

    And along with how we build applications come changes in the techniques used to keep them secure.

    Securing modern applications requires more diligence than ever before. A review of how application development has changed over the past decade will explain why more diligence is necessary.

    Traditional Web Applications: Placing an Order From a Menu

    The traditional web application operates like ordering food from a menu at a restaurant. You have a list of dishes available, and you ask for one. The chef decides which ingredients are necessary and how the plate looks when it arrives.

    In a traditional web app, the client fetches a URL. Let’s say you want to see a dashboard of marketing metrics, and thus your browser retrieves example.com/dashboard.jsp. The client doesn’t control what’s on the dashboard; it just knows to ask for it.

    The web server processes the request in three steps:

    1. The web server pulls data from the database.
    2. The server builds an HTML page with the data placed inside.
    3. The server returns the rendered HTML page to the client.

    The web server decides what data goes into the dashboard and where the data goes. The client simply asks for a resource and displays what the server returns.

    In this model, the client typically has very little code. It requests a URL from the server and displays what comes back. All rendering and data processing happens on the server.

    Modern Web Applications: Buffet Style

    Modern web applications put the client in control. It’s more like a buffet than a sit-down restaurant.

    The client is often a Single-Page Application (SPA), or an application that dynamically updates the same page instead of always requesting a new one from the server.

    In a buffet, you take your plate and pick and choose the foods you want. Each dish can have multiple configurations based on your needs at the time.

    SPAs work like those plates. Instead of a single server creating an entire page and returning it to the client, the client knows how to make the page and asks only for the data required to do it.

    Typically, Application Programming Interfaces or APIs provide this data to the client. Business logic is exposed to clients using APIs that return only what the client needs. Maybe the client only wants the last 20 notifications for an account or the ten most recent emails.

    The use of APIs for business logic and data retrieval opens up the world of application development. You no longer need to build a web application. You can use a mobile application instead. You can use any technology or form factor to access the data, from mobile to Internet of Things (IoT) or other developers building applications of their own.

    JSON, a lightweight data format, is one of the most useful enabling technologies for modern applications. It allows all of the APIs, the client, and the database to store and transmit data using the same format. There are no data transformations necessary, which helps keep the application responsive.

    Going back to the above dashboard example, an SPA wouldn’t ask the server for the entire dashboard at once. Instead, it would ask the appropriate APIs for the specific data it needs to build the dashboard itself.

    The desire for APIs and ultimate flexibility and speed of development gave way to the development of microservices. These services are kept small on purpose to be updated independently of each other and more frequently.

    SPAs emphasize the client, leading to more complex code in the clients and the risk of security vulnerabilities in the clients (more on that later). But this change has opened up transformational technologies like IoT devices.

    From Monoliths to Microservices

    A common theme in the evolution of application development has been toward breaking functionality and features into smaller and more granular components.  Just as with the SPA example above, the functionality of the web page is in isolated components, the same trend is true when you look at overall application architecture in general.

    Where a legacy application might have been designed with separate modules and functions, each internally making calls to each other, modern design now breaks out separate functions into discrete services.   Now rather than each development team maintaining similar code/functionality inside their application, many business functions are separated into clearly defined services.  Consider an ‘address verification’ service which can be used by many other applications.  The functionality of validating an address is decoupled from the ‘customers’ that use the service, which introduces value into the delivery lifecycle. This approach enables development teams to focus on smaller, more granular changes and therefore shorten their cycle time and accelerate delivery.

    Microservices – a Response to the Accelerating Pace of Change

    Digital transformation and the rapid acceleration of  the pace of change within the industry dictates a new way of thinking. This thinking is encapsulated in the following quote by Bronwyn Clere, Executive Director for Capital Planning & Delivery, at Telstra Corporation in PMI’s Pulse of the Profession 2017 report:‍

    We are implementing features and products and using technology that were not invented 18 months ago. No longer can we afford these large monolithic programs that go on for two to three years. We know that what we set out to do at the beginning of that time is not what we will finish out doing. So, we are focusing on very rapid delivery cycles, asking ourselves: How do we mobilize a project very quickly? How do we use the right delivery techniques to work through it quickly? How do we get product into market or to customers or into the business?”‍

    Business leaders everywhere are demanding technology teams deliver faster. As a result, teams have adopted new ways of working and new ways of architecting their solutions.  We’ve seen widespread adoption of Agile, CI/CD,  and DevOps tools.  Similarly, application development and architectures have evolved to further enable velocity.

    A Tour of Cloud-native Architecture

    The increasing pace of change would put significant stress on any IT infrastructure. But cloud-native architecture has fundamentally changed how applications can be built and scaled.

    Cloud-native technologies, such as containers, service meshes, microservices, immutable infrastructure, and declarative APIs, empower developers to build and run scalable applications on public, private, and hybrid clouds.

    Cloud-native architecture focuses on creating loosely coupled services with high resiliency. Developers can make changes frequently without negatively impacting the entire system.

    Let’s take a quick tour of cloud-native applications so you can see how they differ from traditional web applications.

    The bulk of cloud-native applications include many microservices deployed in containers. Each service is isolated from the others and can be destroyed and recreated easily without affecting other services.

    Often an orchestration tool like Kubernetes is used to monitor all of the microservices used in an application. Orchestration is necessary when hundreds of services serve a single application. Kubernetes can detect malfunctioning containers or services, destroy them, and recreate new ones to keep the application running smoothly.

    Each service can be created and updated independently from all the others. Each service can use a different programming language altogether. As long as each service exposes a documented API, the language used behind the scenes doesn’t matter.

    Below is a diagram of Microsoft’s eShop on Containers open source application. It demonstrates what a real-world application looks like using cloud-native technologies.

    In this example, the development team building the Marketing microservice can make changes as often as they want without affecting the ordering or cart functionality. Different technologies can be used within each service and each service has a separate datastore. Flexibility and speed are the hallmarks of modern development.

    In the next post, we’ll dive deeper into specific challenges and considerations you need to take when adopting cloud-native applications.

    4 Necessary Mindset Shifts For Cloud-native Success

    The pace of change affects more than technology. Processes, management styles, and even ways of thinking have to adjust to make modern application development successful within your company.

    Delivery: Think Agile and Devops

    Because of the intensive need to shorten delivery cycles and to automate delivery, cloud-native architectures embrace delivery practices that support short and responsive turn around. Developers can deploy new code in seconds, with some companies pushing new code to production hundreds of times a day.

    As a result, your project management processes have to change. Agile practices (Scrum, Sprint, Lean, etc.) along with strong DevOps capabilities (i.e. trunk based development, CI,CD,etc) best support wide scale microservice development. It’s critical to get delivery, cultural, and organizational changes completed before trying to do cloud-native development at scale. The DevOps Handbook is an excellent resource for those new to DevOps development.

    Production: Think Products, not Projects

    The days of ‘throw it over the wall’ and let Operations manage the application are over.  Given the complexity of modern applications with multiple microservices and associated APIs,  development/product teams need to ‘own’ the application in production as much as they do in development.  In order to successfully scale your adoption of cloud-native applications, you need to explore and embrace “Product Management” over “Project Management” as a practice to manage the full lifecycle of your application.

    Think of your application as a long-term product that will change over time. Market insights and customer feedback will continue to improve it. It’s not a one-and-done exercise.

    Security: Think Security Everywhere

    Security is a major concern in this new environment.  The traditional approach of building a fortress of defensive walls and moats around the application and then you ‘trust’ the activity inside the fortress is insufficient in a world where the individual elements of the application are expected to communicate with other components.  On many levels, the new paradigm for security is one where each microservice, each component must have security built in, they need to embrace “zero trust” as a policy for how they operate.

    Trust No One – Zero Trust in Microservices

    Zero trust is a security architecture that lives by the motto: “Never trust, always verify.” It means verifying every request before returning data or performing an action.

    In a traditional network architecture, we protect the perimeters. Firewalls and DMZs only allow certain types of traffic into the network. We use VPNs to enable secure communication between company servers and remote workers.

    However, the biggest flaw with this security method is that traffic within the network is implicitly trusted. It’s similar to a bouncer protecting a nightclub from a long line of wannabe party-goers. It’s tough to get into the club, but once the bouncer lets you in, you can pretty much do whatever you want.

    In a zero-trust network, all traffic is considered suspect. Just because a request comes from within your environment doesn’t mean you can trust it. Check every request first before the service returns data.

    Microservice architecture requires a zero-trust architecture to be secure. It’ll ensure no requests fall through the cracks.

    Diligence, Compliance and Oversight of Cloud-native Applications

    In addition to zero trust as an approach to enabling microservices to operate securely, organizations must rethink how they monitor and manage their security posture.  We’ve covered several significant changes in web applications, especially in the last ten years.

    • Faster change than ever before
    • Small, independent services on different platforms
    • Autonomous teams
    • Cloud-native
    • More moving parts
    • More can fall through the cracks.

    New levels of diligence are required to secure this new breed of application. Cloud-native applications and microservices create new security vulnerabilities companies must account for to keep up with attacks.

    In the next post, we’ll cover what security measures need to be in place to protect cloud-native applications.

  • Game On: Secure Coding Virtual Summit 2021

    Game On: Secure Coding Virtual Summit 2021

    Agile organizations are looking for ways to win at security without slowing down their release cycles. That’s where DevSecOps comes in. The days of a hands-off security approach for developers are over. Organizations implementing DevSecOps to integrate security into their DevOps framework are able to release secure software faster. Developers test code for potential security vulnerabilities earlier in the pipeline to fix security issues in real time to avoid costly delays.

    At Secure Coding Virtual Summit 2021, industry-leading AppSec and DevSecOps practitioners, analysts and visionaries will come together to share their best pro tips and power ups to level up your code security. The agenda for the virtual event, taking place March 24 from 10 a.m. to 6 p.m. ET, features a mix of topics including AppSec, threat modeling, API security, container security, case studies and more.

    The most brilliant security luminaries from OWASP, Okta, Microsoft, Secure Code Warrior, WhiteSource and many other well-known IT companies, will discuss:

    • How to level up your secure coding strategies
    • How to run an AppSec program with open source projects
    • The best practices for securing your APIs, the attack surface of an API and common authorization problems
    • The concept of threat modeling, its objectives and its role in the SDLC
    • How to transform developers into security people
    • How easy (or not) it is to get a container or Kubernetes cluster hacked on purpose
    • How to create an AppSec pipeline with containers in a short period of time (demo)

    This year’s Secure Coding features outstanding industry leaders, such as:

    • Vandana Verma Sehgal, global board of directors at OWASP
    • Simone Curzi, cybersecurity principal consultant at Microsoft
    • Keith Casey, API problem solver at Okta
    • Matias Madou, CTO and co-founder at Secure Code Warrior
    • Matthew Coles, senior principal product security engineer at Dell
    • Sarah Young, security architect at Microsoft
    • Chris Romeo, CEO and co-founder at Security Journey
    • Dr. Phillipe de Ryck, web security expert and founder at Pragmatic Web Security
    • Richard Greenberg, founder and CEO at Security Advisors LLC
    • Izar Tarandach, principal security engineer at Squarespace
    • Jeroen Willemsen, principal security architect at Xebia
    • Shiri Ivtsan, director of product at WhiteSource
    • Justin Hutchings, director of product management at GitHub
    • Matt Tesauro, senior partner at 10 Security
    • Matthew Butler, principle engineer at Laurel Lye

    Attendees will have access to useful resources and will be able to interact with sponsors to power up their secure coding strategies. There will be live Q&A chats with keynote speakers to get your burning questions answered. Attendees will also have the opportunity to hunt for Easter eggs to boost their player score for a chance to win a PlayStation 5.

    To see the full agenda and to register, please visit the Secure Coding website.

  • OpenAPI Specification: Perception vs. Reality

    OpenAPI Specification: Perception vs. Reality

    The OpenAPI Specification (OAS) (formerly known as the Swagger specification) provides a way to describe and document REST APIs and their components. It includes details on endpoints, their operations, parameters needed for the operations, expected responses for every operation, authentication methods and even annotations. OAS is an easy format to learn and read, and can be understood by both humans and machines. As you might imagine, this kind of “accessible” documentation is useful and beneficial in a number of different use cases for both development and security teams.

    Developer Relationships With OAS

    For developers, OAS can be used to generate documentation for APIs. Proper documentation can help other developers figure out how best to integrate and use these APIs with their own application.

    Even so, many developers have a love/hate relationship with OAS. Let’s face it, documenting is a far cry from developing. Although it is easy to learn, the actual act of documenting is tedious, manual and time consuming. Frankly, it’s probably one of the least glamorous parts of a developer’s job, and, therefore, many developers only do the absolute minimum. As a result, OAS can be incomplete or, in some cases, missing entirely. Not to mention, when the API is updated, how often is the OAS updated, too?

    In the case of incomplete or nonexistent documentation, developers will muddle through with trial and error, even though this can slow down the development process.

    If out-of-date OAS proves an annoyance for dev teams, what’s the impact on security?

    Security’s Relationship With OAS

    OAS can be consumed by both humans and machines, and both are critical for security’s use of OAS.

    OAS helps security teams (humans) become aware that the API exists, since its documentation is often part of the CI/CD process.

    By examining an OAS file, a security team can understand what the API is supposed to do and, from that, determine if it conforms to or violates the organization’s security policy. As an example, security teams might use the OAS to make sure that authentication and authorization are being implemented correctly, and that sensitive data, like PII, is not being exposed.

    Security teams might also deploy tools (machines) that use the OAS to enforce policy based on what’s in the documentation. As an example, the OAS may specify that, for a particular parameter, a string should be expected; it should be no more than four characters and it should contain only letters and numbers with no special characters. By validating input based on what is defined in the OAS, security tools can check that the API does what developers intend it to do.

    This plan sounds great on paper, but …

    Perception versus Reality

    Imagine a perfect world, in which every API is well-documented as part of the development process. As that API makes its way through the development pipeline, it does so hand-in-hand with an associated OAS. At the appropriate time, before production, security is made aware of the API and the OAS, the team evaluates the details, validates that the API matches policy, gives the thumbs up and the API goes into production. Security and development teams live in harmony and everyone is happy.

    We don’t live in a perfect world. Instead, we must deal with questions such as:

    • Does the OAS exist? In the most extreme cases, the OAS doesn’t even exist. It was never created as part of the development process, so it can’t be used for any sort of awareness. These misses happen more often than you think, giving rise to the problem known as shadow APIs. These APIs slip through the cracks, and make it into production with no documentation at all. While you might be saying to yourself, “Our company would never let this happen!” you should also consider that numerous APIs are stood up by development teams as a test, as part of a beta or as a quick-and-dirty way to get something done. There are more of them than you think, and these shadow APIs create unrealized risk.
    • Is the OAS complete? In slightly less-scary territory, let’s consider an incomplete OAS. You might be saying to yourself, “We have a top-notch development team, well-defined development processes and strict policies around documentation. No API makes it into production without an OAS!” Perhaps, but the devil is in the details, and those details are often missed. I’ve worked with countless customers who have happily and confidently produced an OAS in which critical details don’t match the reality of the API. Sometimes they’re not complete. Sometimes they’re missing all together. The industry calls these missing details shadow endpoints. Yes, someone did produce an OAS, and security was aware of the API, but a lot of critical detail is missing.
    • Is it being kept up-to-date? Development cycles seem to be moving faster and faster, and as documentation is one of the least glamorous parts of a developer’s job, updates can be missed, dismissed or, at the very least, lag behind. We commonly see multiple versions of an API, and the OAS does not reflect the new capabilities of the latest version.

    While a non-existent or outdated OAS presents a modest concern for API visibility, it creates a substantial concern when trying to serve as the foundation for API security.

    You take a huge risk if you depend solely on OAS for security. More often than not, an OAS is not accurate, lacks critical details and is only as useful as the data you feed into it. Gaps, including shadow APIs, leave out critical details, making enforcement impractical.

    The inaccuracy of OAS leaves customers with two choices. You can either enforce security policies based on strict adherence, and risk blocking legitimate traffic, or you can enforce based on loose adherence and risk letting attacks through. In either scenario, your organization is unduly vulnerable, and significantly less secure than your dev teams intended or your security teams would like.

    OAS is Only a Starting Point

    OAS provides a great starting point for documenting your APIs. Don’t make the mistake, however, of basing your API security strategy on what’s in your OAS. It’s simply not accurate enough. Taking that approach will leave your company’s vital data and services at the mercy of API attackers who will quickly know more about your APIs and what they expose than your OAS does.

  • Strengthen API Security With These Tips and Patterns

    Strengthen API Security With These Tips and Patterns

    If you haven’t noticed, digital organizations are building more and more APIs. ProgrammableWeb tracks more than 23,000 public web APIs at the time of writing, and the API market is estimated to be worth $5.1 billion by 2023. Building with APIs increases internal interoperability, reduces development time and can extend product functionality tremendously. In short, the value of APIs is rising. However, opening up with APIs brings security caveats that, if not addressed, could result in serious breaches that negate these benefits.

    I recently spoke with Roey Eliyahu of Salt Security to get his take on the top security concerns for API-enabled companies, and how organizations can safeguard their services. In short, he recommends thoroughly cataloging and understanding your API inventory, designing for legal challenges and mitigating OWASP’s top 10 API security vulnerabilities.

    Challenges for API Security

    APIs have been called “the next frontier in cybercrime.” Rightly so, as API breaches continue to pop up nearly every day. Take the recent API vulnerabilities at Cisco Systems, Shopify, Facebook, U.S. presidential campaign apps, and GCP as evidence. The most infamous was likely the Equifax breach—not enforcing formats on incoming API calls resulted in a massive data breach, which cost the company a $700 million lawsuit.

    So, why have API breaches increased recently? Well, a few years ago, there were simply fewer APIs. And, these older services exposed less sensitive data. Nowadays, companies typically have many more APIs. Banking applications, for example, might expose hundreds of highly valuable endpoints that are very appealing to hackers.

    Companies also build APIs for different audiences: A 2020 study by SmartBear found 72% of companies develop both internal and external-facing APIs. These APIs could easily hold hundreds of parameters, and with every new method added, a company’s potential attack surface grows considerably.

    3 Steps To Secure APIs

    To mitigate the above API security issues, Eliyahu suggested three main steps: Understand your API inventory, audit against privacy policies and data privacy regulations, and track the most pressing API vulnerabilities like a hawk.

    Know Your API Inventory

    “You need a great inventory of APIs to know your attack surface,” said Eliyahu. Many API providers document their APIs with OpenAPI definitions. But, these files don’t always match the production realities—they may be manually generated or leave out certain methods. “In every organization, there is up to a 40% gap between APIs that are actually deployed versus what has been inventoried,” he said. By maintaining a clearer API inventory, organizations can avoid unprotected shadow IT.

    Include Legal Auditing

    A change to an API could result in a change in how it collects user information. Updates involving sensitive data could break privacy policies or regulations such as GDPR. “After you have an inventory, you need to map all parameters manually,” said Eliyahu. He recommended performing a legal audit against your API inventory and establishing a repeatable testing process that plugs into a continuous delivery pipeline.

    As API teams release new updates, they must consider security and legal implications earlier on in the development flow. “Now, with CI/CD, these changes have to happen very frequently,” he noted.

    Watch the OWASP API Security Top 10

    There are many known API security gaps. For example, there may not be proper authorization in place, keys could be exposed, unexpired tokens could be hijacked and so on. Thankfully, OWASP has compiled a resource of top API security vulnerabilities, which Eliyahu and many others in the API economy have rallied behind. “The world should move to adopt the OWASP issues,” he said. These vulnerabilities are as follows:

    1. Broken Object Level Authorization
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources & Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging & Monitoring

    Using AI To Go Beyond ‘Whac-A-Mole’

    Plugging these above holes is a good start. However, these are only defensive measures against known patterns; they aren’t helping you keep guard for nuanced attack types. Ideally, security systems should stop cyberattacks before they even get started.

    Yet, Eliyahu recognizes a big gap in how APIs are monitored. Organizations “don’t have proper tools to know who is looking for vulnerabilities,” he said. “Tools are typically not that advanced. They mainly look for injections and known patterns.”

    Imagine a hacker probing an API. They will likely do so by trial and error, testing undocumented endpoints, sending malformed requests and so on. “They need to probe for hours or days before they find something,” said Eliyahu. If an AI could detect these odd attempts in minutes or seconds, IT could significantly reduce risk.

    Security solutions should thus leverage big data and AI to create baselines of typical behavior, then deter malicious activity the millisecond any nefarious probing begins. Eliyahu said such a security AI must consider dozens of behaviors such as, How is the API being accessed? What parameters are being used? What are the relationships between parameters? What is the flow of API calls? What type of data can be exposed?

    Instead of waiting for a breach to occur, an AI-enabled API security monitoring could instantly pause behavior deemed “out of the norm” by referencing a knowledge base that’s constantly refined using machine learning. Because, if you are only blocking malicious actors without knowing how you need to improve API security posture, “you are just playing Whac-A-Mole,” said Eliyahu.

    DevSecOps Requires API Security Forethought

    Mark O’Neil, analysis at Gartner, predicted that by 2021, 25% of organizations with public APIs will have discontinued or rebooted their public API strategy, citing security concerns as a common breaking point. APIs are now at the core of many application developments. Yet, without the proper DevSec proposition, teams risk wasted efforts and costly breaches.

    To summarize, here are our tips on API security:

    • Ensure everything is well-documented: API inventories cannot be audited if undocumented. Shadow APIs increase the likelihood of an attack.
    • Watch the top 10 OWASP vulnerabilities: These points are foundational to API security. Though not a cure-all, they present a starting point.
    • Build a security and legal review process: Ensure APIs are never deployed without the proper security review. Create validation systems that plug into continuous development processes, so new versions are never breaking privacy policies.
    • Each API is unique: Another thing to keep in mind is each API is unique. Therefore, API security monitoring also requires more context into unique business logic.
    • Continuously monitor your APIs: Continuous search for anyone looking for vulnerabilities.
    • Remove deprecated APIs: Remove old API versions. “You need a mechanism to identify and remove old API versions.” Otherwise, “zombie APIs will bite you!”
    • Learn from the attacks you block: Don’t just play Whac-A-Mole. “You need a mechanism to learn from attacks you block.”
  • Sacrificing Security for Speed: 5 Mistakes Businesses Make in Application Development

    Sacrificing Security for Speed: 5 Mistakes Businesses Make in Application Development

    Earlier this year, the Democratic party in Iowa announced its plans to use a smartphone app to calculate and transmit their caucus results. Using technology to improve the speed of governance, one would think, “What could possibly go wrong? A lot, apparently. The app’s failure on results day was attributed to reporting and coding issues.

    While security was the matter of concern from the day of its announcement, the inevitable happened. Data and security breaches happen almost every minute. University of Maryland researchers find cyberattacks every 39 seconds. The last decade has seen many data breaches, putting personal information of billions of users in the hands of dubious entities. Every enterprise, from Yahoo to Facebook and Target to Home Depot, has been under attack—and this is likely to continue. Research has found that cybersecurity breaches will result in over 146 billion records stolen by 2023.

    Poor security is putting enterprises, governments and citizens at risk every day. Yet, in a hurry to leverage technology, companies bring unsecured applications to market all the time. In essence, they sacrifice security for speed. Adding to this, today’s modern web and mobile applications are built with latest and greatest technology stacks and frameworks, heavily reliant on client side functionality, and integration to multiclouds and third party systems using a myriad of APIs. Also teams are more diverse and work collaboratively using remote workforces. 

    These trends increase the security challenges the application development teams need to be aware of, and leverage platforms that provide built-in controls and protection against these to avoid security breaches and attacks. 

    While prioritizing speed over security in application development take into consideration the following mistakes that you need to avoid and address.

    Not Looking at Data Security Holistically 

    Data tends to be the most important and valuable aspect of modern web applications. Poor application design and architecture leads to data and security breaches. Application development teams generally assume that by providing the right authentication and authorization measures to the application, data will be protected. This is a misconception. Right measures to provide data security involve focussing on data integrity, fine grained data access and encrypting data while in rest as well as in motion. In addition, data security needs to be looked at holistically from the time the request is made to the time response is sent back across all layers of the application runtime.

    Not Considering Security Across the Application Development Lifecycle 

    Today’s modern web applications are highly sophisticated and built with a big focus on simplistic user experience combined with high scalability. This combination can be challenging for application development teams from a security perspective. Most development teams focus only on silos when securing the application (only client, server or integration layer). Teams should focus on end-to-end full stack security when developing applications. Also application teams should enforce security best practices incorporated by default as part of the collaborative development process.

    Not Focusing on API Security

    Most of the modern web applications use APIs from systems and services which include internal enterprise systems, cloud SaaS APIs, partner APIs and third party product APIs. Today, almost all web applications tend to expose their own functionality to the external environment as a core set of APIs. What’s more, nearly 100% of web applications today tend to expose its own functionality as a core set of APIs to the external world. Teams need to make sure they are using external APIs with proper security guidelines and protocols as well as exposing their own APIs with multiple choices of protecting them. API access needs to be protected with both coarse grained as well as fine grained measures.

    Not Providing Strong Authorization and Authentication Methods

    Authenticating your application and authorizing what users can access is an important part of application security. Without this, you are leaving your attack surface wide open. Your application needs to incorporate stringent and strong measures for authentication to prevent unauthorized access. This includes multi-factor authentication, passwordless authentication, single sign on and if using passwords very strong password policies. It must also offer fine grained role-based access control preventing access of sensitive and confidential data to non-privileged users. Moving to a market with ambiguous weak authentication, lack of fine grained control, improper session control and insufficient logging might not seem like a probable risk until you’re attacked.

    Not Incorporating Vulnerability Testing Throughout the Development Lifecycle

    Security threats are evolving faster than anyone can keep track of. The Open Web Application Security Project (OWASP), a community of application developers and security professionals, identifies the top 10 security risks each application team must mitigate. This includes risks across injection, data exposure, misconfiguration, security deserialization and so on. Development teams should incorporate vulnerability assessment as a continuous process and not leave it at the end of the deployment cycle.

    Automating Security with Development Platforms

    Integrating security into your application development process does not have to slow you down. By utilizing key technologies such as a low-code platform, you can accelerate development and enable security procedures at the same time.

    While promising accelerated development, what an ideal low-code application development platform offers is a visual development environment and code-customization with two-way workplace sync with IDEs. It also enables autogeneration of code, ensures extensibility and reuse with prefabs, and allows for full integration with CI/CD pipelines. 

    One of the important features of a low-code platform is built-in security, one that ensures automation of the development of application-level security features. A perfect platform provides a configuration for prevention of security vulnerabilities such as XSS and CSRF and ensures in-built encryption, robust authentication and authorization systems, along with enterprise-grade auditability and traceability.

    While speed may be the name of the game, rolling out your applications without considering security would have little positive impact if they fail to function and are not secure. One of the best ways to integrate security across your application development lifecycle is to leverage the benefits of low-code platforms that are designed for professional development, those that have built-in, application-level security features. While your application development plans may be time-critical, security cannot be an afterthought, because sacrificing security for speed may make it longer for you to mitigate the risks than achieve your application development goals. 

  • Breaking Down the OWASP API Security Top 10, Part 2

    Breaking Down the OWASP API Security Top 10, Part 2

    Due to the widespread usage of APIs, and the fact that attackers realize APIs are a new attack frontier, the OWASP API Security Top 10 Project was launched. From the beginning, the project was designed to help organizations, developers and application security teams become increasingly aware of the risks associated with APIs. This past September, the OWASP API Security Top 10 release candidate (RC) was finalized and published on OWASP.

    In my first article on this topic, I provided a high-level view of the interaction between API endpoints, modern apps and backend servers, in addition to how they’re different from their traditional browser-based counterparts. I also discussed why this project was so important to the contributors and industry overall. 

    In my second article, I focused on the first five risks and emphasized some of the respective possible attack scenarios. In this article, I will attempt to clarify the last five risks to help organizations understand the dangers associated with deficient API implementations. The following discussion follows the same order as found in the OWASP API Security Top 10.   

    API6:2019 – Mass Assignment

    Modern frameworks encourage developers to use functions that automatically bind input from the client into code variables and internal objects. Which means users should have the ability to update their user name, contact details, etc. (within their profiles for example), but they should not be able to change their user-level permissions, adjust account balances and other administrative-like functions. An API endpoint is considered vulnerable if it automatically converts the client input into internal object properties, without considering the sensitivity and exposure level of these properties. This could allow an attacker to update things they should not have access to.

    Example Attack Scenario:

    To illustrate this further, imagine a ride sharing application provides the user the option to edit basic information about themselves in their user profile. For example, they can adjust their user name, age, etc. In this case, the API request would look like this: PUT /api/v1/users/me with the following legitimate information {“user_name”:”john”,”age”:24}

    However, the attacker determines the request GET /api/v1/users/me includes an additional credit_balance property (field) as shown below.

    {“user_name”:”john”,”age”:24,”credit_balance”:10}.

    The attacker desires to increase their credit balance on their own and replays the first request with the following payload:

    {“user_name”:”john”,”age”:24,”credit_balance”:99999}

    Since the endpoint is vulnerable to mass assignment, the attacker can easily adjust their own credit_balance at will, for example changing it from 10 credits to 99999 as shown above.

    API7:2019 – Security Misconfiguration

    Attackers will often attempt to find unpatched flaws, common endpoints or unprotected files and directories to gain unauthorized access or knowledge of the system they want to attack. Security misconfigurations can not only expose sensitive user data, but also system details that may lead to full server compromise.

    Example Attack Scenario:

    Say for instance that an attacker uses a popular search engine such as Shodan to search for computers and devices directly accessible from the internet. The attacker found a server running a popular database management system, listening on the default TCP port. The database management system was using the default configuration, which has authentication disabled by default, and the attacker gained access to millions of records with PII, personal preferences and authentication data.

    API8:2019 – Injection

    Injection vulnerabilities cause computing systems to potentially process malicious data that attackers introduce. To put it in its simplest terms, attackers inject code into a vulnerable piece of software and change the way the software is intended to be executed. As a result, injection attacks can be somewhat disastrous, since they normally lead to data theft, data loss, data corruption, denial of service, etc.

    Example Attack Scenario:

    Suppose an attacker starts inspecting the network traffic of their web browser and identifies the following API request designed to help a user recover their password. The attacker identifies the request responsible to start the recovery-password process as follows: 

    POST /api/accounts/recovery {“username”: “john@somehost.com”}

    Then the attacker replays the request with a different payload: 

    POST /api/account/recovery {“email”: “john@somehost.com’;WAITFOR DELAY ‘0:0:5’–“}

    By adding the ;WAITFOR DELAY ‘0:0:5’–” the attacker observes that the response from the API took five seconds longer, which helps confirm the API is vulnerable to SQL injection. Exploiting the injection vulnerability, the attacker was able to gain unauthorized access to the system.

    API9:2019 – Improper Assets Management

    Old API versions are often unpatched and can become an easy way to compromise systems without having to fight state-of-the-art security systems, which might be in place to protect the most recent API versions. Attackers may gain access to sensitive data, or even takeover the server through old, unpatched API versions connected to the same database.

    Example Attack Scenario:

    Say for instance that an organization redesigning their applications forgot about an old API version (api.someservice.com/v1) and left it unprotected, and with access to the user database. While targeting one of the latest released applications, an attacker found the API address (api.someservice.com/v2). Replacing v2 with v1 in the URL gave the attacker access to the old, unprotected API, exposing the personal identifiable information (PII) of millions of users.

    API10:2019 – Insufficient Logging and Monitoring

    Without logging and monitoring, or with insufficient logging and monitoring, it is almost impossible to track suspicious activities targeting APIs and respond to them in a timely fashion. Without visibility over ongoing malicious activities, attackers have plenty of time to potentially compromise systems and steal data.

    Example Attack Scenario:

    Imagine that a video-sharing platform was hit by a large-scale credential stuffing attack. Despite failed logins being logged, no alerts were triggered during the timespan of the attack, and it proceeded without being noticed. As a reaction to user complaints about a possible breach, API logs were analyzed and the attack was detected, way after the fact. The company had to make a public announcement asking users to reset their passwords, and report the incident to their regulatory authorities.

    Pertaining to the five risks above, one could easily imagine similar attack scenarios. Those provided were just examples of the nearly unlimited possibilities when attacking vulnerable API implementations. Hopefully, you can see the risks above are primarily caused by errors or oversights that could be easily remedied, especially when it comes to the way organizations utilize APIs today.

    — Erez Yalon

  • Best of 2019: Breaking Down the OWASP API Security Top 10, Part 1

    Best of 2019: Breaking Down the OWASP API Security Top 10, Part 1

    As we close out 2019, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the fifth in our weeklong series of the Best of 2019.

    As a result of a broadening threat landscape and the ever-increasing usage of APIs, the OWASP API Security Top 10 Project was launched. From the start, the project was designed to help organizations, developers and application security teams become more aware of the risks associated with APIs. This past September, the OWASP API Security Top 10 release candidate (RC) was finalized and published on OWASP.

    In my previous article, I provided a high-level view of the interaction between API endpoints, modern apps and backend servers, in addition to how they’re different from their traditional browser-based counterparts. I also discussed why this project was so important to the contributors and the industry overall.

    In this article, I aim to clarify the first five risks by highlighting some of the possible attack scenarios to help organizations and end-users understand the dangers associated with deficient API implementations. The following discussion follows the same order as found in the OWASP API Security Top 10.

    API1:2019 – Broken Object Level Authorization

    Attackers can exploit API endpoints vulnerable to broken object level authorization by manipulating the ID of an object sent within the client request. What this means is the client can request information from an API endpoint that they are not supposed to have access to. This attack normally leads to unauthorized information disclosure, modification or destruction of data.

    Example attack scenario:

    Say for instance there is an e-commerce platform that provides financial and hosted services to a group of different online stores (shops). The platform provides an API used to gain access to revenue charts for each of their hosted stores, and each store should only have access to their own revenue charts. However, while inspecting the client request from a single store who wants to gain access to their own revenue charts, an attacker can identify (find) the API endpoint for those revenue charts and identify the URL in use, for example /shops/{shop name}/revenue_data.json. Using the names of other stores being hosted on the e-commerce platform, an attacker can create a simple script to modify the {shop name} ID object in subsequent requests, and gain access to the revenue charts of every other store.

    API2:2019 – Broken Authentication

    Being different than authorization discussed above, authentication on the other hand is a complex and confusing mechanism concerning APIs. Since authentication endpoints are exposed to anyone by design, the endpoints responsible for user-authentication must be treated differently from regular API endpoints and implement extra layers of protection for credential stuffing attempts, in addition to brute force password and token guessing attacks.

    Example attack scenario:

    Suppose an attacker obtained a list of leaked username/password combinations as the result of a data breach from another organizations. If the API endpoint handling authentication does not implement brute force or credential stuffing protections such as CAPTCHA, rate-limiting, account lockout, etc., an attacker can repeatedly attempt to gain access using the list of username/password combinations to determine what combination(s) work.

    API3:2019 – Excessive Data Exposure

    By design, API endpoints often expose sensitive data since they frequently rely on the client app to perform data filtering. Attackers exploit this issue by sniffing the traffic to analyze the responses, looking for sensitive data that should not be exposed. This data is supposed to be filtered on the client app, before being presented to the user.

    Example attack scenario:

    Image an IoT-based camera surveillance system allows administrators to add a newly-hired security guard as a system user, and the administrator wants to ensure the new user should only have access to certain cameras. These cameras are accessible via a mobile app the security guard uses while at work. The newly hired security guard’s mobile app makes an API request to an endpoint in order to receive data about the cameras and relies on the mobile app to filter which cameras the guard has access to. Although the mobile app only shows the cameras the guard can access, the actual API response contains a full list of all the cameras. Using the sniffed traffic, an attacker can manipulate the API request to show all cameras, bypassing the filtering on the mobile app.

    API4:2019 – Lack of Resources and Rate Limiting

    It is common to find API endpoints that do not implement any sort of rate limiting on the number of API requests, or they do not limit the type of requests that can consume considerable network, CPU, memory and storage resources. The amount of resources required to satisfy a request greatly depends on the user input and endpoint business logic. Attackers exploit these issues causing denial-of-service attacks and associated endpoint outages.

    Example attack scenario:

    Let’s say an attacker wants to cause a denial-of-service outage to a certain API that contains a very large list of users. The users’ list can be queried, but the application limits the number of users that can be displayed to 100 users. A normal request to the application would look like this: /api/users?page=1&size=100. In this case, the request would return with the first page and the first 100 users. If the attacker changed the size parameter from 100 to 200,000, it could cause a performance issue on the backend database, since the size parameter in use is so large. As a result, the API becomes unresponsive and is unable to handle further requests from this or any other client.

    API5:2019 – Broken Function Level Authorization

    Although different than API1 above, exploitation of this issue requires the attacker to send API requests to endpoints that they should not have access to, yet are exposed to anonymous users or regular, non-privileged users. These types of flaws are often easy to find and can allow attackers to access unauthorized functionality. For example, administrative functions are prime targets for this type of attack.

    Example attack scenario:

    To illustrate this further, imagine during the registration process to a certain application that only allows invited users to join, the mobile app triggers an API request to GET /api/invites/{invite_guid}. GET is a standard HTTP method used to request information from a particular resource. In this case, the response to the GET contains details about the invite, including the user’s role and email address.

    Now, say an attacker duplicated the request and manipulated the HTTP method by changing GET to POST. POST is an HTTP method used to send information to create or update a resource. The URL would look like this: POST /api/invites/new/{“email”:”hugo@malicious.com”,”role”:”admin”}. In this case, the attacker easily exploits this issue and sends himself an email invite to create an admin account.

    In the context of the five risks above, one could easily image many similar attack scenarios. Those provided were just examples of the nearly unlimited possibilities when attacking vulnerable API implementations. As you can see, the risks above are primarily caused by errors or oversights. I believe these risks could easily be managed or nearly eliminated when organizations improve their secure coding practices, especially when it comes to the way they’re utilizing APIs.

    — Erez Yalon

  • Survey Sees More Complex API Challenges Ahead

    Survey Sees More Complex API Challenges Ahead

    A survey of more than 10,000 developers of application programming interfaces (APIs) suggests there’s lots of room for improving the overall efficiency of API lifecycle management.

    The survey was conducted by Postman, a provider of a platform for building APIs. Respondents on average said they only spend a quarter of their time (26%) on the development of APIs. The rest of the time is consumed by debugging and manual testing (22%), automated testing (11%), designing and mocking APIs (11%), managing others (9%), documentation (7%), monitoring (6%) and publishing (4%). A full 70% said they are spending more time on manual testing and debugging than they thought they should.

    All that time spent on manual testing and debugging may be having an adverse impact on the number of APIs that can be built, tested and deployed at a time when a transition to microservices-based architectures is requiring organizations to build and support more than ever.

    According to the survey results, about a quarter of respondents (24%) work with more than 20 APIs. Well over half those employed on average (53%) are for internal use, compared to 28% employed specifically for integration and 19% that are made public.

    In terms of technologies survey respondents are most excited about for the coming year, microservices (54%), containers (46%) and serverless computing frameworks (44%) top the list.

    As far as the performance is concerned, survey respondents are evenly split. Just under half (48%) said they feel that their APIs do not break, stop working or materially change specification often enough to matter. However, 28% said these issues arise on a monthly basis, while 16% said they deal with these issues weekly. Another 3% said it was a daily challenge.

    In terms of security, survey respondents are relatively confident: Nearly three-quarters of respondents (73%) said they feel that their APIs are “very secure” or have “above-average security.” Only 2% said they felt they were not at all secure.

    It’s hard to say how secure any API is without testing it. Rebecca Johnston-Gilbert, a marketing manager for Postman, said it’s apparent more organizations are starting to address security at the design phase rather than after the API has been built and deployed. Many organizations have already adopted an API-first approach to application development that enables them to manage them in isolation from the applications they are designed to support, she said.

    Among other survey findings, 73% of survey respondents said they work on a team of 10 members or less, while a quarter (26%) work on teams with 22 to 50 members. In addition, 78% of respondents have five or fewer years of experience in developing APIs.

    In general, survey respondents said they would like to see improvements in the areas of documentation (64%), standardization (59%) and sample code (58%), which suggests consuming APIs is still not all that simple.

    There is no doubt organizations increasingly will be applying best DevOps practices to the building and maintaining APIs. The challenge organizations face is, not only do they need to build and maintain what could soon be hundreds (if not thousands) of APIs to support microservices but also those APIs will need to be a lot more resilient as the dependencies between microservices exponentially increase.

    — Mike Vizard

  • Autonomous Security in Containers

    Autonomous Security in Containers

    With the advent of DevOps, the development world has quickly moved to agile development practices and containerized applications. At Forum Systems, we have responded to this trend by putting our API security software, Forum Sentry, into virtual form factors such as Amazon Machine Image, Azure Image, VMware Image, Linux, Windows and Docker.

    Why do we feel it’s necessary to containerize API security in this way, and what benefits does it deliver over traditional software or even hardware-based API security?

    What Is API Security?

    Before we explain why we containerized our API security software, it is first necessary to define exactly what we mean by API security. As a result of the major IT trends of the last decade–in particular cloud, mobile and IoT–more people and applications are connecting to IT assets than ever before.

    What’s more, the majority of these interactions are from untrusted entities outside the organization’s network perimeter (and as you will read below, across container boundaries). Securing your organization’s systems, data and business-critical processes is harder than ever.

    Almost every interaction relies on an API to communicate to an application or system somewhere in the world. The simplicity of APIs makes it easy for developers to connect their projects to other systems to enhance their functionality, with data being easily shared between a myriad of external partners, cloud providers, virtualized data centers and on-premise applications.

    As a result, APIs have become the primary channel for business transactions and the traditional boundaries of data exchanges have become blurred. APIs provide many benefits but also present risks, as wherever there is innovation, there is also the dark side of threat and attack, and always someone who will aim to exploit weaknesses.

    In many environments, APIs and their underlying technologies are designed primarily to share data; they are not designed to thwart threat and attack. This is where API security gateways are necessary to validate both the data and the identity of users, systems and devices interacting with the API.

    API security goes far beyond just access control, it requires specialized technology to perform dynamic data security to inspect and ensure the specific and unique characteristics of each API communication are correct. The API security policies are designed to prevent intrusion, data leakage and other forms of data loss as a seamless and transparent part of the technology architecture.

    API security gateways differ greatly from API gateways; the key word “security” immediately distinguishes this technology from simple API gateways, which serve only to provide proxy and simplified access control points. API security gateways are purpose-built to protect against API threats, and the dynamic data security capabilities they offer provide centralized protection of bi-directional API communications. API security gateway technology provides essential risk mitigation at each layer of the API architecture, and as rising adoption of containers and micro-service architectures arise, it provide zero-trust concepts within and across the container boundaries to protect the assets and technologies therein.

    Why Containerize API Security?

    Container technology such as Docker has become a popular means to deploy API micro-services, a collection of loosely coupled services which are fine-grained and lightweight. The move toward virtual and cloud was initially driven by fully virtualized images with their own operating system, but the adoption of lightweight services and on-demand environments has led to widespread adoption of container technologies run on a shared operating system. These container architectures provide flexibility and ease of deployment, but come with the same set of API risks.

    The concept of containers also brings into focus the trust model that needs to be considered for communication among technology components within and across containers. Containers become a new API boundary layer and thus represent the same type of risk paradigms, where a rogue container application can gain access or otherwise wreak havoc if the proper security controls are not put into place (commonly known as an insider attack).

    By deploying API security directly into a container, organizations can automate their API security into their existing workflows and provide zero-trust security capability that ensures real-time enforcement and protection of container-based APIs. This means API security becomes autonomous and baked into the architecture, rather than tacked on at a later stage.

    As mentioned earlier, dynamic data security is essential wherever information is traversing. The traditional cyber umbrella approach no longer applies in the interconnected API world. It’s like using an umbrella in a water park, it may stop the water from the top, but not from the sides. By having automated API security at the container and virtual layers, the ability to visualize, connect and secure information becomes an integral (and necessary) aspect of the container security strategy and a fundamental baseline for secure API enablement and trusted data exchanges.

    API security gateways deployed as container nodes allow DevOps teams to harness the power of virtualization, cloud computing and containers while at the same time protecting the organization against API threats from both the inside and the outside. With API security baked into the container, developers are free to focus their time on building the best functionality in their apps.

    — Jason Macy

  • How to Automate an API Security Program Without Adding Staff

    How to Automate an API Security Program Without Adding Staff

    In today’s information economy, data is a primary raw material and a source of value to both providers and consumers. For many companies, entire business models are built on the exchange of information.

    Consider a ride-sharing business that owns no vehicles of its own. What the company does possess, however, is a database of private vehicle owners who are willing drivers, a roster of people who will gladly pay for a ride and an application that can instantly connect a rider with a driver via an application programming interface (API). The ride-sharing company makes its money by taking a cut of the fare.

    Another example is a company that collects and refines financial data and makes it available to investors who might want to buy stock. Companies such as E*TRADE, Merrill Lynch and Fidelity buy that investment data to make it available to their clients. APIs are at the heart of these important data exchanges.

    How Prominent are APIs?

    The information economy is synonymous with the API economy. APIs are increasingly the way business partners—internal and external—exchange and monetize data and services. APIs allow for machine-to-machine data retrieval, essentially removing barriers and accelerating access to data. There is hardly a modern application today that doesn’t provide an API to integrate with other applications and data sources. The typical mobile app today uses an average of 10 to 15 APIs to move meaningful data into and out of the app. Modern web apps called SPAs (single-page apps) do the same. APIs have proven to be so efficient and useful that many companies have begun creating new business ventures by mobilizing their data to third-party developers and the public.

    DevOps teams heartily embrace APIs to advance their ability to produce applications much more quickly. APIs, however, are largely a mystery to security teams that must ensure that this means of rapid data exchange does not create unnecessary risk and negative exposure for the company or its brand. Enterprise security teams are right to question the vulnerabilities and threats posed by APIs. Insecure APIs have led to some very serious data breaches, some of which are outlined in the Dark Reading article, “Expect API Breaches to Accelerate.”

    For example, the mobile payment app Venmo exposed sensitive details about hundreds of millions of transactions through a poorly secured API. In another case, an insecure Panera Bread API used by a mobile app exposed users’ private details through a searchable API that required no authentication to access. As a result, as many as 37 million records, which included customer personal information identifiers (PII) such as names, email addresses, physical addresses, birthdays and the last four digits of credit cards—all in plain text—were exposed. T-Mobile, McDonald’s, Symantec, Instagram and numerous other companies have suffered through significant data breaches traced back to insecure APIs. The damage is high because most APIs are designed to serve data without security in mind.

    DevOps and security teams can agree that a data breach coming from their applications is completely untenable. Thus, designing and applying a security program that spans across all APIs across all applications is an essential function in protecting data and brand. Just exactly how can this be achieved? Let’s look at the steps of automating an API security program without needing to add additional security staff.

    The Challenge of Securing APIs

    The very nature of identifying all APIs makes it a challenge to secure them. A developer can create an API in a matter of minutes and publish it on the internet with almost no resistance when using public cloud services such as Amazon, Microsoft and Google. What’s more, she can make changes to that API as often as she wants, and every change cycle presents an opportunity to introduce new risk. It’s not unusual for a developer to change her API weekly or daily.

    Let’s go back to that example of the financial services company that sells data to stock brokers. Suppose the developer makes a change to her API which unintentionally enables the brokers to see the client lists of every other broker that consumes data via the API. That would be a catastrophic breach, yet this is precisely the type of API breach suffered by the U.S. Postal Service a year ago.

    APIs today increasingly are built on serverless infrastructures such as Amazon Lambda, Azure Functions or Google Cloud Functions. Traditional firewalls, gateways and agents can’t protect this type of API built on ephemeral infrastructure. Now consider that a large enterprise might develop and/or use hundreds or even thousands of APIs. The magnitude of the challenge to secure every API becomes apparent. Manual security oversight and enforcement are simply out of the question. Automation of security assessments done on a continuous basis is the only scalable approach.

    Start With an API Security Framework

    Every organization that creates or uses APIs needs an API security framework that consists of three steps:

    1. Continuous API discovery and specification creation.
    2. Continuous API specification analysis and inspection.
    3. API policy enablement and enforcement.

    Let’s have a look at each step and its impact.

    Know What APIs Are in Use and What They Are Intended to Do

    Gathering API specifications is an important first step in defining what APIs are intended to do. However, many APIs exist without any specification. A service that creates API specs helps to deal with those APIs void of documentation. However, this spec creation service also needs to continuously monitor and discover new APIs to remedy the problem of not knowing what APIs exist and their intended function. It’s common for a developer to document what her API is designed to do initially, but updating that documentation every time she makes a change to her API is rare. To compensate, the organization needs to have an automated tool that gathers this information and notes each time an API changes, then accordingly updates the API specification.

    For example, consider an API that exists to transfer customer information between a company’s back-end server and a mobile application. The developer adds a feature or two and the API changes to support these new features, resulting in the API doing things it wasn’t originally expected to do. How would the organization know about these changes? There is a need to continuously analyze the API for such changes to understand the current state of specifications for what the API is doing.

    The organization needs to create specifications of all the APIs, especially publicly facing APIs hosted in the cloud. This service needs to operate continuously to look for changes in the APIs constantly. There are tools that can automate these various activities, including discovering new APIs and changes to existing APIs. These tools also can uncover other cloud resources and data services related to these APIs; enumerate API domains, functions and associated methods; and generate a standards-based (Swagger, OpenAPI v3) spec if one does not exist.

    Analyze the APIs for Security Threats

    The next step is to perform a security inspection on each API operation every time it changes. The security team needs to know: Does it have the right data encryption? Is proper authentication in place? What type of authorization policy is being applied? What is the API’s level of availability? What kind of data sources does it access? Knowing each API’s current security posture is critical if the organization wants to avoid a data breach.

    This API analysis needs to take place continuously and at scale since manual processes are ineffective for organizations using numerous APIs. Fortunately, there are tools and technologies that automate this process and perform tasks such as finding potential vulnerabilities within the authentication and encryption layers of the API. The tools also can generate security tasks with recommended changes for developers to remedy their respective API problems and alert security personnel when there are discrepancies between the API specification and its functional operations.

    Create and Enforce Security Policies

    No two companies have the same appetite for risk. If there’s one aspect of creating an API security program that requires a manual investment of time, it’s policy creation. Automation then can be used to enforce the policy. A security policy for APIs should start with two primary questions: Who should be able to utilize the API? And what level of sensitivity, regulatory oversight and/or privacy concerns does the API have? Based on the answers to those first two questions, you can form the basis for the security policy.

    For example, a bank has an API that provides transaction statements for a specified account. That API has access to extremely sensitive and private information for each of its customers. One customer should never be allowed to access another customer’s account statements. Therefore, the authentication, authorization, encryption and availability of that API would be set to the most restrictive security standards available to ensure data exposure is tightly controlled. Another API from this same bank may provide the current interest rates of savings and money market accounts. This is data the bank likely would share with anyone potentially interested in opening an account with them. In this case, the level of security restriction would be lowered to support a wide variety of systems, browsers, SDKs and apps to ensure this information is highly available.

    Historically, API policy enforcement for authentication, encryption and availability was often done at the network gateway layer. As applications have migrated to modern architectures such as mobile and cloud, the gateway approach has increasingly become less practical, less scalable and more restrictive. Application developers are often leveraging authentication, encryption and availability zones provided to them through SDKs and/or cloud services. In these cases, an automated service that integrates with these security services is a better approach for API policy enforcement versus traditional network gateways.

    Automation is Key

    Security teams are notoriously overworked and short-staffed. Worldwide, there’s a dire shortage of skilled security professionals available for hire, so adding additional security staff to build and execute the API security program isn’t a practical option. Bringing in consultants is expensive and can be budget-busting. Thus, automation through tools and technology is a sensible approach.

    Automation provides the benefits of saving time and money when it comes to executing the three steps outlined above. What’s more, an automated program provides consistency in the repetitive tasks necessary to discover, document and analyze the APIs in use, and enforce corporate policies to control risk.

    APIs are critically important to modern applications. DevOps people heartily embrace them, and security teams can learn their value as well once they understand how a robust and continuous API security program will benefit their organization.

    — Doug Dooley