SYSTEMS AND METHODS FOR TRUE PRIVILEGE APPLICATION ELEVATION

A method comprising storing a privilege rule, detecting an instruction to execute an application, and determining whether execution of the application requires an elevated privilege. The example method further comprises identifying, responsive to a determination the execution of the application requires the elevated privilege, one or more attributes of the application, and generating a request for the elevated privilege based on the privilege rule and the one or more attributes of the application. The method further comprises receiving the elevated privilege responsive to an approval of the request for the elevated privilege, and causing the execution of the application with the elevated privilege.

FIELD OF USE

Various embodiments discussed herein relate generally to elevating privileges for application execution. More particularly, various embodiments relate to systems and methods that utilize an agent to facilitate execution of applications with true elevated privileges.

BACKGROUND

All too often, too many users of a network are granted full, unrestricted superuser, root, or administrator privileges, regardless of whether or not access is needed. Even if unrestricted access is needed occasionally, many users maintain full, unrestricted access persistently. This “all trusting” environment is insecure to both inside and outside attacks. Further, this type of approach is frequently coupled with a lack of accountability of this access. These privileged accounts are often exploited by unethical insiders and hackers to perpetrate fraud, steal data, and/or damage systems.

A similar issue exists with non-human processes in the area of application-to-application (A2A) or application-to-database (A2DB) communication involving service accounts on various IT systems. The passwords for these accounts are often hard-coded or embedded in the calling application or script and rarely, if ever, change. Couple this with the fact that any skilled administrator or programmer with access to the application source code or script may view those passwords, and the potential for damage greatly increases.

Due to the depth of access that privileged and embedded passwords provide to highly sensitive and confidential information, and the fact that these access credentials are shared among administrators, it is only natural that security experts and compliance auditors are recommending and requiring more scrutiny and control in this area. Without a system of checks and balances and overall accountability for privileged and embedded passwords, an organization is open to exploitation and exposes mission-critical systems to intentional or accidental harm and malicious activity.

Therefore what is needed is needed is a computer-implemented method for storing a privilege rule, detecting an instruction to execute an application, and determining whether execution of the application requires an elevated privilege.

SUMMARY

To minimize the limitations in the prior art, and to minimize other limitations that will become apparent upon reading and understanding the present specification, the following discloses a new and useful computer-implemented method for storing a privilege rule, detecting an instruction to execute an application, and determining whether execution of the application requires an elevated privilege.

The systems and methods described herein may provide enhanced security and/or improved user workflow for application privilege elevation. Typical systems may elevate application privileges using application security tokens. However, elevating application security tokens may be unsuccessful for applications that need to communicate across a network because security tokens may only be recognized locally. Other typical systems may have a user check out and/or manually enter account credentials (e.g., username and password) for an administrator account (or, super-user account), however such systems may have inherent security flaws (e.g., revealing administrator credentials) and/or may interrupt user workflow. The systems and methods described herein address these, and other, problems.

In various implementations, security agents executing on client devices facilitate execution of applications with true elevated privileges retrieved from a security system. True elevated privileges may include, for example, account credentials associated with an account with elevated privileges, such as an administrator account. Client devices may include, for example, mobile devices, laptops, smartphones, desktops, hardened devices, servers, and/or so forth. In some embodiments, applications may be transparently executed with true elevated privileges retrieved from a security system without displaying, or otherwise revealing, the true elevated privileges and/or requiring input from a user. For example, applications may be executed automatically with the “RUN AS” command using the retrieved true elevated privileges.

Furthermore, the systems and methods described herein may allow application elevation on an application-by-application basis without potentially granting elevated privileges for other applications. Moreover, application execution with true elevated privileges as described herein may be automated such that applications appear to be executed with the user's own credentials. For example, a particular application (e.g., regedit) may require a higher privilege-level than the user's associated privilege-level. A security agent may initiate execution of the particular application with true elevated privileges retrieved from a security system without prompting the user to enter a new set of credentials, and/or potentially compromising security by exposing administrator credentials to the user.

One embodiment is a method for true privilege application elevation, the steps comprising: providing a client device; storing, by the client device, at least one privilege rule; detecting, by the client device, an instruction to execute an application; determining, by the client device, whether execution of the application requires an elevated privilege; generating, by the client device, a request for the elevated privilege based on the at least one privilege rule; communicating the request for the elevated privilege to a security system that is in operative communication with the client device; receiving, by the client device, a privilege response from the security system; wherein the privilege response is a response selected from the group of responses selected from: an approval and a denial; wherein if the privilege response is an approval, then the application is executed with the elevated privilege. Wherein if the privilege response is an approval the privilege response may comprise one or more true elevated privileges. The method may further comprise: identifying, responsive to determining the execution of the application requires the elevated privilege, one or more attributes of the application; wherein the request for the elevated privilege may further be based on the one or more attributes of the application. The client device may comprise a security agent; wherein the security agent may comprise an agent management module, and/or an agent rules database that may store the at least one privilege rule. The at least one privilege rule may be generated by the agent management module or may be retrieved from the security system. The security agent may further comprise an agent communication module that may receive the privilege response and an agent authentication module that may authenticate a source of the privilege response. The security agent may further comprise an agent encrypt/decrypt module that may decrypt the privilege response. The agent encrypt/decrypt module may encrypt the request for the elevated privilege and the agent communication module may communicate the request for the elevated privilege to the security system.

Another embodiment is a method for true privilege application elevation, the steps comprising: providing a client device; storing, by the client device, at least one privilege rule; detecting, by the client device, an instruction to execute a first application; determining, by the client device, whether execution of a second application on a remote device requires an elevated privilege, the second application linked to the first application via the network connection; generating, by the client device, a request for the elevated privilege for the second application based on the at least one privilege rule; communicating the request for the elevated privilege to the security system that is linked to the client device via a network connection; receiving, by the client device, a privilege response from the security system; wherein the privilege response is a response selected from the group of responses selected from: an approval and a denial; wherein if the privilege response is an approval, then the second application is executed with the elevated privilege. Wherein if the privilege response is an approval the privilege response may comprise one or more true elevated privileges. The method may further comprise: identifying, responsive to determining that execution of the second application requires the elevated privilege, one or more attributes of the second application; wherein the request for the elevated privilege may further be based on the one or more attributes of the second application. Preferably, the client device may comprise a security agent, wherein the security agent may comprise: (a) an agent management module; (b) an agent rules database that may store the at least one privilege rule; (c) an agent communication module that (i) may receive the privilege response and (ii) may communicate the request for the elevated privilege to the security system; and (d) an agent authentication module that may authenticate a source of the privilege response; and (e) an agent encrypt/decrypt module that may decrypt the privilege response and that may encrypt the request for the elevated privilege. The at least one privilege rule may be generated by the agent management module or may be retrieved from the security system.

In another embodiment, the method may comprise the steps: providing security system; generating and storing, by the security system, one or more device records; generating and storing, by the security system, one or more security system privilege rules; receiving a request for an elevated privilege, by the security system; determining, by the security system, whether to approve or deny the request for the elevated privilege; generating, by the security system a privilege response; wherein the privilege response is a response selected from the group of responses selected from: an approval and a denial; communicating, by the security system, the privilege response to a client device; wherein if the privilege response is an approval, then an application is executed with the elevated privilege. Wherein the security system may approve or deny the request for the elevated privilege based on the one or more security system privilege rules. The security system may approve or deny the request for the elevated privilege based on one or more attributes of the application. The security system may comprise: (a) a security system management module; (b) a security system rules database that may store the one or more security system privilege rules; (c) a security system communication module that (i) may receive the request for the elevated privilege and (ii) may communicate the response to the request for the elevated privilege to the client device; (d) a security system authentication module that may authenticate a source of the request for the elevated privilege; and (e) a security system encrypt/decrypt module that decrypts the request for the elevated privilege and that encrypts the response to the request for the elevated privilege. The one or more security system privilege rules may be generated by the security system management module. Preferably, when the privilege response is an approval, the privilege response may comprise one or more true elevated privileges. The security system may further comprise a security system privilege module that may retrieve the one or more true elevated privileges.

It is an object of the new method to overcome the limitations of the prior art.

DETAILED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS

In the following detailed description of various embodiments, numerous specific details are set forth in order to provide a thorough understanding of various aspects of one or more embodiments. However, these embodiments may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, and/or components have not been described in detail so as not to unnecessarily obscure aspects of embodiments of the invention.

While multiple embodiments are disclosed, other embodiments will become apparent to those skilled in the art from the following detailed description, which shows and describes illustrative embodiments. As will be realized, the invention is capable of modifications in various obvious aspects, all without departing from the spirit and scope of protection. Accordingly, the graphs, figures, and the detailed descriptions thereof, are to be regarded as illustrative in nature and not restrictive. Also, the reference or non-reference to a particular embodiment of the invention shall not be interpreted to limit the scope of the invention.

In the following description, certain terminology is used to describe certain features of the following embodiments. For example, as used herein, the terms “computer” and “computer system” generally refer to any device that processes information with an integrated circuit chip.

As used herein, the terms “software” and “application” refer to any set of machine-readable instructions on a machine, web interface, and/or computer system” that directs a computer's processor to perform specific steps, processes, or operations disclosed herein. The application or software may comprise one or more modules that direct the operation of the computer system on how to perform the disclosed method.

As used herein, the term “computer-readable” medium may refer to any storage medium adapted to store data and/or instructions that are executable by a processor of a computer system. The computer-readable storage medium may be a computer-readable non-transitory storage medium and/or any non-transitory data storage circuitry (e.g., buggers, cache, and queues) within transceivers of transitory signals. The computer-readable storage medium may also be any tangible computer readable medium. In various embodiments, a computer readable storage medium may also be able to store data, which is able to be accessed by the processor of the computer system.

The systems and methods described herein may provide enhanced security and/or improved user workflow for application privilege elevation. Typical systems may elevate application privileges using application security tokens. However, elevating application security tokens may be unsuccessful for applications that need to communicate across a network because security tokens may only be recognized locally. Other typical systems may have a user check out and/or manually enter account credentials (e.g., username and password) for an administrator account (or, super-user account), however such systems may have inherent security flaws, e.g., revealing administrator credentials, and/or may interrupt user workflow. The systems and methods described herein address these, and other, problems.

In various implementations, security agents executing on client devices facilitate execution of applications with true elevated privileges retrieved from a security system. True elevated privileges may include, for example, account credentials associated with an account with elevated privileges, such as an administrator account. Client devices may include, for example, mobile devices, laptops, smartphones, desktops, hardened devices, servers, and/or so forth. In some embodiments, applications may be transparently executed with true elevated privileges retrieved from a security system without displaying, or otherwise revealing, the true elevated privileges and/or requiring input from a user. For example, applications may be executed automatically with the “RUN AS” command using the retrieved true elevated privileges.

Furthermore, the systems and methods described herein may allow application elevation on an application-by-application basis without potentially granting elevated privileges for other applications. Moreover, application execution with true elevated privileges as described herein may be automated such that applications appear to be executed with the user's own credentials. For example, a particular application (e.g., regedit) may require a higher privilege-level than the user's associated privilege-level. A security agent may initiate execution of the particular application with true elevated privileges retrieved from a security system without prompting the user to enter a new set of credentials, and/or potentially compromising security by exposing administrator credentials to the user.

FIG. 1is an illustration of one embodiment of an example system and environment for executing applications with true elevated privileges according to some embodiments.FIG. 1illustrates an example system and environment100for executing applications with true elevated privileges according to some embodiments. The system and environment100includes a client device102(or “user device”), a manager device104, and an administrator device106, each of which may each communicate with a security system108. Routers/switches110, firewalls112, windows servers114, Unix servers116, Linux servers118, AS/400 servers120, z/OS mainframes122, and databases124may each be operatively coupled to a network126which may be operatively coupled to the security system108.

In various embodiments, a digital device may comprise the client device102, the manager device104, the administrator device106, the security system108, routers/switches110, firewalls112, the windows servers114, the Unix® servers116, the Linux® servers118, the AS/400 servers120, the z/OS mainframes122, and/or the databases124. It will be appreciated that a digital device is any device with a processor and memory, such as a computer. Digital devices are further described herein.

The client device102is any digital device with one or more accounts (e.g., user accounts, service accounts, and the like) and a security agent to facilitate executing applications with true elevated privileges. In some embodiments, true elevated privileges may include account credentials (e.g., username and password) associated with an account with elevated privileges, such as an administrator account. The client device102may be a mobile device, laptop, smartphone, desktop, hardened device, server, and/or so forth.

In some embodiments, the client device102is any digital device with an application that may seek access to a secured application and/or secured database. In one example, the user of the client device102may be an accountant and the seeking application may be Microsoft Access. The accountant may wish to access a secured accounting database on a network (e.g., stored within the databases124). Before the seeking application gains access to the secured accounting database, a request to access the database (e.g., a registration request) may be approved. Once approved, the client device102may receive a password to be stored within the client device102. Alternately, the password is not stored within the client device102but rather the client device102may receive the password when the seeking application requests access to the secured application. In some embodiments, the password may be associated with an expiration event after which the password is expired and the client device102must then request another password. The process of registering and seeking passwords is further described herein.

It will be appreciated that, in some embodiments, the secured database may be on the client device102and the seeking application on another device that is on the network126. Similar to the example above, before the seeking application gains access to the secured database on the client device102, the client device102may be accessible over the network126and a request to access the database (e.g., a registration request) may be approved by the security system108. Once approved by the security system108, assuming the client device102is accessible, the seeking application (or the digital device of the seeking application) may receive a password to access the secured database.

A seeking application is any application that requires a password or other authentication information before accessing a secure application and/or secured database. A secured application is any application that requires a password or other authentication information before being able to access the secured application. Similarly, a secured database is any database that requires a password or other authentication information before access is granted. It will be appreciated that a secured database may refer to any secured data structure and is not limited only to databases (e.g., a secured table).

The client device102may further include a security agent. The client device102is further discussed herein.

The manager device104is any digital device that may approve a registration request. In some embodiments, the client device102may provide a registration request. The registration request may include information about the user of the client device102(e.g., login information), the client device102, itself, and/or a seeking application. The manager and/or an application on the manager device104may review the registration request and approve or deny the request. In one example, the manager device104is operated by a manager that may approve a registration request from the client device102. In another example, the manager device104may be configured to automatically approve one or more registration requests. In some embodiments, the manager of the manager device104may approve one or more components of the registration request (e.g., program factors discussed herein) and the manager device104is configured to approve the same or different components of the registration request.

In another example, the manager may receive the registration request that indicates the user and the seeking application. If the user is authorized for access (e.g., the user is an accountant seeking access for financial information) and the seeking program is confirmed based on program factors, the manager may approve the registration request, thereby allowing the seeking application access. It will be appreciated that there may be any number of ways a manager and a managing device104may, either in combination or separately, review and examine registration requests for approval or denial. Further, it will be appreciated that the manager device104may be optional and the approval process may take place within the security system108(further described herein) and/or the administrator device106.

The administrator device106is any digital device that configures the security system108. In various embodiments, the administrator device106is operated by an administrator (e.g., a network administrator, security officer, or IT professional) who can configure the security system108. In one example, the administrator device106may display a configuration interface (e.g., a web page from the security system108) that allows configuration. The administrator device106may configure the security system108to perform different tasks depending upon the seeking application, the user of the client device102, and/or the client device102. In one example, the administrator device106may specify specific manager devices104which must approve a registration request from a specific user name before the registration request may be approved and access to a secured application provided (e.g., via a password). The administrator device106may also specify program factors that must be confirmed as well as what the values of the program factors are expected to be. It will be appreciated that the security system108may be configured in any number of ways.

The security system108may comprise hardware, software, or a combination of both. In various embodiments, a digital device includes the security system108. The digital device may be cabled to (or otherwise in communication with) the network126. In some embodiments, the security system108may comprise software configured to be run (i.e., executed) by a server, router, or other device. The security system108may also comprise hardware. For example, the security system108may comprise a Windows® 2003 server (such as a hardened Windows® 2003 server), with quad-core CPUs, hot swap mirrored drives, redundant power supplies, and redundant fans. The security system108may also comprise redundant CPUs and hot-bank memory.

In various embodiments, the security system108is configured (e.g., by an administrator and/or the administrator device106) to provide security for accounts, applications and databases. In some examples, the security system108may be configured to process requests for true elevated privileges, generate and update account passwords, process registration requests, log relevant information, and so forth. In some embodiments, the security system108is configured to privilege requests103a,approve or deny the request103a,and/or transmit privilege responses103bto the client device102. For example, the privilege response103bmay include true elevated privilege credentials for approved requests103a.

In various embodiments the security system108is configured to generate and update passwords for a secure application and/or secured application. In one example, software to create a password for a specific secured database (e.g., a secured SQL database) may be stored within or by the security system108. The security system108may then execute the software. The software may comprise executable instructions which are executable by a processor to perform a method for creating or changing a password for one or more secured applications and/or secured databases. The security system108may interact directly (or indirectly) with one or more digital devices, secured applications, and/or secured databases to create or change the password. Once the password is generated, the security system108may store the password.

The security system108may also update the password to the secured application and/or the secured database. In various embodiments, the security system108determines an expiration event after which a password is expired (e.g., after a predetermined time or date). At that time, the security system108may change the password to the secured application and/or the secured database. In one example, the security system108interacts with the secured application and/or the secured database to change the password and then the security system108may store the password. The predetermined time or date may be any time or date. For example, the security system108may change a password of a secured application or database after a period of time (e.g., every day, hour, minute, or the like). The security system108, for example, may change any number of passwords every thirty seconds while changing other passwords every week. It will be appreciated that any period of time may be used. Similarly, the security system108may change any number of passwords at a scheduled time and/or day.

It will be appreciated that the security system108may encrypt generated password(s) and/or encrypt storage where the password(s) is stored. The security system108may encrypt communications between the security system108and any other digital device (e.g., all communication between the client device102and the security system108may be encrypted). For example, the security system108may perform FIPS-140 validated encryption of data and communications, access control mechanisms, secure storage of credentials, and/or secure audit trails. The security system108may also comprise a sealed operating system.

The security system108may also process registration requests. In one example, prior to a seeking application on a client device102being allowed to access a secured application or secure database, the security system108may require registration. The client device102may then provide a registration request to the security system108. The registration request may include information regarding the user, the client device102, and/or the seeking application. Based on a prior configuration, the security system108may, based on the user, the client device102, and/or the seeking application, review the registration request and/or route the registration request to one or more manager devices104for approval. In one example, the security system108may be configured to determine if the client device102and/or the user logged into the client device102have rights to the secured application and/or secured database. If the client device102and/or the user do not have rights, the security system108may be configured to deny the registration request. The security system108may also be configured to email or otherwise contact one or more manager devices104to receive approval for the registration request. For example, the administrator may configure the security system108to email all registration requests associated with a particular seeking application to a predetermined number of managers and/or manager devices104. In some embodiments, the security system108may not approve the registration request until all managers and/or manager devices approve the registration.

The security system108may be configured to log all privilege requests, privilege elevation, registration requests, passwords, password changes, and/or password requests thereby creating a record of the activities of each user, client device102, and/or seeking application. In some embodiments, the logs of the security system108may be used to confirm that the secured application and/or the secured database are being used as approved. The logs may also be encrypted. In various embodiments, the logs may be audited (e.g., by the administrator and/or the administrator device106). The security system108may also be configured to provide reports regarding user/approver, requester activities, password maintenance, user and file entitlement (rights) and/or internal diagnostics. In a few examples, the reports may be exportable in CSV and HTML formats.

AlthoughFIG. 1shows curved lines between the client device102and the security system108, the manager device104and the security system108, as well as the administrator device106and the security system108, it will be appreciated that the client device102, manager device104, and administrator device106may not be each directly connected to the security system108. In one example, the client device102, manager device104, and administrator device106may be in communication with the security system108over one or more networks. The curved lines inFIG. 1may depict the nature of the communication between a digital device and the security system108. In one example, in order to receive a password to log into the windows servers114, the client device102may send a password request to the security system108. The security system108may be configured by the administrator device106(e.g., as depicted inFIG. 1as “administration”) to send the password request to the manager device104for approval. The manager device104may send the approval to the security system108which may then provide the password to the client device102. The password may then be provided to the Windows servers114. In some embodiments, the password is not visible or displayed to the user of the client device102.

In another example, the client device102may comprise a seeking application or script that seeks access to a secured database. Prior to access, the client device102(e.g., via the seeking application or script) may provide the password request to the security system108which may either provide the password or provide the password after the proper approvals have been obtained. The password may then be sent to the client device102which may log into the secured database to obtain access with the password.

It will be appreciated that the security system may not be limited to privilege elevation and/or password management. Although various embodiments described herein refer to elevating privileges, generating, changing, and providing passwords to access the secured application and/or the secured database, similar systems and methods may be used with any form of security, including the issuance of encryption keys (e.g., private or public keys), certificates, digital signatures, decryption keys, credentials as well as rights management to files, volumes, and/or devices. Instead of a password being provided to the client device102, the security system108may alter user rights such that the user may view, access, make changes to, and/or share the secured application and or secured database. In some embodiments, the security system108may provide a password to the client device102as well as make changes to file rights. The security system108may provide access in any number of ways.

In some embodiments, the client device102may be required to provide a registration request for rights to a program or database on another digital device. The rights may include, but are not limited to, rights to view, access, make changes, and share with other users. The security system108may perform similar tasks as when a password is requested. In one example, the security system108may examine the registration request and analyze program factors to ensure that the seeking application, user, or client device102is authorized and/or authenticated. One or more manager devices104may also approve the registration request. Upon approval, the security system108may grant any number of rights to access the application or database. Further, the security system108may generate a new password for the sought application or database and/or provide the password to the client device102.

Although the security system108is depicted as communicating directly over the network126, the security system108may also communicate indirectly over the network126. In one example, the security system108may be a part of or otherwise coupled to the client device102, the manager device104, the administrator device106, the security system108, the routers/switches110, the firewalls112, the windows servers114, the Unix servers116, the Linux servers118, the AS/400 servers120, the z/OS mainframes122, and the databases124. Alternately, it will be appreciated that there may be multiple networks and the security system108may communicate over all, some, or one of the multiple networks.

The security system108may comprise a software library that provides a programmatic interface to the security system108. In one example, an API library resident on the security system108may have a small set of functions that are rapidly mastered and readily deployed in new or existing applications. There may be several API libraries, for example one library for each computer language or technology, such as, Java, .NET or C/C++ languages. Each specific instance, the API library may provide the same set of functions.

The routers/switches may comprise any number of routers and/or switches. In some embodiments, the security system108may manage rights or access to one or more routers or switches. The client device102may be required to provide a registration request and receive approval before rights to access the routers or switches are approved. The routers/switches110may comprise Cisco routers and switches for example. In another example, the routers/switches110may comprise a Terminal Access Controller Access-Control System (TACACS). The routers/switches110may also comprise web proxies or caches including, but not limited to, BlueCoat Security Gateway devices.

The firewalls112may comprise hardware, software, or a combination of both hardware and software. Control to access and manage the firewalls112may be controlled by the security system in a method similar to that described herein. In one example, before the user of the client device102is permitted to access and/or configure the firewall112, the client device102may be required to provide a registration request that must be approved. In a few examples, the firewalls112may comprise Cisco PIX, Netscreen, Nokia IPSO, Check Point, or Cyberguard.

The windows servers114may include any server configured with a Microsoft® Windows® operating system. In a few examples, the Microsoft operating system may be Windows 2000, 2003, XP, Media Center, Active Directory, NT 4.0, NT Domains, Vista®, and Windows® 7.

The Unix® servers116may include any server configured with a Unix operating system. In a few examples, the Unix® operating system may be Solaris, AIX, HP-UX, Tru64, or UnixWare®. Similarly, the Linux® server118may be any server configured with the Linux operating system. In a few examples, the Linux operating system may be Red Hat or Suse.

The AS/400 servers120and the z/OS servers122may include any server(s) with the associated operating system. Further a server may be configured with RACF, HP iLo, VMware, BoKS, Fujitus RSB, and Radius.

The databases124may comprise hardware, software, or a combination of hardware and software. In one example, the databases124are on a file server. The databases may include Oracle databases, Microsoft SQL, Sybase, MySQL, DB2 or any other database for example.

It will be appreciated that many operating systems, databases, and applications may be in communication with or otherwise coupled to the network126. The examples listed herein are not intended to be limiting and other operating systems, databases, and applications may be used in conjunction with various embodiments described herein.

The computer network126may provide communication between the client device102, the manager device104, the administrator device106, the security system108, routers/switches110, firewalls112, the windows servers114, the Unix servers116, the Linux servers118, the AS/400 servers120, the z/OS mainframes122, and/or databases124. In some embodiments the network126represents one or more network(s) that one or more digital devices may use to communicate. In some examples, the network126comprises Ethernet cables, fiber optic, or other wired network topology. In other examples, the network126may be wireless and support wireless communication between two or more wireless devices. It will be appreciated that the network126may comprise two or more networks, including wired and wireless networks.

Although the routers/switches110, the firewalls112, the windows servers114, the Unix servers116, the Linux servers118, the AS/400 servers120, the z/OS mainframes122, and the databases124are discussed as plural, it will be appreciated that there may be any number of (including one or zero) routers/switches110, the firewalls112, the windows servers114, the Unix servers116, the Linux servers118, the AS/400 servers120, the z/OS mainframes122, and the databases124and be within embodiments described herein.

FIG. 2is a block diagram of one embodiment of a client device comprising a security agent according to some embodiments.FIG. 2is a block diagram of an example client device102according to some embodiments. The client device102may be any digital device. Some examples of the client device102may include, for example, a mobile device, smartphone, tablet device, laptop, desktop, or hardened device. In some embodiments, the client device102comprises a security agent202, one or more accounts204, one or more applications206, and an operating system208, although in the other embodiments, the client device102may be configured otherwise. The security agent202, the accounts204, the applications206and/or the operating system208may be controlled by a processor such as the processor804described in relation toFIG. 8herein.

The security agent202may be configured to facilitate application control (e.g., cause application execution, deny application execution, etc.) for applications requiring elevated privileges to execute. In some embodiments, the security agent202utilizes true elevated privileges to execute such applications. For example, a user associated with a user account may need to execute an application (e.g., an application residing on client device102and/or on a remote device) which requires a higher privilege-level to execute than a privilege-level associated with the calling user account. Rather than requiring the user to manually enter a different set of credentials (e.g., administrator credentials), the security agent202may facilitate execution, and/or control, of the application with true elevated privileges. The security agent202is discussed further below with reference toFIG. 3.

Accounts204may include or be linked to any number of accounts. In one example, an account is or is linked to at least one record that enables authentication of credentials (e.g., passwords) to further enable access or other rights to information (e.g., applications, data, records, and/or other accounts).

Accounts204, for example, may include user accounts, service accounts (e.g., accounts used to launch applications206), and the like. In some embodiments, the accounts204are local to the client device102(e.g., not domain-based), and/or domain-based accounts. In various embodiments, each account204may be associated with an account identifier and a password. The password may be encrypted and/or stored on the client device102and/or the security system108. In various embodiments, accounts may be associated with hardware of the client device102(e.g., credentials necessary to access hardware services or unlock the device). The accounts may be associated with an operating system208(e.g., credentials associated with accessing a user profile or device access). There may be any number accounts associated with hardware or services of the client device102.

In another example, one or more accounts204may be associated with information technology (IT) professionals and may be used to enable IT professionals to access an application (e.g., of applications206), operating system208, firmware, hardware, and/or any other aspect of the client device102. In some embodiments, IT professionals may utilize the one or more accounts204to maintain the client device102, perform updates, perform upgrades, troubleshoot, and/or otherwise provide service.

Applications206may include any application. An application is any program or executable designed to enable end users to perform specific tasks, such as, but not limited to, word processing, database management, accounting, finance, spreadsheets, or communication. Applications may include, for example, word processing programs, system software, operating systems, browsers, spreadsheets, readers, players, database applications, email applications, design applications, or the like. It will be appreciated that there may be any number of applications206. In various embodiments, applications206comprise applications that have been installed and/or configured by the user of the client device102, administrator, and/or other trusted individual.

As used in this paper, it will be appreciated that applications may include local applications residing on the client device102, remote applications, and/or linked applications. Linked applications may include applications executed and/or accessed, either locally or remotely, by an application residing on the client device102. For example, a client application (e.g., an MS Access client) executing on the client device102may require access to a server application (e.g., an MS Access Database) executing on database124, and the server application may require different privileges than the client application. The security agent202may perform the same functionality with regard to linked applications as any other application, e.g., request true elevated privileges, execute with true elevated privileges, and so forth.

In some embodiments, the applications206include one or more attributes. The one or more attributes may include, for example, an application identifier (e.g., name, hash value, etc.), version information, linked application(s), privilege-level required to execute the application, and so forth. The one or more attributes may be used, for example, to generate privilege requests103a, determine if an application requires elevated privileges to execute, and the like.

A rule of the client device102may apply to all applications or a subset of applications of the applications206. In one example, a rule may instruct the client device102to allow or deny launch of any application. The rule may instruct the client device102to allow or deny launch of any application based on one or more credentials (e.g., password) of the account associated with the application. For example, a rule may instruct the client device102to deny application launch if the account used to launch the application does not have sufficient privilege to launch the application. In some embodiments, a rule may instruct client device102to request elevated privileges from the security system108and/or instruct the client device102to execute the application with the elevated privileges, e.g., without requiring input from the user and/or otherwise interrupting their workflow.

Operating system208may be any operating system. For example, the operating system208may be Microsoft Windows, OSX, Unix, BSD, or any other operating system. In some embodiments, the security agent202may include an API and/or a module in communication with the operating system208to detect when an application is to be launched or when an active communication connection is available between the client device102and the security system108.

In some embodiments, the client device102includes a credential storage that may store passwords and/or other credentials. The credential storage may be on any computer readable media including, for example, storage808inFIG. 8discussed further with regard toFIG. 8. The credential storage may, in some embodiments, be encrypted. The credential storage may, in some embodiments, store passwords received by from the security system108and/or generated by the security agent202.

FIG. 3is a block diagram of one embodiment of a client device comprising an example security agent according to some embodiments.FIG. 3is a block diagram of an example client device102including an example security agent202according to some embodiments. The security agent202may be software, hardware, firmware, or a combination thereof. In one example, the security agent202is a system (e.g., an application) on the client device102configured to generate and/or transmit privilege requests103a,receive true elevated privileges contained within privilege responses103b,and/or cause execution of applications with received true elevated privileges. In some embodiments, the security agent202executes on the client device102and includes an agent management module302, an agent rules database304, an agent record database306, an agent monitor module308, an agent application identification module310, an agent privilege module312, an agent encrypt/decrypt module314, an agent communication module316, and an agent authentication module318.

The agent management module302may be configured to create, read, update, delete, and/or otherwise access agent privilege rules320stored in the agent rules database304. Such operations may be performed manually (e.g., by an administrator interacting with a GUI) or automatically (e.g., retrieved from the security system108). For example, the rules320may be generated by the security system108and transmitted to the security agent202via the network126. Generally, the rules320include instructions to be executed by the security agent202.

In some embodiments, the rules320define a list, or other structure, of applications206managed by the security system108, and may define functions, attributes, and/or conditions for generating privilege requests103a,processing privilege responses103b,and/or causing the execution and/or control of applications206with true elevated privileges.

In some embodiments, the rules320may be associated with applications206. For example, each rule320may be associated with one or more applications206. The rules320may define any of the following attributes and/or conditions:Rule Identifier: Identifier that uniquely identifies a rule320.Rule Name: Name of the rule320(e.g., Calc.exe with PBSW)Applications: Selected applications206, and/or any selected linked applications206, associated with the rule320.Actions: commands and/or functions associated with the rule320. For example, actions may include “RUN AS” using true elevated privileges retrieved from the security system108.Accounts: Selected accounts204associated with the rule320. Execution of an associated selected application, and/or any selected linked applications, by users associated with the selected accounts204may trigger the actions defined in the rule320.

In some embodiments, the rules320may include or specify other information as well, such as encryption and decryption protocols used by the agent encrypt/decrypt module314, discussed below. It will be appreciated that the agent rules database304may be any structure (e.g., active database, relational database, table, and the like) suitable for storing and managing the aforementioned rules320.

In some embodiments, the agent management module302is configured to create, read, update, delete, and/or otherwise access, agent records322stored in the agent records database306, and related data (e.g., account passwords) stored on the client device102. The agent records322may maintain account information (e.g., account identifiers, account names, and the like) and account credentials (e.g., passwords) for the accounts204installed on the client device102.

For example, the agent record database322may include an account and/or an account identifier that identifies one of the accounts204installed on the client device102. The account identifier may be a number, character, string, or otherwise. In some embodiments, the records322may also include an encrypted password associated with the identified account, although in other embodiments the encrypted password may be stored or managed elsewhere on the client device102. In some embodiments, the agent records322may include one or more rule identifiers that identify corresponding rule(s)320stored in the agent rules database304. It will be appreciated that the agent record database306may be any structure (e.g., active database, relational database, table, and the like) suitable for managing and/or storing the aforementioned records322.

It will be appreciated that the agent records database306and records322are optional, and that such functionality (e.g., maintain account information, passwords, and the like) may be included in other features of the security agent202or client device102(e.g., operating system208).

The agent monitor module308may be configured to monitor a client device102for a launch of an application (e.g., an application from the set of applications206) and/or any linked applications. In some embodiments, the agent monitor module308is configured to monitor the client device102for a launch of an application that requires elevated privileges to execute. In various embodiments, all or part of the agent monitor module308intercepts and/or otherwise receives calls to the operating system208to launch an application. In various embodiments, all or part of the agent monitor module308may have hooks within the operating system208(e.g., the monitor module may have hooks in the kernel). The agent monitor module308may detect commands or calls to launch an application or may intercept such commands or calls.

The agent application identification module310may be configured to identify the launching application, and/or any linked applications, and/or one or more attributes of the launching application, and/or one or more attributes of any linked applications. For example, the agent application identification module310may identify the launching application as well as the launching application's version. All or part of the agent application identification module310may be within or in communication with the operating system208, resident in memory (e.g., RAM) of the client device102, or in communication with any component(s) of the client device102.

In various embodiments, prior to the application being commanded to launch, the agent application identification module310may scan all or parts of the client device102to identify applications and/or attributes (e.g., application identifiers, application versions, privilege level(s) required to execute the application, etc.) of the application or account seeking to launch the application. The application attributes may be stored or cached. When the agent application identification module310detects a command or call to launch the application, the agent application identification module310may identify the launching application based on the previously stored or cached information.

In some embodiments, the agent application identification module310retrieves an application identifier from a stored plurality of application identifiers. The retrieval of the application identifier may be based on information from scanning the directory of the launching application. The application identifier may be a name of an application, a value (e.g., code), a hash, or any other information that may identify the launching application.

In various embodiments, the agent application identification module310may also identify various attributes of the account seeking to launch the application. In some embodiments, the agent application identification module310may identify an account name, an account identifier, an account privilege level or status (e.g., normal user, administrator, etc.), and so forth. For example, it may detect if the user or account calling to launch the application is signed in as a trusted or elevated account (e.g., whether the account has active administrative or super-user privilege status). Those skilled in the art will appreciate that the account identifier may be a number, character, string, or other identifier sufficient to identify an account, e.g., from the set of accounts206.

The agent privilege module312may be configured to execute agent privilege rules320to cause the execution and/or control of applications with true privilege elevation. For example, the agent privilege module312may cause the application to be executed with the “RUN AS” command. In some embodiments, the agent privilege module312may generate a privilege request103awhen an instruction is detected to execute an application requiring elevated privileges. The privilege request message103amay include, among other things, one or more attributes of the associated application206, characteristics and/or attributes of the client device102and/or accounts204installed thereon. The characteristics and/or attributes may include for example, a device identifier, a device name, a fully qualified domain name (FQDN), a domain name, an IP address, a MAC address, an account name, an account identifier, a user name, a user ID, a CPU ID, a CPU serial number, a root disk volume, an OS version, an OS type, and so forth. It will be appreciated that the device identifier and the account identifier may be a number, character, string, or other identifier that may each identify, at least with respect to the client device102and the security system108, the device and account associated with those identifiers.

In some embodiments, the agent privilege module312may also be configured to update any number of rules320based upon update messages received from the security system108. The agent privilege module312may receive one or more rules from the privilege response messages103bsent from the security system108. In some embodiments, the agent privilege module312may generate new rules based on information received from the security system108. In one example, the agent privilege module312may look up a rule in the rule database304with a rule identifier specified in the received update message, and replace the existing “old” rule with the “new” rule contained in the received message. Alternatively, the agent privilege module312may upon only update a portion of the rule (e.g., a trigger condition) as opposed to replacing the whole rule.

The agent communication module316may be configured to provide communication between the client device102and the security system108. In some embodiments, the communication module316may also be configured to communicate between the security agent202and the security system108. For example, the agent communication module316may establish an active (or, real-time) communication connection between the client device102and the security system108, and the security agent202may send privileges requests103a,and/or receive privilege response103b,via that connection.

The agent encrypt/decrypt client module314is configured to encrypt, decrypt, and/or otherwise secure information during communication between the client device102and the security system108and/or information stored by the security agent202. The encrypt/decrypt client module212may encrypt, decrypt, or otherwise secure information in any number of ways including, but not limited to, those described herein. For example, agent encrypt/decrypt client module314may encrypt privilege requests103asent to the security system108, and decrypt privilege responses103breceived from the security system108. In some embodiments, the encryption/decryption protocols utilized by the agent encrypt/decrypt client module314are defined in the rules320.

In some embodiments, the agent authentication module318may be configured to authenticate a source of incoming messages (e.g., privilege responses103b). The agent authentication module318may authenticate incoming messages, for example, based upon authentication data contained within the incoming messages. This may prevent, among other things, “man in the middle” attacks. In some embodiments, the rules for appropriately authenticating a source of incoming privilege responses103bmay be defined in rules320. Authentication may utilize, for example, challenge messages, encryption, 3rdparty authentication, and the like.

It will be appreciated that a “module,” “agent,” or “database” may be or comprise software, hardware, firmware, and/or circuitry. In one example, one or more software programs comprising instructions capable of being executable by a processor (e.g., processor804described with regard toFIG. 8) may perform one or more of the functions of the modules, databases, or agents described herein. In another example, circuitry may perform the same or similar functions. The circuitry may utilize, for example, an ASIC or other processing device.

Alternative embodiments may comprise more, less, or functionally equivalent modules, agents, or databases, and still be within the scope of present embodiments. For example, as previously discussed, the functions of the various modules, agents, or databases may be combined or divided differently. It will also be appreciated that some of the modules identified inFIG. 3are optional (e.g., the agent encrypt/decrypt module314and the agent authentication module318may be optional).

FIG. 4is a block diagram of one embodiment of a security system according to some embodiments.FIG. 4is a block diagram of an example security system108according to some embodiments. In some embodiments, the security system108includes a security management module402, a security system management database404, a security system rules database406, a security system privilege module408, a security system authentication module410, a security system communication module412, and a security system encrypt/decrypt module414. The security system108may be configured to approve or deny privilege requests103a,retrieve true elevated privileges for approved requests103a,and/or generate privilege responses103b.

The security management module402is configured to create, read, update, delete, and/or otherwise access, device records416stored in the security system management database404and the rules418stored in the rules database406. The security management module402may perform any of these operations either manually (e.g., by an administrator interacting with a GUI) or automatically (e.g., by the security system privilege module408). In some embodiments, any of device records416store a variety of information about the client device102and/or other devices that connect to the security system108(e.g., via network126). For example, the device records405could store device identifiers (e.g., MAC addresses, IP addresses, Firmware identifiers, or the like), account identifiers, rule identifiers, security agent identifiers, passwords, password identifiers, application identifiers, log entries, log entry identifiers, network connection status identifiers, password status (e.g., current, expired, requires updating, and the like) and so forth.

In some embodiments, each device record416may include a digital device identifier that identifies a client device102in communication with the security system108. For example, a device record416may include a device identifier that identifies client device102. The device records416may also include an encrypted password associated with the digital device identifier, and a rule identifier that identifies a rule from a set of rules418. In some embodiments, each of the device records416may include a password identifier instead of the password itself. That password identifier may identify an encrypted password stored elsewhere on the security system108, or other device connected thereto.

It will be appreciated that the device records416may not include a password. In some embodiments, a device record may identify when a password was last changed on a device and/or account. The device record may further indicate whether a change of password is due or whether a change is not due.

In some embodiments, the rules418are each associated with one or more applications206. The rules418may define various attributes, e.g., a rule identifier, a rule name, a rule description, associated application(s), one or more actions to be taken, a privilege-level required to execute the associated application(s), an elevated account identifier for an account with privileges sufficient to execute the associated application(s), and so forth. In some embodiments, the rules418may also include one or more account names, or other account identifiers, for selected accounts that are associated with the rule.

For example, a rule418may be named “Calc with PBPS Run As” and specify that associated user accounts206may execute the Windows CALC.EXE application with account credentials stored on the security system108or otherwise. The associated accounts206may be specifically defined in the rule418, or they may be separately defined by the agent202or security system108(e.g., by a table or other data structure defining associations between the rules and applicable accounts or groups of accounts). In some embodiments, the rules418may also define encryption/decryption protocols used by the security system encrypt/decrypt module414, discussed below.

In some embodiments, the rules418may define any of the following attributes and/or conditions:Rule Identifier: Identifier that uniquely identifies a rule418.Rule Name: Name of the rule418(e.g., Calc.exe with PBSW)Applications: Selected applications206, and/or any selected linked applications206, associated with the rule418.Actions: commands and/or functions associated with the rule418. For example, actions may include “RUN AS” using true elevated privileges retrieved from the security system108.Accounts: Selected accounts204associated with the rule418. Execution of an associated selected application, and/or any selected linked applications, by users associated with the selected accounts204may trigger the rule418.

In some embodiments, the security system management module402comprises a library of executable instructions each of which may be executable by a processor (e.g., a processor804further described with regard toFIG. 8) for performing any of the aforementioned operations. The library may comprise any number of methods (e.g., one or more programs) stored in the library may be configured to change the password to an SQL database. It will be appreciated that the security system management database404may be any structure (e.g., active database, relational database, table, and so forth, and the like) suitable for storing the aforementioned records.

The security system privilege module408may be configured to execute rules418to approve or deny privilege requests103a,retrieve true elevated privileges for approved requests103a,and/or generate privilege responses103b.

The security system authentication module410may be configured to authenticate a source of messages sent to the security system108. Thus, for example, the security system authentication module410may verify that the privilege request103aactually originated from the client device102, as opposed to an illegitimate device, such as a device used by a hacker in a man-in-the-middle attack. The security system authentication module410may authenticate a source of incoming messages based on authentication data included in the message.

The security system communication module412may be configured to provide communication between the security system108and the client device102. In some embodiments, the security system communication module412may also be configured to communicate between the security system108and the security agent202. The security system communication module412may also be configured to establish an encrypted communication (e.g., VPN, HTTPS, SSL, and so forth) with the client device102and/or the security agent202.

The security system encrypt/decrypt module414may be configured to provide encryption, decryption, or other security measures for the security system108. For example, the security system encrypt/decrypt module414may be able to encrypt privilege response103bsent to the client device102, and decrypt privilege requests103areceived from the client device102. In some embodiments, the security system encrypt/decrypt module414issues a program key. A program key may be an SSH DSS private key or an X509v3 client certificate, for example. The security system108may issue a program key for use on behalf a program account. In some embodiments, the program key may be a required parameter for API functions.

In some embodiments, the security system108does not allow direct access to the operating system on the security system108. Further, the security system108may comprise a firewall (e.g., with IPSEC support) to prevent hacking. Moreover, the security system108may perform encryption, such as FIPS-140 validated components, and perform hard disk AES 256-bit encryption for whole disk encryption. Passwords, once generated, may be stored with x509v3 certificates. In some embodiments, inbound connections may be only through HTTPS and SSH. The security system108may also support single- or two-factor authentication using LDAP Active Directory, SecureID, Safeword, and x509v3 certificates. The security system108may perform any or more than the functions listed herein.

As discussed herein, one or more software programs comprising instructions capable of being executable by a processor (e.g., processor804described with regard toFIG. 8) may perform one or more of the functions of the modules, databases, or agents described herein. In another example, circuitry may perform the same or similar functions. The circuitry may utilize, for example, an ASIC or other processing device.

Alternative embodiments may comprise more, less, or functionally equivalent modules, agents, or databases, and still be within the scope of present embodiments. For example, as previously discussed, the functions of the various modules, agents, or databases may be combined or divided differently. It will also be appreciated that some of the modules identified inFIG. 4are optional.

FIG. 5is a flow block diagram of one embodiment of a method of operation for an example security agent according to some embodiments.FIG. 5is an example method of operation for an example security agent202according to some embodiments. In some embodiments, operation of the security agent202may include a greater or lesser number of such steps.

In step502, the security agent202, executed by client device102, generates and/or stores agent privilege rules320. The privilege rules320may be stored in a memory that may be hardware (e.g., SSD, HDD, RAM, and the like), software (e.g., database, table, and so forth), or combination thereof. The agent privilege rules320may include, for example, a list of applications managed by the security system108, associated accounts204and/or applications206, and so forth. In some embodiments, the agent privilege rules320are generated by a security agent management module302, and/or retrieved from the security system108, and stored in rules database304.

In step504, the security agent202detects and/or intercepts an instruction to execute an application and/or any linked applications. For example, the application may be a local application206residing on the client device102, and a linked application may be an application residing on a remote device (e.g., database124). The applications may be linked via a network (e.g., network126).

In various embodiments, the security agent202may detect and/or intercept instructions to execute any of the applications206, and/or a subset of the applications206. For example, a subset of the applications206may comprise applications managed by the security system108, e.g., as defined by the agent privilege rules320. By way of further example, if an instruction is detected for an application which is not managed by the security system108, the security agent202may ignore the instruction and allow the instruction be processed without interception and/or further interruption. In some embodiments, rather than intercepting the instruction, the security agent202may terminate the instruction and/or issue a new instruction to execute the application. In various embodiments, the agent monitor module308may detect, intercept, and/or terminate instructions to execute an application and/or any linked applications.

In step506, the security agent202determines whether an elevated privilege is required to execute an application and/or any linked applications. For example, the security agent202may determine that a user launching a client application (e.g., an MS Access database client application) on the client device102may have sufficient privileges to successfully launch that client application, but insufficient privileges to launch a linked server application (e.g., MS Access database server application) on a remote device (e.g., database124). Accordingly, the security agent202may determine an elevated privilege is required for the linked application. In some embodiments, the agent monitor module508may determine if the application and/or any linked applications require elevated privileges.

In step508, if an elevated privilege is not required to execute the application and/or any linked applications, the security agent202may let application execution proceed without further intervention. In step510, if an elevated privilege is required for the application and/or any linked applications, the security agent202may identify one or more attributes of the application and/or linked applications requiring the privilege elevation. In some embodiments, agent application identification module310may identify the one or more application attributes.

In step512, the security agent202may determine if the application and/or any linked applications requiring elevated privileges are managed by the security system108. If the application and/or any linked applications requiring elevated privileges are not managed by the security system108, e.g., as determined based on rules320, the security agent202may deny application execution and/or prompt the user for elevated credentials (step514). In some embodiments, the agent privilege module312may determine if the application and/or any linked applications requiring elevated privileges are managed by the security system108.

In step516, the security agent202may generate a privilege request103a.The privilege request103may be based on the one or more identified application attributes and/or associated rules320. For example, the privilege request103amay include an application identifier associated with the application requiring elevated privileges, an account identifier associated with the user that issued the instruction to execute the application requiring elevated privileges, a client device identifier associated with the application requiring elevated privileges, and so forth. In some embodiments, agent privilege module312and/or the agent communication module316may generate the privilege request103a.

In step518, the security agent202may communicate the privilege request103ato the security system108. In some embodiments, the request103amay be encrypted by agent encrypt/decrypt module314, and/or the agent communication module316may communicate the request103avia network126.

In step520, the security agent202may receive a privilege response103bfrom the security system108. If the request103awas denied (step522) by the security system108, the response103bmay deny application execution and/or prompt the user from elevated credentials (step514). If the request103awas approved by the security system108, the privilege response103bmay include true elevated privileges. For example, the true elevated privileges may comprise account credentials (e.g., username and password) associated with an administrator account. In some embodiments, agent communication module316may receive the privilege response103b, agent authentication module318may authenticate a source of the response103b(e.g., security system108), and/or agent encrypt/decrypt module314may decrypt the response103b.

In step524, if the request103awas approved by the security system108, the security agent202may cause the execution of the application and/or any linked applications requiring elevated privileges. For example, the application and/or any linked applications may be executed with a “RUN AS” command using the true elevated privileges included in the privilege response103b.In some embodiments, the security agent202may terminate the detected instruction and cause a new execution of the application and/or linked applications using the true elevated privileges included in the privilege response103b.In some embodiments, agent privilege module312may cause the execution of the application and/or linked applications based on one or more associated rules320.

FIG. 6is a flow block diagram of one embodiment of a method of operation for an example security agent according to some embodiments.FIG. 6is an example method of operation for an example security agent202according to some embodiments. In some embodiments, operation of the security agent202may include a greater or lesser number of such steps.

In step602, the security agent202, executed by client device102, generates and/or stores agent privilege rules320. The privilege rules320may be stored in a memory that may be hardware (e.g., SSD, HDD, RAM, and the like), software (e.g., database, table, and so forth), or combination thereof. The agent privilege rules320may include, for example, a list of applications managed by the security system108, associated accounts204and/or applications206, and so forth. In some embodiments, the agent privilege rules320are generated by a security agent management module302, and/or retrieved from the security system108, and stored in agent rules database304.

In step604, the security agent202detects and/or intercepts an instruction to execute a first application206on the client device102. For example, the first application206may be a client application, such as an MS Access database client application. In some embodiments, agent monitor module308detects and/or intercepts the instruction.

In various embodiments, the security agent202may detect and/or intercept instructions to execute any of the applications206, and/or a subset of the applications206, as discussed above. In some embodiments, as discussed above, rather than intercepting the instruction, the security agent202may terminate the instruction and/or issue a new instruction to execute the application. In various embodiments, the agent monitor module308may detect, intercept, and/or terminate instructions to execute an application and/or any linked applications.

In step606, the security agent202determines whether execution of a second application (or, linked application) linked to the first application, e.g., via network126, requires an elevated privilege. For example, the second application may be a server application, such as an MS Access database server application (e.g., residing on databases124). In some embodiments, the agent privilege module312determines whether the elevated privilege is required for the second application based on one or more associated rules320.

In step608, if the second application requires the elevated privilege to execute, the security agent202may generate a privilege request103a.The privilege request103may be based on one or more associated rules320. For example, the privilege request103amay include an application identifier associated with the first application and/or second application, an account identifier associated with the user that issued the instruction to execute the first application, a client device identifier(s) associated with the first application and/or second application, and so forth. In some embodiments, agent privilege module312and/or the agent communication module316may generate the privilege request103a.

In step610, the security agent202may communicate the privilege request103ato the security system108. In some embodiments, the request103amay be encrypted by agent encrypt/decrypt module314, and/or the agent communication module316may communicate the request103avia the network126.

In step612, the security agent202may receive a privilege response103bfrom the security system108. If the request103awas approved by the security system108, the privilege response103bmay include true elevated privileges. For example, the true elevated privileges may comprise account credentials (e.g., username and password) associated with an administrator account. In some embodiments, the agent communication module316may receive the privilege response103b,agent authentication module318may authenticate a source of the response103b(e.g., security system108), and/or agent encrypt/decrypt module314may decrypt the response103b.

In step614, the security agent202may cause the execution of the first application and/or second application using the true elevated privileges included in the privilege response103b.For example, the first application and/or second application may be executed with a “RUN AS” command using the true elevated privileges included in the privilege response103b.In some embodiments, the security agent202may terminate the detected instruction and cause a new execution of the first application and/or second application using the true elevated privileges included in the privilege response103b.In some embodiments, the agent privilege module312may cause the execution of the first application and/or second application based on one or more associated rules320.

FIG. 7a flow block diagram of one embodiment of a method of operation for an example security system according to some embodiments.FIG. 7is an example method of operation for an example security system108according to some embodiments. In some embodiments, operation of the security system108may include a greater or lesser number of such steps.

In step702, the security system108generates and stores device records416in a memory. The memory may be hardware (e.g., SSD, HDD, RAM, and any other kind of computer readable media), software (e.g., database404), or combination thereof. In some embodiments, the security management module402generates and/or stores the device records416.

In step704, the security system108generates and stores security system privilege rules418. The security system privilege rules418may be stored in a memory that may be hardware (e.g., SSD, HDD, RAM, and the like), software (e.g., database, table, and so forth), or combination thereof. The security system privilege rules418may include, for example, a list of applications managed by the security system108, associated accounts204and/or applications206, and so forth. In some embodiments, the security system privilege rules418are generated by a security system management module402, and/or stored in rules database406.

In step706, the security system108may receive a privilege request103afrom the client device102. In some embodiments, the communication module412may receive the request103a, the authentication module410may authenticate a source of the request (e.g., client device102), and/or encrypt/decrypt module414may decrypt the request103a.

In step708, the security system108may approve or deny the request103a.In some embodiments, security system privilege module408approves or denies the request103abased on one or more associated rules418.

In step710, if the request103ais denied, the security system108may generate a denial response103band communicate the denial response to the client device102(step712). In some embodiments, the security system privilege module408and/or communication module412may generate and/or transmit the denial response103b.In some embodiments, the encrypt/decrypt module414may encrypt the denial response103bprior to transmission to the client device102.

In step714, if the request103ais approved, the security system108may retrieve true elevated privileges based on the request103aand/or an associated rule418. In some embodiments, the security system privilege module408may retrieve the true elevated privileges.

In step716, the security system108may generate privilege response103band/or transmit the response103bto the client device102(step718). For example, the privilege response103bmay include the retrieved true elevated privileges. In some embodiments, the security system privilege module408and/or communication module412may generate and/or transmit the response103b.In some embodiments, the encrypt/decrypt module414may encrypt the response103bprior to transmission to the client device102.

In step720, the security system108may receive a password update request.

FIG. 8is a block diagram of one embodiment of a digital device according to some embodiments.FIG. 8is a block diagram of an example digital device802according to some embodiments. Any of the client device102, the manager device104, the administrator device106, the security system108, routers/switches110, firewalls112, the windows servers114, the Unix servers116, the Linux servers118, the AS/400 servers120, the z/OS mainframes122, and databases124may be an instance of the digital device802. The digital device802comprises a processor804, memory806, storage808, an input device810, a communication network interface812, and an output device814communicatively coupled to a communication channel816. The processor804is configured to execute executable instructions (e.g., programs). In some embodiments, the processor804comprises circuitry or any processor capable of processing the executable instructions.

The memory806stores data. Some examples of memory806include storage devices, such as RAM, ROM, RAM cache, virtual memory, and so forth. In various embodiments, working data is stored within the memory806. The data within the memory806may be cleared or ultimately transferred to the storage808.

The storage808includes any storage configured to retrieve and store data. Some examples of the storage808include flash drives, hard drives, optical drives, and/or magnetic tape. Each of the memory system806and the storage system808comprises a computer-readable medium, which stores instructions or programs executable by processor804.

The input device810is any device that inputs data (e.g., mouse and keyboard). The output device814outputs data (e.g., a speaker or display). It will be appreciated that the storage808, input device810, and output device814may be optional. For example, the routers/switchers110may comprise the processor804and memory806as well as a device to receive and output data (e.g., the communication network interface812and/or the output device814).

The communication network interface (com. network interface)812may be coupled to a network (e.g., network126) via the link818. The communication network interface812may support communication over an Ethernet connection, a serial connection, a parallel connection, and/or an ATA connection. The communication network interface812may also support wireless communication (e.g., 802.11 a/b/g/n, WiMax, LTE, Wi-Fi). It will be apparent to those skilled in the art that the communication network interface812may support many wired and wireless standards.

It will be appreciated by those skilled in the art that the hardware elements of the digital device802are not limited to those depicted inFIG. 8. A digital device802may comprise more or less hardware, software and/or firmware components than those depicted (e.g., drivers, operating systems, touch screens, biometric analyzers, and so forth). Further, hardware elements may share functionality and still be within various embodiments described herein. In one example, encoding and/or decoding may be performed by the processor804and/or a co-processor located on a GPU (i.e., Nvidia).

It will further be appreciated that although the example method steps described herein (e.g., steps502-524,602-624, and702-718) are described in a specific order, each of the steps may also be performed in a different order. Each of the steps may also be performed sequentially and/or in parallel with one or more of the other steps. In other embodiments, the methods may include a lesser or greater number of such steps.

The above-described functions and components may comprise instructions that are stored on a storage medium such as a computer readable medium. Some examples of instructions include software, program code, and firmware. The instructions may be retrieved and executed by a processor in many ways.

The systems and methods described herein are with reference to example embodiments. It will be appreciated that various modifications may be made and other embodiments may be used without departing from the broader scope of the present disclosure. Therefore, these and other variations upon the example embodiments are intended to be covered by the present disclosure.

The methods and systems disclosed herein are not limited to a particular hardware or software configuration, and may find applicability in many computing or processing environments. The methods and systems may be implemented in hardware or software, or a combination thereof. The methods and systems may be implemented in one or more computer programs, where a computer program may be understood to include one or more processor executable instructions. The computer program(s) may execute on one or more programmable processors, and may be stored on one or more storage mediums (i.e., computer readable medium) readable by the processor (including volatile and non-volatile memory and/or storage elements), one or more input devices, and/or one or more output devices. The processor thus may access one or more input devices to obtain input data, and may access one or more output devices to communicate output data. The input and/or output devices may include one or more of the following: Random Access Memory (RAM), Redundant Array of Independent Disks (RAID), floppy drive, CD, DVD, magnetic disk, internal hard drive, external hard drive, memory stick, or other storage device capable of being accessed by a processor as provided herein, where such aforementioned examples are not exhaustive, and are for illustration and not limitation. Those skilled in the art will appreciate that the RAM, RAID, floppy disks, optical medium (e.g., CD and DVD disks), magnetic disks, internal hard drive, external hard drive, memory stick or other storage device may also be computer readable mediums.

The computer program(s) may be implemented using one or more high level procedural or object-oriented programming languages to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. The language may be compiled or interpreted.

The processor(s) may be embedded in one or more devices that may be operated independently or together in a networked environment, where the network may include, for example, a local area network (LAN), wide area network (WAN), an intranet, the Internet, and/or another network. The network(s) may be wired, wireless, or a combination thereof and may utilize one or more communications protocols to facilitate communications between the different processors. The processors may be configured for distributed processing and may utilize, in some embodiments, a client-server model as needed. Accordingly, the methods and systems may utilize multiple processors and/or processor devices, and the processor instructions may be divided amongst such single or multiple processor/devices.

The device(s) (e.g., computers) that integrate with the processor(s) may include, without limitation, for example, a personal computer(s), workstation (e.g., Sun®, Hewlett Packard®), personal digital assistant (PDA), handheld device such as cellular telephone, laptop, handheld, or another device capable of being integrated with a processor(s) that may operate as provided herein. Accordingly, the devices provided herein are not exhaustive and are provided for illustration and not limitation. Similarly, as used herein a system may be a single digital device (e.g., a computer) or may comprise multiple digital devices.

As used herein, the terms “microprocessor” and “processor,” may be understood to include one or more microprocessors that may communicate in a stand-alone and/or a distributed environment(s), and may thus may be configured to communicate via wired or wireless communications with other processors, wherein such one or more processor may be configured to operate on one or more processor-controlled devices that may be similar or different devices. Use of such “microprocessor” or “processor” terminology or the like may thus also be understood to include a central processing unit, an arithmetic logic unit, an application-specific integrated circuit (IC), and/or a task engine, with such examples provided for illustration and not limitation.

Furthermore, memory, unless otherwise specified, may include, without limitation, one or more processor-readable and accessible memory elements and/or components that may be internal to the processor-controlled device, external to the processor-controlled device, and/or may be accessed via a wired or wireless network using a variety of communications protocols, and unless otherwise specified, may be arranged to include a combination of external and internal memory devices, where such memory may be contiguous and/or partitioned based on the application. Accordingly, references to a database may be understood to include one or more memory associations, where such references may include commercially available database products (e.g., SQL, Informix®, Oracle®) and also proprietary databases, and may also include other structures for associating memory such as links, queues, graphs, trees, with such structures provided for illustration and not limitation.

References to a network, unless provided otherwise, may include, without limitation, one or more intranets and/or the Internet. References herein to microprocessor instructions or microprocessor-executable instructions, in accordance with the above, may be understood to include programmable hardware.

Although the methods and systems have been described relative to a specific embodiment thereof, they are not so limited. Obviously, many modifications and variations may become apparent in light of the above teachings. Many additional changes in the details, materials, and arrangement of parts, herein described and illustrated, may be made by those skilled in the art. Accordingly, it will be understood that the disclosed methods and systems are not to be limited to the embodiments disclosed herein, may include practices otherwise than specifically described, and are to be interpreted as broadly as allowed under the law.

While various embodiments have been disclosed and described in detail, various modifications and improvements thereon will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present description is not to be limited by the foregoing examples, but is to be understood in the broadest sense allowable by law.

While the foregoing written description enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. These embodiments therefore are not be limited by the above described illustrated embodiments, methods, and examples, but by all embodiments and methods within the scope as claimed.