Browse Prior Art Database

Analytics based approach for testing and enforcing enterprise-wide interaction policies

IP.com Disclosure Number: IPCOM000244848D
Publication Date: 2016-Jan-22
Document File: 3 page(s) / 58K

Publishing Venue

The IP.com Prior Art Database

Abstract

The enforcement of enterprise wide interaction policies between disparate and heterogeneous applications and application stacks.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 01 of 3

Analytics based approach for testing and enforcing enterprise-wide interaction policies

This article proposes a novel method for the enforcement of enterprise wide interactions across heterogeneous applications. In a large organisation it can be extremely challenging to monitor at a technology level all of the interactions between systems, especially where organisations have grown organically. This problem would be compounded by acquisitions or where separate departments have developed their own applications without a plan for centralised integration (e.g. legacy systems).

Key questions to be answered in an enterprise are:


Where has partially processed data gone?

Is data being exchanged in compliance with enterprise security and audit polices? For example:

Is adequate protection in place along the entire route?

Is data being exchange via prescribed mechanisms?

    There are existing business level policy monitors and enforcers in the field but nothing that works at an application level, or enforces policies based on historical data.

    A mechanism for capturing history of application interactions with files and other resources is presumed to be pre-existing and is referred to in the text as the "Capture Mechanism"

    This invention uses the historical data to dynamically define interaction rules, which then have a number of potential uses. A rule is:
a pair of application processes, and
a transport over which they are permitted to interact (e.g. network port, file path, system socket)
optionally, a time aspect - that the relationship should happen within a certain period of time - note that the interaction may be asynchronous
and given the prior invention, those applications processes form a group of related processes and there is a set of rules for application pairs within the group that define the permitted interactions. We will refer to that set of rules as an interaction policy.

    There is a further aspect to this invention which is that the database built up from a Capture Mechanism can be used to infer a set of permissive rules (whitelist) from observed behaviour. This allows an operator to avoid typing lots of individual rules, and instead say that "current behaviour is OK, check it keeps behaving like that". See the Description section below for example rules.

    Each interaction will be compared against the rule sets, and any non-compliance or irregularities could then result in one or more actions. For example:

Alert the relevant people to review the interaction, which could result in a new rule being approved or a security action being taken.

Automatically reconfigure one or more systems. For example, at a network router level so that traffic from that application now goes via a data logger for a more detailed investigation.

Network router actions, such as automatically shutting down parts of the network to prevent further spread of malware.

Notifying user exits to take specific customised actions.

The key novelties of this idea are:


Rul...