Application programming interfaces (APIs) drive the automation behind software development and deployment processes. While automation has removed a great deal of error from manual tasks conducted by humans and the security vulnerabilities that come with that, risk has shifted from humans to the machines that power these APIs and new attack vectors have been introduced. Where a developer would previously login to an AWS console to spin up an EC2 instance, that infrastructure now gets spun up via code through tools such as Terraform or CloudFormation.
It’s now more important than ever to have clear visibility and responsive control into the identities of the machines that are accessing the organization’s APIs. In zero-trust parlance, we call this Non-person Entity (NPE) Identity and access to an enterprise’s systems, services, and data. As Gartner in its 2022 API Hype Cycle Report and Akamai in its State of the Internet Security report discuss, this type of API communication has exploded recently. Yet organizations lack the frameworks to protect and regulate these API-driven ecosystems and secure this automated machine-to-machine communication at scale.
Security teams must shift their focus from “How do we make sure Jill isn’t granted too many permissions in AWS?” to “Do we know the identity of the machines that have API access and do we trust them?” This mindset forces security leaders to treat machines, and the workloads they run, as users just like Jill – essentially have strategies for API Identity and Access Management (IAM). Automation requires engineering and security teams to treat machines as first-class citizens. If identity truly has become the new perimeter in security, then it’s critical to have clear visibility into the identities of non-person entities like machines and service accounts.
This emphasis of securing non-person entities (NPEs) or nonhuman entities in API-driven ecosystems are called out in zero-trust architecture frameworks like NIST 800-207 and CISA’s zero-trust maturity model. Here are the basics of the NIST framework:
A ZT approach is primarily focused on data and service protection but can and should be expanded to include all enterprise assets (devices, infrastructure components, applications, virtual and cloud components) and subjects (end users, applications and other nonhuman entities that request information from resources).
So what can DevSecOps teams do today to reclaim the security posture of machine-driven API access? Here a few actionable steps:
- Take an inventory of all machines. Take inventory of the machines accessing API services from within the network and outside. Audit identity providers for loose or stale service accounts and follow best practices and good security hygiene around scoped and time-limited service accounts. Have an automated way to get this information on the fly. Gartner recommends splitting machines into devices (tablet/computer/etc) and workloads (microservices/containers/pods/server/vm/etc). Remember the more we automate, the more we shift the risk from human to machine and addressing that means elevating machine identities as users.
- Identify and categorize risk. Once the team takes an inventory of the machines allowed into the network, systems, and services, it’s important to identify those that may access more critical API services. These could be those workloads holding or passing sensitive data. Again, this categorization and risk assessment needs to recur and stay responsive to the company’s ever-changing API landscape.
- Automate API IAM. Start applying the same strategies around identity and access management to API clients as the team would do with human users. This means implementing the pillars of traditional IAM like least privilege, access controls, and privilege escalation. It’s time to elevate API IAM to the same level as human IAM.
- Seek visibility. Here’s where API gateways can help the team understand where all of its API traffic comes from and help create a uniform baseline of identity, authentication, and access. The team needs to create visibility into all service-to-service connections and API traffic whether it’s east-west, or north-south traffic.
- Strive for control. Ask within the organizations today: “If an API secret or service account were compromised today, how quickly could we respond?” The ability to control API access, authentication, and authorization on a fine-grained level could help the organization reduce its threat surface and more effectively respond to security events. If an API secret gets compromised, create the ability to quickly revoke it, but this means these secrets cannot be shared among machines and the team has to have the ability to provision a fresh one quickly. At scale the only way to achieve this in a cloud-driven world is through automating security hygiene. Look for ways to automate provisioning, rotating, controlling, and even revoking API secrets.
Hopefully these strategies are helpful as organizations have conversations and develop strategies around API security, identity, and access.
Anusha Iyer, co-founder, president, and CTO, Corsha
Click Here For The Original Source.
————————————————————————————-