Showing posts with label risk. Show all posts
Showing posts with label risk. Show all posts

Monday, July 29, 2013

Creating an Information Security Compliance Capability

In my last post I wrote about compliance and 3rd party providers and this time I want to go deeper into what it takes to have a good compliance capability. Please note that this post doesn't go into detail but will provide sufficient guidance (I guess).

So first of all, why we need a compliance capability or function? Organisations today have regulatory requirements that they must comply with. As an example, if the organisation’s mission is to provide healthcare services in the US, then HIPPA and/or FDA will be a regulatory requirement. Now, if part of the organisation’s business strategy is to go public (IPO) in the US, you will need to comply with SOX requirements.

Also there are industry best practices or frameworks that an organisation can adopt as part of its business or IT strategy such as ISO, NIST, COBIT which will then be part of its compliance requirements. Also, last but not least, an organisation’s internal policies should also be considered as part of its compliance requirements. The following figure illustrates what I’ve just mentioned:




Why it is important to be compliant?
Well, to simply put it, being non-compliant with regulation requirements might imply quantifiable losses to your organisation (financial sanctions, impossibility to offer in the NYSE, etc) along with non-quantifiable losses, such as image and reputation loss. So, in other words, non-compliance creates a risk to an organisation. If you do some googling for HIPPA or privacy breach and you’ll get what I’m meaning.

What happens when you are not complaint with your own policies? Well, internal or external auditors will have a finding (risk), which will require a remediation plan and funding to rectify the non-compliance… Plus someone above you in the corporate chain will not be happy.

Why implementing a compliance capability is good?
A compliance capability will provide the organisation the resources required to understand compliance requirements, communicate them, assist in achieving a complaint state, maintain it, manage the risks associated with non-compliance situations and track their rectification.

In order to implement this capability, it is necessary to define a framework, like the one shown in the following figure:






Process Management

The first step for implementing a compliance capability is to plan the capability itself in terms of policies, procedures and human resources. Depending on the organisation and the compliance scope, the number of human resources will vary.

Also, the capability’s policies and procedures need to be developed. These will specify how the capability’s governance is to be achieved and how it will relate to other capabilities at an enterprise level and other governance functions (i.e. IT and Information Security).

Things like principles, roles and responsibilities, KPIs, assess compliance (determine compliance requirements, build SOA), track and rectify non-compliance issue (register) amongst others.

Changes in processes across the enterprise might be required in order to create interfaces for compliance reporting.


Risk Management
Any non-compliance issue will trigger a risk to the enterprise. Because of this, it is very important that the compliance framework is inline with the enterprise risk management or IT risk management framework. Each non-compliance situation must have it’s risk assessed tracked as part of the organisation’s risk profile until rectified.

Based on the organisation’s risk appetite and tolerance it is possible to assign to each non-compliance issue a risk rating.

The compliance policy and non-compliance issue management procedures should establish how this interface will work.



Monitor and Evaluate
In order to evaluate the organisation’s current compliance posture, information can be fed from the following sources:
  • Using internal / external audit reports
  • Using self-assessments
  • Executing internal compliance assessments
  • Reviewing operational KPIs.
Enterprise interfaces are key to monitoring activities that could generate non-compliance situations (and as such, risks). These interfaces are process modifications across the enterprise that would feed the compliance capability of current activities that are happening which may impact the compliance posture. Activities such as outsourcing a service done by a business unit should be detected and analysed for compliance.




Communication and Training
The organisation needs to be aware of the compliance requirements and the capability itself. In order to achieve a good compliance, the people need to know where to go with questions.


Key things to consider are:

  • Create a compliance focal role: This role will be responsible to answer all questions on compliance requirements and can also interface between business units and the organisations compliance capability. It can be one resource or many resources distributed across the organisation.
  • Awareness and training: The compliance capability must ensure that awareness and training happens at an organisational level. Why? What? When? and How’s should be part of the awareness and training.
The compliance capability on the other hand needs to report to Governance boards (IT / Information Security) or key stakeholders on the current compliance situation. Dashboards and reports are good ways to show how the organisation is doing on its compliance aspects.


Hope it helps!

Sunday, July 1, 2012

Compliance and third party providers



This is my first blog post from Melbourne, Australia. Sorry it took me so long, but moving to a new country is not an easy thing. Anyways, having finished one of my first projects here, I thought that it was a good moment to blog… and what better way to start with third party provider compliance.

Organisations today are switching from Capital Expenditure (CAPEX) to Operational Expenditures (OPEX). Just as a reminder, CAPEX are generally investments such as buying buildings, servers and software. OPEX on the other hand, is the budget for things you rent or purchase in increments like payroll, utilities or maintenance. Hence, OPEX is more controllable, flexible and has more accounting benefits.

This is one of the main reasons why organisations are switching from investing in infrastructure to “renting” or outsourcing it.  Infrastructure (hardware and server management), cloud services, security services and software development are typical examples of outsourcing.
But outsourcing is not simply switching from CAPEX to OPEX, you are actually giving  a third party the possibility to access, create, modify, transfer or delete data and information. This requires an analysis of inherent risks and a proper compliance monitoring from organisations, which in my opinion, is not normally executed.

Let us use the following software development outsourcing example (which in my opinion is quite real):

Organisation XYZ decides to outsource a web development to organisation ABC. The web development requires access to customer’s information. Once the deliverables were finished, organisation XYZ signed off the deliverables for production. Months later, Organisation XYZ’s new web development got hacked and millions of records containing customers’ information were exposed. After analysing what happened, it turns out that organisation ABC didn’t include information security best practices as part of their SDLC (Software Development Life Cycle) and neither tested their deliverables for vulnerabilities. Now organisation XYZ is facing lawsuits for privacy breaches.

Who is responsible for this breach?  Did organisation XYZ applied due diligence and due care? What could organisation XYZ have done to reduce the risk of this from happening?

Note: In my following post I will write about a proper compliance framework, so for this post I assume legal and regulatory compliance requirements are already known.

Step 1: Create a third party provider outsourcing policy

Depending on what we are going to outsource; we need to have a policy specifying which are the organisation’s outsourcing requirements. For example, if we outsource software development, policy might specify:
  • Risks of outsourcing must be analysed and mitigation controls implemented during SDLC.
  • A SDLC framework according to best practices must be applied by provider.
  • A proper change management process with approvals from both organisations must be in place.
  • Threat Risk Assessment (TRA) should be included as part of the change management process.
  • Information protection mechanisms should be in place to protect its CIA (Confidentiality, Integrity and Availability).
  • Vulnerability scans and penetration tests should be performed for a development to achieve a security certification.
  • Development must be accredited before entering into the production stage.
  • Requirements for compliance to this policy must be included in outsourcing contract.
  • Provider must have a proper information security program.
  • Provider must execute annual risk assessments on its infrastructure.
  • Provider must have a proper information security framework in place.

Also we can create a generic policy, which ever approach fits best an organisation.

Step 2: Perform a risk assessment

Going back to our example, the development required access to customers’ information and that itself requires an analysis of what are the possible risks and impacts. Here are some questions that might have been asked:
  • What would happen if the code is contains bugs? Will that allow a hacker to get into our systems? 
  • What would happen in the platform has vulnerabilities and we do not apply patches to them? 
  • What if the connections to the database are insecure?
  • What if the customer information gets stolen? 
  • Is the provider properly screening its employees? 
  • Does the provider outsource to another provider? 
  • What regulations could be breached if something goes wrong?

Step 3: Include compliance requirements in contract

This is a key step, because we will be checking compliance on the contract. The contract should have a special compliance clause that lists all the requirements that the third party provider must comply with. You can use your outsourcing policy (internal) as a source plus any new requirements that resulted as the risk assessment process.

Other key requirements that might be specified (as an example) are:
  • Rights to audit the third party provider 
  • Liability issues (if their deliverables are vulnerable without proper due care taken) 
  • Personnel screening by third party provider 
  • No “outsource” requirement (do not allow the third party provider to outsource to a fourth one). 
  • Reporting and monitoring requirements (KPIs and reports to be created). This is important to perform monitoring.

Step 4: Monitor compliance


Now that we have a contract that includes compliance requirements which are based on the organisation’s policies and risks detected, we can monitor the third party provider for compliance based on that contract.

The compliance monitoring process can be fed from the following sources:
  • Assurance activities (external / internal audits) 
  • KPI measurements that might indicate a non-compliance (i.e. number of changes requested and approved do not match the changes placed in production) 
  • Results from penetration tests and Vulnerability scans 
  • Self-assessment reviews 
  • Regulatory reviews 
  • Consulting reviews 
  • Changes in regulatory requirements that might affect the development


A key thing is having a good compliance framework and a management system to track non-compliance issues resolutions and associated risks. I’ll adress that in my next post.

Hope it helps :)

Friday, March 25, 2011

Social Networks and Organizations: Associated Security risks

Note: This article was originally published in Spanish on December 2nd 2009 at Iprofesional.com

Social networks, like Facebook, Plaxo, Linkedin and MySpace, among others, have become interaction tools with more than a million users worldwide. According to recent statistics, social networks as applications have superseded common e-mail and two thirds of Internet users have at least one profile in one of them (1).
                                            
These new technologies and its impressive growth has attracted the attention of cyber criminals, who according to statistics, are responsible for 19% of attacks against social networks detected between January and July of this year (2).

A study has revealed that two thirds of the surveyed organizations felt that social networks represent a risk to their security (3). For this reason, many companies and institutions requested advice on the possible risks on allowing employees to access these networks through the available IT infrastructure at their workplace (i.e. Internet access, workstations, notebooks, etc.).

From an information security perspective, there are several risks that an organization may face if preventive measures are not taken:
                                                                                                                       
The first one, and most common, is disclosure of confidential information. Let us imagine that an employee is working on a confidential project and accidentally publishes in a social network, like Linkedin, what he is working on (the majority of these networks allow a user to publish what they are doing under the question “What’s on your mind?” or “Share your comments”). What would the impact of this action be? For starters, all users with access to this employee’s profile will know what he is working on, thus information otherwise classified as confidential will be disclosed.

The second risk is associated with the increase of possibilities to be victim of a social engineering attack. In most of these networks, the user is required to store personal information like full name, date of birth, marital status, employment, hobbies, work experiences, etc. Without the correct configuration of privacy options, an attacker could create a social profile of the victim by simply using google, becoming these actions the grounds for an identity theft attack. 
Once attackers have your personal information, what stops them from calling your company helpdesk and ask for a password reset? Or opening a bank account? There have been public cases where persons had been victims of identity theft in social networks, like Facebook, where attackers pretend to be the victim by creating virtual profiles (this is a very common case with celebrities).
Is it possible for an attacker to steal the identity of a company’s CEO, create a virtual profile in a social network, add company employees to this profile and then try to obtain confidential information? The answer is yes, and it has already happen in personal and corporate levels.

Other risks are malware attacks, caused mainly by worms. The quantity of malware that use social networks as a distribution point has significantly grown. Allowing access to these sites from organizations workplaces increases the chances of infection.

What to do with the risks mentioned previously? As preventive measures, it is critical to configure each social network privacy options in a most restrictive way, validate the users that we are adding to our networks, personnel training and awareness programs, monitor social network activities, apply technical controls (i.e. antivirus software) and a sound security and acceptable use policy regarding access to these networks.

Author: Agustin Chernitsky

Sources: 
(1). Nielsen - Global Faces and Networked Places.
(2) Breach - The Web Hacking Incidents Database 2009.
(3) Sophos - Security threat report: Update July 2009.