Cisco Technology, Inc.

Walter Hulick

Thomas Szigeti

David John Zacks

Shannon McFarland

Nagendra Kumar Nainar

An example method identifying a request to access or modify a data resource. The request is made by a user. The example method further includes authenticating the user. Based on authenticating the user, the example method includes determining that the request is associated with a malicious intent based on a characteristic of the user. Further, based on determining that the request is associated with the malicious intent, the example method includes blocking the user from accessing or modifying the data resource.

Optimizing application security based on malicious user intent

Provided herein are techniques to facilitate enhanced cloud access security broker (CASB) functionality via in-band application observability in which a CASB can be implemented in-line between the client device and an embedded application security service. In one instance, a method may include, obtaining, by a CASB from a client device, a first message for an application transaction involving an application operating via the client device. The first message can be augmented to include first security metadata and can be forwarded to trigger one or more actions by an embedded application security service associated with the application. The CASB may obtain a second message from the embedded application security service that includes second security metadata, and one or more actions can be triggered at the CASB based, at least in part, on the second security metadata included in the second message.

Enhanced cloud access security broker functionality utilizing in-band application observability

Techniques for expressing, communicating, de-conflicting, and enforcing consistent access policies between an IBN architecture and a Cloud-Native architecture. Generally, network administrators and/or users of a Cloud-Native architecture and an IBN architecture express access policies independently for the two different domains or architectures. According to the techniques described herein, a Network Service Endpoint (NSE) of the Cloud-Native architecture may exchange access policies with a network device of the IBN architecture. After exchanging access policies, conflicts between the sets of access policies may be identified, such as differences between allowing or denying communications between microservices and/or applications. The conflicts may be de-conflicted using various types of heuristics or rules, such as always selecting an access policy of the IBN architecture when conflicts arise. After the access policies have been de-conflicted, the IBN architecture and Cloud-Native architecture may then apply consistent access policies for traffic and communications in their respective network architectures.

Growing community of inventors

Pearland, TX, United States of America

Walter Hulick