This Background is intended to provide the basic context of this patent application and it is not intended to describe a specific problem to be solved.
Detecting relevant data and pinpointing the source of data transmission across electronic trust boundaries may be difficult given traffic and operations generated by basic systems such as the operating system and network protocol data transmissions. Trying to pinpoint the application of code section that caused the breach of the trust boundary also has been a challenge.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
A method of reviewing electronic communication of a computing device to determine if unwanted data transfers occurred such as a transfer of information of interest, such as personally identifiable information, of a user that passes a defined trust boundary is disclosed. The method captures communication from a computing device, stores the communication in a memory, captures stack traces related to the communication and selects review communications. The review communications may be the communication that satisfies a trust boundary condition. The symbols for the stack traces in computer executable code related to the review communications may be resolved and the review communications and the symbols may be stored in a memory. The review communications may be searched for information of interest. Searching for information may entail selecting the review communications that satisfy at least one information heuristic condition. The heuristic may be based on the data payload or may be based on the source and destination of the data packet. If the information is found or if the transfer was made without consent, an alert may be communicated that the information has been communicated beyond the defined trust barrier.
Although the following text sets forth a detailed description of numerous different embodiments, it should be understood that the legal scope of the description is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment since describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.
It should also be understood that, unless a term is expressly defined in this patent using the sentence “As used herein, the term ‘______’ is hereby defined to mean . . . ” or a similar sentence, there is no intent to limit the meaning of that term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be interpreted to be limited in scope based on any statement made in any section of this patent (other than the language of the claims). To the extent that any term recited in the claims at the end of this patent is referred to in this patent in a manner consistent with a single meaning, that is done for sake of clarity only so as to not confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by reciting the word “means” and a function without the recital of any structure, it is not intended that the scope of any claim element be interpreted based on the application of 35 U.S.C. §112, sixth paragraph.
With reference to
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180, via a local area network (LAN) 171 and/or a wide area network (WAN) 173 via a modem 172 or other network interface 170.
Computer 110 typically includes a variety of computer readable media that may be any available media that may be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. The ROM may include a basic input/output system 133 (BIOS). RAM 132 typically contains data and/or program modules that include operating system 134, application programs 135, other program modules 136, and program data 137. The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media such as a hard disk drive 141 a magnetic disk drive 151 that reads from or writes to a magnetic disk 152, and an optical disk drive 155 that reads from or writes to an optical disk 156. The hard disk drive 141, 151, and 155 may interface with system bus 121 via interfaces 140, 150.
A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not illustrated) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device may also be connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 190.
Detecting relevant data and pinpointing the source of data transmission across electronic trust boundaries may be difficult given traffic and operations generated by basic systems such as the operating system and network protocol data transmissions. Trying to pinpoint the application of code section that caused the breach of the trust boundary also has been a challenge.
At block 200, communication may be captured from a computing device 110. Referring to
Referring again to
At block 210, stack traces related to the communication may be captured. The stack traces may be kernel stack traces or user mode stack traces. In either case, a picture of the stack may be stored such that it may be later reviewed (or resolved) to determine in the computer executable code the cause of the breach of the trust boundary.
At block 215, review communications may be selected. Review communications may be the communication 320 that satisfies a trust boundary condition. The review may be part of the capture service 340 or may be a separate analysis of the log 350 as will be described in relation to
The trust boundary condition may be any communication 320 that passes over a boundary set by a user. Examples of a trust boundary include, but are not limited to, communicating to a memory, communicating to a local network, communicating to an outside network and communicating to a peripheral device. The source of the trust boundary may be a separate application, may be set by a user, may be set according to a remote authority or may be a combination of all the sources. Communicating to a memory may sound harmless, but if the computing device 110 is a device 110 used by many users, even this data may pass a trust boundary.
At block 220, symbols for the stack traces may be resolved or mapped to computer executable code related to the review communications. In this way, the cause of the violation of the trust boundary may be mapped to a specific code section. Once the code section is known, it may be corrected, reviewed, adjusted, modified, etc.
At block 225, the review communications and the symbols may be stored in a memory such as the log 350. The log 350 may be stored locally or may be stored remotely, such as at an IT location. The log may be stored in a logical manner that may be easily and quickly searched, such as in a database.
At block 230, the review communications may be searched for information of interest such as personally identifiable information. This information may be determined by selecting the review communications that satisfy at least one information condition heuristic or simply the fact that data was transferred. An information condition a particular user does not desire to be available to others may be set as a condition. For example, information conditions that may be set include data that is communicated outside the computing device, any data that is communicated to a specific website, any data that contains a user name, any data the matches a pattern for other personal data, any unauthorized communication, phoning home type behavior, etc. The communication may or may not contain personal information. The communication may be noticed by reviewing the sending and receiving addresses of the packets being communicated or by simply reviewing the payload of the packets.
In some embodiments, the information condition is preset. In other embodiments, the information condition is set by a user. In yet other embodiments, information conditions are retrieved or pushed from a remote source. Of course, what is an information condition is personal and may vary by application, user, situation, embodiment, etc. The method may be intelligent and may learn from user inputs what the user considers personal. For example, if a home address is marked as personal, a home phone number is likely personal.
The determination of what is an information of interest condition are based on heuristics.
Again, the engine may need to be tuned to the situation. For example, some salesmen go to great lengths to get their phone number and email address into users' hands. On the other hand, teachers may go to great lengths to keep home phone numbers and email addresses out of the reach of students. The situation will likely drive what would satisfy the information of interest condition, and the condition may be created and stored for each individual user.
At block 235, if the information of interest, is detected, an alert 540 may be communicated that information of interest (or information that satisfies the information of interest condition) has been located. The alert 540 may be in virtually an form that triggers a sensory response in a user.
In some embodiments, the alert 540 may include the information of interest that passed the trust barrier. In other embodiments such as when the code is being tested by a developer or is part of a development application, the alert 540 may include the origin in of the network traffic in the computer executable code.
If the alert 540 is part of a development application, and if an alert 540 is generated, the application execution may be stopped and the alert 540 may be presented to the developer. The alert 540 may include the code section at fault which may be determined from the stack traces and symbols therein.
The alert 540 also may rank the risk of the information being passed and how it is being passed. Some breaches of the trust boundary may be classified as high, medium or low. The classification may be set by the application, by a user or by a remote application. Based on the alert, the developer may attempt to adjust the computer executable code to avoid or mitigate the violation of the trust boundary.
As a result of the method, increased flexibility in describing data that may be personally identifiable may be achieved. In addition, additional flexibility may be obtained through defining the personal trust boundary. By allowing the definition of what is personally identifiable information and what is a persona trust boundary to change and be varied, virtually any situation may be handled.
In conclusion, the detailed description is to be construed as exemplary only and does not describe every possible embodiment since describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.