We will assess your architecture concept from the Information Security point of view and develop a baseline for your Secure SDLC and architecture hardening.
Adversary simulation assessments are scenario-based penetration tests, that focus more on achieving specific goals in the infrastructure as opposed to discovering all potential vulnerabilities. During the test, a complete path is developed from the outside networks with no prior knowledge of the infrastructure to the internal protected segments and hosts of the network.
The assessment utilizes many techniques that are not a part of a usual penetration testing methodology to gain initial access to the infrastructure. Social engineering attacks of different kinds, physical access misconfigurations, wireless attacks will all be tested to provide complete coverage of possible attack vectors. Sometimes it also makes sense to start with an insider scenario, where office employee-level access is given to the penetration tester.
After gaining initial access, internal services, applications, servers, and personal machines are tested for any vulnerabilities that may allow lateral movement to other hosts and segments in the network. Segmentation flaws are also taken into account at this stage, as they may allow the attacker to gain access to restricted regions of the infrastructure. The penetration tester may also exploit vulnerabilities in the employee-owned machines, install keyloggers and screen grabbers, use saved passwords of the machine’s users to gain authentication credentials to internal services and applications.
If the penetration tester manages to gain both network-level and application-level access to the target assets, the adversary simulation test is considered complete. A report is created, detailing all discovered attack vectors and paths. To read an example of a real-world attack path, please refer to the relevant case study.
When to perform adversary simulation tests
Sometimes adversary simulation is not more valuable than a penetration test. Because penetration testing assessments will only focus on immediately exploitable vulnerabilities, the test will skip potential or medium-risk security flaws, that may still present a significant threat to the business processes of a company.
It is recommended to perform adversary simulation to:
- test threat response, detection, and investigation processes
- test social engineering training processes and prevention capabilities
- test internal monitoring and detection capabilities
- discovering potential compromise paths
- test endpoint protection systems, policies, and configurations
- test wireless configurations and employee training on dealing with wireless attacks
However, it is recommended to prefer a penetration test over an adversary simulation assessment to:
- discover the most potential vulnerabilities in internal or external infrastructure
- perform a complete security evaluation of a Web application
- perform a complete security evaluation of a mobile application
- perform a penetration test as per the requirements of a security standard (such as PCI DSS)
Differences between adversary simulation and penetration testing
- Penetration testing assumes discovering most potential vulnerabilities in the target application or infrastructure and confirming their exploitability, while adversary simulation uses the vulnerabilities to create an attack path.
- Penetration testing assumes access to the target segments and basic knowledge of the environment.
- While performing penetration testing assessments, the penetration testing team does not try to conceal their actions and the security team is aware of the testing process.
- Penetration testing does not rely on human interaction and thus does not use social engineering or keylogging software to gain access. Sometimes office networks and employee’s PCs are completely excluded from the scope of the penetration test.
Discovering potential compromise paths. Test threat response, detection, and investigation processes.
Web applications vulnerabilities could let an attacker obtain unauthorized access to the application or exploit its functionality to gain access to sensitive information, underlying OS or conduct unauthorized actions (i.e. transactions in a banking application).