There is absolutely no excuse for getting Security Groups wrong, Security Groups should be used correctly and planned prior to anything being deployed into AWS.

  • Configure security group rules to permit ONLY necessary traffic based upon the actual component(s) you are protecting.
  • Ensure rules are configured to specific ranges and not overly permissive.
  • Don’t use large CIDRs like /8 or 0/0.
  • Ensure you have a clear description for each rule.
  • Where you are unsure of the functionality of a rule, seek guidance from your security team.
  • Where feasible, create single security groups and apply to multiple instances, where those instances are provisioning the same services.
  • When using VPCs ensure endpoints are leveraged for traffic flows into AWS services.
  • Never connect directly to instances, leverage either AWS SSM or as a minimum use a bastion host (jumpbox – if your lazy, stupid and want to waste money instead of using the AWS eco-system).
  • Delete any unused security groups.
  • ALWAYS, ALWAYS be aware of limitations: https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html

How much do you trust your third party providers, can you and do you have sufficient assurance?

This is an information security risk assessment designed to validate the information security controls in place when using third parties to verify whether appropriate controls and processes are in place to protect information.

The first of the two document should be sent to your third party provider (ideally before you select them; but if you already use them then you can conduct this on a periodic basis nonetheless). The second is a scoring document which is used to collate the responses and will automagically provide you with a scoring dashboard.

As soon as time permits this will be iterated into a web application.

3rdParty_RA

3rdParty_RA-SCORING

GOOGLE: ext:pem intext:BEGIN RSA PRIVATE KEY

ext:txt inurl:gov intext:”Content-Type: text/…