TECHNICAL FIELD
[0001] Embodiments relate generally to wireless computer networks, and more particularly but not exclusively, to methods,
systems and computer readable media for rogue access point detection.
BACKGROUND
[0002] Devices that can access networks via wired or wireless connections have proliferated. As a consequence, the variety of
threats, devices, applications, and communication protocols has also increased. Detecting rogue access points or other rogue
devices in dynamic and rapidly changing network environments can be a challenge for users.
SUMMARY
[0003] In general, some implementations may include a system configured to detect rogue access points. One or more
embodiments may include methods, systems and computer readable media for rogue access point detection. Some
implementations may include a method. The method can include receiving, at a listening wireless network access point, a
beacon message including a hash value as an information element of the beacon message, wherein the beacon message is
transmitted to the listening wireless network access point from a transmitting wireless network access point, and wherein the
hash value is generated using a key value, and determining, at the listening wireless network access point, whether the hash
value is valid. The method can also include based on determining that the hash value is valid, storing, at the listening wireless
network access point, a trusted indication that the transmitting wireless network access point is a trusted access point, and
based on determining that the hash value is not valid, storing, at the listening wireless network access point, an impersonator
indication that the transmitting wireless network access point is an impersonating access point.
2
[0004] In some implementations, the key value is provided by a threat management system to one or more trusted wireless
network access points that have each registered with the threat management system, and wherein the listening wireless network
access point is one of the one or more trusted wireless network access points.
[0005] In some implementations, determining whether the hash value is valid includes generating, at the listening wireless
network access point, a listening wireless access point hash value based on one or more of the key value, a basic service set
identifier, a service set identifier, or a nonce; comparing the listening wireless access point hash value with the hash value
received in the beacon message; and if the listening wireless access point hash value matches the hash value received in the
beacon message, the hash value is determined to be valid.
[0006] In some implementations, determining whether the hash value is invalid further includes determining that the hash
value is invalid and that the beacon message has one of a basic service set identifier (BSSID) or a service set identifier (SSID)
matching a BSSID or an SSID of the listening wireless network access point, respectively.
[0007] In some implementations, the hash value is based on one or more of unique key, a basic service set identifier, a service
set identifier, or a nonce. In some implementations, the nonce is updated periodically and distributed to the listening wireless
network access point by a threat management system.
[0008] Some implementations can include an access point, comprising one or more processors, and a nontransitory computer
readable medium coupled to the one or more processors, the nontransitory computer readable medium having stored thereon
software instructions that, when executed by the one or more processors, causes the one or more processors to perform
operations. The operations can include receiving a beacon message including a hash value as an information element of the
beacon message, wherein the beacon message is transmitted from a transmitting wireless network access point, and wherein
the hash value is generated using a key value, and determining whether the hash value is valid.
[0009] The operations can further include based on determining that the hash value is valid, storing a trusted indication that the
transmitting wireless network access point is a trusted access point, and, based on determining that the hash value is not valid,
storing an impersonator indication that the transmitting wireless network access point is an impersonating access point.
3
[0010] In some implementations, the key value is provided by a threat management system to one or more trusted wireless
network access points that have each registered with the threat management system, and wherein the access point is one of the
one or more trusted wireless network access points. In some implementations, determining whether the hash value is valid
includes generating a listening wireless access point hash value based on one or more of the key value, a basic service set
identifier, a service set identifier, or a nonce; comparing the listening wireless access point hash value with the hash value
received in the beacon message; and if the listening wireless access point hash value matches the hash value received in the
beacon message, the hash value is determined to be valid.
[0011] In some implementations, determining whether the hash value is invalid includes determining that the hash value is
invalid and that the beacon message has one of a basic service set identifier (BSSID) or a service set identifier (SSID)
matching a BSSID or an SSID of the access point, respectively. In some implementations, the hash value is based on one or
more of unique key, a basic service set identifier, a service set identifier, or a nonce. In some implementations, the nonce is
updated periodically and distributed to the access point by a threat management system.
[0012] Some implementations can include a nontransitory computer readable medium having stored thereon software
instructions that, when executed by one or more processors, causes the one or more processors to perform operations. The
operations can include receiving, at a listening wireless network access point, a beacon message including a hash value as an
information element of the beacon message, wherein the beacon message is transmitted to the listening wireless network
access point from a transmitting wireless network access point, and wherein the hash value is generated using a key value. The
operations can also include determining, at the listening wireless network access point, whether the hash value is valid, and
based on determining that the hash value is valid, storing, at the listening wireless network access point, a trusted indication
that the transmitting wireless network access point is a trusted access point. The operations can further include based on
determining that the hash value is not valid, storing, at the listening wireless network access point, an impersonator indication
that the transmitting wireless network access point is an impersonating access point.
4
[0013] In some implementations, the key value is provided by a threat management system to one or more trusted wireless
network access points that have each registered with the threat management system, and wherein the listening wireless network
access point is one of the one or more trusted wireless network access points.
[0014] In some implementations, determining whether the hash value is valid includes generating, at the listening wireless
network access point, a listening wireless access point hash value based on one or more of the key value, a basic service set
identifier, a service set identifier, or a nonce; comparing the listening wireless access point hash value with the hash value
received in the beacon message; and, if the listening wireless access point hash value matches the hash value received in the
beacon message, the hash value is determined to be valid.
[0015] In some implementations, determining whether the hash value is invalid includes determining that the hash value is
invalid and that the beacon message has one of a basic service set identifier (BSSID) or a service set identifier (SSID)
matching a BSSID or an SSID of the listening wireless network access point, respectively.
[0016] In some implementations, the hash value is based on one or more of unique key, a basic service set identifier, a service
set identifier, or a nonce. In some implementations, the operations further comprise, if the hash value is not valid, sending an
indication of the impersonating access point from the listening wireless network access point to one or more of a network
administrator system, another wireless network access point, or a threat management facility.
[0017] In some implementations, the operations further comprise, if the hash value is not valid, transmitting a message to one
or more endpoint devices indicating presence of the impersonating access point. In some implementations, the operations
further comprise, if the hash value is not valid, interrupting the impersonating access point using a Wireless Intrusion
Prevention System (WIPS).
5
BRIEF DESCRIPTION OF THE DRAWINGS
[0018] FIG. 1 is a diagram of an example wireless network environment including a system for rogue access point detection in
accordance with some implementations.
[0019] FIG. 2 is a flowchart showing an example method for rogue access point detection in accordance with some
implementations.
[0020] FIG. 3 is a diagram showing an example method for generating a hash value for rogue access point detection in
accordance with some implementations.
[0021] FIG. 4 is diagram of an example environment for threat management.
[0022] FIG. 5 is a diagram of an example threat management system in accordance with some implementations.
[0023] FIG. 6 is a diagram of an example computing device configured for rogue access point detection in accordance with
some implementations.
DETAILED DESCRIPTION
[0024] Embodiments were conceived in light of the above mentioned needs, challenges and/or limitations, among other things.
In general, some implementations may help provide wireless computer network security through rogue access point detection.
[0025] In one type of network security breach (or attempted breach), an intruder device is configured to pose as an authorized
access point. For example, in a large facility having a wireless network serving a number (e.g., hundreds or thousands) of
users, there may be a number of authentic or trusted access points physically distributed throughout the facility to provide
wireless connections to user devices. A malicious actor may insert a rogue or impersonating access point to try to have user
devices (endpoints) connect to the rogue AP to obtain access to data transmitted by user devices. Such rogue AP may be within
the facility or within wireless range of the facility and configured to masquerade as an authentic access points for the facility.
6
[0026] To be effective, a rogue access point must impersonate an authentic access point in one or more ways such that user
devices mistake the rogue access point for an authentic access point and connect to the rogue access point. As user devices
connect to the rogue access point, the rogue access point can collect information about the users (e.g., authentication
credentials such as a user name, password, etc.), user devices, and other information that may be helpful to an intruder in
further accessing a network in an unauthorized manner and exploiting the network or network resources.
[0027] Some implementations include a lightweight technique and protocol that enhances an existing beacon message process
to help identify rogue access points and distinguish a rogue or impersonating access point (e.g., 120 in FIG. 1) from an
authentic access point (e.g., 116 or 117 in FIG. 1). In general, the disclosed technique includes inserting a data item into a
beacon message that is already being transmitted so that the additional overhead to the access points is minimized. The data
item can include or be based on information that has only been shared with authentic access points (e.g., a secret unique key
shared with authentic access points that have been registered with a network security management system). Further, the data
item may be included in the beacon messages according to some periodicity or updated at a time interval such that a rogue
access point cannot successfully impersonate an authentic access point with a simple replay attack, e.g., by simply
retransmitting beacon messages that it previously obtained.
[0028] Some implementations include an access point (AP) that calculates a value (e.g., a hash value as described below) for a
specific combination of parameters (e.g., one or more of wireless channel, basic set service identifier (BSSID), service set
identifier (SSID), nonce, etc.) and sends that value as part of a beacon message. The value can be refreshed from time to time
with a different or updated value (e.g., the nonce value) to prevent a replay attack. Further, additional security is provided in
that an attacker attempting to use the generated value would have to use the same channel, BSSID, and/or SSID (or other
suitable information used to generate the value) and secret key shared between access points and a threat management system
that the access points have registered with.
[0029] FIG. 1 is a diagram of an example environment 100 in accordance with some implementations. The environment 100
includes a threat management facility or system 102 that includes a security policy server 104, a security policy server database
7
106, and a cloud administration console 108. The environment 100 also includes a wireless threat management system 110 that
serves as an intermediary system between one or more user endpoint devices 118 and a network 114 (e.g., the Internet). The
environment 100 also includes one or more access points (APs) 116/117 within a site 119. A site can include an area of
physical proximity, such as a building or other structure. The environment 100 also includes another wireless threat
management system 112 (optional) serving an intermediary system between one or more endpoint devices 118 and the network
114. The endpoint devices 118 and access points 116/117 can be connected to a same wireless threat management system (e.g.,
110). Also, a rogue access point (or impersonating access point) 120 is shown. For example, the rogue access point 120 can
include an access point that is attempting to impersonate an authentic access point within the system. However, the rogue
access point 120 will not have registered with the threat management system 102 or wireless threat management system 110,
and consequently will not have received the shared secret unique key described below. Thus, when the rogue access point 120
transmits a beacon message, the authentic access points (116/117) will be able to detect that the rogue access point 120 is a
rogue or impersonating access point using the technique described below.
[0030] In operation, the threat management system 102 in conjunction with one or more of the access points (116, 117) can
provide rogue access point detection according to the techniques described below in conjunction with FIGS. 2 and 3.
[0031] FIG. 2 is a flowchart showing an example method 200 for rogue access point detection in accordance with some
implementations. The method 200 may be performed by one or more access points (e.g., 116, 117). The method begins at 202,
where a wireless network device (e.g., an access point such as 116 or 117) receives a secret unique key. For example, when an
AP registers with a threat management facility (e.g., a cloud-based threat management facility) for a given customer and site,
the AP (e.g., 116 and/or 117) can receive a unique key from the network security system (e.g., 400). In some implementations,
the unique key can be common for all APs within a site (e.g., 119). In another example, the unique key can be provided from a
cloud/management server (e.g., threat management facility). For example, the cloud/management server can use a universal
unique identifier (UUID) of the customer as the unique key. The customer can include the customer account for which the
access points are reregistered for. The UUID is unique per customer. Processing continues to 204.
8
[0032] At 204, an AP uses the unique key to generate a hash value. In some implementations, the hash value can include a
value that is 32 Bytes in length. In some implementations, the hash value can be generated according to the following:
XOR(Unique Key, BSSID, Channel, SSID, Nonce) or Hash(Unique Key, BSSID, Channel, SSID, Nonce).
[0033] In some implementations, the hash value can be included in beacon messages at a given interval (e.g., every 5 beacon
messages. The nonce value is used to add randomness in the hash value. The nonce can be sent by a threat management server
or an AP can generate it and send it to the other APs. A hash algorithm or another suitable technique (e.g., XOR operation) can
be used to generate the hash value. The hash value could also be an encrypted value that can then be decrypted by a listening
AP.
[0034] For example, the unique key received in 202 can be used, along with other input data, as an input to a hash function (or
other similar function such as an XOR function) or an encryption function to calculate a value for transmitting within a beacon
message or frame. The other data can include BSSID, channel, SSID, and/or a nonce. The hash value generation is described in
greater detail below in connection with FIG. 3. Processing continues to 206.
[0035] At 206, the AP (e.g., a transmitting AP) transmits a beacon message including the hash value calculated in 204. Beacon
messages are typically transmitted by an access point in an infrastructure basic service set (BSS). In some implementations, the
hash value can be included as an information element (IE) of the beacon message. In some implementations, a beacon message
(or frame) can include one of the management frames in IEEE 802.11 based WLANs. The beacon message can contain
information about a wireless network, among other things. The hash value can be included in the beacon message as a Vendor
Specific Information Element. The Vendor Specific Information Element format is defined by the 802.11 standard, and can
follow an “elementID – Length – OUI – Data” order. Beacons are transmitted at every beacon interval. The beacon interval can
be configurable value. For example, the beacon interval can be 100ms or other values. Beacon messages can be transmitted
periodically and serve to announce the presence of a wireless LAN and to synchronize devices within a service set. Processing
continues to 208.
9
[0036] At 208, a neighbor AP (or listening AP) receives the beacon message transmitted by the transmitting AP. Processing
continues to 210.
[0037] At 210, the listening AP uses its unique key value to determine if the hash value received in the beacon message is valid
and if the beacon message has the same BSSID as the listening AP. For example, the listening AP can determine whether the
hash value is valid for a given broadcasted BSSID, channel, and/or SSID. For example, the listening AP can generate its own
hash value using one or more of its unique key, BSSID, SSID, and/or a nonce and compare the generated hash value with the
hash value received in the beacon message to determine if the beacon message hash value is valid. In another example, if the
hash value is an encrypted value, the listening AP can use a key (e.g., the unique key) to decrypt the hash value and extract
components of the values (e.g., BSSID, SSID, nonce, etc.). If the beacon message hash value is invalid and the beacon includes
the same BSSID as the listening AP, processing continues to 220, otherwise processing continues to 212.
[0038] At 212, the listening AP determines whether the beacon includes the same BSSID as the listening AP. If so, processing
continues to 222, otherwise processing continues to 214.
[0039] At 214, the listening AP determines whether the beacon includes a hash value. If so, processing continues to 216,
otherwise processing continues to 224.
[0040] At 216, the listening AP determines if the hash value is valid. For example, if the received hash value matches a hash
value generated by the listening AP using it unique key, BSSID, SSID and nonce, then the hash value received in the beacon
message is determined to be valid. If the hash value is valid, processing continues to 218, otherwise processing continues to
226.
[0041] At 218, the transmitting AP is marked as a trusted AP by the listening AP. Processing for the listening AP can continue
to 208. The transmitting AP can repeat 204-206.
[0042] At 220, it is determined whether the beacon includes the same SSID as the listening AP. If so, processing continues to
228. Otherwise, processing continues to 230.
10
[0043] At 222, it is determined whether the beacon includes the same SSID as the listening AP. If so, processing continues to
232. Otherwise, processing continues to 230.
[0044] At 224, it is determined whether the beacon includes the same SSID as the listening AP. If so, processing continues to
234. Otherwise, processing continues to 2226.
[0045] At 226, the transmitting AP is marked as an untrusted AP by the listening AP.
[0046] At 228, the transmitting AP is marked as an advanced impersonating AP. An attacker can capture the beacon of a
trusted AP and replay it. In order to avoid that situation, the APs include an encrypted/hashed value in the beacon. If the
recalculation of hash or the decryption of the value fails, but the transmitting AP beacon includes a BSSID and SSID matching
the listening AP, the transmitting AP can be considered an advanced impersonating AP.
[0047] At 230, the transmitting AP is marked as a BSSID impersonating AP.
[0048] At 232 the transmitting AP is marked as an evil twin AP. Evil twin is a term in the network security art that refers to a
malicious AP that mimics a trusted AP and appears to be legitimate. In this case, an evil twin may be using a BSSID and SSID
that matches the listening AP.
[0049] At 234, the transmitting AP is marked as an SSID impersonating AP.
[0050] One or more actions can be taken against an AP that has been determined to be an impersonating AP, an evil twin AP, or
an untrusted AP. For example, the indication of advanced impersonating AP can be sent by the listening AP to a network
administrator account or system, to other APs and/or a threat management facility (e.g., 400). Another action can include
notifying endpoint devices that utilize the AP to access network resources about the presence of the impersonating AP. Yet
another action can include terminating the impersonating AP using a Wireless Intrusion Prevention System (WIPS). For
example, one of the common WIPS techniques can include performing a Wireless Denial of Service attack on the Rogue AP.
[0051] FIG. 3 is a diagram showing an example hash value 312 and associated inputs (302-310) in accordance with some
implementations. The beacon hash value 312 can be based on input including one or more of a shared secret unique key 302
11
(e.g., the unique key received at 202), a channel 304 (e.g., a frequency channel within a wireless network protocol), a BSSID
306, an SSID 308, and/or a nonce 310.
[0052] The inputs including one or more of 302-310 can be combined via an XOR function 311 (or hash or other similar
function, or an encryption function) to yield a hash value that can be transmitted within a beacon message as an information
element.
[0053] The techniques described herein do not require any modifications to endpoints (e.g., user devices). Instead, by
configuring trusted access points (transmitting APs) to transmit beacon messages that can only be generated by trusted access
points (e.g., that have access to a shared key), and having other trusted APs (e.g., listening APs that are neighbor APs that are
within wireless range) verify that the hash value is correct, the techniques leverage the ability of the threat management system
to control trusted APs to expose the presence of a rogue AP. The techniques are lightweight and easily deployable with an
enhancement of the beacon transmission process. The techniques are resilient to replay attacks since the nonce that forms part
of the hash value may be updated from time to time such that even if a rogue AP were to temporarily gain access to a hash
value, it will be exposed as rogue after the nonce value is updated and sent to the trusted APs (e.g., the APs registered with the
threat management system).
[0054] FIG. 4 illustrates an example environment for threat management including rogue access point detection in
accordance with some implementations. Specifically, FIG. 4 depicts a block diagram of a threat management facility 400
providing protection to one or more enterprises, networks, locations, users, businesses, etc. against a variety of threats - a
context in which the techniques described above may usefully be deployed. The threat management facility 400 may be used
to protect devices and assets (e.g., Internet of Things (IoT) devices or other devices) from computer-generated and humangenerated
threats. For example, a corporation, school, web site, homeowner, network administrator, or other entity may
institute and enforce one or more policies that control or prevents certain network users (e.g. employees, residents, users,
guests, etc.) from accessing certain types of applications, devices, resources generally or in a particular manner. Policies may
12
be created, deployed and managed, for example, through the threat management facility 400, which may update and monitor
network devices, users, and assets accordingly.
[0055] The threat of rogue access points, malware or other compromises may be present at various points within a network
402 such as laptops, desktops, servers, gateways, communication ports, handheld or mobile devices, IoT devices, firewalls. In
addition to controlling or stopping malicious code, a threat management facility 400 may provide policy management to
control devices, applications, or users that might otherwise undermine productivity and network performance within the
network 402.
[0056] The threat management facility 400 may provide protection to network 402 from computer-based malware, including
viruses, spyware, adware, Trojans, intrusion, spam, policy abuse, advanced persistent threats, uncontrolled access, and the like.
In general, the network 402 may be any networked computer-based infrastructure or the like managed by the threat
management facility 400, such as an organization, association, institution, or the like, or a cloud-based facility that is available
for subscription by individuals. For example, the network 402 may be a corporate, commercial, educational, governmental, or
other enterprise network, and may include multiple networks, computing resources, and other facilities, may be distributed
among more than one geographical locations, and may include administration facility 434, a firewall 438A, an appliance 440A,
a server 442A, network devices 448A–B, clients 444A–D, such as IoT devices or other devices. It will be understood that any
reference herein to a client, endpoint, or client facilities may include the clients 444A–D shown in Fig. 4 and vice-versa.
[0057] The threat management facility 400 may include computers, software, or other computing facilities supporting a
plurality of functions, such as security management facility 422, policy management facility 412, update facility 420, a
definitions facility 414, network access rules facility 424, remedial action facility 428, detection techniques facility 430, testing
facility 418, a threat research facility 432, and the like. In embodiments, the threat protection provided by the threat
management facility 400 may extend beyond the network boundaries of the network 402 to include clients 444D (or client
facilities) that have moved into network connectivity not directly associated with or controlled by the network 402. Threats to
client facilities may come from a variety of sources, such as from network threats 404, physical proximity threats 410,
13
secondary location 408 threats, and the like. Clients 444A–D may be protected from threats even when the client 444A–D is
not directly connected or in association with the network 402, such as when a client 444E–F moves in and out of the network
402, for example when interfacing with an unprotected server 442C through the Internet 454, when a client 444F is moving
into a network where secondary location threat 408 is present (such as interfacing with components 440B, 442B, 448C, 448D
that are not protected), and the like.
[0058] The threat management facility 400 may use or may be included in an integrated system approach to provide network
402 protection from a plurality of threats to device resources in a plurality of locations and network configurations. The threat
management facility 400 may also or instead be deployed as a stand-alone solution. For example, some or all of the
components of the threat management facility 400 may be integrated into a server or servers at a remote location, for example
in a cloud computing facility. For example, some or all of the components of the threat management facility 400 may be
integrated into a firewall, gateway, or access point within or at the border of the network 402. In some embodiments, the threat
management facility 400 may be integrated into a product, such as a third-party product, e.g., through an application
programming interface, which may be deployed on endpoints, on remote servers, on internal servers or gateways for a
network, or some combination of these.
[0059] The security management facility 422 may include a plurality of elements that provide protection from malware to
device resources of the network 402 in a variety of ways, including endpoint security and control, email security and control,
web security and control, reputation-based filtering, control of unauthorized users, control of guest and non-compliant
computers, and the like. The security management facility 422 may include a local software application that provides
protection to one or more network 402 devices. The security management facility 422 may have the ability to scan client
facility files for malicious code, remove or quarantine certain applications and files, prevent certain actions, perform remedial
actions and perform other security measures. This may include scanning some or all of the files stored on the client facility or
accessed by the client facility on a periodic basis, scanning an application when the application is executed, scanning data (e.g.,
14
files or other communication) in transit to or from a device, etc. The scanning of applications and files may be performed to
detect known or unknown malicious code or unwanted applications.
[0060] The security management facility 422 may provide email security and control. The security management facility 422
may also or instead provide for web security and control, such as by helping to detect or block viruses, spyware, malware,
unwanted applications, and the like, or by helping to control web browsing activity originating from client devices. In an
embodiment, the security management facility 422 may provide for network access control, which may provide control over
network connections. In addition, network access control may control access to virtual private networks (VPN) that provide
communications networks tunneled through other networks. The security management facility 422 may provide host intrusion
prevention through behavioral based protection, which may guard against known or unknown threats by analyzing behavior
before or while code executes. The security management facility 422 may provide reputation filtering, which may target or
identify sources of code.
[0061] In embodiments, the security management facility 422 (or endpoint threat protection 520 described below with respect
to FIG. 5) may provide rogue access point detection in the wireless network (e.g., according to the methods described above
regarding FIGS. 2 and 3). This aspect of the security management facility 422 may also take place on the firewall 438A (e.g.,
an access point), appliance 440A, or within client (or endpoint) devices (e.g., one or more of clients 444A-444E).
[0062] In general, the security management facility 422 may support overall security of the network 402 using the various
techniques described above, optionally as supplemented by updates of malicious code information and so forth for distribution
across the network 402.
[0063] The administration facility 434 may provide control over the security management facility 422 when updates are
performed. Information from the security management facility 422 may also be sent from the enterprise back to a third party, a
vendor, or the like, which may lead to improved performance of the threat management facility 400.
[0064] The threat management facility 400 may include policy management facility 412 configured to take actions, such as to
block applications, users, communications, devices, and so on based on determinations made. The policy management facility
15
412 may employ a set of rules or policies that determine access permissions to the network 402 for a client 444. In an
embodiment, a policy database may include a block list, a black list, an allowed list, a white list, or the like, or combinations of
the foregoing, that may provide a list of resources internal or external to the network 402 that may or may not be accessed by
client 444 (e.g., via client devices). The policy management facility 412 may also or instead include rule-based filtering of
access requests or resource requests, or other suitable techniques for controlling access to resources consistent with a
corresponding policy.
[0065] In some embodiments, the policy management facility 412 may include or be part of a security policy server (e.g.,
server 104 described above). The policy management facility 412 may include policies to permit or deny access, to take
remedial action, to issue alerts, and so on based on particular reliability index determinations.
[0066] The policy management facility 412 may also or instead provide configuration policies to be used to compare and
control the configuration of applications, operating systems, hardware, devices, and/or a network associated with the network
402. An evolving threat environment may dictate timely updates, and thus an update facility 420 may also be provided by the
threat management facility 400. In addition, the policy management facility 412 may require update management (e.g., as
provided by the update facility 420 herein described). In some implementations, the update facility 420 may provide for patch
management or other software updating, version control, and so forth.
[0067] The security management facility 422 and policy management facility 412 may push information to the network 402
and/or a given client 444. The network 402 and/or client 444 may also or instead request information from the security facility
422 and/or policy management facility 412, network server 442, or there may be a combination of pushing and pulling of
information. In an embodiment, management update modules of the policy management facility 412 and the security
management facility 422 may work in concert to provide information to the network 402 and/or a facility of client 444 for
control of applications, devices, users, and so on.
[0068] As threats are identified and characterized, the threat management facility 400 may create updates that may be used to
allow the threat management facility 400 to detect and remediate malicious software, unwanted applications, configuration and
16
policy changes, and the like. The threat definition facility 414 may contain threat identification updates, also referred to as
definition files. A definition file may be a virus identity file that may include definitions of known or potential malicious code.
The virus identity definition files may provide information that may identify malicious code within files, applications, or the
like. The definition files may be accessed by security management facility 422 when scanning files or applications within the
client facility for the determination of malicious code that may be within the file or application. A definition management
facility may include a definition for a neural network or other recognition engine. A definition management facility 414 may
provide timely updates of definition files information to the network, client facilities, and the like.
[0069] The security management facility 422 may be used to scan an outgoing file and verify that the outgoing file is permitted
to be transmitted per rules and policies of the enterprise facility 402. By checking outgoing files, the security management
facility 422 may be able to discover malicious code infected files that were not detected as incoming files.
[0070] The threat management facility 400 may provide controlled access to the network 402. The network access rules
facility 424 may be responsible for determining if an application or other facility of a client 444 should be granted access to a
requested network resource. In an embodiment, the network access rules facility 424 may verify access rights for facilities of
thee client 444 to or from the network 402 or may verify access rights of computer facilities to or from external networks.
When network access for a client facility is denied, the network access rules facility 424 may send an information file to the
client facility, e.g., a command or command file that the remedial action facility 428 may access and take action upon. The
network access rules facility 424 may include one or more databases that may include a block list, a black list, an allowed list,
a white list, a reputation list, an unacceptable network resource database, an acceptable network resource database, a network
resource reputation database, or the like. The network access rules facility 424 may incorporate rule evaluation. Rule
evaluation may, for example, parse network access requests and apply the parsed information to network access rules. The
network access rule facility 424 may also or instead provide updated rules and policies to the network 402.
[0071] When a threat or policy violation is detected by the threat management facility 400, the threat management facility 400
may perform or initiate remedial action through a remedial action facility 428. Remedial action may take a variety of forms,
17
such as terminating or modifying an ongoing process or interaction, issuing an alert, sending a warning to a client or
administration facility 434 of an ongoing process or interaction, executing a program or application to remediate against a
threat or violation, recording interactions for subsequent evaluation, and so forth. The remedial action may include one or more
of blocking some or all requests to a network location or resource, performing a malicious code scan on a device or
application, performing a malicious code scan on the client 444, quarantining a related application (or files, processes or the
like), terminating the application or device, isolating the application or device, moving a process or application code to a
sandbox for evaluation, isolating a facility of the client 444 to a location or status within the network that restricts network
access, blocking a network access port from a facility of the client 444, reporting the application to an administration facility
434, or the like, as well as any combination of the foregoing.
[0072] Remedial action may be provided as a result of a detection of a threat or violation. The detection techniques facility 430
may include tools for monitoring the network or managed devices within the network 402. The detection techniques facility
430 may provide functions such as monitoring activity and stored files on computing facilities. Detection techniques, such as
scanning a computer’s stored files, may provide the capability of checking files for stored threats, either in the active or passive
state. Detection techniques such as streaming file management may be used to check files received at the network, a gateway
facility, a client facility, and the like.
[0073] Verifying that the threat management facility 400 detects threats and violations to established policy, may involve the
ability to test the system, either at the system level or for a particular computing component. The testing facility 418 may allow
the administration facility 434 to coordinate the testing of the security configurations of client facility computing facilities on a
network. For example, the administration facility 434 may be able to send test files to a set of client facility computing
facilities to test the ability of the client facility to determine acceptability of the test file. After the test file has been transmitted,
a recording facility may record the actions taken by the client facility in reaction to the test file. The recording facility may
aggregate the testing information from the client facility and report the testing information to the administration facility 434.
The administration facility 434 may be able to determine the level of preparedness of the client 444 based on the reported
18
information. Remedial action may be taken for any of the facilities of the client 444 as determined by the administration
facility 434.
[0074] The threat management facility 400 may provide threat protection across the network 402 to devices such as clients
444, server 442, administration facility 434, firewall 438, a gateway, one or more network devices 448 (e.g., hubs and routers),
a threat management or other appliance 440, any number of desktop or mobile users, and the like. As used herein the term
endpoint may refer to any computing instance running on a device that can source data, receive data, evaluate data, buffer data,
process data or the like (such as a user’s desktop computer, laptop, IoT device, server, etc.). This may, for example, include any
client devices as well as other network devices and the like within the network 402, such as a firewall or gateway (as a data
evaluation endpoint computer system), a laptop (as a mobile endpoint computer), a tablet (as a hand-held endpoint computer),
a mobile phone, or the like. The term endpoint may also or instead refer to any final or intermediate source or destination for
data within a network 402. An endpoint computer security facility 452 may be an application locally loaded onto any
corresponding computer platform or computer support component, either for local security functions or for management by the
threat management facility 400 or other remote resource, or any combination of these.
[0075] The network 402 may include a plurality of client facility computing platforms on which the endpoint computer
security facility 452 is installed. A client facility computing platform may be a computer system that is able to access a service
on another computer, such as a server 442, via a network. The endpoint computer security facility 452 may, in corresponding
manner, provide security in any suitable context such as among a plurality of networked applications, for a client facility
connecting to an application server 442, for a web browser client facility connecting to a web server 442, for an e-mail client
facility retrieving e-mail from an Internet 454, service provider’s mail storage servers 442, or web site, and the like, as well as
any variations or combinations of the foregoing.
[0076] The network 402 may include one or more of a variety of servers 442, such as application servers, communications
servers, file servers, database servers, proxy servers, mail servers, fax servers, game servers, web servers, and the like. A
facility of the server 442, which may also be referred to as a server facility 442 application, server facility 442 operating
19
system, server facility 442 computer, or the like, may be any device(s), application program(s), operating system(s), or
combination of the foregoing that accepts client facility connections in order to service requests from clients 444. In
embodiments, the threat management facility 400 may provide threat protection to server facilities 442 within the network 402
as load conditions and application changes are made.
[0077] A server facility 442 may include an appliance facility 440, where the appliance facility 440 provides specific services
to other devices on the network. Simple server facility 442 appliances may also be utilized across the network 402
infrastructure, such as switches, routers, hubs, gateways, print servers, modems, and the like. These appliances may provide
interconnection services within the network 402, and therefore may advance the spread of a threat if not properly protected.
[0078] A facility of the client 444 may be protected from threats from within the network 402 using a local or personal
firewall, which may be a hardware firewall, software firewall, or combination, that controls network traffic to and from a
client. The local firewall may permit or deny communications based on a security policy. Another component that may be
protected by an endpoint computer security facility 452 is a network firewall 438, which may include hardware or software, in
a standalone device or integrated with another network component, that may be configured to permit, deny, or proxy data
through a network 402.
[0079] The interface between the threat management facility 400 and the network 402, and through the appliance facility 440
to embedded endpoint computer security facilities, may include a set of tools that may be the same or different for various
implementations, and may allow each network administrator to implement custom controls. In embodiments, these controls
may include both automatic actions and managed actions. The administration facility 434 may configure policy rules that
determine interactions. The administration facility 434 may also establish license management, which in turn may further
determine interactions associated with licensed applications. In embodiments, interactions between the threat management
facility 400 and the network 402 may provide threat protection to the network 402 by managing the flow of network data into
and out of the network 402 through automatic actions that may be configured by the threat management facility 400 for
example by action or configuration of the administration facility 434.
20
[0080] Clients 444 within the network 402 may be connected to the network 402 by way of wired network facilities or wireless
network facilities provided by network device(s) 448. Mobile wireless facility clients 444, because of their ability to connect to
a wireless network access point, may connect to the Internet 454 outside the physical boundary of the network 402, and
therefore outside the threat-protected environment of the network 402. Such a client 444, if not for the presence of a locallyinstalled
endpoint computer security facility 452, may be exposed to a malware attack or perform actions counter to network
402 policies. Thus, the endpoint computer security facility 452 may provide local protection against various threats and policy
violations. The threat management facility 400 may also or instead be configured to protect the out-of-enterprise facility 402
mobile client facility (e.g., the clients 444) through interactions over the Internet 454 (or other network) with the locallyinstalled
endpoint computer security facility 452. Thus mobile client facilities that are components of the network 402 but
temporarily outside connectivity with the network 402 may be provided with the threat protection and policy control the same
as or similar to clients 444 inside the network 402. In addition, mobile clients 444 may receive the same interactions to and
from the threat management facility 400 as clients 444 inside the network 402, such as by receiving the same or equivalent
services via an embedded endpoint computer security facility 452.
[0081] Interactions between the threat management facility 400 and the components of the network 402, including mobile
client facility extensions of the network 402, may ultimately be connected through the Internet 454 or any other network or
combination of networks. Security-related or policy-related downloads and upgrades to the network 402 may be passed from
the threat management facility 400 through to components of the network 402 equipped with the endpoint computer security
facility 452. In turn, the endpoint computer security facility 452 components of the enterprise facility 402 may upload policy
and access requests back across the Internet 454 and through to the threat management facility 400. The Internet 454, however,
is also the path through which threats may be transmitted from their source, and an endpoint computer security facility 452
may be configured to protect a device outside the network 402 through locally-deployed protective measures and through
suitable interactions with the threat management facility 400.
21
[0082] Thus, if the mobile client facility were to attempt to connect into an unprotected connection point, such as at a
secondary location 408 (having secondary location threats) that is not a part of the network 402, the mobile client 444 may be
required to request network interactions through the threat management facility 400, where contacting the threat management
facility 400 may be performed prior to any other network action. In embodiments, the client’s 444 endpoint computer security
facility 452 may manage actions in unprotected network environments such as when the client (e.g., client 444F) is in a
secondary location 408, where the endpoint computer security facility 452 may dictate what applications, actions, resources,
users, etc. are allowed, blocked, modified, or the like.
[0083] The secondary location 408 may have no endpoint computer security facilities 452 as a part of its components, such as
its firewalls 438B, servers 442B, clients 444G, hubs and routers 448C–D, and the like. As a result, the components of the
secondary location 408 may be open to threat attacks, and become potential sources of threats, as well as any mobile enterprise
facility clients 444B–F that may be connected to the secondary location’s 408 network. In this instance, these components may
now unknowingly spread a threat to other connected to the network 402.
[0084] Some threats do not come directly from the Internet 454. For example, a physical proximity threat 410 may be
deployed on a client device while that device is connected to an unprotected network connection outside the network 402, and
when the device is subsequently connected to a client 444 on the network 402, the device can deploy the malware or otherwise
pose a threat. In embodiments, the endpoint computer security facility 452 may protect the network 402 against these types of
physical proximity threats 410, for instance, through scanning any device prior to allowing data transfers, through security
validation certificates, through establishing a safe zone within the network 402 to receive data for evaluation, and the like.
[0085] FIG. 5 illustrates an example threat management system 500 including endpoint threat protection as contemplated
herein. In general, the threat management system may include an endpoint 502 for example, a laptop, or a device such as an
IoT device, an access point 504, a server 506 and a threat management facility 508 in communication with one another directly
or indirectly through a data network 505, for example, as generally described above. Each of the entities depicted in FIG. 5,
22
may, for example, be implemented on one or more computing devices such as the computing device described with reference
to FIG. 6 below.
[0086] A number of systems may be distributed across these various components to support threat management, for example,
including a coloring system 510, a key management system 512, and a heartbeat system 514, each of which may include
software components executing on any of the foregoing system components, and each of which may communicate with the
threat management facility 508 or an endpoint threat protection agent 520 executing on the endpoint 502, on the access point
or firewall 504, or on the server 506 to support improved threat detection and remediation.
[0087] The coloring system 510 may be used to label or ‘color’ software objects for improved tracking and detection of
potentially harmful activity. The coloring system 510 may, for example, label files, executables, processes, network
communications, data sources and so forth with any suitable label. A variety of techniques may be used to select static and/or
dynamic labels for any of these various objects, and to manage the mechanics of applying and propagating coloring
information as appropriate. For example, a process may inherit a color from an application that launches the process. Similarly
a file may inherit a color from a device when it is created or opened by a device, and/or a process may inherit a color from a
file that the process has opened. More generally, any type of labeling, as well as rules for propagating, inheriting, changing, or
otherwise manipulating such labels, may be used by the coloring system 510 as contemplated herein. A color may be or may
be based on one or more reliability index values, the meeting of one or more reliability index thresholds, the rate of change of
one or more reliability index values, etc. A color of a device may be used in a security policy. A color of a process, a file, a
network request, and so on may be based on a color of a device, and that color may be used in a security policy.
[0088] The key management system 512 may support management of keys for the endpoint 502 in order to selectively permit
or prevent access to content on the endpoint 502 on a file-specific basis, a process-specific basis, an application-specific basis,
a user-specific basis, or any other suitable basis in order to prevent data leakage, and in order to support more fine-grained and
immediate control over access to content on the endpoint 502 when a security compromise is detected. Thus for example, if a
particular process executing on the endpoint is compromised, or potentially compromised or otherwise under suspicion, keys to
23
that process may be revoked in order to prevent, e.g., data leakage or other malicious activity. In embodiments, keys on device
may be revoked based on one or more reliability index values, the meeting of one or more reliability index thresholds, the rate
of change of one or more reliability index values, etc.
[0089] The heartbeat system 514 may be used to provide periodic or aperiodic information from an endpoint about system
health, security, status, etc. A heartbeat may be encrypted or plaintext, or some combination of these, and may be
communicated unidirectionally (e.g., from the endpoint 502 to the threat management facility 508) or bidirectionally (e.g.,
between the endpoint 502 and the server 506, or any other pair of system components) on a useful schedule.
[0090] In implementations, the access point or firewall 504 may use the heartbeat system 514 to report a potential or actual
compromise of a device based, for example, on a color of the device, or based on one or more reliability index values, the
meeting of one or more reliability index thresholds, the rate of change of one or more reliability index values, etc. The
heartbeat from heartbeat system 514 from the access point 504 may be communicated to a server 506, for example, and
administrative server or directly or indirectly to a threat management facility 508. If the endpoint 502 has an endpoint threat
protection 520, the endpoint threat protection 520 may be used to further investigate the status, or to take remedial measures,
again by communication using the secure heartbeat provided by the heartbeat system 514.
[0091] In general, these various monitoring and management systems may cooperate to provide improved threat detection and
response. For example, the coloring system 510 may be used to evaluate when a particular device is potentially compromised,
and a potential threat may be confirmed based on an interrupted heartbeat from the heartbeat system 514. The key management
system 512 may then be used to revoke keys to a process so that no further files can be opened, deleted or otherwise modified.
More generally, the cooperation of these systems enables a wide variety of reactive measures that can improve detection and
remediation of potential threats to an endpoint.
[0092] In some implementations, the coloring system 510 and/or the heartbeat system 514 may be used to assign a device to a
VLAN. In some implementations, information about the status of the device, for example, health status, may be provided by a
security module, and the status of the device may be used to assign the device to VLAN. For example, the endpoint threat
24
protection 520 may monitor the device. A change in health status as reported by the threat protection 520 may be used to
request that an access point 504 assign or reassign a device to a VLAN. For example, a device that meets security
requirements may continue to use or may be assigned to a particular VLAN and a device that has one or more flagged security
issues, such as software that is not up to date, a modified operating system, identified malware, etc., may be assigned or
reassigned to another VLAN. The heartbeat system 514 may be used as a secure communication channel to report the status of
the endpoint.
[0093] In some implementations, the access point 504 may receive status information from the endpoint, and assign or
reassign the endpoint 502 to the VLAN based on the status information. In some implementations, the server 506 or the threat
management facility 508 may receive information about the endpoint 502 and direct the wireless access point to assign or reassign
the endpoint 502 to a VLAN. In some implementations, the threat management facility 508 may direct the endpoint 502
to a VLAN without the cooperation of the access point, or by notifying the access point 504 and the endpoint 502 of the
change at the same time.
[0094] In some implementations, in connection with the assignment or reassignment of an endpoint 502 to a VLAN, the threat
management facility 508 or the server 506 provides an authentication credential to the endpoint 502, which the endpoint can,
in turn, present to the access point 504 for VLAN access.
[0095] In some implementations, an access point or firewall 504 may color the endpoint 502 based at least in part on activity
or behavior of the endpoint 502. The coloring may be used by the access point or firewall 504 to assign or reassign the
endpoint to VLAN. For example, if a color that indicates a potential compromise is assigned to the endpoint 502, the endpoint
may be assigned or reassigned to a VLAN. Likewise, the assignment to a VLAN may be used as a color to consider the
behavior of the VLAN in context.
[0096] FIG. 6 is a diagram of an example computing device 600 in accordance with at least one implementation. The
computing device 600 includes one or more processors 602, nontransitory computer readable medium or memory 604, I/O
interface devices 606 (e.g., wireless communications, etc.), and a network interface 606, all of which may be operatively
25
coupled to each other by a bus. The computer readable medium 604 may have stored thereon an operating system 608, a rogue
access point detection application 610 for detecting rogue access points, and a database 612 (e.g., for storing shared secret
unique keys, hash values, BSSID, SSID, nonce, and/or beacon messages, etc.).
[0097] In operation, the processor 602 may execute the application 610 stored in the computer readable medium 604. The
application 610 may include software instructions that, when executed by the processor, cause the processor to perform
operations for rogue access point detection in accordance with the present disclosure (e.g., performing one or more of the
operations described in one or more of FIGS. 2 and/or 3).
[0098] The application program 610 may operate in conjunction with the database 612 and the operating system 608. The
device 600 can include a wireless access point.
[0099] It will be appreciated that one or more of 202-226 may be repeated in whole or in part, performed in a different order or
performed periodically.
[00100] It will be appreciated that the modules, processes, systems, and sections described above may be implemented
in hardware, hardware programmed by software, software instructions stored on a nontransitory computer readable medium or
a combination of the above. A system as described above, for example, may include a processor configured to execute a
sequence of programmed instructions stored on a nontransitory computer readable medium. For example, the processor may
include, but not be limited to, a personal computer or workstation or other such computing system that includes a processor,
microprocessor, microcontroller device, or is comprised of control logic including integrated circuits such as, for example, an
Application Specific Integrated Circuit (ASIC). The instructions may be compiled from source code instructions provided in
accordance with a programming language such as Java, C, C++, C#.net, assembly or the like. The instructions may also
comprise code and data objects provided in accordance with, for example, the Visual Basic™ language, or another structured
or object-oriented programming language. The sequence of programmed instructions, or programmable logic device
configuration software, and data associated therewith may be stored in a nontransitory computer-readable medium such as a
26
computer memory or storage device which may be any suitable memory apparatus, such as, but not limited to ROM, PROM,
EEPROM, RAM, flash memory, disk drive and the like.
[00101] Furthermore, the modules, processes systems, and sections may be implemented as a single processor or as a
distributed processor. Further, it should be appreciated that the steps mentioned above may be performed on a single or
distributed processor (single and/or multi-core, or cloud computing system). Also, the processes, system components,
modules, and sub-modules described in the various figures of and for embodiments above may be distributed across multiple
computers or systems or may be co-located in a single processor or system. Example structural embodiment alternatives
suitable for implementing the modules, sections, systems, means, or processes described herein are provided below.
[00102] The modules, processors or systems described above may be implemented as a programmed general purpose
computer, an electronic device programmed with microcode, a hard-wired analog logic circuit, software stored on a computerreadable
medium or signal, an optical computing device, a networked system of electronic and/or optical devices, a special
purpose computing device, an integrated circuit device, a semiconductor chip, and/or a software module or object stored on a
computer-readable medium or signal, for example.
[00103] Embodiments of the method and system (or their sub-components or modules), may be implemented on a
general-purpose computer, a special-purpose computer, a programmed microprocessor or microcontroller and peripheral
integrated circuit element, an ASIC or other integrated circuit, a digital signal processor, a hardwired electronic or logic circuit
such as a discrete element circuit, a programmed logic circuit such as a PLD, PLA, FPGA, PAL, or the like. In general, any
processor capable of implementing the functions or steps described herein may be used to implement embodiments of the
method, system, or a computer program product (software program stored on a nontransitory computer readable medium).
[00104] Furthermore, embodiments of the disclosed method, system, and computer program product (or software
instructions stored on a nontransitory computer readable medium) may be readily implemented, fully or partially, in software
using, for example, object or object-oriented software development environments that provide portable source code that may
be used on a variety of computer platforms. Alternatively, embodiments of the disclosed method, system, and computer
27
program product may be implemented partially or fully in hardware using, for example, standard logic circuits or a VLSI
design. Other hardware or software may be used to implement embodiments depending on the speed and/or efficiency
requirements of the systems, the particular function, and/or particular software or hardware system, microprocessor, or
microcomputer being utilized. Embodiments of the method, system, and computer program product may be implemented in
hardware and/or software using any known or later developed systems or structures, devices and/or software by those of
ordinary skill in the applicable art from the function description provided herein and with a general basic knowledge of the
software engineering and computer networking arts.
[00105] Moreover, embodiments of the disclosed method, system, and computer readable media (or computer program
product) may be implemented in software executed on a programmed general purpose computer, a special purpose computer, a
microprocessor, a network server or switch, or the like.
[00106] It is, therefore, apparent that there is provided, in accordance with the various embodiments disclosed herein,
methods, systems and computer readable media for providing and managing security rules and policies.
[00107] While the disclosed subject matter has been described in conjunction with a number of embodiments, it is
evident that many alternatives, modifications and variations would be, or are, apparent to those of ordinary skill in the
applicable arts. Accordingly, Applicants intend to embrace all such alternatives, modifications, equivalents and variations that
are within the spirit and scope of the disclosed subject matter. It should also be understood that references to items in the
singular should be understood to include items in the plural, and vice versa, unless explicitly stated otherwise or clear from the
context. Grammatical conjunctions are intended to express any and all disjunctive and conjunctive combinations of conjoined
clauses, sentences, words, and the like, unless otherwise stated or clear from the context. Thus, the term “or” should generally
be understood to mean “and/or” and so forth.

We Claim:-
1. A computer-implemented method, comprising:
receiving, at a listening wireless network access point, a beacon message including a hash value as an information
element of the beacon message, wherein the beacon message is transmitted to the listening wireless network access point from
a transmitting wireless network access point, and wherein the hash value is generated using a key value;
determining, at the listening wireless network access point, whether the hash value is valid;
based on determining that the hash value is valid, storing, at the listening wireless network access point, a trusted
indication that the transmitting wireless network access point is a trusted access point; and
based on determining that the hash value is not valid, storing, at the listening wireless network access point, an
impersonator indication that the transmitting wireless network access point is an impersonating access point.
2. The method of claim 1, wherein the key value is provided by a threat management system to one or more trusted wireless
network access points that have each registered with the threat management system, and wherein the listening wireless network
access point is one of the one or more trusted wireless network access points.
3. The method of claim 1, wherein determining whether the hash value is valid includes:
generating, at the listening wireless network access point, a listening wireless access point hash value based on one or
more of the key value, a basic service set identifier, a service set identifier, or a nonce;
comparing the listening wireless access point hash value with the hash value received in the beacon message; and
29
if the listening wireless access point hash value matches the hash value received in the beacon message, the hash value
is determined to be valid.
4. The method of claim 1, wherein determining whether the hash value is invalid includes determining that the hash value is
invalid and that the beacon message has one of a basic service set identifier (BSSID) or a service set identifier (SSID)
matching a BSSID or an SSID of the listening wireless network access point, respectively.
5. The method of claim 1, wherein the hash value is based on one or more of unique key, a basic service set identifier, a service
set identifier, or a nonce.
6. The method of claim 5, wherein the nonce is updated periodically and distributed to the listening wireless network access
point by a threat management system.
7. An access point, comprising:
one or more processors; and
a nontransitory computer readable medium coupled to the one or more processors, the nontransitory computer readable
medium having stored thereon software instructions that, when executed by the one or more processors, causes the one or more
processors to perform operations including:
receiving a beacon message including a hash value as an information element of the beacon message, wherein
the beacon message is transmitted from a transmitting wireless network access point, and wherein the hash value is generated
using a key value;
determining whether the hash value is valid;
based on determining that the hash value is valid, storing a trusted indication that the transmitting wireless network
access point is a trusted access point; and
30
based on determining that the hash value is not valid, storing an impersonator indication that the transmitting wireless
network access point is an impersonating access point.
8. The access point of claim 7, wherein the key value is provided by a threat management system to one or more trusted
wireless network access points that have each registered with the threat management system, and wherein the access point is
one of the one or more trusted wireless network access points.
9. The access point of claim 7, wherein determining whether the hash value is valid includes:
generating a listening wireless access point hash value based on one or more of the key value, a basic service set
identifier, a service set identifier, or a nonce; and
comparing the listening wireless access point hash value with the hash value received in the beacon message,
wherein if the listening wireless access point hash value matches the hash value received in the beacon message, the
hash value is determined to be valid.
10. The access point of claim 7, wherein determining whether the hash value is invalid includes determining that the hash
value is invalid and that the beacon message has one of a basic service set identifier (BSSID) or a service set identifier (SSID)
matching a BSSID or an SSID of the access point, respectively.
11. The access point of claim 7, wherein the hash value is based on one or more of unique key, a basic service set identifier, a
service set identifier, or a nonce.
12. The access point of claim 11, wherein the nonce is updated periodically and distributed to the access point by a threat
management system.
13. A nontransitory computer readable medium having stored thereon software instructions that, when executed by one or more
processors, causes the one or more processors to perform operations including:
31
receiving, at a listening wireless network access point, a beacon message including a hash value as an information
element of the beacon message, wherein the beacon message is transmitted to the listening wireless network access point from
a transmitting wireless network access point, and wherein the hash value is generated using a key value;
determining, at the listening wireless network access point, whether the hash value is valid;
based on determining that the hash value is valid, storing, at the listening wireless network access point, a trusted
indication that the transmitting wireless network access point is a trusted access point; and
based on determining that the hash value is not valid, storing, at the listening wireless network access point, an
impersonator indication that the transmitting wireless network access point is an impersonating access point.
14. The nontransitory computer readable medium of claim 13, wherein the key value is provided by a threat management
system to one or more trusted wireless network access points that have each registered with the threat management system, and
wherein the listening wireless network access point is one of the one or more trusted wireless network access points.
15. The nontransitory computer readable medium of claim 13, wherein determining whether the hash value is valid includes:
generating, at the listening wireless network access point, a listening wireless access point hash value based on one or
more of the key value, a basic service set identifier, a service set identifier, or a nonce;
comparing the listening wireless access point hash value with the hash value received in the beacon message; and
if the listening wireless access point hash value matches the hash value received in the beacon message, the hash value
is determined to be valid.
16. The nontransitory computer readable medium of claim 13, wherein determining whether the hash value is invalid includes
determining that the hash value is invalid and that the beacon message has one of a basic service set identifier (BSSID) or a
service set identifier (SSID) matching a BSSID or an SSID of the listening wireless network access point, respectively.
32
17. The nontransitory computer readable medium of claim 13, wherein the hash value is based on one or more of unique key, a
basic service set identifier, a service set identifier, or a nonce.
18. The nontransitory computer readable medium of claim 13, wherein the operations further comprise, if the hash value is not
valid, sending an indication of the impersonating access point from the listening wireless network access point to one or more
of a network administrator system, another wireless network access point, or a threat management facility.
19. The nontransitory computer readable medium of claim 13, wherein the operations further comprise, if the hash value is not
valid, transmitting a message to one or more endpoint devices indicating presence of the impersonating access point.
20. The nontransitory computer readable medium of claim 13, wherein the operations further comprise, if the hash value is not
valid, interrupting the impersonating access point using a Wireless Intrusion Prevention System (WIPS).