Systems and methods for identification and access risk reduction informed by risk signaling and device status - Patents.com

Abstract

The system and method identify an elevated risk factor for endpoint devices on a computing network according to one or more characteristics of the endpoint devices. A user associated with the endpoint device having the elevated risk factor is determined. User credentials associated with the user at one or more computing systems and / or computing applications accessible on the computing network are revoked based on the elevated risk factor. The endpoint device having the elevated risk factor is included in a group of endpoint devices identified as having an elevated risk level. Access by the group of endpoint devices identified as having an elevated risk level to one or more computing systems and / or computing applications accessible on the computing network is restricted based on the elevated risk level.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority under 35 U.S.C. §119 from U.S. Provisional Patent Application No. 63 / 377,034, filed September 24, 2022, entitled "Systems and Methods for Identity and Access Risk Reduction Informed by Risk Signaling and Device Posture," the disclosure of which is incorporated herein by reference in its entirety for all purposes. [Technical Field]

[0002] The present disclosure relates generally to security of computer systems, and more particularly to dynamically reducing the attack surface of a computing system in response to the detection of a positive threat. [Background technology]

[0003] Mobile devices are becoming increasingly prevalent in everyday use, including in homes, offices, and educational environments. For example, some school districts are beginning to implement one-to-one technology programs that provide each student with access to a mobile device, such as a tablet computer. As another example, many businesses are providing their employees with mobile devices to enable them to perform work-related functions while on the go. Mobile devices that an organization provides to users of its computing networks and systems may be more vulnerable to various security risks and attacks than fixed-location devices within the organization, such as desktop computers, and may be exposed to various risks and threats that fixed-location devices would not be exposed to. [Brief explanation of the drawings]

[0004] The present disclosure will be better understood with reference to the following drawings and description. The elements in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the present disclosure. Moreover, in the figures, the same reference numbers may indicate corresponding parts throughout the different views.

[0005] [Figure 1] FIG. 1 illustrates a particular embodiment of a system operable to maintain dynamically updated groups of managed devices.

[0006] [Figure 2] FIG. 2 is a diagram showing inventory data of the system of FIG.

[0007] [Figure 3] FIG. 3 illustrates a particular embodiment of a method for dynamically updating group membership.

[0008] [Figure 4] FIG. 4 illustrates a specific embodiment of a dynamic grouping graphical user interface (GUI).

[0009] [Figure 5] FIG. 5 illustrates another specific embodiment of a dynamic grouping GUI.

[0010] [Figure 6] FIG. 6 illustrates another specific embodiment of a dynamic grouping GUI.

[0011] [Figure 7] FIG. 7 illustrates another specific embodiment of a dynamic grouping GUI.

[0012] [Figure 8] FIG. 8 illustrates another specific embodiment of a dynamic grouping GUI.

[0013] [Figure 9]FIG. 9 illustrates another specific embodiment of a dynamic grouping GUI.

[0014] [Figure 10] FIG. 10 illustrates another specific embodiment of a dynamic grouping GUI.

[0015] [Figure 11] FIG. 11 illustrates another specific embodiment of a dynamic grouping GUI.

[0016] [Figure 12] FIG. 12 is a flow chart illustrating a particular embodiment of a method of operation in a mobile device management (MDM) server.

[0017] [Figure 13] FIG. 13 is a flow chart illustrating a particular embodiment of a method of operation in an MDM server and a managed computer.

[0018] In one or more embodiments, not all of the components depicted in each figure may be required, and one or more embodiments may include additional components not shown in the figures. Changes in the arrangement and type of components may be made without departing from the scope of the claims of this disclosure. Additional, different, or fewer components may be utilized within the scope of the present disclosure. Summary of the Invention

[0019] The present disclosure provides a system and method that enables a mobile device management (MDM) server to mitigate the risk of lateral movement between systems in a protected computing environment and rapidly and dynamically reduce the attack surface by revoking credentials for user devices (e.g., mobile phones, tablets, laptop computers) that may have been compromised by an attack and are likely to have had their credentials stolen, and by disabling access to critical systems through the user's devices themselves. The MDM server can provide these capabilities through "smart" groups, for which the MDM server can maintain and update inventory information. As used herein, a "smart" group is a group of devices whose membership is dynamically updated in response to specific events. Illustratively, an IT administrator can create groups with specific membership / grouping criteria. As managed devices (e.g., mobile phones, tablet computers, laptop computers) check in to the MDM server and provide updated inventory information, the group's membership can be dynamically updated. IT administrators can use the dynamically updated groups to more easily and quickly perform MDM actions. As a non-limiting example, a dynamically updated group can be created for devices that have not backed up data to an MDM server (or another external backup device) in the past 30 days. To send a backup reminder message to all devices that have not backed up in the past 30 days, an IT administrator can select the group as the recipient of the message. This is a quicker and easier method than having the IT administrator identify each device that has not backed up in the past 30 days. For example, using a dynamic group of managed devices to select the target of an MDM action may be faster than an IT administrator querying a device database or asking individual device users to indicate when each device was backed up.

[0020] As an example, an elevated risk factor for an endpoint device on a computing network is identified according to one or more characteristics of the endpoint device, a user associated with the endpoint device having the elevated risk factor is determined, and user identity information associated with the user on one or more computing systems and / or computing applications accessible on the computing network is invalidated based on the elevated risk factor.

[0021] In one example, an elevated risk factor for an endpoint device on a computing network is identified according to one or more characteristics of the endpoint device. The endpoint device having the elevated risk factor is included in a group of endpoint devices identified as having an elevated risk level. Access by the group of endpoint devices identified as having an elevated risk level is restricted to one or more computing systems and / or computing applications accessible on the computing network based on the elevated risk level. The one or more characteristics of the endpoint device may include an outdated version of an operating system installed. The one or more characteristics of the endpoint device may include a geolocation of the endpoint device. A user associated with the endpoint device having the elevated risk factor may be identified. One or more additional endpoint devices on the computing network associated with the identified user may be identified. The one or more additional endpoint devices may be included in the group of endpoint devices identified as having an elevated risk level. User credentials associated with the user may be revoked on one or more computing systems and / or computing applications accessible on the computing network based on the elevated risk factor.

[0022] As one example, a non-transitory computer-readable storage device is provided that stores instructions that, when executed by a processor, cause the processor to perform operations. The instructions, when executed by the processor, cause the processor to identify elevated risk factors for endpoint devices on a computing network according to one or more characteristics of the endpoint devices. The instructions, when executed by the processor, cause the processor to include endpoint devices having elevated risk factors within a group of endpoint devices identified as having elevated risk levels. The instructions, when executed by the processor, cause the processor to restrict access by the group of endpoint devices identified as having elevated risk levels to one or more computing systems and / or computing applications accessible on the computing network based on the elevated risk levels. In certain aspects, the instructions, when executed by the processor, cause the processor to identify a user associated with an endpoint device having an elevated risk factor. In certain aspects, the instructions, when executed by the processor, cause the processor to identify one or more additional endpoint devices on the computing network associated with the identified user. In certain aspects, the instructions, when executed by a processor, cause the processor to include one or more additional endpoint devices in a group of endpoint devices identified as having an elevated risk level. In certain aspects, the instructions, when executed by a processor, cause the processor to revoke user authentication associated with the user on one or more computing systems and / or computing applications accessible over a computing network based on the elevated risk factor.

[0023] It should be noted that while various embodiments will be described herein with reference to an educational or corporate environment, this is by way of example only and is not to be considered limiting. The teachings of the present disclosure may also be applied to other mobile device environments, such as, but not limited to, home environments, retail environments, etc. DETAILED DESCRIPTION OF THE INVENTION

[0024] The detailed description set forth below is intended as a description of various embodiments and is not intended to represent the only embodiments in which the subject technology may be practiced. As will be appreciated by those skilled in the art, the described embodiments can be modified in a variety of different ways, all without departing from the scope of the present disclosure. Accordingly, the drawings and description are illustrative in nature and not restrictive.

[0025] The average dwell time of cybersecurity threats within an organization's computing network is decreasing over time. Therefore, network security teams must respond more quickly to mitigate the potential damage caused by such threats and prevent malicious actors from accessing core systems within an organization's computing network. Phishing scams are also one of the most common ways hackers gain unauthorized access to an organization's computing systems. With over 80% of security breaches resulting from brute force attacks or the misuse of lost or stolen credentials, providing required user connectivity to critical business systems via mobile devices is becoming increasingly risky.

[0026] As a result, organizations' computing network security teams must implement faster, more dynamic responses to detected security threats in an attempt to mitigate risk and potential damage. Described herein are novel systems and methods that provide rapid, dynamic attack surface reduction, revoke credentials for users whose portable devices may be compromised (and likely vulnerable to credential theft), and disable access of potentially compromised users' devices to critical business systems, thereby reducing the risk of lateral movement. The systems and methods described herein can be built upon, and utilize, mobile device management systems that dynamically update an inventory of groups of devices and their capabilities and characteristics.

[0027] Referring to FIG. 1 , a particular embodiment of a system operable to maintain a dynamically updated group of devices is shown, generally designated 100. The system includes a mobile device management (MDM) server 120 communicatively connected to a push notification service 130, one or more managed computers (e.g., exemplary managed computer 140), one or more managed mobile devices (e.g., exemplary managed mobile device 150), and an email server 170. While one managed computer 140 and one managed mobile device 150 are shown in FIG. 1 , it should be noted that the present disclosure is not limited to any particular configuration and number of devices. In alternative embodiments, there may be a different number of managed computers and / or managed mobile devices. For example, multiple managed computers and multiple managed mobile devices may be enrolled with the MDM server 120.

[0028] Managed computer 140 may be a portable computing device with wired and / or wireless networking capabilities. For example, managed computer 140 may be a desktop computer, a laptop computer, a server, etc. Managed mobile device 150 may be a portable device with wireless networking capabilities. For example, managed mobile device 150 may be a tablet computer, a mobile phone, a portable media player, an eBook reader, or any combination thereof.

[0029] The managed computer 140 may include an operating system (OS) 141, and the managed mobile device 150 may include a mobile OS 151. Each OS 141, 151 may control computing functions such as input / output (e.g., touchscreen display, speakers, microphone, camera, etc.) and networking (e.g., cellular, Bluetooth, Wi-Fi, Ethernet, etc.). Each OS 141, 151 may also support the execution of applications (apps) 143, 153 and enable such applications to access device resources and data 144, 154. Examples of applications include, but are not limited to, web browsers, email, calendars, social networking, document / e-book readers, media players, etc. Applications may correspond to software instructions stored in memory and executed by a processor, hardware circuitry that implements the application's functionality, or both. Applications 143, 153 may be pre-installed (e.g., as part of or along with the OS), downloaded (e.g., via a storefront), or side-loaded (e.g., from an external storage device). In certain embodiments, each OS 141, 151 stores a passcode 142, 152. For example, the passcode 142, 152 can be used to secure access to the device. When a user attempts to operate the device, the user is prompted to enter the passcode, and access to the device is not enabled unless the entered passcode matches the stored passcode 142, 152.

[0030] The MDM server 120 can correspond to hardware and / or software that implements MDM functionality. As an illustrative, non-limiting example, in an educational context, the MDM server 120 can manage teacher and student computers and mobile devices. The MDM server 120 may include a graphical user interface (GUI) generation module 121. The GUI generation module 121 may generate an operable (e.g., usable) GUI for defining dynamic groups. For example, the MDM server 120 can send the generated GUI to a computing device associated with a user 101 (e.g., an IT administrator) and receive user input 102 via the GUI. The user input 102 may define grouping criteria for one or more dynamic groups, as further described herein. The MDM server 120 may store the grouping criteria 125 received via the GUI. Examples of GUIs generated by the GUI generation module 121 are further described with reference to FIGS. 4 through 11.

[0031] As shown, MDM server 120 includes a grouping criteria evaluation module 122 and may store (or have access to) an inventory database 123 and group membership data 128. The inventory database 123 may contain data about each managed entity (eg, computer or mobile device) in the system 100 . Examples of data stored in inventory database 123 are further described with reference to Figure 2. In particular embodiments, inventory database 123 includes values ​​for various inventory attributes for each managed entity. As an illustrative, non-limiting example, inventory data for a managed computer may include values ​​for one or more of the following inventory attributes:

[0032] Active Directory Status, Application Title, Application Version, Architecture Type, Asset Tag, Available RAM Slots, Available SMU, Barcode, Battery Capacity, Boot Drive Utilization, Boot ROM, Building, Bus Speed ​​MHz, Cache Package, Computer Group, Computer Name, Department, Disk Encryption Settings, Drive Capacity MB, Customer Care ID, Encrypted Volume Eligibility, Encrypted Volume Individual Key Validation, Encrypted Volume Authority Key, Encrypted Volume Partition Encryption Status, Encrypted Volume Recovery Key Type, Encrypted Volume Status, Encrypted Volume User, Email Address, Registration Method: Prestige Registration, Font Title, Font Version, Full Name, IP Address, Last Check-in, Last Registration, Last Inventory Update, Lease Expiry, Licensed Software, Average Lifespan, Local User Account, MAC Address, Manufacturer, Mapped Printers, Master Password Set, MDM Platform Binary Version, MDM Server ID, Model, Model Identifier, NIC Speed, Number of Updates Available, Number of Processors, Operating System, Optical Drive, MDM Packages installed with Suite, Packages installed with Native Installer / SWU, Partition Name, Phone Number, Platform, Plugin Title, Plugin Version, PO Date, PO Number, Job Title, Processor Speed ​​MHz, Processor Type, Purchase Price, Purchased or Leased, Purchasing Account, Purchasing Contact, Room, Running Services, SMART Status, Scheduled Tasks, Serial Number, Service Pack, SMC Version, Total RAM MB, User Name, Vendor, Warranty Expiry

[0033] As another illustrative, non-limiting example, inventory data for managed mobile devices may include values ​​for one or more of the following inventory attributes:

[0034] Activation Lock Bypass Enabled, App Identifier, App Name, App Version, Asset Tag, Available Space in MB, Battery Level, Block Encryption Capability, Bluetooth MAC Address, Building, Space in MB, Carrier Settings Version, Cellular Technology, Certificate Name, Current Carrier Network, Current Mobile Country Code, Current Mobile Network Code, Customer Care ID, Data Protection, Data Roaming Enabled, Department, Device ID, Device Locator Service Enabled, Device Phone Number, Display Name, Do Not Disturb (DND) Enabled, Email Address, Enrollment Method: Enrollment Profile, Enrollment Method: Prestage Enrollment, Enrollment Method: User Invited, Enrollment Method: User Initiated - No Invite, Expiration Date, File Encryption Capability, Full Name, Hardware Encryption, Home Carrier Network, Home Mobile Country Code, Home Mobile Network Code, ICCID, Identifier, Proof of Identity, IMEI, IP Address, Language, Last Backup, Last Registration, Last Inventory Update, Lease Expiry, Average Lifespan, Locale, MDM Profile Removal Permission, MEID, Mobile Device Group, Model, Model Identifier, Modem Firmware Version, OS Build, OS Version, Passcode Compliance, Profile Passcode Compliance, Passcode Status, PO Date, PO Number, Job Title, Profile Name, Provisioning Profile Name, Purchase Price, Purchased or Leased, Purchasing Account, Purchasing Contact, Roaming, Room, Serial Number, Subscriber MCC, Subscriber MNC, Monitored, UDID, Percentage Space Used, User Phone Number, User Name, Vendor, Version, Voice Roaming Enabled, Warranty Expiry, Wi-Fi MAC Address, Wireless Media Streaming Password

[0035] Group membership data 128 may include a list of devices that are members of each dynamic group maintained by MDM server 120. Group membership data 128 may be updated in response to various events occurring in system 100. As illustrative, non-limiting examples, group membership data 128 may be updated in response to a managed device being added to system 100, a managed device being removed from system 100, a managed device providing updated inventory data to MDM server 120, etc. Examples of updating group membership data 128 are further described with reference to FIG. 3. In particular embodiments, MDM server 120 sends an alert in response to a change in group membership. For example, MDM server 120 may send email message 171 via email server 170 to user 101 or another IT administrator. Additional examples of alerts include, but are not limited to, a short message service (SMS) message, an instant message, a GUI alert, an automated phone call, etc.

[0036] In particular embodiments, user input 102 may include data specifying an action to be performed on a particular dynamic group of managed entities (e.g., managed devices). For example, a dynamic group called "Low Battery Laptops" may include laptops with batteries below a threshold ("Battery < 10%), in which case an action may be to display a pop-up message on the laptop prompting the user to charge the laptop.

[0037] Examples of MDM actions include, but are not limited to, installing an application on a managed device, adjusting configuration settings on a managed device, providing content to a managed device, sending a message to a managed device, setting or clearing a passcode, editing one or more inventory data attributes, sending a communication / message (e.g., email or SMS message), deleting data, sending a remote command, etc.

[0038] In response to receiving user input 102, grouping criteria evaluation module 122 can determine which laptops are members of the "Low Battery Laptops" group based on membership data 128 and / or inventory database 123 and initiate sending push notifications to such laptops. As described further herein, MDM server 120 may previously receive and store information about the laptops' remaining battery power based on inventory data updates provided by the laptops. Alternatively, or in addition, MDM server 120 may request the remaining battery power information in response to receiving user input 102. In particular embodiments, MDM server 120 may send a notification request 124 to push notification service 130, where the notification request 124 identifies the laptop.

[0039] In an exemplary embodiment, the GUI allows a user 101 to define dynamic groups through the recursive application of grouping criteria. For example, user input 102 can define a first dynamic group based on first grouping criteria 126 and a second dynamic group based on second grouping criteria 127. First grouping criteria 126 may be based on at least second grouping criteria 127 and a logical operator.

[0040] For example, a second dynamic group may be called "Science Department Mobile Devices" and include mobile devices that are owned by (or assigned to) the science department of a school. Thus, the second grouping criteria 127 may include the value "Science" for the inventory attribute "Department", e.g., the second grouping criteria 127 may be "Department=Science". A first dynamic group may be called "Chemistry Building Mobile Devices" and include mobile devices from the science department that are located in the chemistry building of a school. Thus, the first grouping criteria 126 may be:

[0041] "Mobile Device Group = Science Department Devices AND Building = Chemistry"

[0042] Thus, the first dynamic grouping criteria 126 (e.g., chemistry building mobile devices) may be based on at least the second dynamic grouping criteria 127 (e.g., science department mobile devices) and a logical operator (e.g., AND operator). Examples of logical operators that can be used in grouping criteria include, but are not limited to, "and," "or," "not," "is," "is not," "has," "does not have," "member of," "not member of," organizational operators (e.g., open parenthesis, close parenthesis, etc.), and mathematical operators (e.g., "equal," "not equal," "greater than," "less than," etc.).

[0043] It should be noted that while various embodiments are described herein in the context of an educational setting, this is by way of example and not limitation, and the teachings of the present disclosure may be applied to other settings, including, but not limited to, home, corporate, retail, and other settings.

[0044] During operation, MDM server 120 may receive user input 102, which may include dynamic grouping criteria and / or identify actions to be performed on devices in a particular dynamic group. In an exemplary embodiment, user 101 may be prompted for authentication credentials (e.g., username, password, uniform resource locator (URL) of MDM server 120, etc.) before being granted access to the GUI. Communications between various components of system 100 may occur over secure (e.g., encrypted) channels, such as encrypted Internet Protocol (IP) connections.

[0045] If the user input 102 indicates that an action is to be performed with respect to devices in a group, the grouping criteria evaluation module 122 can determine which devices are members of the group. The MDM server 120 can send a notification request 124 to a push notification service 130, where the push notification request 124 identifies the devices determined to be members of the group. The push notification service 130 can correspond to one or more network-accessible servers configured to send push notifications 131, 132 to devices in the group, such as managed computers 140 and / or managed mobile devices 150.

[0046] In particular embodiments, push notifications 131, 132 may be associated with check-in events 146, 156 that cause the managed computer 140 and managed mobile device 150 to check with the MDM server 120 to see if there are any actions to be performed by the managed computer 140 and managed mobile device 150. For example, actions 147, 157 specified by user input 102 may be "queued" by the MDM server 120 and retrieved by the managed computer 140 and managed mobile device 150 in response to the push notifications 131, 132.

[0047] In alternative embodiments, the push notifications 131, 132 may include or specify an action to be performed. For example, the push notifications 131, 132 may utilize an application programming interface (API) of the OS 141 or 151 to instruct the managed computer 140 or the managed mobile device 150 to perform an action. In yet another alternative embodiment, the notification and / or action may be pushed directly to the managed computer 140 or the managed mobile device 150 by the MDM server 120. For example, if the managed mobile device 150 is an iOS® device, the command may be compatible with the iOS® MDM API / protocol (iOS is a registered trademark of Cisco Systems, Inc. of San Jose, California, and used under license by Apple Inc. of Cupertino, California), such as a device lock command, a passcode clear command, etc.

[0048] During operation, the managed computers 140 and managed mobile devices 150 may provide updated inventory information 145, 155 to the MDM server 120. The updated inventory information 145, 155 may indicate changes to inventory attributes associated with the managed computers 140 and managed mobile devices 150. The managed devices may provide updated inventory information to the MDM server 120 in response to a specific event (e.g., performing an MDM action, moving to another building, powering on, waking from sleep mode, etc.). Alternatively, or in addition, the updated inventory information may be provided periodically, in response to user input, or in response to a request from the MDM server 120. In certain embodiments, to reduce the amount of data sent to the MDM server 120, the updated inventory information identifies only changed values ​​of inventory attributes instead of values ​​of all inventory attributes. Upon receiving the updated inventory information 145 or 155, the MDM server may update the record in the inventory database 123 of the corresponding managed computer 140 or managed mobile device 150. When updated inventory information 145, 155 causes a managed computer 140 or managed mobile device 150 to be added to or removed from a dynamic group, the MDM server 120 updates the group membership data 128. To illustrate, the MDM server 120 may receive an update from a device indicating that the device has been moved to a chemistry building at a school. The MDM server 120 may update the device's inventory database 123 record to reflect that the device has been moved to the chemistry building. The MDM server 120 may update the group membership data 128 (which may include a group membership list) by adding the device to a group whose grouping criteria 125 includes "building=chemistry" and removing the device from a group whose grouping criteria 125 includes a different value for "building."

[0049] 1 can support the creation and updating of dynamic groups and the sending of push notifications to devices that belong to particular dynamic groups. Performing MDM actions using dynamic (e.g., “smart”) groups is typically faster than having a user select devices one by one. It will also be appreciated that system 100 may automatically update group membership based on inventory updates from managed devices and may evaluate group membership just-in-time (e.g., in response to an MDM action request), thereby targeting appropriate managed devices for MDM actions (as opposed to targeting devices based on “stale” inventory information).

[0050] 2, a particular embodiment of inventory data is shown and generally designated 200. In an exemplary embodiment, inventory data 200 may be stored in an inventory database, such as inventory database 123 of FIG.

[0051] Inventory data 200 may include managed computer inventory data 210 and managed mobile device inventory data 220. Managed computer inventory data 210 may include inventory data associated with one or more managed computers registered with an MDM server (e.g., MDM server 120 of FIG. 1 ). In the illustrated example, managed computer inventory data 210 includes data 212 associated with a first managed computer (Computer 1). Data 212 associated with the first managed computer includes values ​​for one or more inventory attributes, including, but not limited to, active directory status, customer care ID, application title, barcode, battery capacity, etc. Additional inventory attributes associated with managed computers are described with reference to FIG. 1 .

[0052] Managed mobile device inventory data 220 may include inventory data associated with one or more managed mobile devices enrolled in an MDM server (e.g., MDM server 120 of FIG. 1). In the illustrated example, managed mobile device inventory data 220 includes data 222 associated with a first managed mobile device (Mobile Device 1). Data 222 associated with the first managed mobile device includes values ​​for one or more inventory attributes, including, but not limited to, activation lock bypass, Air playback password, customer care ID, asset tag, battery level, etc. Additional inventory attributes associated with managed mobile devices are described with reference to FIG. 1.

[0053] Referring to Figure 3, an exemplary embodiment for dynamically updating group membership is shown, generally designated 300. In the example of Figure 3, group membership for a "Low Battery" group is shown. The grouping criteria for this group is "Battery < 10%." Thus, mobile devices with a battery remaining below 10% are members of the group.

[0054] 3, mobile device 1, mobile device 19, mobile device 50, and mobile device 72 are initial members of the low battery remaining group, as shown at 310. Thus, group membership data 128 for the low battery remaining group in FIG. 1 may identify mobile device 1, mobile device 19, mobile device 50, and mobile device 72. Inventory data in inventory database 123 in FIG. 1 may store the most recently known (e.g., received) battery remaining amounts of the mobile devices.

[0055] An MDM server (e.g., MDM server 120 of FIG. 1) can receive updates from mobile devices during operation. For example, as shown at 320, the MDM server can receive a first update that mobile device 2 has 8% battery remaining and a second update that mobile device 72 has 95% battery remaining.

[0056] In response to receiving the update, the MDM server can store the received battery level information in an inventory database. The MDM server can also dynamically update group membership data for one or more groups that include battery level as a grouping criterion. For example, as shown at 330, mobile device 2 is added to the low battery level group and mobile device 72 is removed from the low battery level group. In particular embodiments, instead of changing the group membership data in response to each update from each managed device (e.g., in real time or near real time), the MDM server may queue the updates and process the updates asynchronously (e.g., when the MDM server has available resources to process the queued updates). In such an implementation, when an MDM action is requested by a user, the update queue may be processed (e.g., “emptied”) before the group membership data is evaluated to identify devices that should be notified about the MDM action.

[0057] It should be noted that the example shown in FIG. 3 is for illustrative purposes only and is not limiting. At any time, a managed device may be a member of any number of dynamic groups. A device may be removed from a group, added to a group, or removed from one group and added to another group in response to an update. For example, in response to an update that mobile device 72 has 95% battery remaining, mobile device 72 may be removed from the Low Battery group and added to the “High Battery” group, which has the grouping criterion “Battery > 90%.” Thus, as shown in FIG. 3, the MDM server can dynamically update group membership data based on update information received from managed devices. It should be noted that while FIG. 3 illustrates updating group membership data based on a change in a single attribute, a device update may include updated values ​​for multiple attributes, and group membership data may be updated in response to changes in multiple attributes.

[0058] In particular embodiments, an MDM server (e.g., MDM server 120) can maintain static groups as well as dynamic groups. A static group may have fixed membership that is not dynamically updated. For example, a static group with grouping criteria "manufacturer=company X" may have fixed membership that includes managed devices made by company X.

[0059] Although various implementations have been described herein with reference to managed computers and managed mobile devices, dynamic groups of other types of managed entities can also be created and used. For example, the MDM server 120 can support the creation and use of dynamic groups of users. Each user may be associated with one or more managed devices (e.g., computers or mobile devices), and sending a push notification to a user may result in the push notification being sent to one or more managed devices associated with the user. The grouping criteria for a dynamic user group may include values ​​for one or more of the following inventory attributes:

[0060] Content name, content type, email address, full name, phone number, job title, username, VPP (Volume Purchase Program) account, VPP invention status.

[0061] 4-11 illustrate specific embodiments of graphical user interfaces (GUIs) that may be generated by the GUI generation module 121 of FIG. 1. The MDM server 120 may provide the GUI to a display device for display. For example, the GUI may be displayed on a display device viewable by the user 101. The user 101 may provide user input 102 responsive to the GUI using an input device such as a keyboard, mouse, or touch screen.

[0062] 4, a first embodiment of a GUI is shown, generally designated 400. GUI 400 includes elements (e.g., icons, links, buttons, etc.) 410, 420, and 430 for selecting managed computer options, managed mobile device options, and managed user options, respectively. In the illustrated example, element 420 for mobile devices is selected. GUI 400 also includes selectable elements 440 and 450 for displaying a list of "smart" (e.g., dynamic) mobile device groups and a list of static mobile device groups, respectively. In the illustrated example, element 440 for smart mobile device groups is selected.

[0063] As shown in FIG. 4, GUI 400 may include a count 402 indicating the number of active groups. In the illustrated example, three dynamic groups are active: "All Managed Tablets," "All Managed Phones," and "All Managed Music Players." A user can select (e.g., click, tap, etc.) a link for an active managed group or a button 460 to define a new dynamic mobile device group. Selecting an active managed group allows the user to modify the grouping criteria and / or other settings associated with the selected group. Selecting the "New" button 460 allows the user to define the grouping criteria for the newly added dynamic group.

[0064] For example, FIG. 5 illustrates a specific embodiment of a GUI 500 corresponding to the selection of the “New” button 460 in FIG. 4. The GUI 500 includes a “Mobile Device Groups” tab 502 and a “Criteria” tab 504. In the example of FIG. 5, the “Mobile Device Groups” tab is selected. A user has created a new dynamic group for mobile devices and entered “Older Mobile Devices” as the group name, as shown at 510. The user has also selected option 520 to cause an MDM server (e.g., MDM server 120 of FIG. 1) to begin sending email notifications to users (e.g., devices associated with the user) when membership in the “Older Mobile Devices” group changes. For illustrative purposes, the email notification may correspond to email message 171 of FIG. 1.

[0065] Turning now to FIG. 6 , a specific embodiment of a GUI corresponding to selection of the “Criteria” tab 504 of FIG. 5 is shown, generally designated 600. GUI 600 may include various elements. In the example of FIG. 6 , button 602 may be used to add another criterion to the grouping criteria. Element 604 is used to include an open parenthesis operator in the grouping criteria. At 606, the inventory data attribute “Model” (e.g., mobile device model) is selected for inclusion in the criteria. As shown at 608 and 610, the sub-criteria including the “Model” attribute includes the IS operator and the value “2014 Phone.” Thus, the “Model” sub-criteria may be satisfied by managed mobile devices having a value of “2014 Phone” for the “Model” inventory attribute. At 612, the AND operator is selected to combine the sub-criteria “Model is 2014 Phone” with the sub-criteria “Display Name is Test Phone.” At 614, the closing parentheses operator is selected, and at 616, the OR operator is selected to combine the subcriteria within the parentheses with the subcriteria "Phone model is 2013". Thus, the overall grouping criteria defined in the GUI of Figure 6 is:

[0066] (Model is a 2014 phone and display name is test phone) or model is a 2013 phone.

[0067] Thus, mobile devices that are members of the "Older Mobile Devices" group would be 2014 model "test" (e.g., beta) mobile phones or 2013 model mobile phones. The user can select button 618 to save the grouping criteria and finish defining the "Older Mobile Devices" group. Once the "Older Mobile Devices" group is saved, the active groups count 402 increases from 3 to 4, and a link to "Older Mobile Devices" appears along with the previously displayed links to "All Managed Tablets," "All Managed Phones," and "All Managed Music Players."

[0068] 7, a particular embodiment of a GUI displayed in response to selection of a previously created dynamic group is shown, generally designated 700. In particular, GUI 700 corresponds to a user selecting the link for the previously created "Older Mobile Devices" group. GUI 700 includes a "Done" button 702 for saving changes to the group, a "History" button 704 for viewing historical information associated with the group (e.g., how the group's grouping criteria have evolved over time), and a "View" button 706 for viewing the members of the group. After selecting view button 706, the user can select actions to be performed on the members of the group, as further described with reference to FIG. 11.

[0069] GUI 700 also includes a "Clone" button 708 for creating a copy of a group. For example, as shown in GUI 800 of FIG. 8, selecting clone button 708 creates a "Copy of Legacy Mobile Devices" group. Note that the grouping criteria for the "Copy of Legacy Mobile Devices" group are identical to the grouping criteria for the "Legacy Mobile Devices" group shown in FIG. 6. Cloning a group, such as for testing purposes, may be quicker and more convenient than manually defining a new group with the same grouping criteria as an existing group.

[0070] GUI 700 further includes a "Delete" button 710 for deleting a group and associated grouping criteria and membership data. If the deleted group is used in a recursive group definition of another group, the other group may also be deleted. Alternatively, the user may be prompted for confirmation as to whether the other group should be deleted or whether the other grouping criteria should be modified. GUI 700 includes an "Edit" button 712 for editing a group (e.g., editing the group's name, email notification status, and / or grouping criteria).

[0071] As described with reference to FIG. 1 , the present disclosure enables a user to recursively define dynamic groups based on membership in other dynamic groups. FIG. 9 illustrates a specific embodiment of a GUI used to define recursive grouping criteria, generally designated 900. In the example of FIG. 9 , grouping criteria is defined for a dynamic group called “Older Mobile Devices with Low Battery Levels.” A mobile device is a member of the dynamic group if it is a member of the “Older Mobile Devices” group described with reference to FIG. 6 and has less than 10% battery life. As shown at 902, a “pseudo” inventory attribute called “Mobile Device Group” can be used to recursively define grouping criteria, where the value of the “Mobile Device Group” attribute is the name of another (e.g., previously defined) dynamic group. Corresponding “pseudo” inventory attributes for managed computers and managed users may be called “Computer Group” and “User Group,” respectively.

[0072] 9 illustrates an example of defining the grouping criteria of a first dynamic group (e.g., an "old mobile devices with low battery levels" group) based on the grouping criteria of a second dynamic group (e.g., an "old mobile devices" group) and at least one logical operator (e.g., an AND operator). When the membership of the second dynamic group changes, the MDM server (e.g., MDM server 120 of FIG. 1) can automatically reevaluate and update the membership of the first dynamic group. Thus, the techniques of this disclosure can enable the definition of dynamic groups without re-entering the grouping criteria from previously defined dynamic groups.

[0073] In particular embodiments, a GUI generated in accordance with the described techniques can facilitate input of grouping criteria by maintaining and displaying a list of frequently used grouping criteria (e.g., inventory data attributes). Referring to FIG. 10 , a particular embodiment maintaining such a “short list” is shown, generally designated 1000. Once inventory attributes are added to the grouping criteria (e.g., by selecting button 602 in FIG. 6 ), the short list of frequently used inventory attributes may be displayed in place of a list of all available inventory attributes. In the example on the left side of FIG. 10 , the short list includes building, department, display name, last inventory update, MDM profile deletion permission, mobile device group, model, monitored target, and user name. An “All Criteria” option may also be displayed at 1002. Selecting the “All Criteria” option 1002 will display a complete list of all inventory attributes available for defining the grouping criteria. The short list and the complete list may differ depending on whether the grouping criteria are defined for managed mobile devices, managed computers, or managed users.

[0074] The shortlist of frequently used attributes may be updated as the user defines dynamic groups. For example, as shown at 1004, the "Last Backup" attribute is added to the shortlist after "Last Backup" is selected one or more times during the definition of grouping criteria. In certain embodiments, the shortlist has a fixed size, and an overflow condition may occur when adding attributes to the list. In response to an overflow condition, when an attribute is added to the fixed-size shortlist, another (e.g., least recently used) attribute may be removed from the shortlist.

[0075] A GUI generated in accordance with the present disclosure can be used to indicate actions to be performed on members of a dynamic group. Examples of MDM actions include, but are not limited to, installing an application on a managed device, adjusting configuration settings on a managed device, providing content to a managed device, sending a message to a managed device, setting or clearing a passcode, editing one or more inventory data attributes, sending a communication / message (e.g., an email or short message service (SMS) message), deleting data, sending a remote command, etc. Referring to FIG. 11 , a specific embodiment of a GUI that can be used to select an action to be performed on members of a dynamic group is shown, generally designated 1100. In an exemplary embodiment, GUI 1100 may be displayed after selecting the view button 706 of FIG. 7 .

[0076] To illustrate, when the view button 706 is selected, a GUI may be displayed that includes a list of managed entities (e.g., computers, mobile devices, and / or users) that are members of a particular dynamic group. The list of managed entities may be based on group membership data 128 of Figure 1. In particular embodiments, when a user clicks the view button 706 of Figure 7, the membership of the dynamic group may be reevaluated (e.g., updated).

[0077] A user can display GUI 1100 by selecting an element (e.g., a button) on the GUI that includes a list of managed entities. GUI 1100 may also include a list of “bulk actions” that can be performed on each device that is a member of the dynamic group. In the example of FIG. 11, the list of actions includes editing the building or department of one or more managed entities in the group, editing the site of one or more managed entities in the group, sending a notification to one or more managed entities that have a particular application, content, or feature installed / activated (e.g., Self Service Mobile in FIG. 11), removing one or more managed entities (e.g., from the group, completely from the inventor database, etc.), and sending a remote command to one or more managed entities. In alternative embodiments, different “bulk actions” may be available. When an action is selected, the action is automatically performed on each managed entity in the group, or the user is provided with the option to select a specific managed entity in the group as the target of the action.

[0078] 12, a particular embodiment of an operation at an MDM server is shown and generally designated 1200. In an exemplary embodiment, method 1200 may be performed at MDM server 120 of FIG.

[0079] Method 1200 may include, at a server configured to access inventory data associated with a plurality of managed entities, generating 1202 a GUI operable to define grouping criteria for one or more dynamic groups of managed entities (e.g., managed computers, managed mobile devices, and / or managed users). For example, to generate a dynamic grouping GUI such as one of the GUIs described with reference to FIGS. 4-11 , the MDM server may access inventory and / or group membership data and include one or more elements (e.g., links, buttons, etc.) in the GUI based on the inventory and / or group membership data. The MDM server may enable and / or disable certain GUI elements based on the inventory and / or group membership data. For example, if a managed computer is not enrolled in the MDM server, GUI elements associated with the managed computer may be disabled (e.g., “grayed out” and / or unavailable for user selection).

[0080] The method 1200 may also include, at 1204, receiving first grouping criteria via a GUI, where the first grouping criteria is based on at least the second grouping criteria and a logical operator. For example, the MDM server 120 may receive grouping criteria for an “older mobile devices with low battery” dynamic group via the GUI 900 of FIG. 9 . The grouping criteria is based on the grouping criteria for the “older mobile devices” dynamic group and an AND operator. In particular embodiments, the first grouping criteria may be received based on user input. For example, the MDM server may receive data over a wired or wireless network from a computing device that displays a GUI and accepts user input. The data may include values ​​entered by a user into text fields, an indication of buttons selected by the user, etc. The MDM server can extract such data from the received packets / messages and determine the first grouping criteria based on the extracted data.

[0081] The method 1200 may further include, at 1206, receiving data via the GUI identifying an action to be performed with respect to the managed entities that meet the grouping criteria, and, at 1208, determining a group of managed entities that meet the first grouping criteria based on the inventory data. The managed entities may include managed mobile devices, managed computers, managed users, or a combination thereof. In particular embodiments, the data identifying the action may be received based on user input. For example, the MDM server may receive data over a wired or wireless network from a computing device that displays the GUI and receives user input, the data identifying an action selected by the user (e.g., from GUI 1100 of FIG. 11 ). The MDM server may extract such data from the received packets / messages and determine the selected action based on the extracted data. The MDM server can determine a group of managed entities that meet the first grouping criteria by filtering the inventory database using the first grouping criteria as a filter parameter. Alternatively, or in addition, the list of potential members that meet the first grouping criteria may be available in the form of group membership data, where the group membership data is updated in response to receiving updates from individual managed entities.

[0082] For example, as shown in FIG. 11, the MDM server may receive a selection of the "Send Remote Command" action of FIG. 11 to be performed on a mobile device in the "Older Mobile Devices with Low Battery" group.

[0083] Method 1200 may include, at 1210, initiating, by the server, sending a push notification regarding the action to be sent to each managed entity in the group of managed entities. For example, to initiate sending of the push notification, the MDM server may generate a push notification request including a list of group members and / or data regarding the action to be performed and send the push notification request to a push notification service (e.g., over a wired or wireless network). If communication with the MDM server is encrypted, receiving and sending data may also include encryption and decryption operations. To illustrate, in FIG. 1 , grouping criteria evaluation module 122 may identify members of the dynamic group, and MDM server 120 may send notification request 124 to push notification service 130. In response to notification request 124, push notification service 130 may send push notifications (e.g., push notifications 131 and / or 132) to members of the dynamic group (e.g., managed computer 140 and / or managed mobile device 150).

[0084] Referring to FIG. 13 , a specific embodiment of operations at a managed computer 140 and an MDM server 120 communicating with each other is shown, generally designated 1300. In an exemplary embodiment, some operations of method 1300 are performed on the managed computer 140, and some operations of method 1300 may be performed on the MDM server 120 of FIG. 1 . Method 1300 may include bidirectional communication between the managed computer 140 and the MDM server 120 of FIG. 1 . Method 1300 can provide a risk reduction of cybersecurity threat attack surface and lateral movement when a positive threat detection occurs on a user's managed computer 140. The managed computer 140 may include one or more apps or drivers installed thereon to provide additional risk signaling based on information provided by one or more applications 143 (e.g., security management apps) installed on the managed computer 140 and / or one or more applications 143 or 153 (e.g., security tools or apps) installed on the user's other managed computers 140 and / or managed mobile devices 150 available to the user.

[0085] In one example, MDM server 120 can have a device management app, such as, but not limited to, JAMF PRO software, installed and running for management of one or more user endpoint devices, e.g., user's managed computers 140. User's managed computers 140 may include APPLE® MAC® laptops that have an endpoint computer security app, such as, but not limited to, JAMF PROTECT software, installed and running to provide endpoint security. User's managed computers 140 may also have an endpoint security app, such as, but not limited to, JAMF PRIVATE ACCESS software, installed and running to facilitate, enable, and secure network access by user's managed computers 140 to various business systems via bidirectional communication with MDM server 120. Users may authenticate to business systems through an authentication provider (IdP) (e.g., but not limited to, an IdP app such as OKTA) that supports an application programming interface (API) for user authentication.

[0086] Method 1300 may include, at 1302, detecting a cybersecurity threat on a user's managed computer 140. As an example, an endpoint computer security app, such as, but not limited to, JAMF PROTECT, running on the user's APPLE® MAC® laptop may detect the cybersecurity threat.

[0087] Method 1300 may include, in response to detecting 1302 the cybersecurity threat, having MDM server 120 update 1304 the inventory record 212 in inventory database 123 corresponding to the managed computer 140 with information reflecting the positive detection of the cybersecurity threat. As an example, in response to detecting 1302 the cybersecurity threat, an endpoint computer security app, such as but not limited to, JAMF PROTECT, may trigger a remediation integration between and / or between a device management app, such as but not limited to, JAMF PRO, and the endpoint computer security app, such as but not limited to, JAMF PROTECT, such that the inventory record 212 in inventory database 123 corresponding to the managed computer 140 is updated with information reflecting the positive detection of the cybersecurity threat.

[0088] The method 1300 may include, at 1306, in response to updating the inventory record 212 in the inventory database 123, the grouping criteria evaluation module 122 of the MDM server 120 identifying an updated security threat detection status for the managed computer 140 from the inventory record 212, recalculating group membership for the managed computer 140 based on the updated security threat detection status for the managed computer 140, and updating the group membership data 128 based on the results of the recalculated group membership. The updated group membership data 128 may reflect that the managed computer 140 is added to and / or removed from a dynamic group based on the detection of a cybersecurity threat in the user's managed computer 140. The group membership updates and criteria may include identifying additional risks associated with the user's managed computer 140, such as, for example, an outdated operating system (OS), an improper or problematic configuration, device geolocation, the presence of a virus or malware, installed outdated or unpatched software, or other characteristics related to the hardware, software, location, or operation of the user's managed computer 140.

[0089] The method 1300 may include, at 1308, the MDM server 120 detecting a change in group membership of the user's managed computer 140 and sending a message and / or control signal to an agent and / or associated computing device pre-configured to receive notification of the group membership change. In one example, the agent may include instructions executable on a computing processor. For example, the agent may include instructions executable on the computing processor along with a computing processor. In one example, the agent may include an electronic circuit, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or other pre-configured electronic device pre-configured to perform the agent's predetermined function. As one example, sending the message and / or control signal may include sending an HTML POST request (hereinafter, a “webhook”) to a pre-defined URL (hereinafter, a “webhook receiver”) pre-configured to receive notification of the group membership change. The webhook may include a message or be an example of a message. The webhook receiver may include an agent or be an example of an agent. The message may include information about the user's managed computer 140 stored in an associated inventory record 212 in inventory database 123. In one example, computer-readable instructions executing on MDM server 120 may include a messaging function that detects changes in group membership of the user's managed computer 140 and triggers the output of a message to a defined agent. As one example, a device management app executing on MDM server 120, such as, but not limited to, JAMF PRO, may include a messaging function and / or webhook function that detects changes in group membership of the user's APPLE MAC computer 140 and triggers the output of a message to a defined agent or webhook receiver.

[0090] At 1310, the method 1300 may include, in response to receiving the message at 1308, the agent performing a predefined action. The predefined action may be implemented, for example, via computational instructions or scripts executable on a computing processor. The predefined action may include: (a) obtaining an API token for the MDM server 120 (e.g., a device management app, such as, but not limited to, JAMF PRO, running on the MDM server 120); (b) gathering information about the user's managed computer 140 from the message receipt data and parsing the message receipt data to determine an ID code corresponding to the user's managed computer 140; and (c) querying the MDM server 120 (e.g., a device management app, such as, but not limited to, JAMF PRO, running on the MDM server 120, via the app's API) to obtain information about the user's managed computer 140 stored in an associated inventory record 212 in the inventory database 123. The information includes a device identifier for the user's managed computer 140 and an identifier for the associated user. The associated user's identifier may be determined in conjunction with or by reference to an IdP app, such as, but not limited to, OKTA, and / or a username associated with the associated inventory record 212 for the user's computer system 140 in the inventory database 123 of the MDM server 120, and / or a device management app, such as, but not limited to, JAMF PRO, running on the MDM server 120.

[0091] The method 1300 may include, at 1312, obtaining a universally unique identifier (UUID) for the user managed computer 140 from information about the user managed computer 140 obtained at 1310 from the associated inventory record 212 in the inventory database 123. The database record of the risk level for the user managed computer 140 may be updated based on the severity of the detected risk and the current group membership of the user managed computer 140. The risk level may be updated to one of several levels, for example, low, medium, or high. The UUID may be used to identify the user managed computer 140 in the database record of the risk level for the user managed computer 140. In one example, the database record of the risk level for the user managed computer 140 may be stored and / or accessed via a web interface and / or API. In one example, the web interface and / or API may include an app, such as, but not limited to, the JAMF RADAR web portal or other web portal app. In one example, the app may include an API function, such as, but not limited to, JAMF RADAR API endpoint / risk / v1 / override, that rapidly (e.g., immediately or near-instantly) updates a database record of the risk level of the user's managed computer 140 and may trigger changes in access to protected systems within the protected computing network, for example, through an endpoint security app (e.g., an endpoint security app such as, but not limited to, JAMF PRIVATE ACCESS) on the user's managed computer 140. In one example, the operation of 1312 may be performed by an agent or an associated computing device.

[0092] Updates to the risk level of the user's managed computer 140 in the risk level database record (e.g., including but not limited to, a web portal app, a JAMF RADAR web portal, and / or other database) of the user's managed computer 140 may include risk signals based on the detection of cybersecurity threats and may be augmented by computer inventory and configuration details (e.g., inventory database 123) from the MDM server 120, thereby facilitating the user's managed computer 140 being reclassified within the risk level database record (e.g., including but not limited to, a web portal app, a JAMF RADAR web portal, and / or other database) of the user's managed computer 140 and / or any security and access policies within a security app (e.g., a security app such as JAMF PRIVATE ACCESS) of the user's managed computer 140 being correspondingly adjusted for the user's managed computer 140. For example, an updated risk status of a user managed computer 140 that is a medium or medium risk may limit or restrict access to the user managed computer 140's business computing systems and resources, such as customer relationship management (CRM) and human resources (HR) systems, while still allowing the user managed computer 140 access to less critical business computing systems. If the user managed computer 140's updated risk status is high, the user managed computer 140 may be restricted from accessing all computing systems on the organization's protected computing network.Thus, risk will be mitigated across any business or computing system within a protected computing network environment where access is restricted by an endpoint security app on the managed device (e.g., but not limited to, a security app such as JAMF PRIVATE ACCESS).

[0093] Method 1300 may include, at 1314, in response to obtaining an identifier for the user at 1310 (e.g., determined in conjunction with or with reference to an IdP app such as, but not limited to, OKTA, and / or a username associated with the user's associated inventory record 212 for the user's computer system 140 in inventory database 123 of MDM server 120, and / or a device management app such as, but not limited to, JAMF PRO running on MDM server 120), restricting and / or revoking the user's access to one or more business systems on the computing network protected by MDM server 120 and / or a device management app such as, but not limited to, JAMF PRO running on MDM server 120, and / or one or more portions of the computing network or itself. First, an API for the IdP (e.g., an IdP app such as, but not limited to, OKTA) may be queried with the user's identifier (e.g., username) to obtain a user ID from the IdP (this may depend on what IdP functionality and IdP API functionality is provided). Second, the IdP's API may be queried to disable the user account associated with the user ID within the IdP, thereby preventing that user account from being used for new authentications to any business systems on the organization's protected computing network that use the IdP for authentication and / or authorization. In one example, the user's IdP username may be associated with a computer inventory record in a device management app, such as, but not limited to, JAMF PRO, running on the MDM server 120 via an extended attribute feature if populated from an authentication or identity management app, such as, but not limited to, JAMF CONNECT, during inventory collection, or from native user information collection during inventory collection. Any active sessions of the disabled user account may also be disabled.In certain other aspects, the IdP's API may be queried to clear the user session token (API token), force a password reset, suspend the user, and other appropriate actions.

[0094] The above-described operations at 1312 and 1314 for restricting (e.g., at 1312) the access of a user's computer system 140 to the organization's systems on the protected computer network, and for restricting or disabling (e.g., at 1314) the user's user account on the organization's systems on the protected computer network, may be designed to reduce access of medium to high risk computer systems 140 and associated users to business-critical systems on the organization's protected computer network and mitigate risk.

[0095] Method 1300 may optionally include, at 1316, performing one or more actions to remediate one or more risk factors associated with one or more groups of which the user managed computer 140 is a member, in response to the information obtained at 1310 and / or group membership data 128 corresponding to the user managed computer 140 (changes of which may have been detected at 1308). Modification of the risk factors associated with group membership may be triggered for the purpose of causing the user managed computer 140 to resolve one or more risks that caused it to be included as a member of a group associated with the one or more risks. Resolving the one or more risks may return the user managed computer 140 to member status in one or more groups not associated with the one or more risk factors, and further, remove it from membership in one or more groups associated with the one or more risk factors, thereby enabling the user and / or the user managed computer 140 to resume normal access to services of the organization's protected computing network. Resolving the risk may include, for example, patching software applications that pose a risk due to the need for patching, or changing the configuration of software applications, operating systems, or hardware that pose a risk due to their current configuration, in order to return the user's managed computer 140 to a manageable and acceptable risk level.

[0096] Method 1300 may optionally include, at 1318, in response to obtaining an identifier for the user at 1310 (e.g., determined in conjunction with or with reference to an IdP app such as, but not limited to, OKTA and / or a username associated with the user's computer system 140's associated inventory record 212 in inventory database 123 of MDM server 120, and / or a device management app such as, but not limited to, JAMF PRO running on MDM server 120), querying one or more security applications 143 installed on MDM server 120 and / or the user's managed computer 140 to identify one or more additional managed devices (e.g., managed computer 140 and / or managed mobile device 150) associated with the user having the username and / or other obtained user identifier. For each of the one or more additional managed devices that may be identified as associated with the user, operations of method 1300 may be performed to establish additional risk signaling and access restrictions in a manner and with corresponding effects to the risk signaling and access restrictions established for the user's managed computer 140, as described above. Thus, group memberships and / or restrictions established based on a user's managed computer 140 may apply to all managed devices on the managed computing network associated with that user.

[0097] Method 1300 may optionally include, at 1320, in response to updating the risk level of the user's managed computer 140 in the risk level database record (e.g., a web portal such as, but not limited to, the JAMF RADAR web portal) at 1312, posting one or more risk notifications from the risk level database (e.g., a web portal such as, but not limited to, the JAMF RADAR web portal) to notify other security tools and apps operating within the protected computing network environment in an industry standard format (e.g., CAPE / SDP).

[0098] The methods and operations described herein facilitate providing cybersecurity capabilities by utilizing network device management solutions as intermediaries. Benefits include layering additional cybersecurity risk context about a user's managed computers 140 (e.g., Apple Mac computers) from broad computer characteristic and configuration inventory data (e.g., stored in inventory database 123). Such inventory data can range from simple or straightforward information, such as outdated operating system (OS) versions, to complex information, such as device geolocation or specific configuration settings, by grouping managed devices within a protected network according to computer characteristic and configuration inventory data associated with different risk factors and / or risk levels. The methods and operations described herein facilitate the assurance and protection of both cloud-based and on-premise computing networks (e.g., via security software such as, but not limited to, the JAMF PRIVATE ACCESS software solution). Risk signaling as described herein can provide broad lateral movement mitigation across all business-critical computing systems within a protected computing network environment. Another advantage is layering additional risk context, such as state and context from additional managed devices within the protected computing network that are owned or controlled by the user who owns or manages the managed computer 140 described above.

[0099] It should be noted that the order of steps or operations described with reference to FIGS. 1-13 is illustrative and not limiting. In alternative embodiments, the order of steps may differ. Furthermore, one or more steps may be optional and / or replaced with other steps. For example, in certain embodiments, steps 1202 and 1204 may be optional (e.g., dynamic groups may be predefined and method 1200 may begin with step 1206 when a user selects an action to be performed on members of the dynamic group). Furthermore, one or more steps may be integrated. In accordance with various embodiments of the present disclosure, one or more methods, functions, and modules described herein may be implemented in a software program executable by a computer system. Furthermore, implementations of one or more embodiments in accordance with the present disclosure may include distributed processing, component / object distributed processing, and / or parallel processing.

[0100] Certain embodiments may be implemented using a computer system executing a set of instructions that cause the computer system to perform any one or more of the methods or computer-based functions disclosed herein. The computer system may include a laptop computer, a desktop computer, a server computer, a mobile phone, a tablet computer, a media player, one or more other computing devices, or any combination thereof. The computer system may be connected to other computer systems and peripheral devices, for example, using a network. For example, the computer system or components thereof may include or be included in one or more of the following: MDM server 120 of FIG. 1 , a computing device or server corresponding to push notification service 130 of FIG. 1 , managed computer 140 of FIG. 1 , managed mobile device 150 of FIG. 1 , email server 170 of FIG. 1 , an output device that displays a GUI generated by the MDM server, an input device that receives user input responsive to the GUI, and / or a computing device that includes an output device and an input device.

[0101] In a network deployment, the computer system may operate as a server or as a client-user computer in a server-client-user network environment. The term "system" may include any collection of systems or subsystems that individually or collectively execute a set of instructions or multiple sets of instructions to perform one or more computer functions.

[0102] In certain embodiments, the instructions may be embodied in a computer-readable or processor-readable device. The terms "computer-readable device" and "processor-readable device" include a single storage device or multiple storage devices, such as centralized or distributed memory and / or associated caches and servers, that store one or more sets of instructions. The terms "computer-readable device" and "processor-readable device" also include any device that can store a set of instructions for execution by a processor or that can cause a computer system to perform any one or more of the methods or operations disclosed herein. For example, a computer-readable or processor-readable device or storage device may include random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, a hard disk, a removable disk, disk memory (e.g., compact disk read-only memory (CD-ROM)), solid-state memory, or any other form of storage device. A computer-readable device or processor-readable device is not a signal.

[0103] In certain embodiments, a method includes generating, at a server configured to access inventory data associated with one or more managed devices, a GUI operable to define grouping criteria for one or more dynamic groups of managed devices. The method also includes receiving, at the server via the GUI, first grouping criteria and data identifying actions to be performed on managed devices that meet the first grouping criteria. The first grouping criteria is based on at least second grouping criteria and a logical operator. The method further includes determining, at the server, groups of managed devices that meet the first grouping criteria based on the inventory data. The method includes initiating, by the server, sending push notifications regarding the actions to each managed device in the group of managed devices.

[0104] In another particular embodiment, an apparatus includes a processor and memory storing instructions that, when executed by the processor, cause the processor to perform operations including generating a GUI operable to define grouping criteria for one or more dynamic groups of managed devices. The operations also include receiving, via the GUI, first grouping criteria, the first grouping criteria based on at least second grouping criteria and a logical operator. The operations further include receiving, via the GUI, data identifying an action to be performed on the managed devices that meet the first grouping criteria. The operations further include determining, based on the inventory data, a group of managed devices that meets the first grouping criteria and initiating sending a push notification regarding the action to each managed device in the group of managed devices.

[0105] In another particular embodiment, a computer-readable storage device has recorded thereon instructions that, when executed by a processor, cause the processor to perform operations including generating, at a server configured to access inventory data associated with one or more managed devices and one or more managed users, a GUI operable to define grouping criteria for one or more groups of managed devices, managed users, or both. The operations also include receiving, at the server, first grouping criteria via the GUI; and receiving, at the server, via the GUI, data identifying actions to be performed on the managed devices that meet the first grouping criteria. The first grouping criteria is based on at least the second grouping criteria and a logical operator. The operations further include determining, at the server, groups of managed devices, groups of managed users, or both that meet the first grouping criteria based on the inventory data. The operations include initiating, by the server, sending a push notification regarding the action to each managed device in the group of managed devices, at least one device associated with each user in the group of managed users, or both.

[0106] The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of various embodiments. The illustrated forms are not intended to be a complete description of all elements and features of apparatus and systems that utilize the structures or methods described herein. Many other embodiments will be apparent to those skilled in the art upon review of the disclosure. Other embodiments may utilize and derive from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Accordingly, the disclosure and figures are to be considered illustrative and not restrictive.

[0107] Although specific embodiments have been illustrated and described herein, it is to be understood that any subsequent arrangements designed to achieve the same or similar purposes may be substituted for the specific embodiments shown. This disclosure is intended to cover any subsequent adaptations or variations of the various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those skilled in the art upon review of this specification.

[0108] This Summary is submitted with the understanding that it will not be used to interpret or limit the scope of the claims. In addition, in the foregoing Detailed Description, various features may be grouped together or described in a single embodiment for the purpose of streamlining the disclosure. This disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter may be directed to some, but not all, features of any of the disclosed embodiments.

[0109] The subject matter disclosed above is considered to be illustrative and not limiting, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments that fall within the scope of this disclosure. Accordingly, the scope of the present disclosure shall, to the maximum extent permitted by law, be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be limited or constrained by the foregoing detailed description.

[0110] In one aspect, a method may be an operation, an instruction, or a function, or vice versa. In one aspect, a phrase or claim may be modified to include some or all of the terms (e.g., instructions, operations, functions, or components) recited in one or more other phrases, and may be modified to include one or more words, one or more sentences, one or more phrases, one or more paragraphs, one or more paragraphs, and / or one or more claims.

[0111] To illustrate the interchangeability of hardware and software, various illustrative blocks, modules, components, methods, operations, instructions, algorithms, etc. have been described generally in terms of their functionality. Whether such functionality is implemented as hardware, software, or a combination of hardware and software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in a variety of ways for each particular application.

[0112] As used herein, the phrase "at least one," with the term "and" or "or" separating the items, precedes a list of items and modifies the entire list, rather than each item in the list (e.g., each item). The phrase "at least one" does not require the selection of at least one item. Rather, the phrase allows for the inclusion of at least one of any one of the items, and / or at least one of any combination of the items, and / or at least one of each of the items. For example, the phrase "at least one of A, B, and C" or "at least one of A, B, or C" refers to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C, respectively.

[0113] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." An embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. Terms such as "aspect," "the aspect," "another aspect," "some aspects," "one or more aspects," "implementation," "the implementation," "another implementation," "some implementations," "one or more implementations," "embodiment," "the embodiment," "another embodiment," "some embodiments," "one or more embodiments," "configuration," "the configuration," "another configuration," "some configurations," "one or more configurations," the subject technology, disclosure, the present disclosure, other variations thereof, and similar expressions are used for convenience and do not imply that disclosure associated with such terms is essential to the subject technology or that such disclosure applies to all configurations of the subject technology. Disclosure associated with such terms may apply to all configurations or to one or more configurations. Disclosure associated with such terms may provide one or more examples. Terms such as "aspect" or "some aspects" may refer to one or more aspects, and vice versa, as well as other preceding terms.

[0114] A reference to an element in the singular does not mean "one and only one" unless otherwise specified, but rather "one or more." The term "some" refers to one or more. Underlined and / or italicized headings and subheadings are used for convenience only and do not limit the subject technology, and are not to be construed in connection with the interpretation of the description of the subject technology. Relationship terms such as "first" and "second" may be used to distinguish one entity or operation from another, but do not necessarily require or imply an actual relationship or order between such entities or operations. All structural and functional equivalents to the various components described throughout this disclosure that are known or later become known to those skilled in the art are expressly incorporated herein by reference and are intended to be encompassed by the subject technology. Furthermore, the content disclosed herein, whether or not expressly set forth in the above description, is not intended to be made publicly available. No claim element may be construed under 35 U.S.C. § 112, paragraph 6, unless the element is expressly recited using the language "means," or, in the case of a method claim, the element is recited using the language "step."

[0115] While this specification contains many specificities, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of particular implementations of the subject matter. Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, while the features described above may be described as working in particular combinations and may initially be claimed as such, one or more features of a claimed combination may, in some cases, be deleted from the combination, and the claimed combinations may be directed to subcombinations or variations of such combinations.

[0116] Although the subject matter herein has been described in terms of particular embodiments, other embodiments are possible and are within the scope of the following claims. For example, while the figures depict operations in a particular order, this should not be understood as requiring such operations to be performed in the particular order or sequential order depicted, or even to perform all of the depicted operations, to achieve desirable results. The operations recited in the claims can be performed in a different order and still achieve desirable results. As an example, the processes depicted in the accompanying figures do not necessarily have to be performed in the particular order or sequential order depicted to achieve desirable results. Multitasking or parallel processing may be advantageous in certain situations. Furthermore, the separation of various system components in the above-described embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated into a single software product or packaged into multiple software products.

[0117] The title, background art, brief description of the drawings, abstract, and drawings are incorporated into this disclosure and are provided as illustrative of the disclosure, not as limiting descriptions. They are submitted with the understanding that they will not be used to limit the scope or meaning of the claims. Furthermore, in the detailed description, it will be appreciated that the specification provides illustrative examples, and that various features have been grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention requiring more features than are expressly recited in each claim. Rather, as the claims reflect, original subject matter lies in less than all features of a single disclosed structure or operation. Each claim herein is incorporated herein by its own independent, individually claimed subject matter.

[0118] The claims are not intended to be limited to the embodiments described herein, but are to be accorded the full scope consistent with the language of the claims and encompass all legal equivalents. However, no claim is intended, and should not be interpreted, to encompass subject matter that does not comply with applicable patent law requirements.

Claims

1. identifying an elevated risk profile of an endpoint device on a computing network according to one or more characteristics of the endpoint device; including the endpoint device having the elevated risk factor in a group of endpoint devices identified as having an elevated risk level; and restricting access by the group of endpoint devices identified as having the elevated risk level to one or more computing systems and / or computing applications accessible on the computing network based on the elevated risk level.

2. The method of claim 1 , wherein the one or more characteristics of the endpoint device include an installed operating system version that is outdated.

3. The method of claim 1 , wherein the one or more characteristics of the endpoint device include a geolocation of the endpoint device.

4. identifying a user associated with the endpoint device having the elevated risk factor; identifying one or more additional endpoint devices on the computing network associated with the identified user; and 10. The method of claim 1, further comprising: including the one or more additional endpoint devices in the group of endpoint devices identified as having the elevated risk level.

5. 5. The method of claim 4, further comprising: invalidating user credentials associated with the user on one or more computing systems and / or computing applications accessible on the computing network based on the elevated risk factors.

6. The method of claim 5 , further comprising modifying the elevated risk factors associated with the group of endpoint devices.

7. The method of claim 6 , further comprising restoring the endpoint device to membership status in response to correcting the elevated risk factor.

8. a processor; a memory configured to store instructions; The instructions, when executed by the processor, cause the processor to: identifying an elevated risk profile for an endpoint device on a computing network according to one or more characteristics of the endpoint device; causing the endpoint device having the elevated risk factor to be included in a group of endpoint devices identified as having an elevated risk level; and restricting access by the group of endpoint devices identified as having the elevated risk level to one or more computing systems and / or computing applications accessible on the computing network based on the elevated risk level.

9. The apparatus of claim 8 , wherein the one or more characteristics of the endpoint device include an installed operating system version that is outdated.

10. The apparatus of claim 8 , wherein the one or more characteristics of the endpoint device include a geolocation of the endpoint device.

11. The memory, when executed by the processor, causes the processor to: identifying a user associated with the endpoint device having the elevated risk factor; identifying one or more additional endpoint devices on the computing network associated with the identified user; 10. The apparatus of claim 8, configured to store instructions that cause the one or more additional endpoint devices to be included in the group of endpoint devices identified as having the elevated risk level.

12. The memory, when executed by the processor, causes the processor to:

12. The apparatus of claim 11, configured to store instructions to cause user credentials associated with the user on one or more computing systems and / or computing applications accessible on the computing network to be invalidated based on the elevated risk factor.

13. The memory, when executed by the processor, causes the processor to: The apparatus of claim 12 , configured to store instructions for modifying the elevated risk factors associated with the group of endpoint devices.

14. The memory, when executed by the processor, causes the processor to:

14. The apparatus of claim 13, configured to store instructions that cause the endpoint device to return to membership status in response to correcting the elevated risk factor.

15. a non-transitory computer-readable storage device that stores instructions, The instructions, when executed by a processor, cause the processor to: identifying an elevated risk profile for an endpoint device on a computing network according to one or more characteristics of the endpoint device; causing the endpoint device having the elevated risk factor to be included in a group of endpoint devices identified as having an elevated risk level; and limiting access by the group of endpoint devices identified as having the elevated risk level to one or more computing systems and / or computing applications accessible on the computing network based on the elevated risk level.

16. The non-transitory computer-readable storage device of claim 15 , wherein the one or more characteristics of the endpoint device include an installed operating system version that is outdated.

17. The non-transitory computer-readable storage of claim 15 , wherein the one or more characteristics of the endpoint device include a geolocation of the endpoint device.

18. When executed by the processor, the processor: identifying the user associated with the endpoint device having the elevated risk factor; identifying one or more additional endpoint devices on the computing network associated with the identified user; 16. The non-transitory computer-readable storage device of claim 15, storing instructions for causing the one or more additional endpoint devices to be included in the group of endpoint devices identified as having the elevated risk level.

19. When executed by the processor, the processor:

20. The non-transitory computer-readable storage device of claim 18, storing instructions for causing user credentials associated with the user on one or more computing systems and / or computing applications accessible on the computing network to be revoked based on the elevated risk factor.

20. When executed by the processor, the processor:

20. The non-transitory computer readable storage device of claim 19, storing instructions for modifying the elevated risk factors associated with the group of endpoint devices.

Images