WO2008138029A1 - Filtre de détection - Google Patents

Filtre de détection Download PDF

Info

Publication number
WO2008138029A1
WO2008138029A1 PCT/AU2007/001929 AU2007001929W WO2008138029A1 WO 2008138029 A1 WO2008138029 A1 WO 2008138029A1 AU 2007001929 W AU2007001929 W AU 2007001929W WO 2008138029 A1 WO2008138029 A1 WO 2008138029A1
Authority
WO
WIPO (PCT)
Prior art keywords
filter
applying
access request
application
condition rule
Prior art date
Application number
PCT/AU2007/001929
Other languages
English (en)
Inventor
Constantine Siourthas
Bjarne Staugaard Matzen
Original Assignee
Fmt Worldwide Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/747,705 external-priority patent/US20090025084A1/en
Priority claimed from AU2007202119A external-priority patent/AU2007202119A1/en
Application filed by Fmt Worldwide Pty Ltd filed Critical Fmt Worldwide Pty Ltd
Priority to EP07845371A priority Critical patent/EP2156362A4/fr
Priority to AU2007353308A priority patent/AU2007353308A1/en
Publication of WO2008138029A1 publication Critical patent/WO2008138029A1/fr
Priority to US12/616,660 priority patent/US20100146638A1/en
Priority to US13/414,617 priority patent/US20130067596A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/67—Risk-dependent, e.g. selecting a security level depending on risk profiles

Definitions

  • the present invention relates to a system for detecting possible fraudulent activity during an access request process in an online environment, and in particular to a detection filter that can be used to detect a fraud condition or perform pre-processing on an access request.
  • Web server systems currently employ authentication systems to authenticate users when they request access to connect to and use server applications.
  • the authentication systems seek to determine that an access request is being made by an authorised user, e.g. on the basis of a unique username and password combination or some other unique authentication data submitted (e.g. biometric data).
  • biometric data e.g. biometric data
  • Online banking systems for example, authenticate users, establish a connection session and allow transactions with an Internet banking application to be completed during the session; fraud detection is only performed subsequently by back-end analytic systems.
  • the analytic systems receive transaction data of the session and process the data for comparison with pattern data representing possible fraudulent conditions. This is clearly unsatisfactory as a user's account can be compromised before any fraud is detected. Suspicious activities or other undesirable conditions may not be detected until identified by the back-end analytic software, i.e. after the event has occurred.
  • a fraud detection filter installed in an application server including a secure application, said filter including a rules engine for receiving request data representing an access request for the secure application from a user, and applying at least one risk condition rule to the request data for generating a risk probability level, and detecting at least one fraud condition when said risk probability level exceeds a threshold level, before passing said access request to said secure application.
  • the present invention also provides a management server for generating an interface to adjust and set said at least one risk condition rule.
  • the present invention also provides a filter system including the filter and the management server.
  • the present invention also provides an application server including a secure application for access by a user and the fraud detection filter.
  • the present invention also provides a process for detecting a fraud condition, performed by an application server, including: receiving request data representing an access request from a user for a secure application of the application server; applying at least one risk condition rule to the request data for generating a risk probability level; and detecting said fraud condition when said risk probability level exceeds a threshold level, before granting access to said secure application.
  • the present invention also provides a filter installed in an application server including a application, said filter including a rules engine for receiving request data representing an access request for the application from a user, and applying at least one condition rule to the request data for generating a probability level, and detecting at least one condition when said probability level exceeds a threshold level, before passing said access request to said application.
  • the present invention also provides a process for detecting a condition, performed by an application server, including: receiving request data representing an access request from a user for an application of the application server; applying at least one condition rule to the request data for generating a probability level; and detecting said condition when said probability level exceeds a threshold level, before granting access to said application.
  • Figure 1 is a schematic diagram of a filter system arranged in a condition of use
  • Figure 2 is a schematic diagram of the filter system showing modules of an application server
  • Figure 3 is a flow chart of a filter process of the filter system ;
  • Figure 4 is a flow chart of part of the filter process showing process blocks;
  • Figure 5 is a schematic diagram of the filter system showing modules of a preprocessing filter and of a management server;
  • Figure 6 is an image of a user interface showing user options
  • Figure 7 is an image of a user interface generated by the management server of the filter system showing example process blocks.
  • a fraud detection system in the form of a filter system 100, as shown in Figure 1, filters an access request from a user device 102 of a user 104 who is attempting to access a secure - A -
  • the user device 102 accesses the application server 106 via a first data network 108 (e.g. the Internet) and an associated network server 110 (e.g. a Web server).
  • the access request is filtered in the filter system 100 by a preprocessing filter 202 that is installed or embedded in the application server 106, as shown in Figure 2, before access is granted to the secure application 204.
  • the pre-processing filter 202 provides a real-time decision engine which performs blocking and alerting process actions depending on a risk probability level determined from the access request.
  • the access request is in accordance with standard communication protocols, such as the suite of IP protocols, and may be a HTTP Get request.
  • the action taken by the pre-processing filter 202, and the treatment of data obtainable from the access request, is configurable via a management server 112.
  • the management server 112 is controlled from a management console 114 securely in communication with the management server 112, which is operated by an administrator 116.
  • the administrator 116 may be the owner of the application server 106 and secure application 204 (e.g. a bank owning an on-line banking application), or a third party security administrator providing security services to the owner of the secure application 204.
  • the administrator 116 may conveniently configure and adapt the pre-processing filter 202 using the management console 114.
  • the pre-processing filter 202 has access to an internal database 118 of the application server 106, for securely storing relevant filter data, and to a second data network 120 (e.g. an intranet or the Internet), by which one or more external databases 122, a client device 124 (of a person (i.e. client) 126 authorised by the owner to monitor performance of the filter 202) and the user devices 102 may be accessed.
  • a second data network 120 e.g. an intranet or the Internet
  • the internal database 118 is used by the pre-processing filter 202 to keep a secure record of filter data, such as a history of past access requests and other data that may be deemed relevant by the administrator 116.
  • a secure record of filter data such as a history of past access requests and other data that may be deemed relevant by the administrator 116.
  • the filter 202 is able to rely upon and use the same data and procedure calls as the secure application 204.
  • the filter 202 can therefore access account data and access history data for individual user accounts on a per user level.
  • the pre-processing filter 202 may access the external database 122 to draw on third party information (such as published Internet Protocol address blacklists), or to deliver report data into a case management file.
  • Report data may also be sent by the pre-processing filter 202 and the management server 112 to the client device 124 for real-time reporting by the filter system 100: for example, a person 126 may be alerted when the access request originates from a certain undesirable range of EP addresses.
  • the pre-processing filter 202 may access the user device 102 via the web server 110 and the first data network 108 to seek a second authentication factor.
  • the filter system 100 may request an additional user/password from the user 104, or submission of an encoded token sent by SMS to a mobile telephone, when certain access request characteristics, i.e. a fraud condition, is detected by processing of the access request by the pre-processing filter 202.
  • a two factor authentication process can be invoked that needs to be satisfactorily completed before access is granted.
  • a filter process 300 performed by the pre-processing filter 202 commences with the preprocessing filter 202 receiving an access request sent by the user device 102 requesting access to the secure application 204 for the user 104 (step 302 in Figure 3). Following reception of the access request, the pre-processing filter 202 then applies rules to the data of the request to generate the risk probability level, i.e. a measure representative of the probability that the access request originates from a risky, or fraudulent, user 104. Once the risk probability level is generated in step 304, the pre-processing filter 202 generates an action command depending on the level of the risk probability. For example, if there is a very low risk probability (determined at step 304) the action command (generated in step 306) may allow access to the secure application 204.
  • the risk probability level i.e. a measure representative of the probability that the access request originates from a risky, or fraudulent, user 104.
  • the action command may block access to the secure application 204 and/or alert the client 126 using a message sent to the client device 124.
  • the filter process may continue by repeating the application of the rule/s (step 304) and the generation of a consequent action command (step 306) depending on the number of steps in the pre-processing filter 202.
  • the owner 116 configures how many rules are applied and how many action commands are generated.
  • the filter process ends once no further rules remain to be applied. For example, an access request including access request data may be received (at step 302) from an IP address located in an untrustworthy Russian city.
  • the pre-processing filter 202 then applies a rule that considers the risk probability level associated with IP addresses from certain geographic locations, and assigns a relatively high risk level to this access request at step 304. Consequently, in step 306, the pre-processing filter 202 generates an action command to block the access request from the secure application 204 and a second action command to retain a record of this access request in the internal database 118.
  • Typical access request data may include one or more of the following characteristics of interest which may indicate a risk probability associated with the access request:
  • the rules applied in step 304 relate to the access request data.
  • Typical rules may include: (a) Checking the originating country for the IP address is not a high risk or black listed country (b) Impossible travel speed between current originating IP address and previous originating IP address
  • the filter 202 being part of the application server 106, applies rules to every access request made during a transaction session, even once a user has been given access privileges to the secure application 104. Accordingly, the rules are tailored for the specific application as required, (e) Checking if browser characteristics have changed from a previous request
  • the access request data is received in step 402 (shown in Figure 4).
  • the access request is for a Web application
  • the access request data includes: data representative of the version of the Web browser used on the user device 102; and data representative of the IP address used by the user device 102.
  • this user 104 (identified by a username and password combination in the access request data) has previously interacted with the pre-processing filter 202, and thus historical data of previous access requests for other sessions is stored in the internal database 118.
  • the first rule applied by the pre-processing filter 202 is a browser change rule (in step 404): if the browser version of the present access request has not changed since the previous access request, or is a more recent version, no action is taken by the pre- processing filter 202, and the filter process 300 continues to apply a second rule, being a land speed rule (in step 406). If, on the other hand, a downgrade of the browser version is detected (in step 404), a non-zero risk probability level is generated, and the pre-processing filter 202 generates an action command depending on the level of the fraud probability. If the risk probability level is high, corresponding to receipt of a percentage (say greater than 0.1%) of transactions, i.e. access requests, for a period that represent a browser downgrade, then an email alert action command is generated which leads to an email alert notice to be sent once to the client device 124.
  • a browser change rule in step 404: if the browser version of the present access request has not changed since the previous access request, or is
  • the pre-processing filter 202 continues with an annotation action command being generated in step 410.
  • the annotation action command tags record data in the internal database 118 to indicate that the access request data is suspect or dangerous (i.e. has a corresponding risk probability level).
  • a land speed rule step 406
  • a value comparer rule step 408 are used by the pre- processing filter 202 to determine whether the present IP address is at a time and location which is greater than 400 km/h from the previous IP address and location (i.e. that a user 104 would have had to have travelled at least 400 km/h to move between the previous IP address location and the current IP address location).
  • the pre-processing filter 202 If the land speed is less than 400 km/h, a low fraud probability is generated, and the pre-processing filter 202 generates an action command indicating that the access request data is "ok", and thus grants access to the secure application 204 (step 412). If, on the other hand, the user 104 appears to have travelled faster than 400 km/h, an action command is issued (at step 410) to annotate the relevant record in the internal database 118 indicating that the access request is suspect, but nonetheless allowing access to the secure application at step 414. This could also result in a case being created by generating and storing case record data in the management server as part of a case management system or two factor authentications can be requested.
  • an email alert action command (step 408) is executed to notify the administrator 116 that too many potential cases are being created and the pre-processing filter 202 executes an overload action command (step 416). This step allows the administrator to avoid overloading personnel that follow up fraud cases in the case management system. This can be an important step when new rules are being tested for the first time.
  • Steps 404, 406, 408, 410 in the example process of Figure 4 is in the form of a process block.
  • Steps 304 and 306 of the filter process may be represented as a series of process blocks arranged such that filter rules are applied to the access request data and resultant action commands are generated.
  • the filtering process 300 is performed by a rules engine 502 in the pre-processing filter 202 as shown in Figure 5.
  • the rules engine 502 executes action commands relating to the customer devices 124 and the user device 102.
  • the access request data is received in the pre-processing filter 202 by an input adaptor 504 which translates the access request data from a variety of formats into a format recognised by the rules engine 502.
  • the input adaptor 504 can accept access requests for Web services, http services and Java APIs with the input being in a format corresponding to CSV, XML and/or a messaging system (e.g. IBM MQ Series).
  • the rules engine 502 accesses the internal database 118 via a data connector 506 thus providing access to historical access request data and also has the ability to access data on the internal network during a user session with the secure application or via the Internet using the second data network 120.
  • the rules engine 502 accesses and writes to the external database 122 via the second data network 120 using the same data connector 506 or a different data connector.
  • the specific arrangement or configuration of the rules engine 502 are selected by the administrator 1 16 using an editor 508 of the management server 112.
  • the editor 508 is controlled by a user interface on the management console 114, a screen shot of which is shown in Figure 6.
  • a further screen shot, shown in Figure 7, is a graphic representation of a plurality of process blocks which constitute the steps to be taken by the filter process 300 in an example configuration of the rules engine 502.
  • the visual interface to the editor 508 advantageously allows rapid, convenient and error-free configuration and re-configuration of the particular filter process 300 performed by the pre-processing filter 202.
  • the process blocks which are available to be used in the rules engine 502 are stored in a rules catalogue 510. New rules may conveniently be updated from a third party provider of data security products (e.g. over the Internet) or created ad-hoc by the administrator 1 16 using a process block creator in the editor 508.
  • the set-up of the rules engine 502 is thus performed with an easy-to-use graphical interface and is highly flexible and adaptable to the needs of the owner 116 and the customer 126.
  • Example process blocks in the catalogue 510 include:
  • the process blocks fall into one of three categories: 1. data analysis process blocks;
  • the data analysis process blocks extract data from the data submitted by the user, and perform manipulations of the data.
  • the data analysis process blocks may concatenate string data, access white or black-list data, retrieve historical data from the internal database 118, access geo-spatial data relating to an Internet Protocol address of the access request, generate data representing calculations of land speed / deviations / amounts etc, and generate analytical data based on patterns in the data submitted by the user (e.g. click path, payment patterns).
  • the rule application process blocks control the process flow of the fraud detection filter. For example, a rule application process block may compare data drawn from submissions by the user 104 to a constant value, or to data drawn from other submissions. A rule application process block may also execute policies in a loop, or in a sequence, or may exit a sequence.
  • the action command process blocks generate command data to be transmitted to external systems. For example, an action command process blocks may log selected data or add a case to a case management system. An action command process blocks may also generate alerts (e.g. SMS, email) for the user 104 or the customer 126 or reject an access request.
  • alerts e.g. SMS, email
  • a process block may also consist of a number of subsidiary process blocks linked so as to create a single process block.
  • the administrator 116 may also test the processing of the arrangement in an off-line environment (i.e. before running the new process in the rules engine 502) using a simulator 512.
  • the simulator 512 allows the proposed filter process to be tested and observed in operation.
  • the graphical user interface which displays the process blocks (e.g. as shown in Figure 7) also graphically indicates the flow of the process during operation, thus enabling the administrator 116 to clearly visualise the operation of the proposed process.
  • the pre-processing filter 202 may be implemented using software code written in a computer program language, such as Java, running on a server engine (e.g. JSP) and the application server 106 may be in the form of a server product such as J2EE.
  • the management server 112 may be a J2EE server.
  • the pre-processing filter 202 and management server 112 may be implemented at least in part by dedicated hardware circuits, such as ASICs and FPGAs, to further enhance processing speed, particularly if processing of the engine is not to be reconfigured regularly.
  • the logical implementation of the rules engine 502 is in the form of a multi-threaded design which provides high speed filtering. High speed filtering is used so that the user 104 does not notice an appreciable delay when accessing the secure application 204 via the pre-processing filter 202 (e.g. if the access request is granted).
  • the external database 122 includes corporate databases, geospatial data, web services and black lists (e.g. OFAC, SpamHaus, Hunter, Aristion, NetEconomy, and SearchSpace).
  • the pre-processing filter 202 and the management server 112 may be implemented on the same server as the secure application, or the management server 1 12 is separate as described above.
  • the filter 202 is placed before the application 204 on the application server so as to provide access to the same session data and procedures as the secure application 204.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un filtre de détection installé dans un serveur d'application qui inclut une application sécurisée. Le filtre inclut un moteur de règles destiné à recevoir des données de demande représentant une demande d'accès pour l'application sécurisée de la part d'un utilisateur. Le moteur applique au moins une règle de condition de risque aux données de demande pour générer un niveau de probabilité de risque et détecte au moins une condition de fraude lorsque le niveau de probabilité de risque dépasse un niveau seuil, avant de transmettre la demande d'accès à l'application sécurisée.
PCT/AU2007/001929 2007-05-11 2007-12-13 Filtre de détection WO2008138029A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP07845371A EP2156362A4 (fr) 2007-05-11 2007-12-13 Filtre de détection
AU2007353308A AU2007353308A1 (en) 2007-05-11 2007-12-13 A detection filter
US12/616,660 US20100146638A1 (en) 2007-05-11 2009-11-11 Detection filter
US13/414,617 US20130067596A1 (en) 2007-05-11 2012-03-07 Detection filter

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US11/747,705 2007-05-11
US11/747,705 US20090025084A1 (en) 2007-05-11 2007-05-11 Fraud detection filter
AU2007202119A AU2007202119A1 (en) 2007-05-11 2007-05-11 A fraud detection filter
AU2007202119 2007-05-11

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/747,705 Continuation US20090025084A1 (en) 2007-05-11 2007-05-11 Fraud detection filter

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/616,660 Continuation US20100146638A1 (en) 2007-05-11 2009-11-11 Detection filter

Publications (1)

Publication Number Publication Date
WO2008138029A1 true WO2008138029A1 (fr) 2008-11-20

Family

ID=40001568

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2007/001929 WO2008138029A1 (fr) 2007-05-11 2007-12-13 Filtre de détection

Country Status (3)

Country Link
EP (1) EP2156362A4 (fr)
AU (1) AU2007353308A1 (fr)
WO (1) WO2008138029A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2515496A1 (fr) * 2009-12-15 2012-10-24 Telefónica, S.A. Système et procédé de génération de confiance chez des utilisateurs de réseaux de données

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997000483A1 (fr) * 1995-06-15 1997-01-03 Fraudetect, L.L.C. Procede et appareil de detection de fraude
US20020161711A1 (en) * 2001-04-30 2002-10-31 Sartor Karalyn K. Fraud detection method
US20030153299A1 (en) * 1998-11-18 2003-08-14 Lightbridge, Inc. Event manager for use in fraud detection
WO2004003676A2 (fr) * 2002-06-28 2004-01-08 Waterleaf Limited Detection de fraude
US20040148256A1 (en) * 2003-01-23 2004-07-29 International Business Machines Corporation Fraud detection within an electronic payment system
US20060285665A1 (en) * 2005-05-27 2006-12-21 Nice Systems Ltd. Method and apparatus for fraud detection

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020133606A1 (en) * 2001-03-13 2002-09-19 Fujitsu Limited Filtering apparatus, filtering method and computer product
WO2005114886A2 (fr) * 2004-05-21 2005-12-01 Rsa Security Inc. Systeme et procede permettant de reduire la fraude
WO2006094275A2 (fr) * 2005-03-02 2006-09-08 Markmonitor, Inc. Systemes et procedes d'evaluation de confiance
CN101375546B (zh) * 2005-04-29 2012-09-26 甲骨文国际公司 用于欺骗监控、检测和分层用户鉴权的系统和方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997000483A1 (fr) * 1995-06-15 1997-01-03 Fraudetect, L.L.C. Procede et appareil de detection de fraude
US20030153299A1 (en) * 1998-11-18 2003-08-14 Lightbridge, Inc. Event manager for use in fraud detection
US20020161711A1 (en) * 2001-04-30 2002-10-31 Sartor Karalyn K. Fraud detection method
WO2004003676A2 (fr) * 2002-06-28 2004-01-08 Waterleaf Limited Detection de fraude
US20040148256A1 (en) * 2003-01-23 2004-07-29 International Business Machines Corporation Fraud detection within an electronic payment system
US20060285665A1 (en) * 2005-05-27 2006-12-21 Nice Systems Ltd. Method and apparatus for fraud detection

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2515496A1 (fr) * 2009-12-15 2012-10-24 Telefónica, S.A. Système et procédé de génération de confiance chez des utilisateurs de réseaux de données
EP2515496A4 (fr) * 2009-12-15 2013-07-03 Telefonica Sa Système et procédé de génération de confiance chez des utilisateurs de réseaux de données

Also Published As

Publication number Publication date
EP2156362A4 (fr) 2012-03-07
EP2156362A1 (fr) 2010-02-24
AU2007353308A1 (en) 2008-11-20

Similar Documents

Publication Publication Date Title
US20090025084A1 (en) Fraud detection filter
US7908645B2 (en) System and method for fraud monitoring, detection, and tiered user authentication
US8739278B2 (en) Techniques for fraud monitoring and detection using application fingerprinting
JP5207736B2 (ja) ネットワークセキュリティ及び不正検出システム及び方法
US11805129B2 (en) Fictitious account generation on detection of account takeover conditions
US11902307B2 (en) Method and apparatus for network fraud detection and remediation through analytics
US20080222706A1 (en) Globally aware authentication system
US20140380478A1 (en) User centric fraud detection
US20230155817A1 (en) Managing secret values using a secrets manager
US11411947B2 (en) Systems and methods for smart contract-based detection of authentication attacks
US20240089260A1 (en) System and method for graduated deny list
JP6842951B2 (ja) 不正アクセス検出装置、プログラム及び方法
WO2008138029A1 (fr) Filtre de détection
AU2007101183A4 (en) A detection filter
AU2012278375A1 (en) A fraud detection filter
US20230353537A1 (en) Cumulative sum model for ip deny lists
US11356441B2 (en) Alternate user communication routing
CN117714151A (zh) 一种加密流量的访问控制方法、系统和介质
JP2021082342A (ja) 不正アクセス検出装置、プログラム及び方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07845371

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 7528/DELNP/2009

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2007845371

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007353308

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2007353308

Country of ref document: AU

Date of ref document: 20071213

Kind code of ref document: A