Puppet announced Puppet Comply, a new product built to work with Puppet Enterprise aimed at assessing, remediating, and enforcing infrastructure configuration compliance policies at scale across traditional and cloud environments.
The start of 2020 was an extremely turbulent time as the world dealt with the spread of COVID-19 and businesses globally shifted to a fully remote work environment on an extremely abbreviated timeline. This situation has had a downstream effect on security teams that were suddenly and unexpectedly forced to deal with dramatic changes to their environment.
The Threat Stack Security Operations Center (SOC) recently pulled together research into how businesses are managing their cloud infrastructure since the COVID-19 quarantine began and identified some interesting trends that stood out to me.
AWS Systems Manager Usage Growing
AWS continues to develop its Systems Manager service (SSM) as a powerful automation multi-tool, and users are noticing. SSM usage in Q1 2020 saw a major uptick but there are a few best practices in managing the tool:
■ Mitigate Automation Risk by Tuning Permissions and Access Controls – SSM Session Manager and SSM Run Command are two features whose activity manifests itself differently in the underlying event metadata. SSM Run Command lets users automate a range of predefined configuration tasks across EC2 instances and currently offers 36 Command Documents that are prebuilt to speed common admin tasks like configuring Docker or updating EC2 settings. Because they are for system admin use, they run with admin-level permissions. SSM gets a lot of permissions by necessity as an automation tool. By default, it creates a user with root privileges: ssm-user on your EC2 hosts. Disabling this admin user might be an option, depending on your use case.
■ Get granular with Identity Access Management (IAM) – These features can create problems for security teams if IAM permissions are not finely scoped down to the individual components of SSM. There are several IAM managed policies specific to SSM, and the documentation provides further examples for writing your own identity-based policies.
Security Teams Showing Lax Kubernetes Security
While growth in Kubernetes usage isn't new, security teams are increasingly losing sight of the security risks that are present when using microservices. For instance, load balancers serving as Amazon Elastic Kubernetes Service (EKS) Ingress Controls default security settings are not adequate for all businesses. Rather than relying on AWS to protect critical business data, including cleaning up permissions every 90 days, organizations should proactively remove them once the load balancer is no longer used.
It should be noted that EKS clusters also use the Amazon VPC CNI plugin for Kubernetes, allowing it to represent pods on the VPC itself. This isn't enough to support Kubernetes network policies without additional manual integration of Calico. Moreover, because of how the CNI maps down to the host's ENIs, the CNI can only support one security group per node. This can potentially create problems when EKS schedules unrelated pods on the same node.
Immediate, Widescale Multi-Factor Authentication
Faced with the prospect of their entire workforce now accessing applications and sensitive business data remotely, many organizations decided to either rollout or expand multi-factor authentication (MFA). MFA adoption is a net-positive for businesses and provides dividends even after workers return to the office.
However, the speed with which many organizations were forced to roll out MFA led to a large number of users who were not provisioned properly or employees having either too much or too little access to corporate information. Either scenario isn't ideal as productivity is being inhibited and businesses can be exposed to unnecessary risk.
Changes in Behavior Complicate Security Investigations
As remote workers are signing on from new IPs, from different locations, or outside typical working hours, security teams are forced to confirm that what used to be normal behavior is still expected. It's important for IT and Security leaders to understand their cloud environment by baselining what is normal expected behavior and what could be deemed suspicious.
The beginning of 2020 was a time of rapid and unexpected change for security teams globally that demanded flexibility and creative problem solving. More of the same can be expected moving forward and businesses begin re-opening their offices. Security teams should be focusing on ensuring that their teams are set up for success and are able to monitor their cloud environment, identify suspicious behavior, and take meaningful action to remediate threats and reduce risk.