Clarification on effective practices for testing across network and application layers, for comprehensive and efficient cybersecurity.
Introduction
Here are the most important and most Frequently Asked Questions for conducting penetration testing. Our focus is on clarifying effective practices for testing across various network and application layers, ensuring your cybersecurity measures are comprehensive and efficient.
FAQs
1. What is Network Penetration Testing?
Network penetration testing is a proactive security exercise in which specialists simulate an attack on an organization's network to identify and address vulnerabilities. This "mock hack” helps ensure that potential intruders cannot exploit weaknesses.
2. What is a vPenTest and how does it fit into the “agile GRC concept”?
Traditional penetration tests are usually high-cost, annual, point-in-time assessments that may leave organizations vulnerable for the rest of the year. Virtual penetration tests (vPenTests) are generally lower cost and allow for more frequent, automated tests (monthly or on-demand). vPenTests typically cover all publicly exposed endpoints of your on-premise or cloud-based environment. Frequent testing aligns with Trustero’s agile GRC concept by providing continuous oversight and rapid adaptability to new threats.
3. What information do I need to provide for a vPenTest?
For your external vPenTest targeting the network layer, you need to provide all external facing (publicly accessible) IP addresses and/or domain names. This should include:
- Web portals (public-facing web applications)
- VPNs
- APIs (system-to-system connections)
NOTE: This ensures comprehensive coverage of all potential entry points into your infrastructure.
4. When should Penetration Testing be conducted?
While most frameworks require at least annual testing, the evolution of technology like vPenTest allows for monthly testing, providing ongoing assurance against external threats.
5. What frameworks require vPenTests?
Most major information security frameworks recommend or require penetration testing, including SOC 2, ISO 27001, PCI DSS, HIPAA, HITRUST, NIST CSF, FedRAMP, CMMC, and FISMA.
6. What if I am not a SaaS Provider? Do I still need to conduct a vPenTest?
Certain scenarios like legal firms using cloud storage or marketing services using cloud solutions are not directly responsible for conducting a vPenTest. In these scenarios, the PenTest requirement is “inherited” by the cloud storage solution.
NOTE: See Scoping - Determining Control Responsibility for more details on “inherited by” and “outsourced to” controls.
7. How does vPenTesting differ from Vulnerability Scanning?
A vulnerability scan is the first step in preparation for vPenTesting. The vulnerability scan is designed to detect and identify any security vulnerabilities. Once vulnerabilities are identified, the vPenTest attempts to exploit the vulnerabilities, with the ultimate goal of gaining access to secured data and systems.
8. Are there audits that require above-and-beyond a standard vPenTest?
Yes, the Payment Card Industry uses stricter standards in its Data Security Standard (the PCI DSS). The SAQ-D (card-present) scope requires using an Approved Scanning Vendor (ASV) to conduct external vulnerability scans. Here is the list: Approved Scanning Vendors
Another Payment Card Industry standard may require internal testing, looking for weaknesses between your organization’s internal network layers. Internal testing is required if the Card-holder Data Environment contains resources (cloud-based) or systems (on-prem) that are used for purposes outside of the services stated within the Attestation of Compliance (AoC), and Report on Compliance (RoC).
9. What about nice-to-haves? Internal application layer testing?
Remember, the goal of information security is to be proactive versus reactive. With a proactive approach, security controls can be integrated into operational workflows, enabling continuous security checks, as follows:
- Educate Developers: Train developers on secure coding practices and the importance of considering security at every stage of the development process.
- Continuous Security Assurance: Incorporating security testing such as Static Application Security Testing (SAST) for every pull request and Dynamic Application Security Testing (DAST) to scan libraries in real-time ensures vulnerabilities are identified and addressed before software deployment. This avoids introducing new vulnerabilities into the production/live environment.
- Infrastructure as Code (IaC) in Cloud-Based Environments: Adopting best practices for Infrastructure as Code allows for the consistent and secure deployment of environments, reducing human errors, and ensuring compliance with security policies through code.
- Regular Security Configuration Monitoring: Setting up at least weekly monitoring of all security configurations in the production environment helps in early detection and remediation of any new vulnerabilities.