Several areas of traditional IT services may not translate over into the cloud platforms. Within AWS, tenants place a request for additional shared services including additional inbound bandwidth, additional LUNS within the cloud storage, and additional virtual machines within the VPC. AWS services, not the client, orchestrates these shared services. Tenants need to rely on AWS security controls to ensure these services do not add any additional attack surfaces or vulnerabilities into their VPC. Tenants need to consider what level of layer of security they will need within their VPC. Traditional security solutions like hardware based firewalls will not install into a cloud based VPC. The underlying infrastructure within the VPC features virtual networks, virtual servers, enabled with endpoint security and other adaptive virtual controls.
In a cloud network, any person or system with the right credentials can instantly add new infrastructure. This makes it far easier to change the network to a cloud network unless the controls and monitoring are in place.
Technologies like orchestration spin up virtual machines and place these assets into a production VPC in seconds. Traditional security measures like vulnerability scanning are no longer enough.
The ease of spinning up systems and high rate of change make it very difficult for security teams to maintain complete control of their cloud environment. They make this worse in hybrid networks (IT environments that include both on-premises and cloud networks) and multi-cloud environments (IT environments that include cloud networks from multiple cloud providers).
The lack of centralized data makes it difficult (if not impossible) to get an accurate sense of the organization’s overall security posture, data privacy enforcement, and continued compliance reporting. Many forms of a traditional aspect of security do not fit into the virtualized model. Many security efforts used in an on-premise deployment require a new way of thinking when moving into a cloud instance. CISO’s and CIO’s need great awareness of cloud security capabilities prior to the actual deployment of the new services.
Developing a Fluid Cybersecurity plan within AWS
Cloud instances, along with continuous development of applications within the VPCs, required a fluid cybersecurity plan. As the tenants’ cloud applications change over time, the security posture and adaptive controls need to adjust as well. Yet, most times, applications have changed without the security group knowledge.
Having a fluid AWS cloud security strategy is important. Even with the first cloud migration, basic security solutions won’t offer you the protection you need to safeguard your cloud platform. Developing a global risk and compliance program to help with a structure for the fluid cybersecurity plan.
Implementing a GRC structure with success
To build a strong GRC program for any company, you must know:
- Which assets are you trying to protect?
- What are you protecting against?
- Why must we protect the asset?
- What are the right safeguards?
- Who is protecting them?
- When they’re protected?
This approach lets you bake cloud security into all stages of your cloud application development process.
GRC helps to implement a good fluid cybersecurity strategy. Create a fluid and living document with your security policies and controls and share it on an internal drive where everyone within your organization can access. Stakeholders, external collaborators, and third-party vendors in pen testers should have access to the GRC plan.
Adding in pen testing to validate ongoing GRC changes and implementations is highly recommended.
AWS Policy for Penetration Testing
AWS customers are welcome to execute pen tests against their provisioned VPCs.
Cloud network security assessment or penetration tests against their AWS infrastructure without prior approval for 8 services, listed in the next section under “Permitted Services.”
Ongoing cloud security posture management should include cloud security controls along with critical security controls built for a cloud environment.
The following activities below permits tenant and 3rd party pen testing within the tenant’s VPC within AWS.
- NAT Gateways, and Elastic Load Balancers
- RDS
- CloudFront
- Aurora
- API Gateways
- Lambda and Lambda Edge functions
- Elastic Beanstalk environments
The tenant is 100% responsible for all pen activities. This AWS tenant handles all arrangements with 3rd party testers. The tenant needs to ensure the testing follows AWS user policy.
AWS Security Best Practices – Preparing and maintaining a secure Virtual Private Cloud for pen testing and vulnerability scanning.
- Understand clearly what AWS architect is open for 3rd party pen testing.
- Submit the notification documents with AWS prior to engaging in a pen test.
- Pen testing:
- Validate data plane only Cloud Security Controls within the tenant VPC.
- Document testing results after each pen test.
- Verify the testers, white, black, or gray box teams have access to the cloud assets.
- Backup Your Data
- Create a Prevention program – post pen test
- Ensure it has completed all remediation on all services prior to placing back into production.
- Execute a fresh pen test after they complete remediations.
Conclusion
Maintaining cloud security should be a top-to-bottom effort with every member of the organization taking responsibility for it. Ongoing pen testing against the AWS instance is the only way to ensure continuous compliance and security adaptive control. As more cloud systems become better automated, so is the need to test, validation, deploy, remediate with additional pen testing sequences.
The threat landscape is constantly evolving and attackers are always looking for new ways to bypass all counter security measures.
The quicker you respond to a successful attack, the easier it is to reduce the damage. You can identify where and why the breach occurred, what your security vulnerabilities are, and how you can solve the problem before it gets worse, even in the cloud.
