好色先生TV

A Cloud Access Security Broker (CASB, pronounced KAZ-bee) is an on-premises or cloud-based policy enforcement point placed between cloud service consumers and cloud service providers (CSPs) to monitor cloud-related activity and to apply security, compliance, and governance rules related to the use of cloud based resources. A CASB lets an organization extend to the cloud the same sorts of controls it would apply to on-premises infrastructure, and can combine different types of policy enforcements, such as:

• User credential authentication so access is provided only to approved cloud services.
• Data protection through encryption, tokenization, or other means so sensitive information is not exposed in cloud services or to CSPs.
• Cloud service activity monitoring so user and entity behavior can be logged, flagged, and analyzed for anomalous usage patterns or compromised credentials.
• Data loss prevention (DLP) so sensitive information cannot leave the organization’s network, and malware detection and remediation so sensitive information cannot enter the organization’s network.

The purpose of a CASB is thus to improve an organization’s ability to take advantage of cloud services safely and securely. A CASB can be thought of as a “security node” through which access to an organization’s cloud services is controlled. As a component of an organization’s security infrastructure, it complements, rather than replaces, technologies such as enterprise and web application firewalls, IDaaS (IDentity as a Service), and secure web gateways (SWGs).

The increasing importance of CASBs parallels the wider adoption of cloud services and BYOD (“Bring Your Own Device”) policies that permit personal laptops, smartphones, tablets, and other unmanaged devices onto the network. The use of CASBs to control some or all of an organization’s cloud services is expanding and it is expected that adoption by larger enterprises will triple, from 20% in 2018 to 60% by 2022 (Gartner, 2018). Over a similar period, the cloud security market as a whole is predicted to rise to around $112B by 2023 (Forrester, 2017).

CASBs originally focused on discovering unknown services used by individuals or business units outside those permitted by the IT department – but as organizations realized that the solution to this problem pointed more toward controlled enablement rather than removal of these services, CASBs began to offer feature sets across four pillars: Data Security, Compliance, Threat Protection, and the core capability of Visibility.

Visibility

Many organizations are already accelerating formal adoption of cloud computing across a wide range of business units. This may be leading to an increasing number of employees managing their own security credentials on IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service), and now FaaS (Functions as a Service) resources. In this environment, CASBs can help bridge the security gaps created by this erosion of centralized identity and access management (IAM) and improve control over use of these services, presenting an appropriate barrier and yet not impeding the natural conduct of business by employees both on-premises and in the field.

This consolidation of cloud access controls helps where it is known which cloud services are being used but it does not help with shadow IT. Such services might be being used to work around perceived or actual deficiencies in an organization’s official IT stack, or they may just be a simple reflection of user preference. Rather than activity that must be stamped out, their use may actually be critical for productivity, efficiency, employee satisfaction, and even as a source of innovation, but it is unlikely to be in line with the organization’s security policies or other IT requirements for support, reliability, availability, etc., and can also be a source of malware that could lead to a catastrophic .

A CASB can help bring an organization’s shadow IT into the light, not only enabling support for necessary work practices while ensuring they do not compromise the mission, but also illuminating true cloud expenditure that permits improvements in cost controls.

Data security

Many organizations are already migrating IT resources away from their own data centers and into multiple clouds, including those offered by Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and the breadth of online applications available across the SaaS vendor market. Employees are already sharing sensitive data through these services – Office 365, Salesforce, Amazon S3, Workday, et al.– many of which assert some version of a shared responsibility model that places liability for data security on the customer.

Concerns about the security of the cloud itself are largely misplaced, however. The infrastructure of most CSPs, especially those offering services that have become mainstream, is undeniably highly secure. Concerns should instead be focused on correct configuration of security controls offered by the CSP, as well as identification of required controls that are not available. A recent report discovered that, due solely to such mis- or missing configurations, over 1.5 billion files were exposed in cloud and cloud-related services such as S3, rsync, SMB, FTP, NAS drives, and web servers (Digital Shadows, 2018). It is anticipated that, through 2023, at least 99% of cloud security failures will be due to mistakes made by cloud service consumers rather than by CSPs (Gartner, 2018). While some CASBs now offer cloud security posture management (CSPM) capabilities to assess and reduce configuration risk in IaaS, PaaS, and SaaS offerings through additional controls such as encryption, a CASB can provide an organization with further insurance such that, even if misconfigurations are present, sensitive data cannot be compromised. Such insurance proves particularly necessary when adequate data protection is not offered by a particular cloud service, or when such protection is required against the CSP itself.

Most CASBs evolved from one of two initial postures in relation to data security: a focus on data loss prevention (DLP) and threat detection, or the provision of encryption or tokenization to address privacy and data residency. While these starting positions subsequently expanded to provide coverage across all of these features, there has been a shift away from offering robust data-centric security and key management. For most CASBs, nowadays, data security primarily means DLP, which uses a variety of mechanisms to detect sensitive data within sanctioned cloud services or as it is uploaded to cloud services – sanctioned or shadow – and then blocking, deleting, placing in legal hold, or quarantining content flagged as a potential policy violation. This typically supports both on-premises and remote cloud services users, whether from mobile applications, web browsers, or desktop sync clients. But DLP can only go so far in environments that make data sharing within and across cloud services increasingly easy before a breach occurs. Any organization that uses the cloud to store data should realize that a CASB may not be able to detect how or with whom that data is shared from the cloud, or even who shared it.

Strong data-centric protection mechanisms can address this breach risk, but while many CASBs advertise the capability to encrypt or tokenize data destined for the cloud, these features now tend to be restricted to only a small number of mainstream services, such as Salesforce and ServiceNow. CASBs that began adding these features – driven as much to satisfy analyst ratings as to achieve or maintain competitive parity – discovered that cryptography is a challenging technical domain. Considerable subject matter expertise is required to implement and maintain cryptographic systems, and this expertise does not typically fall within the scope of CASB core competencies. As a result, some CASBs have withdrawn or no longer actively market these features, and some obfuscate their lack of capability or restricted applicability via generalized claims of “data security” that only addresses DLP, adaptive access control (AAC), and the like.

Additionally, while the enactment of the Clarifying Lawful Overseas Use of Data (CLOUD) Act in the U.S. and the growing understanding of the EU’s?General Data Protection Regulation (GDPR) strongly suggest that encryption and key management are becoming critical capabilities (Gartner, 2019), there has been some hesitancy in their adoption, as encryption and tokenization applied outside a SaaS application can affect its functionality as well as that of integrated third party services. Continuing innovations in applied cryptography available via some vendors such as 好色先生TV Voltage, however, have minimized these impacts on functionality such that it is now worth assessing any that might remain in relation to the cost and risk of delegating field and file level data protection to the CSP, or of not applying it at all.

Compliance

The advent of stricter privacy laws in many industries and regions may also be impacting operations. Regional regulations like the GDPR, the California Consumer Privacy Act (CCPA), the , and the as well as industry regulations like those imposed by PCI DSS, SOX, HIPAA, HITECH, FINRA, and FFIEC are creating an array of compliance requirements whose complexity pushes many organizations toward the most conservative global position: ensuring that the sensitive data of the businesses and its customers is always protected, wherever it goes, and to the strongest degree possible.

A CASB with strong data privacy controls across multiple applications can help achieve this; and through policy awareness and data classification functionality, CASBs can help to ensure compliance with data residency laws and to benchmark security configurations against constantly updating regulatory requirements.

Threat detection and prevention

A CASB can defend the organization against the ever-expanding arsenal of malware, including introduction and propagation through cloud storage services and their associated sync clients and applications. A CASB may use advanced threat intelligence sources to scan and remediate threats in real-time across internal and external resources; identify compromised user accounts through the detection and prevention of unauthorized access to cloud services and data; and combine static and dynamic analyses with machine learning and UEBA (User Entity Behavior Analytics) capabilities to identify anomalous activities, ransomware, data exfiltrations, et al.

How does a CASB work?

CASB can be deployed as proxies and/or as API brokers. As certain CASB features depend on the deployment model, “multimode” CASBs – those that support both proxy and API modes – provide a wider range of choices for how to control cloud services.

CASBs deployed in proxy mode are typically focused on security and might be configured as reverse or forward proxies in the path of data access, between the cloud service consumer and the CSP. Reverse-proxy CASBs do not require agents installed on endpoints and so may work better for unmanaged (e.g., BYOD) devices by avoiding the need for configuration changes, certificate installations, and so on. They do not control unsanctioned cloud usage as well as forward-proxy CASBs do, however, through which all traffic from managed endpoints is directed, including traffic to unsanctioned cloud services: this means some unmanaged devices may slip through the net. Forward-proxy CASBs thus often require installation of agents or VPN clients on endpoints. Where agents and VPN clients are misconfigured or mistakenly switched off, sensitive traffic may not get forwarded to the CASB, bypassing inspection.

CASBs deployed in API mode focus on administration of SaaS (and increasingly IaaS and PaaS) applications via APIs provided by those services, including inspection of data at rest, log telemetry, policy control, and other management functions. They work well with unmanaged devices but, as only the mainstream cloud services typically offer API support – and do so to varying degrees – API-only CASBs are unlikely to cover all required security features. While it is possible that SaaS vendors and other CSPs may enhance their APIs to close this gap, in the meantime API-only CASBs do not provide capabilities robust enough to meet scalability and availability requirements. In addition, when CSPs throttle responses to API requests due to the increasing volume of data exchanged between users and cloud services, API-mode CASBs experience unmanageable performance degradations. Proxy mode therefore remains a critical capability.

CASBs may run in a corporate data center, in a hybrid deployment that involves both the data center and the cloud, or exclusively in the cloud. Organizations focused on data-centric protection, or that are subject to privacy regulations or data sovereignty considerations, tend to require on-premises solutions to retain complete control over security infrastructure. Further, the delegation of responsibility and third-party trust requirement that cloud-only CASBs impose through the “Bring Your Own Key” (BYOK) model may contravene internal or external policies, and this problematic position naturally extends to security services offered by the CSPs themselves who may also require to whitelist the CASB’s IP addresses.

Is Voltage Secure Data Sentry a CASB?

Voltage SecureData Sentry is a Security Broker that specializes in data protection, not only for cloud services but also for on-premises applications. It is therefore not a traditional CASB in that it does not seek to provide other functionality across the four pillars. Instead, Sentry coexists with CASBs that specialize in provision of those complementary features, while doing the cryptographic heavy lifting to add strong data-centric protection mechanisms that can be applied across SaaS and other cloud services as well as to commercial and self-developed applications in internal networks.

Voltage SecureData is innovative and standards-based, and has been subject to independent verifications of security strength by internationally recognized, independent cryptographic bodies. It is trusted to secure the world’s most sensitive data by many leading global organizations across the public and private sectors, and in multiple industries.

Format-Preserving Encryption (FPE), which ensures that protection is applied at the field-level in a way that will not break existing database schemas or SaaS field type or size limitations, is combined with a stateless key management system that avoids additional burdens to security administrators. Secure Stateless Tokenization (SST) ensures that numeric fields containing credit card numbers or SSNs are protected without the management or performance overhead of a token database while enabling selected portions of the field to remain in the clear, such as the first six or last four digits, to support routing or customer verification. Format-Preserving Hash (FPH) ensures data referential integrity for analytics and other use cases while complying with regulations such as the GDPR’s right to erasure. Moreover, through additional innovations, such as secure local indices supporting partial and wildcard search terms, and secure email address formatting for SMTP relaying, Sentry preserves application functionality that is impacted by competing solutions.

Organizations can deploy Sentry on premises and/or in the cloud. Sentry communicates with ICAP (Internet Content Adaptation Protocol) capable network infrastructure, such as HTTP proxies and load balancers, to apply security policies to data traveling to and from the cloud, and it intercepts JDBC (Java Database Connectivity) and ODBC (Open Database Connectivity) API calls to apply security policies to data traveling to and from the database. Wherever it is deployed, the enterprise retains complete control over the infrastructure, without the need to share encryption keys or token vaults with any other party, and Sentry’s inspection mode ensures that security policies can be targeted at the specific data fields and file attachments that contain sensitive information.