This invention uses the device requested information delivered over a multitude of requests to determine the continued validity of access to the content offered by the information source and delivered to the device requesting such information.
Next Generation Firewall technology has become commonplace in today's networks. These devices generally allow or block content for a transaction between a client devices (heretofore a requesting device) and a content resource on the public Internet. Within this process the Firewall solution typically looks at a session of information and decides the best way to control that session.
Prior to Next Generation Firewall solutions controlling the data flowing in and out of a device to a resource, systems like Internet Proxies control the data flowing between a requesting device and the content resource. Proxies typically would control the access via an inspection of the connections and the URL requested. The proxy may also use the user name and other information based on the transaction for the allow or deny decision on a transaction.
A transaction of a single webpage, for example, can deliver a multitude of images and objects from other webpages within a single transaction and each object can be categorized differently and thus controlled. Today's solutions focus on the control of that page's content, whether delivered by the host site or another referenced location. The culmination of the delivered content and the decision whether to block or allow that content is based on logic processed within that single request.
The state of the art currently categorize a site defined by a list of URLs grouped into a finite list of content categories which provides a typical filtering process. The current art only process traffic that exists in the session and maximize overall efficiency, the state of the art solutions focus on content analysis on a single transaction and make an allow or block decision based on information within that session.
The researched embodiments of the present solutions, such as Intrusion Prevention Systems (IPS), next generation firewall solutions, proxy appliance systems, and other Internet Control Devices, uncovers the lack of use of extended context of a plurality of unique data requests over time to categorize and thus limit access to Internet Resources.
This invention builds upon the current art in expanding the context of categorization of resources over time to build a unique response to requesting device over a multiple of requests to formulate an allow or blocking decision for the access of a resources on the public network.
In one embodiment, this invention intercepts the data flowing between a requesting device and the content on the public network and collects the Uniform Resource Locator (URL) information for the initial request. Like many other inventions currently published, this invention extracts the URL for a contextual categorization of the initial request. If this request is denied then no further processing is made and the request is logged into the user access database. If the requested content is allowed, then the transaction is marked as allowed and also logged. There is no difference between this process and other art in the marketplace. The new art in this invention pertains to subsequent access to resources in the public network which are evaluated based on the previous transactions made by the requesting device. The prior decisions made for a specific resource will influence current access restrictions and thus generate a unique allow or block decision based on the prior access results.
A further embodiment of the invention evaluates access of the requested resource by analyzing the context of a multitude of transactions from a multitude of content sources over a period of time to create a profile of access that allows or denies the utilization of a resource on a public network. This custom profile allows for future access unique to the individual device. In a sample use of this embodiment, the access to a search engine may change restriction patterns to enforce the search engine's Safe Search function if the requesting device has a searching pattern of restricted content occurs over a period time.
Once a threshold is met the system would enforce safe search by appending a safe search variable to the requested URL which is subsequently sent from the intermediary device to the search service. This threshold of search restriction may be imposed for a finite amount of time or number of search requests.
A further embodiment of the invention involves using “referer” (SIC), and heretofore known as referrer, and categorizes this referrer URL and maintains this information to make future URL access decisions. As a basis for the categories on a subsequent content requests both the referrer and the base URL are compared to a category list. System logic evaluates the requested resource by initially evaluating the requested URL which may will result in one of three results to either allowed, blocked or further analyzed the content. Further analysis will take the category of referrer URL. The resultant decision from the analysis of the category of the referrer will result in an allow, block or further analysis based on the legacy data collected from the requesting devices' previous access to public resource and content. A final decision on the content requested will be logged into the access data store for the requesting device.
Categorization of the requested resource will be made using the hostname 108. If the hostname is invalid, request categorization will be attempted 109 using just the IP address. Finally, the validation of the assigned category or categories for this transaction is tested 110. If the category is valid, the category for the transaction is stored as a variable for later use 112 in making a block, allow, or continue examining the transaction. If the category is invalid, then the system stores that the category is not valid. Once the category, hostname, source identification and additional information relating to the current flow data is collected, it is passed 150 to the referrer category and session processing functions described in
If the request is HTML and a URL 2001 is available, then additional specific categorization of the authority with a path is made 204 and then stored for further analysis 205. If the session does not contain a header or the path is already categorized, then a check is done for a referrer 203 within the header. If the referrer exists, then categorization of the referrer is performed 207 and the result is stored for later analysis 206. If no referrer is present or the referrer categorization is completed, then all data is consolidated into a matrix of current categories 208.
A check for the base category is performed 209 to validate it is allowed in any circumstance. If the base category is not allowed no matter the circumstance, a block 215 is performed on that object 299 and the response is sent back to the exit processing system 181. If the base category can be allowed under the correct conditions then the referrer category is validated. If the referrer category is to be blocked no matter the circumstance. 210 then a block is performed 216 and the response is sent back to the exit processing system 181.
If the referrer is allowed 210 then the system processes additional logic to modify the request 211. The request modification takes into consideration all factors collected throughout the data flow and consolidates a decision with respect to modification. If no modification is deemed required, the transaction is allowed 217 and returned 298 to the exit processing system 182.
If an adjustment to the transaction is required, then the session is checked for HTML 213 as adjustments to HTML is handled differently than other flows. If the flow is not HTLM then a validation of the session 212 is performed. If the session cannot be modified or does not need modification, then a response is sent 297 to the exit processing system 182. If the session is HTML, then the session is sent to the logic adjustment system 298.
If the hostname is valid, the system stores the hostname variable 410 for later processing. The system extracts historical client and device used 411 and checks that the site is a modifiable request 412. With a valid modifiable request presented, determination of the use count will be performed 413 and based on logic 414 a determination if the request needs to be modified or allowed to continue unmodified. If a modification is required 415 it is processed. If a modification is not required or successful modification is completed, then 498 will be sent the modification result and prepare the session for use at the information source.
If the request is not able to be modified or if the hostname extraction failed then the session will exit unchanged 409 by sending the notification to the intermediate control exit point 498.
The intermediate control exit point 498 prepares the transaction for delivery and presents the session back onto the network 499 where it will continue to the content source server.
Classifications 713/154, 713/156, 713/160, 726/10, 726/11, 726/12
Patent Citations