|Publication number||US7421739 B2|
|Application number||US 10/711,768|
|Publication date||Sep 2, 2008|
|Filing date||Oct 4, 2004|
|Priority date||Oct 4, 2004|
|Also published as||US20060075488|
|Publication number||10711768, 711768, US 7421739 B2, US 7421739B2, US-B2-7421739, US7421739 B2, US7421739B2|
|Inventors||Michael R Barrett, Michael Plummer|
|Original Assignee||American Express Travel Related Services Company, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (25), Referenced by (4), Classifications (8), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application generally relates to software security applications, and more particularly, to a system and method for monitoring and ensuring data integrity in security systems.
An Enterprise Security System (ESS) typically includes a single, central, security repository such that, for example, ESS may register and control access for all users of systems residing on all platforms. As such, if a user desires access to a specific system and/or application, a front-end ESS system may control the access.
Remote Access Control Facility (RACF) is known as the back-end security engine used in IBM mainframe platforms. Because RACF terminology and coding language may be difficult to learn and understand, the ESS often re-formats security commands into RACF commands because ESS is easier to use and understand. Thus, RACF security may be updated by individuals and/or programs that do not know RACF terminology. While security updates should originate in ESS and be transferred to RACF, sometimes the updates originate in the RACF back-end. Accordingly, these inconsistencies often cause computing access failures, delays, and confusion.
The invention discloses systems and methods for facilitating the monitoring and ensuring data integrity in security across multiple platforms. The invention also provides a substantially seamless security administration across multiple platforms by, for example, monitoring and/or preventing back-end updates to an Enterprise Security System (ESS) to ensure that security access is controlled from one, centralized location. More particularly, in one embodiment, the system detects a back-end security update in a back-end database, compares the back-end security update to front-end security information stored on a front-end database; and reconstructs the back-end database to conform to the front-end database.
A more complete understanding of the present invention may be derived by referring to the detailed description and claims when considered in connection with the figures, where like reference numbers refer to similar elements throughout the figures, and:
The detailed description of exemplary embodiments of the invention herein makes reference to the accompanying drawings, which show the exemplary embodiment by way of illustration and its best mode. While these exemplary embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, it should be understood that other embodiments may be realized and that logical and mechanical changes may be made without departing from the spirit and scope of the invention. Thus, the detailed description herein is presented for purposes of illustration only and not of limitation. For example, the steps recited in any of the method or process descriptions may be executed in any order and are not limited to the order presented.
Moreover, it should be appreciated that the particular implementations shown and described herein are illustrative of the invention and its best mode and are not intended to otherwise limit the scope of the present invention in any way. Indeed, for the sake of brevity, certain sub-components of the individual operating components, conventional data networking, application development and other functional aspects of the systems may not be described in detail herein. Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in a practical system.
As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as a method, a data processing system, a device for data processing, and/or a computer program product. Accordingly, the present invention may take the form of an entirely software embodiment, an entirely hardware embodiment, or an embodiment combining aspects of both software and hardware. Furthermore, the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program code means embodied in the storage medium. Any suitable computer-readable storage medium may be utilized, including hard disks, CD-ROM, optical storage devices, magnetic storage devices, and/or the like.
The present invention may be described herein in terms of functional block components, screen shots, optional selections and various processing steps. It should be appreciated that such functional blocks may be realized by any number of hardware and/or software components configured to perform the specified functions. For example, the present invention may employ various integrated circuit components (e.g., memory elements, processing elements, logic elements, look-up tables, and the like), which may carry out a variety of functions under the control of one or more microprocessors or other control devices.
These software components may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks. These software components may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block or blocks. The software components may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.
Accordingly, functional blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions, and program instruction means for performing the specified functions. It will also be understood that each functional block of the block diagrams and flowchart illustrations, and combinations of functional blocks in the block diagrams and flowchart illustrations, can be implemented by either special purpose hardware-based computer systems which perform the specified functions or steps, or suitable combinations of special purpose hardware and computer instructions.
The software components of the present invention may be implemented with any programming or scripting language such as C, C++, Java, COBOL, assembler, PERL, Visual Basic, SQL Stored Procedures, extensible markup language (XML), with the various algorithms being implemented with any combination of data structures, objects, processes, routines or other programming elements. Further, it should be noted that the present invention may employ any number of conventional techniques for data transmission, signaling, data processing, network control, and the like. For a basic introduction of cryptography and network security, the following may be helpful references: (1) “Applied Cryptography: Protocols, Algorithms, And Source Code In C,” by Bruce Schneier, published by John Wiley & Sons (second edition, 1996); (2) “Java Cryptography,” by Jonathan Knudson, published by O'Reilly & Associates (1998); (3) “Cryptography & Network Security: Principles & Practice,” by William Stalling, published by Prentice Hall; all of which are hereby incorporated by reference.
In general, in accordance with various aspects and embodiments of the present invention, a backfeed process for an Enterprise Security System (ESS) is provided which is configured to, for example, provide monitoring and ensuring data integrity of back-end updates originating in RACF from being non-conforming to the security information updated and available on the ESS system. By monitoring and ensuring data integrity, the backfeed process and/or any other part of an ESS may be configured to monitor update information, detect update information, analyze update information, transfer update information, compare update information, report update information, change update information and/or execute any other process to ensure the integrity of the data and/or other update information on the ESS system. The ESS system includes an administration system that allows substantially seamless security across multiple platforms. ESS allows for centralized updates to security protocols, such as, for example, deletion of IDs, updating of passwords, and access control for departments, groups, users and resources. ESS is configured to manage the security engine (e.g., IBM's Remote Access Control Facility (RACF)) for all or most computing platforms. While an exemplary RACF engine is discussed and depicted for purposes of illustration throughout, the security engine may be any known security engine in the art, including, but not limited to RACF, Computer Associate's Access Control Facility 2 (CA-ACF2), and/or Lightweight Directory Access Protocol (LDAP). For example, users may use ESS, but the users may not understand RACF, CA-ACF2, and/or LADP terminology, but the system reformats security requests into RACF, CA-ACF2, and/or LADP commands. ESS may also be configured to operate with one or more processes to find and/or send updated security commands (i.e., RACF commands) from the front-end ESS system to the back-end (i.e., RACF) security system.
With reference to
Repository 110 may be structured with one or more ESS master tables 112, one or more acknowledgement tables 114, and/or one or more ESS audit tables 116 to facilitate storing and processing database information. Master tables 112 may be configured to store a copy of the information stored on the back-end RACF databases. Acknowledgement tables 114 may be used to facilitate the transfer of information from repository 110 to the RACF databases. Acknowledgement tables 114 may be used to facilitate writing ESS update information into RACF command format. Audit tables 116 may be configured to compare and display the information from RACF databases before and after the RACF databases are updated. Repository 110 may include one or more other security and/or encryption schemes to limit access. For example, repository 110 may be configured with any of various suitable security features, such as firewalls, access codes, encryption, de-encryption, compression, decompression, and/or the like. Repository 110 may be configured to be implemented within IBM's DB/2 relational database management system for Multiple Virtual storage (MVS) operating system users. Repository 110 may be configured for administrative use only. As a result, the individual security databases used by platform-specific security managers may still contain the information needed to perform local security authorizations. That is, a front-end user/administrator may use ESS to provide a second user access to a resource without the user/administrator having access to the resource himself.
Master tables 112, acknowledgement tables 114, and/or audit tables 116 may be configured to permanently and/or temporarily store RACF information before it is applied to RACF. Information may include update information, status changes, user-IDs, commands, revocation information and/or authorization information. In one embodiment, passwords associated with user IDs may not be stored in repository 110.
Repository tables 112, 114, and 116 may be configured to facilitate encryption of data. In one embodiment, every row within tables 112, 114, and/or 116 may be stamped with a non-forgeable token. Authorized processes may be configured to generate this token and write rows into the tables. Processes running on a system may be required to validate the token in order to proceed. Encryption tokens may also be used for the transfer of information between ESS and Transaction Processing Facility (TPF) systems and/or ESS and any other system.
Front-end 100 may include various processes in accordance with the present invention to facilitate updating and tracking security administration. Again, with reference to an exemplary embodiment depicted in
Front-end 100 may also be configured to be consistent with industry directions, particularly Distributed Computing Environment (DCE) and DCE Security Services (i.e., Kerberos). Front-end 100 may be configured to be inter-operable with other security managers such as RACF and TPF products. Front-end 100 may also be configured to link separate security managers together. Front-end 100 may also be configured to facilitate access to administration transactions from any CPU. For example, front-end 100 may use the Multiple Systems Coupling (MSC) feature of IMS/TM to provide access to users across all platforms. The transactions may be defined as remote on remote CPUs in order to enable IMS to remotely schedule the transactions to execute on the system where ESS resides.
DSA 140 may also be configured to provide a “collector option ” to support BP 200. For example, DSA 140 may be one or more computing platforms. DSA 140 may be configured to use a specific address (e.g., DSA collector 160) to facilitate capture and/or transfer of updates to and from RACF databases. DSA collector 160 may be configured to use term rewriting system (TRS) exits to transform terms (i.e., expressions, strings, etc.) into equivalent terms. DSA collector 160 may use the TRS exits to facilitate the capture and/or transfer of RACF updates to BP 200. DSA collector 160 may also be configured to transfer RACF changes across multiple CPUs 105. In another embodiment, each CPU 105 may be configured with individual DSA collectors 160 to facilitate the capture and/or transfer of RACF updates to/from local BPs 200.
An exemplary overview of the back-end 220, in accordance with the present invention, is illustrated in
As used herein, user 102 may include any external or internal person, employee, officer, entity, merchant, business, client, corporation, customer, contractor, administrator, operator, customer service representative, third-party provider, user, web service consumer, computing system, hardware and/or software. User 102 may interact through an interface 104 via any communication device, protocol, hardware and/or software discussed herein. User 102 may be in a home or business environment with access to a network. In an exemplary embodiment, access is through the Internet through a commercially available web-browser software package.
As used herein, the term network shall include any electronic communications means which incorporate both hardware and software components of such. For example, a network may include any distributed system, such as a mainframe complex, thin cable network, Ethernet, token ring network, Intranet, Internet, Local Area Network (LAN), wide area network (WAN), and/or any other method or system of communications described herein.
Resource 230 may be any application, transaction process, database, protocol, system, script, hardware, software, program, equipment, area, lab, device, and/or any other type of resource. Authorized, as used herein, may include a user possessing clearance, passwords, identification, and/or any other pre-approved and/or other secure means to access a resource.
The user computer and/or interface 104 may include any remote interface or terminal through which user 102 may remotely access any option or function associated with front end 100 and/or back-end 220. The user computer and/or interface 104 may include any of the input devices, computing units, or computing systems described herein, such as, for example, kiosk, personal digital assistant, handheld computer (e.g., Palm Pilot®, Blackberry®), cellular phone and/or the like. Access may also be obtained using a conventional card reader which recognizes a magnetic stripe or bar code associated with appropriate user identification information, a biometric device, a smart card reader which recognizes information stored on a microchip integrated with appropriate user identification information, a pervasive computing and/or system (i.e., a domestic appliance or financial institution network), and/or any other device capable of accessing, interacting, transmitting, receiving, downloading, and/or uploading application related data transmitted electronically, magnetically, optically, and/or the like.
In an exemplary embodiment, and with reference to
The computing units discussed herein may be connected with each other via a data communication network, such as, for example, interface 104. Interface 104 may be a public network and assumed to be insecure and open to eavesdroppers. In the illustrated implementation, interface 104 may be embodied as the Internet. In this context, the computers may or may not be connected to the Internet at all times. For instance, user 102 may be using a computer that employs a modem to occasionally connect to the Internet, whereas the various components, programs and applications might be running on servers that maintain a permanent connection to the Internet. Specific information related to the protocols, standards, and application software utilized in connection with the Internet may not be discussed herein. For further information regarding such details, see, for example, D
A variety of conventional communications media and protocols may be used for data links such as, for example, a connection to an Internet Service Provider (ISP) over the local loop as is typically used in connection with standard modem communication, cable modem, Dish networks, ISDN, Digital Subscriber Line (DSL), or various wireless communication methods. User 102 might also reside within a local area network (LAN), which interfaces to network via a leased line (T1, D3, etc.). Such communication methods are well known in the art, and are covered in a variety of standard texts. See, e.g., G
Front-end 100 and/or back-end 220 may be a stand-alone system or incorporated into any pre-existing network or via any software and/or hardware customization or upgrades. Front-end 100 and/or back-end 220 may include any hardware and/or software discussed herein. Front-end 100 and/or back-end 220 may include a host server or other computing systems including a processor for processing digital data, a memory coupled to said processor for storing digital data, an input digitizer coupled to the processor for inputting digital data, an application program stored in said memory and accessible by said processor for directing processing of digital data by said processor, a display coupled to the processor and memory for displaying information derived from digital data processed by said processor and a plurality of databases, said databases including client data, employee data, resource data, application and/or like data that could be used in association with the present invention. As those skilled in the art will appreciate, front-end 100 and/or back-end 220 will typically include an operating system (e.g., MVS, Windows NT, 95/98/2000/XP, Linux, Solaris, AIX, etc.) as well as various conventional support software and drivers typically associated with computers.
Similarly, front-end 100 and/or back-end 220 may include, or be used in conjunction with, any type of personal computer, network computer, workstation, minicomputer, mainframe, or the like running any operating system such as any version of Windows, Windows NT, Windows2000, Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris or the like. Moreover, the invention may be implemented using TCP/IP communications protocols, IPX, Appletalk, IP-6, NetBIOS, OSI or any number of existing or future protocols.
Any databases discussed herein, such as database 215 and/or repository 110, may be any type of database, such as relational, hierarchical, graphical, object-oriented, and/or other database configurations. Common database products that may be used to implement the databases include the aforementioned DB/2 system by IBM (White Plains, N.Y.), various database products available from Oracle Corporation (Redwood Shores, Calif.), Microsoft Access or Microsoft SQL Server by Microsoft Corporation (Redmond, Wash.), or any other suitable database product. Moreover, the databases may be organized in any suitable manner, for example, as data tables or lookup tables. Each record may be a single file, a series of files, a linked series of data fields or any other data structure. Association of certain data may be accomplished through any desired data association technique such as those known or practiced in the art. For example, the association may be accomplished either manually or automatically. Automatic association techniques may include, for example, a database search, a database merge, GREP, AGREP, SQL, and/or the like. The association step may be accomplished by a database merge function, for example, using a “key field” in pre-selected databases or data sectors.
More particularly, a “key field” partitions the database according to the high-level class of objects defined by the key field. For example, certain types of data may be designated as a key field in a plurality of related data tables and the data tables may then be linked on the basis of the type of data in the key field. In this regard, the data corresponding to the key field in each of the linked data tables is preferably the same or of the same type. However, data tables having similar, though not identical, data in the key fields may also be linked by using AGREP, for example. In accordance with one aspect of the present invention, any suitable data storage technique may be utilized to store data without a standard format. Data sets may be stored using any suitable technique, including, for example, storing individual files using an ISO/IEC 7816-4 file structure; implementing a domain whereby a dedicated file is selected that exposes one or more elementary files containing one or more data sets; using data sets stored in individual files using a hierarchical filing system ; data sets stored as records in a single file (including compression, SQL accessible, hashed via one or more keys, numeric, alphabetical by first tuple, etc.); block of binary (BLOB); stored as ungrouped data elements encoded using ISO/IEC 7816-6 data elements; stored as ungrouped data elements encoded using ISO/IEC Abstract Syntax Notation (ASN.1) as in ISO/IEC 8824 and 8825; and/or other proprietary techniques that may include fractal compression methods, image compression methods, etc.
In one exemplary embodiment, the ability to store a wide variety of information in different formats is facilitated by storing the information as a Block of Binary (BLOB). Thus, any binary information can be stored in a storage space associated with a data set. The BLOB method may store data sets as ungrouped data elements formatted as a block of binary via a fixed memory offset using either fixed storage allocation, circular queue techniques, or best practices with respect to memory management (e.g., paged memory, least recently used, etc.). By using BLOB methods, the ability to store various data sets that have different formats facilitates the storage of data associated with a wide variety of system components by multiple and unrelated owners of the data sets. For example, a first data set which may be stored may be provided by a first issuer, a second data set which may be stored may be provided by an unrelated second issuer, and yet a third data set which may be stored, may be provided by an third issuer unrelated to the first and second issuer. Each of these three exemplary data sets may contain different information that is stored using different data storage formats and/or techniques. Further, each data set may contain subsets of data, which also may be distinct from other subsets.
As stated above, in various embodiments of the present invention, the data can be stored without regard to a common format. However, in one exemplary embodiment of the present invention, the data set (e.g., BLOB) may be annotated in a standard manner when provided for manipulating the data onto the network. The annotation may comprise a short header, trailer, or other appropriate indicator related to each data set that is configured to convey information useful in managing the various data sets. For example, the annotation may be called a “condition header,” “header,” “trailer,” or “status,” herein, and may comprise an indication of the status of the data set or may include an identifier correlated to a specific issuer or owner of the data. In one example, the first three bytes of each data set BLOB may be configured or configurable to indicate the status of that particular data set (e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED). Subsequent bytes of data may be used to indicate for example, the identity of the issuer, user, transaction/membership account identifier or the like. Each of these condition annotations is further discussed herein.
BP 200 may be configured to operate alongside RACF 210 to monitor security updates originating within RACF 210. BP 200 may also be configured to compare the information in the RACF updates with information stored in master tables 112 within repository 110. If the information from the RACF updates does not match the master table 112 information, BP 200 may be used to facilitate updating repository 110 with the information from RACF 210. BP 200 may also be configured to facilitate restoration of RACF 210 with the information stored in master tables 112. The latter option may be used to prevent back-end updates to the RACF security system. These BP 200 configurations will be described in greater detail below. In an exemplary embodiment, BP 200 may operate in real-time. In this context, “real-time” may include BP 200 information being immediately, or nearly immediately, updated at the time the changes or other transactions are completed. As such, BP 200 may immediately view or manage the changes within RACF 210 and repository 110 and/or RACF 210 may be immediately updated to ensure seamless security. However, one skilled in the art will appreciate that BP 200 may operate in any less than real-time mode, such as, for example, batch processing. In another exemplary embodiment, BP 200 may operate partially in real-time and partially in batch mode, wherein during batch mode, RACF 210 and/or repository 110 security information is stored, and periodically updated to repository 110 and/or RACF 210.
To better understand the backfeed update process of the present invention, an exemplary RACF/TPF update process 124 is set forth in
In an exemplary method, UP 124 may initiate when security information is updated (step 301) by a user and/or system in front-end 100. The information may then be stored (step 303) in command data format on repository 110. UP 124 may then read the commands (step 305) from acknowledgement table 114 within repository 110. UP 124 may be configured to read the commands by selecting all eligible rows from acknowledgement table 114 and sort them into ascending date/time-stamp order to ensure correct sequencing. Upon reading the commands, UP 124 may be configured to decrypt the commands (step 307) for execution (step 309). During the execution step, UP 124 may be configured to use other applications, such as, for example, a TSO command processor, to facilitate execution of the commands. If the commands succeed, UP 124 may delete (step 311) the commands from repository 110. UP 124 may then use DSA 140 to forward the commands to RACF databases 215 (step 313). Alternatively, if the commands fail, UP 124 may write status information regarding the failure into repository 110 (step 315). UP 124 may also be configured to attempt execution of the next command (step 317).
DSA 140 may be any security administration product used to synchronize the contents of the various RACF databases. In one embodiment, DSA 140 is a Distributed Security Administration product distributed by Plato software. DSA 140 may be configured to communicate with other DSA systems on other CPUs using any communication means known in the art. In one embodiment, DSA 140 may be configured to use one or more Virtual Telecommunications Access Method (VTAM) facilities to facilitate communication across multiple platforms. DSA 140 may also be configured with a request/acknowledgement based store and forward scheme, a queue capability for updates, encryption and decryption means, modifiable standard exit points, and the aforementioned “collector option.”
The term command, as used herein, may refer to password and/or user ID changes, revocation of user IDs, passwords, resumes of user IDs and passwords, and/or any other RACF-compatible command. Command information may relate to the distribution of security profiles, that is, it may relate to access control between users, groups and resources. For example, front-end 100 may be configured to use architectural hierarchy similar to that of RACF database 215. As such, front-end 100 may group users together based upon the different users' job functionality. In turn, each group may require access to various resources to facilitate the group's job functions. As such, front-end 100 may be configured to connect users to one or more groups (and thereby provide them access to resources associated with each group). DSA 140 may be used to translate and/or transfer front-end 100 security information into this RACF-architectural hierarchy.
In accordance with another aspect of the invention, and illustrated in
User 102 may generate an update (step 401) through back-end 220. In order to detect this back-end update, DSA collector 160 may be configured to receive any back-end update information (step 403) and transfer the update information to BP 200 (step 405). The transfer of update information may occur via a regular call and/or any other communication means described herein. By transferring via a regular call, DSA collector 160 may use the same Task Control Block (TCB) as BP 200 to communicate information about tasks (i.e., back-end updates) within its address space. Through this TCB, BP 200 may use DSA 140 and/or DSA collector 160 to facilitate access to repository 110.
Once BP 200 receives update information from DSA collector 160, BP 200 may be configured to filter (step 407) the information. By filtering, BP 200 may scan the update information from RACF databases 215 to determine whether any of the updates should have been made through front-end 100. For example, it may be desirable to control some security information through back-end 220 instead of front-end 100. BP 200 may filter out the security updates that may originate in back-end 220 so that they are not updated and/or compared with front-end 100 information. BP 200 may be configured to employ naming conventions to facilitate a determination of whether any back-end updates should have been made through front-end 100. For example, if an ESS user-ID has been revoked in back-end 220, BP 200 will be able to detect this revocation. BP 200 may also be configured to transfer information about this back-end revocation to UP 124 using DSA 140 and/or DSA collector 160 (step 409).
UP 124 may be configured to compare the back-end information (i.e., information about the revocation) to information stored in repository 110 (step 411). If the back-end information does not conform to the information in repository 110, UP 124 may reconstruct RACF database 215 (step 413) so that the back-end information conforms to the information stored in repository 110. Alternatively, if the back-end information conforms to the information in repository 110, UP 124 does not proceed and the process terminates (step 415).
To reconstruct RACF database 215, and with reference to an exemplary method depicted in
In accordance with another exemplary embodiment, BP 200 may be configured to route updates that have originated and/or occurred in RACF 210 to a Transaction Processing Facility (TPF) operating system operating on one or more mainframes connected to a computing system. Routing may be used when a user has access to resources controlled by both RACF 210 and TPF. For example, if user 102 with access to RACF and TPF changes his password through front-end 100, DSA 140 may be configured to update all or any portion of RACF databases 215 with the new password. BP 200 may then be used to route the password update to one or more TPF systems. For example, with reference to an exemplary method illustrated in
In another exemplary embodiment, and with reference to
TPF backfeed and/or update processes may be any protocol, software, application, program, script, and/or any other type of process for facilitating transfer of commands from repository 110 tables to one or more TPF systems. TPF backfeed and/or update processes may be configured to use Advanced Program-to-Program Communications (APPC) to facilitate communication and transfer of commands. TPF backfeed and/or update processes may also be configured to employ Common Program Interface (CPI) language capabilities to facilitate communication with remote TPF update programs. The update programs may be partner programs on TPF systems. The update programs may be any protocol, software, application, process, script, and/or any other type of program for facilitating communication with TPF backfeed and/or update processes and updating TPF security databases. The update programs may also be configured to use CPI language capabilities.
Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any or all the claims. As used herein, the terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, no element described herein is required for the practice of the invention unless expressly described as “essential” or “critical.”
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5557747||Jun 22, 1993||Sep 17, 1996||Rogers; Lawrence D.||Network policy implementation system for performing network control operations in response to changes in network state|
|US5611048||May 9, 1994||Mar 11, 1997||International Business Machines Corporation||Remote password administration for a computer network among a plurality of nodes sending a password update message to all nodes and updating on authorized nodes|
|US5694595||Aug 14, 1995||Dec 2, 1997||International Business Machines, Corporation||Remote user profile management administration in a computer network|
|US5822434||Jun 19, 1996||Oct 13, 1998||Sun Microsystems, Inc.||Scheme to allow two computers on a network to upgrade from a non-secured to a secured session|
|US5968176||May 29, 1997||Oct 19, 1999||3Com Corporation||Multilayer firewall system|
|US6158010||Feb 12, 1999||Dec 5, 2000||Crosslogix, Inc.||System and method for maintaining security in a distributed computer network|
|US6243815||Dec 24, 1997||Jun 5, 2001||Anand K. Antur||Method and apparatus for reconfiguring and managing firewalls and security devices|
|US6263446||Nov 19, 1998||Jul 17, 2001||Arcot Systems, Inc.||Method and apparatus for secure distribution of authentication credentials to roaming users|
|US6678826||Sep 9, 1998||Jan 13, 2004||Communications Devices, Inc.||Management system for distributed out-of-band security databases|
|US6678827||May 6, 1999||Jan 13, 2004||Watchguard Technologies, Inc.||Managing multiple network security devices from a manager device|
|US6714930 *||May 31, 2000||Mar 30, 2004||International Business Machines Corporation||Lightweight directory access protocol, (LDAP) trusted processing of unique identifiers|
|US20010007133||Jan 22, 2001||Jul 5, 2001||Mark Moriconi||System and method for maintaining security in a distributed computer network|
|US20010014912||Nov 26, 1997||Aug 16, 2001||International Business Machines Corporation||Distributed security system for a communication network|
|US20010025346||May 18, 2001||Sep 27, 2001||Makoto Kayashima||Security management system and security managing method|
|US20020002677 *||Feb 21, 2001||Jan 3, 2002||International Business Machines Corporation||Data processing system and method|
|US20030028804||Aug 3, 2001||Feb 6, 2003||Noehring Lee P.||Apparatus and method for resolving security association database update coherency in high-speed systems having multiple security channels|
|US20030065942||Sep 28, 2001||Apr 3, 2003||Lineman David J.||Method and apparatus for actively managing security policies for users and computers in a network|
|US20030093690||Nov 15, 2001||May 15, 2003||Stefan Kemper||Computer security with local and remote authentication|
|US20030110397||Jun 26, 2002||Jun 12, 2003||Pervasive Security Systems, Inc.||Guaranteed delivery of changes to security policies in a distributed system|
|US20030115322||Sep 13, 2002||Jun 19, 2003||Moriconi Mark S.||System and method for analyzing security policies in a distributed computer network|
|US20030115484||Sep 13, 2002||Jun 19, 2003||Moriconi Mark S.||System and method for incrementally distributing a security policy in a computer network|
|US20040019807||May 14, 2003||Jan 29, 2004||Zone Labs, Inc.||System And Methodology For Providing Community-Based Security Policies|
|US20040064727||Sep 30, 2002||Apr 1, 2004||Intel Corporation||Method and apparatus for enforcing network security policies|
|US20040083382||Oct 28, 2002||Apr 29, 2004||Secure Computing Corporation||Associative policy model|
|US20040083386||Oct 28, 2002||Apr 29, 2004||Bertrand Marquet||Non-repudiable distributed security policy synchronization|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7930753 *||Jun 30, 2003||Apr 19, 2011||First Data Corporation||Methods and systems for performing security risk assessments of internet merchant entities|
|US8478616 *||Oct 29, 2005||Jul 2, 2013||FrontRange Solutions USA Inc.||Business application development and execution environment|
|US20040073445 *||Jun 30, 2003||Apr 15, 2004||First Data Corporation||Methods and systems for performing security risk assessments of internet merchant entities|
|US20060225032 *||Oct 29, 2005||Oct 5, 2006||Klerk Adrian D||Business application development and execution environment|
|U.S. Classification||726/26, 726/27|
|Cooperative Classification||G06F21/6227, G06F2221/2141, G06F21/64|
|European Classification||G06F21/64, G06F21/62B1|
|Oct 4, 2004||AS||Assignment|
Owner name: AMERICAN EXPRESS TRAVEL RELATED SERVICES COMPANY,
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BARRETT, MICHAEL R;PLUMMER, MICHAEL;REEL/FRAME:015213/0106;SIGNING DATES FROM 20040902 TO 20040921
|Sep 14, 2011||FPAY||Fee payment|
Year of fee payment: 4
|Apr 21, 2014||AS||Assignment|
Owner name: III HOLDINGS 1, LLC, DELAWARE
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AMERICAN EXPRESS TRAVEL RELATED SERVICES COMPANY, INC.;REEL/FRAME:032722/0746
Effective date: 20140324
|Feb 23, 2016||FPAY||Fee payment|
Year of fee payment: 8