Cisco CloudLock
Cloud applications have changed the way organizations store, access, and share information. Users can work with SaaS applications from corporate offices, branch locations, home networks, and mobile devices, while sensitive data can move between multiple cloud services without passing through the traditional corporate security perimeter.
This creates a different security challenge.
The question is no longer simply whether a user is connected to the network or whether a connection should be allowed. Security teams increasingly need to understand who is accessing the application, what they are doing, what data is involved, and whether that activity complies with security policy.
This is the security problem that Cisco CloudLock was designed to address.
Cisco CloudLock is a cloud-native Cloud Access Security Broker (CASB) that provides visibility and security controls around cloud applications, users, and data. Rather than attempting to recreate the traditional network perimeter around every SaaS application, CloudLock works with cloud services to provide a security and governance layer around activity taking place within them.
This becomes particularly important as organizations adopt multiple cloud applications. Security teams need to understand not only which applications are being used, but also how those applications are being used, what information is being shared, and where potential security risks exist.
CloudLock therefore brings together several important areas of cloud security, including data security, application security, user security, threat detection, and policy enforcement.
The broader objective is not simply to block cloud activity. It is to provide enough visibility and context for security teams to distinguish legitimate business activity from behaviour that may introduce risk.
Throughout this article, we will examine the architecture behind CloudLock, the security challenges created by direct-to-cloud access, the role of DLP and application-aware controls, and how the CASB model provides a different approach to protecting cloud applications and data.
Microservices Security
“The Road To Cisco Cloudlock Or Multiple Point Products”
Protecting a modern SaaS environment can require multiple security capabilities, including UEBA, DLP, application security, threat detection, identity controls, and compliance monitoring. Historically, organizations often addressed these requirements by deploying separate products for each capability and then integrating those products with individual cloud applications.
This approach can provide strong functionality, but it also introduces operational complexity. Security teams may need to manage multiple products, policies, integrations, dashboards, and data sources across an increasingly distributed environment.
As the number of cloud applications increases, maintaining consistent security policies across these individual control points becomes increasingly difficult.
The challenge is therefore not simply adding more security products. It is creating a security architecture that provides visibility across users, applications and data while allowing security policies to be applied consistently.
Cisco CloudLock provides an example of this approach through its cloud-native Cloud Access Security Broker (CASB)architecture, bringing cloud application visibility, user activity analysis, data protection, and policy enforcement into a cloud-focused security model.
The broader Cisco security architecture can then provide additional controls for secure access, identity, threat protection, and network security.
Challenge: Lack of Visibility
Cloud adoption changes the traditional security model. Applications and data are no longer necessarily hosted inside an organization’s data centre, and users may access SaaS applications directly from offices, branch locations, home networks, or mobile devices.
This creates a fundamental visibility challenge.
Security teams need to understand what is happening in the cloud, who is performing the activity, which application is involved, what data is being accessed, and whether that activity complies with security policy.
Traditional network controls can provide important visibility into network traffic, but they do not necessarily provide the application-level or data-level context required to understand activity occurring inside SaaS platforms.
The cloud therefore introduces a different security question.
Instead of asking only where a connection originated, security teams increasingly need to understand the relationship between identity, application, data, behaviour and policy.
Examples: Cloud Security Solutions.
Cisco CloudLock
Cisco Umbrella
Cisco Secure Cloud Analytics
Cisco Duo Security
These technologies address different parts of the wider cloud-security problem. The important architectural principle is that cloud security should not depend on a single control point. Identity, application, data, network, and threat controls may all contribute to the overall security model.
Challenge: Direct to the Cloud
Cloud computing provides users with direct access to applications, data, and services from almost anywhere. SaaS applications have accelerated this model because employees can work directly with cloud services without requiring applications to be hosted inside the corporate network.
As organizations adopt direct internet access, branch offices and remote users increasingly connect to cloud services instead of backhauling traffic through a central corporate security stack.
This changes the role of traditional security controls.
The traditional security stack was designed around a model where users, applications, and data were largely located behind a corporate perimeter. Cloud services challenge that assumption because the application may be external, the user may be remote, and the data may exist entirely within a SaaS platform.
This does not make traditional network security obsolete. Instead, it means network security must be complemented by controls that understand cloud applications, identities, user activity, and data.
The result is a shift from a purely network-centric security model towards a broader model based on identity, application, data, behaviour and policy.
Cisco Umbrella and Cisco Cloudlock
Cisco Umbrella and Cisco CloudLock address different parts of the cloud-security problem.
Umbrella provides cloud-delivered security capabilities for users connecting to the Internet and can provide visibility across network devices, office locations, and roaming users. This makes it particularly relevant to secure internet access and identifying or preventing malicious activity before it reaches users and devices.
CloudLock takes a different approach. It uses a 100 percent cloud-native, API-based approach. Rather than relying solely on visibility of network traffic, the CASB model focuses on activity occurring within cloud applications, including users, applications, data, and cloud-to-cloud interactions.
This distinction is important.
A user may access a SaaS application successfully over an encrypted internet connection while performing an action that violates organizational policy. Network-level controls may know that the user connected to the application, but a cloud security control needs to understand what the user did inside the application and what happened to the data.
Together, these approaches demonstrate an important principle of modern cloud security: protecting cloud environments requires visibility both around the connection and inside the cloud application.
Highlighting Cisco Cloudlock
Cisco CloudLock is a Cloud Access Security Broker (CASB) that helps organizations understand and protect cloud-based identities, applications, and data.
The value of the CASB model is not simply that it adds another security product. It provides a security control point for understanding activity that can otherwise be difficult to observe when applications and data are hosted outside the traditional corporate network.
CloudLock can therefore be viewed through three primary security domains: data security, application security, and user security.
Data Loss Prevention:
A Cisco Cloudlock Data Loss Prevention (DLP) capability can identify sensitive information within cloud environments and apply policies designed to reduce unauthorized sharing or exposure.
At this stage, the important architectural point is simply that cloud DLP provides visibility into the data being used within cloud applications and allows security policy to be applied to that activity.
The detailed DLP use cases and data-protection mechanisms are examined later in this article.
Automated Responses:
Cloud security becomes more effective when visibility can be connected to an appropriate response.
Through Cisco Cloudlock’s API-driven Cloud Access Security Broker (CASB) architecture, security events can be associated with actions within the monitored cloud application. Depending on the application and policy, responses can include generating alerts, restricting activity, protecting information, or taking action against cloud resources.
This creates a security workflow that moves beyond simple discovery:
Visibility → Analysis → Policy → Security Response
The objective is to identify risky activity and provide security teams with enough context to make an appropriate response without relying entirely on manual investigation.
Understanding CASBs – Security Control Point
CASB, the acronym for Cloud Access Security Broker, describes a security control point positioned around cloud services and applications. It is a security control point, providing visibility, policy enforcement, data protection, and security monitoring for cloud environments.
The importance of CASB becomes clearer when considering how cloud applications are used today. Users may connect from different locations and devices, applications may be delivered entirely through SaaS platforms, and sensitive information may move between multiple cloud services.
A CASB therefore helps security teams establish a consistent security view across these activities.
The principal CASB capabilities include:
cloud application visibility
data protection and DLP
policy enforcement
threat and behavioural analysis
access and identity controls
compliance monitoring
security response
Importantly, CASB solutions go beyond simply “permitting” or “denying” access. They can provide visibility into what users are doing inside cloud applications and apply policy to activities involving data and applications.
The cloud application itself does not necessarily need to change. Users continue accessing the SaaS service, while the CASB provides an additional security and governance layer around that activity.
CASB Categories:
CASB architectures can be implemented in different ways. Two important approaches are API-based CASB and log-based CASB.
A log-based approach typically consumes activity information from cloud applications or other monitoring systems. This provides valuable visibility, but the CASB is dependent on logs being generated, collected, and processed before meaningful analysis can occur.
An API-based approach communicates directly with supported cloud applications through their APIs. This allows the CASB to inspect cloud data and activity without requiring all user traffic to pass through a traditional proxy.
API-based CASB protection is particularly useful for cloud-to-cloud activity. For example, a user may move information between SaaS applications without that traffic ever travelling through the corporate network.
Cloudlock is an API-based CASB. Therefore, unlike a traditional proxy-based security architecture, it does not need to sit directly in the user traffic path to provide cloud security controls.
This has important architectural advantages. The security model does not require all cloud traffic to be forced through a central proxy infrastructure simply to gain visibility into cloud applications.
The result is a different approach: rather than attempting to recreate the traditional corporate perimeter around every cloud application, the security control works directly with the cloud application’s data, users, and APIs.
That distinction is central to understanding why CloudLock is fundamentally a cloud-native security control rather than simply another network firewall.
Cloud Security Concepts
A. Data Loss Prevention (DLP)
Let us start with DLP. Data Loss Prevention (DLP) is designed to prevent sensitive or regulated information from leaving an organization without authorization. This becomes particularly challenging in cloud environments, where users can access, copy, share, and distribute information across multiple SaaS platforms and external services.
Traditional security controls such as firewalls, email security, and endpoint protection are primarily concerned with protecting users, systems, and network traffic. DLP addresses a different problem: preventing authorized users from performing unauthorized data-handling actions.
This is an important distinction. An employee may legitimately have access to customer records, financial information, or intellectual property. The security problem begins when that legitimate access is used to move sensitive information somewhere it should not go.
Intentional and accidental data breaches are not uncommon.
Example: Google Cloud Sensitive Data Protection
DLP in Action – Example of Threat:
Consider a financial services organization where an employee has legitimate access to large quantities of credit card numbers and personally identifiable information (PII). The employee may also have legitimate access to corporate email.
An attacker does not necessarily need to compromise the employee’s account. A malicious insider, or an employee acting accidentally, could simply attach sensitive information to an email and send it to a personal account.
Firewalls and email security solutions can’t necessarily prevent this type of activity because the user may be legitimately authenticated and the email service itself may be authorized.
They are not looking for that type of metadata. DLP, however, is specifically designed to identify sensitive information and apply policy when that information is being shared, copied, downloaded, or transferred.
With appropriately configured DLP policies, organizations can identify sensitive information, generate alerts, block unacceptable transfers, and create an audit trail for investigation.
“Generally speaking, it boils down to a lack of visibility”
This is particularly important in cloud environments. Traditional on-premises security controls have historically provided strong visibility into network traffic, but SaaS applications introduce a different model. Users can share files directly from cloud applications with external parties without that activity necessarily passing through the organization’s traditional network security stack.
The collaborative nature of cloud applications makes this both powerful and risky. A user can share a document with an external address, create a public link, or move information between cloud services without the data ever traversing the corporate network.
DLP and CASB technologies extend visibility into these environments. A security team can determine whether sensitive files are being shared externally, whether sharing violates organizational policy, and whether an action should be allowed, blocked, or reported.
The important point is that DLP is not simply about identifying sensitive information. Effective cloud DLP combines data classification, user identity, application context, activity, and policy to determine whether an action should be permitted.
B. Application Firewalls
Next, we have application firewalls. How does an application firewall differ from a “traditional firewall”? The fundamental difference is what the security policy is protecting.
A traditional network firewall primarily evaluates network traffic using attributes such as source and destination addresses, ports, protocols, and connection state. An application firewall moves the security decision closer to the application itself.
Application Firewall vs. Traditional Firewall.
Cloud applications introduce an important challenge for traditional network-based controls. A SaaS application may need to be accessible from many different networks and devices. Consequently, building security policy primarily around “Source IP” becomes increasingly restrictive and less useful.
A user could connect from a corporate office, a home network, a mobile connection, or another country. The application still needs to determine whether the user, request, session, or transaction should be trusted.
Your toolkit just became ineffective when it came to Layer 3 and Layer 4 security controls.
This does not mean that network firewalls have become irrelevant. Layer 3 and Layer 4 controls remain important for network segmentation, traffic filtering, and infrastructure protection. The issue is that they cannot, by themselves, provide all of the context required to make decisions inside modern cloud applications.
Application-aware security can consider factors such as:
the application being accessed
the identity of the user
the type of device
the requested action
the sensitivity of the data
the location or risk context
the behaviour associated with the session
The security model therefore moves beyond simply asking “Where did this traffic come from?” and begins asking “What is the user attempting to do, and should that action be permitted?”
Example: Distributed Firewalling
Distributed security controls illustrate how policy can be enforced closer to workloads, applications, and users rather than relying exclusively on a centralized perimeter.
The important architectural point is that cloud security is not achieved by simply extending the traditional perimeter into the cloud. Security controls need to operate at the appropriate layer and understand the application, identity, data, and context involved.
For CloudLock, this distinction is important because CloudLock is not primarily a replacement for a traditional network firewall. Its value comes from providing visibility and policy enforcement around cloud applications and the data contained within them.
C. Cloud Access Security Broker (CASB)
Users interact with cloud services such as SaaS applications, IaaS platforms, and PaaS environments from many different locations and devices. A Cloud Access Security Broker (CASB) provides a security control point around the organization’s use of those cloud services.
The key benefit is visibility and policy enforcement in environments that the organization does not directly own or operate.
CASB solutions can help protect cloud data, applications, and user activity regardless of where the user is or how they access the cloud application.
Where traditional security mechanisms often focus on the endpoint or network, a CASB focuses specifically on the organization’s use of cloud services.
CASBs can provide capabilities including:
visibility into cloud application usage
data loss prevention
policy enforcement
detection of risky behaviour
access control
compliance monitoring
protection of sensitive information
Importantly, CASB solutions go beyond simply “permitting” or “denying” access. They can provide visibility into what users are doing inside cloud applications and apply policy to activities involving data and applications.
The cloud application itself does not necessarily need to change. Users continue accessing the SaaS service, while the CASB provides an additional security and governance layer around that activity.
CASB Categories:
CASB architectures can be implemented in different ways. Two important approaches are API-based CASB and log-based CASB.
A log-based approach typically consumes activity information from cloud applications or other monitoring systems. This provides valuable visibility, but the CASB is dependent on logs being generated, collected, and processed before meaningful analysis can occur.
An API-based approach communicates directly with supported cloud applications through their APIs. This allows the CASB to inspect cloud data and activity without requiring all user traffic to pass through a traditional proxy.
API-based CASB protection is particularly useful for cloud-to-cloud activity. For example, a user may move information between SaaS applications without that traffic ever travelling through the corporate network.
Cloudlock is an API-based CASB. Therefore, unlike a traditional proxy-based security architecture, it does not need to sit directly in the user traffic path to provide cloud security controls.
This has several architectural advantages. The security model does not require all cloud traffic to be forced through a central proxy infrastructure simply to gain visibility into cloud applications.
Instead, the CASB can work with the cloud application’s own interfaces to understand data, users, application activity, and policy-relevant events.
This becomes particularly valuable when data moves between cloud services. A user might download information from one SaaS platform and upload it into another without that activity traversing the corporate network.
A traditional network-centric security model may have limited visibility into that cloud-to-cloud transaction. An API-based CASB can provide a different point of visibility by interacting directly with the supported cloud services.
The result is a different security model: rather than attempting to recreate the traditional corporate perimeter around every cloud application, the security control works directly with the cloud application’s data, users, and APIs.
That distinction is central to understanding why CloudLock is fundamentally a cloud-native security control rather than simply another network firewall.
How to Think About CloudLock
Cloud security is easier to reason about when visibility, analysis, policy and response are treated as a continuous engineering process rather than isolated security features.
Start with visibility. Identify cloud applications, users, data, access patterns and cloud activity. The objective is to understand what exists before attempting to control it.
Cloud Visibility
Cloud Security Visibility and Context
The three security capabilities described above address different parts of the cloud-security problem, but they share a common requirement: visibility with context.
Knowing that a user connected to a cloud application is useful, but it is not enough to determine whether the activity represents a security risk.
A modern cloud-security control needs to understand several pieces of information at the same time:
Identity: Who is performing the activity?
Application: Which cloud service or SaaS application is involved?
Data: What information is being accessed, uploaded, downloaded, or shared?
Behaviour: Is the activity consistent with the user’s normal behaviour?
Context: Where is the user connecting from, what device are they using, and does the activity present additional risk?
Policy: Is the requested action permitted by the organization?
Together, these elements create a more useful security model than simply allowing or denying a network connection.
For example, consider a user who normally accesses a small number of documents from a corporate laptop during working hours. The same user account suddenly downloads thousands of sensitive files from a new location and attempts to share them with an external account.
The network connection itself may be legitimate.
The identity may also be legitimate.
The application may be authorized.
But when identity, application, data, behaviour, and context are considered together, the activity becomes significantly more suspicious.
This is where cloud security moves beyond traditional perimeter thinking.
The security question is no longer simply:
“Can this user connect to the application?”
It becomes:
“Is this user performing an action that is consistent with policy and acceptable risk?”
This distinction is important because cloud security is increasingly concerned with what happens after access has been granted. A user can be authenticated, the application can be approved, and the network connection can be legitimate while the activity itself still violates organizational policy.
A CASB such as CloudLock helps provide the visibility required to evaluate this activity within the cloud environment. By combining information about users, applications, data, and activity, security teams can apply policy based on more than network location alone.
The resulting security workflow can be represented as:
Visibility → Analysis → Policy → Security Response
This provides the foundation for a more contextual approach to cloud security.
The traditional network perimeter still has an important role, but it cannot provide all of the context required to understand modern SaaS activity. Security controls must increasingly understand what is happening inside the cloud service, not simply whether traffic is travelling towards it.
That is the fundamental shift from network-centric security to cloud-aware security: the security decision is increasingly based on the relationship between identity, application, data, behaviour, context, and policy.
Connect the Context. Make the Security Decision.
Cloud security decisions become stronger when identity, application, data and behaviour are considered together. Select the context an engineer would investigate before applying policy.
1. Select Investigation Context
Choose the information available to the security team during a cloud-security investigation.
Security Assessment
More relevant context produces a stronger basis for policy decisions.
- Fortinet’s new FortiOS 7.4 enhances SASE - April 5, 2023
- Comcast SD-WAN Expansion to SMBs - April 4, 2023
- Cisco CloudLock - April 4, 2023