ACCESS BEHAVIOR

TECHNICAL FIELD

[0001] The subject matter disclosed herein relates generally to physical access control systems (PACS), and more particularly an access control mapping of a facility to identify spatio-temporal properties of an event to assist in detecting inconsistencies and suspicious access control behavior.

BACKGROUND

[0002] Physical access control systems (PACS) prevent unauthorized individuals access to protected areas. Individuals who have a credential (e.g., card, badge, RFID card, FOB, or mobile device) present it at an access point (e.g., swipe a card at a reader) and the PACS makes an almost immediate decision whether to grant them access (e.g., unlock the door). The decision is usually computed at a controller by checking a permissions database to ascertain whether there is a static permission linked to requester's credential. If the permission(s) are correct, the PACS unlocks the door as requested providing the requestor access. Typically, with static permissions, such a request for access can be made at a given time of the day and access will be granted. In standard deployment of a PACS, a

permission(s) database is maintained at a central server and relevant parts of the permissions database are downloaded to individual controllers that control the locks at the doors.

[0003] When a cardholder swipes a card at a reader, a new record is created in an access event record database, specifying the time of the day, the identity of the cardholder, the identifier of the reader and the response of the system that denies or grants access. The objective of reliable and efficient access control systems is not only to ensure lawful access requests are satisfied, but it is also vital to detect unlawful and suspicious access behavior. Indeed, physical access control systems are facing challenges in detecting and addressing security breaches and violations such as fake cards, cards used by unauthorized persons, or simply misused stolen cards. To address such issues, access controls systems rely on administrator experience and off-line manual audits of access logs to identify potential unlawful/suspicious access events. This type of audit consumes considerable amounts of time and resources. Moreover, manual audits unfortunately, do not guarantee detection of suspicious activities. More importantly, if such suspicious access activities are detected, often, it is too late to address or at least limit the damages of any security breaches. BRIEF SUMMARY

[0004] According to an exemplary embodiment, described herein is A spatio- temporal topology learning system for detection of suspicious access control behavior in a physical access control system (PACS). The spatio-temporal topology learning system including an access pathways learning module configured to determine a set of spatio- temporal properties associated with a resource in the PACS, an inconsistency detection module in operable communication with the access pathways learning module, the inconsistencies detection module configured to analyze a plurality of historical access control events and identify an inconsistency with regard to the set of spatio-temporal properties, and if an inconsistency is detected, at least one of the events is flagged as potentially suspicious access control behavior.

[0005] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the spatio-temporal properties are based on at least one of a cardholder identity , a resource to which access is desired, the resource associated with a reader and a access point controlling access to the resource, a time zone specifying the time of the day when access to the resource is required, and a history of access events.

[0006] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the spatio-temporal properties are based on a rule that a first reader can be reached from a second reader if there exists two consecutive access events for any cardholder that accesses the first reader and the second reader.

[0007] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the spatio-temporal properties include a reachability graph.

[0008] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include refining the reachability graph based on an initial estimate of the notional distance between readers determined as the minimum difference between access event time stamps at two connected readers.

[0009] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include refining the reachability graph by labeling access pathways based on a profile of at least one cardholder of a plurality of cardholders in the PACS. [0010] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include refining the reachability graph based on at least one of attributes associated with at least one user and an intelligent map of a facility using the PACS to form a refined reachability graph.

[001 1] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the attribute is specific to the user.

[0012] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the attribute is generic to a group of users.

[0013] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the attribute is at least one of a user's role, a user's department, a badge type, a badge/card ID.

[0014] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that an inconsistency includes any instance where consecutive events are impossible.

[0015] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that an inconsistency includes a cardholder accessing a first access point at a selected physical distance from a second access point within less than a selected time.

[0016] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that an inconsistency includes a card holder accessing a first access point without also having accessed a second access point in between.

[0017] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that an inconsistency includes a card holder accessing a first access point without also having accessed a second access point in between the first access point and a third access point.

[0018] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the flagged event is reported and provided with an explanation of a context of the inconsistency.

[0019] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include updating a knowledge database of

inconsistencies, the knowledge database employed in the identifying an inconsistency.

[0020] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include an administrator reviewing the suggested flagged inconsistencies. [0021] Also described herein in an embodiment is a physical access control system (PACS) with spatio-temporal topology learning system for detection of suspicious access control behavior. The physical access control system comprising a credential including user information stored thereon, the credential presented by a user to request access to a resource protected by a access point, a reader in operative communication with the credential and configured to read user information from the credential, a controller executing a set of access control permissions for permitting access of the user to the resource. The PACS also incudes that the permissions are generated with access control request manager based on learning profile based access pathways including, an access pathways learning module configured to determine a set of spatio-temporal properties associated with each resource in the PACS, and an inconsistency detection module in operable communication with the access pathways learning module, the inconsistencies detection module configured to analyze a plurality of historical access control events and identify an inconsistency with regard to the set of spatio- temporal properties and if an inconsistency is detected, at least one of the events is flagged as potentially suspicious access control behavior.

[0022] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the spatio-temporal properties are based on at least one of a cardholder identity, a resource to which access is desired, the resource associated with a reader and a door controlling access to the resource, a time zone specifying the time of the day when access to the resource is required, and a history of access events.

[0023] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that the spatio-temporal properties are based on a rule that a first reader can be reached from a second reader if there exists two consecutive access events for any cardholder that accesses the first reader and the second reader.

[0024] In addition to one or more of the features described above or below, or as an alternative, further embodiments could include that an inconsistency includes any instance where consecutive events are impossible.

[0025] Other aspects, features, and techniques of embodiments will become more apparent from the following description taken in conjunction with the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

[0027] FIG. 1 depicts a standard deployment and operation of a PACS in accordance with an embodiment;

[0028] FIG. 2 depicts a flow diagram for an Access Pathways Learning Engine in accordance with an embodiment; and

[0029] FIG. 3 depicts a flow diagram of a process for a Supposition Behavior Detection system based on spatio-temporal properties in accordance with an embodiment.

DETAILED DESCRIPTION

[0030] In general, embodiments herein relate to a system and a methodology for detecting suspicious access control behaviors based on inconsistencies and relationships inferred from access history data logs with respect to spatial and temporal properties. In operation, the system analyzes a series of data logs taking into consideration the

position/location and the time stamp of access events to detect suspicious activities and flag them to an administrator. In addition, the system provides an explanation of the context of the potential violations to motivate the suggestion of potential unauthorized access control activity. The system in the described embodiments employs an intelligent map of the building and its access control mapping to provide the spatio-temporal properties of an event (location). That is, a map locating the readers, doors and the like, where the access control history logs provide the time stamp of the access events, in particular, those access events that are considered to be unauthorized. The system also employs an intelligent and knowledge-based engine or process that analyzes properties, events locations and times, to detect inconsistencies and therefore flag suspicious access control behaviors.

[0031] For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings, and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of this disclosure is thereby intended. The following description is merely illustrative in nature and is not intended to limit the present disclosure, its application or uses. It should be understood that throughout the drawings, corresponding reference numerals indicate like or corresponding parts and features. As used herein, the term controller refers to processing circuitry that may include an application specific integrated circuit (ASIC), an electronic circuit, an electronic processor (shared, dedicated, or group) and memory that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable interfaces and components that provide the described functionality.

[0032] Additionally, the term "exemplary" is used herein to mean "serving as an example, instance or illustration. " Any embodiment or design described herein as

"exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" are understood to include any integer number greater than or equal to one, i.e. one, two, three, four, etc. The terms "a plurality" are understood to include any integer number greater than or equal to two, i.e. two, three, four, five, etc. The term "connection" can include an indirect "connection" and a direct "connection".

[0033] As shown and described herein, various features of the disclosure will be presented. Various embodiments may have the same or similar features and thus the same or similar features may be labeled with the same reference numeral, but preceded by a different first number indicating the figure to which the feature is shown. Thus, for example, element "a" that is shown in Figure X may be labeled "Xa" and a similar feature in Figure Z may be labeled "Za. " Although similar reference numbers may be used in a generic sense, various embodiments will be described and various features may include changes, alterations, modifications, etc. as will be appreciated by those of skill in the art, whether explicitly described or otherwise would be appreciated by those of skill in the art.

[0034] FIG. 1 depicts a deployment and operation of a PACS 10. In the figure, a user 12 with a credential 14 (e.g., cardholder) arrives at a reader 22 at a given access point with a lock 21 (e.g., locked door 20, gate, etc.) controlling access to a protected space also called a resource 26. The user 12 presents the credential 14 (e.g., badge, FOB, or mobile device) which is read by the reader 22 and identification information stored on the credential 14 is accessed and transmitted to a local controller 30. The controller 30 compares the

identification information from the credential 14 with a permissions database 25 on the controller 30 to ascertain whether there is a permission 25 linked to user's credential 14. If the permission(s) 25 are correct, i.e., there is a match, and the particular credential 14 has authorization to access the protected space 26, the controller 30 then sends a command to the door controller or lock 21 to unlock the door 20 as requested providing the user or requestor 12 access. The controller 30 in this instance, makes an almost immediate decision whether to grant the access (e.g., unlock the door). Users 12 also expect a rapid response, waiting at the access point of access decisions would be very undesirable and wasteful. In a conventional deployment of a PACS 10, a set of static permission(s) database 25 is maintained at a central server 50. To ensure rapid response when queried, relevant parts of the permissions 25 database are downloaded to individual controllers 30 that control the locks 21 at the doors 20.

[0035] In many PACS, such as the access control system 10 shown in FIG. 1, neither the card readers 22 nor the credentials 14 e.g., access cards have any appreciable processing, power, or memory themselves. Hence, such card readers 22 and access cards 14 are usually referred to as passive devices. By contrast, the centralized controller 30 and server 50 of the access control system 10 is usually a well-designed and sophisticated device with fail- operational capabilities and advanced hardware and algorithms to perform fast decision making. Moreover, the decision making process of the centralized controller 30 is fundamentally based on performing a lookup in of the static permissions 25. The static permissions 25 contains static policy based rules, (e.g., one rule might provide that user 12 is not allowed entry into a given room 26), which change only when the policy changes (e.g., the static permissions 25 might be changed to provide that user 12 can henceforth enjoy the privileges of a given room 26). Policies are implemented in a set of rules that governs authorization. The static policies as mentioned above can be viewed as context-independent policies 135 and rules. In contrast, context-sensitive policies 135 will require a dynamic evaluation of different states of the PACS 10, building system parameters, other building systems, and external criteria, maybe even including the user's past history of activities. This evaluation is referred to as dynamic authorization.

[0036] With such an interconnect architecture of depicted in FIG. 1 and with a reasonable number of users 12 of a protected facility, the PACS 10 using static permissions 25 makes decisions quickly, is reliable, and is considered to be reasonably robust. However, as buildings expand and enterprises expand, the use of the static permissions 25 in a database can grow and become unwieldy and the potential for unauthorized access events increases. Furthermore, it is expected that buildings and facilities of the future will require increasingly more intelligent physical access control solutions. For example, access control solutions are being provided with the capability to detect such conditions as intrusion and fire. In general, this increased capability implies that such access control solutions should be provided with the ability to specify conditions that are dynamically evaluated, e.g., disable entry to a particular room 26 in case of a break-in, and/or disable entry to a particular room 26 if its occupancy reaches its capacity limit, and/or allow entry to a normal user 12 only if a supervisor is already present inside the room 26, etc. This increased capability leads to a significant emphasis on the need not only for more dynamic means for requesting and assigning permissions 25 to users 12, but also a more dynamic scheme for detecting suspicious access behavior. Such a dynamic scheme can be centrally implemented with an architecture that learns information within PACS 10 to facilitate or automate future tasks including audits of access control behaviors to address and minimize the ramifications of security and access control breaches.

[0037] Turning now to FIG.2 as well, FIG. 2 depicts a flow diagram for a Topology Learning module 100. In an embodiment, the Topology Learning (TLM) 100 is a process that can run independently of the operation of the PACS 10 and learns offline or online in background the reader's 22 (or access points/doors 20) reachability graph 115. The TLM 100 is a process operating on server (shown generally as 50 in FIG. 2), which may be centrally located or cloud based. The TLM 100 could also be a process operating on one or more controllers 30 in the PACS 10.

[0038] At process step 110 the reader's 22 reachability graph 115 is a connectability matrix of the accessible pathways between readers 22 or access points 20 in the PACS 10. The reachability graph 115 of a given facility or building is inferred based on historical event records 112 saved in the server 50 of the user's 12 accesses at all readers 22 and doors 20. The reachability graph 115 is compiled employing a rule that a pathway 111 can be defined given reader 22 X (Rx) can be reached from and other reader 22 Y (Ry), if there exists two consecutive access events for any cardholder 12 that accesses Ry and Rx. Of course, it will be appreciated that any variety of rules could be employed for establishing pathways 111 and the reachability graph 115, including a more conservative rule requiring more than multiple consecutive access events as a positive indication that a reader 22 can be reached from another reader 22. In addition, the reachability graph 115 may also to capture information about distance among readers 22. This may be accomplished based on an analysis of the time difference between two consecutive access events from the historical access events records. Moreover, the TLM learns the reachability graph 115 and estimates distance among readers 22 based on access events. In an embodiment, the minimum difference between access event time stamps at two connected readers 22 may be used to obtain an initial estimate of the notional distance between readers 22. Once initial estimates for one-to-one reader distances are obtained, conventional techniques such as trilateration or triangulation may be employed at the building level to correct distance estimates and obtain additional information on the relative location of one reader 22 to another reader 22. [0039] If an intelligent map 1 16 of the facility for the PACS 10 is available, the reachability graph 115 may be readily refined using topological information from the map 1 16. For example, when an intelligent map is available; the map is processed to extract information about rooms/areas protected by the readers 22, proximity (neighborhood), reachability, and distances.

[0040] Once the reachability graph 1 15 had been established, at process step 120 the reader reachability graph 115 and historical event records of cardholders with a specific profile (set of attributes 1 14) are used to compute the profile-based access pathways 121 (list of connected readers 22) that cardholders 12 with specific profile traverse from any entry reader 22 (readers giving access to facilities) to every other reader 22. The profile-based access pathways 123 are learned also from the access event database 1 12 with (only events from cardholders 12 with a specific profile/attributes 1 14) with the same rule(s) as the reachability graph 115 but considering also a sequence of events. As an example, if in the events records 112, a cardholder' access record includes the following consecutive access readers 22 "Re, Rl , R3,R5,R3,R4" being Re an entry reader 22 the access pathways 123 will be {Re, Rl } to Rl, {Re,Rl ,R3 } to R3, and {Re,Rl,R3,R5 } to R5 and {Re,Rl ,R3,R4} to R4. The reachability graph 1 15 is used to check that the direct/simple pathways 11 1 , 121 really exist between readers 22 Re-Rl , R1 -R3, R3-R4 and R3-R5. When analyzing all the cardholders 12 for a specific profile, each access pathway 123 will have its corresponding frequency based on the number of time this access pathways 123 was seen in the access event database 1 12. Readers reachability graph and profile-based access pathways 123 as depicted at 125 are updated regularly based on new access events as the PACS 10 is used. The reachability graph and profile-based access pathways 125 is saved in the server 50 as depicted at 130 for use in managing permissions 25 requests as described herein. FIG. 3 depicts a flow diagram of a process for topology learning and suspicious behavior analysis 200. In an embodiment, the process 200 can run independently of the operation of the PACS 10 and includes the Topology Learning Module (TLM) 100 described above with respect to FIG. 2. The process initiates at step 205 with a consideration of a historical group of access events 112 log window composed of a sequence of access control events 207, where each event "e" 207 includes at least a Cardholder ID (do) (an attribute 124) having requested access to a Door Dj 20 at time T _y and if access was granted or not. In addition, each event 207 may include additional data and metadata regarding the user 12 associated with the event. The data may include the cardholder attributes 124 (e.g. Cardholder's title, departments or badge type) resource attribute (e.g. export control, location, type (Lab, office)). An inconsistency checking module includes a processing engine 210 that analyzes the event data 207 and searches for inconsistencies with regard to spatio-temporal properties, e.g. , the reachability graph 1 15 and profile based access pathways 125, 130 provided by the TLM 100 and user attributes 124. In general an inconsistency is highlighted/triggered 1 ) when a violation of a logical behavior (e.g. two swipes of the same card cannot take place in doors that are far apart), 2) when a suspicious behavior is detected (e.g. successive denied access in neighboring doors), or whenever a pattern (sequence of timed requests of access through a particular path) is detected that is defined by security manager as risky/suspicious. For example, in a simple case, one inconsistency would be that a card holder 12 cannot access two doors 20 that are far apart in physical distance within a short time frame. Another example would be that a card holder 12 cannot access two doors 20 without also having requested access by presenting a card or credential 14 at another reader 22 and door 20 in between. If an inconsistency is detected as depicted at 215, the process 200 moves to 220 and provides an explanation describing the spatio-temporal properties that have been violated. If not, the process returns to continue reviewing the access control events 207 at process step 205. Finally at 225 an inconsistency knowledge data base is maintained and updated with the inconsistency identified.

[0041] Continuing with FIG. 3, the inconsistency knowledge data-base 225 is a set of rules describing spatio-temporal inconsistencies. In one embodiment, the inconsistency knowledge data-base 225 is initially generated from the intelligent map 116, or extracted from the learned topology spatio-temporal properties e.g., the reachability graph and profile based access pathways 125, 130 provided by the TLM 100. In operation, the database 225 is updated on real time basis through the inconsistency detection engine 210. Alternatively, in another embodiment database could also be populated as a consistency knowledge database that contains a set of rules describing the spatial, temporal, and user attribute 124 properties that are employed for one or more events. In other words, a consistency database could also be formulated based on acceptable spatial, temporal, and user attribute 124 data. In this case, the inconsistency engine 210 can look for deviations from the consistency database.

[0042] The spatio-temporal, user attribute 124 properties amassed in the

inconsistency database 225 may also be employed to ensure/enforce policies. For example, in one embodiment an "Escort Policy" - That is, ensure a visitor card presented at a reader 22 with attribute 124 export control = Yes, is either preceded by or followed by an escort employee card being presented at that reader 22 within a certain temporal, spatial constraint. Another example of policy enforcement that could be employed would be a "No loitering zone" - that is, to ensure consecutive credential presentations at the given entry reader 22 and exit reader 22 of a specified "no loitering zone" occur within a specified or expected time.

[0043] Advantageously the described embodiments will provide new capabilities to physical access controls systems by 1) enabling "near" real-time detection of suspicious access control behaviors through analysis of spatio-temporal of inconsistencies in access events, 2) enabling forensics capabilities to trace specious behaviors and provide evidence of security breaches 3) supporting auditing and access control logs analysis, specific to certain categories of violation, e.g., borrowing access card to unauthorized user 12. Moreover, the described embodiments automate part of the administrative processes for an enterprise and that has heretofore been limited to skilled administrative 27 functions.

[0044] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. While the description has been presented for purposes of illustration and description, it is not intended to be exhaustive or limited to the form disclosed. Many modifications, variations, alterations, substitutions, or equivalent arrangement not hereto described will be apparent to those of ordinary skill in the art without departing from the scope of the disclosure. Additionally, while the various embodiments have been described, it is to be understood that aspects may include only some of the described embodiments. Accordingly, embodiments are not to be seen as being limited by the foregoing description, but is only limited by the scope of the appended claims.