The present invention is related to the field of risk management, and, more specifically, to risk analysis of systems and subcomponents, including the review, messaging, infrastructure and associated processes of documents and messages related to a risk state.
Assessing risks and making decisions based on risks is common. For example, banking and investment institutions assess risks, and make risk determinations on investments, loans, and other transactions based on those assessed risks. Financial institutions, for example, may look at risks that include foreign exchange (FX) risk, reputation risk, credit risk, and operational risk in making determinations about, among other things, types, costs and approaches to entering into counterparty transactions. Insurance companies may make similar determinations to evaluate risk versus reward, and issue an insurance policy based on probability of claims and likely claim magnitude. In such instances, available and appropriate historical data may be used to support decision making for current and future actions.
Technologies have been developed to assess risks and support determinations for actions based on the assessed risks. However, processes and architecture for risk management in business processes have historically been difficult to deploy across one or a multitude of local (intra-) and external (inter-) business and technological domains. Further, in existing systems, once risk based decisions are made, various actions may be difficult to perform, including the denial of a transaction to be performed, or initiation of new transactions or transitions (e.g., to make and/or sell automatically to rebalance accounts, qualify for or obtain insurance), and/or notification warnings to appropriate personnel.
Data security controls use risk assessment with regard to data systems (e.g., networks and computers). Based on a specified policy that sets forth what is acceptable and unacceptable, and which may include attention to “Signatures”, patterns of appropriate or inappropriate actions (actions on the host/network system) may be allowed or denied. Historical information may be kept to determine, in part, what may be acceptable based on past actions. Thus, actions may be allowed or denied in the present and/or future based on what has been allowed in the past. One such implementation for data security controls is known in the art as a firewall.
Intrusion detection systems (IDS) may be used in computer systems and networks. IDSs may be used to detect and identify unauthorized use of a computer(s). Generally, an IDS looks for specific patterns, or Signatures, via logs, network traffic, file modification and other sources available, to detect malicious activity. These signatures may be identified using, for example, finite state machines, simple pattern matching, or specialized algorithms. Many IDSs may be prone to both false positive and false negative alerts. False positives occur when the IDS identifies a problem (e.g., unauthorized activity) and such a problem has not occurred. False negatives occur when an IDS does not detect a problem when a problem has occurred.
In light of the reliance on historical data and the possibility of false positives and false negatives, in order to fully protect a system, mere Signatures of negative patterns may be desirable but not sufficient. A negative Signature approach addresses the identification of that which is not allowed. The complementary approach, namely the positive Signature approach, defines specifically that which is allowed, or at least acceptable within a tolerable deviation.
Rules, also termed herein as Policies, represent those actions that may be specifically allowed and/or those actions that may be specifically denied. Rules specify the parameters within which transactions operate. A dynamic rule is one in which various responses may change over time such as in response to particular inputs, such as response changes based on various considerations.
Ideally, rules used for IDS testing would be dynamic rules. However, because, rules may be often “hard coded” as part of the binary code of a security system, rules may be typically not truly dynamic. The lack of dynamic rules causes difficulty in a variety of situations, including, for example, when the security software is updated (e.g., the executable code becomes longer and slower, and machines must be turned off to upgrade).
Further, business processes may be typically far more complex than the rules associated with intrusion against a computer system operating those business processes. For example, flows of information may come from multiple entry points, and may not arrive at centralized points. In order to hide the lack of dynamic rules, and to account for the ever-increasing complexity of business processes, network based firewalls may change an IP address via Network Address Translation, more commonly known as NAT, or via Port Address Translation, more commonly known as PAT, to hide a particular internal network configuration. However, in such a “fix”, the context of the messaging stays the same although the content seen has been modified. Such fixes may be inefficient to hide, or remedy, changes or terminations of business processes for specific transaction types, and may be likewise inefficient to vary the allowability or disallowability of specific transactions or states over time. Further, such fixes do not allow for various monitoring or control techniques to be added dynamically in a simple manner as various risks through-out an inter-enterprise distributed process may be identified and addressed.
Therefore, the need exists for a system, method, and device that efficiently monitor risk, and that allow for flexibility in modifying or updating risk policy.
USPTO Backgrounds
USPTO Backgrounds