Skip to content

Cloud Security

Potentially outdated

This page was last updated 44 months ago (on 2022-07-25). Verify the information is still accurate before relying on it.

AWS Account Credentials

How do we currently store AWS root account credentials

As part of AWS foundational best practices, it is recommended that we add MFA to new AWS account root credentials.
Due to the number of accounts being created Hardware MFA is not an option, however we do have the ability to set Virtual MFA for each new account.

According to LastPass this is how to create a TOTP for new accounts: https://support.lastpass.com/help/how-do-i-create-a-time-based-one-time-passcode-totp-for-site-entries-as-a-lastpass-or-identity-user

A good way of securing these new accounts is to atomically split passwords and TOTP and save the credentials in a shared folder. Passwords are given to IT and TOTP are shared with CloudOps, this way there is a level of security preventing the miss-use of AWS accounts.

AWS Authentication

The current authentication model in AWS uses federation through an IDP such as AzureAD or Google.

As a company we are looking to reduce this to one IDP (AzureAD), this, however brings a lot of problems around existing services that have adopted the use of Google and requires some untangling.

Moving to a single method of authentication allows the company to adopt passwordless (authNcontext) for authentication and allows the company to use ABAC (attribute based access control), which scales far better than the traditional RBAC approach. Tagging of AWS services also allows us to track spend and gives us greater detail around security.

Account IDP
Cloud Master - 8215428355567 LyniateAD - Azure
RAAS Master - 614738037075 Google

AWS Authorisation

The current Authorisation model looks at an RBAC approach through Google IDP and the same again with AzureAD.
RBAC is a great strategy for a smaller organisation with a small number of teams, however, as the organisation grows managing policies and roles for each individual user group and resources can become truly unmanageable.

By tagging AWS organisational units and their services it becomes far easier to allow a certain group of users with tags passed into their session such as costcenter or team, the control can be implemented from a deployment of services PoV rather than a constant SSO Policy/Role change and group creation.

Some examples of ABAC from an organisational level: SCP's ABAC

AWS Security Services

~~Do we have CSPM (Cloud Security Posture Management) tooling?~~

Do we utilise AWS Cloud Security Tooling and do we need any of the below?

(blue star) Guardduty - Can we be sure EC2’s are not compromised. Can we be sure AWS users have not been compromised?

  • Guardduty is currently disabled - but this is not the only tool we can rely on to provide us with lateral movement issues and potential compromised instances.

(blue star) AWS Inspector - Can we be sure EC2’s are running the latest patch software updates?

(blue star) AWS Detective - Can we be sure that lateral movement is being detected?

(blue star) AWS SecurityHub - Do we know our current posture?

  • Security Hub is currently disabled, however this is not the only way we can get visibility over our Security posture.

    • Scores are generated either by regions or can be aggregated into a single region (the latter provides a clearer all round posture if multiple regions are in use.)

  • Sophos Cloud Optix can supply detail of our overall score - however I believe a number of accounts have not been integrated and are missing from the entire org.

  • Other tools can give us an idea of score, such as Orca.

(blue star) AWS Macie - Do we know of any S3 buckets that could potentially hold PII data?

  • Macie is disabled, this could help us detect if any S3 buckets hold PII data

  • If we are unsure as an Organisation if any buckets hold PII data there are tools in the market that are slightly more affordable than Macie that can detect and alert of PII data in S3.

  • Can Sophos Cloud Optix detect PII data within S3

  • Can Orca be a better alternative?

(blue star) AWS Service Control Policies - Do we manage account posture using account based IAM?

  • We should at a minimum be securing accounts by way of implementing baseline SCP’s

  • By deploying AWS Control Tower accounts can be managed by preventative rules prevent the ability to interact with services that are prohibited within an account and an org as a whole.

  • We can fine tune these policies and actions to help create a manageable set of guardrails keeping us compliant within the organisation.

  • AWS CloudTrail - Do we know whom is accessing what within AWS?

How do we assess the needs of the above tooling?

How much visibility does Infosec require to fill fully informed on Lyniate's Cloud Security posture?

Do we (CloudOps) create a CloudSec

Current

  • Contact at Orca has given me a trial account to conduct a security gap analysis over Sophos Cloud Optix

    • For access please ask.

  • CaaS

    • Sophos Cloud Optix

  • RaaS

    • Sophos Cloud Optix

Discovery

Sophos Cloud Optix is currently deployed to the following accounts and Cloud Providers.

Cloud Provider Account Name
AWS raas-customer-matrixcare
AWS raas-customer-stellarhealth
AWS raas-customer-omnicure
AWS raas-customer-sensato
AWS raas-customer-verato
AWS raas-customer-tmp
AWS raas-customer-biointellisense
AWS raas-customer-cdph
AWS raas-customer-scotland
AWS raas-customer-ihis
AWS corepoint1-development
AWS raas-master
AWS raas-development
AWS raas-development-management
AWS raas-customer-uk
AWS raas-management
AWS raas-security
AWS raas-self-service
AWS raas-self-service-test
AWS raas-customer-synlab
AWS raas-customer-rwj
AWS raas-customer-hackensack
AWS raas-customer-miravista
AWS raas-customer-uofl
AWS raas-customer-crohns
AWS raas-customer-westherts

Synced from Confluence: Cloud Security | Last modified: 2022-07-25 | Author: Lee Jelley