Overpromising is never a good thing when it comes to fulfilling compliance dates. Doing so only further irks both...
the technologists and business owners impacted by compliance audits. Therefore, proper planning around some technology hurdles that commonly trip up compliance efforts can make compliance automation less painful.
Use threat model to define compliance risks
Many companies roll the dice when it comes to compliance across multiple industries. Compliance is expensive, and some organizations simply don't have the budget to embark on fulfilling all of the requirements. For this reason, listing all of the regulatory requirements and identifying how the lack of fulfillment can jeopardize client retention or result in exorbitant legal fees and ongoing reparation costs can all equate to legitimate risks that organizations need to consider.
Although traditional threat models are focused on threat enumeration and countermeasure development, it's important to define the compliance landscape via a risk-centric framework. For example, the seven-stage Process for Attack Simulation and Threat Analysis (PASTA) factors in how insecurities inherently affect business objectives. In stage one of the PASTA process, technologists and business managers define business objectives and identify security and compliance requirements. It's important to determine what the compliance landscape is for your business, product or application to help define the scope of your compliance readiness.
Know what to audit
Most auditors have too much faith in the compliance scanners that they select. This places a lot of dependency on the scanning tools to dictate what is to be scanned and how it is to be scanned. Once you get beyond the marketing hype around compliance policy scanners, make sure to investigate what those checks are actually doing in their respective scanning engines and marry those checks to your regulatory control baseline requirements (PCI-DSS, HIPAA HITRUST CSF, NERC CIP and NIST 800-53).
Here is a password length Windows check example: If scanner uses registry checks, validate that its check is going after right Registry Key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Network) where a REG_BINARY value entitled MinPwdLen is sought.
Agent-based or agentless? Know the difference
Scanning tools use various technologies to receive results from computing endpoints (workstations, laptops and servers). It's important to know what challenges exist with the agent-based or agentless techniques in your scanning solution.
Agent-based technology runs localized scans on your target endpoints via installed software. Agent software deployment requires help from desktop or server-side support teams. You will need a lot of planning to deploy these agents via your IT operations' preferred technology, such as Microsoft Windows Server Update Service and Short Message Service. The good news is that changing firewall access control lists is less messy because scanning activities are localized on targeted endpoints. The only other network traffic associated with agent-based scanning is the reporting communication sent back to a central compliance server; however, this is generally over HTTP (port 80) or HTTPS (port 443).
"Agentless" means that no software is installed on the target endpoints and that all configuration setting inquiries are done from a central scanning server. Although the headache of installing software agents is averted, you may run into challenges if your network firewalls are blocking certain ports that are required by your compliance scanner.
Understand network segmentation
Many auditors don't have a good understanding of the network architecture and network scanning in particular; this always equates to delays in getting results and can make for a lot of finger pointing between compliance auditors and network operations personnel. Knowing what network segments are going to be scanned or having a target list and sorting it by subnets (group them by /24 networks) is very important. If you are doing agentless scanning and have a mobile scanner (e.g., a scanner running on a laptop) that you can physically port to areas where you can connect to subnets, you may avoid having to make firewall-related change requests. Otherwise, there will be holes in the internal firewall that need punching because most compliance scanners are using more than just port 80 (HTTP) and file-sharing TCP ports (such as 137, 138, 139 and 445). Preparing for what ports you'll need to open and identifying your range of access from a central scanning location will save a lot of time and make you look like a compliance-planning czar.
So you have domain admin credentials, now what?
Many compliance auditors have a false sense of security after obtaining domain admin credentials and think they have carte blanche, unrestricted access to query the network. A common pitfall is that the security context of the domain admin (Windows) account doesn't really have the necessary privileges needed to scan target hosts on a given domain. This is a problem if unique Group Policies are tied to different domains with no explicit trusts. Compliance professionals may assume that domain admin equates to being an administrator across all domains of a target enterprise. For this reason, test your credentials via remote desktop or secure shell connections to make sure that you can not only connect to the systems, but also visit the registry or certain file paths on the target endpoint's file system (/etc/pam.d/system-auth) or anything in /etc for *nix-based systems.
Whether you're using Nessus, nCircle, QualysGuard Policy Compliance, Nexpose or any of the other well-known or niche compliance validation tools, these technical preparations will go a long way to improving the success of your overall compliance checks.
From the editors: More on compliance risk management
See below for more from our May 2013 special report on compliance risk management featuring Tony UcedaVelez of VerSprite.
Information Security magazine feature: Reframing compliance with a threat model
Webcast: Compliance frameworks; rethinking compliance strategy
About the author
Tony UcedaVelez, CISM, CISA, GSEC, CRISC, is a managing partner at VerSprite.