Application programming interfaces (APIs) drive the automation of software development and deployment processes. While automation has removed much of the error from manual tasks performed by humans and the resulting security vulnerabilities, the risk has shifted from humans to the machines that power these APIs and new attack vectors have been introduced. . Where a developer previously logged into an AWS console to launch an EC2 instance, this infrastructure is now launched via code through tools such as Terraform or CloudFormation.
It is now more important than ever to have clear visibility and responsive control over the identities of the machines that access the organization’s APIs. In zero-trust parlance, we call this Non-Personal Entity Identity (NPE) and access to a company’s systems, services, and data. As Gartner explains in its 2022 API Hype Cycle Report and Akamai in its State of the Internet Security report, this type of API communication has exploded recently. Yet organizations lack frameworks to protect and regulate these API-based ecosystems and secure this automated machine-to-machine communication at scale.
Security teams should focus on “How do I make sure Jill doesn’t get too many permissions in AWS?” to “Do we know the identity of the machines that have access to the API and do we trust them?” This mindset forces security managers to treat the machines—and the workloads they run—like users like Jill—essentially have policies for API Identity and Access Management (IAM). Automation requires engineering and safety teams to treat machines like first-class citizens. If identity is really to become the new security perimeter, it is essential to have clear visibility into the identities of non-personal entities such as machines and service accounts.
This emphasis on securing non-person entities (NPEs) or non-human entities in API-driven ecosystems is evident in zero-trust architecture frameworks such as NIST 800-207 and the zero-trust maturity model. from CISA. Here are the basics of the NIST framework:
A ZT approach is primarily focused on protecting data and services, but can and should be extended to include all enterprise assets (devices, infrastructure components, applications, virtual and cloud components) and subjects (users endpoints, applications and other non-human entities that request information from Resources).
So what can DevSecOps teams do today to recover machine-driven API access security posture? Here are some concrete steps:
- Take an inventory of all machines. Take inventory of machines accessing API services from the network and from outside. Audit identity providers for loose or outdated service accounts and follow best practices and good security hygiene around extended and time-limited service accounts. Have an automated way to get this information on the fly. Gartner recommends dividing machines into devices (tablet/computer/etc) and workloads (microservices/containers/pods/server/vm/etc). Remember that the more we automate, the more we transfer risk from human to machine and that means elevating the identities of machines as users.
- Identify and classify risks. Once the team has taken inventory of the machines authorized to access the network, systems and services, it is important to identify which ones can access the most critical API services. These can be workloads containing or transmitting sensitive data. Again, this categorization and risk assessment must replicate and remain responsive to the ever-changing enterprise API landscape.
- Automate API IAM. Start applying the same strategies around identity and access management to API clients as the team would with human users. This means implementing the pillars of traditional IAM like least privilege, access controls, and privilege escalation. It’s time to elevate IAM API to the same level as human IAM.
- Look for visibility. This is where API Gateways can help the team understand where all of their API traffic is coming from and help create a uniform identity, authentication, and access baseline. The team needs to create visibility into all service-to-service connections and API traffic, whether east-west or north-south traffic.
- Strive to control. Ask organizations today: “If an API secret or service account were compromised today, how soon would we be able to respond?” The ability to control API access, authentication, and authorization at a granular level could help the organization reduce its threat surface and respond more effectively to security events. If an API secret is compromised, create the ability to revoke it quickly, but that means these secrets cannot be shared between machines and the team must have the ability to provide a new one quickly. At scale, the only way to achieve this in a cloud-driven world is to automate security hygiene. Look for ways to automate the provisioning, rotation, monitoring, and even revoking of API secrets.
Hopefully these policies will be useful as organizations have conversations and develop policies around security, identity, and API access.
Anusha Iyer, Co-Founder, President and CTO, Corsha