Automated static and dynamic code scanners are an essential part of an agile Application Security Program, and regular vulnerability scans are essential for identifying easy to discovery issues in your environment, but nothing replaces the need for a targeted manual network and application penetration test conducted by knowledgeable individuals.
A penetration test is a targeted simulated malicious attack on a computing environment which is used to evaluate how systems or applications in can withstand an internal or external compromise attempt. Unlike a vulnerability assessment, which is limited to the passive identification of vulnerabilities that may exist on a system (e.g. software version checks), where a penetration test will attempt to exploit vulnerabilities and logic control flaws.
Our assessment processes include an active assessment of the in scope systems and applications for known or unknown hardware or software flaws (vulnerabilities), or operational weaknesses. The analysis is conducted from the point of view of a potential attacker (threat agent), and involves active exploitation of known or potential vulnerabilities in the in-scope environment.
Penetration tests are more in-depth than vulnerability assessments for several reasons:
- They may succeed in exploiting vulnerabilities they may not have been a false negative on a vulnerably assessment.
- Your organization will gain an understanding of the actual risk, and can determine the impact of known vulnerabilities.
- Custodela can test for vulnerabilities that cannot be tested using automated scanners due to the potential impact on the environment.
- Custodela can test for vulnerabilities that are unique to your organization, where vulnerability scanners would not have signatures available (e.g. custom applications or unique configurations).
- Custodela can correlate intelligence provided from ‘informational’ vulnerabilities to assist in successfully exploiting other vulnerabilities.
- Custodela can exploit known low or medium risk vulnerabilities, and use the access gained to further exploit unknown vulnerabilities (e.g. vulnerabilities that are not remotely exploitable).
- Horizontal privilege escalation attacks are possible.
- Custodela can identify vulnerabilities that may otherwise go unnoticed by automated tools (i.e. unique to your organization, or specific configuration).
- Custodela can write new or customize existing exploits specifically designed for the target environment.
Zero Knowledge Model. Black box testing is where no prior knowledge of the target environment is known to the assessor. The purpose is to understand how vulnerable an environment is to remote exploitation from an attacker with no inside knowledge of your organization. This knowledge model puts additional time and effort into the intelligence gathering and discovery phase. Public Internet infrastructure Penetration Tests is an example of where this knowledge model is most commonly used
Partial Knowledge Model. Grey box testing is a knowledge model commonly used for internal targeted Penetration Tests and focused Application Penetration Testing, it is recommended to follow this knowledge model to ensure the entire application can be thoroughly tested end to end. For Application Penetration Tests, available architecture documentation will be provided along with credentials for various application roles. For multi-tenant applications, credentials for different tenants should be provided. In both cases, this allows for the assessor to easily test for privilege escalation, security misconfigurations, and other access control related vulnerabilities rapidly. For Internal Network Penetration tests, at a minimum system and application inventory information should be made available to allow for more targeted less aggressive (discovery scanning and application interrogation) assessments to be conducted on internal systems to minimize the chance of service disruption. Further information, credentials, or firewall bypass may be required depending on the scope of the assessment.
White box testing is where significant prior knowledge of the target environment is known to the assessor prior to the assessment. In addition to grey box materials such as architecture documentation and credentials to the applications or systems, source code (if available and applicable) as well as cooperative subject matter experts for the environment and applications should be made available to ask questions or view logs during the assessment. The benefit of white box testing is that the time to complete the assessment may be reduced as the assessor has a lot less information to gather independently. Other benefits include less risk of impact to the in-scope environment due to the additional probing requirements, and a far more thorough and complete test per for each engagement hour. White box knowledge models are commonly used when applications are internally developed by the partner organization.
This source model will be used if the threat agent is any and all systems on the Internet. No firewall, VPN, or system configuration changes will be made prior to the assessment execution. This model will allow your organization to determine if systems are vulnerable to exploitation to the threat source that poses the highest risk.
This source model is used when we are looking to have specific systems or services exposed to the assessor that are not completely available to the public Internet, but are available to trusted or semi trusted partners or individuals. This model is most appropriate for assessments where access is provided to partner connections, IP filtering, or specific proxy/api authentication gateway barriers.
This source model is used when looking to assess systems are commonly available to everyone connected to the internal network (i.e. corporate networks). These assessments are typically used to test internal access and segmentation controls to determine if your sensitive production environments are adequately protected from non-production (corporate/development/consumer) networks.
This source model will be used when the network controls in place are removed to the threat source. A threat source may gain access to a system or systems with limited or limitless network access to the target environment. The threat source may also compromise boundary network devices restricting access to the target environment, or a misconfiguration may inadvertently expose the threat environment to a threat source. Providing full access to the threat source will allow the systems to independently be tested to determine how they would withstand a direct attack, validating defence in depth.
Prior to the assessment, we want to ensure the scope and rules of engagement are clearly defined to ensure only the required systems are targeted, and to ensure the time used to conduct the assessment is efficiently utilized. The amount of detail required in the scope depends on the type of assessment to be conducted. The following must be first determined:
- Target(s) – IP addresses or Subnets and URLs
- Type of assessment to be conducted
- Knowledge model used
- Threat source location
- Restrictions (assessment window/methods)
- Contacts and disclosure rules (i.e. immediate notifications of critical vulnerabilities discovered)
Our assessment IP addresses will be provided. We would ask that all IDS/IPS/WAF devices (unless used for specific application vulnerability compensating controls) allow our IP addresses to scan the target(s) unimpeded.