Watch this webinar to learn what codeless security looks like for the cloud apps you build. Codeless - that means baking in security capabilities to defend your custom apps against data breaches without having to write a single line of code.
Codeless Security for the Apps You Buy & Build on AWS
1. Codeless Security for the
Apps You Buy & Build on
AWS
Russell Miller
Director, Product Marketing
Ari Leeds
Senior Product Manager
1
2. Continuing Professional Education (CPE) Credits
Claim your CPE credit for attending this webinar
https://www.isc2.org/
For more information or questions please contact us
info@cloudlock.com
2
3. Agenda
02
SaaS & IaaS Markets: Why are we here?
Security Requirements for IaaS
01
3
03 The CloudLock Approach to IaaS
& AWS Security
4. “
2016 Market Growth:
● SaaS: 20.3%
● IaaS: 38.4%
“IaaS continues to be the strongest-growing segment as
enterprises move away from data center build-outs and move their
infrastructure needs to the public cloud.”
4
SaaS vs. IaaS Market Growth
http://www.gartner.com/newsroom/id/3188817
- Sid Nag, Gartner Research Director
"Forecast: Public Cloud Services, Worldwide, 2013-2019, 4Q15 Update"
6. Apps on IaaS MORE critical than SaaS Apps
6
1. Internal & Partner-facing IaaS apps
2. Customer-facing IaaS apps
7. Platform
as a Service (PaaS)
People
Data
Applications
Runtime
Middleware
Operating System
Virtual Network
Hypervisor
Servers
Storage
Physical Network
Cloud Shared Responsibility - SaaS/PaaS/IaaS
7Gartner, Mind the SaaS Security Gaps, Craig Lawson and Sid Deshpande, May 19, 2016
Infrastructure
as a Service (IaaS)
Hypervisor
Servers
Storage
Physical Network
SaaS
People
Data
Applications
Runtime
Middleware
Operating System
Virtual Network
Hypervisor
Servers
Storage
Physical Network
CSP
Responsibility
Customer
Responsibility
People
Data
Applications
People
Data
Applications
People
Data
Applications
Runtime
Middleware
Operating System
Virtual Network
8. Amazon’s View: “The Shared Responsibility Model”
8Source: https://aws.amazon.com/compliance/shared-responsibility-model/
9. Let’s Talk About Bees (No Birds Needed)
9Source: http://www.ForestWander.com
20. CloudLock Platform
Protect the usage of
business apps in
the cloud
CASB for
SaaS
Protect the usage of
critical infrastructure
in the cloud
CASB for
IaaS/PaaS
Include the cloud in
security workflows
Cloud Security
Orchestration
20
Challenge: As the AWS security admin, I need insight into AWS logs, so that I can perform spot checks, produce weekly status reports to my boss and perform forensic analysis as needed. With all the activity in AWS, I need to make sure that I can reduce noise and filter out an activity stream that tells a story that I can follow.
CloudLock Capability:
In the CloudLock platform, navigate to the “Activities” page. Begin by prepare a series of filters for inclusion:
Platform = “AWS”
Event Type = “Login”, “Update”, “Create”, “Delete”
These normalized event type filters will provide the best insight into your user and data transactions. For deeper insight on known specific AWS raw events, you may use the Raw events filter for finer control.
Challenge: As the security admin, I need to know when our AWS environment has been accessed from IP addresses that are known bad actors or are on our list of black-listed countries, so that I can manage a potential compromise or breach and mitigate further risk.
CloudLock Capability:
Create a Correlated User Behavior policy specific to the AWS platform. Add “Countries” context criteria and create a Black list. Also, add context for Blacklisted IPs, utilizing the CloudLock CyberLab Suspicious IP Feed.
Create a response action to notify the administrator.
The incident will be available for review with all related activities included for performing a forensic analysis. The admin can now take appropriate action such as suspending the account or modifying configuration within the AWS console to close the entry point.
Challenge: As the general admin for our AWS console, I need to know when potentially sensitive activities occur that may indicate new access points to our instances, changes in user accounts and updates to Identity Access Management (IAM) roles and policies, so that I can make sure that all changes have been approved and follow company protocol.
CloudLock Capability:
Create a Correlated User Behavior policy specific to the AWS platform and set the severity to Warning. Add “Events” context criteria and select “Events By Threat Category”. Include the “Sensitive” category and optionally add in “Privilege escalation” to cover permissions changes in the AWS console as well.
Optionally, create a response action to notify the administrator immediately or in a daily digest.
The incident will be available for review with all related activities included for performing a forensic analysis. The admin can now take appropriate action such as suspending the account or modifying configuration within the AWS console to close the entry point.
Challenge: We have and allow certain types of sensitive data in our AWS environment in specific S3 buckets. However, for compliance and auditing purposes, I need to know exactly where that data resides, so that I can provide an export in the case of an audit.
CloudLock Capability:
Create a custom or predefined content policy for discovering this data and set the severity level to “Alert” with a policy name that clearly indicates its purpose.
Optionally, create a response action to auto-resolve the incident so that it is not mixed up with other unresolved incidents that may actually require immediate attention.
When it’s time to provide the results for a compliance audit, simply navigate to the CloudLock incidents page and filter by any/all of the policy names used for this purpose and perform an export.
Challenge: To be in compliance with our PCI data policy, we do not allow any payment card information to be added to our S3 buckets. The threat comes from the applications that are hosted on our AWS instance which allow end-users to upload files. When a file containing PCI information is uploaded, we need to be alerted immediately so that we can take corrective action.
CloudLock Capability:
Create a PCI policy for discovering this data and set the severity level to “Severe”.
Create a response action to notify the administrator.
The incident will be available for review with a link to the violating content in AWS, so that the administrator can take actions such as removing the file or redacting the sensitive information in place and resolve the incident.
So that’s a little bit of the first question on Why do something? Let’s talk a little bit about what CloudLock actually does form a product solution standpoint. CloudLock is 100% cloud native and what that means is that CloudLock is running in the cloud we run on top of AWS ourselves and to consume CloudLock there are no agents to be installed no proxies to be installed anywhere it is literally a process that takes a few minutes to connect to our customers environments. Everything we do, we do through API’s both internally and as a way to connect to our customers cloud applications. There are three areas of our platform, these areas are: CASB for SaaS where you use CloudLock to protect data and users and we are unique in the industry in our ability to extend these CASB controls into the apps running on Iaas and Paas. Last but not least we have a cloud sec orchestration play which really means that we integrate with all other moving pieces in the environment.
So let’s break this down a little bit - CASB for SaaS really means taking a level of our core security capabilities - At the bottom of the page you see our security micro services which are the internal security engines that make up our platform and are being applied towards those environments. So when you think about a customer that has SFDC, Box and O365 and really applying CloudLock to those environments means that I as a customer can see if Eric is logging into SFDC at 9:00 AM from SanFran and then at 9:15 logging into Box and downloading data from Boston. That activity is obviously suspicious and we have the UEBA security micro service that can detect that anomalous behavior and flag a potentially compromised account.. Similarly I might be deploying apps from AWS and I need to enforce HIPAA compliance because I am operating in or selling in the Healthcare market and CloudLock has a DLP sec microservice that has the ability to scan and detect sensitive content stored in this case, in aws S3 buckets and flag objects stored in those S3 buckets as containing, in this case HIPAA related information and also the applications that are making use of those pockets and hence that data. And last but not least from an orchestration perspective CloudLock today through our API’s has the ability to integrate into NGF, SWG, SIEM solutions, malware protection solution, IDaaS solutions to provide support for advanced workloads in the environment.
For example we can set a policy that grabs files being uploaded into Box and we can send those files to an external sandbox solution for malware scanning looking for zero day threats. We have the ability to connect to Idaas solutions like Okta or OneLogin or others and if we see Eric performing suspicious activities either in the way Eric is downloading or accessing data or the way that Eric is logging into the environment that could suggest that Eric is either being a malicious insider or perhaps Eric’s account has been compromised we could trigger a two factor authentication or terminate Eric’s session through the fact that we can orchestrate or integrate or speak to a SSO or IDaas platform. These are some of the advanced uses cases we can bring to the table through these orchestrations.
Actual Questions:
Seed Questions:
Does CloudLock see actual data living in the custom apps we have built on AWS? How is that data secured?
Tell more more about how you index our data? Do you store any of it?
Why should I use CloudLock for AWS? A: Microservices, unlike other CASBs