devopsy.kinsta.cloud

Author: Galeal Zino

  • Squaring the Circle: How to Make Public APIs Private

    Squaring the Circle: How to Make Public APIs Private

    APIs have become an integral part of enabling seamless data exchange and functionality between systems and businesses. In fact, APIs are trebling every year. Public APIs are, by their nature, designed to be open and discoverable. By definition, this also means that APIs are open to attacks from the networks. This is why APIs have become the number one attack vector.

    APIs becoming the top attack vector makes sense. All our other business apps are hidden behind private networks–usually MPLS (AWS Direct Connect, Azure ExpressRoute, etc.), VPN or zero-trust network access (ZTNA). But APIs are exposed to the public Internet.

    Day 2 API Security Solutions and Snowflakes

    This network exposure is why there are so many ‘Day 2′ API security solutions – WAFs, API security platforms, IDS, etc. These solutions do a great job of blocking threats that have already been identified, yet there are successful API attacks each day. Why?

    Each API is unique and evolves rapidly–constant changes in business logic, authentication, authorization and configurations. APIs are snowflakes. The result is that many API attacks are effectively zero-day attacks–novel attacks that exploit recent and unique changes to specific APIs.

    A Difficult Race to Win

    Network exposure and snowflake characteristics are why API-related vulnerabilities multiply each day.

    The ‘snowflake’ issue means many attacks are unknown to the Day 2 solutions – they attack vulnerabilities that didn’t previously exist. So, after the novel attack, we race to apply a fix. Who are we racing against? Every attacker on the internet. The API is public–exposed to the networks–not like our other business apps, which are private behind an MPLS, VPN or zero-trust solution. Racing against attackers on the internet is difficult–and coming second may result in a service outage, data breach or customer compromise.

    Why Not Avoid the Race?

    So why not make the APIs private, avoid exposing them to the internet, put them behind MPLS, VPN or ZTNA, like we do for all our other business apps? API clients are too distributed and dynamic; there is no good way to manage agents or dedicated circuits across all those API clients. Those solutions were not made for APIs–it is like fitting a square peg in a round hole.

    Zero-Trust API Networking Needs to be Built for APIs

    To make our APIs private like the rest of our business apps, we must first meet the business need. API providers need to achieve the business velocity and agility they require. On the technical side, we need a secure networking solution which is built to manage the distribution of the API clients, and assume that there will always be snowflake-like vulnerabilities.

    Let’s look at an open source solution for zero trust APIs which is purpose-built for those business, technical and operational requirements:

    There are usually three reactions to the diagram above:

    1. OK, tell me how it works. See below.
    2. Looks complex. Nope. All software, spun up in minutes, centrally managed.
    3. Seems like a proprietary solution for users accessing their applications. Yes! It uses principles similar to the user-to-app zero-trust world but secures APIs.

    How Zero-Trust API Networking Works

    Here are the four pillars of zero-trust API networking:

    1. Eliminate public access. Your API clients will use private IPs or domains to reach your APIs. If your company name is Acme, then your clients might now use api7.acme.unreachable (you make up any domain you want). Envision an attacker trying to interrogate *.acme.unreachable to find snowflake vulnerabilities. Not possible because it is not a public domain—your API server is no longer reachable.
    2. Identity, authentication, authorization, mutual TLS. Authorized API clients do need to access your APIs from the internet. Your zero-trust API overlay network is accessed from the internet only with X.509-certificate cryptographically authenticated identities, continuous authentication and least privileged access authorization via mTLS links. You move the policy enforcement point (PEP) from your DMZ to your API clients. Your API clients add a few lines of zero-trust networking code to enable this model. This code replaces VPNs, MPLS, etc. (there are non-code options too). For example, some of your API clients likely use Resty, a popular open source REST client library for Golang. Their existing Resty code adds a few lines of zero-trust API networking code: 
    3. Outbound-only. You eliminated the inbound access. Your server will instead open identified, authenticated and authorized sockets to your zero-trust API overlay network (you’ll close all your inbound ports and only enable outbound ports to specific overlay network router IPs or to your x.acme.unreachable domain).
    4. Management. API networking security is not very valuable without simple management. The zero-trust API overlay cloud is software-only and cloud-native. You spin up your private API clouds in minutes, anywhere, without deploying hardware. If an API client is compromised, one click or automated action removes its access. Network usage for each client/API is in your web console or management dashboard.

    The above is based on the open source OpenZiti zero-trust networking platform, but any zero-trust API platform should provide similar functionality. Specifically, it should enable:

    • Speed. Securing APIs but slowing down business or complicating operations is not the trade-off most organizations want. Security and speed is the goal.
    • Minimize the threat surface. Close all inbound ports in front of your API servers. Use private, unreachable addresses or domains to minimize your attack surface and stop racing against network-based attackers.
    • Extensibility. Software-only, cloud-native architectures. Preferably open source based.
    • Operations excellence. Centralized visibility, controls, policies and identities. Rich telemetry data. Performance-optimized overlay networks.
    • Zero-trust security. Identity-based networking, continuous authentication, strong authorization, mutual TLS (mTLS), encrypted delivery, microsegmentation.
    • Flexibility. API clients add a few lines of code to get zero-trust API networking. Other API clients use API-specific agents or DNS to access the overlay, if desired, while your API server/gateway is still private.
    • Recovery. Assume breaches. Implement microsegmentation, prevent data exfiltration and provide simple controls to immediately remove threats.

    Zero-Trust API Networking

    While APIs will always be snowflakes, they no longer need to be our only business app that is exposed to the networks. By minimizing the attack surface, without compromising business velocity and API client experience, we can finally mitigate against our greatest API security risk. This also simplifies our day two API security, the solutions that inspect API queries after they enter our DMZ.

    Rather than trying to filter the internet, day two solutions can focus on detecting authorized API clients that may have been compromised. Similarly, our operations teams are freed to focus on sessions from authorized API clients rather than wading through oceans of data from port scanning, DDoS attacks, unauthorized API queries and attempts to interrogate public APIs to find new snowflake vulnerabilities.

  • Embedded Connectivity Solves the Right (and Left) Problem

    Embedded Connectivity Solves the Right (and Left) Problem

    In Steven Bellovin’s book, “Thinking Security: Stopping Next Year’s Hackers,” (2015) he wrote:

    “Companies are spending a great deal on security, but we read of massive computer-related attacks. Clearly, something is wrong.

    The root of the problem is two-fold: We’re protecting (and spending money on protecting) the wrong things, and we’re hurting productivity in the process.

    InfoSec is hurting productivity in the organization it is supposed to be protecting.”

    Bellovin clarified what he meant by “the wrong things.” He observed that security measures tend to stick around even when the threat they were intended to address has faded into the past. Those security costs have only increased since 2015 when the book was published, and today represent a trillion-dollar drag on the global economy despite the emergence of security-integrated models of software delivery such as DevSecOps, shift left and shift right.

    The 2021 IBM Security Threat Intelligence Index reports the No. 1 attack vector was a surveillance technique known as scan-and-exploit. Defenders face an asymmetric engagement with such network threats. The successful attacker needs only to exploit a single vulnerability whereas defenders must secure 100% of the network’s ports of entry 100% of the time. The fundamental problem is the anonymous and permissionless nature of the internet. This makes it both useful and easily abused. Anyone anywhere may conduct reconnaissance and launch attacks at a massive scale with little cost or risk. How can we make it prohibitively difficult or costly to successfully surveil and attack our own applications? What if we could reliably defend against the entire category of active scanning tactics?

    There are no secure networks, only isolated networks. Taking this back to first principles, a network’s purpose is to convey packets of data from sender address to recipient address. The network has no built-in ability to identify either party or to discern the legitimacy of any activity. Active scanning techniques identify potential targets that are then probed by scripts that may be intrusive or stealthy or both. We could simply reject all incoming network traffic with a firewall, but application servers must be continually reachable in order to listen for incoming requests. Any interruption of availability causes errors like “connection refused” and “service unavailable” for the user. 

    This necessary network exposure leaves the upper layers of the network and the application server itself vulnerable to intrusion and denial of service attacks. “Private” enterprise applications are similarly exposed to the famously-vulnerable group that are VPN users’ devices, and so are by no means immune to this problem. This presents the problem of automatically discerning which incoming connections are legitimate, continually, forever. Are we trying to solve the wrong problem?

    Ideally, we would identify the sender before they connect to the application server. That way, we can know whether they have permission to connect at all. This is something we simply can not do when the sender is known only by a network address. We can’t ask for a credential because that introduces yet another application layer with all of the same problems. This is precisely why VPNs do not go far enough: A superficial barrier is erected for users that prevents the application server from checking for permission until after surveillance and subsequent attacks have occurred. 

    Embedded connectivity-as-code solves the right problem. This represents a shift in thinking about the relationship between the application and the network. Now, the application brings its own point-to-point overlay with a verifiable identity on both ends. This has significant implications for the security of the application that can be summarized in terms of shifting security left in the development timeline and shifted right in the life span after deployment.  

    Shift left: OpenZiti makes embedding connectivity-as-code convenient for developers and transparent for auditors and users. As open source software, it fits into DevSecOps processes that scan the source code. The management side of the OpenZiti network is cloud-native and API-driven and fits into the DevOps paradigm of continuous integration testing. For example, a network-as-code may be continually created and destroyed by a pipeline to exercise any imaginable configuration of endpoints, services and policies, or to facilitate dynamic scanning of the data edge and fabric APIs. 

    Shift right: OpenZiti allows us to shift right security to measure and monitor applications after development, in production, with a novel ease and without compromising security. Operators maintain perfect visibility of deployed applications and need not cope with the complexity of hopping through security gateways or bastions or worrying about external malicious actors and inbound connections. This best-of-both-worlds reality is a natural effect of  an access control scheme that is based upon verifiable cryptographic identity, not a weak identifier like an IP address. Importantly, this means it is always knowable which identity is accessing what services, when they were accessed and to what extent.

    OpenZiti gives applications superpowers! To name a few: Identity-driven addressability, private domain name system, shelter from unauthorized connections, portable and programmable micro-segmentation, end-to-end encryption, solves the IPv4 shortage without IPv6, smart routing to choose optimal routes across the internet and is transparent to end users.

    Learn more about OpenZiti by checking out our Quickstarts or engaging in conversation on Discourse. 

  • Networking: The DevOps Community Deserves Better

    Networking: The DevOps Community Deserves Better

    Developers of cloud-native applications are at the heart of a process of radical transformation shaking up the business world. Using DevOps and SRE methodologies, modern development teams are bringing a level of agility to the game that is all about freeing enterprises from the shackles of the old, pre-cloud days and letting them take advantage of new opportunities at light speed.

    But the developer community has a problem. The process of developing and delivering cloud-native applications in a DevOps paradigm demands the right connectivity to back it up, and traditional networks aren’t doing the job. Cloud-native developers need cloud-native networking—network solutions that work in the same frictionless and agile way they do—solutions that put the application first and replace traditional manual network configuration with connectivity-as-code.

    To play their part, developers need application-friendly connectivity that is designed for applications composed of microservices and APIs which span many edges, clouds and service meshes. A new software only, cloud-native approach to connectivity is required to address this and other challenges such as security, performance and operational support at scale.

    There are four things developers shouldn’t take for granted in a network solution: agility, security, simplicity and performance.

    Agility

    What application developers need is a cloud-native, agile, on-demand alternative to traditional networking—something that delivers the speed to market that they need, and safeguards their profitability. With a model such as application-specific networking in network-as-a-service models, application development teams can create on-demand connectivity across edge, cloud and service mesh environments to support their apps wherever their apps travel.

    Security

    App developers require zero-trust software defined perimeter security that meets and exceeds even the most stringent compliance standards, and can be controlled as code by their DevOps tools and applications.

    Simplicity

    New networking approaches that puts the application in contol can abstract the developer and DevOps teams from the complexity of differences between underlying networks, clouds or service meshes.

    Cost-Effective Performance

    Application-controlled network-as-a-service models can deliver operational cost reduction over traditional MPLS and VPN solutions, while boosting throughput and performance compared with legacy alternatives.

    Conclusion

    Developers deserve better networking. It’s time for them to say goodbye to the old way of doing things and move on from restrictive legacy solutions with their lack of scalability, absence of agility, poor security and unpredictable overheads.

    — Galeal Zino