Compliance Management - Considerations

Many a times we encounter situations where we find that certain Information Security Policy requirements and considerations are not in line with the Global Security Best Practices and they actually are not in-line with the Global Standards to that effect. But, the major mistake that we make at such a point is to take into considerations the Business Requirements for that organization or for those who actually are the recipient of the overall results on those Business Requirements.

The issues are overwhelming for the Risk and Compliance Manager across the world as they try to bridge the gap between the Auditor's Expectation with the Real World Scenarios with all the practicalities.  This doesn't mean that Auditor's Expectations are not practical or not something that need not be entertained per say.  What is more important for the Risk and Compliance Managers as well as the Business Managers is to ensure that these expectations are well understood so that it would be easier to meet them by remediating the open issues.

More often than not Auditors as well as Risk & Compliance Managers are often misunderstood and seen as a "Red Flag Bearers" by the Business & Technology Managers. Though this perception can't be justified, but then they have their own reasons as they have to run the show.  There are many a times when Business as well as Technology Managers have to take quick decisions and at times they circumvent / bypass some critical security / compliance considerations to ensure that the "Show has to Go on."

However, though they say everything needs to be done to ensure that the Business as Usual must prevail, there are some checks and balances that must be applied and Compliance Considerations must be brought to the every day work life.  Though I had maintained for long that "what is compliant" is not always secure (for if it were secure we would not have as many breaches as we hear), I still maintain that Compliance provides for the baseline controls we must have in place.  How we convert them from Compliance Controls to Security Controls depends on how Security Focused we are.

The Compliance Considerations that I prefer Organizations should keep up to are -

1. Following defined processes and procedures
2. Documenting what is being done - meetings, notifications, trainings, approvals etc.
3. Documenting the changes being introduced
4. Resolving issues with Long Term strategies than short term remediations
5. Following Risk Based Approach
6. Adopting Return on Investment from Technology (ROIT) adoption rather than resorting to Cost  & Benefit Analysis (CBA) - This would always prove to be profitable approach in longer term
7. Unified Compliance Approach rather than Project base Compliance Approach working in Silos - This would always help reduce duplication / redundancy in controls being managed and technology being deployed. There always is an overlap of requirements across various Industry standards and regulations impacting compliance posture of any organization
8. Drive Enterprise-wide Compliance efforts rather than Business Segment Silos

There are few others that may be considered, but the basics of Compliance Management would seek solace in the ones mentioned above.

PCI-DSS and Risk Management

PCI-DSS and requirement of Risk Assessment have a very close relationship. In effect PCI-DSS has specified the requirement for an annual risk assessment as per the control 12.2 and has mentioned the requirement under guidance for requirement 10.6.2 and Testing Procedures for requirement 11.5.

PCI-DSS requirement 12.2 establishes the requirement for implementing a risk assessment process that:

• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),
• Identifies critical assets, threats and vulnerabilities, and 
• Results in formal risk assessment

Guidance to PCI-DSS requirement 10.6.2 - Logs for all other system components should also be periodically reviewed to identify indications of potential issues or attempts to gain access to sensitive systems via less-sensitive systems. The frequency of the reviews should be determined by an entity’s annual risk assessment.

Testing Procedures for 11.5 - Additional critical files determined by entity (for example, through risk assessment or other means).

When we analyze the requirement 12.2, it has though established the need to conduct annual risk assessment per set standards including NIST 800-53 and others, but it has not covered the overall efficiency led requirement for a risk assessment. The requirement as cited above states setting up a process that results in a formal risk assessment by the way of identifying the critical assets, threats and vulnerabilities, but shies out to specify the continuous monitoring of Threats as well as Risk Spectrum.  

In the current scenario, if an organization has to pass a PCI audit, it would be easy to lay down the risk assessment process, conduct the risk assessment and then publish the risk assessment report. But in the real world, is that all that an organization would need to fend off the hackers? Certainly not!!

So what is needed for the organizations to step up to and for the PCI-DSS as a standard to emphasize? The answer is to extend the requirement 12.2 from a being a risk assessment requirement to a risk management program requirement. This would put emphasis on the requirement to cover the full circle from the time Threat and Risks are identified to the point that those are remediated / accepted.

PCI standards council should also look at introducing Risk based approach to select the Compensating Controls by the organizations. The completed ROC should be modified to include the outcome of Risk Management snapshot covering the reasons to not implement given control and selection of the Compensating control instead. 

In the prioritized approach also, PCI Standards Council should assert highest priority to Risk Management.  

On part of the organization impacted with the change in the requirements around Risk Assessment and Management, the focus should be on the composite Risk Management activities that they conduct at the organizational / enterprise level. The organizations need to understand that the silo approach to compliance never benefits their functioning, rather just increases the cost of managing compliances. If they would integrate the Risk Assessment as required by various standard and compliances, they would be able to harbor a better compliance assertion against each one of them with minimal set of controls and maximum cover.

PCI-DSS Challenges and Considerations

With PCI-DSS fast approaching its deadline for the compliance adherence, most of the organizations are putting their act together to meet the compliance requirements. But there lies a challenge to look for the right approach therein. The consultants/implementers/maintainers are often dwindling about what approach to take in this area. Various vendors are pitching for their products and many are claiming to achieve the same through technical deployments. But following questions stand by with us -

• Will technological deployment only help achieve the results as required and desired?
• Will it not be a piecemeal approach to plug the issues with what we see as the right requirement for each of the areas as stated above?
• Will we be able to work towards integrating these distinct products and technologies together to achieve the required output?
• What effect changes in the architecture and infrastructure would have on the other Compliances as ISO 27001, SOX etc.

There are many such other questions that would always be hovering around in our minds for us to answer and act upon. However, whatever the approach be the steps to PCI-DSS compliance must focus on the following –

• Highly Sensitive Payment Card Information stored in business databases
• Identification of all systems within the organization where Payment Card Information is stored
• Legacy systems not supporting the PCI DSS requirements for encryption
• Access to payment card information to large no. of business users
• Log Management and Monitoring
• Data Classification and Handling
• Access Management on various systems and devices
• Information Security Policies and Procedures
• Periodic vulnerability assessment and penetration testing
• Segregation of Duties among Production, Development and Testing Teams

Mayank Trivedi