View source for CSA Talk May 2018


== Abstract ==

AWS introduces many new capabilities for provisinf IT services. They do so in a software defined way and give you lots of options.

All of the services provided by AWS take se


== A Grab Bag of Security Practices ==

'''Tools'''

* tools to help with security
** some free some not free
** cloudcheckr
** aws-config-rules https://github.com/awslabs/aws-config-rules
*** Sample implement 2 of these
** truffle hog
** cloud custodian
** cfn nag
** Carivin / Evident.io

'''NTP'''

* AWS NTP time sync + dhcp.
* https://aws.amazon.com/blogs/aws/keeping-time-with-amazon-time-sync-service/


'''MFA'''

* root mfa
* using roles to access account from a central place.
* using peering to central manage.
** Diagram
* using config rules

'''IAM'''

* IAM policy best practices.

'''Auditing and forensics'''

** the cloudtrail -> s3 -> cloudwatch trinity
** s3 replication
** s3 imutablity
** Anomaly detection datadog

* anti patterns
** egress backhaul

* Partners and Vendor: what can my vendor do?

== AWS Get Key ==

You can see all sorts of api calls you can do to “get key” for various services that AWS offers. Google "aws api get key". Here is a summary.

'''AWS''' uses keys in a couple of places:

'''ACM''' – AWS Certificate Manager – For doing TLS

'''AWS IAM Keypairs''' – ssh keys that are the first key that get installed on instances in the case of linux servers, or are used to encrypt the administrator password for windows instances.

'''AWS API Keys''' – Keys that users and application uses to make API calls to AWS

'''AWS KMS''' - Key Management Service  – for encrypting data at rest i.e disks – I’m not skilled on this.

There are a couple of different way they are dealt with.

'''ACM'''

Two ways you can use keys here:

1.	You make the private and public yourself and upload them to AWS. Then you can use them with AWS services, like databases, and load balancers. You cannot get the private key back once you give it to AWS. Better make sure you don’t loose your copy if you intend to use it somewhere else.

2.	Tell AWS to generate both public and private. Then go and use those keys with AWS services. You can never get the private key out of AWS, ergo you can _only_ use this key with AWS services.

'''Keypairs'''

There are two ways here as well but slightly different than ACM

1.	You make the private and public yourself and upload only the public key to AWS. Now AWS puts the public key “into” new linux instance as they get lit up so you can login. Don’t loose the private key you have or you can’t get into that instance without some major work, (downing the server, unmounting the root disk and mounting is as data disks on a different instance. )

2.	Generate the key pair “in” aws, aws gives you the private key , which you store safely, and it retains the public key. You can never get the private key again from aws ( I think it doesn’t keep it ).

'''AWS API Keys'''

This is “fully managed” application layer stuff.

AWS _always_ generates these for you.

It always makes an access key and a secret key.

Once the access key and secret are generated and given to you, you can never again get the secret key from AWS. But you can “lookup” the pair by their access key.

You should rotate these as you would passwords.

'''In all cases it is impossible to ask AWS for the secret key itself.'''


== 10 AWS security blunders and how to avoid them | InfoWorld ==

https://www.infoworld.com/article/3132023/security/10-aws-security-blunders-and-how-to-avoid-them.html

 Mistake 1: Not knowing who is in charge of security
 Mistake 2: Forgetting about logs
 Mistake 3: Giving away too many privileges
 Mistake 4: Having powerful users and broad roles
 Mistake 5: Relying heavily on passwords
 Mistake 6: Exposed secrets and keys
 Mistake 7: Not taking root seriously
 Mistake 8: Putting everything in one VPC or account
 Mistake 9: Leaving wide open connections
 Mistake 10: Skimping on encryption