The below are a few security anti patterns for AWS cloud which should be avoided when implementing comprehensive cloud security strategy:
Security Anti-patterns Categories:
- Account Structure
- N/w design
- Auditing
- S/W delivery
AntiPattern (Account Structure): Personally owned AWS account
- Make sure the Root account (login, MFA) is not tied to a person's email id. Root email id should be tied to team DL
- Root MFA must be tied with some sort of official hardware device
- Contact info etc must be of office address
- No one logs into the account root. Use IAM only.
Anti-pattern (Account Structure): AWS account overcrowding
- Not all and every services/ teams should be placed under one single account. It becomes very hard to manage policy wise and governance wise
- If admin creds for the account is compromise, the blast radius will be more, all the services get compromised
- If some of the services are in scope for compliance, and since they are not separated, it'll be a concern from Compliance perspective.
- Multi- account pattern is recommended. Where the accounts are grouped logically.
Anti-pattern (N/W design): Trusted IP access w/p client auth
- Routing should not be treated as security
- Segregate and use a lot of relevant edge devices and services to achieve defense in depth- AWS Shield, API Gateway, IAM auth, cert etc
Anti-pattern (N/W design):N/W egress back hauling
- Don't directly talk to internet. Restrict egress via Exit VPC
- Use VPC endpoint to talk to publicly hosted services such as S3.
Anti-pattern (Auditing): Questionnaires
- Create attestations instead of entertaining long list of client's questionnaires about the organization's security postures and implementations.
- Get certifications/ assurances and maintain standards sich as ISO 2Ks, SOc2, PCI -DSS etc
Anti-pattern (Auditing): Manual technical auditing
- Inconsistent
- Time consuming, not frequent
- USe automated continuous auditing tools and processes such as Cloud Watch, Inspector, Trusted adviser, Evident.io
- Practice DevSecOps- securit as a code, proactive controls enforced by code
Anti-pattern (S/W delivery): Over-the-wall s/w delivery
- Dev, QA, and ops kept separte- no concept of DevOps basically
- A lot of manual process
- Infrequent release cycles
- Implement DevSecOps
Security Anti-patterns Categories:
- Account Structure
- N/w design
- Auditing
- S/W delivery
AntiPattern (Account Structure): Personally owned AWS account
- Make sure the Root account (login, MFA) is not tied to a person's email id. Root email id should be tied to team DL
- Root MFA must be tied with some sort of official hardware device
- Contact info etc must be of office address
- No one logs into the account root. Use IAM only.
Anti-pattern (Account Structure): AWS account overcrowding
- Not all and every services/ teams should be placed under one single account. It becomes very hard to manage policy wise and governance wise
- If admin creds for the account is compromise, the blast radius will be more, all the services get compromised
- If some of the services are in scope for compliance, and since they are not separated, it'll be a concern from Compliance perspective.
- Multi- account pattern is recommended. Where the accounts are grouped logically.
Anti-pattern (N/W design): Trusted IP access w/p client auth
- Routing should not be treated as security
- Segregate and use a lot of relevant edge devices and services to achieve defense in depth- AWS Shield, API Gateway, IAM auth, cert etc
Anti-pattern (N/W design):N/W egress back hauling
- Don't directly talk to internet. Restrict egress via Exit VPC
- Use VPC endpoint to talk to publicly hosted services such as S3.
Anti-pattern (Auditing): Questionnaires
- Create attestations instead of entertaining long list of client's questionnaires about the organization's security postures and implementations.
- Get certifications/ assurances and maintain standards sich as ISO 2Ks, SOc2, PCI -DSS etc
Anti-pattern (Auditing): Manual technical auditing
- Inconsistent
- Time consuming, not frequent
- USe automated continuous auditing tools and processes such as Cloud Watch, Inspector, Trusted adviser, Evident.io
- Practice DevSecOps- securit as a code, proactive controls enforced by code
Anti-pattern (S/W delivery): Over-the-wall s/w delivery
- Dev, QA, and ops kept separte- no concept of DevOps basically
- A lot of manual process
- Infrequent release cycles
- Implement DevSecOps
Comments