Module-5

1. Audit andCompliance
1.1. Audit and compliance refers to the internal and external processes that an
organization implements to:
• Identify the requirements with which it must abide—whether those
requirements are driven by business objectives, laws and regulations, customer
contracts, internal corporate policies and standards, or other factors
• Put into practice policies, procedures, processes, and systems to satisfy such
requirements
• Monitor or check whether such policies, procedures, and processes are
consistently followed
Audit and compliance functions have always played an important role in
traditional outsourcing relationships. However, these functions take on increased
importance in the cloud given the dynamic nature of software-as-a-service (SaaS),
infrastructure-as-a-service (IaaS), and platform-as-a-service (PaaS) environments.
Cloud service providers (CSPs) are challenged to establish, monitor, and
demonstrate ongoing compliance with a set of controls that meets their customers’
business and regulatory requirements. Maintaining separate compliance efforts
for different regulations or standards is not sustainable. A practical approach to
audit and compliance in the cloud includes a coordinated combination of internal
policy compliance, regulatory compliance, and external auditing.

 Internal PolicyCompliance
CSPs, like other enterprises, need to establish processes, policies, and procedures
for managing their IT systems that are appropriate for the nature of the service
offering, can be operationalized in the culture of the organization, and satisfy
relevant external requirements.
In designing their service offerings and supporting processes, CSPs need to:
• Address the requirements of their current and planned customer base
• Establish a strong control foundation that will substantially meet customer
requirements, thereby minimizing the need for infrastructure customization
that could reduce efficiencies and diminish the value proposition of the
CSP’s services
 • Set a standard that is high enough to address those requirements
• Define standardized processes to drive efficiencies
Figure 8-1 shows a life cycle approach for determining, implementing,
operating, and monitoring controls over a CSP.

FIGURE 8-1. CSP life cycle approach

Here is an explanation of each stage of the life cycle:

Define strategy
As a CSP undertakes to build out or take a fresh look at its service offerings,
the CSP should clearly define its business strategy and related risk
management philosophy. What market segments or industries does the CSP
intend to serve?
This strategic decision will drive the decision of how high the CSP needs to
“set the bar” for its controls. This is an important decision, as setting it too
low will make it difficult to meet the needs of new customers and setting it
too high will make it difficult for customers to implement and difficult for the
CSP to maintain in a cost-effective manner. A clear strategy will enable the
CSP to meet the baseline requirements of its customers in the short term and
provide the flexibility to incorporate necessary changes while resisting
unnecessary or potentially unprofitable customization.
Define requirements
Having defined its strategy and target client base, the CSP must define the
requirements for providing services to that client base. What specific
regulatory or industry requirements are applicable? Are there different levels
of requirements for different sets of clients?
The CSP will need to determine the minimum set of requirements to serve its
client base and the incremental industry-specific requirements. For example,
the CSP will need to determine whether it supports all of those requirements as
part of a base product offering or whether it offers incremental product
offerings with additional capabilities at a premium, now or in a future release.
Define architecture
Driven by its strategy and requirements, the CSP must now determine how
to architect and structure its services to address customer requirements and
support planned growth. As part of the design, for example, the CSP will
need to determine which controls are implemented as part of the service by
default and which controls (e.g., configuration settings, selected platforms,
or workflows) are defined and managed by the customer.
Define policies
The CSP needs to translate its requirements into policies. In defining such
policies, the CSP should draw upon applicable industry standards as
discussed in the sections that follow. The CSP will also need to take a
critical look at its staffing model and ensure alignment with policy
requirements.
Define processes and procedures
The CSP then needs to translate its policy requirements into defined, repeatable
processes and procedures—again using applicable industry standards and
leading practices guidance. Controls should be automated to the greatest extent
possible for scalability and to facilitate monitoring.
Ongoing operations
Having defined its processes and procedures, the CSP needs to implement
and execute its defined processes, again ensuring that its staffing model
supports the business requirements.
Ongoing monitoring
The CSP should monitor the effectiveness of its key control activities on an
ongoing basis with instances of non-compliance reported and acted upon.
 Compliance with the relevant internal and external requirements should be
realized as a result of a robust monitoring program.
Continuous improvement
As issues and improvement opportunities are identified, the CSP should ensure
that there is a feedback loop to guarantee that processes and controls are
continuously improved as the organization matures and customer requirements
evolve.

2. Governance, Risk, and Compliance (GRC)

CSPs are typically challenged to meet the requirements of a diverse client base. To
build a sustainable model, it is essential that the CSP establish a strong foundation
of controls that can be applied to all of its clients. In that regard, the CSP can use
the concept of GRC that has been adopted by a number of leading traditional
outsourced service providers and CSPs.* GRC recognizes that compliance is not a
point-in-time activity, but rather is an ongoing process that requires a formal
compliance program. Figure 8-2 depicts such a programmatic approach to
compliance.

FIGURE 8-2. A programmatic approach to compliance

Key components of this approach include:

Risk assessment
This approach begins with an assessment of the risks that face the CSP and
identification of the specific compliance regimes/requirements that are
applicable to the CSP’s services. The CSP should address risks associated
with key areas such as appropriate user authentication mechanisms for
accessing the cloud encryption associated key management controls, logical
 separation of customers’ data, and CSP administrative access.
Key controls
Key controls are then identified and documented to address the identified
risks and compliance requirements. These key controls are captured in a
unified control set that is designed to meet the requirements of the CSP’s
customers and other external requirements. The CSP drives compliance
activities based on its key controls rather than disparate sets of externally
generated compliance requirements.
Monitoring
Monitoring and testing processes are defined and executed on an ongoing
basis for key controls. Gaps requiring remediation are identified with
remediation progress tracked.
The results of ongoing monitoring activities may also be used to support any
required external audits.
Reporting
Metrics and key performance indicators (KPIs) are defined and reported on an
ongoing basis. Reports of control effectiveness and trending are made available
to CSP management and external customers, as appropriate.
Continuous improvement
Management improves its controls over time—acting swiftly to address any
significant gaps identified during the course of monitoring and taking
advantage of opportunities to improve processes and controls.
Risk assessment—new IT projects and systems
The CSP performs a risk assessment as new IT projects, systems, and services
are developed to identify new risks and requirements, to assess the impact on
the CSP’s current controls, and to determine whether additional or modified
controls and monitoring processes are needed.
The CSP also performs an assessment when considering entry into a new
industry or market or taking on a major new client with unique control
requirements.

 Benefits of GRC for CSPs

GRC approach helps a CSP to:
• Reduce risks through a structured risk management approach
 • Improve monitoring of IT compliance
• Improve security
• Rationalize compliance requirements and control assessment processes
• Reduce the burden of compliance monitoring and testing

 GRC Program Implementation

To implement a GRC program several major scope elements must be developed,
approved, and put in place. The major components of work have been broken
down into the following work streams: governance, risk management,
compliance, and continuous improvement.
Governance build-out
• The operating scope/charter, procedures, and governance mechanisms for
the GRC team will be developed.
• An organizational change management and transition plan will be
developed to assist the organization in communicating how the GRC team
will integrate with the CSP as a whole.
Risk management build-out
• A risk assessment framework will be developed leveraging existing
methodologies. This framework will be tailored to the CSP’s processes
and will be accompanied by a risk assessment process definition.
• The CSP’s compliance requirements will be rationalized to support the
development of the unified control matrix.
• The unified control matrix will be developed and mapped against
current control processes with gaps identified.
• KPIs will be defined to monitor progress and provide a basis for ongoing
measurement and project management office dashboard reporting.
Compliance build-out
The testing/monitoring processes and procedures, tools, templates, and
methodologies will be developed to support effective compliance utilizing a
standardized and efficient approach.
Continuous improvement
Controls improvement recommendations will be developed, risk-rated, and
prioritized.
Set strategy
The set-strategy phase will encompass the GRC team presenting the program as
a whole to the GRC oversight group and acquiring consensus and approval
for the program strategy and approach.
Transition
The transition phase will comprise a short period of communicating the new
GRC roles and introducing resources and activities to the broader
organization.
Operate
The operate phase is when the ongoing services are made operational and the
program executes its charter, strategy, and approach as defined and approved in
previous phases.

3. Regulatory/External Compliance
CSPs face an increasingly complex array of external compliance requirements from
their customers, whether those include industry standards, regulatory regimes, or
customer-specific frameworks. Frequently, those requirements are based on or refer
to industry standards. As a result, using industry standards can be an effective
compliance approach for CSPs if they can navigate through the ever-increasing
number of standards that exist or are under development number of standards that
exist or are under development.

FIGURE 8-4. So many standards

From an information technology and security controls perspective, it can be

helpful to look at these standards in terms of their focus and objective. The
matrix in Table 8-1 was developed to summarize how a number of leading
 industry standards/regulatory requirements fit together. Understanding these
standards in their proper context helps an organization to determine their
applicability and how they might be used.
TABLE 8-1. High-level standards road map

Control Informatio IT Systems Financ ial Specific

technologi
environme n security service develop reporti ng es or
n t/ delivery/ me nt system increment
company operations s al
requireme
level nts
controls

Best COBIT

practices COSO ISO27002 ITIL CMM/ ITGI- ISO

Guidance ISO SOX
ISO various
20000-2 21827
ANSI

Various
NIST
various
Certificati ISO 27001 ISO 20000-1
on/ audit
criteria/
requireme
nts
Regulator FFIE SO X PCA EV SSL
y/ OB
industry C
requireme
nts HIPA

HITR

UST
 NIST

PCI
ISO
2700X
Audit SAS 70 PCAOB WebTrus
framewo SysTrust
rk WebTrust t CA
BITS FISAP
WebTrus

t EV

GAPP As
Table
8-1 shows, many IT standards have a specific area of focus, such as:
Overall control environment/company-level controls
• Information security
• IT service delivery/operations
• Systems development
• Financial reporting systems
• Specific technologies
In addition, the nature of individual standards can generally be characterized as:
• Best Practices Guidance
• Certification/Audit Criteria/Requirements
• Regulatory/Industry Requirements
• Audit Framework
When developing a controls framework or assessing how to address the
requirements of a particular standard/set of requirements, it is desirable to base the
framework on the standard that is most relevant. For CSPs, where security is a
paramount concern, ISO 27001 is used as a baseline. The CSP may refer to ISO
27002 for additional best practices guidance. It may then be necessary to add to
the control framework incremental requirements from relevant regulatory or
industry requirements or topics covered in the illustrative control objectives. As
the CSP enters new markets or industries and inherits new requirements, it is
essential that the CSP critically analyze such requirements to determine whether
they truly give rise to needed additional controls or whether they are already
covered by the CSP’s control set.Relevant audit frameworks should be considered
when designing the CSP’s control set and periodic external audits should cover the
most relevant aspects of the CSP’s controls.

4. Cloud SecurityAlliance
The Cloud Security Alliance (CSA) is a grassroots effort to create and apply best
practices to help secure and provide assurance within cloud computing. The
group is striving to provide security practitioners with a comprehensive
roadmap for being proactive in developing positive and secure relationships
with cloud providers. Much of this guidance is also quite relevant to the cloud
provider to improve the quality and security of their service offerings.
 FIGURE 8-5. Overall COBIT framework
The primary objective of CSA are:
• Promote a common level of understanding between the consumers and
providers of cloud computing regarding the necessary security requirements
and attestation of assurance.
• Promote independent research into best practices for cloud computing security.
• Launch awareness campaigns and educational programs on the appropriate
 uses of cloud computing and cloud security solutions.
• Create consensus lists of issues and guidance for cloud security assurance.

5. Auditing the Cloud for Compliance

When it comes to auditing cloud computing against the compliance requirements
discussed earlier, there are two perspectives that must be dealt with. First is what
your organization’s internal audit department’s expectations are for meeting
requirements, as well as, of course, the expectations that your external auditors
have with regard to meeting requirements. The “Right to Audit” (RTA) clause is
often used in outsourcing contacts to ensure that clients can conduct audits for
various assurance reasons. In the case of a CSP, the RTA can be applied.
Customers need to define the scope of the RTA. For example, customers should
validate service level performances, the security of data-at-rest, and the physical
security of the data center. However, due to multitenancy and shared logical
environment, it becomes difficult to conduct an audit without the CSP breaching
the confidentiality of other tenants sharing the infrastructure. In such cases, the
CSP should adopt a compliance program based on standards such as ISO27001
and provide assurance via SysTrust or ISO certification to its customers.

• Internal Audit Perspective

As we discussed earlier, a programmatic approach to compliance is particularly
important in a cloud computing environment as the impact of a control failure
could be quite severe. The CSP cannot afford to wait until the annual external
audit to determine whether controls have operated effectively during the past
year, because of the increased potential for control failures impacting multiple
customers. Key controls must be identified early on and proactively monitored
so that any potential issues can be investigated and addressed in a timely
manner. For example, a failure to detect errors in the automated system
configuration and activity logging processes on a near-real-time basis could lead
to system downtime, breached security, or data loss. Although controls should
be designed to prevent the occurrence of such issues, near-real-time detection
and rapid correction of any such issues will go a long way toward
demonstrating the CSP’s commitment to security and continuous improvement.

• External Audit Perspective

 An external audit of the CSP will likely be required for customers to gain comfort
in the effectiveness of the CSP’s controls. Historically, a variety of audit
frameworks have been used to assess the controls of outsourced service
providers, including CSPs. Some of the most common audit frameworks are
summarized here and described in the section that follows.
Although some CSPs have been completing such external audits for five or more
years, an increasing number of CSPs are now initiating external audits for the
first time in response to increasing market pressure

• Audit framework
SAS 70
Audit of controls based on control objectives and control activities (defined by
the service provider).
Auditor opinion on the design, operational status, and operating effectiveness of
controls.
Intended to cover services that are relevant for purposes of customers’ financial
statement audits.
SysTrust
Audit of controls based on defined principles and criteria for security,
availability, confidentiality, and processing integrity.
Intended to apply to the reliability of any system.
WebTrust
Audit of controls based on defined principles and criteria for security,
availability, confidentiality, processing integrity, and privacy.
Intended to apply to online/e-commerce systems.
ISO 27001
Audit of an organization’s Information Security Management System
(ISMS), as defined in a documented ISMS.
6. Security-As-a-Cloud Service

 Origins
Three points of impetus help to explain how security-as-a-[cloud] service began.
The earliest impetus is a decade old now: spam, or unsolicited email. As early as
1999, companies (such as Postini*) were offering email services as follows:
 Postini was founded with the idea that email should be better. While email
is the most popular Internet resource, service providers and software
developers aren’t making email better, and worst of all, aggressive
marketers are targeting any email user as a potential customer. Postini
services are designed to extend the capability of your service providers’
email offering. Junk mail services are only the first step. Over the coming
months, you will see more Postini services that make email even better.†
A number of other companies now provide email filtering services, both
standalone security companies, as well as many Internet service providers
(ISPs) which are often reselling the services of standalone security companies
with their own brand.
A second impetus for SaaS is managed security services (MSSs). Managed security
service providers (MSSPs) have been providing outsourced services to customers
for several years, whereby the MSSPs manage an organization’s network security
devices, such as firewalls and intrusion detection systems (IDSs). The impetus for
using MSS was, and is, the same as cloud computing: lower costs compared to in-
house solutions through shared resources. The difference between MSSPs and
CSPs, however, is that the shared resources for MSSPs are personnel, and not
infrastructure. Additionally, because many organizations are not staffed to handle
round-the-clock support for such services and do not have the expertise to fully
staff such positions, the shared services (i.e., personnel) model of MSSPs can be
financially attractive. The MSSP model became an impetus for CSPs
because it broke the strong but informal barrier to outsourcing parts of an
organization’s information security program. And in this case, that outsourcing
also meant off-premises management of information security devices. (Although
outsourcing information security is often an option, initially it tended to be
outsourcing on-premises—that is, within the customer’s own facilities—as
opposed to off- premises. Of course, now outsourcing can be on-premises, off-
premises, onshore, offshore, and other variations in delivery.)
A third point of impetus for SaaS is the declining organizational efficiency of trying
to provide security on the endpoints directly. Not only is there is a huge proliferation
of endpoints, but they have so many configuration variables that organizational IT
departments simply cannot manage them effectively. Additionally, because many of
these endpoints are mobile, trying to troubleshoot configuration problems and keep
security software up-to-date is a huge task. Add to those problems the fact that many
mobile devices lack sufficient resources (e.g., processing power, memory, and
storage capacity) to adequately handle today’s endpoint protection suites and the
endpoint protection situation is not looking positive.

Today’s Offerings
Today’s offerings in the SaaS segment involve several services to improve
information security: email filtering (including backup, archival, and e-
discovery§); web content filtering; vulnerability management; and identity-as-a-
service.spelled in this chapter as IDaaS).

Email Filtering
SaaS for email primarily involves cleansing spam, phishing emails, and
malware included in email from an organization’s incoming email stream, and
then delivering that clean email securely to the organization so that it is
effectively not repolluted. The touted benefits of this approach are not only
more comprehensive security for clients due to the use of multiple engines, but
also better performance of those client devices (because the anti-malware runs in
the cloud and not on the endpoint directly), as well as far better anti-malware
management. The anti-malware management is superior to endpoint solutions
because that anti-malware is OS- and processor-agnostic, so it can be managed
centrally through the cloud rather than working with multiple management
systems, probably from multiple anti-malware vendors. This cleansing-in-the-
cloud service has corollary benefits: reduced bandwidth used by email, reduced
loads on organizational email servers, and improved effectiveness of a
(recipient) organization’s own anti-malware efforts.

Web Content Filtering

As endpoints belonging to an organization—whether they are within an
organization’s facilities, at home, or on the road—try to retrieve web traffic, that
traffic is diverted to a SaaS provider that scans for malware threats and ensures
that only clean traffic is delivered to end users. Organizations can also enforce
their web content policies by allowing, blocking, or throttling traffic (use of
 bandwidth for that traffic reduced). Because of the number of websites accessible
today, earlier URL filtering solutions deployed on organizations’ premises are
increasingly inefficient. SaaS providers supplement that URL filtering with the
examination of Hypertext Transfer Protocol (HTTP) header information, page
content, and embedded links to better understand site content. Additionally, these
services use a collective reputation scoring system to bolster the accuracy of this
filtering.
SaaS for web content also involves scanning outbound web traffic for sensitive
information (e.g., ID numbers, credit card information, intellectual property) that
users could send externally without appropriate authorization (data leakage
protection). Web traffic is also scanned for content analysis, file type, and pattern
matching to prevent data exfiltration.

Vulnerability Management
As the Internet-facing presence of organizations has grown in size and
complexity, as well as in importance to their operations, ensuring the secure
configuration and operation of the systems involved has become more difficult
and more important. There are SaaS providers that discover, prioritize, and assess
systems for vulnerabilities, and then report and remediate those vulnerabilities and
verify the systems’ secure operation. Such information is also used to monitor
for and report on compliance with some regulatory requirements (e.g., the
Payment Card Industry’s Data Security Standard).
FIGURE 10-1. SaaS web content filtering

Identity Management-As-a-Service
Identity management-as-a-service (IDaaS) only recently emerged as an example
of SaaS, in comparison to email filtering, web content filtering, and vulnerability
management, which are more established as SaaS offerings. IDaaS attempts to
provide some IAM services in the cloud. Today’s relatively early IDaaS
offering tends to focus on authentication, because this is the most critical problem
for customers; see Figure 10-2. However, the most significant problem for CSPs
concerns IDaaS providers, and developing some form of collaborative meta
system. (Just as meta directories did not scale within organizations, virtual
directories will not scale to a cloud level.) IDaaS providers will also need to
provide other IAM services for cloud customers, including authorization (groups
and roles at a minimum), provisioning, and auditing.
FIGURE 10-2. IDaaS model