Incorporating Context into Access Analysis and the k9 Access Capability Model

The k9 team would like to share a guide and new features that help engineers contextualize and analyze AWS Cloud deployments using tags. We will also explain why we created the k9 Access Capability model instead of reusing AWS’ model.

Contextualize with Tags

k9 published the Guide to Tagging Cloud Deployments that helps technology teams tag Cloud application and infrastructure resources with the context needed to manage, operate, and secure those resources effectively.

With this information, Development, Operations, Finance, Security, Audit, and Risk Management personnel can collaborate efficiently and answer many of their own questions without resorting to time and attention consuming meetings and chats.

Incorporate Context into Analysis with k9

k9 has a new ‘Resources’ view that lists the S3 resources for your account and incorporates context provided by tags (sample report – xlsx):

The figure shows that the qm-dev-k9-reports bucket:

• is owned by the product team
• is used by the dev environment for the k9 application (see extra tags in json)
• expects confidentiality level Restricted, integrity of 6 nines, and availability three point five nines

You can incorporate this data into the resource and access summary views to support deeper analysis. This allows you to answer questions like:

• Which principals have access to data with Confidentiality level Confidential or Restricted?
• Does my application have access to Restricted data that it does not need?

What questions do you want to ask? We’d love to answer them for you – reply via email or contact us.

The k9 Access Capability Model

Some may wonder why k9 created its own access capability model instead of using AWS’ existing ‘access levels’. AWS access levels include: List, Read, Write, Permissions Management, and Tagging.

Briefly, we feel AWS’ model has significant shortcomings for security engineering:

• inconsistent classification of API actions to access levels, even within a service
• API actions are mapped to exactly one AWS access level, even when multiple apply
• inadequate set of access levels for security engineering

The k9 Access Capability Model describes our motivation, the problems with the AWS access level model, and our approach to solving it.

k9 summarizes each IAM user or role’s provisioned access to AWS resources into a small number of access capabilities:

• administer-resource – one or more AWS api actions results in the capability to administer an AWS resource with create, modify, or destroy a given resource or the security controls for that resource (e.g. modify bucket policies)
• use-resource – a generic capability indicating that the principal has the ability to use a resource, but the resource manages its access control internally, e.g. rds-db:connect
• read-data – capability indicating the principal has the ability to read data from the resource, e.g. read objects from an S3 bucket or DynamoDB table
• write-data – capability indicating the principal has the ability to write data in the resource, e.g. put objects into an S3 bucket or DynamoDB table
• delete-data – capability indicating the principal has the ability to delete data from the resource, e.g. delete objects in an S3 bucket or items from a DynamoDB table
• unclassified-access – the principal’s level of access to the resource has not been classified by k9 yet (unhandled, unknown); note: customers should never see this as our delivery pipeline tests for this condition and stops delivery

We think these access capabilities are much more useful for engineers securing data. We’d love to hear your thoughts and feedback.

k9 Security