FIELDNOTICE: More than one reissue application has been filed for the reissue of U.S. Pat. No. 8,397,301 B2. This is an application for reissue of U.S. Pat. No. 8,397,301 B2 and this application is a continuation of application Ser. No. 16/670,488, which is also an application for reissue of U.S. Pat. No. 8,397,301 B2 and a continuation of application Ser. No. 15/898,124, now U.S. Pat. No. RE47,757, which is also an application for reissue of U.S. Pat. No. 8,397,301 B2 and a continuation of application Ser. No. 14/109,725, now U.S. Pat. No. RE46,768, which is also an application for reissue of U.S. Pat. No. 8,397,301 B2.
The invention relates generally to mobile security, and specifically, to assessing the vulnerability of a mobile communication device.
BACKGROUNDMobile communication devices or mobile devices, such as cellular telephones, smartphones, wireless-enabled personal data assistants, and the like, are becoming more popular as cellular and wireless network providers are able to expand coverage and increase bandwidth. Mobile devices have evolved beyond providing simple telephone functionality and are now highly complex multifunctional devices with capabilities rivaling those of desktop or laptop computers. In addition to voice communications, many mobile devices are capable of text messaging, e-mail communications, internet access, and the ability to run full-featured application software. Mobile devices can use these capabilities to perform online transactions such as banking, stock trading, payments, and other financial activities. Furthermore, a mobile device used by an individual, a business, or a government agency can often store confidential or private information in forms such as electronic documents, text messages, access codes, passwords, account numbers, e-mail addresses, personal communications, phone numbers, and financial information.
In turn, it is more important to protect those devices against malware, malicious attacks and other exploits. Specifically, it would be helpful to be able to identify vulnerabilities for a mobile communication device, so that the user of the mobile communication device can be alerted if his or her device suffers from any exploitable weaknesses. It is also important for an organization that relies on mobile devices to understand the state of their security and be able to respond to vulnerabilities on mobile devices in an efficient and effective manner.
Presently, current solutions for assessing the vulnerabilities of a computer on a network focus on a conventional desktop, laptop, server, or other computing devices that often enjoy more processing power and memory than a mobile communication device and generally have less restricted application environments than a mobile communication device. As such, these computing devices can often include local monitoring services that can run in the background without overly taxing valuable computing resources. In addition, conventional computing devices are often consistently tethered to a particular local network, such that devices can be remotely scanned over the local network for security weaknesses. Mobile communication devices, on the other hand, are often connected to public networks and switch between networks and network types, making remote, network-based security scans undesirable.
What is therefore needed is a way to provide similar protective services for mobile communication devices in a manner that does not overly tax resources on the mobile communication device, and that extends protective services even when the mobile communication device is not connected to a particular network or is not connected to any network.
There are many differences between mobile communication devices (e.g. operating systems, hardware capabilities, software configurations) that make it difficult to have a single system for accurately assessing the vulnerability of multiple types of devices. Additionally, many mobile communication devices are able to accept installation of various third-party software applications or “apps” that have been developed to extend the capabilities of the device. The installation of apps can alter the vulnerability state of a device, since each app may alter how and with which networks the mobile device communicates. What is therefore needed is a way to assess vulnerabilities of a mobile communication device that accounts for differences such as the operating system, the make, model, configuration, or any installed software on the mobile device. Also needed is a way for a user or administrator to view the security status of, remediate, and otherwise assess and manage the security of multiple different mobile communication devices.
BRIEF DESCRIPTION OF THE FIGURESThe invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which:
FIG.1 is an exemplary block diagram depicting an embodiment of the invention.
FIG.2 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.3 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.4 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.5 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.6 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.7 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.8 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.9 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.10 is an exemplary flow diagram illustrating the steps of an embodiment of the invention.
FIG.11 is an exemplary screenshot illustrating an embodiment of the invention.
DETAILED DESCRIPTIONThe invention is a system and a method for identifying, assessing, and responding to vulnerabilities on or affecting a mobile communication device. As will be discussed further below, a mobile communication device may transmit certain information to a server, and the server may transmit certain result information to the device that contains an assessment or identifies known or potential vulnerabilities affecting the device. Additionally or alternatively, the server may transmit notifications about possible or actual vulnerabilities affecting a mobile communication device, which may include instructions for remediating any vulnerabilities identified as affecting the mobile communication device. Furthermore, the server may host a management console that allows an administrator to view the security status of multiple mobile communication devices and take action to secure them if necessary.
It should be appreciated that the invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, a computer readable medium such as a computer readable storage medium containing computer readable instructions or computer program code, or as a computer program product comprising a computer usable medium having a computer readable program code embodied therein. One will appreciate that the mobile communication device described herein may include any computer or computing device running an operating system for use on handheld or mobile devices, such as smartphones, PDAs, mobile phones and the like. For example, a mobile communication device may include devices such as the Apple iPhone®, the Palm Pre™, or any device running the Android™ OS, Symbian OS®, Windows Mobile® OS, Palm OS® or Palm Web OS™.
In the context of this document, a computer usable medium or computer readable medium may be any medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus or device. For example, the computer readable storage medium or computer usable medium may be, but is not limited to, a random access memory (RAM), read-only memory (ROM), or a persistent store, such as a mass storage device, hard drives, CDROM, DVDROM, tape, erasable programmable read-only memory (EPROM or flash memory), or any magnetic, electromagnetic, infrared, optical, or electrical system, apparatus or device for storing information. Alternatively or additionally, the computer readable storage medium or computer usable medium may be any combination of these devices or even paper or another suitable medium upon which the program code is printed, as the program code can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
Applications, software programs or computer readable instructions may be referred to as components or modules. Applications may be hardwired or hard coded in hardware or take the form of software executing on a general purpose computer such that when the software is loaded into and/or executed by the computer, the computer becomes an apparatus for practicing the invention. Applications may also be downloaded in whole or in part through the use of a software development kit or toolkit that enables the creation and implementation of the invention. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.
FIG.1 is a block diagram illustrating an embodiment of a system for identifying and assessing vulnerabilities on a mobile communication device. In an embodiment, the system may include one or moremobile communication devices101 connected on a cellular, wireless Internet orother network121. One ormore servers151 may also have access tonetwork121. The one ormore servers151 may receive one or more sets of vulnerability identification information from the one or moremobile communication devices101, and/or may transmit one or more sets of result information to the one or moremobile communication devices101. In addition, the one ormore servers151 may have access to adata storage111 that stores information about mobile communication device vulnerabilities. One will appreciate thatdata storage111 may be a database, data table, file system or other memory store.Data storage111 may be hosted on any of the one ormore servers151, or may exist externally from the one ormore servers151, so long as the one ormore servers151 have access todata storage111. One will also appreciate that the configuration of the system illustrated inFIG.1 is merely exemplary, and that other configurations are possible without departing from this disclosure or the scope of the invention. For example,servers151 ordata storage111 may be singular or plural, or may be physical or virtualized.
One will appreciate that communication betweenmobile communication device101 andserver151 may utilize a variety of networking protocols and security measures. In an embodiment,server151 operates as an HTTP server and thedevice101 operates as an HTTP client. To secure the data in transit,mobile communication device101 andserver151 may use Transaction Layer Security (“TLS”). Additionally, to ensure thatmobile communication device101 has authority to accessserver151, and/or to verify the identity ofmobile communication device101,device101 may send one or more authentication credentials toserver151. For example, authentication credentials may include a username and password or any other data that identifiesmobile communication device101 toserver151. Authentication may allowserver151 to store specific information, such as vulnerability identification information, aboutmobile communication device101, and may also provide a persistent view of the security status ofmobile communication device101.
As previously mentioned,data storage111 may be used to store sets of information about mobile communication device vulnerabilities (“vulnerability information”), which may be transmitted in whole or in part to one or more mobile communication devices in the form of “result information.” As used herein, a vulnerability may include an exploitable weakness on a mobile communication device that may result from the device hardware or software. Vulnerabilities may arise due to weaknesses in the device's operating system, other software or hardware flaws in the device, protocol implementation or specification flaws, misconfiguration of the device, software applications installed or stored on the device, or services provided through, to or by the device. Vulnerabilities may arise form the features of the device, such as from the presence of Bluetooth, infrared or Internet capabilities on the device, or other communication interfaces and protocols available on the device. Vulnerabilities may arise from weaknesses in the device's interaction with, flaws in, or misconfiguration of other services and systems such as text messaging, voice mail, telephony, or other services and systems accessed through a mobile communication device. Information about a vulnerability, i.e., vulnerability information, may be stored indata storage111 and accessed byserver151 ormobile communication device101.Data storage111 may store general information about mobile communication device vulnerabilities, or may store information about vulnerabilities specific to a mobile communication device. As will be discussed further below, sets of vulnerability information corresponding to vulnerabilities that could affect or actually affect the mobile communication device may be transmitted in the form of result information, notifications, or both.
One will appreciate that as used herein, vulnerability information may include the name, description, severity rating, security impact summary and remediation instructions for a vulnerability. Vulnerability information may be included in theresult information server151 transmits tomobile communication device101 or may be stored indata storage111. Result information may include a list of vulnerabilities that are known to affectmobile communication device101, a list of potential vulnerabilities that may affectmobile communication device101, and a list of vulnerabilities that are known not to affectmobile communication device101. Each entry in a list of vulnerabilities may include some or all of the set of vulnerability information for a vulnerability. As will be discussed in more detail below, the result information may also include a binary assessment of mobile communication device101 (e.g., good or bad, “okay” or “not okay”), a threat score, remediation instructions for known or potential vulnerabilities, or may instruct display of a graduated icon that changes depending upon state (a sad face for a vulnerable mobile communication device, to a happy face for a “safe” mobile communication device). Vulnerability information may include criteria for determining if amobile communication device101 is affected. In an embodiment, vulnerability information may include information about a vulnerability such as a title, a description, a security impact summary, human or computer readable remediation instructions or a severity rating for the vulnerability.
As used herein, “vulnerability identification information” or “identification information” includes data thatserver151 may use to determine ifmobile communication device101 is susceptible to any vulnerabilities. Such vulnerability identification information may include the operating system and version formobile communication device101; the firmware version of themobile communication device101, the device model formobile communication device101; carrier information formobile communication device101; authentication information; and/or user information for the user ofmobile communication device101. Vulnerability identification information may also include a list of files, software components, libraries and/or a list of the applications or other software installed onmobile communication device101, as well as other information related to these applications and software such as version and configuration information, configuration information about themobile communication device101, communications interfaces and protocols in use by mobile communication device101 (e.g., WiFi, Bluetooth, IR, SMS, MMS), cellular network information, cellular carrier information, the make and model ofmobile communication device101, and the like.
In an embodiment, vulnerability information stored indata storage111 may have associated information that includes a description, a title, an overview of the security impact, remediation instructions, and criteria for affected firmware versions. In an embodiment,mobile communication device101 sends vulnerability identification information toserver151 that includes the device's firmware version.Server151 may utilizedata storage111 to examine the vulnerability information stored therein and determine if the firmware version formobile communication device101 matches the firmware version criteria for any vulnerabilities. If any vulnerabilities match,server151 may determine thatmobile communication device101 is vulnerable.Server151 may then transmit result information to themobile communication device101, as described herein and shown in the Figures. In an embodiment,server151 only transmits result information corresponding to vulnerabilities that affectmobile communication device101. In an embodiment,server151 transmits result information for all vulnerabilities that may affectdevice101. In an embodiment,server151 transmits result information which contains all vulnerabilities that may affectdevice101 and which of those vulnerabilities actually do affectdevice101. In an embodiment, the firmware version criteria for being affected by a vulnerability includes the version of the firmware in which the vulnerability was fixed. One will appreciate that some vulnerabilities may only affect certain firmware versions, and that once firmware has been updated to a new version, some vulnerabilities which affected previous versions may no longer be of issue. In order to account for variations in firmware,server151 may detect and transmit information for vulnerabilities regardless of the firmware version onmobile communication device101, thereby adding extra precautions. Alternatively,server151 may only send result information for those vulnerabilities that affect the version of firmware installed onmobile communication device101, thereby being more specific.
For example, a certain vulnerability may affect a mobile communication device having firmware version 1.0, but not a mobile communication device with firmware version 2.0.Server151 may receive information about the firmware version ofmobile communication device101, and if the firmware version is earlier than version 2.0, thenmobile communication device101 is determined to be susceptible to the certain vulnerability. However, if the firmware version formobile communication device101 is 2.0 or higher, thenmobile communication device101 may not be susceptible to the certain vulnerability. One will appreciate that other variations are possible, and that the determination of whether to send more or less result information may be a setting specified by an administrator, or may involve the application of logic depending upon the severity of the vulnerability and the risks or benefits of transmitting an overabundance of result information tomobile communication device101. One will also appreciate that the amount of result information to transmit tomobile communication device101 may also depend upon the capabilities ofmobile communication device101 or the bandwidth of the network.
In an embodiment,data storage111 stores vulnerability information for at least two types ofmobile devices101. The two mobile device types may have different operating systems, firmware versions, model numbers, carrier information, authentication information, user information, configuration information, states, software applications, and the like. As a result, the vulnerability identification information for each of the at least two mobile devices will differ in some aspect. As such, in an embodiment,data storage111 may store vulnerability information for vulnerabilities that may affect both of the two device types, including vulnerabilities that may affect one device type but not the other. One will appreciate thatdata storage111 may store vulnerability information for a variety of mobile communication devices, and will be able to provide information that will help identify, assess and remediate vulnerabilities for a variety of mobile communication devices.
Whendata storage111 stores information about vulnerabilities that may affect multiple types of mobile communication devices, it is important that the transmitted result information not include information regarding vulnerabilities that a user may perceive as irrelevant to a particular device. As such it is important that the list of vulnerabilities that may affect a device not simply include all vulnerabilities stored bydata storage111. In an embodiment, a vulnerability may affect a device if the device's vulnerability identification information at least partially matches the vulnerability's criteria for affecting a device. Providing partially matching result information provides a conservative, or safer approach to detecting and identifying potential vulnerabilities, as it may provide a opportunity for further assessment and action (e.g. further analysis conducted by software on a device), rather than only providing full criteria matches.
In an embodiment, the partial match includes criteria related to a device that does not change, is unlikely to change, or is irrespective of particular software versions, firmware versions, updates, and configuration. Such criteria may include the device's operating system, model, carrier, software applications installed, hardware capabilities, and the like. For example,data storage111 may store information about a vulnerability that affects a particular range of firmware versions of the Apple iPhone® OS. This vulnerability information may include criteria that it affects the Apple iPhone® OS and criteria that it affects specific firmware ranges of various device models. In an embodiment, theserver151 determines that the vulnerability does affect all devices running Apple iPhone® OS that match the vulnerability information's firmware version criteria, the vulnerability may affect devices running any firmware version containing Apple iPhone® OS, and the vulnerability may not affect any devices running Android™, Windows Mobile®, Symbian OS®, or other operating systems. One will appreciate that other methods of determining what vulnerabilities stored bydata storage111 may affect a device may be performed without departing from the scope of this disclosure.
FIGS.2-10 are exemplary flow diagrams depicting various process embodiments. One will appreciate that the following figures and processes are merely exemplary, and that the invention may perform other processes without departing from the scope of this disclosure. One will also appreciate that unless otherwise stated, the performance of the steps in the disclosed processes are not constrained by time. The time between two successive steps may differ from the time between two other successive steps. Additionally, the time to perform each step may differ each time a step is performed. One will also appreciate that the amount of information as described herein is referred to as a “set of information” or a plurality of sets of information. A set of information may include at least one quanta, data point or other quantifiable amount of information, but is not designed to limit or constrain the amount of information discussed herein. In an embodiment, a set of vulnerability information may include multiple pieces of information that relate to a given vulnerability, such as a title, a description, a threat rating, and criteria for the vulnerability to affect a device. In an embodiment, a set of result information may include a security status for a device, and a list of vulnerabilities that the device is vulnerable to, each entry in the list comprising a set of vulnerability information.
FIG.2 depicts and embodiment in which vulnerability information is transmitted tomobile communication device101. Inblock201,data storage111 stores a plurality of sets of vulnerability information related to one or moremobile communication devices101. Inblock202, vulnerability information is transmitted to at least onemobile communication device101 overnetwork121. One will appreciate that the transmission of vulnerability information to the at least onemobile communication device101 may be controlled byserver151 having access todata storage111. One will also appreciate that inblock202, the transmitted vulnerability information may also be termed result information.
FIG.3 depicts an embodiment in which result information is transmitted tomobile communication device101 afterserver151 receives vulnerability identification information frommobile communication device101. One will appreciate that the process illustrated inFIG.3 and described herein may be performed in addition to any of the processes disclosed herein, or may be performed separately from any of the processes disclosed herein. Inblock201,data storage111 stores a plurality of sets of vulnerability information related to one or moremobile communication devices101. Inblock301,server151 receives vulnerability identification information from at least onemobile communication device101. Inblock302,server151 correlates the received set of vulnerability identification information to at least one of the plurality of sets of vulnerability information to generate a set of result information which contains information about vulnerabilities that affect or may affect the at least onemobile communication device101. This may include accessingdata storage111 byserver151. Inblock202, result information is transmitted to at least onemobile communication device101 overnetwork121.
In an embodiment, the scope or type of result information transmitted byserver151 may be general information, or may be specific information about vulnerabilities that may specifically affectmobile communication device101. As such, the result information transmitted todevice101 may include all of the vulnerability information stored indata storage111, or may include a subset of all of the vulnerability information stored indata storage111. The option to transmit general or specific result information may be an option set by an administrator, may depend upon the hardware or software constraints of the mobile communication device, or may depend upon the bandwidth of thenetwork connecting server151 tomobile communication device101.
In an embodiment, determining which vulnerabilities specifically affectmobile communication device101 may involve correlating the vulnerability identification information provided bymobile communication device101 to the vulnerability information available toserver151. As used herein, “correlating” vulnerability identification information to vulnerability information may involve determining whether the vulnerability described by the vulnerability information affects a device, whether it may affect a device, or whether it does not affect a device. Determinations may be made through a variety of methods, including matching vulnerability identification information with vulnerability information and determining whether identification information satisfies one or more criteria for vulnerability. Correlating may be performed byserver151 and/ordata storage111, and may include applying logic, comparing operating systems, comparing version identifiers, checking for the presence of specific software or other data on the mobile communication device, and the like. In an embodiment, correlating may utilize an identification of the hardware or specifications of the mobile communication device. In an embodiment, correlating may also be performed bymobile device101.
FIG.4 is directed to a process in whichdata storage111 is updated with new vulnerability information that may be transmitted as a new or second set of result information to affectedmobile communication devices101. As will discussed in more detail below, this process may include the transmission of one or more notifications. One will appreciate that the process illustrated inFIG.4 and described herein may be performed in addition to any of the processes disclosed herein, or may be performed separately from any of the processes disclosed herein. Inblock201 ofFIG.4,data storage111 stores a plurality of sets of vulnerability information related to one or moremobile communication devices101. Inblock301 ofFIG.4,server151 receives identification information for one of the one or moremobile communication devices101. In an embodiment,server151 stores this identification information indata storage111. This stored information may be used in block402 (discussed below) to determine if a newly received vulnerability affectsdevices101. In an embodiment, the data is used to present a status or administrative interface for the device. One will appreciate that storing vulnerability identification received byserver151 may apply to the other processes as well. For example, anytime server151 receives vulnerability identification information, theserver151 may store the information for use in generating and transmitting user interfaces (e.g. web interfaces) or identifying whether a vulnerability affects adevice101 while thedevice101 is not connected toserver151.
Inblock302 ofFIG.4,server151 performs a correlating step to identify vulnerabilities that affect or may affect themobile communication device101, which may include accessingdata storage111 byserver151. As a result of correlating step inblock302,server151 may generate a set of result information. Inblock202 ofFIG.4, the set of result information is transmitted to the affectedmobile communication device101 overnetwork121. Inblock401,server151 ordata storage111 waits for and receives new vulnerability information. One will appreciate that there may not be a set time interval as to when block401 is performed. After new vulnerability information is received,server151 makes a determination whether the newly received vulnerability information affects any knownmobile communication device101 having access toserver151 or data storage111 (block402). In an embodiment, the determination inblock402 may use the same method for determining if a vulnerability affects adevice101 as in the correlatingblock302; however, instead of identifying which vulnerabilities affect a givendevice101, theserver151 may identify whichdevices101 are affected by the newly received vulnerability. In an embodiment, theserver151 determines which devices are vulnerable to the newly received vulnerability by correlating vulnerability identification information for each device stored indata storage111 to the vulnerability criteria for the newly received vulnerability. If the new vulnerability information does affect any of themobile communication devices101 having access toserver151 ordata storage111, then inblock403,server151 transmits a notification of the new vulnerability or transmits information about the new vulnerability to the affectedmobile communication devices101. If the new vulnerability information does not affect any of themobile communication devices101 having access toserver151 ordata storage111, thenserver151 ordata storage111 will wait until new relevant vulnerability information is received (block401).
Server151 may transmit a notification tomobile communication device101 via a variety of mechanisms. A notification may be sent via email, text messaging, or through a client-server communication system as described in U.S. patent application Ser. No. 12/372,719, entitled, “SYSTEM AND METHOD FOR REMOTELY SECURING OR RECOVERING A MOBILE DEVICE,” and incorporated in full herein. A notification may provide information about a vulnerability, information about a potential vulnerability, the status of a mobile communication device, information about remediation instructions, or may request that the user of an affected mobile communication device perform some action to update the vulnerability information on the mobile communication device, or perform some action to remediate the mobile communication device.
In an embodiment, a notification may contain information or an instruction indicating that themobile communication device101 needs to connect toserver151 in order to receive new vulnerability information. The notification may be directed to software resident on themobile communication device101, may include software readable remediation instructions, and may be in the form of an SMS or may be sent via a push notification service, such as that provided by Apple Computer Inc. to its iPhone® devices. For example,mobile communication device101 may receive a notification with instructions that the device should be updated to protect against a new security risk. A specific application on the device may require an update, in which case the notification may also causemobile communication device101 to update the specific application without user intervention. In an embodiment, a notification may be directed to the user of the mobile communication device. This may include a text message, push notification, or e-mail message containing human-readable information, or a voicemail or other verbal communication directed to the user ofmobile communication device101. Notifying amobile communication device101 allows for rapid response to new vulnerabilities, thereby greatly increasing the effectiveness of systems that would otherwise rely on a scheduled or manually-initiated check for security vulnerabilities.
FIG.5 illustrates an embodiment in whichserver151 may require additional information about amobile communication device101 in order to confirm whether a vulnerability affectsmobile communication device101. One will appreciate that the process illustrated inFIG.5 and described herein may build upon any of the processes discussed herein, or may be performed independently of any of the other processes discussed herein. Inblock201 ofFIG.5,data storage111 stores a plurality of sets of vulnerability information related to one or moremobile communication devices101. One will appreciate thatdata storage111 may be accessed byserver151. Inblock301 ofFIG.5,server151 receives identification information for amobile communication device101. Inblock302 ofFIG.5,server151 correlates the received identification information to the stored plurality of sets of vulnerability information to determine which vulnerabilities affect or may affect themobile communication device101, which may include accessingdata storage111 byserver151.Server151 generates a set of result information that inblock202 ofFIG.5 is transmitted to themobile communication device101 overnetwork121.
Inblock401 ofFIG.5,server151 ordata storage111 waits for and receives new vulnerability information. Inblock501,server151 assess whether there is enough information to determine which mobile communication devices may be affected by the newly received vulnerability information. If there is not enough information, then inblock502,server151 will request additional vulnerability identification information from one or moremobile communication devices101, and will then receive the additional information from the one or moremobile communication devices101 inblock503. One will appreciate that the request inblock502 may utilize notification mechanisms such as those described above or may be performed the next time themobile communication device101 connects to theserver151. Once the additional information is received,server151 may make a determination whether the newly received vulnerability information affects any of the one or moremobile communication devices101 having access toserver151 or data storage111 (block402). If the new vulnerability information does affect any of the one or moremobile communication devices101 having access toserver151 ordata storage111, then inblock403 ofFIG.5, theserver151 will transmit a notification of the new vulnerability to the affectedmobile communication devices101, or may transmit an updated, new or second set of result information regarding the new vulnerability. If the new vulnerability information does not affect any of themobile communication devices101 having access toserver151 ordata storage111, thenserver151 ordata storage111 may wait until new relevant vulnerability information is received (block401 ofFIG.5).
One will appreciate that the process illustrated inFIG.5 includes a situation in whichserver151 receives operating system information from amobile communication device101. In an embodiment, this information is stored byserver151 indata storage111 or other accessible storage. Later, after receiving new vulnerability information,server151 may determine that based on the stored operating system information formobile communication device101, the vulnerability could affectmobile communication device101. However,server151 may require additional identification information frommobile communication device101 in order to determine whether the device is actually affected.Server151 may request additional configuration information frommobile communication device101.Server151 will receive the requested identification information and then sends accurate vulnerability information to thedevice101.
FIG.6 is directed to a process in which amobile communication device101 having access toserver151 ordata storage111 requests vulnerability information fromserver151. Inblock601,mobile communication device101 transmits a request toserver151 for vulnerability information overnetwork121. Inblock602,mobile communication device101 receives vulnerability information fromserver151. One will appreciate thatserver151 may accessdata storage111 in order to gather and transmit the vulnerability information. Inblock603,mobile communication device101 correlates the received vulnerability information to its own identification information, and makes a determination whether any of the received vulnerability information is relevant to themobile communication device101. In this embodiment, vulnerability information processing may thereby be performed by themobile communication device101. In an embodiment, bothmobile communication device101 andserver151 perform processing on vulnerability information. For example, theserver151 may send vulnerability information tomobile communication device101 based on the operating system ofmobile communication device101. In an embodiment,server151 may use information sent by device101 (e.g. HTTP header information) in therequest601 or information stored indata storage111 to determine the operating system of thedevice101. The mobile communication device may then use additional information such as the applications installed on the device, configuration information, and the versions of software libraries to perform additional processing, correlating or analysis on the received vulnerability information. One will appreciate that a vulnerability may be rated as severe if the device's configuration makes the vulnerability exploitable by remote parties; however, the vulnerability may be rated as less severe if the device's configuration leaves the vulnerability as not remotely exploitable.
FIG.7 is any exemplary flowchart of a process in which amobile communication device101 transmits vulnerability identification information to server151 (block701), and in response, received result information on (block702). One will appreciate that this may require access todata storage111 byserver151. One will also appreciate that the process illustrated inFIG.7 and described herein may be performed as part of any of the other processes described or illustrated herein, or may be performed independently of the other processes described or illustrated herein.
FIG.8 is directed to a process in which amobile communication device101 transmits additional vulnerability identification information toserver151 in order to receive additional result information relevant to themobile communication device101. One will appreciate that the process illustrated inFIG.8 and disclosed herein may augment any of the other disclosed or illustrated processes. Inblock701 ofFIG.8,mobile communication device101 transmits vulnerability identification information toserver151. Inblock801,mobile communication device101 receives a request for additional identification information fromserver151. Inblock802,mobile communication device101 transmits additional vulnerability identification information toserver151. In response,mobile communication device101 receives correlated result information fromserver151 inblock702 ofFIG.8. One will appreciate thatserver151 may accessdata storage111 in order to provide the relevant result information for transmission tomobile communication device101.
One will appreciate that the process illustrated inFIG.8 contemplates a situation in which amobile communication device101 first transmits its operating system information to aserver151.Mobile communication device101 may then receive a request fromserver151 for version information pertaining to software libraries installed on thedevice101.Mobile communication device101 may then send the requested information toserver151 and may receive result information correlated to the device's vulnerability given its specific software library version information. If the software library versions installed onmobile communication device101 are not affected by a specific vulnerability, the result information received bymobile communication device101 may indicate that thedevice101 is not vulnerable to that vulnerability. If, however, the software library versions are affected by a specific vulnerability, then the result information received bymobile communication device101 may indicate thatmobile communication device101 is vulnerable and may contain instructions for how to remediate the issue.
FIG.9 illustrates a process in which vulnerabilities on amobile communication device101 are remediated. One will appreciate that the process illustrated inFIG.9 and described herein may be combined with any of the processes discussed herein, or may be performed independently of any of the other processes discussed herein. Inblock201 ofFIG.9,data storage111 stores a plurality of sets of vulnerability information related to one or moremobile communication devices101. Inblock301 ofFIG.9,server151 receives vulnerability identification information for amobile communication device101. Inblock302 ofFIG.9,server151 correlates the received vulnerability identification information to vulnerability information in order to generate a set of result information about vulnerabilities affecting themobile communication device101. This step may include accessingdata storage111 byserver151. Inblock202 ofFIG.9, result information is transmitted to themobile communication device101 overnetwork121. In an embodiment, the result information may include instructions for the user to remediate vulnerabilities that affect thedevice101.
Inblock901 ofFIG.9, a determination is made as to whethermobile communication device101 is vulnerable. This determination may be made using logic resident onmobile communication device101, orserver151 may perform the analysis. In an embodiment, a device is only vulnerable if it is affected by vulnerabilities that have a certain level of severity. For example, if a device is only susceptible to locally-exploitable vulnerabilities, it may not be considered vulnerable inblock901; however, if the device is vulnerable to remotely-exploitable vulnerabilities or has a virus installed, it may be considered vulnerable inblock901. Ifmobile communication device101 is vulnerable, then inblock902,server151 may be set to wait for confirmation that themobile communication device101 has been remediated.Server151 may be conditioned to wait for confirmation for a certain period of time (block903).
If the time limit for receiving a remediation confirmation has been exceeded, then inblock904, an action may be taken. For example,server151 may notify an administrator about the vulnerable mobile communication device and that the user has not taken action in the specified period of time. In this example, an administrator may take manual action such as sending a personal email or otherwise notifying the user to secure thedevice101. In an embodiment,server151 may automatically disablemobile communication device101 in some fashion to prevent affecting other devices on thenetwork121 or to prevent further damage. For example,server151 may preventmobile communication device101 from connecting to a specific network, email system, document repository, or other system. Alternatively,server151 may disablemobile communication device101 such that an administrator must verify that the device is safe before it is can be used again. Some mechanisms by which the disablement can take place are disclosed in U.S. patent application Ser. No. 12/372,719, entitled, “SYSTEM AND METHOD FOR REMOTELY SECURING OR RECOVERING A MOBILE DEVICE,” and U.S. patent application Ser. No. 12/255,632, entitled, “SECURE MOBILE PLATFORM SYSTEM,” both of which are incorporated in full herein. In an embodiment, the user ofmobile communication device101 may be notified byserver151 via email, text message or other means of communication that the mobile communication device is vulnerable and that corrective action was not taken within the prescribed time. The notification may serve as a reminder to help the user take action and secure the device. In this fashion, the invention goes beyond simply updating a mobile communication device to ensure security, or periodically scanning mobile communication devices on the network for potential vulnerabilities. As described herein, the invention may provide a customized vulnerability assessment based upon the unique state and configuration of each mobile communication device on the network, and may provide notifications and remediation instructions based upon this unique state and configuration.
One will appreciate that other actions may be performed in order to optimally secure a mobile device once it is known to be vulnerable. The embodiments described herein may be combined as part of a security response process. In an example, a user may receive a direct reminder after one day if his or her device is determined to be vulnerable and is not yet remediated. After two additional days, if the device is still vulnerable, an administrator may be notified and the device disallowed access to email and the organization's VPN service. Once the device is remediated, the administrator may be notified and access to email and VPN may be automatically restored. Other examples are also possible without departing from this disclosure or the scope of the invention.
If inblock903 ofFIG.9,server151 received confirmation that a vulnerability affectingmobile communication device101 has been remediated, or if inblock901,mobile communication device101 is not vulnerable, then inblock401 ofFIG.9,server151 may wait for receipt of new vulnerability information. Inblock501 ofFIG.9,server151 may assess whether there is enough information to determine ifmobile communication device101 is affected by the newly received vulnerability information. If there is not enough information, then inblock502 ofFIG.9,server151 will request additional vulnerability identification information frommobile communication device101, and will then receive the additional vulnerability identification information frommobile communication device101 inblock503 ofFIG.9. Once the additional vulnerability identification information is received,server151 may make a determination whether the newly received vulnerability information affects mobile communication device101 (block402 ofFIG.9), thereby generating a new, updated or second set of result information. If the new vulnerability information does affectmobile communication device101, then inblock403 ofFIG.9,server151 may send a notification of the new vulnerability information to the affectedmobile communication device101, or may send information relating to the new vulnerability tomobile communication device101. If the new vulnerability information does not affectmobile communication device101, thenserver151 ordata storage111 will wait until new relevant vulnerability information is received (block401 ofFIG.9). One will appreciate that the portions of the process for remediating vulnerabilities present on themobile communication device101 may be performed in conjunction with any of the other processes disclosed herein.
FIG.10 is directed to a process for generating data for display, e.g. on a web interface. In an embodiment, a user of themobile communication device101, administrator for a group ofmobile communication devices101, administrator forserver151, or other party may wish to check the security status ofmobile communication devices101 connected to thenetwork121. This may be helpful for identifying which mobile communication devices are vulnerable, identifying which need manual remediation or intervention from an administrator, determining the risk posed by a new vulnerability, and performing other actions relevant to securing a group of mobile communication devices. It may also be helpful to provide a single graphical user interface that displays information on mobile communication devices having access toserver151.
Inblock201 ofFIG.10,data storage111 stores a plurality of sets of vulnerability information that may be accessed byserver151. Inblock301 ofFIG.10,server151 receives vulnerability identification information for one or moremobile communication devices101 connected tonetwork121. Inblock1001,server151 receives a request for the status of vulnerabilities for the one or moremobile communication devices101. This request may originate from one of the one or moremobile communication devices101, or from a web interface. Inblock302 ofFIG.10,server151 correlates the received set of vulnerability identification information to at least one of the plurality of sets of vulnerability information to identify vulnerabilities that affect or may affect any of the one or moremobile communication devices101 connected toserver151 onnetwork121. Inblock1002,server151 transmits the status of vulnerabilities for any of the one or moremobile communication devices101 for display on a web page or other interface. One will appreciate that the status may include whether any of the vulnerabilities have been remediated, and if not, whichmobile communication device101 still suffers from vulnerabilities that have not been remediated. The actions inblock302 may be performed beforeserver151 receives a request for vulnerability status. The result of the correlation may be stored by theserver151 so that when the server receives a request for vulnerability status, theserver151 recalls the previous results. The storage may be in a database, in-memory cache, or other method of storing and recalling data available toserver151.
In an embodiment, the data transmitted byserver151 inblock1002 ofFIG.10 may pertain to an individual mobile communication device, multiple devices, or a group of devices. The data may include information about specific individual devices or aggregated information relating to multiple devices. The information about an individual device may include the device's security status (e.g. vulnerable/not vulnerable, severity of vulnerability, number of unremediated vulnerabilities), software version information, phone number, count of security events in a time period, or last time communicating withserver151. Aggregated information relating to a group of devices may include the percentage of devices in the group that are vulnerable, the number of devices in the group that are vulnerable, the overall risk level of the group, or other information that can be combined between specific devices in the group.Server151 may automatically group devices using criteria such as common characteristics (e.g. operating system type, operating system version, having the presence of certain software, having a certain configuration, etc.), or common security statuses (e.g. being vulnerable, being not vulnerable, being affected by a specific vulnerability, being out of compliance, awaiting remediation, etc.).
In an embodiment, the data transmitted byserver151 inblock1002 ofFIG.10 may be selected by receiving searching or sorting information in therequest1001. The search or sort may reference any information stored by the server relating to specific devices. For example, a user may search for all devices with a specific piece of software installed or may sort devices based on highest severity. In an embodiment, the data transmitted byserver151 inblock1002 includes a prioritized list of current security issues. This list may also include recommended actions to remediate the issues and the ability to initiate such actions. For example, in a large mobile device deployment, the list of current issues may include iPhone® vulnerability that is severe and affects 1000 devices, an Android™ vulnerability that is of moderate severity and affects 1200 devices, a Windows Mobile vulnerability that is severe and affects 100 devices, and a Blackberry vulnerability that is of low severity and affects 3000 devices. The prioritization in this case takes into account both the severity of the vulnerability and the number of devices that are part of the deployment and affected by the vulnerability.
In an embodiment,server151 may transmit reports based on security status information available at the server. The reports may show changes in security status over time or show a current summary. Some example reports include the number of vulnerable of devices with respect to time, the current number of vulnerable devices with each severity level, the current number of vulnerable devices broken down by operating system type, and a list of contact information for users with the most severely vulnerable devices.
In an embodiment,server151 may transmit security related events that are generated both by clients and byserver151 due to automatic or administrative action. The events may be displayed, gathered, processed, or otherwise interacted with as disclosed in U.S. patent application Ser. No. 12/255,635, entitled, “SECURITY STATUS AND INFORMATION DISPLAY SYSTEM,” which is incorporated in full herein.
In an embodiment,server151 allows an administrator to perform actions related to a device or group of devices. Actions that may be performed include notifying the user of the device via a push notification, text message, email, or another messaging system; disabling the device; disabling the device's access to a service, potentially using a mechanism disclosed in U.S. patent application Ser. No. 12/255,632, entitled, “SECURE MOBILE PLATFORM SYSTEM”; or those disclosed in U.S. patent application Ser. No. 12/372,719, entitled, “SYSTEM AND METHOD FOR REMOTELY SECURING OR RECOVERING A MOBILE DEVICE,” both of which are incorporated in full herein.
In an embodiment,server151 allows an administrator to configure how the server operates. One such configuration may include custom triggers or alerts on certain events (e.g. devices not remediating in a period of time) that will result in logging and administrator notification via email, text message, or other messaging medium. Other examples of configuration options include: the time period the server waits before notifying an administrator of an un-remediated vulnerable device, the email address or addresses administrators should be notified at, how often to remind users of vulnerable devices that they need to take remediation actions, what method ofcontact server151 should use to remind users (e.g. SMS, E-mail, push notification service), how the server interacts with e-mail or VPN services to disable access for a specific vulnerable device, and other ways of controlling the functionality disclosed herein.
In an embodiment, vulnerability identification information is stored byserver151 so that, in the case of a new vulnerability,server151 can determine whether the device is vulnerable, not vulnerable, or potentially vulnerable based on the information is has. In an embodiment, the server stores vulnerability identification information ondata storage111. This allows an IT admin to get an instant picture of the security risk of their device deployment in the case of a new emerging vulnerability. Such rapid understanding is critical to prioritize response effort in the case of a rapidly spreading worm or severe vulnerability.
FIG.11 is an exemplary screenshot of result information being displayed on amobile communication device101. As shown, two vulnerabilities have been identified as affecting the mobile communication device. One will appreciate that these vulnerabilities may have been identified byserver151 after receipt of vulnerability identification information frommobile communication device101, as described above and illustrated in the Figures. As previously discussed, the identified vulnerabilities may specifically affectmobile communication device101 because of its particular operating system version, firmware version, or software, or may be a general vulnerability that affects all similar makes and models ofmobile communication device101. As shown, multiple vulnerabilities are shown to not affect themobile communication device101. In an embodiment, these vulnerabilities are vulnerabilities that may affect similar makes and models of mobile device but do not affect thespecific device101. In an embodiment, resultinformation display1101 may link to another screen or to a website with more information on a vulnerability, including instructions on how to remediate the vulnerability. In an embodiment, theresult information display1101 may occur due to the result of thedevice101 receiving result information sent by the server in response to a request from thedevice101. In an embodiment, theresult information display1101 may occur due to the device receiving a notification that thedevice101 is vulnerable. One will appreciate that other situations may prompt the display of result information ondevice101 without departing from this disclosure. One will appreciate that other screen layouts are possible, and that the screen depicted inFIG.11 is not meant to limit the invention in any fashion.
In the description above and throughout, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be evident, however, to one of ordinary skill in the art, that the invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate explanation. The description of the preferred embodiments is not intended to limit the scope of the claims appended hereto. Further, in the methods disclosed herein, various steps are disclosed illustrating some of the functions of the invention. One will appreciate that these steps are merely exemplary and are not meant to be limiting in any way. Other steps and functions may be contemplated without departing from this disclosure or the scope of the invention.