This is the second series of the blog post titled “Saviynt’s Journey to AWS” with the focus on security.
Part 1 of this series (Snowflakes to Phoenix Servers) described how team Saviynt adopted and implemented its services on AWS. Architectural patterns and processes regarding dissecting the cloud in layers and implementing Immutable Server Infrastructure using the Phoenix Server Pattern were some of the key points discussed in this post.
Part 2 of this blog series aims to discuss key security challenges for native AWS Services which Saviynt faced when implementing its offerings on AWS. The blog also intends to share our learnings, design patterns and methodologies used to overcome these challenges. Saviynt with its vision to provide comprehensive Cloud Access Governance and Intelligence have built these security controls within its core platform and uses the same to secure its offerings on AWS.
With multiple implementations, learnings from the industry and community, our understanding evolved and over a period of time we were able to define a concrete list of missing security controls for native AWS services which are as follows
- Consolidated Access View of an AWS IAM User based on IAM Roles and Policies not available
- Lack of Privileged Access Management
- Lack of effective monitoring on Privileged Users
- Lack of Flexible, granular and and extensible risk signatures and controls framework to enforce compliance needs
- Absence of extensible and customizable preventative controls framework
- Lack of AWS IAM Governance
- AWS Command Line allows user defined “session names” (Discussed in Part 3 of Blog Series)
- Native controls to secure infrastructure as code (Discussed in Part 3 of Blog Series)
- Securing CI/CD and devOps processes (Discussed in Part 3 of Blog Series)
- Identification of sensitive data across S3 buckets (Discussed in Part 3 of Blog Series)
Before going into the details of each challenge mentioned above – Lets first understand how Saviynt services are deployed on AWS and integrated with AWS Accounts.
As shown in the illustration below Saviynt is deployed either as AMI or a SAAS solution on one of the AWS Accounts in a clustered manner for reliability and scalability. Using AWS IAM Roles Saviynt scans for the following information across Cross AWS Accounts on a scheduled basis as well as in real-time
- Security Configurations viz. EC2 Instances Metadata, VPC, Subnets, Route Tables, Security Groups etc. configurations (Saviynt pulls in more than 100+ AWS objects configurations)
- AWS IAM Roles, Policies and the access relationships of AWS Users and Groups (Federated and AWS Admin Accounts) with Infra components
- Usage data (Cloud Trail Logs, VPC Flow Logs, Cloud Watch Logs etc.)
Another illustration of the integration architecture of Saviynt’s services with AWS Services is shown below.
Let’s take a deep-dive and understand how Saviynt defined, designed and built security controls to overcome the challenges outlined earlier
Challenge of Consolidated Access View – Saviynt scans and builds an “Access Hierarchy” model in its data store based on the relationships between AWS IAM Users, Groups and Roles and Policies. This entails parsing large sets of AWS IAM Objects and building the “Access View”. Having a detailed “Access View and Hierarchy” enables Saviynt to determine “Who” has “Access to What” and how many such users/groups are privileged in nature with critical access to critical workloads in the AWS datacenters . This helps Saviynt to identify Privileged Users in AWS datacenters and also determine the “Risk Exposure” associated with a specific AWS Account.
Lack of Privileged Access Management – Access to AWS objects is primarily provided by IAM Policies and Roles and the Access Assignment is long term with no lifecycle or approvals associated to it .Access Assignments removal require intervention (human or via scripts) based on events and often lead to long term privileged access and residual privileged access (due to partial policy clean-ups).
Duration based access provisioning/de-provisioning is critical for privileged access management. Saviynt with its emergency access request module with pre-defined Roles (These roles get mapped to AWS Roles at the time of deployment). Users can request for these roles for a limited duration(configurable) enabling them to get high privileged access in AWS for a limited duration only. Post the expiration of allowed duration of the role, users assignment to the roles is automatically removed, without the need for any human intervention.
Lack of Effective Monitoring on Privileged Users – All AWS API calls are logged in Cloudtrail logs including privileged activities. Sifting and monitoring AWS Cloudtrail logs is never easy because of the sheer volume of logs, which can easily range in petabytes. Cloudtrail Logs are great, but parsing them and deducing meaningful information out of them requires a solid feat of engineering. Adding further complexities would be aggregating activities across Multiple AWS Accounts. Above all, filtering the high privileged events across AWS accounts and correlating the same adds even more complexity.
Saviynt developed the solution to ingest Cloudtrail logs using big data technologies like Elastic Search, Hadoop and Apache Spark. The highly scalable solution allows Saviynt to sift High Privileged activities across AWS accounts and present the same for admins, forensic admins to investigate
Lack of Flexible, granular and and extensible risk signatures and controls framework to enforce compliance needs – With the Shared Responsibility model, AWS is responsible for security of the cloud. However, end clients are responsible for security “in” the cloud.
FedRamp, PCI-DSS, PHI, SOC are some of the compliance mandates which organizations have to achieve and continuously monitor and enforce the same across their AWS environments.
A clear mapping of AWS services to various compliance controls does not exist. Effective monitoring of the same and to enforce the same for various AWS services viz. EC2, S3, RDS etc. during an organization’s cloud adoption journey does not exist
Saviynt with its out of box 250+ risk signatures not only maps AWS services to various compliance mandates , but also provide the necessary recommendations and actions for organization’s AWS admins to meet their compliance objectives and meet the mandates defined as part of CIS AWS Foundations benchmark
A comprehensive list of risk signatures extend all the way from EC2 (Open Ports, Missing Roles) to CloudTrail (Disabled, Disabled Log Validation etc.) to RedShift/RDS (Unencrypted instances etc.) to IAM Controls (High Privileged Users, Roles, Root account with API Keys enabled)
Absence of extensible and customizable preventative controls framework – Staying compliant is harder than achieving compliance. With the elasticity of cloud comes the challenge of enforcing organization’s security baseline across the ever changing infrastructure (immutable infrastructure)
AWS does not provide an extensible preventative control framework which would allow organizations to enforce their security baseline standards across AWS objects. For ex. Stopping EC2 instances outside VPC which have open SSH ports to internet or Terminating critical/production workloads associated with unencrypted EBS Volumes.
Saviynt designed and implemented deep integration with AWS Config and AWS CloudWatch Events thereby providing a robust and extensible preventative controls framework for organizations to enforce their security baseline policies across AWS objects. These integrations allow Saviynt to receive events in near-real time from AWS, followed by enforcement of fine grained rules/security policies as per defined in its rules engine.
Lack of AWS IAM Governance – Concept of “ownership” do not exist in AWS. Creating an IAM policy to assign permissions for AWS IAM objects is a crude way to manage ownership.
Managing roles and policy changes via assignment of owners is critical from a governance standpoint to ensure only the “authorized” set of owners/users can perform“CRUD (Create/Update/Delete)” or “Role/Policy Assignment” operations in AWS
HR termination does not lead to access deprovisioning of local AWS IAM users Lack/absence of workflow based access provisioning/de-provisioning Lack/absence of SOD (segregation of duties) rulesets for access assignments
Lack/absence of Access and Usage Attestation.
From a governance standpoint, attestation lifecycle which are Periodic, Policy and Role Owner based or Event Based is critical to ensure only authorized users are getting access to AWS Objects. However, with the significant number of AWS accounts, large number of policy objects and roles, this process can easily turn into a “Rubber-Stamping” process. Saviynt with its robust core IGA framework, applied the same principles and extended the functionalities to AWS, thereby creating an intelligent and robust governance framework around AWS
I hope this blog post helped in explaining some of the key security challenges we faced and also the resolutions regarding each of them.
Part 3 of this series will focus on the remaining Security Challenges around devOps , CI/CD processes and data governance.