managing saas risks for cloud customers 2 - track 2.4 - mr... · 2016-09-15 · ⬣...
Post on 06-Jul-2018
215 Views
Preview:
TRANSCRIPT
Managing SaaS risks for cloud customers
© 2016 Ribose. Public.
Information Security Summit 2016September 13, 2016
Ronald TseFounder & CEO, Ribose
© 2016 Ribose. Public.
[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
© 2016 Ribose. Public.
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
© 2016 Ribose. Public.
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
© 2016 Ribose. Public.
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
© 2016 Ribose. Public.
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
© 2016 Ribose. Public.
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
© 2016 Ribose. Public.
Much higher risk than IaaS and PaaS
PROBLEM
Integrated security
Platformsecurity
Application security
Process security
Three necessary components of SaaS security and their positioning
© 2016 Ribose. Public.
OVERVIEW
Purpose specific security
CloudPrivacyFinance
GovernmentMedia
…
SaaS adoption lifecycle
© 2016 Ribose. Public.
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
© 2016 Ribose. Public.
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?
© 2016 Ribose. Public.
ISO 31000 risk management process
Evaluation: process security and data risks
© 2016 Ribose. Public.
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
© 2016 Ribose. Public.
⬣ 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
© 2016 Ribose. Public.
⬣ 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
© 2016 Ribose. Public.
⬣ 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
© 2016 Ribose. Public.
⬣ 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
© 2016 Ribose. Public.
SaaS usage lifecycle
© 2016 Ribose. Public.
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
© 2016 Ribose. Public.
T H A N K Y O U
© 2016 Ribose. Public.
top related