The present invention relates generally to managing tasks performed on computer systems, and more specifically to controlling the tasks to safeguard the systems.
System administrators, help desk personnel and other information technology (IT) workers need access to computer systems that they support. However, occasionally they modify installed programs, data, or configurations, which damages the computer system or the programs or the data it contains, or is otherwise not beneficial. Known techniques limit the types of commands that such personnel are authorized to perform. For example, a help desk personnel without admin or root authority typically cannot change access permission of himself or herself or another IT worker. Some access control is based on an access control table which lists which applications or data files each authorized person can access and whether the access is to write or read only. It was known to limit access based on time of day, for example, during the normal shift hours of the authorized personnel.
Access control to a sensitive IT environment is also controlled to prevent intentional attacks/intrusions while allowing authorized people access. In order to properly manage business critical services, IT systems and services are locked down during specific times (e.g., during a peak business season). Locking down a system may employ change control, access control, monitoring control, hardening control, and/or event control and response. Existing automated access control systems provide conjoint access control (e.g., biometric authentication via a thumb print scan and a retina scan) and can utilize both physical and logical identity management techniques.
Mike Meyers' CISSP Certification Passport, Chapter 2—Access Control, by Shon Harris, 2002 teaches access control models and access control techniques. The access control models include discretionary access control (DAC) models, mandatory access control (MAC) models, and role-based access control (RBAC) (i.e., nondiscretionary) models. A DAC model allows owners of resources in an organization to control who accesses the resources and what operations can be performed on the resources, and is typically implemented through access control lists that grant permission to access the resources on a need-to-know basis. A user's access to resources in a DAC model is based entirely on the identity of the user or a role that the user plays within the organization. A MAC model compares a subject's clearance and need-to-know to a classification of a resource to either grant or disallow access to the resource. Every resource in a MAC model has a security label, which includes classification information (e.g., top secret, secret, etc.). In order to access a resource, the subject's clearance must be equal to or greater than the resource's classification. The security label also includes categories for which a subject must have a need-to-know before access to the resource can be granted. An RBAC model makes decisions about granting access to resources based on the rights and permissions assigned to a role or a group. Administrators create roles or groups and assign access rights and permissions to each role or group, instead of directly to the user. A user that is placed into a role inherits the permissions and access rights from the role. Different access control techniques work within the aforementioned models, and include restricted interfaces, access control matrices, and content-dependent access control. One type of restricted interface utilizes a user profile to dictate what icons, menus, applications, commands, and functionality is available within the user's environment. Another type of restricted interface is a database view, which shows a user only the information within a database that the user has access rights to view. Yet another type of restricted interface is a physically constrained interface of a system (e.g., automated teller machine) which presents users with buttons only for specific functions, without allowing access to other capabilities of the system. An access control matrix uses a capability table and an access control list to associate access permissions of a user to a resource. Content-dependent access control grants access to a resource based on the specific content of the resource that a user is trying to access. The above-mentioned access control models and techniques can utilize more granular access control types: (1) physical location (i.e., allow a user to access a resource only if the user has interactively logged in to a computer to indicate that the user is physically at a computer and not logged in remotely); (2) logical location (i.e., restrict access to a resource by an IP address, which is a logical location on a network); (3) time of day (i.e., allow access to a resource between specific hours of the day and specific days of the week); and/or (4) transaction type (i.e., restrict access to a resource based on the type of an operation that is requested to be carried out).
A first embodiment of the present invention is a method, computer system, and computer program product for controlling a task. A computer receives a change ticket. The computer correlates a task to perform the change ticket with one or more commands to perform the task, one or more users who are authorized to initiate execution of the one or more commands to perform the task for the change ticket, and an authorized location to initiate the execution of the one or more commands to perform the task. Subsequent to correlating the task, the computer determines that a request has been made by a requestor to execute one of the one or more commands to perform the task for the change ticket, and in response, the computer determines if (a) the requestor is currently located at the authorized location correlated with the task, and (b) the requestor is one of the one or more users correlated with the task. Based in part on (a) and (b) being true, the computer executes the requested command. If (a) or (b) is false, the computer prevents execution of the requested command.
A second embodiment of the present invention is a method, computer system and computer program product for securing and controlling a task. A computer receives a change ticket. The computer correlates a task to perform the change ticket with one or more commands to perform the task and with a user who is authorized to initiate execution of the one or more commands to perform the task for the change ticket. Subsequent to correlating the task, the computer determines that the user has requested execution of a command to perform the task for the change ticket. If the requested command is one of the one or more commands correlated to the task for the change ticket, the computer allows the execution of the requested command. If the requested command is not one of the one or more commands correlated to the task for the change ticket, the computer prevents the execution of the requested command.
Embodiments of the present invention provide an intelligent compound access control engine that secures and controls specific tasks to be performed on locked down computer systems (i.e., highly managed environments) by specific individuals at pre-specified times from specific physical locations using specific management systems. The compound access control engine captures essential requirements from multiple sources and automates temporary and location-specific access control and task performance control. Embodiments of the present invention allow the addition of entries to and deletion of entries from an access control database based on a lock down service request and/or a pre-specified task window.
Embodiments of the present invention provide access and task control by linking physical security systems and logical security systems to allow or prohibit a performance of a task by a user at a specific time by verifying that the following items in sequence: (1) the user entered and has not left one of specified physical location(s), (2) the user logged into one of specified managing computer system(s) in one of the specified physical location(s), (3) the user remotely logged into a target computer system from one of the managing computer system(s), (4) the user is one of specified user(s) who are allowed to initiate a performance of the task during one of specified time period(s) (e.g., change windows, maintenance windows, and upgrade windows), and (5) the specific time at which the performance of the task is initiated is included in one of the specified time period(s). The target system can be a locked down system and the specified time period can be included in a time period during which the target computer system is locked down. Rules for specifying the user(s) who are allowed to initiate the performance of the task, the time period(s) during which the task is allowed to be initiated, the target computer system, the managing computer system(s), and the physical location(s) of the managing computer system(s) may be defined by (1) previously agreed upon policies and procedures (e.g., security, lock down, or service management policies), (2) a change and/or service request, or (3) related sources, such as a change and configuration management database.
System for Securing and Controlling a Task
Access and task control program 104 receives a service request 106 and/or a change ticket 108. Service request 106 is a request to lock down a target computer system during a specified period of time. Change ticket 108 specifies a change to a target computer system (not shown) in a specified period of time (e.g., in a change or maintenance window). Locking down the target computer system in response to service request 106 restricts changes to the target computer system to only critical changes specified by change ticket 108, where the critical changes result from performing specified task(s) initiated by specified user(s) in specified time period(s), where the user(s) utilize specified managing computer system(s) (not shown) in specified location(s) to remotely login to the target computer system to perform the task(s). Access and task control program 104 stores and correlates the aforementioned user(s), task(s), time period, managing computer system(s), and target computer system in a change and configuration management database 110.
Access and task control program 104 receives verification of a person's location from a physical identity (ID) management system 112 that utilizes a combination of physical credentials (e.g., access badge) and biometric authentication (e.g., retina scan) to provide physical access control to a building or other physical structure in which one or more managing computer systems (not shown) are located. The physical access control provided by physical ID management system 112 verifies that a user has entered and has not exited a physical structure that includes a managing computer system. Physical ID management system 112 verifies that a user who is authorized to initiate the task(s) specified by change ticket 108 is in physical proximity to one or more other individuals who may be able to assist the user. For example, a database administrator who is performing database maintenance activities on a locked down database may be required to perform the database maintenance activities while being close to network administrators in a network operation center who are performing tasks associated with a locked down switch.
Access and task control program 104 receives verification of a user logging into a managing computer system from a logical ID management system 114 for the managing computer system, where the logical ID management system 114 for the managing computer system provides logical access control. Logical ID management system 114 for the managing computer system is integrated with physical ID management system 112 so that access and task control program 104 verifies that the following actions happen in sequence: (1) a user enters a physical structure that includes a managing computer system that can initiate a task specified by change ticket 108; and (2) the user logs onto the managing computer system.
Access and task control program 104 receives verification of a user remotely logging into the target computer system from a managing computer system specified in a system ID table 118. In one embodiment, system ID table 118 is included in change and configuration management database 110. The received verification is from a logical ID management system 116 for the target computer system, where the logical ID management system 116 provides system level authentication for the target computer system. The received verification indicates that a packet source for the remote login is a specified managing computer system, and is not a pass through (i.e., the verification indicates that the user did not log in remotely to the specified managing computer system, from which the user then attempts a remote login to the target computer system).
Access and task control program 104 receives verification that the task specified by the change ticket 108 is being initiated by a specified user whose user ID is correlated with the task in a task table 120. Access and task control program 104 can receive the verification that the task is initiated by the specified user by retrieving the correlation between the user ID and the task from task table 120. In one embodiment, task table 120 is included in change and configuration management database 110.
Access and task control program 104 receives verification that a user is initiating the task specified by the change ticket 108 at a time that is within a time period which is correlated with the task within the change and configuration management database 110.
Internal and external components of computer 102 are further described below relative to
In step 204, access and task control program 104 (see
In step 206, access and task control program 104 (see
In step 208, access and task control program 104 (see
Returning to step 208, if access and task control program 104 (see
Step 214 follows step 210 and step 212. The process of
In step 304, access and task control program 104 (see
In one embodiment, step 304 (or another step prior to step 308) includes access and task control program 104 (see
In step 306, access and task control program 104 (see
Prior to step 308, access and task control program 104 (see
In step 308, access and task control program 104 (see
In step 310, access and task control program 104 (see
In step 312, access and task control program 104 (see
In step 314, access and task control program 104 (see
In step 316, access and task control program 104 (see
In step 318, access and task control program 104 (see
In step 320, access and task control program 104 (see
Returning to step 318, if access and task control program 104 (see
Returning to step 316, if access and task control program 104 (see
Returning to step 314 (see
Returning to step 312 (see
Returning to step 310 (see
Returning to step 308 (see
After step 324, the process of
In another embodiment, a variation of the process of
After step 504, John attempts to log into managing computer system A located in building ABC. In step 506, access and task control program 104 (see
In step 508, based in part on the first timestamp indicating John entered and has not exited building ABC and the second timestamp indicating John attempted to log into managing computer system A while John was in building ABC, access and task control program 104 (see
In step 510, access and task control program 104 (see
In step 512, based on John's attempt to remotely log into target computer system XZ from managing computer system A and a correlation between John's user ID and an ID of the target computer system XZ, access and task control program 104 (see
In step 514, access and task control program 104 (see
In step 516, access and task control program 104 (see
If access and task control program 104 (see
Returning to step 516, if access and task control program 104 (see
Step 522 follows step 518 and step 520. The sample process of controlling the performance of a task in
Computer System
The set of internal components 600 also includes a read/write (R/W) drive or interface 632 to read from and write to one or more portable tangible computer-readable storage devices 736 that can store but do not transmit a computer program, such as a CD-ROM, DVD, memory stick, magnetic tape, magnetic disk, optical disk or semiconductor storage device. The program instructions 104 (for computer 102 in
The set of internal components 600 also includes a network adapter or interface 636 such as a transmission control protocol/Internet protocol (TCP/IP) adapter card or wireless communication adapter (such as a 4G wireless communication adapter using orthogonal frequency-division multiple access (OFDMA) technology). The program 104 (for computer 102 in
The set of external components 700 includes a display screen 720, a keyboard or keypad 730, and a computer mouse or touchpad 734. The set of internal components 600 also includes device drivers 640 to interface to display screen 720 for imaging, to keyboard or keypad 730, to computer mouse or touchpad 734, and/or to the display screen for pressure sensing of alphanumeric character entry and user selections. The device drivers 640, R/W drive or interface 632 and network adapter or interface 636 comprise hardware and software (stored in storage device 630 and/or ROM 624.
The program 104 (see
Based on the foregoing, a computer system, method and program product have been disclosed for securing and controlling a task. However, numerous modifications and substitutions can be made without deviating from the scope of the present invention. Therefore, the present invention has been disclosed by way of example and not limitation.
This application is a continuation application claiming priority to Ser. No. 15/483,050 filed Apr. 10, 2017, now U.S. Pat. No. 10,019,578 issued Jul. 10, 2018, which is a continuation application claiming priority to Ser. No. 14/211,135 filed Mar. 14, 2014, now U.S. Pat. No. 9,665,718 issued May 30, 2017, the contents of which are hereby incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
5261070 | Ohta | Nov 1993 | A |
5560008 | Johnson et al. | Sep 1996 | A |
7073174 | Volkoff et al. | Jul 2006 | B2 |
7853675 | Cannon et al. | Dec 2010 | B2 |
8327417 | Carter et al. | Dec 2012 | B2 |
8433769 | Cacheria, III et al. | Apr 2013 | B2 |
8453256 | Aggarwal et al. | May 2013 | B2 |
8869252 | Asokan et al. | Oct 2014 | B2 |
9077713 | Zheng et al. | Jul 2015 | B1 |
9330370 | Anderson | May 2016 | B2 |
9356968 | Dotan et al. | May 2016 | B1 |
9450946 | Boulos | Sep 2016 | B2 |
9548907 | Finn et al. | Jan 2017 | B2 |
9665718 | Anderson et al. | May 2017 | B2 |
20070244896 | Liu et al. | Oct 2007 | A1 |
20080043274 | Wang | Feb 2008 | A1 |
20080215713 | Cannon et al. | Sep 2008 | A1 |
20080244605 | Bennington | Oct 2008 | A1 |
20080263644 | Grinstein | Oct 2008 | A1 |
20090254982 | Jansen | Oct 2009 | A1 |
20100287620 | Fanton et al. | Nov 2010 | A1 |
20110167260 | Fanton et al. | Jul 2011 | A1 |
20110289547 | Aggarwal et al. | Nov 2011 | A1 |
20120060163 | Khan et al. | Mar 2012 | A1 |
20120216243 | Gill et al. | Aug 2012 | A1 |
20120260090 | Hauck et al. | Oct 2012 | A1 |
20130073859 | Carlson et al. | Mar 2013 | A1 |
20130091188 | Du et al. | Apr 2013 | A1 |
20130110588 | Livne | May 2013 | A1 |
20130152164 | Aggarwal et al. | Jun 2013 | A1 |
20130247144 | Marshall et al. | Sep 2013 | A1 |
20140096241 | Li et al. | Apr 2014 | A1 |
20150012977 | Huh et al. | Jan 2015 | A1 |
20150261956 | Anderson et al. | Sep 2015 | A1 |
20150350194 | Gilpin et al. | Dec 2015 | A1 |
20150378722 | Zuniga-Hernandez | Dec 2015 | A1 |
20160078214 | Angal | Mar 2016 | A1 |
20160191347 | Finn et al. | Jun 2016 | A1 |
20170213033 | Anderson et al. | Jul 2017 | A1 |
Entry |
---|
Amendment after Notice of Allowance (Rule 312) filed Feb. 13, 2017) for U.S. Appl. No. 14/211,135, filed Mar. 14, 2014; Confirmation No. 2195. |
Amendment filed Dec. 22, 2016 in response to Office Action (dated Aug. 25, 2016) for U.S. Appl. No. 14/211,135, filed Mar. 14, 2014; Confirmation No. 2195. |
Hovav et al; Tutorial: Identity Management Systems and Secured Access Control; Communications of the Association for Information Systems; vol. 25, Issue 1, Article 42; Dec. 1, 2009; http://aisel.aisnet.org/cais/vol25/iss1/42; 42 pages. |
Mike Meyers' CISSP Certification Passport; Chapter 2: Access Control; 2002; pp. 29-68. |
Notice of Allowance (dated Jan. 30, 2017) for U.S. Appl. No. 14/211,135, filed Mar. 14, 2014; Confirmation No. 2195. |
Office Action (dated Aug. 25, 2016) for U.S. Appl. No. 14/211,135, filed Mar. 14, 2014; Confirmation No. 2195. |
Quest Software; Solutions Brief: Developer and Administrator Access to Production; Retrieved from the Internet URL: http://www.aspirant.com.sg/download/quest/brochure/questsoftware_developerandadministratoraccesstoproductiontechbrief.pdf; retrieved on Apr. 13, 2013; Copyright 2011; 12 pages. |
Rodzinka, Mark; Cross-Enterprise Access Control Security for Electronic Health Records: Technical, Practical and Legislation; Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Science; Rochester Institute of Technology; Sep. 21, 2012; 103 pages. |
SAP GRC Regional Implementation Group; How to Performance Optimize SAP GRC Access Control 5.3; Version 1.1; Feb. 2011; 28 pages. |
Office Action (dated Oct. 19, 2017) for U.S. Appl. No. 15/483,050, filed Apr. 10, 2017; Confirmation No. 4552. |
Amendment filed Jan. 18, 2018 in response to Office Action (dated Oct. 19, 2017) for U.S. Appl. No. 15/483,050, filed Apr. 10, 2017; Confirmation No. 4552. |
Notice of Allowance (dated Mar. 7, 2018) for U.S. Appl. No. 15/483,050, filed Apr. 10, Confirmation No. 4552. |
Number | Date | Country | |
---|---|---|---|
20180322289 A1 | Nov 2018 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 15483050 | Apr 2017 | US |
Child | 16021063 | US | |
Parent | 14211135 | Mar 2014 | US |
Child | 15483050 | US |