Penetration Testing and Cloud Platforms.
A holistic security approach also encompasses the aspect of penetration testing. Not only is it good practice to conduct regular penetration tests on all IT systems, but it is quite often also a compliance requirement to maintain a PCI certification for instance. With the move towards the use of more and more cloud-based infrastructure and applications, some complications arise around this Penetration Testing. For a deeper dive into penetration testing, cloud professionals can check out the CCSP training offered by the InfoSec Institute. Not surprisingly, most Cloud Service Providers do not appreciate unannounced penetration testing directed at their infrastructure and some policies have been drawn up.
The issue
Cloud Service Providers (CSP) such as Amazon, Azure, and Google manage the security and availability of their Cloud Infrastructure like any large enterprise. They monitor and investigate security events and incidents. These providers will need to be able to differentiate between a customer's penetration test and an actual attack on the environment itself. If they don't, traffic could be dropped, blocked or blackholed by dDOS protection or Intrusion Prevention Systems along the way. Not only will this cost valuable time and resources, the shared character of a cloud environment means this could impact other customers negatively as well.
FREE role-guided training plans
Communication
The solution to notify the CSP beforehand seems easy but has a few caveats. Communication is key here, and the method of communication is just as important to the message itself. The CSP will need to be alerted in a timely, clear and precise manner. The notification should include the time and scope of the planned test. The actual test should not deviate from this notification.
Most providers such as Amazon and Microsoft have instructions, limitations and authorization request forms available on their websites. Google works a little different here. They state there is no need to contact them as long as the tester adheres to the Acceptable Use Policy and the Terms of the Service. Testing is obviously only allowed to affect the customer's projects.
Limitations.
The most important aspect of the limitations of cloud service penetration testing is where the responsibilities of the system start and end. This means it is important whether the target system is running within an IaaS (Infrastructure as a Service), PaaS (Platform as a Service) or SaaS (Software as a Service) configuration. IaaS will allow for much more intrusive and broad testing than SaaS, because of the difference in the level of responsibilities and possibly the risk to multi-tenant shared systems. For example, in an IaaS configuration, the Operating System of a target server is managed by and dedicated to the customer. In a SaaS configuration, this is not the case. A penetration test could affect the target and possibly cause an outage for other customers using that same shared system. In the worst case, there could even be an unintended information leak from another cloud customer. Determination of the responsibilities helps to set the scope of the test.
Another aspect to consider when planning a penetration test on a system within a cloud platform is whether pivoting is required. Pivoting is a common attack technique where a system is compromised to attack another system via that obtained access. This might, for instance, circumvent firewall filtering. It could also allow the attacker to leverage a trusted service between two hosts or to jump on to another network via a VPN tunnel or multiple Network interfaces. Pivoting from a compromised cloud-based host to an external non-cloud system is usually not allowed by CSP's which is something to keep in mind. This could limit the penetration tester, but will not be an issue for a real attacker, which means the test is incomplete.
A distributed Denial of Service attack (dDOS) is usually not permitted either. An attack such as this is very hard to separate from other, non-authorized attacks due to it's distributed characteristics. The hundreds or thousands of source IP addresses covering multiple simultaneous dDOS attacks cannot be confidently split. This can trigger automatic mitigation systems and that will negatively impact on other customers of the often shared CSP resources.
Cloud-based Penetration Testing Techniques
A lot of the issues and limitations mentioned are not new. Solutions have been created, and these can be successful. It is quite common for CSPs to have their own internal penetration testing team and additionally to use a third party tester as well. Microsoft has an active offensive Red Team and a Defensive Blue Team within their Azure platform. Other large providers most likely have similar systems in place. While this effort will keep the platform itself secure, customer systems and applications are still out of the CSP's scope. As mentioned earlier with regards to the limitations, these customer systems are naturally the responsibility of the customers themselves.
Some CSP's offer their own internal penetration testing team to customers as a paid service. This takes away from a lot of the planning and communication concerns of the customer and also reduces the number of mandatory limitations to the testing methods. A dDOS attack can be directly targeted at a system from the internal cloud network for instance. This will limit the impact to the bandwidth and the resources of other customer's systems. Because the CSP has much more control over their own tests, items such as pivoting could be amongst the options as well.
Some 3rd party organizations have specialized in cloud-based penetration testing services. NCC Group for instance not only provides regular penetration testing services to Azure and Amazon for their actual platforms, but they are also available for cloud users needing their systems and applications tested.
Nettitude is another example of a cloud penetration testing provider, but most larger specialized security firms can now offer this service up to a certain level.
Other Penetration Testing Service providers are actually benefitting from the flexibility of cloud services themselves. The
Core CloudInspect
What should you learn next?
Conclusion
Time has not stood still around Cyber Security while the connected world moved more and more towards cloud solutions over the last decade. Several large breaches of internal corporate systems have proven cloud security might not be so bad in comparison after all. With this move, Penetration testing has adapted to the new challenges. New external services have sprung up, and existing services both on the side of the cloud provider and on the side of customers and third parties have incorporated the new methods and technologies.
In this Series
- Penetration Testing and Cloud Platforms.
- Penetration testing steps: How-to guide on pentesting
- How does automated penetration testing work?
- Intelligence-led pentesting and the evolution of Red Team operations
- Red Teaming: Taking advantage of Certify to attack AD networks
- How ethical hacking and pentesting is changing in 2022
- Ransomware penetration testing: Verifying your ransomware readiness
- Red Teaming: Main tools for wireless penetration tests
- Fundamentals of IoT firmware reverse engineering
- Red Teaming: Top tools and gadgets for physical assessments
- Red teaming: Initial access and foothold
- Top tools for red teaming
- What is penetration testing, anyway?
- Red Teaming: Persistence Techniques
- Red Teaming: Credential dumping techniques
- Top 6 bug bounty programs for cybersecurity professionals
- Tunneling and port forwarding tools used during red teaming assessments
- SigintOS: Signal Intelligence via a single graphical interface
- Top tools for mobile android assessments
- Top tools for mobile iOS assessments
- Red Team: C2 frameworks for pentesting
- Inside 1,602 pentests: Common vulnerabilities, findings and fixes
- Red teaming tutorial: Active directory pentesting approach and tools
- Red Team tutorial: A walkthrough on memory injection techniques
- Python for active defense: Monitoring
- Python for active defense: Network
- Python for active defense: Decoys
- How to write a port scanner in Python in 5 minutes: Example and walkthrough
- Using Python for MITRE ATT&CK and data encrypted for impact
- Explore Python for MITRE ATT&CK exfiltration and non-application layer protocol
- Explore Python for MITRE ATT&CK command-and-control
- Explore Python for MITRE ATT&CK email collection and clipboard data
- Explore Python for MITRE ATT&CK lateral movement and remote services
- Explore Python for MITRE ATT&CK account and directory discovery
- Explore Python for MITRE ATT&CK credential access and network sniffing
- Top 10 security tools for bug bounty hunters
- Kali Linux: Top 5 tools for password attacks
- Kali Linux: Top 5 tools for post exploitation
- Kali Linux: Top 5 tools for database security assessments
- Kali Linux: Top 5 tools for information gathering
- Kali Linux: Top 5 tools for sniffing and spoofing
- Kali Linux: Top 8 tools for wireless attacks
- Kali Linux: Top 5 tools for penetration testing reporting
- Kali Linux overview: 14 uses for digital forensics and pentesting
- Top 19 Kali Linux tools for vulnerability assessments
- Explore Python for MITRE ATT&CK persistence
- Explore Python for MITRE ATT&CK defense evasion
- Explore Python for MITRE ATT&CK privilege escalation
- Explore Python for MITRE ATT&CK initial access
- Top 18 tools for vulnerability exploitation in Kali Linux
- Explore Python for MITRE PRE-ATT&CK, network scanning and Scapy
Get certified and advance your career
- Exam Pass Guarantee
- Live instruction
- CompTIA, ISACA, ISC2, Cisco, Microsoft and more!
Penetration testing
Penetration testing
Penetration testing
Intelligence-led pentesting and the evolution of Red Team operations
Penetration testing
Red Teaming: Taking advantage of Certify to attack AD networks