Plan your pen testing
The reality is, for most organizations, penetration testing is less than continuous. Well-resourced and security-conscious companies are likely to conduct regular vulnerability scanning (which is not the same as testing) and layer semi-annual pen tests into the mix. Even for companies with the ability to test their networks (and their network segmentation) more frequently, pen testing is never 24x7. Therefore, the best way to be sure that recurring testing achieves its goal of finding vulnerabilities and validating controls are working properly is to review the scope of every test (i.e., what are you are testing; why are you testing) and to assess changes in the environment. A good question to ask as you embark on your pen test planning is: What are the high-level risks we need to address from an exposure and configuration standpoint and/or a potential data loss standpoint?
As for changes to the environment, no network is static and so past testing requirements and scope likely do not accurately reflect today’s or tomorrow’s test. Some things to ask before you write a requirements guide for your test include: What configuration changes have been made between the last test and the upcoming test? Were any new patches applied, and have new patches been released that aren’t yet implemented (i.e., new known vulnerabilities)? Have any new services been deployed?
Using the results from your automated and continuous inventorying, mentioned above, include current dataflows and applied segmentation information in your scope, too. Establishing tighter integration between business and technology will help accomplish this step.
Use compliance guidance to improve requirements
The PCI requirement 188.8.131.52 says that segmentation testing should “validate the effectiveness of segmentation controls, every 6 months or after any changes to segmentation controls, to ensure segmentation controls continue to operate effectively.” Following this guidance, even if you’re not subject to PCI DSS, will align your company with industry-leading practices. Further, PCI mandates require “continual, complete isolation between cardholder data environments (CDE) and non-CDE systems.” This requirement is a good recommendation for any organization’s most-sensitive data, regardless of PCI applicability. Implementing strict segmentation around business-critical applications and data is always best practice for preventing unauthorized access to and leakage of data.
Segmentation testing should go well beyond port scanning and enumeration of available services. The point of segmentation testing is for testers to try to gain access into environments to which they shouldn’t have access. There are various ways to test segmentation controls—through network-based communication channels, app-based channels, identity and access management, credential stealing...the possibilities are endless! So, too, are attackers’ tricks, therefore your testing should reflect as many avenues as possible. Importantly, segmentation testing must look at what can access what within environment. In other words: Which applications are connecting to which other applications? Should server A be talking to that host B? Is this type of traffic, user, direction, flow, frequency expected, etc? Is it authorized? The answers to these types of questions should be part of the audit report you receive from your testers.
Optimally, the methods used for testing should include not just brute force against systems and applications, but also use analytics (such as the aforementioned overexposure analysis) that is context aware. Only in this way will you start to understand your cybersecurity risk—where your biggest vulnerabilities against your specific environment lay in wait—and be able to determine your best strategy to mitigate those vulnerabilities.
In our next webinar recap post, we’ll address some methods you can use to mitigate risk and avoid data breach.
To close out this post, a good game plan that will help you get started on right-sizing your segmentation testing includes the following:
- Incorporate automation to understand data flows
- Integrate segmentation testing into your security strategy
- Learn everywhere microsegmentation is in use, especially with containers, cloud, and other dynamic/ephemeral environments
- Update upcoming pen test plans with recent changes and requirements; pen testing requirements are not static
- Update risk and threat models to include new attack types and scenarios that were previously unknown or enumerated