HK1111791A

HK1111791A - A system and method for risk detection, reporting and infrastructure

Info

Publication number: HK1111791A
Application number: HK08100387.3A
Authority: HK
Inventors: 亚伊尔．弗兰克尔; 查尔斯．J．米勒; 诺阿利．J．罗森克兰茨
Original assignee: 格林莱恩系统公司
Priority date: 2003-06-09
Filing date: 2004-06-08
Publication date: 2008-08-15

Description

System and method for risk detection, reporting and infrastructure

Cross Reference to Related Applications

This application claims priority from U.S. provisional patent application No. 60/476,628, filed on 9/6/2003.

Background

Technical Field

The present invention relates to the field of risk management, and more particularly to risk analysis of systems or subcomponents, including browsing, messaging, infrastructure (infrastructure), and related processing of files and messages related to risk status.

Background

Risk assessment and decision making based on risk are well known. For example, banks and investment institutions assess risk and determine the risk of investing, loans, and other transactions based on these assessments of risk. The financial institution may, for example, view risks, including FX risk, reputation risk, credit risk, and operational risk, to determine the types, costs, and manners of risk present in transactions with contractors (counties) therein. Insurance companies can make similar determinations to assess risk versus reward, and issue insurance policies based on probability of claims and the number of possible claims. In such a case, available and appropriate historical data may be used to support decisions that are helpful in current and future actions.

Techniques have been developed to assess risk and determine an action based on the risk assessment. However, processes and architectures for risk management in business processes have historically been difficult to deploy in one or more local (internal) and external (to each other) business and technology domains. Furthermore, in existing systems, after making risk-based decisions, it may be difficult to perform various actions, including refusing transaction execution or initiating new transactions or transitions (e.g., to make and/or automatically sell to reclassify accounts, qualify for insurance, or obtain insurance), and/or alerting appropriate personnel.

Data security control uses risk assessment with respect to data systems (e.g., networks and computers). Appropriate or inappropriate behavior (behavior in the host system/network system) patterns may be accepted or rejected based on what is specifically specified as acceptable, what is not (and which may also include concerns about "features (Signatures)"). Historical information may be maintained to determine what is acceptable based in part on past behavior. Thus, behavior may be allowed or denied in the current and/or future based on past allowances. One such implementation for data security control is a firewall as is known in the art.

Intrusion Detection Systems (IDS) may be used in computer systems and networks. IDS can be used to detect and identify unauthorized use of a computer. Typically, IDS look for specific patterns or features via logs, network traffic, file modifications, or other available sources to detect malicious behavior. These features may be identified using, for example, a finite state machine, simple pattern matching, or a dedicated algorithm. Many IDS tend to be false alarms and missed alarms. False alarms occur when an IDS identifies a problem (e.g., unauthorized behavior) that does not occur. And a missed alarm occurs when a problem occurs and the IDS does not detect the problem.

In terms of confidence in the historical data and false alarm probability, it is desirable, but not sufficient, to have only a negative pattern feature in order to fully protect the system. The negative characteristic approach addresses the identification of those that are not allowed. The complementary (i.e. positive characteristic) defines specifically which are allowed, or at least acceptable within a tolerable range of deviation.

Rules (Rule), also referred to herein as Policy (Policy), represent those behaviors that may be explicitly allowed and/or those that may be explicitly denied. The rules specify the parameters in which the transaction is to be performed. Dynamic rules are various rules that can change response over time (e.g., in response to a particular input), such as changing response based on various considerations.

Ideally, the rules for IDS testing are dynamic rules. However, because rules may often be "hard coded" as part of the binary encoding of the security system, these rules are typically not truly dynamic. The lack of dynamic rules creates challenges in various situations, including, for example, when updating a software system (e.g., executable code becomes longer and slower, and the machine must be shut down for upgrade).

In addition, business processes are typically far more complex than rules associated with intrusions into the computer systems operating the business processes. For example, information streams may enter from multiple entry locations and may not reach a centralized location. To hide the lack of dynamic rules and account for the increasing complexity of business processes, network-based firewalls may change the IP address through network address translation (more commonly known as NAT) or via port address translation (more commonly known as PAT) to hide detailed internal network configurations. However, in the above-mentioned "adjustment (fix)", although the content seen is modified, the context of the message is not changed. Such adjustments may not be sufficient to hide or remedy changes or terminations of business processes for a particular transaction type, and may likewise not be sufficient to change the allowance or denial of a particular transaction or state over time. Moreover, the above-described adjustments do not allow for the dynamic addition of various monitoring or control techniques in a simple manner, as various risks in distributed processing throughout the interior of an enterprise may be identified and addressed.

Therefore, there is a need for a system, method, and apparatus that can effectively monitor risk and allow flexible modification or upgrade of risk policies.

Disclosure of Invention

The present invention comprises a method, system and arrangement for monitoring risks associated with at least one business process, which may include: evaluating at least one of a plurality of file instances according to a plurality of risk categories, wherein each of the file instances includes a plurality of file values associated therewith; executing the plurality of risk categories in accordance with at least one acceptable risk policy approved for the at least one business process; and qualifying at least one of the plurality of documents based on approval rating of at least one document in at least one risk category.

The present invention thus provides a system, method and apparatus that can effectively monitor risk and allow flexible modification or upgrade of risk policies.

Brief description of the drawings

An understanding of the present invention may be facilitated by the following detailed description taken in conjunction with the accompanying drawings (in which like reference numerals represent like parts), in which:

FIG. 1 is a diagram showing a mapping between files (documents), risk categories, and policies;

FIG. 2 is a diagram illustrating multiple risk policies against multiple file instances (Document instances);

FIG. 3 is a diagram showing the relationship between files, policies, and qualifications;

FIG. 4 is a flow diagram illustrating obtaining a file instance value from a database to add to a field (value);

fig. 5 is a diagram showing RDS components;

FIG. 6 is a diagram illustrating secure transmission of templates;

FIG. 7 is a diagram illustrating policy enforcement from different organizations;

FIG. 8 is a diagram showing an example or template of a secure transmission from RDS;

FIG. 9 is a diagram showing user access in relation to a trust manager; and

fig. 10 is a diagram showing a plurality of files combined into one using the method in fig. 4.

Detailed description of the invention

It is to be understood that the figures and descriptions of the present invention have been simplified to illustrate elements that are relevant for a clear understanding of the present invention, while eliminating, for purposes of clarity, other elements found in typical information devices, apparatus, systems, and methods. Those of ordinary skill in the art will recognize that other elements are desirable and/or required in order to implement the present invention. However, since these elements are well known in the art and do not contribute much to a better understanding of the present invention, they will not be discussed herein. The present disclosure is directed primarily to variations and modifications of the applications, networks, systems and methods disclosed herein and known or obvious to those of skill in the art. In addition, the present invention is described throughout this document, however, one skilled in the art will recognize in light of the present disclosure that the present invention may be beneficially utilized in any number of commercial transactions and processes.

FIG. 1 is a flow chart illustrating the evaluation of a file 101 comprising a plurality of values 104 according to a risk policy 107. The file 101 may be provided into the system shown via web access (web access), web service (web service), gateway, and physical file converted to electronic format, for example by optical character recognition (ORC) or scanning, or any similar method known to those skilled in the art. The invention is not limited by the manner in which the file is provided or converted to electronic format.

File 101, as used herein, may be or represent a value that is important to a business system or process. The values may be fields in a record, as is well known in the art. The documents 101 may be a subset or superset of one or more originally defined or structured based written documents, or may be a subset or superset of established or structured data sources. These definition-based data sources or written documents may contain values having values obtained from other sources. References to file 101 include, but are not limited to, references to all fields in the file.

A file may be defined into the RDS system and its associated facilities. For example, a scripting language or a technique to implement a GUI (graphical user interface) or other presentation method may be used. According to one aspect of the invention, an extensible language, such as XML [ XML ], may be used. The XML used may be based on the "survey example" of Allen Wagner: net Web page Form Design (Web Sample in asp.ne) ".

For example, XML encoding may include:

XML-A

</Question>

</Question>

</Question>

</Question>

</Question>

</Document>

according to this aspect of the invention, a file 101 (e.g., a survey) may be specified. The description of this document may produce a data definition, although it will be apparent to those skilled in the art that other methods may be used to incorporate the pre-existing database definition. The data source type may be a web-based input that stores information in the form of appropriate records from a database, for example, masterdb bldsecurity with a home key, in this example the web address that may be set is www.xxx.com/surfey.

The question may be numbered using the ID and displayed based on whether the "Visible" flag is set to "Yes" as shown in the previous example. The question to be displayed is provided in the form of "Text (Text)", and the Type of the response is located in "Type (Type)", as shown in this embodiment. Types may include, but are not limited to, for example, "characters", "numbers", "freeform" (arbitrary format), "multiplication choices", "Boolean (Boolean), etc. Other types will be apparent to those skilled in the art and may be effective whether the input type is correct or incorrect.

In the above-described embodiments, the "Answer (Answer)" has a plurality of purposes, and typically may represent an input of the submitter. The submitter may be a human, process, automatic, manual, electronic, or mechanical input, to name a non-limiting example.

"Tag (Tag)" may be used as the variable name for the question. In the above embodiment, the country value CountryValue (defined as ID ═ 1) in the calculation field with ID equal to 2 browses the risk value riskvvalue in the country risk table CountryRiskTable indexed with CountryValue. The answer (answer) to the question (query) in this embodiment, which is not visible during the input process in this embodiment, is a national risk value multiplied by four (4).

The above embodiments illustrate web-based input. These processes may be provided using other forms of input, as will be apparent to those of ordinary skill in the art. For example, instead of displaying the question, it may take the form of an electronic query according to a digital format (e.g. a database), such as a query for access information. The input in response to the question may be, for example, any transmitted electronic message representing information in a data store (e.g., a database, directory, or plain text). In this case, the data description may specify the manner in which the value to be input is obtained. For example, the data description may specify that the value is a particular field in a database table, or the first X bits of the data value starting with the Y-th bit. In the case of "visible ═ No'", the input in response to the question may be a calculated value, rather than a human input.

Fig. 4 is a schematic use showing "Tag (Tag)" and "calculate (computer)". Likewise, file 101 may include a series of values. For simplicity, in this embodiment, the values 1 through 4 (the portion above line 402) may be values that are visible to the user, while the remaining values below line 402 are not visible to the user. In this embodiment, the value n may be a copy 403 of the value1, as shown. The value 5 may be obtained 405 from a local store, such as database 406. The values 5 and 6 may both be identified by TAGs, which may be for illustrative purposes, and may be denoted as TAG _ V5 (e.g., < Answer TAG ═ TAG _ V5 >) and TAG _ V6, respectively. The more complex calculation 404 may be any function f that is controllable by the security system and capable of performing calculations and using both visible and invisible values. The result of function f may be present in the required (requested) or requested (requested) location, e.g., in this embodiment, the result is placed to a value of 6. This may also be encoded like < answercomputer ═ TAG _ V5 ═ TAG _ V6 ″ >, such as shown in the above embodiments.

Returning to FIG. 1, a Risk Category (Risk Category)102 may classify a Risk into various groupings that meet certain target requirements and may conform to the allowable Risk of one or more business processes. As an example, in [ BS 7799], the features of information security are classified into confidentiality (C), integrity (I), and availability (a). It is common in risk management applications that the system can be evaluated individually based on various unique or applicable criteria, and that the evaluations can be analyzed simultaneously. In the foregoing BS 7799 example, the necessary controls to meet the various criteria may be different and, in fact, may be conflicting in some cases when using levels of confidentiality, integrity and availability. For example, in container transportation it is expected that an assessment of the process of controlling the loading of cargo and the containment of the cargo into a container will be assessed according to separate and distinct, and possibly conflicting, risk-related criteria.

[57] The risk categories referenced in fig. 1 may be specified, for example, in the form of XML or a similar scheme, but are not limited thereto. For example, XML encoding for such risk classification may include:

</RiskCategories>

however, the risk category may be a risk aggregation calculation of some risk attributes, rather than a specific risk aspect of some risk attributes. Thus, these aggregations may be one-to-one 106, many-to-one 109, or one-to-many 105. Also, the exemplary XML-A discussed above may be modified to:

XML-B

</Answer}

</Answer>

</Question>

in XML-B, if question 3 has a Yes response, it is incremented by 50 for RiskCat1 and by 20 for RiskCat 2. Note that addition, subtraction, multiplication, division, multiplication by a constant or coefficient, or other calculation function may be used, as shown in Answer ID ═ 2 ". Further, the calculation may be performed hierarchically. For example, if answer A is yes, multiply by 3, if the result is greater than 50, query B, if the response is answer C, divide by 3. Further, data may be obtained from one or more or other data sources in accordance with the performance of the above-described calculations. For example, the function F may be performed on an input value (e.g., "Add (thisInput 5)"), and a response (i.e., thisInput) may be multiplied by 5, with the result being added to the appropriate risk category. The functions may be complex and may include other programming features, for example, using Java or other high-level languages in conjunction with program scripts. The program script or calculation may specify a tag name in a function, such as the "CountryValue" described in XML-A to represent a value, or as an index to a value (e.g., a value in a database or a web location table) lookup, but is not so limited.

The risk categories may be analyzed according to one or more risk policies 107. Thus, the file 101 (and more specifically the values in the file 101) may be rated against the risk policy according to one or more requested risk policies.

In the following embodiments, a number of rules may be applied, wherein an "Action" is performed when a "criterion" is assessed, i.e. a script returning true or false is assessed, i.e. a script in a proprietary or well-known language (e.g. Basic, Visual Basic, C, C + +, Java, Perl). As will be apparent to those skilled in the art, the following embodiments are not limited to a particular language and may additionally be performed, for example, in XML.

Name:<policy name>

Rule:<label>

Criteria:<conditional script>

Action:<script>

Policy-Rule:

PolicyName:SilverBuilding

Rule:RequireSupervisor

Criteria:((Riskoatl＞50)or(Riskcat2＞1000))and(riskcat3＞5)

Action:Require(″Supervisor″，RED)；exit()

Rule:EmailCommerce

Criteria:((Riskcatl＞20)or(Riskcat2＞100))

Action:Notification(email，″warning@commerce.com″，″ReviewCompany X Warning logs″)

Rule:Accept

Criteria:Null

Action:Accept(″1 June 2004″)

The above examples are performed from top to bottom, and as an example, some functions to be noted include, but are not limited to:

exit (): exit is not tested against any additional rules;

required (< Group >, < FLAG >, < effective date >): the receipt of a file requests acceptance by some of the people in the Group < Group >. Provide the FLAG value (e.g., RED status) to the user to help the user understand the severity of the problem, and when the user in the Group accepts the file, < effective date > states the effective date on which the user accepted the file (i.e., how long the acceptance was effective);

notification (< type >, < user name >, < subject >, < Body >): a notification is sent to the < user name > with Subject < Subject > and Body < Body >. Types of notifications include, but are not limited to, email, calendar, fax, automatic telephone calls, and other forms of notification systems. Emergency notifications may call a government agency (e.g., "'911' call") as a primary response action, e.g., by law enforcement, transportation, commerce, military, or other agencies;

schedule (< date/Time >, < actions script >): this determines the Time of the action script to be executed at a particular date and Time (i.e., the < date/Time > field). For example, after a certain time, a transaction may be initiated or a notification may be set;

accept (< date >): accepting instances according to the policy includes a date in the date field and is valid before the date;

store (< value2>, < location1>, < value2>, < location2>, # etc.): store the value1 to location1, store the value2 to location2, and so on. The location may be, for example, a field in a database. May for example be local storage or storage between or within each other (see fig. 5);

PushPolicy (< policy description >: policy can be pushed into the current system or out to other systems, for example, when certain conditions are met, the policy is caused to change RDS instances for other RDS processing;

CreateTransaction (< transaction type >, < recipient >, < field >, < value1>, >): similar to PushPolicy, the create-ena transaction transfers the transaction file to the recipient (recipient) who constitutes the transaction type. The data section for the transaction places a value of 1 in field 1.

As will be apparent to those skilled in the art in light of the disclosure herein, specialized scripts and other forms of programming languages may likewise be used in the present invention to implement deeper and more complex standard and rule encodings. Such additional complexity may include, for example, loop structures (including outside-in and inside-out loops), access to external data (including external proprietary scripts), initial values, and statements of other complex conditions.

The policy template may provide suggestions, changes, modifications, or generally acceptable practices to allow for risk policies to be generated, or to allow for data to be passed as input to the risk policies. For example, policy data takes a number of forms, as will be apparent to those skilled in the art, and policy templates may provide for the transformation of one form to another. The following is an exemplary "trigger policy" policy template shown using XML:

Trigger-Policy

</Event>

</Event>

</Event>

</TriggerPolicy>

for example, in the exemplary "building Security" file (see embodiments XML-A and XML-B above), the trigger policy TriggerPolicy template first checks if the country value matches "Korea". If there is a match, the strategies GoldBuildingAsia and SilverBuilding can be tested against this document. If not, the policies GoldBuilding and SilverBuildingAsia are tested against the file.

A Policy template (e.g., Trigger Policy Trigger-Policy) may also establish or incorporate other file Instance Document-instances. For example:

<Event ID＝″1″Document＝″BuildingSecurity″

Criteria＝″CountryValue＝Korea″>

</Event>

<Event ID＝″2″Document＝″KoreaBuildingForm″

Criteria＝″CountryValue＝″Korea″>

in this embodiment, the build security file is converted to a new file, korea building form. The new format korea building form instance is run through the trigger policy described above. The mapping from BuidlingSecurity to KoreaBuildingForm can be implemented in various ways, as will be apparent to those skilled in the art. The mapping from tag value to tag value may be an exemplary method of converting information using a policy template. For example, the country value can exist in two forms, and policy template mapping is performed one-to-one.

As used herein, an instance of a file 101 may be an approved instance or an unapproved instance. A file instance may be an approved file if one of the following two conditions holds:

(1) accept () is executed;

(2) require () is executed, including that the group member specified in the Require () approved the file.

The calculation 108 may describe one embodiment of calculating a risk category. The method of this calculation may be complex, entity rule, or general and non-entity rule, for example. For simplicity, in this embodiment, the exemplary operations may have the form: f (g (Value), h (Value, Value'))) Risk Cat Value, where F is the mathematical sum of the input values. In this embodiment, g and h may be various algebraic functions, e.g., if (value) then return 50, otherwise return 100. Also, a multiplication selection may be generated. For example, the calculation may return (value constant), where the constant is a predetermined integer. Thus, the values g and h may be or require one or more inputs, may be external, such as data input in response to a question, or internal, such as applying a constant to data obtained in performing the calculation 108 of h.

FIG. 2 is a flow diagram illustrating the application of multiple risk policies. In this embodiment, the file instance 202 for the file 101 represents a "filled-out form" for a particular input instance. The descriptive file instance 202 is weighted 205 by one or more Risk categories, where the Risk Cat values x, y represent values for the file y according to the Risk category y. Thus, according to a specific exemplary risk policy 201, a file instance 202 may be approved, for example, via an approval function Accept () or via a function Require () after a user in a Group accepts or rejects the instance. The file instance 202 is approved according to more than one policy 203, 204 (e.g., in a risk policy hierarchy applied to the given file 101) prior to final approval.

In the exemplary embodiment in FIG. 2, risk policy 203 describes file instances that are accepted according to only one policy, while risk policy 204 represents file instances that are approved according to more than one policy.

It should be noted that in an XML-B embodiment, the RiskCat value may be file-dependent, and the same file instance may not generate multiple RiskCat values, e.g., those associated with different policies. However, by considering the risk categories as having different values according to the respective policies, the same file instance can be evaluated according to two different policies. For example, a company may have an internal confidentiality policy and an external confidentiality policy. These strategies may be: any confidential digital data that leaves the organization must be encrypted during transmission, and no encryption is required when the data is transmitted internally. Thus, the file may specify whether data leaving the internal server is to be encrypted. Thus, for internal policies, the "confidentiality" risk category does not typically affect the transfer from an internal server to other internal servers. However, if the attempted transmission is external, the answer "NO (NO)" to the encryption of the file would affect the risk for the "confidentiality" policy. Thus, in this embodiment, the confidentiality risk category score (score) has different results according to different policies.

This restriction in the exemplary XML-B simplifies the evaluation by allowing a browser to understand the risk category to have only one meaning. This limitation on the risk category is only an example and need not be used in the present invention. In this exemplary manner, risk value evaluation may be limited to the values specified in the Policy Rule Policy-Rule. The risk policy reference may be introduced into XML-B as follows:

the file instance may have approval for the policy. Similarly, policies and qualifications (qualifications) may be linked. FIG. 3 is a flow diagram illustrating a relationship between policies and qualifications. File set 305 may be associated with policy or policy set 301 via relationship 306. Qualifications 302 may be associated with one or more policy instances 301. For example, if a file instance 101 or a set of file instances 305 is approved according to policy 1, then qualification 1302 and qualification 2 may be obtained. Qualification may require more than one policy approval 304. In this embodiment, the file instance should be eligible for approval for policy 2 and policy m 3. Thus, there is a hierarchy between policies and qualifications. The qualifications may also be ranked relative to other qualifications and policies, as described above with respect to the ranking features for policies. The qualifications may be encoded, for example using XML, as follows:

QUAL-Template

</Rules ID＝″1″>

</Rules></QUAL>

</Rules>

</Rules>

</Rules>

</QUAL>

</RiskCategories>

in the above embodiments, the qualification "GoldSeal" may only be obtained if the risk categories GoldPolicyphysical and GoldPolicyProcesses are available. However, the qualification "SilverSeal" is obtained if the risk category GolPolicyphysical or GolPolicyphysical is obtained and the SilverPolicyProcesses or SilverPolicyphysical are similarly obtained, rather than obtaining both the risk categories GolPolicyProcesses and GolPolicyphysical.

Fig. 10 simplifies the exemplary description in fig. 4. As shown, a file instance may be associated with multiple entered "files" entered at different times. For example, file a (a value below line 1002) may be received at time 0 and stored in database 1004. File B (value above line 1002) may be received at time 1. File a may be placed in file instance 1003.

The policy evaluation described hereinbefore may be part of a Risk Detection System (RDS). RDS may be present in a larger architecture as shown in figure 5. The RDS may evaluate the policy against the file, maintain storage to evaluate the policy 507, and determine eligibility. The RDS may be linked to one or more aggregators (aggregators) 506. The aggregator may include an RDS that obtains information from multiple RDS's and supplies policies and files to other RDS's. If two files are present in both RDSs, the aggregator may include a moderator (reconciler), such as internal global database 502. The aggregator may dynamically generate or apply policies based in part on the history. For example, inputting multiple inputs to the aggregator from a discreet (discreet) RDS instance indicates that it is extremely at risk in the country (county risk), then the aggregator may modify the policy in various RDS to control this risk. For example, a post-modified file representing a transaction may not be accepted by the modified policy because the acceptable threshold for national risk may have been reset high, and thus a previously acceptable file score may not be accepted.

When the RDS and the aggregator can receive information from an internal global database, the information can be obtained from the mutual global database 502. The mutual global database may be located outside the organization. For example, customs and border protection agencies (external organizations) may have "checklists" (watch lists) of individuals or entities with whom commercial transactions are not welcomed, as well as control (e.g., operational needs) of particular kinds of goods. The U.S. state department maintains a list of known terrorists, and other government agencies and organizations, regulatory and standards bodies, partners, and various other providers also maintain data useful for RDS. Some companies may also provide statistical and other data that can be used to dynamically and efficiently (pro-active) generate policies. Information can also be distributed to the system and trust levels established.

Trust manager 503 represents a secure Trust system, such as Public Key Infrastructure (PKI) [ X500, X509, RFC3280] or Kerberos [ Neuman ] or other means [ Menezes ] as is well known in the art. Trust managers may be managed by mutual or internal management authorities. A regulatory agency may be any individual or group that specifies approval for communications within the infrastructure, and what rights these approved portions of communications have. The trust manager may make security adjustments (security scaleable). However, the infrastructure in FIG. 5 need not use a trust manager, and security can be established directly, such as using physical exchange of keys, or by other methods known in the art.

An Entry point (Entry Points)501 may be a source in which data is received. The RDS may receive data from the entry point directly or in a combined form. The entry point may be a probe in an intrusion detection system. The entry point may reduce costs by only receiving data and placing the data for use in RDS or a mutual or internal global database for RDS or aggregators. The entry point may be specified and may be used to offload workload from the RDS.

For example, XML-B described above includes policy enforcement, although the entry point may accomplish some level of file policy browsing. This reduces the risk of foreign persons discerning the RDS strategy. The entry point may also establish trust either directly or via the trust manager 503.

FIG. 6 is a flow diagram illustrating the secure transmission of a policy template, policy rule, or policy template for a qualification or document (e.g., XML-A or XML-B). The template 605 may be transmitted 602, for example. The sender may be, for example, an aggregator, RDS or a regulatory body. The trust manager 604 may establish a trust 603 between the RDS and the sender. As an example, if the trust manager is a PKI and the message sent by the sender is signed, the RDS may verify the signature based on a certificate (certificate). The RDS (which may also be an aggregator) receives the validated template and may incorporate the policy template into later evaluation.

Policy templates may be generated by different organizations and members in the infrastructure. The priority (i.e., order) of the evaluations may be specified as shown in fig. 7. In the above-described embodiment of policy rule application, the above-described policy is evaluated "top-down". The policy 702 may be composed of sub-policies. For example, policy 702 may be executed before policy 703. Some agencies may be set higher, for example, where government agencies may override company 703 or locally defined entities or individuals 704. An organization may also specify priorities in its policy templates. For example,

Rule:<label>

Priority:<High＝1 to Low＝10>

Criteria:<conditional script>

Action:<script>

in this embodiment, the administration mechanism may set multiple templates into the RDS and may give them a higher priority than other sources 702.

Various organizations may be allowed access to the RDS. Access control may restrict access to, or modification of, information depending on who the user is and how the user identifies. Fig. 9 shows that user 905 has access 906. The users 905 may belong to each other's authorities or internal authorities 902. Trust relationship 903 illustrates the relationship between trust manager 904 and authority 902, and trust relationship 907 between trust manager 904 and RDS 901. Trust can be placed between a trust manager and a user through mechanisms developed for computer security. Examples of this include a Registration Agent (Registration Agent) within the PKI that exercises rights on behalf of an authority to authenticate users, and processes certificates of user public keys. A user may have special rights to access RDS based on trust relationships established through the trust manager 904, and rights to access the aggregator or global database based on rights provided to the user through some access control mechanism. Government agencies or partners may have limited or extended access while internal users may have different access rights. For example, government agencies may be automatically granted access to certain otherwise restricted data and data stores on the condition that a particular event occurs and appropriate credentials are presented, including providing evidence of online identity or role.

One RDS may communicate with another RDS to provide policy instances or policy templates, files and/or qualifications. RDS 1801 may send the object to RDS 2802 or global database data 806, 803, 804. The transmission 803 or 804 may be verified, e.g., digitally signed, or transmitted via a secure channel (e.g., via SSL, VPN, IPSEC, etc.), or transmitted via some other secure means known to those of ordinary skill in the art. Security may be used or established by the trust manager via trust relationship 805 to sends 803 and 804. Relationship 805 may represent a credential relationship by, for example, a trust manager that functions as a Certificate Authority (CA) in a Public Key Infrastructure (PKI).

Figure 8 shows a push method where RDS pushes out various instances and reports in a secure way, e.g. signed with a public key (authenticated by the trust manager as CA). In practice RDS does not require a push approach but represents information locally in response to pulled (pull) information. That is, it may provide a pull rather than a push. Accordingly, the RDS applications 802, 806 may request and receive data 801 locally.

Data represented externally to the RDS or similarly externally by a global database or other data store (e.g., documents, directories, etc.) is useful to users. In fig. 8, several types of information are shown. Reports may be audit logs, risks of aggregation, anomalous findings, and other events that include auditable conditions. The report may allow the outsider to view the process being used, although special audit level access rights may be required. The qualification template, policy template or file template may make the RDS a sending template for external browsing, or the template may be executed by other RDS.

RDS may support various roles. These roles may include: the RDS manager: perform basic system management such as, but not limited to, providing access to users (i.e., ID management), communities, and outside members; monitoring the performance of the system; ensuring that backups are performed, and other basic tasks that are not typically related to the risk that the system is monitoring; the template builder: establishing various templates used in the application, including strategy, file and qualification templates;

the data entrant: the data is submitted to the system. There may be different kinds of data entries with different rights, e.g. some entries may be allowed to fill in some forms but not others, or only forms for a particular group;

a risk manager: actions that specify policy tolerances for risk categories and qualifications, how to determine risk categories, and to execute policies against different categories;

the file approver: upon a request to accept a file being set, a Require () action is set that approves the file instance against a policy for a defined group or groups of instances or instances;

and (4) supervising the approvers: approvers of a particular group. Some organizations may request document approval from approvers as well as supervisors; and

and (3) an auditor: have read-only access to view the actions of other people.

The computer system may perform (at least in part) the role. For example, the RDS and aggregator may also establish a template, and data entry may be the entry point. The risk manager may be a special type of template builder, such as RDS and aggregator. They may browse past actions to determine a policy for future actions.

In an embodiment of intermodal container transport of the present invention, the defined categories may include infrastructure assets, transportation assets, and shipped items. Infrastructure assets are associated with movement from point to point (including from loading point to unloading point) for intermodal containers. Examples of infrastructure assets include computer systems, information handling systems, terminals of warehouses and ports. Infrastructure assets are not limited to physical entities or transactions but may also be legal entities. For example, a company that owns and/or manages a warehouse may be classified as an infrastructure asset. The transport asset may be the actual moving asset of the item that is directly used for shipment, but is not part of the shipment. For example, a train engine, container or other ship or aircraft used for the specific purpose of moving the shipped items may be a transportation asset. If it is difficult to determine whether an asset is an infrastructure asset or a transport asset, it can be treated as both assets. The items shipped may be the actual transported goods, as well as the particular assets and documents used in or associated with the movement of those goods. This category may include, but is not limited to, containers that contain physical shipments, seals that may be barriers or indicate (manually or electronically) modification of shipments, and documents associated with particular shipments, such as shipping instructions, bills of lading, etc.

Surveys, questionnaires, and/or other mechanisms can be used to identify infrastructure assets and other aspects of those infrastructure assets, such as people responsible for the infrastructure assets in some way. An infrastructure asset may have sub-parts, systems, or components. For example, a building may be an infrastructure asset. However, storage facilities located within a building (but not controlled by different physical, logical or legal persons) may be considered subcomponents of a building and still be classified as infrastructure assets. Based on the type of device, the infrastructure assets may be evaluated according to various criteria including, but not limited to:

control over physical security (e.g., type of lock, height of fence, number of security guards, etc.);

control over employee security (e.g., background detection, employment engagement, etc.);

control over data systems (e.g., confidentiality, integrity, availability, etc.);

control of history (e.g., determining whether previous history of fixed assets was properly processed);

insurance (e.g., type of insurance and its limitations);

previous legal and/or administrative handling of the asset (e.g., whether there is or is legitimate or administrative behavior, etc. for the asset, judgments, commands, arbitration, etc.);

contract control (e.g., contract terms for infrastructure assets, their workers or plants, etc.), etc.;

vendor controls (e.g., who they are or how they are evaluated, etc.);

record keeping and audit control (e.g., method of record keeping, type of audit control, etc.); and

procedures and practices (e.g., methods of accomplishing tasks).

These criteria or their synthesis or decomposition can be considered as risk categories. Additional risk categories may be included when desired. The characteristics of the asset being evaluated may determine the risk category with which it is evaluated, as well as the selection or weighting of the data values used to calculate the risk category value. Thus, for example, a problem constituting a physical security risk category for a low value warehouse is different from a problem constituting the same risk category for a high value data center.

The use of assets can be added in a number of ways via RDS. For example, a web system may be used to join assets, or other applications may notify the RDS of new assets. There may be a dedicated RDS for one or more types of assets to join. They may provide data relating to the asset to other RDS systems. The new assets may be saved to other databases (e.g., vendor databases). The fixed asset information may come from aggregators, other RDS, mutual or internal data stores, or other sources. Information may also be obtained from field work, surveys, government contracts, or other data, whether external or internal.

After the resources are defined, the evaluation can be made based on an appropriate strategy. The introduction of the new asset may be a triggering event, such as a new vendor transaction, such as a web-based item, and the triggering event may result in an evaluation in accordance with a trigger policy. Such an assessment may result in a variety of actions as part of the strategy, for example a) it may request that certain surveys be performed (e.g., surveys of physical buildings) and thus send notifications to appropriate people to notify them that a new vendor has started and they must complete a survey, b) observations of internal and external data may be initiated (e.g., detecting the particulars of the denied party, detecting any legal/administrative actions, verifying insurance policies, financial status, etc.), such as an assessment of an external party (e.g., initiating a purchase of a third party for field investigation or other analysis). As more information is received, the trigger policy may test it according to the policy. As more information is received, the policy may satisfy some cases and may qualify the asset in the satisfied cases. In addition, asset eligibility (which may be traffic, infrastructure or freight items, and the shipment itself) is a prerequisite for other events to occur, such as the supply chain in which the shipment is registered; the carrier is based on a direct reservation from a shipper (shipper) or a scheduled carrier shipment received, for example, from a general carrier that is not operating on a ship; the price of the shipment; number of times of response delivery; cargo shippers or other assets used to carry, handle, package, or store cargo.

Approvals similar to qualifications according to policy may be short-lived. For example, if there is a material that does not significantly interfere with or lack the desired control, short term approval can be provided. For example, the physical insurance policy for a building may change. Buildings that meet certain secret criteria may only accept locks according to previous physical security policies for up to a month. After one month, the short-term approval is no longer valid.

The policy can be specified in a hierarchical nature, as described above. For example, the category "gold seal" (i.e., high level in the hierarchy) does not require some freight detection that is required for lower levels. Similarly, this may be done according to qualifications. It can be seen that for people who meet certain "gold seal" criteria, assets can be classified according to valuation in the same manner. A company that is itself an "infrastructure asset" may own freight traffic. Naturally, for many exemplary assets, there may be an "owned" relationship in one aspect and an "owned" relationship in another aspect. Assets may have relationships that relate to risk assessment for any particular transaction. These one-to-one, one-to-many, and/or many-to-many relationships can be used to assess risk. As an example, a port may be evaluated against physical security, for example. The relationship may be shown as the physical security for the port is "managed" by other entities. It is also possible to evaluate the management by the entity, the risk of which is properly calculated into the risk of the port.

Associations of relationships that may be used to affect risk include: is owned; a lessor; a lessee; a consumer; a vendor; a supplier; a manager; a controller; an insurer; an auditor; an evaluator; the person to be tested; an auditor; an operator; processing; a financial institution; a underwriter; a guarantor; safety; relationships (when the relationship type is not specified in the system); and the opposite side described above (e.g., the opposite side owned is the owner).

The items of freight may include the goods being shipped, their packaging, intermodal containers (within which the goods are handled), and various security, visual, or status devices for the cargo containers, as well as shipments associated with documents or messages (e.g., bills for loading the goods or prior notice of shipment). The shipped items may be part of an assessment being made in a risk management assessment of a particular shipment (particularly the containers contained therein). Areas and pathways of risk or risk information repositories include:

risk situations in all or some of the various aspects (e.g., physical, logical, financial, etc.) of infrastructure assets or transportation assets (including all supply chain metering programs, determining bin coordinates for workers and commercial property) can be used to collect, manufacture, package, load, seal, move shipped items, etc.;

masking mutual or internal data stores for information about infrastructure assets, their ownership relationships, or other materials (related to relationships that can affect risk);

the conditions for loading and sealing the container include: detecting, loading and various types of file-forming programs, using independent checking intermediaries, physical access control, logical protection, etc.;

the positive and negative rule sets for containers relate to travel duration, weight, time, location, status, etc., among other possible parameters, as well as other related risk management rules and exception procedures, such as:

no more than a certain period of time;

not shorter than a certain period of time;

no more than a particular measured distance;

a distance at least equal to the particular measurement;

various desired routes, waterways or highways;

a prohibited location, including a determined location tracked by GPS;

an expected location, including a determined location tracked by GPS;

file exceptions, such as an incorrect origin or destination based on origin or season;

door opening or light content (light content) rules for sensors or seals;

abnormal nuclear, biological or chemical substances;

an abnormal temperature change;

anomalous gases such as C02;

anomaly analysis for status messages related to shipments or containers (which may be provided in supply chain events); and

anomaly analysis for documents (other than status messages) related to shipment.

It should be noted that the history and feature templates of various occurrences and the reporting function may be separate services in the present invention. That is, knowing some aspect of the system may be approval by some approval intermediary, or the individual may be authenticated. As an example, vendors may approve against a policy by an agency (establishment). Such approval may be incorporated into the RDS. The approved event may be signed, or other security controls placed on it. A company may purchase an approval event, e.g., an authority may sell approval to a third party as capital, or may be allowed to sell the approval event or some aspect thereof.

In a specific example description describing the present invention as shown in fig. 11, a file is set to have a value therein. These values may be scored according to one or more risk policies, which may be located in one or more risk policy templates. Risk analysis may be performed according to a plurality of scoring mechanisms. For example, a financial institution may score documents and their values in one way, while an insurance institution may score the same documents and their values in a different way.

In such exemplary embodiments, global supply chain risk may be evaluated. For example, a warehouse in a supply chain may include an expanded amount of files (having a large number of values). These files may be classified according to the risk for each category of file. For example, warehouse security may form one category and power supply may form another category. Risk analysis may be performed based on the value-versus-risk policy. For example, a file for warehouse security may include the numerical "camera aim: is (cameras present: yes) ". Obviously, these numerical factors may sufficiently affect the application of the warehouse security policy, as well as whether the application of the risk policy based on these values affects security to pass or fail, or to meet certain qualifications.

Likewise, the exemplary links in the supply chain may be scored for each category as well as for all categories. The risk analysis described above, and all risk analyses, may follow one or more templates. For example, if the above-mentioned warehouse exists in the first country where the crime rate is high, the total score of 80, or the safe score of 85 is not acceptable. However, if the warehouse is present in a second country with a low crime rate, a total score of 70, or a safety score of 75, may be considered acceptable.

In addition, or as an alternative, other processes may be monitored by using the present invention. For example, the transaction flow may be scored by individual transaction parties or by the overall transaction. The process of scoring may include, for example, purchase orders, invoicing, or container storage. The process of scoring may likewise refer to, for example, any business process, including manual, electronic, or a combination of manual and electronic, and may be applied to all or selected portions of any document or stream. Any or all of the applications of the present invention may be reported. The report may be in electronic or paper form, for example.

Given the teachings herein, and the references cited herein and incorporated herein by reference, one skilled in the art can implement the present invention using hardware and software techniques that are already available. In addition, various computer aspects, languages, or scripting languages including XML may be incorporated into the present invention.

Those skilled in the art will recognize that many modifications and variations may be made to the present invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

1. A method for monitoring risks associated with at least one business process, comprising:

evaluating at least one of a plurality of file instances according to a plurality of risk categories, wherein each of the file instances includes a plurality of file values associated therewith;

executing the plurality of risk categories in accordance with at least one acceptable risk policy approved for the at least one business process; and

qualifying at least one of the plurality of documents based on an approval rating of the at least one document in at least one risk category.

2. The method of claim 1, wherein the risk is associated with an infrastructure.

3. The method of claim 1, wherein the evaluating comprises: at least one member of the community specified in the at least one acceptable risk policy performs the necessary intervention.

4. The method of claim 3, wherein the performing comprises notifying the at least one member at least once.

5. The method of claim 1, wherein the qualifying step comprises allowing the at least one document to enter the business process.

6. The method of claim 1, wherein the file comprises a survey.

7. The method of claim 1, wherein the file comprises a superset of the second plurality of files.

8. The method of claim 1, wherein the risk policy is hierarchical.

9. The method of claim 1, wherein the qualification is hierarchical.

10. The method of claim 1, wherein the file specifies at least one asset in the business process.

11. The method of claim 10, wherein the evaluating comprises: evaluating at least one of physical security control, employee security control, data system control, history control, insurance, behavior by asset, contract control, vendor control, record keeping, and audit control.

12. The method of claim 11, wherein the audit control includes authorization.

13. The method of claim 11, wherein the audit control comprises a denial.

14. The method of claim 11, wherein the audit control comprises physical oversight.

15. The method of claim 1, wherein the qualifying does not allow the at least one file to be used in the business process.

16. A method for monitoring risks associated with at least one business process, comprising:

disqualifying the at least one of the plurality of documents based on the approval level of the at least one document in the at least one risk category.

17. The method of claim 16, wherein the risk is associated with an infrastructure.

18. The method of claim 16, wherein the evaluating comprises: at least one member of the community specified in the at least one acceptable risk policy performs the necessary intervention.

19. The method of claim 16, wherein said qualifying comprises admitting said at least one document to said business process.

20. The method of claim 16, wherein the risk policy is hierarchical.

21. The method of claim 16, wherein the qualification is hierarchical.