Prevent your organization from getting lost in critical cloud data protection A Cloud Access Security Broker (CASB) is now a “must-have” Information Security technology. Gartner, Inc. (NYSE: IT), the world’s leading information technology research and advisory company, has recently published an article stating that a CASB is #1 in the list of top ten Information Security technologies for 2016. This post is for those who are not deeply familiar with CASB and need an organized view into why a CASB is a crucial part of any current Information Risk Management strategy. Contact us to get free access to the document, which explains why every organization needs a CASB.

The CASB market is rounding the corner into the mainstream. Venture backed startups are being acquired and big tech firms are positioning while enterprises are taking a serious look at these solutions. In Information Security Risk Management circles, there are some who understand these solutions, but there are still many people that are not clear on where CASBs fit in an overall Information Security strategy. It’s my goal to provide some background on the topic from a business and technology perspective and start some interesting conversations about these solutions. This is the fourth and final post in a four week, non-product specific educational series on the Critical Role of Cloud Access Security Brokers that has covered the topics outlined below, using short, recorded presentations. This post includes Part 4. Part 1: What is Cloud Access Security? [link here] – An introduction or refresher on key Information Security concerns when related to public Cloud adoption and the intro of the CASB market Part 2: What is a CASB and how does it work? [link here] – A deeper dive into how CASB’s work, the functions they provide, and how they are provided Part 3: How do CASBs complement other security tools? [link here] – An overview of how CASBs relate to and integrate with other critical components of the Information Security Architecture Part 4: CASB Use Cases and Deployment Strategy [THIS POST] – The different approaches of implementation and business integration with these solutions For each of these presentations, including this one, a transcript of what I’m saying is provided in the post If you would like a PDF format of the presentation, which may be freely distributed, please let me know. I hope you find this series to be useful and appreciate any and all feedback. Thank you! TRANSCRIPT: Hi, My name is Kyle Watson the managing partner of information security at Cedrus and a veteran executive security architect. This is part four, the final installment in the series where I have explained the critical role of cloud access security brokers or CASB in your Information Security architecture…   Today I’ll provide an overview of CASB Use Cases and Deployment Strategy. As an important side note, this material builds upon many of the topics in previous installments of the series. If you haven’t been through the previous presentations, I strongly suggest that you go back and review them now. You can find them in my youtube channel or as a link in this post. CASB Key Use Cases CASBs provide visibility into cloud apps in use in order to discourage Shadow IT CASBs provide cloud DLP, protecting enterprises from breaches that may occur in a cloud app or prevent specific data from being stored in high risk apps CASBs prevent unauthorized access to cloud apps and prevent insider threats for data theft CASB can streamline the effort of Legal and Information Security teams when selecting cloud apps providing risk based decision support CASB can prevent malware threats in stored files in cloud storage Key Use Case – Visibility Scenario: Employees are using cloud applications without the involvement of IT Security or Legal (Shadow IT). Real World Example: ABC Company uses Microsoft Sharepoint for collaboration. Over the past year, there has been a wait list for new Sharepoint sites to be created for business areas. The Marketing business unit decided that they couldn’t wait so went to Jive and signed up for a new collaboration site. The CASB Use Case: Using the access logs of web access gateways, the CASB UI displays apps in use. Information Security Risk Management discovers that 11 people from Marketing are all using Jive. Now appropriate business decisions that incorporate risk can be made. This doesn’t mean that the app needs to be blocked. If ABC Co decides to continue to use the app it can be integrated with the CASB for DLP, Access Control, and Threat Protection. CASB Key Use Case – DLP through API Scenario: Employees and Contingent Workers have been using cloud storage for a few years, but the data has never been reviewed, so the type of data stored in the cloud is unknown Real World Example: ABC Company uses Box as the preferred vendor for cloud storage. However, there is real concern around the data that has been stored in the cloud, in case of a Box breach. The Information Security Risk Management team and the business work together to define what’s important (PII, Confidential documents, Legal concerns, etc…) The CASB Use Case: Using the policy construction in the CASB UI, the Box app (including instance and folders) is configured to be “crawled” within the files, if files are discovered that match the requirements, the data can be encrypted or placed on legal hold. CASB Key Use Case – DLP through in-line active configuration Scenario: Employees and Contingent Workers inside and outside of corporate boundaries are using corporate sanctioned cloud apps, but may not comply to corporate policy Real World Example: ABC Company uses RSA Syncplicity for Storage. Although it is a sanctioned app, as an organization subject to HIPAA, ABC Co has made a business decision that Protected Health Information (PHI) cannot be stored to the cloud. The CASB Use Case: Using the policy construction in the CASB UI, a basic policy can block SSNs from being stored, but an advanced policy can also be created to ensure that when specific combinations of data are contained in a single document, such as medical record number, name, and medical information – it can be blocked from upload. This is advanced DLP and sometimes we refer to this as CASB 2.0. For more detail and please reference the whitepaper “using advanced DLP” by Netskope. CASB Key Use Case – Access Control Scenario: Sales Employees need access to CRM in the office and on the road, but only Sales, Marketing, and Customer Service should be accessing this information. Real World Example: ABC Company uses Salesforce.com for CRM. The Sales and Customer Service teams need full access to Salesforce.com and Marketing needs limited access. This is necessary both inside and outside of the corporate network. In addition, ABC Company only has reps and customer presence in USA, Canada, and the UK. The CASB Use Case: Using the policy construction in the CASB UI, the Salesforce.com cloud app is limited to access to the Sales, Customer Service, and Marketing OUs. In addition, the policy is configured so that access to Salesforce.com must be initiated from a device attempting access from a supported region of customer presence. Now attempts outside of the known control set are denied. CASB Key Use Case – Cloud Service Provider Risk Management Scenario: Evaluate vendor risk profile before business area signs up with a new solution Real World Example: ABC Company’s marketing department would like to signup for an email marketing add-on for Salesforce from the Salesforce.com AppExchange, but Information Security Risk Management processes require that they get approval prior to signup. The CASB Use Case: The profile for the add-on is retrieved from the CASB user interface. Data protection, data ownership, and audit-ability are key concerns – this is the company client list. In the CASB UI, we will be able to see answers to key questions about the vendor based upon the CASB company’s research. For example Does the vendor support Encryption at rest?   No, in fact they do not. Does the vendor allow the client to hold the encryption keys?   Well, since they do not support encryption at rest, they do not. If we go with this vendor, do we own our own data? Yes. But if we decide to leave them, will they permanently erase our data?   No, they will not. Can we access Admin or User logs? No we cannot. Perhaps there are other criteria that are equally important or through negotiations some of these items may be changed in your particular agreement… As you can see, the CASB UI can provide decision support quickly. A Second Cloud Service Provider Risk Management Use Case Scenario: Evaluate vendor risk profiles to select the correct cloud app for our business Real World Example: ABC Company is moving storage to the cloud, but wants to decide which cloud storage app is preferred for their business needs. ABC Co must understand the risk implications of each vendor to make a sound decision. The CASB Use Case: ABC Company again has set data protection, data ownership, and audit-ability as high concerns in the evaluation criteria. After applying these settings, the cloud storage apps of choice, such as Box and Microsoft OneDrive rated and prioritized. Other vendors get reordered to a lower level of trust, allowing easier shortlisting for vendor negotiations. CASB Key Use Case – Threat Protection Scenario: Employees and Contingent Workers have been using cloud storage for a few years, but the data has never been reviewed, so integrity of the files is unknown Real World Example: ABC Company uses Box as the preferred vendor for cloud storage. However, there is real concern around the data that has been stored in the cloud, in terms of malware that could be propagated to other partners or clients through document sharing. The CASB Use Case: Using the policy construction in the CASB UI, the Box app (including instance and folders) is configured to be “crawled” so that within the files, if malware is discovered, the files are quarantined. CASB Deployment Strategy First, we crawl. Discovery of Cloud Apps in Use and assess risk, both of the risk profile of any app in use, as well as the ways in which apps are being used. Revitalize Corporate Policy and Prioritize Criteria for “Sanctioned Vendors” In addition to our Information risk teams, We need the business to be involved in this to tell us what’s important. What would cripple us if it was leaked or stolen beyond regulations, Social Security Numbers and Credit cards?. (10-K filing, Confidential acquisition document, proprietary trade information) Prioritize Key Applications for Integration in more sophisticated ways in the follow on steps. …Then, we walk. Integrate Key Applications with API integration (non-intrusive) Implement Policy Violation Action/Alerting to Protect Data through polling (taking input from our revitalized policy decisions) Revitalize Corporate Policy to define what user behavior anomalies are – restrictions like device -type, physical location(s), data downloads? Then, we Run Integrate Applications as Active/In-Line (in waves) Implement Policy to Protect Data in real-time (such as the data blocking scenarios we described in the advanced DLP use case) Implement Access Control Policies to Prevent Unsanctioned Access and “Coach” Users to Sanctioned Apps (taking input from our revitalized policy decisions) Technology Integration On Premises Log Collector for processing and sending logs to the CASB Identity and Access Management (IAM) federated Identity and SSO configuration Mobile Device Management (MDM) / to integrate Endpoint Agents on managed devices Security Information and Event Management (SIEM) to capture CASB policy violations and escalate to the central interface Process Integration Incorporate CASB policy violation and forensics into the Incident Handling process Dovetail CASB controls into Identity and Access Management (IAM) application on-boarding and governance Bring CASB results into Key Performance Indicator (KPI) and Critical Success Factor (CSF) Dash-boarding Business Integration Engage BU Security Liaisons to Understand what Critical Data really is to your organization Define a “Service” and Process to Support Business Units with on-boarding to Sanctioned apps and transitioning from risky apps Then, perform the shift to Sanctioned Cloud Apps And Enable Stronger Security with Information Alerting and Reporting from the CASB Well, that’s it for our CASB integration overview. I sincerely hope that this series has provided value in learning about CASB. Thank you, and if you have questions and would like to reach out to me my contact information is on this slide.

The CASB market is rounding the corner into the mainstream. Venture backed startups are being acquired and big tech firms are positioning while enterprises are taking a serious look at these solutions. In Information Security Risk Management circles, there are some who understand these solutions, but there are still many people that are not clear on where CASBs fit in an overall Information Security strategy. It’s my goal to provide some background on the topic from a business and technology perspective and start some interesting conversations about these solutions. This is the third post in a four week, non-product specific educational series on the Critical Role of Cloud Access Security Brokers that will cover the topics outlined below, using short, recorded presentations. This post includes Part 3. Part 1: What is Cloud Access Security? [link here] – An introduction or refresher on key Information Security concerns when related to public Cloud adoption and the intro of the CASB market Part 2: What is a CASB and how does it work? [link here] – A deeper dive into how CASB’s work, the functions they provide, and how they are provided Part 3: How do CASBs complement other security tools? [THIS POST] – An overview of how CASBs relate to and integrate with other critical components of the Information Security Architecture Part 4: CASB Use Cases and Deployment Strategy – The different approaches of implementation and business integration with these solutions For each of these presentations, including this one, a transcript of what I’m saying is provided in the post If you would like a PDF format of the presentation, which may be freely distributed, please let me know. I hope you find this series to be useful and appreciate any and all feedback. Thank you! TRANSCRIPT: Hi, My name is Kyle Watson the managing partner of information security at Cedrus and a veteran executive security architect. This is part THREE of FOUR where I will explain the critical role of cloud access security brokers or CASB in your Information Security architecture…  Today I’ll provide an overview how CASBs integrate with other technologies. As an important side note, this material builds upon many of the topics in Part 2. If you haven’t been through the Part 2 presentation, I strongly suggest that you go back and review it now. You can find it in my youtube channel or as a link in this post. How do CASBs perform Log Based Discovery. Before an analysis can begin, the logs must be sent to the CASB. Logs may be uploaded manually or an on premise log collector can be configured to retrieve logs and send them to the CASB Most common web proxy and next generation firewall logs are natively supported Log files may be zipped with common compression utilities such as zip and gzip prior to upload How CASBs Integrate with Cloud App APIs. API integration is not proxy driven, rather the CASB interacts directly with the Cloud App Polling model: CASB calls the cloud app using its API, to check for changes and crawl data at rest (this is the most common approach and is supported by most cloud apps). As an example, the BOX storage app provides an admin API that can provide visibility into an enterprise account for all users. The CASB can poll the API to discover if any changes to any account. If so, the BOX events API may then be polled to discover detailed data changes and CASB can then apply policy on the data. Callback model: CASB registers with cloud app via API to be informed of significant events (this must be supported by the cloud app). For example, the Microsoft Office365 Webhooks API How CASBs Integrate with Cloud Apps through Reverse Proxy Configuration happens within the cloud app and your Identity solution. Commonly, SAML flows are used to force redirects… Let’s step through how this happens The user, from a browser client, attempts to connect to the application, say Salesforce.com The cloud app responds to the user’s browser and directs the user to login to an Identity Provider. This is a configuration in the cloud app The user authenticates and a SAML SSO token including another redirect are returned to the user’s browser. The user is directed through the CASB as a proxy to the application The SAML token automatically logs the user into the cloud application and the user is working. Now, the CASB is in line so policy decisions can be made to protect corporate data in real time. This configuration can work for any browser, anywhere, but will not help for native apps. How CASBs integrate to Cloud Apps through Proxy Chaining. An existing proxy, such as a secure web gateway, intercepts outbound traffic Based upon existing web proxy configuration – particular traffic can be forwarded to the CASB as a “chained” proxy The CASB proxies the session to the cloud app and this is all transparent to the end user. again, the CASB is in line so policy decisions can be made to protect corporate data in real time. This configuration can work for enterprise devices that are configured to route through the corporate web gateway, either on premise or through VPN – or, through a CASB installed agent as we’ll see on the next page How CASBs Integrate with Cloud Apps for Non-Managed Devices Endpoint agents can be used to ensure native apps are correctly routed. In addition, endpoint agents cover all apps, not just native ones – although as previously mentioned, web apps can be handled in agentless fashion with a reverse proxy Mobile Device Management (MDM) is used to distribute agent to devices Agent/profile configuration will be setup to push particular app domain ranges to CASB (may have an intermediate proxy if desired) This configuration works well for mobile devices that are not on the corporate network at time of access to enterprise cloud apps. How CASBs and Existing on-Premises Data Classification Solutions Enterprises (should) have data classification levels to identify the most critical data Many enterprises have implemented solutions to “tag” the data, these tags represent classifications such as “confidential” Some CASBs can read the tags and use the classifications to enforce policies So when a user tries to save a document with confidential data The CASB can make a policy decision to, for example, not allow the document to be saved to particular cloud app storage or encrypt it. CASBs and Identity and Access Management. CASB depends very heavily on your existing identity and access management infrastructure. Let’s discuss some of the critical areas that either integrate directly with CASB, or that are necessary prerequisites Access Provisioning: Enterprise – Manage user access for common enterprise apps, including the Identity Provider registry used with CASB configs. So if my enterprise user registry was Active Directory, Enterprise access provisioning tool, such as Sailpoint IIQ, would read the HR data and generate user access in the AD. Access Provisioning: Cloud – manage user access and entitlements for cloud apps, this is particularly important as many business apps are being moved to the cloud, bulk and ongoing provisioning to create the access is required. A common framework is now available for this called [System for Cross Domain Identity Management (SCIM 2)] Identity Provider: The enterprise registry of user identities for authentication and authentication pages where users login SAML and OAuth: Single Sign On (SSO) Token types that allow users that authenticate at the Identity Provider to sign-on to the cloud app without a second login page (typically the this is all part of the identity provider configuration to provide these services but I called it out here because it’s a key point) Attestation / Governance: Providing the correct access to particular users based upon role and validating that access periodically by asset owner and manager. This is not CASB specific, but is important for regulatory mandate compliance such as SOX. CASBs and Security Information and Event Management or (SIEM) SIEMs provide an important risk mitigation function to correlate and elevate risks as events occur across separate networks and systems. CASBs are policy enforcement points and generate violation activity logging CASBs can integrate with SIEM via REST API or via logs Correlate cloud activity with enterprise activity (in real-time with API) providing a more holistic view SIEMs and CASBs can work together to handle insider threats effectively. Well, that’s it for our CASB integration overview. Please look out for part 4, where we’ll look at CASB common use cases and implementation plans. Thank you

The CASB market is rounding the corner into the mainstream. Venture backed startups are being acquired and big tech firms are positioning while enterprises are taking a serious look at these solutions. In Information Security Risk Management circles, there are some who understand these solutions, but there are still many people that are not clear on where CASB’s fit in an overall Information Security strategy. It’s my goal to provide some background on the topic from a business and technology perspective and start some interesting conversations about these solutions. This is the second post in a four week, non-product specific educational series on the Critical Role of Cloud Access Security Brokers that will cover the topics outlined below, using short, recorded presentations. This post includes Part 2. Part 1: What is Cloud Access Security? [link here] – An introduction or refresher on key Information Security concerns when related to public Cloud adoption and the intro of the CASB market Part 2: What is a CASB and how does it work? [THIS POST] – A deeper dive into how CASBs work, the functions they provide, and how they are provided Part 3: How do CASBs complement other security tools? – An overview of how CASBs relate to and integrate with other critical components of the Information Security Architecture Part 4: CASB Use Cases and Deployment Strategy – The different approaches of implementation and business integration with these solutions For each of these presentations, including this one, a transcript of what I’m saying is provided in the post. If you would like a PDF format of the presentation, which may be freely distributed, please let me know. I hope you find this series to be useful and appreciate any and all feedback. Thank you! TRANSCRIPT for Part 2: Hi, My name is Kyle Watson the managing partner of information security at Cedrus and a veteran executive security architect. This is part TWO of FOUR where I will explain the critical role of cloud access security brokers or CASB in your Information Security architecture…  Today I’ll provide an overview of CASBs and how they work. What CASB’s are, and what they aren’t: CASBs bring a single interface to common Cloud Access Security Requirements including Visibility into Cloud App Use, CSP Risk Analysis, Visibility, Access Control, Data Loss Prevention, and Threat Protection for cloud applications. Federated Identity Services – CASBs heavily rely on provisioning and SSO solutions but do not, as a general rule, provide them. Enterprise Mobile Device Management Services – CASBs can assist with securing the data in the interaction with Cloud Apps but cannot prevent mobile device penetration, so these services are also critical at the device level. Many CASBs integrate with leading MDMs. The Critical Role of CASB in your Information Security Strategy. These items shown in red, although critical to cloud access security, are not provided by CASB CSP Vendor Risk Management – CASB provides decision support to help select appropriate vendors based upon your risk tolerance Visibility – CASBs can provide visibility into the cloud apps in use, who is using them, and what data is flowing where Access Control – CASBs can control access to specific cloud apps by specific user, device type, location, behavior, and other factors Data Loss Prevention or DLP – CASBs can identify and protect data stored in cloud apps through encryption or tokenization. Threat Protection – CASBs can also detect malware threats in files stored in cloud app storage Lets take a look at CASB in Action. First, the CASB solution examines logs from corporate edge of network devices to analyze traffic and detect what application may be in use, providing visibility. This is known as discovery mode. Once the CASB knows what applications are in use, it can provide decision support for Cloud Service Provider Risk Management – rating the risk associated with each cloud service provider and app, which can be incorporated in to sanctioning decisions In proxy mode, when users access the Cloud App, the CASB sits between the user and the cloud, at the highest level, the CASB can provide Access Control to determine if the application is sanctioned and the person is authorized to use it. It can also provide adaptive controls to determine if a user is authorized based upon device, user behavior, location, time, and other factors The user’s authentication is integrated with a corporate Identity store and an Identity service provider in order to generate an SSO token, which allows the user to login to the app without entering an additional password. It also prevents users whose access has been terminated on corporate identity stores to access the cloud app after termination. The user is directed to the application for business use If critical or regulated data is going to be stored in the cloud app, the CASB can provide data loss prevention and may be configured by policy to tokenize or encrypt the data flowing to the cloud app. Tokenization involves changing the actual data to a represented value. The CASB solutions can also crawl existing cloud storage apps to apply DLP policies. From the CSP to the user, the CASB may be able to assist in providing threat protection, preventing malware from being propagated from the CSP to the user’s device. Some CASB solutions can also crawl existing cloud storage apps to discover malware threats and quarantine suspect files. If the user is outside of the corporate network and attempts to access the application directly, the Cloud App, Identity services and CASB work together. First the Cloud App will be configured to redirect authentication to the Corporate Identity provider Then, once authenticated, the configuration will direct the user through the CASB for use during the session IF the access is from a native app instead of a browser, there will likely be a requirement to install a component on the device to ensure that traffic is routed properly through the CASB. Now lets look at integration in more detail CASBs can be integrated into your security architecture in several ways, and most organizations will use a combination of approaches. Stage 1 – Passive / Non-Intrusive are typical first projects for integration With Log-based Discovery, we capture logs from edge of network devices to detect cloud apps in use or “Shadow IT” Best for providing a baseline of cloud app usage It’s an agentless configuration Passive review of access using network device logs Only relative to access through corporate networks, so this will not capture off premise access that is not through a corporate VPN Works with any / unknown applications – in other words the type of client (browser or native app) is irrelevant With API Integration, we can take advantage of visibility, DLP, and threat protection for cloud apps we already know we’re using or planning to use, such as Salesfoce.com or cloud storage apps. Best for well-known cloud application integration Agentless Cloud application callbacks to CASB or CASB polling of app for interesting items Config is between cloud app and CASB, so the type of client (native app or browser) is irrelevant Only works with cloud applications the CASB vendor has implemented (The top cloud apps used in business today will be available in the popular CASBs) Stage 2 – Active / In-line configurations position the CASB between the user and the cloud app and are typical follow-on project phases Reverse-Proxy (this is when the user contacts the cloud app first and then the CASB is placed in line during authentication) Best for non-enterprise managed devices Agentless Cloud application configuration, through Single Sign On protocols, redirects user for authentication and CASB Proxy Works with browser only And of course, this only works with known and configured applications Forward Proxy (this is when traffic is routed through the CASB by default for particular cloud apps) Best for enterprise managed devices Off network devices require installed agent Proxy chaining allows CASB to have traffic routed through it after going through the main corporate web proxy/gateway. Alternatively, this can be done using DNS. Agentless, works with browser – agent works with browser and native apps Works with any / unknown applications Active/In-line configurations are better for DLP and Access Control, such as preventing upload of data that violates policy as well as identifying potential breach activities such as multiple accesses from different locations in a particular, or downloading much more data than usual. So how are CASB’s providing Cloud Service Provider risk management? In some ways, CASBs allow businesses to outsource most of the hard work in analyzing CSP risk on their own. CASB vendors maintain running lists of cloud apps (tens of thousands) and risk profiles based upon many different data points CASB vendors have teams of specialists, including legal, researching cloud apps continually to accurately present risk profiles up to date They Review Terms and Conditions to determine things like who has license to the data They Review Service Organization Controls (SOC) reporting for effectiveness of security controls And they also send specific questionnaires to CSPs to gather additional information CASB vendors are maintaining risk profiles independently, and see this as a key competitive advantage – meanwhile, Cloud Security Alliance (CSA) is establishing a “Trust” protocol and registry so that Trust can be measured publicly CASB provides a UI with decision support regarding vendor risk profile to incorporate into vendor selection and policy decision-making CASB UIs allow for ranking areas of concern from high to low in order to target the risk review to your business profile. For example a particular regulatory mandate may be important to you along with control of data and physical datacenter locations Here’s the background on how CASBs provide visibility CASBs consume logs from edge of network devices to determine cloud apps in use (passive, log based discovery) Note: If CASB is not configured as forward proxy, logs have to be periodically re-read to detect new cloud apps CASBs may be configured as active in-line to track access to configured / integrated applications (reverse proxy) or any cloud application (forward proxy) This allows you to see how much data, of what type, has gone where, by whom And policy violations And all of these data points can be incorporated into Policy construction in the CASBs CASBs also provide robust Access Control Specific cloud apps can be blocked, or non-preferred cloud app access attempts can be used to “coach” users to sanctioned apps Specific users or groups can be authorized to use specific cloud apps CASBs can utilize risk related data like user behavior, data, device, and location criteria in access control decisions for step-up authentication Identity is not “deeply” integrated with the CASB, in other words there is no HR Identity Feed or personnel information in the CASB There is typically tight integration with Active Directory (AD) so AD groups can be used in Access Control Data Loss Prevention is perhaps the most critical CASB use case Data elements to be protected can be defined, and a set of pre-defined well-known structures like SSNs and credit card numbers are included CASBs also hook into API calls defined by the Cloud Apps and can take action on data during a particular API call HTTPS traffic can be inspected to ensure that policy applies to data sent using transport encryption Cloud storage can be “crawled” to find critical data and apply policy, such as encryption Policy can be defined in a granular fashion as to how the data should be encrypted or tokenized (transformed) as it relates to the CASB and cloud application service. Policy can include user information such as device, location, user behavior, and more. Policy can include vendor risk tolerance aspect from risk analysis, for example no SSNs can ever go to a particular cloud storage app. Some vendors also provide an on-premise solution for DLP and data encryption in those cases where customers are very concerned about data even leaving their network at all. And last but not least is threat protection CASBs maintain activity logging for exceptions and alerting CASBs provide anomaly detection for compromised accounts, forensics support, and provide malware detection As outlined in the DLP section, CASBs can “crawl” storage apps to detect data types and during this crawl, they detect malware in stored files Well, that’s it for our CASB overview. In part 3 we’ll look at CASB integration with other technologies in the security architecture

The CASB market is rounding the corner into the mainstream. Venture backed startups are being acquired and big tech firms are positioning, while enterprises are taking a serious look at these solutions. In Information Security Risk Management circles, there are some who understand these solutions, but there are still many people that are not clear on where CASB’s fit in an overall Information Security strategy. It’s my goal to provide some background on the topic from a business and technology perspective and start some interesting conversations about these solutions. Starting today, and over a period of four weeks, I am publishing a non-product specific educational series on the Critical Role of Cloud Access Security Brokers that will cover the following topics, using short recorded presentations. This post includes Part 1. Part 1 is not an overview of CASB. Rather, it is an overview of key Information Security concerns when considering public cloud use in enterprises today. The objective of Part 1 is to organize key risks for consideration. Many of these risks are not mitigated through the implementation of CASB, but several key risks can be addressed, which is why CASB will play a critical role in your strategy. Part 1: What is Cloud Access Security? [THIS POST] – An introduction or refresher on key Information Security concerns when related to public Cloud adoption and the intro of the CASB market. Part 2: What is a CASB and ow does it work? – A deeper dive into how CASB’s work, the functions they provide, and how they are provided. Part 3: How do CASBs Complement other Security Tools? – An overview of how CASBs relate to and integrate with other critical components of the Information Security Architecture. Part 4: CASB Use Cases and Deployment Strategy – The different approaches of implementation and business integration with CASB solutions. A transcript of what I’m saying is provided in the post at the bottom.  If you would like a PDF format of the presentation, which may be freely distributed, please let me know. I hope you find this series to be useful and appreciate any and all feedback. Thank you! TRANSCRIPT Hi, My name is Kyle Watson the managing partner of information security at Cedrus and a veteran executive security architect. This is part ONE of FOUR where I will explain the critical role of cloud access security brokers or CASB in your Information Security architecture…   Today I’ll provide an intro to Cloud Access Security. The Cloud is a perfect storm for Information Security because we lose visibility and control when service providers take responsibility for systems.   If you’re new to Cloud: The industry has standardized the term “Cloud” as a generic way to categorize Internet delivered data and application services. Cloud services are organized into three buckets. Infrastructure as a Service (IaaS) – systems and storage (ex: AWS) Platform as a Service (PaaS) – application server stack (ex: IBM BlueMix) Software as a Service (SaaS) – business applications (ex: Salesforce) There are various delivery models, but for this presentation we are focused on publicly delivered Cloud although much of it applies to private or hybrid cloud. So, why are Businesses moving to the cloud?.   Reduce Total Cost of Ownership, while increasing agility. Outsource hardware and infrastructure management including the constant system updating. Stop worrying about hard to find and keep high-tech skills. Leave development, version management, and application patching to the vendor.   And Transfer responsibility for secure coding, hardening, and other security concerns… You Cannot Transfer all of Your Information Security Risk to Cloud Service Providers.  Contractually with the provider in your Cloud Service Agreement or through insurance there are ways to financially mitigate the risk of a breach if it occurs at the provider, but your organization will still be accountable if information is leaked or stolen. For example: Regulated Privacy data such as Personally Identifiable Information (PII) – if your company loses my data, I’m going after you Also, corporate espionage or up to the second trade information – what if your plans for acquisition are leaked or proprietary designs are stolen We also cannot hold the Cloud Service Provider accountable for our internal policies or processes being followed correctly including Acceptable Use Assigning access to the minimum necessary least privilege Or Termination of access for personnel that stop working here Shadow IT and IT Consumerization are changing how we work. Shadow IT is the use of consumer targeted or unsanctioned technology to solve business problems, in order to get around IT challenges or funding constraints. IT Consumerization is the growing hazy overlap of personal and corporate device and application use.   Here are some examples. A Business Unit team wants to organize and manage tasks so they signup for Evernote and setup their corporate email to forward it to the vendor provided address, including all attachments. A marketing design person has a big video file about an upcoming acquisition they need to share with a vendor. They can’t attach it to an email and IT has provided no good “big file” sharing tool, so they upload it to their personal Dropbox and share the data. A market analysis employee needs to create sophisticated analysis macros in Excel to highlight key findings in the data, but they don’t have the skills – so they hire an offshore contractor to do it for them out of pocket. Then they share the market data, and share their screen so that the contractor can assist. In all of these cases it means that the employees have agreed to “shrink wrapped” terms and conditions. It also means that confidential or regulated data is being sent to people and businesses to undetermined locations without corporate oversight.  Where is your data going? You’re Already Using Tons of Clouds Apps. The average enterprise is using over 900 Cloud Apps. What is the difference between a Web App and a Cloud App? Web Apps are delivered via web browser. Cloud apps are delivered as a service and house data – they could be Web based or have other delivery mechanisms, like native mobile apps. The average corporate user touches 20 different Cloud Apps per day Of course there are many known and sanctioned apps like these, but this only represents a small percentage of the actual apps in use in any given enterprise today. Our Lives are Mobile and Cloud Apps are Everywhere.  It’s not enough to focus our strategy on Windows PCs behind corporate firewalls.  We have Macs, Chromebooks, Linux and more…  Plus, most Cloud apps have Android or Apple IOS specific apps, Mobile Web layouts, or both and are accessible from anywhere. When Personnel register directly with CSPs, they are usually agreeing to shrink wrapped terms and conditions, and are very likely using the same password that they prefer on the corporate network. Both of these issues introduce risk in addition to the unknown variable of the enterprise-level quality of the CSP.  And based upon recent research by NetSkope, more than half of all Cloud App activity occurs on mobile devices Let’s Review Cloud Access Security Concerns and Risks – First We’ll look at Visibility, Detection, and Prevention If over 900 apps are in use, and IT is aware of 20 of them – how can you determine what cloud apps are in use? Since we do not have physical control over the Infrastructure, we need assurance that the CSPs are following appropriate physical and logical controls including Identity Management, Access Control, patching, resiliency, and malware protection just to name a few. When CSPs are engaged outside of the official IT, Information Risk Management, and Legal functions what risks do we accept from these vendors? Since Cloud apps are evolving faster than ever, how do we continually monitor and govern access to all of the new apps that become available in the market? Other Concerns Include Access Governance How to we provision access to the right people in our organization? When people change jobs or leave the company, how to we ensure that access is adjusted or removed? What mechanisms to we use to ensure that the access provided complies to policy such as least privilege? And how to we gather attestation from managers and asset owners for our users of Cloud apps that are housing regulated data? What about Access Management and Single Sign On? How are our users authenticating to these Cloud Apps? Do we control that identity store or is it at the CSP? How do we ensure only authorized personnel can access Sanctioned Cloud Apps? And how do we control that appropriate authentication mechanisms are implemented outside of corporate firewalls? Of course there is Data Protection Is confidential or regulated data being stored in CSP datacenters? If so, is it encrypted (and who holds the keys)? And is any of that data replicated to local devices for performance or offline access? Enterprises are not properly securing cloud access Have your policies been reviewed and updated in the last 5 years? Does your policy address, for example, Data Protection or Vulnerability Scanning policies when faced with the realities of Cloud? Have your Standards been analyzed to incorporate Cloud Access requirements and constraints? Is anyone watching over what Cloud Apps are allowed or blocked? Is anyone Managing that? Are your Security, Legal, and IT Groups working together to forge solid Cloud Service Agreements? What are the minimum assurance criteria required for Vendor engagement? Physical controls, logical controls, visibility, or incident handling? Here are some key questions for your company How are Cloud apps currently provisioned and deprovisioned? Do you have Federated Identity Management solution, such as user access provisioning and Single Sign On, in place to accommodate the ever growing Cloud App realm? What are the top corporate information assets that are at highest risk in the Cloud? Do you know if they are presently being stored in Cloud Apps? What regulatory mandates are of concern to your organization in this area? What gaps presently exist in your processes or tooling to take on the rapid move to Cloud? Do you have SIEM? Is it actually doing something of value? What about Enterprise Mobility Management? Cloud Access Security Is Ensuring Policies and Standards Exist and account for the realities of today’s Cloud world Engaging Information Security Risk Management and Corporate Legal in Cloud Service Agreement negotiations to address Information Security concerns Providing Federated Identity Services such as provisioning and Federated Single Sign On from Corporate controlled Identity stores. Risk Rating Cloud Apps and Vendors and Incorporating this Risk into Selection / Sanctioning Detecting and Monitoring the Constantly Growing and Changing Cloud App Use by Personnel, including Third Parties Controlling Access to specific Sanctioned Cloud Apps and Preventing access to Unsanctioned Cloud Apps Providing Data Protection for Regulated Data to support compliance requirements Protecting against Cloud App Vendor Compromises and Cloud Threats What’s Happening in the Security World? Enter Cloud Access Security Brokers (CASB) Enterprises are scrambling to detect what cloud apps are in use and working to plug holes. CASB is the next big thing in security and analysts and large organizations are really starting talk and plan around it. CASBs sit between your organization and Cloud Service Providers to provide Identification and Assessment, Policy and Compliance, Data Security, and Threat Protection. Most CASB vendors are niche and growing rapidly and partnering with other vendors, like Okta and Ping for Federated Identity services. Some examples of these vendors are Netskope, Skyhigh, Ciphercloud, and Bitglass. Standards and Solutions are Evolving Cloud Security organizations are settling on standards and guidance. Look for the Cloud Security Alliance for excellent support on Policies, Standards, and Assurance and the Cloud Standards Customer Council for excellent support on Cloud Service Agreements In Technology, the “big” vendors are slow to provide solutions in this area, except for a few including: IBM – who built Cloud Security Enforcer from the ground up Microsoft – acquired Adallom Bluecoat, who acquired the Elastica CASB solution, is now being acquired by Symantec And Cisco, who is acquiring CloudLock Well, that’s it for our first intro into Cloud Access Security. In part 2 we’ll start getting into how CASB’s work. #cloudcomputing #informationsecurity #informationtechnologyandservices