|Publication number||US8214832 B2|
|Application number||US 11/857,471|
|Publication date||Jul 3, 2012|
|Filing date||Sep 19, 2007|
|Priority date||Sep 19, 2007|
|Also published as||US20090077555|
|Publication number||11857471, 857471, US 8214832 B2, US 8214832B2, US-B2-8214832, US8214832 B2, US8214832B2|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (14), Non-Patent Citations (1), Classifications (5), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This disclosure relates generally to separation of duties and, more specifically to techniques for implementing separation of duties using prime numbers.
2. Related Art
Today, security policies of many transactions, e.g., business transactions, require the enforcement of separation of duties (SOD), which in a basic form dictates that multiple tasks contained in a sensitive transaction each be performed by different entities. The main concept of SOD is to distribute the responsibility for a transaction among several different entities such that no single entity controls two or more tasks of the transaction. In this manner, collusion of two or more entities is required to commit deliberate fraud with respect to a transaction. As one example, SOD is employed in handling bank safe deposit boxes in that a bank has required use of two distinct keys to gain access to a safe deposit box. In this case, a first distinct key is maintained by a bank employee and a second distinct key is maintained by a bank customer that has rented the safe deposit box.
As another example, it is common for a company, e.g., a financial institution, to implement policies that prohibit a single employee from preparing and authorizing a check, e.g., an electronic check. In this case, a first employee (e.g., an accounts payable clerk) may prepare the check and a second employee (e.g., a manager) may authorize the check. While SOD is desirable in combating fraud in various transactions, there is no known efficient approach to implement SOD in computer systems that execute transactions. A typical SOD approach has tracked transaction tasks and the entities to which the tasks have been assigned. With this approach, when an entity has tried to perform a task associated with a transaction, a computer system has checked whether the entity has performed other tasks associated with the same transaction. If the entity has not performed other tasks associated with the transaction, the entity has generally been allowed to perform the task (assuming the entity met other qualifications). After the task was performed, the system has recorded the fact that the entity does not have a right to perform other tasks in the same transaction. From the perspectives of computation, storage, and administration, there is a relatively large amount of overhead to implement SOD using traditional approaches.
The present invention is illustrated by way of example and is not limited by the accompanying figures, in which like references indicate similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale.
As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.
Any suitable computer-usable or computer-readable storage medium may be utilized. The computer-usable or computer-readable storage medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include 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 portable compact disc read-only memory (CD-ROM), an optical storage device, or a magnetic storage device. Note that the computer-usable or computer-readable storage medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable storage medium may be any medium that can contain or store the program for use by or in connection with an instruction execution system, apparatus, or device.
Computer program code for carrying out operations of the present invention may be written in an object oriented programming language, such as Java, Smalltalk, C++, etc. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a single computer, on multiple computers that may be remote from each other, or as a stand-alone software package. When multiple computers are employed, one computer may be connected to another computer through a local area network (LAN) or a wide area network (WAN), or the connection may be, for example, through the Internet using an Internet service provider (ISP).
The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (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 program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
As used herein, the term “coupled” includes both a direct electrical connection between blocks or components and an indirect electrical connection between blocks or components achieved using intervening blocks or components. As is used herein, the term “entity” includes an individual user or person, an organization (or portion of an organization), or a computer system associated with an individual person or organization (or portion of the organization). As is also used herein, the term “transaction” includes a process, a routine, and a procedure.
According to various aspects of the present disclosure, relatively efficient techniques are employed to implement separation of duties (SOD) transactions, e.g., business transactions. The transactions may be, for example, executed on multiple computer systems. The transactions may include financial transactions or may include approval of requests within an organization (such as travel requests, new equipment requests, etc. that require multi-level approval). In various embodiments, the techniques disclosed herein employ prime numbers to ensure SOD is achieved. Following this approach, each respective transaction is associated with a respective task transaction number (which in various embodiments correspond to a unique prime number) and each task included in a given transaction inherits the respective task transaction number. If a task is included in multiple transactions, the task inherits the respective task transaction numbers from each of the multiple transactions (i.e., the task transaction number of the task included in multiple transactions is a product of all of the inherited task transaction numbers). Each entity is associated with a task assignment number, which is a product of the task transaction numbers of all the tasks that have been assigned to the entity. When an entity attempts to perform a new task, the current task assignment number of the entity is divided by the task transaction number for the new task (or vice versa, depending on which number is larger). If the result of the division is not an integer, the entity is allowed to perform the task and the task assignment number of the entity is then multiplied by the task transaction number associated with the new task to update the task assignment number. If the result of the division is an integer, the entity is not allowed to perform the new task since a previous task associated with the same task transaction number (i.e., within the same transaction) has already been performed by the entity. A queued task may be reassigned from an entity (prior to performance of the task by the entity) by dividing a current task transaction number of the entity by a task transaction number of the queued task.
Compared to traditional approaches, the techniques disclosed herein (which utilize prime numbers) are more efficient to enforce an SOD policy required by a variety of transactions. Storage overhead of the disclosed techniques is relatively low as only a task transaction number associated with each transaction (not every task) and a current task assignment number for each entity is stored. The run-time performance of the disclosed techniques is advantageously increased as only a division operation and a compare operation (integer or not) is used to check whether a new task can be assigned to an entity. In contrast, conventional approaches require traversing an entire record associated with a transaction to determine whether an entity has performed a previous task associated with the transaction. The disclosed technique is generic and can be implemented in virtually any kind of application where implementation of an SOD policy is desirable.
In a typical application of the disclosed techniques, an organization has a number of transactions that require implementation of an SOD policy. Normally, each of the transactions includes multiple tasks and each task is to be performed by a different entity. In a typical scenario, a task may belong to multiple transactions with an SOD policy enforced on a per transaction basis. In this case, no single entity can perform two tasks that belong to the same transaction. According to various embodiments of the present disclosure, transactions are each assigned a unique prime number that corresponds to a task transaction number and each task within one of the transactions inherits the assigned task transaction number. According to one embodiment, if a task belongs to multiple transactions, the task transaction number is a product of the task transaction numbers of all the transactions to which the task belongs.
According to one aspect of the present disclosure, a technique for implementing separation of duties for transactions includes determining a current task assignment number of an entity. The technique also includes determining whether the entity can perform a new task based upon the current task assignment number and a task transaction number (which is based on at least one prime number) assigned to the new task.
According to another aspect of the present disclosure, a computer network includes multiple computer systems and an application server. The multiple computers systems are each assigned to a different entity. Alternatively, multiple entities may utilize the same computer system to perform tasks. The application server is in communication with the multiple computer systems and is configured to determine a current task assignment number for each of the multiple computer systems. The application server is also configured to determine whether each of the multiple computer systems can perform a new task based upon the current task assignment number for each of the multiple computer systems and a task transaction number assigned to the new task. The task transaction number is based on at least one prime number.
According to another embodiment of the present disclosure, a computer-readable storage medium includes first and second code. The first code is configured to determine a current task assignment number of an entity. The second code is configured to determine whether the entity can perform a new task based upon the current task assignment number and a task transaction number (which is based on at least one prime number) assigned to the new task.
With reference to
With reference to
When an entity tries to perform a task (or before a task is assigned to the entity), a current task assignment number of the entity is divided by a task transaction number associated with the task (or vice versa, depending on which number is larger). If the result of the division is an integer, the task cannot be assigned to (or performed by) the entity since another task that belongs to the same transaction was previously assigned to (or performed by) the entity. If the result is not an integer, the task can be assigned to (or performed by) the entity since a task that belongs to the same transaction has not been previously assigned to (or performed by) the entity. After a new task is assigned to (or performed by) an entity, the task assignment number of the entity is multiplied by a task transaction number associated with the new task to provide a current task assignment number for the entity.
In the example diagram 200 of
With reference to
In block 408, the server 312 determines a current task assignment number of an entity that is to perform the task. Next, in decision block 410, the server 312 determines whether the entity can perform the task to be assigned (i.e., whether the entity has already been assigned (or performed) a task within the transaction) by dividing the current task assignment number of the entity with the with task transaction number of the task and determining whether the result is an integer (i.e., if the result is an integer the task cannot be performed by the entity). If the entity has not already performed a task within the transaction, control transfers from block 410 to block 412, where the server 312 assigns the task to the entity and updates the current task assignment number of the entity. From block 412 control transfers to block 414, where the process 400 returns to a calling routine. If the entity has already performed a task within the transaction, control transfers from block 410 to decision block 416, where the server 312 determines whether another entity is available to perform the task. If another entity is available to perform the task, control transfers from block 416 to block 418 (where another entity is selected) and then to block 408. If another entity is not available to perform the task, control transfers from block 416 to block 414.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. For example, the present techniques can be implemented in any kind of computer system or business transaction application where enforcement of a separation of duties policy is desirable. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Having thus described the invention of the present application in detail and by reference to preferred embodiments thereof, it will be apparent that modifications and variations are possible without departing from the scope of the invention defined in the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5068778||Nov 28, 1988||Nov 26, 1991||Reliance Electric Industrial Company||Industrial control system device|
|US5357632||Aug 8, 1991||Oct 18, 1994||Hughes Aircraft Company||Dynamic task allocation in a multi-processor system employing distributed control processors and distributed arithmetic processors|
|US5534855||Dec 15, 1994||Jul 9, 1996||Digital Equipment Corporation||Method and system for certificate based alias detection|
|US6240358||Jul 8, 1999||May 29, 2001||Denso Corporation||Task control method with reduced stacked memory requirement|
|US6601233||Jul 30, 1999||Jul 29, 2003||Accenture Llp||Business components framework|
|US6816829||Jan 4, 2000||Nov 9, 2004||International Business Machines Corporation||System and method to independently verify the execution rate of individual tasks by a device via simulation|
|US6898790||May 11, 2000||May 24, 2005||International Business Machines Corporation||Mapping actions to tasks within customer service processing systems|
|US6986139 *||Oct 6, 2000||Jan 10, 2006||Nec Corporation||Load balancing method and system based on estimated elongation rates|
|US7111299||Dec 26, 2001||Sep 19, 2006||Platform Computing Corporation||Method and device to assist in the execution of tasks of parallel jobs|
|US7155720||Oct 26, 2001||Dec 26, 2006||Hewlett-Packard Development Company, L.P.||Dynamic task assignment in workflows|
|US20050138181 *||May 15, 2002||Jun 23, 2005||Ip Diva||Method for communication and/or machine resource sharing among plurality of members of a community in a communication network|
|US20060069602||Sep 24, 2004||Mar 30, 2006||Samsung Electronics Co., Ltd.||Method and system for describing consumer electronics using separate task and device descriptions|
|US20060095914||Sep 30, 2005||May 4, 2006||Serguei Mankovski||System and method for job scheduling|
|JP2005031914A||Title not available|
|1||Hung, Patrick C. K. "From Conflict of Interest to Separation of Duties in WS-Policy for Web Services Matchmaking Process"; Proceedings of 37th Annual Hawaii International Conf. on System Sciences, 2004, (IEEE) pp. 1-10.|
|U.S. Classification||718/101, 718/106|
|Sep 19, 2007||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KAO, I-LUNG;REEL/FRAME:019845/0314
Effective date: 20070828
|Sep 30, 2015||FPAY||Fee payment|
Year of fee payment: 4