Enter – The Cloud!  High-end computing is now available as a “metered” service of sorts thanks to cloud computing.  The costs involved are low, the technology and computing power is the best available at any given time, and all an end-user needs to connect is a low-end computing device (even a smart-phone or a tablet) with reasonably good Internet connectivity.  Thanks to cloud computing, today we have Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), Monitoring as a Service (MaaS), Communication as a Service (CaaS), Voice as a Service (VaaS), and essentially Anything as a Service (XaaS).

With the cost-efficiencies that the cloud brings about, organizations the world over should be rubbing their palms in delight.  Several organizations have already embarked on a journey to migrate their technical infrastructure to the cloud and several others will likely follow suit.  The cloud has some clear arguments in its favor – cost, agility, scalability, reliability, location independence, and overall performance.

However, cloud computing, being a relatively nascent technology, also introduces several information security risks that need special attention.  To draw a simple parallel, subscribing to cloud-based services is like getting an electricity connection for your home in a metered manner – you pay for what you use.  However, in this case, you wouldn’t be too concerned about your electricity getting mixed with your neighbor’s electricity before reaching your home.  Replace electricity with corporate information, though, and it should definitely raise eyebrows.

Information Security – A Clouded Issue

On the face of it, the issue might appear mainly technical.  However, we live in highly regulated times and so the legal and regulatory perspectives to cloud computing security make this a cloudy affair.  An organization eyeing cloud computing as their next stop should take a long, hard look at the following key issues –

Technically Speaking

• A primary question that an organization needs to ask is – “Where exactly is my data?”  The cloud is like a house with multiple tenants.  It offers a great deal of computing power but, by itself, it doesn’t offer much in terms of isolation.  Organizations need to ask their cloud service provider precisely how they will offer this isolation.  How, for instance, will they ensure that data classified “Highly Confidential” is treated that way?  What does the cloud service provider do to ensure that classified data is not handled by a server (or cluster) that processes public requests?  Is the data encrypted and, if so, what type of encryption is used for data at rest and in transit?  What about the physical security of all the facilities?
• Data loss and leakage risks, if not properly addressed, are very high in cloud computing environments.  When multiple tenants live in one house, the risk of one tenant’s information falling into another’s hands increases considerably.  The question organizations need to ask their cloud service provider is – “How will data loss and leakage risks be minimized to acceptable levels?” How, for instance, will they address these risks at the design-level itself?  How will they deal with persistent media?  What provisions and safeguards do they have for backup, restore, and storage?
• Logging and monitoring has come a long way and today forms an integral component of an organization’s information security defenses.  When moving to the cloud, organizations need to ask their cloud service provider how logging and monitoring will be performed.  This is a non-trivial task because we’re now talking about the loosely-coupled cloud environment and not a tightly managed technical infrastructure.
• A cloud service provider has physical machines and computing resources located at some physical location on the globe.  This is an important aspect to look into for organizations considering moving to the cloud.  What kind of a business continuity plan (BCP) and disaster recovery plan (DRP) does the cloud service provider have in place?  Your own BCP and/or DRP would have saved the day for you if your data was in-house; except it won’t be that way once you move to the cloud.
• The cloud is, at the end of the day, a technical implementation that, like any other technical implementation, is bound to have information security vulnerabilities.  Organizations need to get lucid clarifications from their cloud service provider as to how their offered cloud will be tested for information security vulnerabilities on an ongoing basis to ensure that the infrastructure on which the organization’s information rests is secure at all times.  Also, depending on the cloud service provider to perform these audits and assessments would not be a good idea because then the cloud service provider would be tasked with auditing what it implemented.  It is important to remember that a cloud-service provider might want you to believe that its infrastructure rests in iron-clad, multi-layered, facilities on the planet Krypton with Superman himself standing guard outside it.  However, these facilities attract hackers like bees to honey.  If you were to think from a hacker’s point of view, the target is attractive and the return on investment is high.

Incident Response

• Information security incidents at organizations need to be identified, contained, investigated, and even reported in accordance with regulations and mandates.  Challenging as it is to perform this process at an organization; it is almost a breeze if you were to compare it with the challenges involved in doing this in a cloud environment.  Organizations need to obtain clarity from their cloud service provider on how they will help and support the entire incident response process that was earlier followed when the infrastructure was in-house.  How exactly will the cloud service provider help identify the root causes of the incident?  This is more complicated than it sounds because during this incident response process, the cloud service provider would actually need to begin by accepting that its cloud infrastructure was not fully secure.
• Digital forensic investigations that ensue following an information security breach or incident pose another significant challenge.  Organizations need to consider how evidence will be preserved and what that evidence will be considering that the cloud does not offer much visibility into it as, say, a normal workstation would.  How will evidence be collected from the machine image since there is no longer the luxury of working with the full disk?  How will evidence be collected from data resting in the Random Access Memory (RAM) or slack space considering that these areas are no longer well-defined and could be spread across hundreds of machines?  How will routing information be collected?
• One significant challenge during incident response that organizations will face is that of gleaning information from auditing and monitoring logs.  Organizations using the cloud will need to take note of the fact that analyzing an ocean of data, available from the heavy and comprehensive logs that clouds can generate, is not an easy task.  To add to the woes, consider a case where cloud-based anti-virus software identified an infected file, but the computing was done by another, remote computer.  Situations like these can be a nightmare for an incident response team.

People and Processes

• People are often considered the weakest link in information security.  An aspect that cannot be overlooked in the cloud perspective is precisely this weakest link – what is sometimes known as the “human firewall”.  Organizations would do good to find out more about the people and the processes that work behind the scenes of their cloud service provider.  What does the cloud service provider do to test the “human firewall”?  What controls are enforced on individuals that have access to the cloud service provider’s customer data?  In a situation where an employee turns rogue, it could mean serious consequences for all organizations hosted with the cloud service provider because an insider is a serious threat to information security considering he/she has detailed knowledge of internal processes and “knows his/her way around”.
• Another important consideration for organizations eyeing the cloud is to investigate what their cloud service provider does to train its employees in information security.  A malicious employee is bad enough, but an unaware employee is not any better.

Legal and Regulatory Angles

• Cloud computing is offered to several customers around the globe.  These customers sometimes include malicious ones – a case in point being the infamous Zeus botnet.  The ease of registration and anonymity offered by cloud computing providers makes matters worse.  Organizations need to consider the potential issues that they would have to deal with if their cloud service provider were to house even one such customer who proves to be a handful.  The cloud service provider would probably remain stuck in a legal net for a while.  Its customers, still unsure on whether their data was breached, would then be faced with the task of migrating to a new provider.
• Organizations with a keen eye for issues like the one just described might look at stringent contractual and service level agreements with cloud service providers.  These agreements, however, need to incorporate issues like regulatory requirements, third-party service provider oversight, right to audit the cloud infrastructure, clear wording on liability, intellectual property, end-of-service considerations and responsibilities, record-keeping requirements, data jurisdiction, and the cloud service provider’s compliance with internationally recognized standards.
• Electronic Discovery (E-Discovery) is quite a normal task when regular workstations hosted in-house in an organization are involved.  When a cloud comes into the picture, organizations will then be faced with identifying where the information is stored, how it is backed up, and how it is secured.  The E Discovery rules assume that the physical examination of storage devices, media, and just about anything stored electronically is possible.  This will change completely with the cloud which will add a whole new dimension to electronically stored information.  Organizations need to consider that if they are, at any point, involved in litigation, E-Discovery will be a demanding task.

The Right Expertise

Cloud computing technology has taken the world by storm.  The advantages are undisputed and surely need to be harnessed.  The cloud is undoubtedly the jet fuel that the world has been looking for to propel organizations into the next generation of efficient and technology-powered business.  However, the information security issues that have followed cloud computing are serious and need to be carefully considered and addressed by organizations that are looking to take advantage of the cloud.

With the right information security expertise backing an organization’s advance into the cloud, there is clearly no stopping the organization’s progress into this new world of opportunities.

Take a walk in the cloud, but watch your step!

Find out what you need to know at a special half-day workshop which will address the impact of the new SSAE 16 service organization reports (formerly SAS70) and related attestation standards on service providers and industry. This event will address both the perspective of Service Organizations who issue SSAE 16 and related reports, as well as those User Entities which rely upon them.

You will receive practical solutions, guidance, as well as tools & techniques to evaluate your organization’s readiness. Your experienced presenters will offer perspectives from across the regulatory, standard setting, reporting, and industry landscape. Following 5 brief presentations, participants will have the opportunity to interact directly with the guest speakers during a one-hour panel discussion.

SSAE 16 has forced both users and providers of outsourced services to adjust and re-align their organizations with the requirements of the new standard. Attend this event to ensure your organization, clients, and auditors are prepared in order to avoid costly and time consuming pitfalls.

 
Agenda:

Breakfast                                                 8:00 AM to 8:30 AM
Presentation & Panel Discussion            8:30 AM to 11:30 AM

Speakers:

Chris Halterman
Chair-AICPA Trust/Data Integrity Task Force, Member-AICPA Service Organization Task Force

Tony DaSilva
Federal Reserve Bank (FRB)

Clay Moegenburg
Enterprise Risk Management, Inc.

Kevin Levy
Attorney, Gunster, Yoakley & Stewart, P.A.

Cost:

$65   Early Registration
$85   at the Door

Directions:

http://www.emrisk.com/contact-us/map

CPEs:

2.5 hours of professional CPEs

To Register:

Visit the Florida International Banker’s Association website for payment options and details – http://www.fiba.net/events 

For more information:

Pat Roth
pat.roth@fiba.net
(305) 579 – 0086

Huntley Maddrey
hmaddrey@emrisk.com
(305) 447 – 6750

The first presentation will be technical in nature with a description of the PCI Data Security Standard and how your business can efficiently and cost-effectively comply with it. The second presentation will focus on the financial aspects of PCI compliance and discuss the increasing importance of a CFO’s role in the PCI compliance process.

Agenda:

Breakfast                                          8:30 AM to 9:00 AM

PCI – Security Presentation             9:00 AM to 10:00 AM

Break                                               10:00 AM to 10:15 AM

PCI – Financial Presentation           10:15 AM to 11:15 AM

Speakers:

Georgios Mortakis, CISSP, CISA, CRISC, PCI QSA, PCI ASV

Director, Enterprise Risk Management

Arnold P. Leap

Executive Vice President and Chief Technology Officer, Direct Insite

Mark Brousseau

President, Brousseau & Associates

CLICK HERE to register for this event.

The security of financial information ranging from payroll records to company financials can essentially make or break an organization’s reputation today. With modern-day information systems now doing the jobs of humans in storing, processing, and sharing financial information, accountability has become more difficult and yet as unforgiving as in the past. This accountability lies in the hands of today’s Chief Financial Officers (CFOs) and there are some serious questions that CFOs should be asking about the security of their financial systems.

Question 1: Where is my organization’s financial information?
Does your organization have current and complete documentation on the organization’s financial information flow? If you need to protect your organization’s financial information, you need to know exactly where it is, how it flows, and where it flows to. Ensure that such documentation is available and is updated on an ongoing basis to ensure that all changes are incorporated and that no information is overlooked.

Question 2: Is our information security budget enough?
The key, really, is to identify if the budget allocated to information security is commensurate with the nature of risks faced by the organization. Key executives of an organization must sit down together to identify how they plan to secure the organization’s critical information, the regulations they need to comply with, and their own standards of what they define as “acceptable” information security. Once this is done, the information security budget only needs to be commensurate to achieve this baseline. A security budget doesn’t have to go beyond what is required. That would be a waste!

Question 3: Are we optimizing our budget usage?
Various regulatory compliance requirements across several regulations often have many similarities. To be fair, all they’re trying to tell you to do is to secure critical and sensitive information. The fact is, you would be trying to that anyway as a part of your ongoing security program. There is, then, no need to view these through separate windows. Combining requirements from different regulations that you need to comply with and addressing them collectively, even inclusively as part of your own security program, will not only save you a significant amount of time and money, but will also enable you with more efficient and effective information security.

Question 4: What regulations do we need to comply with?
Being aware of what regulations an organization needs to comply with may sound simple but, surprisingly, many organizations overlook certain regulations due to misinformation or plain oversight. It is a good idea to be aware of regulatory requirements in a little more detail. For instance, the Payment Card Industry Data Security Standard (PCI DSS) requires compliance from all organizations that handle, process, store, or transmit credit/debit card data. Another example is when educational institutions engage in student loan making or provide other such financial services; they fall under the purview of the Gramm-Leach-Bliley Act (GLBA). One of the often overlooked examples is that of state-specific regulations that mandate organizations to notify and disclose information security breaches. Often, the best approach is to either study information security relevant regulations to see what applies to your organization, or to get an expert to help you do it. Instead of being at the mercy of the regulatory officer’s mood, it would be wise to take stock of the precise regulations that demand compliance.

Question 5: Do we have a plan to respond to a security breach?
In the process of designing and implementing information security in an organization, a critical aspect that can sometimes get lesser attention is that of incident response. While the security program will define how you will achieve information security, it isn’t written in stone that your organization will never be breached. Your organization must have an incident response plan in place which defines exactly what will be done in the face of a security incident, who will do it, and how the organization’s normal functioning will be restored. Once documented, the precise roles and responsibilities need to be communicated to the incident response team identified. Ensure that regulatory compliance procedures are taken into account as well so that reporting requirements are met and evidences are retained using formal chain of custody procedures that allow the evidences to be permissible in a court of law at a later time, if the need arises.

Question 6: Should we outsource?
A long-debated question of whether and how much information security should be handled in-house still has no right answers. The best way is to look at this question based on your own specific organizational size and needs. Overall, the economics of hiring expert help for information security needs undoubtedly offers serious cost advantages, particularly considering that the organization can still maintain control by retaining a small, yet significant, information security function in-house. However, it is important to choose the expert carefully and ensure that the outsourced organization is not only technically gifted but can also view information security in the light of overall business impact and regulatory compliance.

Security must begin at the top of an organization. It is a leadership issue, and the chief executives must set the example.

So what exactly is the insider threat? Simply stated, the insider threat refers to a trusted employee or contractor who intentionally or unintentionally performs an unauthorized action that causes a degradation of service or theft or exposure of intellectual property. The threat is not new but gives many security managers sleepless nights due to the fact that there is no practical and reasonably successful way to eliminate this threat. The best one can do is to mitigate the threat by having sound prevention and/or detection controls in place.

Risk assessment
The first step to mitigate the risk of insider threat is to perform a comprehensive risk assessment.

• Review and identify critical IT assets paying special attention to critical data and intellectual property assets.
• Identify threats to those critical assets including intentional and unintentional actions.
• Determine the probability and impact if those threats were to materialize.
• Identify controls to eliminate or mitigate the threat.

With the critical assets and associated risks identified, the next step is to try and eliminate as many threats to those assets as possible. While many organizations employ defense- in-depth (DID) strategies to address security threats, the overall security program and be enhanced by adding the “Protect, Detect, and React” model to the security strategy. By adding this methodology, organizations can anticipate potential issues, detect them and react in a timely and efficient manner to minimize the damage to their resources and reputation.

Protect
Protect your assets by implementing a strong information security program that includes comprehensive administrative, physical, and technical security controls.

Administrative Controls:
Often underestimated, the administrative controls offer the lowest implementation effort but potentially the best protection. This is because these controls work from the ground-up and help instate a responsible attitude and environment of information security.

• Policies – e.g. acceptable use, authentication and authorization, data classification policy, physical and technical access controls that enforce the “least privilege” and “need to know” concepts, critical data at rest and in-transit encryption, clean desk, after hours work monitoring, etc.
• Change and configuration management programs.
• Periodic user security awareness training programs bolstered by social engineering assessments to achieve highly targeted security awareness efforts.

Physical Security Controls:

• Identification of restricted access areas (server rooms, file storage areas, etc.)
• Implementation of guards, locks, security logs and a review of the physical location of these areas.

Technical controls:

• Firewalls
• Intrusion Prevention Systems
• Proxy services
• Cameras
• Data loss prevention tools
• Anti-malware tools

Detect
With a robust information security program in place, the next step is to detect suspicious behavior in the organizational network.

Technical Controls:

• Network and Host-based Intrusion Detection Systems.
• Deep-packet inspection and analysis tools.
• Log analysis tools.
• Security Information Event Manager (SIEM) – With the over-abundance of log files, alerts, and system information data, organizations often end up with too much information for a network monitoring technician to process and react in a timely and effective manner. To aid in analyzing and effectively correlating data, organizations have started to integrate SIEM tools to provide a real-time dashboard of the network security posture.

React
After an incident has occurred, a timely, structured and meaningful response is the key to minimizing the impact to the affected organization. A well-documented and thoroughly rehearsed incident response program is critical. Roles and responsibilities have to be assigned, documented, and communicated. Incident response drills should be conducted on an ongoing basis, with surprise elements employed, to ensure that incident response personnel fully understand their roles and responsibilities. End-user training is a critical but often overlooked component of the incident response program. Users need to be able to quickly identify abnormal activities and understand what actions need to be taken to minimize the damage to the organization.

Summary
In today’s social media driven world, protecting your organization’s critical information from intentional or unintentional exposure is proving increasingly difficult. By incorporating the “protect detect, and react” strategy into the defense-in-depth strategy, security managers can go a long way in protecting their organization’s information assets from the menacing insider threat.

Please join us on Wednesday, August 31 2011 for a breakfast seminar on understanding how this change will impact your business. Recognized IT security expert, Silka Gonzalez, President of Enterprise Risk Management Inc., cordially invites you to attend this timely, informative, networking event.

Spaces are limited – Reserve your spot today!

Cost: FREE
CPEs: 2

The conference will be held on September 15 and 16, 2011.

For official details, and an overview of the agenda, please visit the official FELABAN website at http://www.felaban.com/eventos.php

The first standard is SAS “Audit Considerations relating to an Entity Using a Service Organization” that was developed for user entity external auditors. The Accounting Standards Board (ASB) has finalized this new auditing standard but it does not go into effect until December 15, 2012. Early implementation of this standard is not permitted. The second standard is Statement on Standards for Attestation Engagements (SSAE) 16 “Reporting on Controls at a Service Organization”, AT section 801 that was developed for the service auditor. SSAE 16 went into effect on June 15, 2011. SAS 70 was changed because external auditors rely on auditing standards to report on the audit of financial statements, whereas SSAE 16 provides guidance to the service auditor for reporting on the service organization’s description of the system (including controls and control objectives) as they relate to financial reporting.

The major changes between SAS 70 and SSAE 16 included the following:

• A written assertion by service organization management regarding the design and operating effectiveness of the description of the system (including controls and control objectives);
• The exclusion of evidence from prior periods on the satisfactory operation of controls to provide a basis for the reduction of testing in the current period;
• The identification of work performed by the service organization’s internal auditors and the service auditor’s procedures with respect to that work; and
• In a type 2 engagement, the service auditor’s opinion on the design and operating effectiveness of the description of the system (including controls and control objectives) for a period rather than as of a specified date. The period referenced is the same period in which the description is reviewed (AICPA, 2011).

SSAE 16 Guidance Expanded Again
In the past, a SAS 70 review was often inappropriately used to report on controls related to compliance, systems, and processes that were clearly unrelated to user entity’s internal controls relevant to financial reporting. Because of this confusion and lack of clarity in scope, the nature of a SSAE 16 review has been re-defined and the AICPA has issued further guidance on providing assurance on user
entity’s controls that are unrelated to financial reporting.

Reporting on user entity’s controls relevant to financial reporting will continue to be performed under SSAE 16 guidance. However, reporting on user entity controls that are unrelated to financial reporting must now be performed under SSAE “Attest Engagements”, AT section 101. This standard allows a service auditor to report on subject matter other than financial statements.
Attestation standards were developed to provide guidance on a growing number of services that CPAs have
been requested to report on. The subject matter to be reported on in these services may include such things as:

• Historical or prospective performance or condition (for example, historical or prospective financial information, performance measurements, and backlog data);
• Physical characteristics (for example, narrative descriptions, square footage of facilities);
• Historical events (for example, the price of a market basket of goods on a certain date);
• Analyses (for example, break-even analyses);
• Systems and processes (for example, internal control);
• Compliance with laws, regulations, and contracts; and
• The effectiveness of controls over privacy (AICPA, 2009).

Three New Reporting Options: SOC 1, SOC 2, and SOC 3 Service Organization Control (SOC) 1 Report
An engagement conducted under SSAE 16 will now result in a Service Organization Control (SOC) 1 report. A SOC 1 engagement focuses on the reporting of user entity’s controls relevant to financial reporting. A type I and II report remain the same where a type I report assesses the fairness of the description and the suitability of the design of controls to achieve control objectives. A type II report continues to include as assessment of the design of controls, but also includes an opinion on controls operating effectiveness, as well as tests of controls and associated results. Both types of assessments require an
assertion by management, as defined in SSAE 16, and require that both types of reports be restricted to
service organization clients, existing user entities, and user auditors.

One of the most significant changes between SOC 1 and SOC 2 engagements pertains to the differentiation in
scope and boundaries of the system of internal controls. In a SOC 1 engagement, the controls that achieve control objectives for financial statement assertions remain the same and include the following:

• Classes of transactions in the user entity’s operations that are significant to the user entity’s financial statements;
• Automated and manual procedures in which accounts/transactions are initiated, authorized, recorded, processed, and reported in the financial statements;
• The capture of other events and conditions that are significant to the financial statements; and
• The financial reporting process used to prepare the financial statements including significant accounting estimates and disclosures (AICPA, 2011).

However, the scope of general computer controls to be defined in the description and assessed by the service auditor must be re-evaluated to ensure that information security, change management, and computer operations control objectives are only related to internal controls relevant to financial reporting and not comingled with overall objectives related to security, availability, processing integrity, confidentiality, or privacy of the system; as this is scope of a SOC 2 engagement. Changes in scope can be readily determined by re-focusing only on the general control objectives and associated controls related to the financial reporting application and the control environment that supports it.

SOC 2 Report
An engagement that provides assurance on controls at a service organization other than those relevant to user entity’s internal controls over financial reporting is now performed under AT section 101 and is specifically called a SOC 2 engagement. A SOC 2 engagement assesses controls over one or more principles relevant to security, availability, processing integrity, confidentiality, or privacy. Assurance is provided on all of the system components of the principle being assessed using the criteria in the AICPA’s Trust Services Principles Criteria and Illustrations. Like a SOC 1 report, there are two types of SOC 2 reports; i.e. Type I and Type II. A type I report includes the following:

• Management’s description of the service organization’s system;
• A written assertion by management that the description of the system of controls
• Has been designed and implemented as of a specified date;
• Was suitably designed to meet the applicable trust services criteria as of a specified date
• A service auditor’s report that expresses an opinion (AICPA, 2011).

A type II report is similar to a Type I report except that it also needs to include an opinion on the operating effectiveness of controls, as well as the tests performed and associated results. In addition, when the description of controls addresses the privacy principle, management must include a statement that they complied with the commitments in their statement of privacy practices throughout the period. Specific tests and results related to this compliance must also be included. In both type I and II engagements management’s written assertion should be attached to the description of the service organization’s system. When the report addresses the privacy principle, the statement of privacy practices should also be attached to the description. Both type I and II SOC 2 reports should be restricted to management of the service organization and other specified parties.

As noted previously in this paper, one of the most significant changes between a SOC 1 and SOC 2
engagement pertains to the differentiation in scope and boundaries of the system of internal controls. A SOC 2 engagement assesses controls over one or more principles relevant to security, availability, processing integrity, confidentiality, or privacy of all the system components related to each principle. Whereas, a SOC 1 engagement accesses controls related to financial transaction initiation, authorization, recording, processing, and reporting; and the general computer controls that support the financial reporting system. These boundaries need to be understood.

For purposes of illustration, the AICPA provides the following illustration for a SOC 2 engagement:
“In a SOC 2 engagement that addresses the privacy principle, the system boundaries cover, at a minimum,
all the system components, as they relate to the personal information lifecycle, which consists of the collection, use, retention, disclosure, and disposal or anonymization of personal information, within well-defined processes and informal ad hoc procedures, such as emailing personal information to an actuary for retirement benefit calculations. The system boundaries would also include instances in which the personal information is combined with other information (for example, in a database or system), a process that would not otherwise cause the other information to be included in the scope of the engagement. That notwithstanding, the scope of a privacy engagement may be restricted to a business unit or geographical location, as long as the personal information is not commingled with information from, or shared with, other business units or geographical locations” (AICPA, 2011).

From a SOC 2 perspective, the description of the system may include one or more information system resources that support the principles of security, availability, processing integrity, confidentiality or privacy and can include:

• The infrastructure – the physical and hardware components of a system (facilities, equipment and networks);
• Software – the programs and operating software of a system (systems, applications and utilities);
• People – the personnel involved in the operation and use of system (developers, operators, users and managers);
• Procedures – the automated and manual procedures involved in the operation of a system; and
• Data – the information used and supported by a system (transaction streams, files, databases, and tables) (AICPA, 2011).

Finally, guidance for performing a SOC 2 engagement also clarifies the meaning of the term “security”, and the difference between privacy and security. The term security can be interpreted more narrowly in a SOC 1
engagement versus a SOC 2 engagement. In a SOC 1 engagement, security refers more to the protection of
information from unauthorized access or disclosure. However, in a SOC 2 engagement that addresses the
privacy or confidentiality principle, security relates more to the authorization, protection, and integrity of transactions throughout the system. As it relates to the difference between privacy and security, privacy is perceived to encompass a broader set of activities beyond security that contribute to the effectiveness of a privacy program (AICPA, 2011).

SOC 3 Report
A SOC 3 engagement is similar to a SOC 2 engagement; however, a SOC 3 report contain a limited description of the system, a written assertion from management, and an opinion. A SOC 3 report is designed to meet the needs of users who do not require the detail provided in a SOC 2 report. It is the AICPA’s position that SOC 3 reports address a market need since both current and prospective customers may use them. As in a SOC 2 engagement, the criteria used for evaluating the design and operating effectiveness of controls in a SOC 3 engagement are the Trust Services Principles Criteria and Illustrations. A service organization that receives a SOC 3 engagement may also display the SysTrust for Service Organization seal on their website.
SOC 3 reports are considered general use reports and can be distributed to the public including customers,
regulators, business partners, suppliers, and management. An assertion by service organization management is required; however a report may still be issued without one. In this case, the form of the report will vary and should be restricted.

Confusion All Over Again!
Due to increasing internal control breakdowns, fraud and theft of confidential and private information, regulation related to internal controls continues to increase. With the benefits of outsourcing comes the transference of risk. User entity management needs to ensure and feel comfortable that their service organization’s system has been updated for the new requirements. Management needs to ensure whether:

• Risk is sufficiently addressed. Does the service organization’s control environment include a risk assessment process, information and communication systems and control and monitoring activities? The
  control environment is critical since it can have a pervasive impact as a whole as it relates to whether
  controls were suitably designed and operating effectively;
• They need to develop and/or implement new complementary controls due to changes in the service
  organization’s description of their system;
• There is a change to the mix or percentage of operations handled by subservice organizations working with your service provider and whether the service organization’s description adequately addresses
  this through the inclusive or carve out method. Often, relationships with subservice providers are not fully understood and can be minimized unintentionally in the service organization’s report.

Management must also develop more detailed assertions for SOC 1, 2 and 3 type engagements. This assertion must fully address the design and operating effectives of the description of the system (including controls and control objectives) for the new criteria. Numerous issues related to the service organization’s description of the system have also arisen with the implementation of the new standards. Service organization management needs to ensure that:

• The scope of the description of the system is appropriate and complies with applicable regulatory requirements. General computer controls will differ between SOC 1 and SOC 2 engagements;
• Control objectives and associated controls address new requirements and criteria defined in the standards. The scope of a SOC 2 engagement addresses controls that are unrelated to financial reporting and include those that support security, availability, processing integrity, confidentiality or privacy principles;
• The AICPA’s Trust Services Principles Criteria have been properly integrated into the description of the
  system. This criteria is necessary for a service auditor to perform a SOC 2 or SOC 3 engagement; and
• Risk assessment and management activities are updated and/or expanded as necessary.

The AICPA has recently issued an Alert and two study guides on the changing dynamics of providing assurance
services related to controls at service organizations. This guidance will help both user and service organization management become aware of the increased requirements and differences between the definition and scope of SOC 1, SOC 2, and SOC 3 engagements.

• A written assertion by service organization management regarding the design and operating effectives of the description of the system (including controls and control objectives);
• The exclusion of evidence from periods on the satisfactory operation of controls to provide a basis for the reduction of testing in the current period;
• The identification of work performed by the service organization’s internal auditors and the service auditor’s procedures with respect to that work; and
• In a type 2 engagement, the service auditor’s opinion on the design and operating effectiveness of the description of the system (including controls and control objectives) for a period rather than as of a specified date. The period referenced is the same period in which the description is reviewed.

SSAE 16 Guidance Expanded Again
Due to increasing internal control breakdowns, fraud and theft of confidential and private information, regulation related to internal controls continues to increase. With the benefits of outsourcing comes the transference of risk. Organizations that choose to outsource operations to a service organization inherit the service organization’s risks. To mitigate these risks, user organization management must ensure that good governance practices exist at service organizations. User organizations must effectively manage relationships with vendors that provide outsourced services by increasing their due diligence efforts as they relate to current and prospective vendor relationships. They need to become more aware of service organization risk management practices as well as their control environment.

A user organization and a service organization can be subject to similar regulatory requirements depending on the industry in which they operate. For example, both organizations may need to be compliant with some of the following regulatory requirements: Basal II, GLBA, FACTA, PCI, ISO 2700 and HIPPA. In the past, a SAS 70 review was often inappropriately used to report on controls related to these regulatory requirements that are clearly unrelated to internal control over financial reporting. Because of this confusion and lack of clarity in scope, the nature of a SSAE 16 review has been re-defined. The AICPA has issued further guidance on providing assurance on controls that are unrelated to financial reporting.

Enter SOC 1, SOC 2 and SOC 3
An engagement conducted under SSAE 16 will now result in a Service Organization Control (SOC) 1 report. A SOC 1 engagement focuses on internal controls over financial reporting and is primarily used by user entity external auditors. The scope of the description of the system from an information system perspective includes the following:

• Classes of transactions in the user entity’s operations that are significant to the user entity’s financial statements;
• Automated and manual procedures in which accounts/transactions are initiated, authorized, recorded, processed and reported in the financial statements;
• The capture of other events and conditions that are significant to the financial statements; and
  The financial reporting process used to prepare the financial statements including significant accounting estimates and disclosures and;
• Application and general controls related to application systems that affect financial statements.

Note that the description of the system does not include any other aspects of information technology used to support security, availability, processing integrity, confidentiality and/or privacy and that compliance with other regulatory requirements/contracts is considered out of scope and must be addressed in a SOC 2 or SOC 3 engagement. Two types of reports remain, i.e. Type 1 and Type 2, and the use of a SOC 1 report is restricted to existing user entities and not potential customers. An assertion by service organization management is still required.

An engagement that provides assurance on controls at a service organization other than those relevant to user entities’ internal controls over financial reporting is now performed as an Attestation engagement and is specifically called a SOC 2 engagement. Controls assessed are typically those relevant to security, availability, processing integrity, confidentiality or privacy. Like a SOC 1 report, there are two types of SOC 2 reports; i.e. Type 1 and Type 2, and the use of a SOC 2 report is usually intended for specified parties that are knowledgeable about the service organization. An assertion by service organization management is required.

The scope of the description of the system from an information system perspective includes resources that support or provide security, availability, processing integrity, confidentiality or privacy and can include:

• The infrastructure – the physical and hardware components of a system (facilities, equipment and networks);
• Software – the programs and operating software of a system (systems, applications and utilities);
• People – the personnel involved in the operation and use of system (developers, operators, users and managers);
• Procedures – the automated and manual procedures involved in the operation of a system; and
• Data – the information used and supported by a system (transaction streams, files, databases, and tables).

The criteria used to perform a SOC 2 engagement is contained in the AICPA’s Trust Services Principles Criteria and Illustrations (AICPA Technical Practice Aid).

A SOC 3 engagement is similar to a SOC 2 engagement; however a SOC 3 report does not contain the service auditor’s description of the system, nor any tests and results. SOC 3 reports are also considered general use reports and can be distributed to the general public including customers, regulators, business partners, suppliers and management. An assertion by service organization management is required.

Confusion All Over Again!
The AICPA has recently issued an Alert and two study guides on the changing dynamics of providing assurance services related to controls at service organizations. Both user and service organization management need to become aware of the increased requirements and differences between the definition and scope of SOC 1, 2, and 3 engagements.

For assistance with the new standards as well as the development or review of SOC 1, 2, 3 reviews, please contact Enterprise Risk Management at 305 447-6750.

The main goal of the strategy is to make the Internet an open, interoperable, secure, and reliable information and communications infrastructure that supports international trade and commerce, strengthens international security, and fosters free expression and innovation(1).

The strategy also includes international computer security standards aimed at preventing theft of private information and ensuring Internet freedom, privacy, and free flow of information. The standards would also include penalties for non-compliance.

The Challenges
The International Cybersecurity strategy recognizes that countries will have to cooperate to maintain a secure space for all to enjoy and prosper. A major concern in cyberspace is the lack of a common ground and rule of law that stretches beyond sovereign borders. In addition, more high level negotiations will be needed to establish a framework for responding to the following cross-border and international challenges and threats:

• Natural disasters
• Sabotage
• Extortion, fraud, identity theft, child exploitation and personal safety
• Intellectual property theft
• Terrorism and organized crime

Cyberattacks: Acts of War?
The Pentagon is planning to issue a new strategy that would define a computer attack from a foreign country as an act of war resulting in possible military retaliation. In particular, attacks that could result in the disruption of essential public services (e.g. bringing down hospitals and emergency-responder networks) could be considered acts of aggression. The policy, however, does not clearly define what type of cyberattack could warrant a military response, or if an attack by a party that is not part of a government could be classified as an act of terrorism resulting in military action.

In the case of criminals and other non-state rogue actors who would threaten national and economic security, domestic deterrence requires all states have processes that permit them to investigate, apprehend, and prosecute those who intrude or disrupt networks at home or abroad. Internationally, law enforcement organizations must work together, whenever possible, to freeze perishable data vital to ongoing investigations, to work with legislatures and justice ministries to harmonize their approaches, and to promote due process and the rule of law.

The Main Components of the Strategy

International Cooperation
One of the strongest points of the strategy is the proposed establishment of international cooperation in the prevention, detection and mitigation of cyberattacks. The new strategy is an attempt to build consensus on the creation of an Internet policy, but not a prescription telling sovereign countries how to develop cyberspace policies.

Regional organizations, private sector, non-governmental organizations, society, academia, as well as government agencies and international organizations will play a fundamental role in developing and applying norms of behavior and developing international, consensus-based cybersecurity standards and deploying products, processes, and services based upon such standards are the basis of an interoperable, secure and resilient global infrastructure. Countries will also need to focus on preventing and detecting online crimes and prosecuting offenders. Further, countries need to help build capacity among law enforcement organizations worldwide to combat crimes in cyberspace.

Domestic Component
The strategy also assigns a primary role to the Department of Homeland Security (DHS) over the security of federal computer systems. The strategy calls for a collaborative effort between DHS and energy companies, water suppliers, and financial institutions to assess and mitigate the most dangerous cyber threats. The law would also require each business to have an independent commercial auditor assess its plans and, in the case of financial firms, report those plans to the Security and Exchange Commission(5).

The strategy, moreover, aims to foster partnership between the public and private sectors with a goal of reducing vulnerabilities while strengthening networks and systems. The sharing of information and awareness of network vulnerabilities and risks among public and private sector networks will be promoted through a national computer security incident response team to share information among government, key industries, our critical infrastructure sectors, and other stakeholders.

Conclusions
The future of cyberspace depends on our collective ability to keep it secure and reliable. The new strategy is a roadmap to better define and coordinate the creation of an international cyberspace policy that will require the partnership, awareness, and accountability of national and international private and public sectors, and end-users.

References

1. http://www.whitehouse.gov/sites/default/files/rss_viewer/international_strategy_for_cyberspace.pdf
2. http://www.defense.gov/news/newsarticle.aspx?id=63966
3. http://www.nytimes.com/2011/06/01/us/politics/01cyber.html?_r=3
4. http://www.nytimes.com/2011/06/01/us/politics/01cyber.html?_r=2
5. http://www.nytimes.com/2011/05/17/us/politics/17cyber.html
6. http://www.stratcom.mil/news/2011/233/White_House_Launches_US_International_Cyber_Strategy/
7. http://www.networkworld.com/news/2011/051611-white-house-releases-new-cyberspace.html