Sunday, January 24, 2021

Lack of the spelling checks for the AWS IAM API actions and security implications

 AWS IAM policy language used everywhere:

- to define IAM policy itself

- to define resource-based policy like S3 bucket policy

- to define the most important AWS control - SCP (Service Control Policy)

- to define VPC endpoint policies 

Let's take a look at the AWS IAM policy structure:


This policy's vital element is "Action," which is a list of AWS APIs that will be Allowed or Denied by the policy. 


Currently, there are several thousands of AWS actions. A list of all of them could be found here.  


It's extremely easy to make a typo in the action name when you are creating a policy. 


But, AWS will detect and warn you, right? 


Nope!


It might come as a surprise even for the experienced cloud engineers, but AWS does not verify API actions spelling.  

Proof: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_policy-validator.html


Yes, when you are using a policy generator, you can choose from the dropdown list of the available API actions.  

But if you are using CLI, Cloudformation, Terraform, or any SDK, your policy will be accepted as long as a policy syntax and grammar will pass (policy grammar, but not action names or resource ARNs )


So what? Not a big deal? If policy not working, you can troubleshoot it using the policy simulator, right, and find a problem? 


The challenge is that even an AWS native policy simulator will not check API (action names) spelling. It will show if the desired actions are allowed or blocked but will not point you to the simple typo in your policy. 


As long as your policy is for the ALLOW effect, it's not a big deal. You might spend some time troubleshooting and not understanding why access is not granted, but generally, it should be OK, right?


Even in the case of ALLOW, not precisely: 

when you are using Infra as a code, you might make a typo in production-related IAM/SCP/etc. policy and cause quite an outage!


What about policies that suppose to protect, a.k.a DENY effect? Implications, in this case, might be quite catastrophic:


- SCP that implements your AWS Account level preventative controls will allow actions that you think you have blocked, making controls not-exiting.


- IAM policy will not protect against destructive or unsafe actions.


- Resource-based policy might become unintentionally too open.


Luckily, AWS has a second layer of protection ( and implicitDeny ) that, up to a certain extent, will compensate for such mistakes: as long as API call (Action name) is not explicitly Allowed, it will be deemed as implicitDeny. This helps and might save your backend, but not in all cases. Moreover, relying on this it's definitely a bad security practice. 


What could be a solution to the problem we just discussed? 


A process and a tool of the IAM policy validation for the syntax and spelling.


The process is an IAM policy linting that must be done before any deployment or during PR review in your code repo.


As for the tool, it might be home built linting tool (example: extension or rule to the CloudFormation Linter  https://github.com/aws-cloudformation/cfn-python-lint ) or an open-source linting tool that performs IAM action names validation. (example:  https://github.com/duo-labs/parliament)


Note, the tool must be regularly and automatically synced with the latest list of the AWS IAM actions or manually updated to reflect any changes AWS might do to the subj. 


Monday, January 4, 2021

My notes on the AWS security: "Where we’ve been, where we’re going" reInvent 2020 session by Steve Schmidt.

 

After finally having time to watch some AWS reInvent 2020 sessions over the holidays, I decided to make some notes and share them in case someone will find this useful.

My notes on "Where we’ve been, where we’re going" reInvent 2020 session by Steve Schmidt :

Topics:

1) 2020 security highlights 

2) Security product launches 

3) Enabling Zero Trust 

4) Ten places to focus on today

2020 security highlights (new features):

GuardDuty:

  • new threat and service coverage 
  • S3 data advance (s3 protection)
  • better organization support (designated account to manage GD in the organization)
Firewall Manager:
  • support for AWS WAF and AWS Managed Rules
  • supports centralized logging (for WAF)
AWS Detective now supports IAM role session analysis (better understands assumed roles cases )

AWS IAM Access Analyzer works the awesome way in the organization (very useful with huge amount of the use cases) 

AWS Single SignOn adds AWS CloudFormation support

ACM private CA:

  • Using AWS ACM private CA could be shared  (using AWS RAM) with other accounts to allow them to provision, manage, and deploy private certificates.
  • Better integration of the certificate lifecycle for the private CA with supported AWS services (LB, API GW, IoT..)
  • ACM supports 5X more APIs (performance )
  • ACM support for the AWS S3 bucket encryption (looks like only for CRL and audit report exports)

AWS Nitro Enclaves is GA: use case: an isolated environment for very sensitive data . 

AWS Macies reduces the costs to up  80% and dashboard redesign.

AWS Security Hub:

  • GA. 
  • auto-remediation support
  • CIS, AWS best practices and PCI DSS security standards 
  • prepackaged with 10 playbooks 
  • Single dashboard for the patching status in the Security Hub using AWS patch manager (part of system manager) 

AWS Detective now supports VPC flow logs and does aggregations and dashboarding for this.   

Security product launches  

AWS Nitro Enclaves

AWS Audit Manager

  • continuously assess control for the risk and compliance (helps with evidence collection for the Auditors and proactively collects evidences) 
  • Currently supports following frameworks:  CIS, GDPR, PIC DSS + build own assessment templates
  • Highlights: known and custom assessment templates,   automated evidence collection, built-in audit workflow.
Cloud Audit Academy - training for the auditor to better understand what the cloud is and how to perform cloud audit.

AWS Network Firewall (based on the docs looks like managed Suricata IPS): 

  • inspect all traffic entering or leaving VPC.
  • zonal service with AZ isolated inspection points
  • basically, a fleet of AWS managed firewall ec2 instances behind a load balancer
  • supports DNS names in the firewall rules. 
  • IDS/IPS functionality as well

Enabling Zero Trust  

Zero Trust - augmenting network-based controls with identity-based controls 

Network:

  • First dimension
  •  Network 
  • Microperimeters? 
  • Security above network? 
  • Gateways or proxies? 
  • More dynamic VPNs? 
  •  Combinations?

Identity

  • Second dimension 
  •  Identity 
  • Humans? 
  • Machines? 
  • Software components? 
  • Combinations?

Avoid binary choice: just identity or just network controls. 

One size doesn't fit all in each case Zero Trust might and will be implemented differently.

Ten places to focus on today:

from 2019: 
  1. Accurate account info 
  2. Use MFA
  3. No hard-coding secrets
  4. Limit security groups
  5. Intentional data policies
  6. Centralize AWS CloudTrail logs
  7. Validate IAM roles
  8. Take action on GuardDuty findings
  9. Rotate your keys
  10. Be involved in dev cycle

new one (2020): 

  1. Use AWS Organizations
  2. Understand your usage
  3. Use cryptography services
  4. Federation for human access
  5. Block public access on accounts
  6. Edge protect external resources 
  7. Patch and measure 
  8. No hard / soft defense (perimeter is both: Network and Identity)
  9. Transparent leadership reviews
  10. Diverse hiring