The present invention relates to protecting communication over a computer network. In one embodiment the invention relates to traffic between a client and an application.
Telecommunication, using a variety of protocols, is widely employed by enterprises globally. Over the past years, enterprises face increasingly sophisticated threats that target, among others, the traffic over computer networks.
Defenses employed to secure computer network traffic include filters, such as firewall, and intrusion detection or prevention systems, which look for suspicious traffic once it has passed through the firewall. In some cases, an access broker, that acts as a security policy enforcement point, is placed between service providers and consumers. However, current day security solutions are not effective against all threats. For example, some worm-like vulnerabilities that could spread from one computer to another, are a daunting security challenge, despite patches that were released to fix such vulnerabilities.
With computers and devices connected everywhere, such vulnerabilities could have potentially disastrous effects not only on businesses, but on government organizations, smart buildings, healthcare, and more.
Embodiments of the invention provide protection from vulnerabilities by ensuring that only uncompromised requests are transferred to applications.
Additionally, embodiments of the invention enable organizations to isolate their applications and provide access to these applications only to a set of privileged/authorized users.
Embodiments of the invention provide a system and method for protecting applications (and thus protecting their host servers and related networks). An access broker, according to embodiments of the invention, operates at the application layer acting as a termination point for client requests. Terminated requests are deconstructed and dangerous components in the deconstructed request are identified and disarmed. The request is then reconstructed without the dangerous components. Thus, potentially harmful requests may be modified such that they are stripped of identified vulnerabilities. The reconstructed request, which is now stripped of vulnerabilities, is then sent to the application.
Because applications are, typically, on a private network, the application can only be accessed via the access broker, thereby preventing access of unmonitored traffic to the application and limiting exposure of other layers to attacks.
In some embodiments, a request is processed via additional one or more protecting and security-enhancing phases such as validation, authentication and authorization, to increase the chance that an accessed application is isolated from malicious requests and is approached only by authenticated and authorized users.
Requests that have been processed via one or a combination of additional phases, are logged to a log file to maintain an audit trail that can help in the event of a security issue, to understand and fix the problem.
The invention will now be described in relation to certain examples and embodiments with reference to the following illustrative drawing figures so that it may be more fully understood. Aspects of the invention are described with reference to flowchart illustrations and/or block diagrams of methods, systems, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
In the drawings:
In the following description, various aspects of the present invention will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the present invention. However, it will also be apparent to one skilled in the art that the present invention may be practiced without the specific details presented herein. Furthermore, well known features may be omitted or simplified in order not to obscure the present invention.
As used herein, the terms “component”, “module”, “unit”, “system” and the like refer to computer-related entities; hardware, firmware, software, a combination of software and hardware, or the execution of software. For example, a component or module may include a process running on a processor, a thread of execution, a program, and/or a computer. A module can be localized within one computer or distributed between multiple computers. Modules can execute from various computer readable media having various data structures stored thereon.
Any of the elements shown in the Figures below are preferably implemented by one or more computers in computer hardware and/or in computer software embodied in a non-transitory, computer-readable medium in accordance with conventional techniques.
Embodiments of the invention may include a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Reference is now made to
In some embodiments, the TAB 102 is configured to receive a response 107 from the application 104 and to send the response 107 to the client 108.
Typically, TAB 102 operates at the application layer of a computer network, enabling the TAB 102 to read and modify requests and responses at this layer. Since the TAB 102 is on the private network and the client is not, the application 104 may only be accessed by the client 108 via the TAB 102, thereby preventing access of unmonitored traffic to the application and limiting exposure of other layers to attacks.
Computers in a computer network (such as the network illustrated in
TAB 102 may be implemented in a unit, such as an application delivery controller, or in a server proxy that acts as a gateway between networks (e.g., a private network and the internet). TAB 102 may include, for example, an identity-aware proxy, a forward proxy and/or a reverse proxy.
An exemplary method for protecting computer network communication, carried out by a unit such as TAB 102 and/or a disarm and reconstruct unit that may be in communication with TAB 102, is schematically illustrated in
Disarming the received request (in step 114) typically includes deconstructing the request into components and detecting permitted and non-permitted components. The permitted (but not the non-permitted) components are then used to obtain the reconstructed request that is sent to the application.
An incoming request terminated, e.g., by TAB 102, is input to the DR unit 206, where it is deconstructed, by a deconstruct module 202, disarmed and then reconstructed by a reconstruct module 204.
Deconstruct module 202 may use, for example, isolated containers to provide a disarm environment for the requests where a parser (or similar component) may be used to deconstruct the request into one or more components, such as, headers and their values.
In some embodiments, a plurality of DR units may be used, possibly simultaneously. Incoming PDUs may be classified by a controller, e.g., based on the type of protocol used by the application being accessed, and may then be routed, e.g., by the controller, to a specific isolation container based on their classification.
Components of a PDU are determined to be permitted or non-permitted, for example, by using a validator and/or comparing components to a list, e.g., checking against a whitelist and/or blacklist. In some embodiments, a list (e.g., whitelist/blacklist) is specific per application, e.g., specific to a protocol of the application. For example, components of a PDU can be compared to an application-specific list of permitted or non-permitted components to determine if the components deconstructed by module 202, are permitted or non-permitted.
To disarm the request, non-permitted components (e.g., headers or values that are not on the whitelist and/or are on a blacklist and/or are determined to be non-permitted by a validator) are removed.
In some cases, the DR unit 206 or a processor in communication with the DR unit 206 may create a permitted component (e.g., header or value) to replace a removed non-permitted component. The newly created component can then be used in reconstruction of the request. By creating a new permitted component to replace a removed component, DR unit 206 ensures that even hidden vulnerabilities are not inserted into a reconstructed request.
Reconstruct module 204 then reconstructs a request from the permitted components, thereby producing a reconstructed request. The reconstructed request, which does not include non-permitted components, can now be sent, e.g., by a controller, such as TAB 102 or other unit, to the application.
In some embodiments, a PDU is validated, namely, determined to conform with a protocol (e.g., application-specific protocol), prior to deconstructing the request. Thus, only validated requests are transferred to the DR unit 206 for disarming.
Non-permitted PDUs (e.g., requests to an application that are not on the whitelist specific to that application) are dropped.
An exemplary method for protecting an application, including disarming and reconstructing a PDU, carried out, for example, by DR unit 206, is schematically illustrated in
A request to an application is received (step 200), e.g., at an access broker. The request is terminated (step 222) and then validated, namely, checked against (one or more) protocols of the application, to determine if it is a permitted request. For example, the request can be checked against a protocol-specific whitelist and/or blacklist. Requests that are included in the whitelist are considered permitted and requests that are not included in the whitelist or included in a blacklist, are non-permitted.
If the request is determined to be non-permitted (decision point 223), the request is dropped (step 224) and is not forwarded to the application. If the request is permitted (decision point 223) the request is deconstructed into components (step 226). Each component is then checked to determine if it is permitted or not (decision point 227). For example, the components can be checked against a whitelist and/or blacklist and/or by using a validator, to determine if they are permitted or non-permitted.
Permitted components are used to reconstruct the request (step 230) and non-permitted components are removed (step 228).
Thus, a reconstructed request produced by DR unit 206 contains only components that comply with the application policy and protocol, and which contain no harmful information. As such, the reconstructed request may be safely sent to the application.
In one exemplifying case, an access broker, such as TAB 102, serves as a broker for a remote desktop protocol (RDP) application having a policy of blocking file-transfers. If a file-transfer request is received at the access broker, it will be checked against a list which does not permit file-transfers, per the application policy. Based on the comparison to the list, the request will be determined to be non-permitted and will be dropped and not forwarded to the application, thereby protecting the application.
In another exemplifying case, CVE 2017-5638 is a vulnerability in Apache Struts—a popular web application framework used by enterprises to build their internal applications. This vulnerability essentially allows a user to run commands on remote servers without permission, by sending invalid values on the Content-Type HTTP header.
This request can be sent despite not being compliant with the Hypertext Transfer Protocol (HTTP), and can be crafted to cause different behaviors on the server side.
If a request containing this (or similar) vulnerability is received at a system according to embodiments of the invention, it will be disarmed, as described herein. The header of this request will be determined to be non-permitted (e.g., by being compared to a HTTP-specific whitelist and/or blacklist). The Content-Type header containing the invalid values will be removed such that, the request containing the vulnerability will not be forwarded to the remote server, thereby preventing the attack and protecting the remote server. Possibly the header containing the invalid values may be replaced by a newly created valid header such that the request may be forwarded to the remote server with no vulnerability.
In yet another example, a worm-like vulnerability named BlueKeep can send malware packets to operating systems that use or enable RDP, causing heap corruption, which allows for arbitrary code execution at the system level.
If a request containing a BlueKeep (or similar) vulnerability is received at a system according to embodiments of the invention, it will be disarmed, as described herein. At least one value of the request will be determined to be non-permitted (e.g., by comparing to an RDP-specific whitelist) and will be removed. Thus, a request containing the BlueKeep vulnerability will not be forwarded to a remote server, thereby preventing the attack and protecting the remote server and the computer network.
An access broker, such as TAB 102, terminates traffic but does not change the protocol at either client or application end, thus, neither client nor application are aware of it. Therefore, embodiments of the invention enable information technology (IT) managers and Security and Operations teams (for example) to protect their organization's applications, their underlying data and their underlying infrastructure, from attempts to compromise them, without requiring a change to users' or applications' workflow.
The network traffic, e.g., requests and responses, is terminated, by TAB 102, at the application layer. As discussed above, operating at the application layer limits the traffic across the network to the bare required minimum and mitigates the risk of adversaries attacking the lower layers of the network model (e.g., Open Systems Interconnection (OSI) model) or gaining access to unauthorized neighboring applications.
In some embodiments, a request is processed via a pipeline which can include one or a combination of protecting and security-enhancing phases, after which, if successfully passing all phases of the pipeline, the request can be sent with no risk to the application.
In one embodiment, which is schematically illustrated in
In one example, which is schematically illustrated in
Pipelines having more or less, possibly differently arranged and ordered, phases may be applied on requests, according to embodiments of the invention.
An access broker, according to embodiments of the invention, may be configured to preform one or more of the pipeline phases exemplified in
Adding context to a request may include, for example, providing information, such as, location, geoIP, IP address, time, application usage history, device identifiers, data from the identity provider, user info, endpoint info, and more. The information added to a request at this phase may provide details that can be used by downstream phases, such as by phase 315 (authorization) and/or phase 316 (log).
In one embodiment, an access broker, such as TAB 102, or a unit in communication with the access broker, validates the request against a given protocol. Since the access broker knows the application it brokers access to, the appropriate protocol is known to the access broker in advance. As described above, packets that do not validate against the protocol at this phase, are dropped and do not advance through the pipeline.
As described above, a system, according to embodiments of the invention, is configured to disarm a request. A request gets deconstructed and re-constructed. Non-permitted headers and/or values are removed from the reconstructed packet, allowing only permitted PDUs, headers, and values to pass through the pipeline. The request now passing through the pipeline is a validated and disarmed and reconstructed request.
An access broker, such as TAB 102, or a unit in communication with the access broker, may be configured to authenticate a reconstructed request. The access broker may use the original protocol of the application in order to authenticated the request without requiring the user to change their workflow, and without modifying the application or its host server.
In one embodiment, the access broker can use the existing protocol to add an additional step, typically, another step that is native to the protocol. Adding a step native to the protocol may include, for example, a prompt for an additional password for an SSH (Secure Shell) session, an inner-login screen for RDP sessions, or a redirect chain that checks cookies on identity providers for HTTP sessions. This method does not require the user to visit a portal.
In another possible embodiment, a parameter is added to the protocol's initial request. This generally means adding a secret to one of the fields that are received by the access broker on the initial request. This can include, for example, adding a mstshash cookie for RDP sessions and encoding a secret to the server name indication (SNI) used for HTTP. Adding a secret to these requests may require the user to get a connection string, or a file (depending on the protocol) from a portal.
An access broker, such as TAB 102, or a unit in communication with the access broker, can use a policy engine to determine if a request (in this example, an already validated, disarmed, and authenticated request) is authorized. In one example, the access broker sends the request details, along with any relevant context (e.g., user info and endpoint info that were added at phase 311), to receive a “Block” or “Allow” verdict, in accordance with the policy.
Typically, every request, and the context added to the request (e.g., at phase 311), whether allowed or blocked, is logged in a log file. This log may help, for example, in the event of a breach or vulnerability exploitation, to understand and fix the vulnerability that allowed it to happen.
Requests that have successfully passed all phases of pipeline unit 334 contain only safe components (e.g., ensured at phase 313), comply with relevant policies and protocols (e.g., ensured at phases 312, 313 and 315), are confirmed to be sent from an identified user (e.g., ensured in phase 314) and can be tracked and analyzed (e.g., by using phases 311 and 316). Thus, embodiments of the invention provide improved visibility and safety to traffic over a computer network.
Unless specifically stated otherwise, as apparent from the description above, it is appreciated that throughout the specification discussions utilizing terms such as “analyzing”, “processing,” “computing,” “calculating,” “determining,” “detecting”, “identifying”, “sending”, “receiving” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulates and/or transforms data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices. Unless otherwise stated, these terms refer to automatic action of a processor, independent of and without any actions of a human operator.
Number | Date | Country | |
---|---|---|---|
62960167 | Jan 2020 | US |