Managing SaaS risks for cloud customers 2 - Track 2.4 - Mr... · 2016-09-15 · ⬣ Security/privacy is the #1 concern in SaaS adoption1 ⬣ SaaS services are often black boxes ⬣

Managing SaaS risks for cloud customers

© 2016 Ribose. Public.

Information Security Summit 2016September 13, 2016

Ronald TseFounder & CEO, Ribose


[1] Gartner, 2016; [2] Cisco, 2014, [3] Quora, 2015

PROBLEM

Vendors numbers worldwide3:IaaS + PaaS (less than 500) vs SaaS (>12,000)

SaaS spending is almost 80% of global cloud service spending (US $204bn1)

SaaS nearly 60% of cloud workloads, and increasing in share2

For every IaaS/PaaS, there are 100s of SaaS


SaaS (+BPaaS +SecaaS)79%

PaaS4%

IaaS17%

[1] CSA 2016; [2] CSA 2016; [3] Computer Economics 2015, 2016

SaaS has virtually penetrated every organization and increasingly important


SaaS Adopter84%

Pure SaaS, 4%

Mostly SaaS, 20%

Under half, 76%

35%

14%

4%

22%

25%

22%

10%

8%

24%

36%

0% 20% 40%

No activity

Considering

Implementing

In place

Increasing

SaaS adoption attitudes

2016 2015

84% have adopted at least one SaaS organization-wide1

25% of SaaS adopters are already heavily reliant on SaaS2

SaaS adoption strengthening by year3

SaaS is increasingly important

PROBLEM

⬣ Security/privacy is the #1 concern in SaaS adoption1

⬣ SaaS services are often black boxes⬣ No transparency = no control

⬣ Often the weakest link⬣ Over 77% have experienced SaaS security

incidents2

⬣ Lack of visibility3

⬣ 28% have no access into user logins⬣ 29% have no audit logs⬣ <49% know [where, when] sensitive data is

accessed

Yet SaaS services are black boxes, and are often the weakest link in security


59.30%

31.90%28.90%

47.40%

22.20%

0%

20%

40%

60%

Unwated sharing Lost/stolen device data syncCompromised credentials Unauthorized device accessMalicious inciders

Organizations that have experienced SaaS security incidents2

[1] CSA 2016; [2] CSA 2016; [3] CSA 2016

PROBLEM

⬣ Different from IaaS providers, SaaS services range from running everything themselves to relying on a mix of IaaS/PaaS/SaaS providers

⬣ Responsibilities and implications to the customer are also different

SaaS architecture is naturally all inclusive and varied


Outsourced

Internal

Infrastructure

Platform

SaaS Service

SaaS Client

PROBLEM

Infrastructure

Platform

SaaS Service

SaaS Client

Infrastructure

Platform

SaaS Service

SaaS Client

Infrastructure

Platform

SaaS service

Micro-services

SaaS Client

Pose different risks but these are all valid SaaS operating models!

A typical SaaS service utilizes many components, but majority of them may be outsourced


Test systems Networks Infrastructure management

📱💻Web

End-user devices

Mobile

Communication, Search,

AuthenticationContainer / Operating System / VM / Physical

Clients Apps

DNS, Email, Chat, Help Desk, Billing

Third-parties

KV / Object / SQL databases

File storage Code / Image storage

Micro / External services

Application components

Monitoring

Backups

Application(s)

Caching / Load balancing / Network access

API

Maybe outsourced

Often outsourced

Often internal

PROBLEM

🤖

SaaS is a “black box”⬣ Compared to PaaS/IaaS

⬣ Much larger attack surface ⬣ More threat agents

⬣ Opaque and length supply chain⬣ Depth, Breadth, Location

⬣ Broad array of services⬣ API, micro services, mobile⬣ DNS, networks, third-party services

⬣ Deep application stack⬣ Machines, VMs, Containers, Libraries⬣ Multiple technologies

SaaS is purpose-specific⬣ SaaS = business logic

⬣ IaaS/PaaS do not deal with business logic⬣ Driving a car

⬣ IaaS/PaaS: car parts manufacturer⬣ SaaS: car manufacturer

⬣ Easy to target⬣ No one knows what a generic database

contains, but everyone knows what type of data is in a SaaS account

⬣ Insecure application even with secure processes = insecure service

SaaS presents wide-ranging and enormous risks unless mitigated


Much higher risk than IaaS and PaaS

PROBLEM

Integrated security

Platformsecurity

Application security

Process security

Three necessary components of SaaS security and their positioning


OVERVIEW

Purpose specific security

CloudPrivacyFinance

GovernmentMedia

…

SaaS adoption lifecycle


Evaluation

Adoption

Usage

Termination

“Is this a potential fit with our risk profile?"

“How do we make this fit our risk profile?”

“How do we make sure it continuously fits our risk profile?

“How do we exit this service within our risk profile?”

Practice Guide for Procuring Cloud Services⬣ Developed by Expert Group on Cloud Computing Services and

Standards (EGCCSS) of HK OGCIO⬣ http://www.infocloud.gov.hk/home/10791?lang=en

Security Checklists for Cloud Service Consumers⬣ Best practices checklist⬣ Developed by WGCSP (Working Group on Cloud Security and

Privacy) of HK OGCIO⬣ http://www.infocloud.gov.hk/themes/ogcio/media/featuredarti

cles/WGCSP-4-6a_Security_Checklists_for_Cloud_Service_Consumers_EN.pdf

Evaluation: there are some good local resources


What is my risk profile?⬣ Risks arise from assets against a context

⬣ Does this service affect my core processes?⬣ What data do I process on, and will be exposed

to this SaaS?⬣ Identify business requirements, laws and regulations

relevant to this service

Assessing risks⬣ Supplier⬣ SaaS service⬣ Usage of service⬣ => Answers to treat risks when adopting SaaS⬣ Risk owner responsible for accepting residual risk

Evaluation: is this a potential fit with our risk profile?


ISO 31000 risk management process

Evaluation: process security and data risks


Service terms

• Service level management• SLA vs our availability requirements• Business continuity promises: RPO, RTO• Incident handling and escalation

• Legal concerns• Legal and regulatory requirements• Jurisdictional authority, legal

requirements of CSP and SaaS service• Indemnity: relocation of jurisdiction, M&A

• Notifications: security, privacy, compliance changes and events

• Termination rights

Data

• Confidentiality requirements driven by data value• Data classification requirements (e.g., HIPAA, PCI)• Data and metadata control: ownership,

processing, licensing• Data location and sovereignty• Availability requirements and data mobility

Privacy

• Our role vs role of the SaaS service?• Controller (PII of customers or staff)• Processor (PII supplied by a controller)

• Privacy policy: do they sell our data?• Breach obligations and responsibilities• PII data inventory, visibility• Consent management

Internal context

• SaaS strategy and policy• Consequences of failure, supplier management

Evaluation: certified assurance helps in risk assessment


⬣ Many certified assurance schemes⬣ Clarifies what is claimed vs reality

TRUST

VerifierTrusted third-party assesses

trustworthiness.

Provider

How to demonstrate trustworthiness to users?

User

Does the provider practice what they claim?

Application security Privacy

Integrated security

Cloud security

MTCS

⬣ Perform detailed risk assessment⬣ Application functionality⬣ Security and monitoring capabilities⬣ Aligning with business/internal requirements

⬣ Develop policies and procedures⬣ Account management procedures⬣ Acceptable use policy against service abuse⬣ Integrate user lifecycle procedures in business⬣ Follow data classification and labelling

procedures⬣ Integrate into existing service level, incident

and vulnerability management processes⬣ Configuration management

⬣ Determine configuration baseline⬣ Setup service according to security policies,

perform risk treatment if required

⬣ Security configuration⬣ Authentication and authorization

⬣ Multi-factor authentication, single sign on⬣ Access restrictions based on geolocation

⬣ Data loss prevention⬣ Password policies and history⬣ Role-based access control

⬣ Data⬣ Availability mitigation processes if necessary,

data exports, backups⬣ Inventory of assets, ownership and

responsibilities⬣ Limitations on external sharing⬣ Cryptographic controls and requirements

Adoption: treating usage risks


⬣ Incident and vulnerability management⬣ Define responsibilities to handle service

incidents and vulnerability reports⬣ Understand threat vectors and attack surface

⬣ Secure access and network components to service

⬣ Develop controls to reduce attack vectors, e.g., malicious files can spread via document sharing

⬣ Develop controls on potential internal failure points, e.g., DNS spoofing, phishing

⬣ User awareness and training⬣ Develop best practices guidelines for secure

usage of this service⬣ Enforce data classification and labelling⬣ User awareness on what are security incidents

for this service and how to report them⬣ Promote a no-repercussion atmosphere for

candid reports

Adoption: treating usage risks


⬣ Periodic service/supplier reviews⬣ Monitor service terms and conditions for

changes archive versions⬣ Validity of security assurances⬣ Ongoing security performance

⬣ Alerts⬣ Monitor suspicious logins and data access⬣ Monitor service usage and abuse⬣ Monitor service attributes for SLA compliance

⬣ Usage visibility⬣ Authentication logs with login, user location⬣ Access logs⬣ Audit logs⬣ Account provisioning and deprovisioning logs

⬣ Continuously evaluate and reduce attack surface⬣ Monitor basic attributes of service for sanity

check⬣ Review controls to reduce attack vectors⬣ Monitor potential internal failure points

⬣ Configuration management⬣ Monitor configuration changes and alert if

necessary⬣ Incident and vulnerability management

⬣ Manage and track vulnerabilities affecting our usage

⬣ Data⬣ Monitoring of valid backups

Usage / Monitoring


⬣ Internal processes⬣ Notify all users on service termination⬣ Guidelines on replacement or data extraction⬣ Extract data for future usage or migration to

new service⬣ Where to store and who is responsible?

⬣ Data retention⬣ Destruction of backups and residual

data/metadata (system logs, audit logs, access logs, search indices, etc)

⬣ Data retention timeframe should satisfy data classification requirements

⬣ Exporting and removal of financial information⬣ Exporting of usage and other reports

⬣ Return of assets⬣ Export of data/metadata (audit logs, access

logs, backups)⬣ Comply with data location requirements⬣ Acceptable data formats⬣ Delivery time, method, accessible for how long

⬣ Decommission service-specific attachments⬣ Service specific monitoring⬣ Security monitoring of service

⬣ Service management⬣ Removal of all integrations with service⬣ Ensure decommissioning of service⬣ Ensure closure of contract

Termination


SaaS usage lifecycle


Eligibility

Provisioning

Monitoring

Deprovisioning

“Should this person be a user of this service?"

“What needs to be done to add this person to the service?”

“Is this person actually using the service, in a normal manner?

“How do we remove this person from the service?”

Eligibility⬣ Evaluate whether person needs access to this⬣ Identify business requirements and role⬣ Information clearance based on data classification⬣ Approval by security review and data owner

(sponsor)

Provisioning⬣ User training on best practices⬣ Awareness on acceptable use, relevant policies and

procedures⬣ Create account according to user access baseline⬣ Least privilege⬣ Billing party: group or sponsor based on usage?⬣ Identify and set resource limits

Monitoring⬣ Set monitoring alerts based on basic usage profile⬣ Alert on suspicious login (e.g., location, time) and

data access (e.g., batch access)⬣ Adherence to password policies ⬣ Data loss prevention

Deprovisioning⬣ Ensure immediate account termination without

residual⬣ Halts resource billing related to account⬣ Audit logs and access logs must be kept⬣ Security review if necessary⬣ Update account termination logs and inventory

Mitigating risks in the SaaS usage lifecycle


T H A N K Y O U


Documents

Managing SaaS risks for cloud customers 2 - Track 2.4 - Mr... · 2016-09-15 · ⬣ Security/privacy is the #1 concern in SaaS adoption1 ⬣ SaaS services are often black boxes ⬣