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.

Misconceptions around SSAE 16 / ISAE3402 / CSAE 3416

Post my previous post, I received a mail from one of my Friend around SSAE 16 / ISAE 3402 and I provided the reply to the friend and then thought, why not share the explanation with the wider Audiences for the good.  May be if somewhere I made a mistake, I would also get to learn -

Hi MT,

 

You are doing a good job...:-)

 

"The discussion was more centered around the need of Assurance Standards like SSAE 16 and ISAE 3402 and the interesting twist that was brought in was "If my organization is ISO 27001 Certified, do I still need to undergo SSAE 16 or ISAE 3402 Audits?"

It took me good enough time initially to make the person understand that the ISO 27001 standard and the controls framework revolves around the Information Security and not just IT Security."

 

Well, I've the same confusion... rather argument. Though ISO27001 is focused on Information Security, it doesn't stop you from adding additional controls, if required. As it is a standard, everything is in black and white..nothing more nothing less...just follow/comply to whatever is mentioned. If you need to add additional controls that you considered as very important, then add the controls and comply.

 

Wherein SSAE16 leads to confusion as they allow you to define your own controls based on GCC (general computer controls). If I select 10 controls, which I feel as important, for example, it is not necessary that you will agree to that, as you may have a different opinion and probably select few different controls that you feel as important. In other words, if 2 people are asked to define the controls for the same environment, the list of controls will definitely not match.

 

Whether it is ISO27001 or SSAE 16, the auditor will test the stated/defined controls and provide an opinion...of course in a different way i.e. either qualification or non-conformity, but the end result is the same.

 

So, the question is still the same, "If my organization is ISO 27001 Certified, why do I still need to undergo SSAE 16 or ISAE 3402 Audits?"

 

Can you help me understand please?

----------------------------------------------------------

My Reply - 

The point is the way the Audit is approached.  ISO 27001 is quite Generic Control Set that revolves around the set of Industry Standard Controls that may or may not be applicable to the set of given Industry Scenario.  The ISO 27001 is Organization wide control environment where you may select or omit the control from within the 133 controls that are defined in the Standard.  You may add a new control, but that needs to be covered under one of the predefined 11 control clauses (domains).  once done, you define the SOA to identify the controls as applicable/omitted from your Organizational environment.  Under such case the Audit is focused around the SOA and the reasoning for omitting a given control.

However, when you look at the specific set of operations for the given Client, the environment may differ from the overall organizational control set.  Certain controls may be applicable from the current set of ISO 27001 controls and certain controls that have been omitted from the Organizational perspective may be applicable in that scenario.  This certainly requires the organizations to go for SSAE 16 / ISAE 3402 (CSAE 3416 in Canadian Context) by defining specific set of controls.  

Let me give you an interesting perspective on the difference of Scope of ISO 27001 and SSAE 16 / ISAE 3402 / CSAE 3416 - 

1. ISO 27001 specifically focuses on the Controls around Information Security, it does not cover the other scope like Contract Management, Delivery Organization & SLAs, these controls may be defined in the SSAE 16 / ISAE 3402 / CSAE 3416.  ISO 27001 doesn't have the provision on these sets
2. ISO 27001 Certification revolves around the Set of 11 Control Clauses, where as in case of the SSAE 16 / ISAE 3402 /CSAE 3416, you would find that the Control Clauses can be customized to suit the environment, operations and services to be covered.
3. Interesting point is around the set of Controls and Operations that are covered in both the cases.  As I mentioned above ISO 27001 focuses on Information Security and the Controls and Operations around that. However if we look at the SSAE 16 / ISAE 3402 / CSAE 3416 they can cover other set of operations and controls like Accounting Principles, Financial Controls etc.
4. SSAE 16 / ISAE 3402 / CSAE 3416 SOC 1 controls and Audit Reports revolve around the Service Organization Controls that impact the Internal Controls on Financial Reporting (ICFRs) of the client. ISO 27001 does not focus on ICFRs.
5. SOC 2 Reporting focuses more around 5 Trust Principles and how each control is implemented, monitored, executed etc.  Even SOC 3 Controls focus on the same 5 trust principles, but the objective of reports is different
6. SOC 1 & SOC 2 Audit Reports are restrictive reports and the Intended Audience are limited set of people within the Service Provider and Client Organization. SOC 3 reports are not so confidential and can be shared publicly as desired.

I hope this clarifies you with the difference between the two Standards and Reporting Requirements

Misconceptions around SSAE 16 / ISAE3402

Pretty recently was indulged in a discussion around the need of Certification to the Need of Assurance.  It was a pretty interesting discussion that led me to evaluate the conceptions and misconceptions that prevail in the industry. I thought why not share it with the rest of the folks who would like to participate in the discussion here (though the discussion is over in the real life)

The discussion was more centered around the need of Assurance Standards like SSAE 16 and ISAE 3402 and the interesting twist that was brought in was "If my organization is ISO 27001 Certified, do I still need to undergo SSAE 16 or ISAE 3402 Audits?"

It took me good enough time initially to make the person understand that the ISO 27001 standard and the controls framework revolves around the Information Security and not just IT Security.  The certification process and the audit methodology involved has a different perspective from the perspective that SSAE 16 or ISAE 3402 Audits take.    

Another argument that was thrown in during the discussion was SSAE 16 and ISAE 3402 are aligned to the Financial Industry and the other industries do not have much benefit of adopting these standards. I had a tough time addressing this point as the set of people were not ready to understand the point for the misconception had a deep rooted belief behind it.  To explain them I had to then break the entire Audit and Reporting perspective of SSAE 16 and ISAE 3402 by the Audit Reports and the manner in which Audit is Approached.  The discussion went from points to tangents with the counter arguments, and there I had to actually dissect the SSAE 16 and ISAE 3402 Reporting requirements as based on the Impact to ICFRs and the Trust Principles. The explanation around Corporate Governance and impact to ICFRs and the relationship between SSAE 16 SOC 1 Type II and ISAE 3402 Type II report helped the audience to clarify the misconceptions they were carrying.

Another aspect that came in to my notice is the misconception around the Reporting requirements in ISAE 3402.  I was a bit startled that one of the person from a Senior Audit Position came with the SOC 2 Reporting requirements for ISAE 3402.  I clarified to them that there is no SOC 1, SOC 2 or SOC 3 reporting requirement in ISAE 3402, however ISAE 3000 provides with a provision to customize the ISAE 3402 reports to suit the Reporting Requirements and that the ISAE 3402 Report may be based on SOC 1, SOC 2 or SOC 3 as may be deemed reasonable.

The next point was to distinguish between the Certification and the Audit Report to provide "Reasonable Assurance".  Most of the participants in the discussion carried a misconception around SSAE 16 and ISAE 3402 about the "Certification". They thought that the Auditors issue or release a Certificate of Compliance.  However, they well noted when explained that the SSAE 16 as well as ISAE 3402 Audits do not result in any certification, rather they result in issuance of an Audit Report that "may be" called a Report on Compliance Status and where the Auditors provide with "Qualified" or "Unqualified" opinion on Service Organization's Controls as defined and implemented for the given "client" operations. 

This however is not the first time that I had been in such a situation, where I had to explain the requirement to undergo an Audit that is more of Attestation Audit than a Certification Audit. But I hope that as these two standards come more into practice, the situation would not look so grim to me.

BYOD Program & Controls Requirement - II

As I wrote the previous Post - BYOD Program & Controls Requirement I received the comment on WFH, but I am certainly not covering that in this article, as that is a separate topic of discussion. What is more interesting that broke out as a discussion point with a colleague over a cup of coffee.  The discussion actually presented a counter argument to the Jump Server configuration.  

While in the discussion, I was very much inclined to and well still am that an organization as the first step to BYOD program should define the set of machines that they would allow.  It is pretty much important for the organization to define whether they are going to allow.  The Deep Dive on the topic reveals that the selection of devices would prompt additional thought process or should I say depending on the Support Strategy for the BYOD program the organization needs to define what devices would be allowed.

The various strategies would revolve around user experience v/s technological deployments. If an organization would like to restrict user experience and go with technological deployments that would ensure Data Security and related controls, the organization would then need to restrict the BYOD to Laptops and Desktops (may be or when its WFH). In this case the controls would be around the set of controls that have already been discussed in the previous post as mentioned above.

In case the organization would select User Experience then the organization would need to ensure that they provide support to any device and enhance the Mobility aspect of the user.  This decision however needs to be based on the following decisions - 

1. What applications would be supported for BYOD and what level of modifications / application changes would need to be carried out?
2. What level of Security would be needed to extend the support to the devices?
3. What would be the application support, would it be Browser based only or Client based with a part of the program sits on the client side
4. Would VPN security be extended to these Devices that would be supported?

There are many more questions that need to be answered for a Successful BYOD program. The Organization would additionally need to check if One Device One Number sort of Program be adopted or not. If the organization would decide to implement this program for increased mobility they need to ensure the Soft Phone Support. 

The BYOD Program as it seems is not actually an easy decision to take as the organization would require to answer many other questions and Specifically that would help them ensure mitigating Risks and meeting Compliance Requirements in Operationally Effective and Efficient Manner

BYOD Program & Controls Requirement

BYOD or Bring Your Own Device is the way organizations are planning to take.  The talk is going abuzz in the corporate world as it would help organizations reduce their IT budget and increase operational efficiency.  In my view it is not that bad an idea, but would require looking a bit deeper at the Compliance perspective and the risks that would emanate when an organization would run BYOD.  The Organizations would require investing and managing various technological solutions to ensure that the Data Privacy and Protection Laws of the world are addresses and that the common framework of controls is enforced across all the devices that come in being due to BYOD. 

The BYOD program from the aspect of controlling data access and ensuring data protection would need to evaluate and consider deploying following technologies:

•   Jump Server – to log in to the organizations corporate network and provide viral desktop environment to the users.  The virtual desktop would have all the desired user settings including file & print configuration, Proxy settings, mailbox configuration and the application shortcuts for the desired applications for the user concerned
• Network Admission Control – to control the risks emanating from the unpatched and unprotected personal devices that can introduce Trojans, viruses, worms, BOTS etc in the corporate network.  The Organizations would need to critically look at investing on a strict Anti-Virus & Patch Management Regime Supported by the Network Admission Control devices.
• Two Factor Authentications – to ensure that the password compromises do not impact / provide access to the corporate network. Additionally this would also help organizations to be able to support the Work from Home (WFH) program thus further reducing their operational cost associated with Facility Management for the ever growing number of seats with workforce increase.

These are just the indicative controls that should be considered or rather implemented by the organizations seriously going the BYOD path.  Certainly the CXOs of the world would be better placed to take the final decision on the set of controls from the likes of IDM, DLP, SSO to add to.  This would certainly require an indepth assessment on the requirements and the risks emanating to an organization.

Time to Consolidate and Govern

Organizations have done a lot to secure their infrastructure, get compliance efforts in place and get going with the emerging requirements that are hard pressing them to move to excellence on the Security Front. But how much to secure is secure? It should not be the case where Security that is supposed to be the business enabler becomes a show stopper.

In my numerous discussions with the CTOs and CIOs, I noted that many of them do not know why a recommendation from consultant or a requirement as being driven by their CISO / CSO is to be honored. There were few remarks as in they go with the general opinion during the meeting and if majority voices to go for it, they go for it. Strange ain't it? To me it was rather shocking. In few other cases, the CIOs I interacted with were a little Puzzled on what data to be secured and where does it lie in their network. Shocking, certainly it was a shocking revelation for me. but I had to accept it the way it is.

So what do we require now? What I call is consolidation of efforts driven to manage IT. Consolidation of Overall Compliance Scenario, which till date is happening on as-on where-is Project basis. Different SMEs leading different Compliance Programs with no interlink between their efforts. The CIOs need a deeper and clearer view of what's happening in the Organizational IT Landscape with a definitive look at the requirements driven from the Risk perspective.

Certainly, I am talking about establishment of a Governance Framework within an organization to ensure that the projects do not get executed as standalone projects and that they have the required interactions between them to rule out any redundant step / control deployment. The governance framework thus established needs to run in a risk management program. This Risk Management program should not just look at the risk emanating from the threats pertinent to organization, but also the threats emanating form the lack of governance to IT Landscape.

The efforts more need to consolidate to ensure that the Organizational Approach towards Securing Data and Information is Top-Down Approach than the Bottom-Up as it will give better control and insight to the Controls Deployment. Any Control / measure deployed will have strict backing of the output from the Risk Management Exercise.

This would not mean that the Organizations need to do away with the Bottom-Up Approach all-together as during the Risk Management Exercise, it will be the Bottom-Up approach that will provided an insight to what is going the way it should and where the gaps are. The Risk Management exercise also needs to be aptly supported with a Business Impact Assessment Program to ensure that the inputs from all the quarters are taken in consideration when decisions are being made.

The market is already moving towards the Governance frameworks and there are many tools in place to address the consolidated requirements in Governance, Risk and Compliance sphere, its just that the drive is from the Vendors and OEMs, we still need to see the Organizations driving it. From where I see, the Role of CISO would need to be molded as that of IT Risk Manager and an Office of IT Governance needs to make its way to the IT Board Room.