Please enjoy reading this archived article; it may not include all images.

IT Security Responsibilities Change When Moving to the Cloud

Author: Larry G. Wlosinski, CISA, CISM, CRISC, CDPSE, CISSP, CCSP, CAP, PMP, CBCP, CIPM, CDP, ITIL v3
Date Published: 1 May 2013

How will an organization’s information security staff be affected if the organization’s computer systems are moved to a cloud environment? What about the change in responsibilities within the organization and the expectations of the cloud service provider (CSP)?

While the three common cloud delivery models1 —Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS)—are pretty well known and described in literature, the latest service being defined by the Cloud Security Alliance (CSA) is Security as a Service (SecaaS).2 SecaaS “provides third-party facilitated security assurance, incident management, compliance attestation, and identity and access oversight. SecaaS is the delegation of detection, remediation, and governance of security infrastructure to a trusted third party with the proper tools and expertise.”3 SecaaS covers 10 security domains that include products and/or services, which are available from many vendors, to manage security concerns with an organization’s cloud provider.

For PaaS, the organization and the provider share the responsibility for the application and the virtual management environment; the CSP provides and manages the control of the server, data storage and network services. For IaaS, the organization is responsible for the application and the responsibility of the virtual management environment is shared with the provider. For SecaaS, the vendor or designated contractors provide the products and/or services that support the cloud environment.

The cloud environment participants fall into the following categories:

  • Consumer/end user—Owner of the data (person or enterprise)
  • Cloud service provider—An organization that makes the service available
  • Cloud service requestor—The enterprise’s technical staff (e.g., architect, developer, business manager, IT manager)
  • Cloud SecaaS provider—The vendor (e.g., an independent assessor4) that provides the product and/or IT security service in lieu of the enterprise’s employees
  • Auditor—Independent IT security assessor
  • Service broker—An enterprise (examples of service brokerages include Intel and McAfee) that offers intermediation, monitoring, transformation/portability, governance, provisioning and integration services, and negotiates relationships among various CSPs and consumers
  • Carrier—Telephone (or data communication) line intermediary between provider and consumer

Cloud Participant Responsibility Breakdown

The breakdown of responsibilities can fluctuate considerably based on the size variations of organizations (from small to large). The following is a baseline breakdown of responsibilities that may be implemented, to some degree, in organizations that have utilized one or more of the cloud delivery models.

The end user (or requesting enterprise) is responsible for:

  • Security awareness of everyone involved with implementing, operating and maintaining the system
  • Access agreements, such as contracts, service level agreements (SLAs) or other joint agreements
  • Malicious code protection, such as antivirus software and continuous monitoring of the network and application

The IT security responsibilities of the CSP include:

  • Application partitioning and information remnants in the infrastructure
  • Security function isolation and resource priority of the platform
  • Boundary protection of the application
  • Regular audit and continuous monitoring to analyze, repair, verify, track and capture malicious activity
  • Monitoring for unauthorized configuration changes
  • Utilizing monitoring tools to maintain a secure information systems (IS) environment
  • Backup and recovery to assess that contingency planning occurs and testing is performed
  • Environmental controls for the customer and the provider
  • Physical access for the customer and the provider

IT security controls managed by the end user or CSP (depending on the service model) include:

  • Account management
  • Account enforcement
  • User identification and authentication
  • Device identification and authentication
  • Authenticator management
  • Cryptographic key establishment and management

Shared responsibilities of the end user and CSP include:

  • Access control to the data, system and server environment
  • Data and media protection of all storage devices
  • Maintenance (configuration management)
  • Incident response participation and reporting
  • Personnel security (including background checks)
  • Contingency planning for the user organization and the CSP locations

The architect of the end user is responsible for:

  • Information flow enforcement
  • Acquisition of network services to the SecaaS and CSP
  • IS documentation

From a cloud model perspective, there are two types of application developers, meaning the writer and tester of the program code. For a SaaS application, the developer is the vendor that offers the system/application. For PaaS and IaaS systems/applications, the developer is the user organization. For both types of developers, the following responsibilities apply:

  • Security training of, for example, the programmers, administrators, help desk and users
  • Life-cycle support for updating current applications and installing new ones
  • System configuration (for the developer who turns the system over to production) and the hosting environment
  • Security testing of the applicable controls5
  • Flaw remediation of source code (this is the responsibility of the organization that wrote the application)
  • Baseline configuration. The baseline is the responsibility of the developing organization (for SaaS, it is the vendor; for IaaS and PaaS, it is the end user).
  • Configuration change management. This responsibility is separated from the security staff as part of security control, known as segregation of duties.
  • Access restrictions for change. This control applies to user accounts and system administration; application of this control depends on the cloud delivery model.

The end user’s business manager is responsible for:

  • Risk assessment and updates, which may be performed by in-house staff or by an organization that provides the service, such as the Federal Risk and Authorization Management Program (FedRAMP)
  • Allocation of resources (e.g., staff, funding)

The end users’ IT manager is responsible for:

  • Access control policies and procedures
  • Account management
  • Audit review, analysis and reporting
  • Security awareness and training policy
  • Security assessment and authorization policy and procedures
  • IS connections
  • Configuration management policy and procedures
  • Contingency planning policy, procedures and plans
  • Identification and authentication policy and procedures
  • Incident response policy and procedures
  • Security planning policy and procedures
  • Third-party personnel security
  • System and communications protection policy and procedures
  • System and services acquisition policy and procedures
  • External IS services

The third-party auditor is responsible for:

  • Security assessment
  • Security certification
  • Security accreditation

The service broker is responsible for:

  • Relationship negotiation
  • Managing the use, performance and delivery of services
The carrier (telecommunication or data line provider) is responsible for:
  • Denial-of-service (DoS) protection
  • Transmission integrity
  • Transmission confidentiality
  • Trusted path

SecaaS IT Security Domains

The SecaaS vendor can be responsible for one or more of the 10 IT security domains according to the interconnection agreement. The 10 IT security domains for SecaaS as defined by the CSA are:

  1. Identity and access management—This includes authentication, identity management, single sign-on, provisioning/deprovisioning, centralized directory services, privileged user management, access management, authorization management, access policy management, and audit and reporting.
  2. Data loss prevention (DLP)—This includes data sovereignty; setting and enforcing policy; legal/regulatory requirements; geographic, architectural, storage, end-point and encryption considerations; and forensics.
  3. Web security—This includes the existing infrastructure, proxy configuration, antivirus, antispyware, compliance, social network/blog access, URL filtering, queries, alerts and the audit trail.
  4. Email security—This includes data security and protection, regulatory compliance, data residency, unauthorized disclosure, malware, spam protection, encryption, records retention/data destruction, system management and logging, and mobile devices.
  5. Security assessment—This includes legality and nondisclosure agreements; standards; architecture; inventory; baseline configurations; process flow; logging; continuous monitoring; common requirements; data access; tools; accuracy and coverage; provider infrastructure; secure communication, reporting and sharing of results; and penetration testing.
  6. Intrusion management—This includes intrusion detection and response; intrusion management; service level agreements; governance, regulatory and compliance issues; and financial, technical, security and architectural issues.
  7. Security information event management (SIEM)—This includes log data management, risk management, regulatory and compliance requirements, incidents and events, SLAs, information sharing, and inputs and outputs.
  8. Encryption—This includes data availability, key management, securing the client, policy and enforcement, data integrity, data at rest, data in transit, data in use, and data destruction.
  9. Business continuity and disaster recovery planning—This includes the SLA; jurisdiction of the data; data protection/ encryption; separation of duties; access controls; metadata retention, separation and protection; resilience; licensing; and failover automation.
  10. Network security—This includes the network model, network access controls, content inspection and control, distributed DoS protection, virtual private network (VPN) and Multiprotocol Label Switching (MPLS) connectivity, forensic support, traffic capture, and resources.

Figure 1 presents the security posture (i.e., protective, preventive, detective, reactive) for each SecaaS domain.

Figure 2 is a mapping of the SecaaS domains to the cloud delivery models.

More detailed information on the CSA SecaaS domains can be found on the CSA web site,6 where one can also find sample vendors, by domain, that can provide support in the way of software, hardware and/or staff to satisfy an organization’s needs. To effectively utilize these services, the organization needs to implement contractual relationships, adjust its security architecture and reevaluate staff assignments to determine who is tasked with performing the job functions and security responsibilities described here.

Conclusion

Enterprises working in or planning a transition to computer systems working in the cloud should consider the job function responsibilities of their technical staff and evaluate their skills and weaknesses. In some cases, it may be beneficial to change job descriptions, and in some cases, it may be necessary to provide them the training they need to function effectively. Remember that the enterprise’s administrators and programmers were trained to develop the new environment because of the changes in software, systems and appliances; therefore, the operational staff can also benefit from learning any new skills associated with moving to the cloud environment.

Endnotes

1 Jansen, Wayne; Timothy Grance; Guidelines on Security and Privacy in Public Cloud Computing, NIST Special Publication 800-144, National Institute of Standards and Technology, December 2011, http://csrc.nist.gov/publications/nistpubs/800-144/SP800-144.pdf
2 Cloud Security Alliance (CSA), Security Guidance for Critical Areas of Cloud Computing Version 3.0, 14 November 2011, https://cloudsecurityalliance.org/research/security-guidance/
3 Ibid.
4 An example of an independent assessor is the Federal Risk Authorization Management Program (FedRAMP), a US federal government organization that supports federal agency efforts in certification and accreditation of cloud systems hosted at vendor locations.
5 Sample responsibility designations can be obtained from the FedRAMP (www.gsa.gov/portal/category/102371) and the CSA (https://cloudsecurityalliance.org) web sites.
6 https://cloudsecurityalliance.org/research/secaas/#_downloads

Larry G. Wlosinski, CISA, CISM, CRISC, CAP, CDP, CISSP, ITIL, is a professional IT security consultant at Earth Resources Technology Inc. and has more than 37 years of experience in IT security. Wlosinski’s security experience includes policy and procedure writing, planning, information assurance, continuous monitoring, security and risk assessments, incident response, network and data security, contingency planning, and security awareness and training. He is also a past president of the Niagara Frontier Chapter of the Data Processing Management Association (DPMA). Wlosinski has spoken on cloud security at federal and professional conferences and has conducted many classes on various IT security topics.