devopsy.kinsta.cloud

Tag: API security

  • API Security: A Key Part of the Bigger Plan

    API Security: A Key Part of the Bigger Plan

    Standing as the “fuel” powering the customer-driven platform revolution, application programming interfaces (APIs) are the new “it thing” amongst operating systems.

    APIs are responsible for how apps communicate with each other and have become key components in many digital transformation strategies. Serving as a set of tools for building software application, they have empowered many businesses to increase their value. However, as they have risen in popularity, concerns have risen over the adequacy of measures being put in place to ensure security for businesses using APIs.

    The Open Web Application Security Project (OWASP) is a global non-profit organization committed to improving application security and makes it a primary mission to ensure software security is a priority for all. OWASP regularly issues a top 10 standard set of rules that are applied to security policies across various platforms. The most recent list presents notable changes that reflect the increase in dependency on APIs, with a focus on how they can both help and hinder security efforts.

    Why Should Businesses Care About API Security?

    Every application needs APIs. It is difficult to find an organization today that doesn’t have its own app or uses an app to complete critical business activities. They contain programming standards, instructions and protocols that allow applications to communicate with one another. Essentially, APIs serve as a bridge that ensures proper and consistent communication between two systems.

    API security is a critical part of API development because millions of applications communicate back and forth daily. With the cyberthreat landscape constantly evolving and the cloud API market predicted to experience a 20 percent CAGR by 2022, it is easy to understand why it is so imperative that companies develop and continually implement thorough API security measures.

    Most APIs do have some governance from management tools, which can offer a range of control features aimed at making APIs more reliable, secure and controllable. However, security should also be top of demand in the design phase of an API and formulating controls that can be implemented across the organization.

    Arming Your Organization with the Right Security Tools

    Systems that host public APIs feel the impact of heavy traffic on a daily. Some of that influx is, unfortunately, not authentic. To avoid overburdening the legitimate users and protect their system, companies need to evaluate behavior to flag potential problematic traffic.

    API security works in the same manner by using rules and algorithms that evaluate client sessions. APIs ask simple questions that gauge how clients are behaving, what they are doing and whether there are unusual error rates or repetitive behavior in short time periods.

    Machine learning is often used to answer these questions and to identify and deter malicious API client practices. Standard web approaches typically don’t function properly with APIs, simply because hackers work to continuously be ahead of the game. They know that standard DoS attacks don’t work, so they distribute hacking attempts across bots that hide alongside legitimate traffic to sneak them through the system, undetected.

    To find these bad eggs and stay on top of the large amount of them, it’s necessary to set up a machine learning-based system that have a deep understanding of API traffic, with a thorough understanding of API keys, access tokens and what the typical request context is on any payload.

    How Can You Prevent Attacks Right Now?

    There are several actions you can take immediately to protect your system from potentially damaging attacks. Begin by using HTTPS, if you’re not already, to ensure proper authentication and authorization. Also, adjust your software development life cycle (SDLC) to include rigorous API security testing and validation with a primary focus on input validation.

    Also important: Make sure all network servers are running on regularly patched OS versions that are stable and include carefully configured security groups. Implementing role-based access control and VPC isolation across environments also can help improve responses to prevent attacks.

    Finally, having a pre-documented response policy for security incidents will help your company establish a secure development environment that is properly maintained at all times.

    Routine API audits and testing can help your organization continually improve the API development and ensure your business is protected against DDoS attacks and malicious bots, while still letting legitimate API traffic through. These techniques will help you validate API requests and sort through which are legitimate and which are not, to completely eliminate or reduce API attacks.

    — Eltjo Hofstee

  • Portability Shmortability: Most Applications are Going Nowhere

    Portability Shmortability: Most Applications are Going Nowhere

    I’m a huge fan of the idea of taking our super-duper applications and deploying them where it makes most sense. I always have been. Those of us in application development spent forever bemoaning the fact that our applications weren’t all that portable between operating systems. In fact, looking back through the history of computers, you find there has always been one roadblock or another to stop portability.

    First there was byte order and instruction set, and we’ve largely overcome those. Internationalization wreaked havoc on us all for a while, and we overcame that. We’re still pretty mightily struggling with OS-dependent things such as windowing systems, but browser-based apps have largely overcome those also. Java takes a lot of heat for a lot of reasons, but it did improve portability of apps written in it. Maybe not “Write once, run anywhere,” as was often claimed—things such as file locations were still OS-specific—but still a lot closer than compilers that were deeply tied to the operating system they ran on. Virtualization and containers have enhanced portability in another dimension, letting the developer take the OS with the app.

    We have overcome a ton of issues, and advancing technology has introduced a ton more. Now we have to either choose mobile targets or find a tool we like that can generate code for wildly different mobile systems from a single source. DevOps really isn’t helping with this process—though it will, eventually. By automating the build process, the target will be switchable at the targeting end, meaning our app—given a tool that can multi-target—can be built for whatever mobile platform the cool kids are playing with today, and the ones that are considered “cost of entry” can be generated in the same run.

    So far, so good, right? We find problems, we overcome problems, DevOps helps us overcome them faster with a wider selection of outputs …

    And then we hit the data.

    Vendors in a variety of spaces would love to paint you a picture where it doesn’t matter. It does. The mass of your data, wherever it resides, is a pull like gravity to new application development. And it should be.

    Some will try to explain to you that in the age of APIs, it doesn’t matter where the data actually resides: You can get it.

    But it really does matter, and this is not Utopia. Even if you ignore the performance implications of data being latency-infested miles away from applications that need to use it non-stop, those APIs are only a viable option if the data can be secured and protected. By definition, an API is an advertisement that whatever data/service it fronts can be found right here. For applications that traditionally are data center apps, it might be possible to expose your customer file or other critical data via API and then lock down access to the API by IP …

    But then we quit ignoring the latency problem. If every bit of data an app needs has to flow from San Francisco (or Tokyo, or Bejing, or London, or wherever) to Seattle before the calling app can do what it needs to and then has to be sent off again to Albuquerque (or Rostov, or Madrid, or wherever) the delays will, by definition, be more than they would be if the app sat with the data and had to transfer over a 1GB (or 10GB) connection between servers before sending it to users.

    This means most data-heavy apps, no matter the level of agile or DevOps, aren’t likely to move. Vendors with a stake in the process will trot out the one or two customers they convinced to make such a move to tell you how great it is, but performance math and security sense tell you it is only great until things get busy or that exposed API is used by bad actors to vacuum user data.

    Some applications have smaller datasets and can move the data with the app. Other applications can be architected not to care where the data is. A few don’t need a database at all. Move these applications to whatever platform makes sense. Make the CD for them retargetable.  Most serious business applications rely too much on core data to fall into these categories. And thus, they aren’t moving, unless someone comes up with a viable way to move a ton of data between platforms that is safe and fast and effectively translates where necessary.

    So, that’s what we need to see next in the march of portability. We currently have containers that can be run pretty much anywhere and languages that will work on pretty much any platform. We need data tools that can alleviate the current set of non-portability/latency constraints and get data where it is needed, when it is needed, securely.

    Unfortunately, I don’t see that happening soon. So addressing the issue, “Where do we target our new application?” will have to start with the question, “Where is the bulk of the data it needs?” At least for now.

    Most of you knew that, because you’re living it. I just thought you might have a use for a third-party article about it. Because someday, you will have this conversation with someone who isn’t living it. Enjoy.

    — Don Macvittie