1: Enable AWS VPC Flow Logs for your VPC or Subnet or ENI level
2: Use AWS Identity and Access Management (IAM) to control who in your organization has permission to create and manage security groups and network ACLs (NACL)
3: Enable AWS Cloud Trail logs for your account
4: Enable AWS App Config for your AWS account. App records all events related to your security group changes and can even send emails
5: Have proper naming conventions for the Amazon Web Services security group
7: Periodically detect, alert or delete AWS Security groups not following the organization naming standards strictly
8: Have automation in place to detect all EC2,ELB and other AWS assets associated with Security groups
9: Create your own security groups and specify them when you launch your instances
10: Alerts by email and cloud management dash board should be triggered whenever critical security groups or rules are added/modified/deleted in production
11 : Have automated programs detecting EC2 associated with multiple SG/rules and alert the SOC/MS periodically. Condense the same manually to 1-3 rules max as part of your operations.
12 : Do not create least restrictive security groups like 0.0.0.0/0 which is open to every one
13: Have a security policy not to launch servers with default ports like 3306, 1630, 1433, 11211, 6379 etc
15: Detection, alert and actions can be taken by parsing the AWS Cloud Trail logs based on usual patterns observed in your production environment. Detect anomalies on how long a change effected and reverted in security groups in production.
16: In case ports have to be opened in Amazon Web Services security groups or a permissive AWS security group needs to be applied, Automate this entire process as part of your operations
17: Make sure SSH/RDP connection is open in AWS Security Group only for jump box/bastion hosts for your VPC/subnets. Have stricter controls/policies avoid opening SSH/RDP to other instances of production environment
18: It is a bad practice to have SSH open to the entire Internet for emergency or remote support
20: Avoid allowing UDP or ICMP for private instances in Security groups
21: Open only specific ports, Opening range of ports in a security group is not a good practice.
22: Private Subnet instances can be accessed only from the VPC CIDR IP range
23: AWS CloudTrail log captures the events related security. AWS lambda events or automated programs should trigger alerts to operations when abnormal activities are detected
24: In case you are an enterprise make sure all security groups related activities of your production are part of your change management process. In case you are an agile Startup or SMB and do not have complicated Change management process, then automate most of the security group related tasks and events as illustrated above on various best practices
26: For some tiers of your application, use ELB in front your instance as a security proxy with restrictive security groups

Méthodologie pour construire des applications faites pour une utilisation de type cloud:

• 1 application = 1 repository de code et 1 seul
• toutes les dépendances doivent-être explicites et fournies avec l'application
• la configuration doit-être gérée dans des variables d'environnements
• tous les services externes (api, database, smtp, cache, messaging...) doivent-être gérés comme des ressources accessibles via une URL
• les étapes de build (compilation + dépendances), release (application configuration) et run (lancement de l'application) doivent être strictement séparées
• l'application doit-être stateless et "share-nothing" (aucune donnée en local)
• l'application doit gérer sa couche réseau sans dépendre d'un logiciel externe (ex: webserver embarqué pour ne pas dépendre d'apache)
• l'application doit-être composés de process instanciables sur le même serveur ou sur différents serveurs (scalabilité)
• les process ne doivent pas être démarrés en taches de font (démon) par l'application. la gestion des process (arrêt/relance, gestion logs et stdout, ...) doit être délégués à un process manager (systemd, runit, foreman, ...)
• les tâches administratives (ex: migration db, ...) doivent être traitées par des process séparées (scripts) mais fournis avec le code applicatif et lancé dans le même environnement applicatif

Un exemple de playbook de chez Thoughtbot qui décrit la facon de travailler chez eux de A à Z:

• Best Practices, Normes et Guidelines
• Outils utilisés
• Méthodologie de travail
• ...