Tuesday, March 22, 2016

Scary false positive or story about Best practice to secure your root AWS account

What the best practice of securing AWS root account? - Not using it at all!

Let's clean it up first:

  1. remove any API key associated with root account
  2.  reset root password and change email assoicated
  3. enable MFA (or deactivate previous and create new) on the root account.

Start using IAM:

  1. Copy/bookmark/save IAM sign-in url 
  2. create required users including one with AdministratorAccess policy attached. 
  3. Enable MFA on all users created

Secure root account:

  1. Print you root account credentials.
  2. Log in using printed credentials to ensure that it works.
  3. Put in tamper evident envelope
  4. Add some signatures, stamps or voodoo on envelope. 
  5. Hide it in SafeBox
  6. Use it only in case of emergency :-)  

Now let's add some monitoring just in case:

  1. Enable and configure CloudTrail + bucket for Logs
  2. Configure CloudWatchLogs (CloudWatch) to process CloudTrail logs
  3. Add metric filters to detect root-user related events
  4. Set-up alarm and notifications (SNS) for the metrics

For root users  CloudWatchLog metric filter looks like:

Filter Name:
Filter Pattern:
{$.userIdentity.type = "Root"}

I did everything mentioned above and was ,let's say, "surprised" to get months after notification saying "Root log-in  detected" . Checked CloudTrail looking for  the root user - nothing....Hmm.. Start looking into CloudTrailLogs content  for the detailed row events and found this:

"eventVersion": "1.02", "userIdentity": { "type": "Root", "principalId": "577343344455", "arn": "arn:aws:iam::577343344455:root", "accountId": "5577343344455", "userName": "my_company", "invokedBy": "support.amazonaws.com" }, "eventTime": "2016-03-22T19:22:23Z", "eventSource": "iam.amazonaws.com", "eventName": "GetAccountSummary", "awsRegion": "us-east-1", "sourceIPAddress": "support.amazonaws.com", "userAgent": "support.amazonaws.com", "requestParameters": null, "responseElements": null, "requestID": "675d-fxx3-1x5-9xxd-4768xxx17", "eventID": "b9xxxxfcaf-3xx7-4xxd-a220-exxxx8", "eventType": "AwsApiCall" "recipientAccountId": "577343344455"

Dear AWS support - you got me :-))

Sunday, March 13, 2016

AWS s3 bucket encryption audit

Storing sensitive information at AWS S3?- it's a must to encrypt your data at rest.

  • do it yourself (client side encryption) and transfer to S3 already encrypted
  • ask AWS to do it for you (server side encryption). In this case you have 2 options: S3 managed encryption keys or KMS-managed encryption keys.

If you create a new bucket for sensitive data NEVER create it without AWS bucket  policy enforcing encryption: encryption is object level attribute at S3 and user specify (technically request) encryption during upload process. Policy will block all uploads if encryption not requested. Simple and Easy.. Except:

      You have existing S3 bucket with data uploaded before you enable this policy, you have mixed (encrypted and non encrypted objects) or just doing security audit. In this case you need to scan the bucket to find unencrypted objects. How? quite easy using  few python lines bellow:

import boto3
import pprint
import sys
s3 = boto3.resource('s3')
if len(sys.argv) < 2:
   print "Missing bucket name"
bucket = s3.Bucket(sys.argv[1])
for obj in bucket.objects.all():
   key = s3.Object(bucket.name, obj.key)
   if key.server_side_encryption is None:
       print "Not encrypted object found:", key

Nice, Yep, But it will take almost forever to scan bucket that contains thousand or tens of thousand of objects. In this it would be nice to have some counters, progress bar, ETA , summary, etc.. So, vuala:


Small program providing all these features mentioned. Feel free to use it or request reasonable changes/modifications.