CN101730892A - Network reputation scoring - Google Patents

Abstract

Methods and systems for operation on one or more data processors for assigning reputations to network-based entities based on previously collected data.

Description

Internet Reputation Score

technical field

This document relates generally to systems and methods for processing communications, and more particularly to systems and methods for categorizing communication-related entities.

background

In the anti-spam industry, spammers use various creative devices to evade detection by spam filters. In this way, the entity from which the communication originates can provide another indication of whether a given communication should be allowed into the enterprise network environment.

However, current tools for analysis by message senders include Internet Protocol (IP) blacklists (sometimes called Real-time Blacklists (RBL)) and IP whitelists (Real-time Whitelists (RWL)). Whitelists and blacklists certainly add benefits to the spam classification process; however, whitelists and blacklists are inherently limited to providing a binary type (YES/NO) in response to each query. Also, blacklists and whitelists treat entities independently and ignore evidence provided by various attributes associated with entities.

overview

Systems and methods for network reputation scoring are provided. A system for assigning reputations to network-based entities may include a communication interface, a communication analyzer, a reputation engine, and a decision engine. The communication interface can receive network communications, and the communication analyzer can analyze the network communications to determine entities associated with the network communications. The reputation engine can provide a reputation associated with the entity based on previously collected data associated with the entity, and the decision engine can determine whether the network communication is delivered to the recipient based on the reputation.

A method for assigning a reputation to a network-based entity may include: receiving a hypertext transfer protocol communication at an edge protection device; identifying an entity associated with the received hypertext transfer protocol communication; querying a reputation engine for information associated with the entity receiving the reputation indicator from the reputation engine; and taking an action with respect to the hypertext transfer protocol communication based on the received reputation indicator associated with the entity.

An example of a computer readable medium operative on a processor to perform aggregating local reputation data to generate a global reputation vector may perform the following steps: receiving a reputation query from a requesting local reputation engine; retrieving a plurality of local reputations, the local reputations being associated with a plurality of local reputation engines; aggregating the plurality of local reputations; deriving a global reputation from the aggregation of the local reputations; and responding to reputation queries with the global reputation.

Other exemplary systems may include a communication interface and a reputation engine. The communication interface can receive global reputation information from the central server, the global reputation being associated with the entity. The reputation engine can bias the global reputation received from the central server according to defined local preferences.

Another exemplary system may include a communication interface, a reputation module, and a traffic control module. The communication interface can receive distributed reputation information from the distributed reputation engine. The reputation module can aggregate the distributed reputation information and obtain the global reputation according to the aggregation of the distributed reputation information, and the reputation module can also obtain the local reputation information according to the communication received by the reputation module. The traffic control module can determine handling associated with the communication based on the global reputation and the local reputation.

Systems and methods for aggregating reputation information are provided. A system for aggregating reputation information may include a centralized reputation engine and an aggregation engine. A centralized reputation engine can receive feedback from multiple local reputation engines. The aggregation engine can obtain the global reputation of the queried entity based on the aggregation of multiple local reputations. The centralized reputation engine may further provide the global reputation of the queried entity to the local reputation engine in response to receiving the reputation query from the local reputation engine.

The method of aggregating reputation information may include: receiving a reputation query from a requesting local reputation engine; retrieving a plurality of partial reputations, the partial reputations being respectively associated with the plurality of local reputation engines; aggregating the plurality of partial reputations; obtaining the global reputation; and responding to the reputation query with the global reputation.

An example of a computer readable medium operative on a processor to aggregate local reputation data to produce a global reputation vector may perform the following steps: receive a reputation query from a requesting local reputation engine; retrieve a plurality of local reputations, the local reputations being associated with Multiple local reputation engines are associated; multiple local reputations are aggregated; global reputation is derived from the aggregation of local reputations; and reputation queries are responded to with the global reputation.

Other exemplary reputation aggregation systems may include a communication interface and a reputation engine. The communication interface can receive global reputation information from the central server, the global reputation being associated with the entity. The reputation engine may bias the global reputation received from the central server according to defined local preferences.

Further exemplary systems may include a communication interface, a reputation module, and a traffic control module. The communication interface can receive distributed reputation information from the distributed reputation engine. The reputation module can aggregate the distributed reputation information and obtain the global reputation according to the aggregation of the distributed reputation information, and the reputation module can also obtain the local reputation information according to the communication received by the reputation module. The traffic control module can determine handling associated with the communication based on the global reputation and the local reputation.

Systems and methods for a reputation-based network security system are provided. A reputation-based network security system may include a communication interface, a communication analyzer, a reputation engine, and a security engine. The communication interface can receive incoming and outgoing communications associated with the network. A communication analyzer may obtain external entities associated with a communication. The reputation engine can obtain reputation vectors associated with external entities. The security engine may receive the reputation vector and send the communication to the interrogation engine, wherein the security engine determines which of the interrogation engines interrogates the communication based on the reputation vector.

Other reputation-based network security systems may include communication interfaces, communication analyzers, reputation engines, and security engines. The communication interface can receive incoming and outgoing communications associated with the network. A communication analyzer may obtain external entities associated with a communication. A reputation engine may obtain reputations associated with external entities. The security engine assigns priority information to the communication, wherein the security engine may assign a high priority to the communication if the external entity is a reputable entity and may assign a low priority to the communication if the external entity is a poorly reputable entity rights whereby the priority information is used by one or more query engines to improve the quality of service to reputable entities.

A method of effectively processing communications based on a reputation of a security threat may include: receiving a communication associated with an external entity based on origination or destination information associated with the communication; identifying an external entity associated with the received communication; The reputation associated with the external entity is derived from criteria of good and bad reputation associated with the external entity; assigns priority to communications based on the derived reputation associated with the external entity; enforces communications based on the priority assigned to the communication One or more tests.

A method of efficiently processing communications based on reputation may include: receiving a communication associated with an external entity based on origination or destination information associated with the communication; identifying an external entity associated with the received hypertext transfer protocol communication; Reputation associated with the external entity based on criteria of good and bad reputation associated with the external entity; assigning the communication to one or more query engines selected from a plurality of query engines, the one or more The selection of the query engine is based on the derived reputation associated with the external entity and the capabilities of the query engine; and executing the one or more query engines on the communication.

Systems and methods for reputation-based connection suppression are provided. A system for reputation-based connection suppression can include a communication interface, a reputation engine, and a connection control engine. The communication interface may receive a connection request associated with an external entity prior to establishing a connection to the external entity. A reputation engine may derive reputations associated with external entities. The connection control engine may deny connection requests to the protected network based on the derived reputation of the external entity.

A method of suppressing a connection request based on a reputation may include: receiving a connection request, the connection request being related to an external entity; querying a reputation engine for a reputation associated with the external entity; policies; allowing the connection request based on determining that the reputation of the external entity associated with the connection request complies with the policy; and suppressing the connection request based on determining that the reputation of the external entity associated with the voice over internet protocol connection request does not comply with the policy.

Description of drawings

FIG. 1 is a block diagram depicting an exemplary network in which the systems and methods of the present disclosure may operate.

FIG. 2 is a block diagram depicting an exemplary network architecture of the present disclosure.

Figure 3 is a block diagram depicting an example of communications and entities, including identifiers and attributes for detecting relationships between entities.

4 is a flowchart describing an operational scheme for detecting relationships and assigning risks to entities.

5 is a block diagram illustrating an exemplary network architecture including a local reputation stored by a local security agent and a global reputation stored by one or more servers.

FIG. 6 is a block diagram illustrating determination of global reputation based on local reputation feedback.

FIG. 7 is a flowchart illustrating an exemplary resolution between global reputation and local reputation.

8 is an example graphical user interface for adjusting settings of filters associated with a reputation server.

9 is a block diagram illustrating reputation-based connection throttling for Voice over Internet Protocol (VoIP) or Short Message Service (SMS) communications.

FIG. 10 is a block diagram illustrating a reputation-based load balancer.

FIG. 11A is a flowchart illustrating an exemplary operational scheme for geographic location-based authentication.

FIG. 11B is a flowchart illustrating another exemplary operational scheme for geographic location-based authentication.

11C is a flow diagram illustrating another exemplary operational scheme for geographic location-based authentication.

12 is a flowchart illustrating an exemplary operational scheme for reputation-based dynamic isolation.

13 is an exemplary graphical user interface display of an image spam communication.

14 is a flowchart illustrating an exemplary operational scheme for detecting image spam.

15A is a flowchart illustrating an operational scheme for analyzing the structure of a communication.

15B is a flowchart illustrating an operational scheme for analyzing features of an image.

Figure 15C is a flowchart illustrating an operational scheme for normalizing images for spam handling.

15D is a flowchart illustrating an operational scheme for analyzing fingerprints of images to find common segments in multiple images.

Detailed description

FIG. 1 is a block diagram depicting an exemplary network environment in which the systems and methods of the present disclosure may operate. A security agent (security agent) 100 may generally exist between a firewall system (not shown) and a server (not shown) inside a network 110 (eg, an enterprise network). As should be appreciated, network 110 may include many servers including, for example, email servers, web servers, and various application servers that may be used by businesses associated with network 110 .

Security agent 100 monitors communications entering and leaving network 110 . These communications are typically received over the Internet 120 from a number of entities 130a-f connected to the Internet 120 . One or more of the entities 130a-f may be the legal originator of the communication traffic. However, one or more of entities 130a-f may also be a poorly reputable entity that initiates unwanted communications. Accordingly, security agent 100 includes a reputation engine. A reputation engine can examine communications and determine a reputation associated with the entity initiating the communications. The security proxy 100 then performs actions on the communication according to the reputation of the originating entity. If the reputation indicates that the originator of the communication is reputable, for example, the security agent may forward the communication to the recipient of the communication. However, if the reputation indicates that the originator of the communication has a bad reputation, among others, the security proxy may isolate the communication, perform more tests on the message, or require authentication from the originator of the message. The reputation engine is described in detail in US Patent Publication No. 2006/0015942, which application is hereby incorporated by reference.

FIG. 2 is a block diagram depicting an exemplary network architecture of the present disclosure. Security proxies 100a-n are shown logically residing between networks 110a-n and the Internet 120, respectively. Although not shown in FIG. 2, it should be understood that a firewall may be installed between the security agents 100a-n and the Internet 120 to provide protection against unauthorized communications from entering the respective networks 110a-n. Also, an intrusion detection system (IDS) (not shown) may be configured in conjunction with the firewall system to identify suspicious patterns of activity and signal an alarm when such activity is identified.

While such systems provide some protection to the network, they generally do not address application layer security threats. For example, hackers often attempt to use various network-type applications (e.g., email, web, instant messaging (IM), etc.) to create pretext connections with networks 110a-n in order to exploit Security holes created by these various applications. However, not all entities 130a-e imply threats to networks 100a-n. Some entities 130a-e initiate legitimate traffic, allowing employees of the company to communicate more efficiently with business partners. While it is useful to inspect communications for possible threats, maintaining current threat information can be difficult as attacks are constantly being refined to address recent filtering techniques. Accordingly, security agents 100a-n may run multiple tests on the communication to determine whether the communication is legitimate.

Additionally, sender information included in communications may be used to help determine whether a communication is legitimate. Thus, sophisticated security agents 100a-n may track entities and analyze characteristics of entities to help determine whether to allow communications into networks 110a-n. Reputations may then be assigned to entities 110a-n. The decision to communicate may take into account the reputation of the entity 130a-e initiating the communication. Also, one or more central systems 200 may collect information about entities 130a-e and distribute the collected data to other central systems 200 and/or security agents 100a-n.

Reputation engines can help identify large volumes of malicious communications without extensive and potentially expensive local analysis of the content of the communications. A reputation engine can also help identify and prioritize legitimate communications for transmission, reducing the risk of misclassifying legitimate communications. Moreover, a reputation engine can provide a dynamic and predictive approach to the problem of identifying malicious as well as legitimate transactions in the physical or virtual world. Examples include the process of filtering malicious communications in email, instant messaging, VoIP, SMS, or other communication protocol systems that utilize analysis of sender reputation and content. The security agents 100a-n may then apply global or local policies to determine what action to take on the communication for reputation results (e.g. reject, quarantine, load balance, transmit with assigned priority, analyze locally with additional scrutiny) .

However, entities 130a-e may connect to the Internet in various ways. As should be appreciated, entities 130a-e may have multiple identifiers (eg, email addresses, IP addresses, identifier files, etc.) at the same time or over time. For example, a mail server with changing IP addresses may have multiple identities over time. Also, one identifier may be associated with multiple entities, for example, when an IP address is shared by an organization supported by many users. Also, the particular method used to connect to the Internet may obscure the identity of entities 130a-e. For example, entity 130b may utilize Internet Service Provider (ISP) 200 to connect to the Internet. Many ISPs 200 use Dynamic Host Configuration Protocol (DHCP) to dynamically assign IP addresses to entities 130b requesting connections. Entities 130a-e may also disguise their identities by deceiving legitimate entities. Thus, gathering data about the characteristics of each entity 130a-e can help classify the entities 130a-e and determine how to handle communications.

The ease of creating and spoofing identities in the virtual and physical worlds can create an incentive for users to act maliciously without bearing the consequences of that action. For example, an IP address of a legitimate entity stolen by a criminal on the Internet (or a stolen passport in the physical world) may enable that criminal to engage in malicious operations with relative ease by pretending to be a stolen identity. However, by assigning reputations to physical and virtual entities and identifying the multiple identities they may use, a reputation system can influence reputable entities as well as poor Entities communicate or interact.

Figure 3 is a block diagram depicting an example of communications and entities, including utilizing identifiers and attributes for detecting relationships between entities. Security agents 100a-b may collect data by inspecting communications sent to relevant networks. Security agents 100a-b may also collect data by inspecting communications relayed by relevant networks. Inspection and analysis of communications may allow security agents 100a-b to gather information about entities 300a-c sending and receiving messages, including transmission patterns, volumes, or whether entities are sending certain types of messages (e.g., legitimate message, spam, virus, mass mailing, etc.).

As shown in FIG. 3, each entity 300a-c is associated with one or more identifiers 310a-c, respectively. Identifiers 310a-c may include, for example, IP addresses, Uniform Resource Locators (URLs), phone numbers, IM usernames, message content, domains, or any other identifier that may describe an entity. Also, identifiers 310a-c are associated with one or more attributes 320a-c. As should be understood, the attributes 320a-c conform to the particular identifiers 310a-c described. For example, a message content identifier may include attributes such as malware, quantity, content type, operational status, and the like. Similarly, attributes 320a-c associated with identifiers such as IP addresses may include one or more IP addresses associated with entities 300a-c.

Furthermore, it should be understood that this data that may be collected from communications 330a-c (eg, email) typically includes some identifier and attributes of the entity initiating the communication. Accordingly, the communications 330a-c provide for the transfer of information about entities to the security agents 100a, 100b. Security agents 100a, 100b may detect these attributes by examining header information included in messages, analyzing the content of messages, and by aggregating information previously collected by security agents 100a, 100b (e.g., summing the number of communications received from entities).

Data from multiple security agents 100a, 100b may be aggregated and utilized. For example, data may be aggregated and utilized by a central system that receives identifiers and attributes associated with all entities 300a-c for which security agents 100a, 100b have received communications. Alternatively, the security agents 100a, 100b communicating identifier and attribute information about the entities 300a-c to each other may operate as a distributed system. The process of utilizing the data may correlate attributes of the entities 300a-c with one another to determine relationships between the entities 300a-c (eg, associations between occurrences, numbers, and/or other determining factors).

These relationships can then be used to build a multi-dimensional reputation "vector" for all identifiers based on the association of attributes associated with each identifier. For example, if a reputable entity 300a with a known reputation with a bad reputation sends a message 330a with a first set of attributes 350a, and then an unknown entity 300b sends a message 330b with a second set of attributes 350b, the security agent 100a may determine that the Whether all or a portion of one set of attributes 350a matches all or a portion of a second set of attributes 350b. When some portion of the first set of attributes 350a matches some portion of the second set of attributes 350b, a relationship may be established based on the particular identifier 320a, 320b comprising the matching attributes 330a, 33b. The particular identifiers 340a, 340b that are found to have matching attributes may be used to determine the strength associated with the relationship between the entities 300a, 300b. The strength of the relationship may help determine how much of the poorly reputable nature of the poorly reputable entity 300a is attributed to the reputation of the unknown entity 300b.

However, it should also be appreciated that an unknown entity 300b may initiate a communication 330c that includes attributes 350c that match some attributes 350d of a communication 330d originating from a known reputable entity 300c. The particular identifiers 340c, 340d that are found to have matching attributes may be used to determine the strength associated with the relationship between the entities 300b, 300c. The strength of the relationship may help determine how much of the reputable property of the reputable entity 300c is attributed to the reputation of the unknown entity 300b.

Distributed reputation engines also allow real-time collaborative sharing of global intelligence on recent threat landscapes, providing the benefit of immediate protection over localized analysis that can be performed by filtering or risk analysis systems, and identifying possible new threats even before they emerge. The malicious source of the threat. Using sensors located at many different geographic locations, information about new threats can be quickly shared with the central system 200 or with the distributed security agents 100a, 100b. As should be appreciated, such distributed sensors may include local security agents 100a, 100b, as well as local reputable clients, traffic monitors, or any other device suitable for collecting communication data (e.g., switches, routers, servers ,etc).

For example, security agents 100a, 100b may communicate with central system 200 to provide sharing of threat and reputation information. Optionally, security agents 100a, 100b may communicate threat and reputation information between each other to provide up-to-date and accurate threat information. In the example of FIG. 3, the first security agent 300a has information about the relationship between the unknown entity 300b and the entity 300a with a bad reputation, while the second security agent 300b has information about the relationship between the unknown entity 300b and the entity 300c with a good reputation. relationship information. In the absence of shared information, the first security agent 300a may take specific actions on the communication based on the detected relationship. However, knowing the relationship between the unknown entity 300b and the reputable entity 300c, the first security agent 300a can utilize the received communication from the unknown entity 300b to take different actions. The sharing of relationship information between security agents thus provides a more complete set of relationship information for which determinations are to be made.

Systems attempt to assign reputations (reflecting general tendencies and/or classifications) to physical entities, such as individuals or automated systems performing transactions. In a virtual world, entities are represented by identifiers (eg, IP, URL, content) that are linked to those entities in a particular transaction they are performing (eg, sending a message or transferring funds from a bank account). Reputations can thus be assigned to those identifiers based on their overall behavior and historical patterns and their relationship to other identifiers, eg IPs sending messages to URLs included in those messages. If there are strong associations between identifiers, a "poor" reputation of a single identifier may worsen the reputation of other nearby identifiers. For example, an IP sending a URL with a bad reputation will have its own reputation worsened by the URL's reputation. Finally, individual identifier reputations can be aggregated into a single reputation (risk score) for the entities associated with those identifiers.

It should be noted that attributes can be divided into many categories. For example, evidence attributes may represent physical, digital, or digitized physical data about an entity. This data can be attributed to a single known or unknown entity, or shared among multiple entities (forming an entity relationship). Examples of evidentiary attributes relevant to message security include IP (Internet Protocol) addresses, known domain names, URLs, digital fingerprints or signatures used by entities, TCP signatures, and the like.

As another example, behavioral attributes may represent human or machine-assigned observations about entities or evidence attributes. Such properties may include one, many or all properties from one or more behavioral profiles. For example, behavioral attributes commonly associated with spammers may depend on the high volume of communications sent from that entity.

Many behavior attributes for a particular type of behavior can be combined to derive a behavior profile. A behavior profile may include a set of predefined behavior properties. The attribute characteristics assigned to these profiles include behavioral events related to the propensity of entities that define matching profiles. Examples of behavioral profiles related to message security may include "spammers," "scammers," and "legitimate senders." Event and/or evidence attributes associated with each profile define the appropriate entity to which the profile should be assigned. This could include a specific set of sending patterns, blacklist events, or specific attributes of evidence data. Some examples include: sender/receiver identification; time interval and transmission mode; payload severity and configuration; message structure; message quality; protocol and associated signatures; communication medium.

It should be understood that entities that share some or all of the same evidence attributes have an evidence relationship. Similarly, entities that share behavioral properties have behavioral relationships. These relationships help form logical groups of related profiles, which relationships are then adaptively applied to enhance the profile or identify entities that more or less conform to the assigned profile.

FIG. 4 is a flowchart describing an operational scheme 400 for detecting relationships and assigning risks to entities. The operational scheme begins at step 410 by collecting network data. Data collection may be accomplished, for example, by a security agent 100, client device, switch, router, or any other device operable to receive data from a network entity (e.g., email server, web server, IM server, ISP, file transfer protocol ( FTP) server, gopher server, VoIP device, etc.) to receive communications.

At step 420, an identifier is associated with the collected data (eg, communication data). Step 420 may be performed by a security agent 100 or central system 200 operable to aggregate data from a number of sensor devices, including for example one or more security agents 100 . Optionally, step 420 may be performed by the security agent 100 itself. The identifier may be based on the type of communication received. For example, an email may include one set of information (e.g. IP addresses of sender and recipient, text content, attachments, etc.), while a VoIP communication may include a different set of information (e.g. calling VoIP client originating IP address), receiving phone number (or IP address if VoIP phone is specified), voice content, etc.). Step 420 may also include assigning attributes of communications with associated identifiers.

At step 430, attributes associated with the entities are analyzed to determine whether any relationships exist between the entities for which communication information is collected. Step 430 may be performed, for example, by the central system 200 or one or more distributed security agents 100 . Analysis may include comparing attributes related to different entities to find relationships between entities. Also, strength can be associated with a relationship according to the particular attribute that underlies the relationship.

At step 440, risk vectors are assigned to entities. Risk vectors may be assigned by the central system 200 or one or more security agents 100 as examples. The risk vectors assigned to the entities 130 (FIGS. 1-2), 300 (FIG. 3) may be based on the relationships that exist between the entities and on the identifiers that form the basis of the relationships.

At step 450, actions may be performed based on the risk vector. This action may be performed by security agent 100, for example. Actions can be performed on received communications associated with the entity to which the risk vector is assigned. Among other things, the actions may include allowing, denying, quarantining, load balancing, transmitting with assigned priority, and locally analyzing with additional scrutiny. However, it should be understood that the reputation vector can be obtained separately.

5 is a block diagram illustrating an exemplary network architecture including local reputations 500a-e derived by local reputation engines 510a-e and global reputations 520 stored by one or more servers 530. FIG. Local reputation engines 510a-e may be associated with a local security agent, such as security agent 100, for example. Alternatively, a local reputation engine 510a-e may be associated with a local client, for example. Each of the reputation engines 510a-e includes a list of one or more entities for which the reputation engines 510a-e store the resulting reputations 500a-e.

However, these stored resulting reputations may be inconsistent across reputation engines, since each reputation engine may observe different types of traffic. For example, reputation engine 1 510a may include a reputation indicating that a particular entity is reputable, while reputation engine 2 510b may include a reputation indicating that the same entity is not reputable. These localized reputation inconsistencies may be based on different traffic volumes received from entities. Alternatively, the inconsistency may be based on feedback from users of the local reputation engine 1510a indicating that the communication is legitimate, while the local reputation engine 2510b provides feedback indicating that the same communication is not legitimate.

Server 530 receives reputation information from local reputation engines 510a-e. However, as noted above, some partial reputation information may not be consistent with other partial reputation information. Server 530 may arbitrate among local reputations 500a-e to determine global reputation 520 based on local reputation information 500a-e. In some examples, the global reputation information 520 may then be provided back to the local reputation engines 510a-e to provide these engines 510a-e with up-to-date reputation information. Optionally, local reputation engines 510a-e are operable to query server 530 for reputation information. In some examples, server 530 responds to queries using global reputation information 520 .

In other examples, server 530 applies a local reputation bias to global reputation 520 . Local reputation biasing may perform a transformation on the global reputation to provide the local reputation engines 510a-e with global reputation vectors that are biased according to the preferences of the particular local reputation engine 510a-e originating the query. Thus, a local reputation engine 510a that an administrator or user has indicated a high tolerance for spam messages may receive a global reputation vector that accounts for the indicated tolerance. Certain components of the reputation vector returned to the reputation engine 510a may include portions of the reputation vector that are less important due to their relationship to the rest of the reputation vector. Likewise, local reputation engine 510b may receive a reputation vector that amplifies a component of a reputation vector related to virus reputation, local reputation engine 510b indicating, for example, a low tolerance communication from an entity with a reputation of originating a virus.

FIG. 6 is a block diagram illustrating determination of global reputation based on local reputation feedback. Local reputation engine 600 is operable to send queries to server 620 over network 610 . In some examples, local reputation engine 600 initiates a query in response to receiving a communication from an unknown entity. Optionally, local reputation engine 600 may initiate a query in response to receiving any communications, thereby facilitating the use of more up-to-date reputation information.

Server 620 is operable to respond to queries using global reputation determinations. The central server 620 can use the global reputation aggregation engine 630 to obtain the global reputation. The global reputation aggregation engine 630 is operable to receive a plurality of local reputations 640 from a corresponding plurality of local reputation engines. In some examples, number of local reputations 640 may be periodically sent to server 620 by reputation engine. Optionally, multiple local reputations 640 may be retrieved by the server upon receiving a query from one of the local reputation engines 600 .

The partial reputations can be merged using a confidence value associated with each partial reputation engine and then accumulating the results. The confidence value may indicate a degree of confidence associated with the local reputation generated by the relevant reputation engine. A reputation engine associated with an individual, for example, may receive a lower weight in the global reputation determination. Conversely, a local reputation associated with a reputation engine operating on a large network may receive greater weight in the global reputation determination based on the confidence value associated with that reputation engine.

In some examples, confidence value 650 may be based on feedback received from a user. For example, a reputation engine may be assigned a low confidence value 650 for the local reputation 640 associated with the reputation engine that receives many feedbacks indicating that the communication was not handled correctly because the local reputation information 640 associated with the communication indicated erroneous actions. Similarly, a reputation engine may be assigned a high confidence value 650 for a local reputation 640 associated with the reputation engine receiving feedback indicating that the communication was handled correctly based on the local reputation information 640, which is consistent with the local reputation information 640 indicating correct action. Communication is associated. Adjustment of confidence values associated with different reputation engines may be accomplished using adjuster 660 operable to receive input information and adjust the confidence value based on the received input. In some examples, the confidence value 650 may be provided to the server 620 by the reputation engine itself, based on stored statistics for misclassified entities. In other examples, information used to weight local reputation information may be communicated to server 620 .

In some examples, a bias 670 may be applied to the resulting global reputation vector. Bias 670 may normalize the reputation vector to provide reputation engine 600 with a normalized global reputation vector. Optionally, a bias 670 may be applied to account for local preferences related to the reputation engine 600 originating the reputation query. Accordingly, the reputation engine 600 may receive a global reputation vector that matches the determined preferences of the queried reputation engine 600 . Reputation engine 600 may take action on communications based on the global reputation vector received from server 620 .

FIG. 7 is a block diagram illustrating an exemplary conversion between global reputation and local reputation. Local security agent 700 communicates with server 720 to retrieve global reputation information from server 720 . Local security agent 700 can receive a communication at 702 . The local security agent can correlate the communication at 704 to identify attributes of the message. Attributes of a message may include, for example, an originating entity, a fingerprint of the message content, a message size, and the like. Local security agent 700 includes this information in queries to server 720 . In other examples, local security agent 700 can forward the entire message to server 720, and the server can perform correlation and analysis of the messages.

The server 720 uses the information received from the query to determine the global reputation according to the configuration 725 of the server 720 . Configuration 725 may include a plurality of reputation information, including information indicating that the queried entity is of poor reputation (730) and information indicating that the queried entity is of good reputation (735). Configuration 725 may also apply weights 740 to each aggregated reputation 730 , 735 . The reputation score determiner 745 may provide an engine for weighting ( 740 ) the aggregated reputation information 730 , 735 and generating a global reputation vector.

The local security agent 700 then sends a query at 706 to the local reputation engine. The local reputation engine 708 performs the determination of the local reputation and returns a local reputation vector at 710 . Local security agent 700 also receives responses to reputation queries sent to server 720 in the form of global reputation vectors. The local security agent 700 then blends the local reputation vector and the global reputation vector together at 712 . Action is then taken at 714 with respect to the received message.

FIG. 8 is an example graphical user interface 800 for adjusting settings of filters associated with reputation servers. The graphical user interface 800 may allow the user of the local security agent to sort through a number of different categories 810, such as "viruses", "worms", "trojan horses", "phishing", "spyware", "spam", "content" And adjust the configuration of local filters in "Mass". It should be understood, however, that the categories 810 described are examples only, and that the present disclosure is not limited to the categories 810 selected here as examples.

In some examples, categories 810 may be divided into two or more types of categories. For example, category 810 of FIG. 8 is divided into a "Security Settings" type 820 of category 810 and a "Policy Settings" type 830 of category. Within each category 810 and type 820, 830, a mixer bar representation 840 may allow a user to adjust specific filter settings associated with the corresponding category 810 of communications or entity reputation.

Also, while the category 810 of the 'policy setting' type 830 can be freely adjusted according to the user's own judgment, the category of the 'security setting' type 820 can be restricted to be adjusted within a range. This difference can be made to prevent users from changing the security settings of the security agent beyond acceptable limits. For example, a dissatisfied employee may attempt to lower security settings, thereby allowing the corporate NetEase to be attacked. Accordingly, a scope 850 placed on a category 810 in the "Security Settings" type 820 is operable to keep security at a minimum level to prevent the network from being compromised. However, as should be noted, the categories 810 of the "policy setting" type 830 are those categories 810 of types that do not compromise network security, but may simply inconvenience users or businesses if the settings are lowered.

Furthermore, it should be appreciated that range limitations 850 may be placed on all categories 810 in various examples. Therefore, the local security agent will prevent the user from setting the mixer bar representation 840 outside the range 850 provided. It should also be noted that in some examples, the range may not be displayed on the graphical user interface 800 . Instead, the scope 850 will be extracted from the graphical user interface 800, and all settings will be related settings. Thus, the category 800 can display and appear to allow the full range of settings while transforming the settings to settings within the range provided. For example, the range 850 for the "virus" category 810 is set between horizontal markers 8 and 13 in this example. If the GUI 800 is set to extract the allowable range 850 from the GUI 800, the "Virus" category 810 will allow the mixer bar representation 840 to be set anywhere between 0 and 14. However, the graphical user interface 800 may transform the 0-14 setting to a setting within the range 850 of 8-13. Thus, if the user requests a setting intermediate between 0 and 14, the graphical user interface may transform the setting to a setting intermediate 8 and 13.

9 is a block diagram illustrating reputation-based connection suppression for Voice over Internet Protocol (VoIP) or Short Message Service (SMS) communications. As should be appreciated, the calling IP phone 900 can place a VoIP call to the receiving IP phone 910 . These IP phones 900, 910 may be, for example, computer-executed softphone software, web-enabled phones, or the like. The calling IP phone 900 can place a VoIP call through a network 920 (eg, the Internet). The receiving IP phone 910 may receive the VoIP call over a local area network 930 (eg, an enterprise network).

When establishing a VoIP call, the calling IP phone has already established a connection with the LAN 930 . This connection can be used similarly to the way email, web, instant messaging or other Internet applications can be used to provide an unregulated connection to a network. Thus, the connection to the receiving IP phone can be used, thereby exposing the computers 940, 950 operating on the local area network 930 to the risk of intrusions, viruses, Trojan horses, worms, and various other types of attacks depending on the connection established. Also, due to the time-sensitive nature of VoIP communications, these communications are generally not checked to ensure that the connection is not being misused. For example, voice conversations occur in real time. If some packets of a voice conversation are delayed, the conversation becomes unnatural and difficult to understand. Therefore, once a connection is established, it is generally not possible to inspect the contents of the packets.

However, the local security agent 960 can use the reputation information received from the reputation engine or server 970 to determine the reputation associated with the calling IP phone. Local security proxy 960 may use the originating entity's reputation to determine whether to allow a connection with the originating entity. Accordingly, security proxy 960 may prevent connections to entities with poor reputations, as indicated by reputations that do not comply with local security proxy 960 policies.

In some examples, local security agent 960 may include a connection suppression engine operable to use the connection established between calling IP phone 900 and receiving IP phone 910 to control the flow rate of packets being transmitted. Therefore, an originating entity 900 with a poor reputation may be allowed to make a connection with a receiving IP phone 910 . However, the packet throughput will be capped, preventing the originating entity 900 from using the connection to attack the LAN 930 . Alternatively, connection suppression may be accomplished by performing a scrutiny of any packets originating from entities with a bad reputation. As mentioned above, scrutiny of all VoIP packets is not efficient. Accordingly, quality of service (QoS) may be maximized for connections associated with entities with a good reputation, while reducing QoS associated with connections with entities with a poor reputation. Standard communication interrogation techniques may be performed on connections associated with disreputable entities to issue whether any transmitted packets received from the originating entity include threats to the network 930 . Various interrogation techniques and systems are described in U.S. Patent Nos. 6,941,467, 7,089,590, 7,096,498, and 7,124,438 and in U.S. Patent Application Nos. , which are hereby incorporated by reference above.

FIG. 10 is a block diagram illustrating the operation of a reputation-based load balancer 1000 . The load balancer 1000 is operable to receive communications from reputable entities 1010 and unreputable entities 1020 (respectively) over a network 1030 (eg, the Internet). The load balancer 1000 communicates with the reputation engine 1040 to determine the reputation of the entities 1010, 1020 associated with incoming or outgoing communications.

The reputation engine 1030 is operable to provide a reputation vector to the load balancer. The reputation vector may indicate the reputation of the entity 1010, 1020 associated with the communication in a variety of different categories. For example, a reputation vector may indicate a good reputation of an entity 1010, 1020 for a spam originating entity 1010, 1020 while also indicating a poor reputation of the same entity 1010, 1020 for a virus originating entity 1010, 1020.

The load balancer 1000 can use the reputation vector to determine what action to take with respect to communications associated with the entities 1010, 1020. Where a reputable entity 1010 is associated with a communication, the message is sent to a message transfer agent (MTA) 1050 and transmitted to a recipient 1060 .

Where the reputable entity 1020 has a reputation for viruses but not other types of reputable activity, the communication is forwarded to one of the plurality of virus detectors 1070 . The load balancer 1000 is operable to determine which of the plurality of virus detectors 1070 to use based on the current capacity of the virus detectors and the reputation of the originating entity. For example, load balancer 1000 may send communications to the least utilized virus detectors. In other examples, the load balancer 1000 may determine a poor reputation associated with the originating entity, and send communications with a slightly poor reputation to the least utilized virus detectors, while sending communications with a very poor reputation to the highly exploited A virus detector that suppresses QoS for connections associated with entities with very bad reputations.

Similarly, where a poorly reputable entity 1020 has a reputation for initiating spam communications but no reputation for other types of poorly reputable activity, the load balancer can send the communication to a dedicated spam detector 1080 to exclude other types of test. It should be appreciated that where a communication is associated with a reputable entity 1020 that initiates multiple types of reputable activity, the communication may be sent to test each type of reputable activity that the entity 1020 is known to exhibit, while avoiding A test associated with activities that do not know the poor reputation of the entity 1020 to display.

In some examples, each communication may receive routine tests for multiple types of illegal content. However, communications may also be isolated for detailed testing isolation of content when the entity 1020 associated with the communication exhibits a reputation for certain types of activity that the entity exhibits a reputation for originating that content.

In yet other examples, each communication may receive the same type of test. However, communications associated with reputable entities 1010 are sent to the test module with the shortest queue or the test module with spare processing capacity. On the other hand, communications associated with entities 1020 with a poor reputation are sent to the test modules 1070, 1080 with the longest queues. Accordingly, communications associated with entities with a good reputation 1010 may be given priority for transmission over communications associated with entities with a poor reputation. The quality of service is thus maximized for entities 1010 with a good reputation, while the quality of service is reduced for entities 1020 with a bad reputation. Thus, reputation-based load balancing can protect the network from attacks by reducing the ability of entities with poor reputations to connect to the network 930 .

11A is a flowchart illustrating an exemplary operational scheme for collecting geographic location-based data for authentication analysis. At step 1100, the operating scheme collects data from various login attempts. Step 1100 may be performed, for example, by a local security agent, such as security agent 100 of FIG. 1 . Among other things, the data collected may include the IP address associated with the login attempt, the time of the login attempt, the number of login attempts before being successful, or details of any unsuccessful passwords attempted. The collected data is then analyzed at step 1105 to derive statistical information, such as the geographic location of the login attempt. Step 1105 may be performed, for example, by a reputation engine. Then at step 1110 statistical information associated with the login attempts is stored. This storage may be performed, for example, by system data storage.

FIG. 11B is a flowchart illustrating another exemplary operational scheme for geographic location-based authentication. At step 1115 a login attempt is received. A login attempt may be received, for example, by a secure web server operable to provide secure financial data over a network. It is then determined at step 1120 whether the login attempt matches the stored username and password combination. Step 1120 may be performed, for example, by a security server operable to authenticate login attempts. If the username and password do not match the stored username/password combination, then at step 1125 the login attempt is declared failed.

However, if the username and password do match a legitimate username/password combination, then at step 1130 the origin of the login attempt is determined. The origin of the login attempt may be determined by a local security agent 100 as shown in FIG. 1 . Optionally, the origin of the login attempt can be determined by a reputation engine. The origin of the login attempts may then be compared to the statistics derived in FIG. 11A , as shown in step 1135 . Step 1135 may be performed, for example, by local security agent 100 or a reputation engine. At step 1140 it is determined whether the origin matches statistical expectations. If the actual origin matches the statistical expectation, then at step 1145 the user is authenticated.

Optionally, further processing is performed at step 1150 if the actual origin does not match the statistical expectation for origin. It should be understood that further processing may include requesting further information from the user to verify his or her authenticity. Such information may include, for example, home address, mother's maiden name, place of birth, or information about any other part known to the user (such as a secret question). Other examples of additional processing may include searching previous login attempts to determine whether the location of the current login attempt is indeed anomalous or merely coincidental. Additionally, the reputation associated with the entity that initiated the login attempt can be derived and used to determine whether to allow the login.

11C is a flowchart illustrating another exemplary operational scheme for geolocation-based verification using an originating entity's reputation to confirm authentication. At step 1115 a login attempt is received. A login attempt may be received, for example, by a secure web server operable to provide secure financial data over a network. It is then determined at step 1160 whether the login attempt matches the stored username and password combination. Step 1160 may be performed, for example, by a security server operable to authenticate login attempts. If the username and password do not match the stored username/password combination, then at step 1165 the login attempt is declared failed.

However, if the username and password do match a legitimate username/password combination, then at step 1170 the origin of the login attempt is determined. The origin of the login attempt may be determined by a local security agent 100 as shown in FIG. 1 . Optionally, the origin of the login attempt can be determined by a reputation engine. The reputation associated with the entity that initiated the login attempt may then be retrieved, as shown in step 1175 . Step 1175 may be performed, for example, by a reputation engine. At step 1180 it is determined whether the reputation of the originating entity is reputable. If the originating entity is reputable, then at step 1185 the user's identity is verified.

Optionally, further processing is performed at step 1190 if the originating entity is reputable. It should be understood that further processing may include requesting further information from the user to verify his or her authenticity. Such information may include, for example, home address, mother's maiden name, place of birth, or information about any other part known to the user (such as a secret question). Other examples of additional processing may include searching previous login attempts to determine whether the location of the current login attempt is indeed anomalous or merely coincidental.

Accordingly, it should be understood that a reputation system may be applied to identify fraudulent behavior in financial transactions. A reputation system can improve a transaction's risk score based on the reputation of the transaction originator or data from the actual transaction (source, destination, amount, etc.). In such cases, the financial institution can better determine the probability that a particular transaction is fraudulent based on the reputation of the originating entity.

12 is a flowchart illustrating an exemplary operational scheme for reputation-based dynamic isolation. At step 1200 a communication is received. Communications are then analyzed at step 1205 to determine if they are associated with an unknown entity. It should be noted, however, that this operational scheme is applicable to any communication received, not just communications received from previously unknown entities. For example, communications received from entities with a bad reputation may be dynamically quarantined until it is determined that the received communications do not pose a threat to the network. Where the communication is not associated with a new entity, the communication undergoes normal processing for incoming communications, as shown in step 1210 .

If the communication is associated with a new entity, then at step 1215 a dynamic isolation counter is initialized. Next at step 1220, communications received from the new entity are sent to the dynamic quarantine. The counter is then checked at step 1225 to determine whether the counter's time has elapsed. If the counter time has not elapsed, then at step 1230 the counter is decremented. At step 1235, the behavior of the entities and isolated communications may be analyzed. At step 1240 it is determined whether the entity's behavior or quarantined communications are anomalous. If no abnormal conditions are found, the operational scheme returns to step 1220 where new communications are quarantined.

However, if at step 1240 the entity's behavior or communications are found to be anomalous, then at step 1245 the entity is assigned a reputation of poor reputation. The process ends by sending a notification to the administrator or recipient of the communication sent by the originating entity.

Returning to step 1220, the process of isolating and examining communications and entity behavior continues until anomalous behavior is found, or until the time of the dynamic quarantine counter at step 1225 elapses. If the dynamic quarantine counter time elapses, then at step 1255 the entity is assigned a reputation. Optionally, the reputation may be updated at step 1245 or 1255 where the entity is not an unknown entity. The operational scheme ends at step 1260 by releasing the dynamic quarantine, where the dynamic quarantine counter time has elapsed without finding anomalies in the communication or in the behavior of the originating entity.

13 is a display of an example graphical user interface 1300 for image spam communications that may be classified as unwanted images or messages. As should be appreciated, image spam poses problems for traditional spam filters. Image spam bypasses traditional text analysis of spam by converting the spam's text message into an image format. Fig. 13 shows an example of image spam. The message displays image 1310 . Although image 1300 appears to be text, it is merely a graphical encoding of a text message. Typically, image spam also includes text messages 1320 that include sentences that are correctly constructed but do not make sense in the context of the message. Message 1320 is designed to evade spam filters for incoming communications in which only image 1310 is included. Furthermore, message 1320 is designed to spoof filters that apply crude tests to the text of communications including image 1310 . Further, when these messages do include information in header 1330 about the origin of the message, the reputation of the entity for image spamming may be unknown until the entity is caught image spamming.

14 is a flowchart illustrating an exemplary operational scheme for detecting unwanted images (eg, image spam). It should be understood that many of the steps shown in FIG. 14 may be performed alone or in combination with any or all of the other steps shown in FIG. 14 to provide some detection of image spam. However, the use of each step in Figure 14 provides a comprehensive process for detecting image spam.

The process begins at step 1400 with the analysis of communications. Step 1400 generally includes analyzing the communication to determine whether the communication includes images that are subject to image spam. At step 1410, the operational scheme performs a structural analysis of the communication to determine whether the image comprises spam. Next at step 1420 the header of the image is analyzed. Analysis of the image headers allows the system to determine whether there are anomalies (eg, protocol errors, corruption, etc.) with respect to the image format itself. At step 1430 the image is analyzed for features. Feature analysis aims to determine whether any feature of an image is anomalous.

The images may be normalized at step 1440 . Normalization of images generally involves removing random noise that may be added by spammers to avoid image fingerprinting techniques. Image normalization aims to convert images into a format that is easily comparable across images. Fingerprinting may be performed on the normalized images to determine if the images match images from previously received known image spam.

15A is a flowchart illustrating an operational scheme for analyzing the structure of a communication. The operational scheme begins at step 1500 with the analysis of the message structure. At step 1505, the hypertext markup language (HTML) structure of the communication is analyzed to introduce n-gram tags as additional tokens for Bayesian analysis. Such processing may analyze text 1320 included in image spam communications for anomalies. The HTML structure of the message may be analyzed to define meta-tokens. The meta-token is the HTML content of the message, which is processed to discard any irrelevant HTML markup, and compressed by removing white space to generate a "symbol" for Bayesian analysis. Each of the above symbols can be used as input to a Bayesian analysis for comparison with previously received communications.

The operational protocol then includes image detection at step 1515 . Image detection may include segmenting the image into portions, and performing fingerprinting on the portions to determine whether the fingerprint matches previously received portions of the image.

Figure 15B is a flowchart illustrating an operational scheme for the process of analyzing features of an image to extract features for messages input into a clustering engine in order to identify messages consistent with known image spam components of the image. The operational scheme begins at step 1520, where a number of high level features of the image are detected for use in a machine learning algorithm. Such features may include numerical values such as the number of distinct colors, the number of noise black pixels, the number of edges (sharp transitions between shapes) in the horizontal direction, and the like.

One of the features extracted by the operational protocol may include the number of histogram patterns of the image, as shown at step 1525 . The number of modes is generated by examining the spectral density of the image. As should be appreciated, artificial images generally include fewer patterns than natural images because natural image colors generally spread over a broad spectrum.

As mentioned above, features extracted from images can be used to identify anomalies. In some examples, the anomaly may include analyzing features of the message to determine a degree of similarity of the features to features of the stored unwanted image. Optionally, in some examples, image features may also be analyzed for comparison with known reputable images to determine similarity to reputable images. It should be understood that none of the extracted features alone can determine the classification. For example, a particular characteristic may be associated with 60% of unwanted messages while also being associated with 40% of wanted messages. Also, as the value associated with a feature changes, the probability that a message is wanted or unwanted may change. There are many characteristics that can indicate a slight tendency. If each of these features is combined, an image spam detection system can make a classification decision.

The aspect ratio is then checked at step 1530 to determine if there are any anomalies with respect to image size or aspect ratio. Similarity of image dimensions or aspect ratios to known dimensions or aspect ratios common to known image spam may indicate such anomalies in aspect ratios. For example, image spam can appear at a specific size to make image spam look more like regular email. Messages that include images that share dimensions with known spam images are more likely to be spam itself. Optionally, there are image sizes that are not conducive to spam (eg, a 1 inch by 1 inch square image may be difficult to read if a spammer inserts a message into the image). Messages including images that are known to be detrimental to the insertion of spam are less likely to be image spam. Thus, the aspect ratio of the message may be compared to common aspect ratios used in image spam to determine the probability that the image is an unwanted image or that the image is a reputable image.

At step 1535, the frequency distribution of the image is checked. In general, natural images have a uniform frequency distribution with relatively few significant frequency gradients. Image spam, on the other hand, generally includes a constant frequency distribution because black letters are placed on a dark background. Therefore, such an uneven frequency distribution may be indicative of image spam.

At step 1540, the signal-to-noise ratio may be analyzed. A high signal-to-noise ratio can indicate that spammers may be trying to evade fingerprinting techniques by introducing noise into the image. Thus increasing the noise level may indicate an increased probability that the image is an unwanted image.

It should be understood that some features may be extracted on the scale of the entire image, while other features may be extracted from sub-portions of the image. For example, an image may be subdivided into sub-sections. Each rectangle can be transformed into the frequency domain using a Fast Fourier Transform (FFT). In the transformed image, the predominance of frequencies in multiple directions can be extracted as features. These sub-portions of the transformed image can also be examined to determine the amount of high and low frequencies. In the transformed image, points farther from the origin exhibit higher frequencies. Like other extracted features, these features can then be compared to known legitimate and unwanted images to determine which characteristics the unknown image shares with each type of known image. Furthermore, the transformed (e.g. frequency domain) image can also be divided into sub-parts (e.g. slices, rectangles, concentric circles, etc.) known legitimate images) for data comparison.

Figure 15C is a flowchart illustrating an operational scheme for normalizing images for spam handling. At step 1545, blur and noise are removed from the image. As mentioned earlier, these may be introduced by spammers to evade fingerprinting techniques, e.g. by changing the hashing of the hash count so that it does not match any previously received hash fingerprints of known image spam . Blur and Noise Removal describes several techniques for removing the artifacts introduced by spammers. It should be understood that artifacts may include techniques used by spammers, such as banding (which includes font changes in an image to alter the meaning of the image).

At step 1550, an edge detection algorithm may be performed on the normalized image. In some examples, the edge-detected image is used and provided to an optical character recognition engine to convert the edge-detected image into text. Edge detection can be used to remove unnecessary detail from a picture that may cause inefficiencies in processing that image relative to other images.

At step 1555, median filtering may be applied. Apply a median filter to remove random pixel noise. Such random pixels can pose problems for content analysis of images. Median filtering helps remove single-pixel type noise introduced by spammers. It should be understood that single-pixel noise is introduced by spammers using image editors to alter one or more pixels in an image, which can make the image look grainy in some areas, making the image more difficult to detect.

At step 1560, the image is quantized. Quantization of the image removes unnecessary color information. This color information generally requires more processing and has nothing to do with the attempted spread of spam. Also, the spammer can slightly change the color scheme in the image, and change the hash again, so that the hash of known image spam does not match the hash derived from color-changed image spam.

At step 1565, contrast extension is performed. With contrast expansion, the color scale in the image is maximized from black to white, even if the colors vary only in shades of gray. Assigns white values to the brightest shadows of the image, and black values to the darkest shadows in the image. All other shadows are assigned their relative positions in the spectrum compared to the lightest and darkest shadows in the original image. Contrast expansion helps limit details in an image that may not be fully utilizing the available spectrum, thus helping to stop spammers from using different parts of the spectrum to avoid fingerprinting techniques. Spammers sometimes intentionally alter the density range of images to invalidate some types of feature recognition engines. Contrast expansion can also help normalize an image so that it can be compared with other images to identify common features contained in the images.

15D is a flowchart illustrating an operational scheme for analyzing fingerprints of images to find common segments in multiple images. At step 1570, the operational protocol begins by defining a region within the image. A winnowing algorithm is then performed on the defined area to identify the relevant portion of the image on which the fingerprint should be extracted at step 1575. At step 1580, the operational scheme fingerprints the segments resulting from the winnowing operation and determines whether there is a match between the fingerprints of the received image and known spam images. A similar winnowing fingerprinting method is described in each of Patent Application Publication No. 2006/0251068, which is hereby incorporated by reference.

As used herein in the specification and in all the claims that follow, the meanings of "a", "an" and "the" include plural reference unless the context clearly dictates otherwise . Furthermore, as used herein in the specification and in all the claims that follow, the meaning of "in" includes, "in" and "on" unless the context clearly dictates otherwise. Finally, as used herein in the specification and throughout the claims that follow, the meanings of "and" and "or" include both combined and disjunctive meanings and are used interchangeably unless the context clearly dictates otherwise.

Ranges can be expressed herein as from "about" one particular value, and/or to "about" another particular value. When such a range is expressed, another embodiment includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations, by use of the preceding "about," it will be understood that the particular value forms another embodiment. It is further to be understood that the endpoints of each range are relative to, and independent of, the other endpoints.

A number of embodiments of the invention have been described. However, it should be understood that various changes may be made without departing from the spirit and scope of the invention. Accordingly, other implementations are within the scope of the following claims.

Claims (135)

1. A computer-implemented method operable to assign a reputation to a network-based entity associated with a hypertext transfer protocol communication, the method comprising the steps of: receiving hypertext transfer protocol communications at the edge protection device; identifying an entity associated with the received hypertext transfer protocol communication; querying a reputation engine for a reputation indicator associated with said entity; receiving the reputation indicator from the reputation engine; An action is taken with respect to the hypertext transfer protocol communication based on the received reputation indicator associated with the entity. 2. The method of claim 1, wherein the entity is a network entity comprising a destination uniform resource locator, domain or IP address. 3. The method of claim 1, wherein the entity's reputation is based on previous communications received from the entity and available public or private network information about the entity, the public or private network information including Ownership or Escrow Information. 4. The method of claim 3, wherein the previous communications include one or more of the following: electronic messaging, hypertext transfer protocol communications, instant messaging, file transfer protocol communications, Simple Object Access Protocol messages, real-time transport protocol packets, short message service communications, multimedia message service communications, or voice over internet protocol telephony communications. 5. The method of claim 1, wherein the action is discarding the communication and notifying an intranet user associated with the hypertext transfer protocol communication. 6. The method of claim 1, wherein the entity is associated with a plurality of different types of network communications including at least Hypertext Transfer Protocol type communications, and including email communications, file transfer protocol communications , instant message communication, gopher communication, short message service communication or voice over internet protocol communication. 7. The method of claim 1, wherein the reputation engine determines the reputation indicator based on an aggregation of reputation-worthy criteria associated with the entity and reputation-bad criteria associated with the entity. 8. The method of claim 7, wherein the reputation indicator is a vector indicating reputation according to a plurality of different criteria. 9. The method of claim 8, further comprising examining a reputation vector to determine whether a policy associated with an enterprise network protected by the edge protection device permits communication with the entity based on the entity's reputation vector . 10. The method of claim 1, wherein the reputation engine is a reputation server operable to provide reputation information to a plurality of edge protection devices. 11. The method of claim 10, wherein the reputation engine is operable to store a global reputation indicator and to bias the global reputation indicator using a local bias before outputting the reputation indicator. 12. The method of claim 1, wherein the reputation indicator comprises a reputation vector comprising a multidimensional classification of the entity. 13. The method of claim 12, wherein the multi-dimensional classification comprises two or more of a pornography category, a news category, a computer category, a security category, a phishing category, a spyware category, a virus category, or an attack category. Classification of multiple ongoing messages. 14. The method of claim 12, wherein the reputation indicator further comprises a confidence level associated with each of the multidimensional classifications of the entity. 15. The method of claim 1, further comprising detecting randomization of Uniform Resource Locators. 16. The method of claim 15, wherein the URL of the URL is determined by generating a hash of the URL and comparing the hash to previously identified URLs of poor reputation. randomize. 17. The method of claim 15, wherein the uniform resource locator is determined by fingerprinting portions of the uniform resource locator and comparing the clutter to previously identified URLs of poor reputation. Randomization of resource locators. 18. A network reputation system on an edge protection device, the network reputation system operable to receive network communications and assign reputations to entities associated with the communications, the system comprising: a communication interface operable to receive network communications; a communication analyzer operable to analyze the network communication to determine entities associated with the network communication; a reputation engine operable to provide a reputation associated with the entity based on previously collected data associated with the entity, and a decision engine operable to receive a reputation indicator from the reputation engine and determine whether the network communication was delivered to a recipient. 19. The system of claim 18, wherein the reputation of the entity is based on previous communications received from the entity, the previous communications including one or more of the following: electronic messages, Hypertext transfer protocol communications, instant messaging, file transfer protocol communications, simple object access protocol messages, real-time transport protocol packets, short message service communications, or voice over internet protocol communications. 20. The system of claim 18, wherein the decision engine is operable to notify an intranet user associated with the hypertext transfer protocol communication if the communication is not transmitted to the recipient. 21. The system of claim 18, wherein the reputation engine determines the reputation indicator based on criteria of a good reputation associated with the entity and criteria of a bad reputation associated with the entity. 22. The system of claim 21, wherein the reputation indicator is a vector indicating reputation according to a plurality of different criteria. 23. The system of claim 22, further comprising examining a reputation vector to determine whether a policy associated with an enterprise network protected by the edge protection device permits communication with the entity based on the entity's reputation vector. 24. The system of claim 18, wherein the reputation engine is a reputation server operable to provide reputation information to a plurality of edge protection devices, and the reputation engine is operable to store a global reputation indicator, and to output The reputation indicator previously biased the global reputation indicator using a local bias. 25. The system of claim 18, further comprising a query engine operable to perform a plurality of tests on the communication and determine a profile associated with the network communication. 26. The system of claim 25, wherein the decision engine is operable to determine whether to forward the network communication based on the profile associated with the network communication. 27. The system of claim 26, wherein the reputation engine is operable to use the profile to update reputation information associated with the entity. 28. The system of claim 18, wherein the reputation comprises a reputation vector comprising a multidimensional classification of the entity. 29. The system of claim 28 , wherein the multi-dimensional classification includes two or more of pornography categories, news categories, computer categories, security categories, phishing categories, spyware categories, virus categories, or attack categories. Classification of multiple ongoing messages. 30. The system of claim 28, wherein the reputation further includes a confidence level associated with each of the multidimensional classifications of the entity. 31. The system of claim 18, further comprising detecting randomization of Uniform Resource Locators. 32. The method of claim 31 , wherein the URL of the URL is determined by generating a hash of the URL and comparing the hash to previously identified URLs of poor reputation. randomize. 33. The method of claim 31 , wherein the uniform Randomization of resource locators. . 34. One or more computer-readable media having software program code operable to assign a reputation to a sending entity associated with a received communication, the software program code comprising: receiving hypertext transfer protocol communications at the edge protection device; identifying an entity associated with the received hypertext transfer protocol communication; querying a reputation engine for a reputation indicator associated with said entity; receiving the reputation indicator from the reputation engine; An action is taken with respect to the hypertext transfer protocol communication based on the received reputation indicator associated with the entity. 35. A reputation system, said system comprising: a centralized reputation engine operable to receive feedback from a plurality of local reputation engines operable to determine local reputations from one or more entities and the respectively associated local reputation engines ; an aggregation engine operable to derive the global reputation of the queried entity from the aggregation of multiple local reputations; and wherein the centralized reputation engine is operable to, in response to receiving a reputation query from one or more of the local reputation engines, provide the one or more of the local reputation engines with the queried entity global reputation. 36. The system of claim 35, wherein the aggregation engine is operable to store confidence values associated with respective local reputation engines, the aggregation engine is further operable to use the confidence values associated with the plurality of local reputations Each associated said confidence value aggregates said plurality of local reputations through its respective local reputation engine. 37. The system of claim 36, wherein the local reputation system is a subsystem of the centralized reputation system and performs reputation scoring on a local scale based on communications received by the local reputation engine, and the A centralized reputation engine performs reputation scoring based on communications received by the centralized reputation engine and reputation information received from the local reputation engines. 38. The system of claim 36, wherein the local reputations are weighted according to their respective confidence values prior to aggregation of the local reputations. 39. The system of claim 38, wherein the confidence value is adjusted based on feedback received from the plurality of local reputation engines. 40. The system of claim 35, wherein the local reputation and the global reputation are vectors identifying characteristics of respective entities with which they are associated. 41. The system of claim 40, wherein the signatures include one or more of: spam signatures, phishing signatures, mass mailing signatures, virus source signatures, legitimate communication signatures, intrusion signatures, Attack signatures, spyware signatures, or geographic location signatures. 42. The system of claim 35, wherein the partial reputation is based on an aggregation of reputable criteria and unreputable criteria. 43. The system of claim 35, wherein the centralized reputation system is operable to apply a local reputation bias to the global reputation based on the local reputation engine originating a reputation query. 44. The system of claim 43, wherein the local reputation bias is based on input received from the local reputation engine that originated the reputation query. 45. The system of claim 43, wherein the local reputation bias is based on feedback received from the local reputation engine that originated the reputation query. 46. The system of claim 43, wherein the local reputation bias is operable to enhance a certain criterion of reputation while reducing another criterion of reputation according to the local reputation bias. 47. The system of claim 35, wherein a local reputation engine is operable to apply a local reputation bias to the global reputation prior to applying the global reputation to communications received from the entity being queried. 48. The system of claim 35, wherein the local reputation engine initiates a reputation query in response to receiving a communication associated with an external entity with respect to a secured enterprise network associated with the local reputation engine. 49. The system of claim 48, wherein the local reputation engine initiates the reputation query in response to a local reputation associated with the external entity being uncertain. 50. The system of claim 35, wherein the centralized reputation engine is further operable to aggregate reputations of a plurality of identities associated with one or more of the plurality of entities. 51. The system of claim 50, wherein the centralized reputation engine is further operable to associate associated attributes with different identities to identify relationships between the identities and to associate with an entity A portion of a reputation is assigned to another entity's reputation, where a relationship is identified between entities. 52. A method of generating a global reputation comprising the steps of: Receive reputation queries from the requesting local reputation engine; retrieving a plurality of local reputations, the partial reputations being respectively associated with a plurality of local reputation engines; aggregating the plurality of partial reputations; deriving a global reputation from the aggregation of said local reputations; and Responding to the reputation query with the global reputation. 53. The method of claim 52, further comprising retrieving a confidence value associated with the local reputation engine, the retrieving step using the confidence value to derive the global reputation. 54. The method of claim 53, wherein the step of deriving further comprises weighting the global reputation using respective confidence values of the global reputation, and combining the weighted reputations to generate the global reputation. 55. The method of claim 54, further comprising adjusting the confidence value based on feedback from the plurality of local reputation engines. 56. The method of claim 52, wherein the local reputation and global reputation are vectors identifying characteristics of respective entities with which they are associated. 57. The method of claim 56, wherein the signatures include one or more of: spam signatures, phishing signatures, mass mailing signatures, spyware signatures, or legitimate email signatures. 58. The method of claim 52, wherein the partial reputation is based on an aggregation of reputable criteria and unreputable criteria. 59. The method of claim 52, further comprising applying a local reputation bias to the aggregation of the local reputations to produce a global reputation vector, the local reputation bias being based on the requested local reputation engine. 60. The method of claim 59, wherein the local reputation bias is based on input received from the requested local reputation engine. 61. The method of claim 59, wherein the local reputation bias is based on feedback received from the requesting local reputation engine. 62. The method of claim 59, further comprising enhancing a certain criterion of reputation based on said partial reputation bias and decreasing another criterion of reputation based on said partial reputation bias. 63. The method of claim 52, wherein the requesting local reputation engine initiates the Describe the reputation query. 64. The method of claim 63, wherein the requesting local reputation engine initiates the reputation query in response to a local reputation associated with the external entity being uncertain. 65. The method of claim 52, wherein said step of deriving said global reputation is further based on public and private information not available to any of said plurality of local reputation engines. 66. One or more computer readable media having software program code operable to perform the step of aggregating a plurality of local reputation vectors to produce a global reputation vector, the steps comprising: Receive reputation queries from the requesting local reputation engine; retrieving a plurality of local reputations, the partial reputations being respectively associated with a plurality of local reputation engines; aggregating the plurality of partial reputations; deriving a global reputation from the aggregation of said local reputations; and Reputation queries are responded to with the global reputation. 67. A reputation system, the system comprising: a communication interface operable to receive global reputation information from a central server operable to determine a global reputation based on feedback received from one or more local reputation engines, the global reputations being respectively associated with one or more entity association; a reputation engine operable to bias the global reputation received from the central server according to defined local preferences; and Wherein the centralized reputation engine is operable to provide a global reputation of the queried entity to the communication interface in response to receiving a reputation query from the communication interface. 68. A reputation system, the system comprising: a communication interface operable to receive distributed reputation information from one or more distributed reputation engines operable to examine communications and derive Union's reputation; a reputation module operable to aggregate the distributed reputation information and derive a global reputation from the aggregation of the distributed reputation information, the reputation module further operable to derive a local reputation from communications received by the reputation module information; and A traffic control module operable to determine handling associated with communications based on the global reputation and the local reputation. 69. A reputation-based network security system, the system comprising: a communication interface operable to receive incoming and outgoing communications associated with the network; a communication analyzer operable to obtain external entities associated with the communication; a reputation engine operable to obtain a reputation vector associated with the external entity, the reputation vector comprising an aggregation of reputable and unreputable criteria in a plurality of categories, the plurality of categories including different types of communication; a security engine operable to receive the reputation vector and send the communication to one or more of a plurality of challenge engines, wherein the security engine is operable to determine from the reputation vector to question the plurality of Which of the engines sends the communication. 70. The system of claim 69, wherein the security engine is operable to avoid sending the communication to an unauthorized useless interrogation engine, wherein the reputation vector does not indicate that the external entity has involvement in the unauthorized The reputation of the activity identified by the authorized query engine. 71. The system of claim 69, wherein each of the one or more query engines includes multiple instances of the query engine. 72. The system of claim 71 , wherein upon selection of a query engine, the security engine is capable of selecting a selected instance of the query engine, wherein the selected instance of the query engine is based on The capabilities of the selected instance are selected. 73. The system of claim 69, wherein the security engine is operable to assign high priority to query queues associated with the plurality of query engines if the external entity is a reputable entity and assigning low priority to communications in the query queue if the external entity is an entity with a poor reputation. 74. The system of claim 73, wherein quality of service is maximized for entities with a good reputation and minimized for entities with a poor reputation. 75. The system of claim 69, wherein each of the one or more query engines comprises multiple instances of the query engine, the instances of the query engines operable to reside at an edge protection device or enterprise client device. 76. The system of claim 69, wherein the reputation engine is a reputation server operable to provide reputation information to a plurality of edge protection devices or client devices. 77. A reputation-based network security system, the system comprising: a communication interface operable to receive incoming and outgoing communications associated with the network; a communication analyzer operable to obtain external entities associated with the communication; a reputation engine operable to obtain a reputation associated with said external entity, said reputation comprising an aggregation of reputable and reputable criteria associated with said external entity; a security engine operable to assign priority information to communications, wherein the security engine is operable to receive the reputation and assign a high priority to communications if the external entity is a reputable entity, and where the Low priority is assigned to communications where the external entity is an entity with a poor reputation, whereby the priority information is used by one or more query engines to improve quality of service for entities with a good reputation. 78. A computer-implemented method operable to efficiently process communications based on a reputation associated with an external entity, the method comprising the steps of: receiving a communication associated with an external entity based on origination or destination information associated with the communication; identifying the external entity associated with the received communication; deriving a reputation associated with the external entity based on criteria of good reputation and bad reputation associated with the external entity; assigning priority to the communication based on the derived reputation associated with the external entity; One or more tests are performed on the communication according to the priority assigned to the communication. 79. The method of claim 78, further comprising maximizing quality of service for messages assigned high priority. 80. The method of claim 78, wherein the reputation obtained is a reputation vector conveying the reputation associated with the external entity in a plurality of categories. 81. The method of claim 80, further comprising bypassing the external entity if the reputation vector associated with the communication indicates that the external entity is a reputable entity with respect to the criteria tested by the bypassed test. Any one of the one or more tests described above. 82. The method of claim 78, wherein each of the one or more tests includes a plurality of engines operable to perform the one or more tests. 83. The method of claim 82, wherein the security engine is operable to distribute testing of communications, including received communications, evenly across a plurality of engines according to capabilities of the engines. 84. The method of claim 78, wherein the one or more tests are performed by a plurality of engines operable to perform the tests, the engines operable to reside on an edge protection device or an enterprise client device superior. 85. The method of claim 78, wherein the reputation is retrieved from a reputation server operable to provide reputation information to a plurality of edge protection devices and client devices. 86. The method of claim 78, wherein the reputation is retrieved from a local reputation engine. 87. A computer-implemented method operable to efficiently process communications based on a reputation associated with an external entity, the method comprising: receiving a communication associated with an external entity based on origination or destination information associated with the communication; identifying said external entity associated with the received hypertext transfer protocol communication; deriving a reputation associated with the external entity based on criteria of good reputation and bad reputation associated with the external entity; assigning the communication to one or more query engines selected from a plurality of query engines based on the derived reputation associated with the external entity and the that query the capabilities of the engine; and The one or more query engines are executed on the communication. 88. One or more computer-readable media having software program code operable to efficiently process a communication based on the reputation of an external entity associated with the communication, the software program code comprising: receiving a communication associated with an external entity based on origination or destination information associated with the communication; identifying said external entity associated with the received hypertext transfer protocol communication; deriving a reputation associated with the external entity based on criteria of good reputation and bad reputation associated with the external entity; assigning priority to the communication based on the resulting reputation associated with the external entity; One or more tests are performed on the communication according to the priority assigned to the communication. 89. A computer-implemented method operable to process communications based on a reputation associated with an external entity, the method comprising: receiving a communication associated with an external entity based on origination or destination information associated with the communication; identifying the external entity associated with the received communication; deriving a reputation associated with the external entity based on criteria of good reputation and bad reputation associated with the external entity; A processing path is assigned to the communication based on the derived reputation associated with the external entity. 90. A reputation-based connection suppression system for voice over internet protocol telephony communications, the system comprising: a communication interface operable to receive a voice over internet protocol connection request associated with an external entity prior to establishing a connection between the external entity and a protected network associated with the communication interface; a reputation engine operable to derive a reputation associated with said external entity; and A connection control engine operable to deny the voice over internet protocol connection request to the protected network based on the derived reputation of the external entity associated with the voice over internet protocol connection request. 91. The system of claim 90, wherein the reputation engine derives the reputation of the external entity from an aggregation of reputable criteria and unreputable criteria associated with the external entity. 92. The system of claim 90, wherein the connection control engine prevents entities with a bad reputation from making connections to the protected network. 93. The system of claim 92, wherein said reputable entity is operable to attempt to send Voice over Internet Protocol telephony communications to said protected network in an attempt to create a conflict with said protected network for illegal activity. Pre-Voice-over-Text-Internet-Protocol connection and utilizing said Pre-Voice-over-Text-Internet-Protocol connection. 94. The system as claimed in claim 90, wherein said communication interface is further operable to receive a short message service connection request, and said connection control engine is operable to communicate with the short message service that initiated the short message service connection request The reputation associated with the entity to reject the SMS connection request. 95. The system of claim 90, further comprising a message query engine operable to examine the content of communications initiated from the external entity to determine whether the external entity uses a Voice over Internet Protocol telephony connection . 96. The system of claim 90, wherein the reputation engine is a reputation server operable to receive reputation queries from the connection control engine and provide the resulting reputation to the connection control engine. 97. The system of claim 96, wherein the reputation server derives the reputation of the external entity by aggregating a plurality of partial reputations associated with the external entity, the plurality of partial reputations being determined by a plurality of Provided by the local reputation engine. 98. The system of claim 90, the connection control engine to include a policy against which the reputation is compared to determine whether to allow the Voice over Internet Protocol telephony connection request. 99. The system of claim 98, the policy defining one or more categories of external entities to which Voice over Internet Protocol telephony requests are allowed. 100. The system of claim 90, the connection control engine operable to reduce quality of service for any connection received from an external entity with a poor reputation and to maximize quality of service for any connection received from an external entity with a good reputation . 101. The method of claim 90, further comprising: receiving a plurality of simultaneous connection requests; correlating the simultaneous connection requests to determine that the requests comprise an attack; and updating a or more reputations associated with the entities to cause suppression of the plurality of connection requests. 102. The method of claim 90, further comprising deriving a reputation associated with the external, the reputation indicating the external entity's reputation for participating in a denial-of-service attack, wherein the reputation for participating in a denial-of-service attack is based on data from a telephone handset An input or policy triggers the connection control engine to immediately suppress connections. 103. The method of claim 90, wherein a connection is requested to a device on the protected network, the device comprising a mobile location aware device. 104. A reputation-based connection suppression system for short message communication, the system comprising: a communication interface operable to receive a short message service connection request associated with an external entity prior to establishing a connection between said external entity and a protected network associated with said communication interface; a reputation engine operable to obtain a reputation associated with said external entity; and A connection control engine operable to deny the short message service connection request to the protected network based on the derived reputation of the external entity associated with the short message service connection request. 105. The system of claim 104, wherein the reputation engine derives the reputation of the external entity based on an aggregation of reputable criteria and unreputable criteria associated with the external entity. 106. The system of claim 105, wherein the connection control engine prevents entities with a bad reputation from making connections to the protected network. 107. The system of claim 106, wherein said reputable entity is operable to attempt to send Short Message Service communications to said protected network in an attempt to create a prior relationship with said protected network for illegal activity. A text short message service connection and utilizes said previous text short message service connection. 108. The system of claim 104, further comprising a message query engine operable to examine the content of communications initiated from the external entity to determine whether the external entity is connected using a Short Message Service. 109. The system of claim 104, wherein the reputation engine is a reputation server operable to receive reputation queries from the connection control engine and provide the resulting reputation to the connection control engine. 110. The system of claim 109, wherein the reputation server derives the reputation of the external entity by aggregating a plurality of local reputations associated with the external entity, the plurality of partial reputations being composed of a plurality of local reputations engine provided. 111. The system of claim 104, wherein the connection control engine includes a policy against which the reputation is compared to determine whether the voice over internet protocol connection request is allowed. 112. The system of claim 111, wherein the policy defines one or more categories of external entities to which Voice over Internet Protocol telephony requests are allowed. 113. A method of reputation-based connection suppression comprising the steps of: receiving a voice over internet protocol telephony connection request, the voice over internet protocol telephony connection request being related to an external entity; querying a reputation engine for reputations associated with said external entity; Comparing the reputation to policies associated with the protected corporate network; Allowing the connection request is based on determining that the reputation of the external entity related to the voice over internet protocol connection request complies with the policy. The connection request is suppressed based on a determination that the reputation of the external entity associated with the voice over internet protocol connection request does not comply with the policy. 114. A method of reputation-based connection suppression comprising the steps of: receiving a connection request requesting a connection between an external entity and the protected enterprise network; querying a reputation engine for a reputation associated with the external entity, the reputation comprising an aggregation of reputable and reputable criteria associated with the external entity; comparing the reputation to policies associated with the protected corporate network; Allowing the connection request is based on determining that the reputation of the external entity related to the voice over internet protocol connection request complies with the policy. The connection request is suppressed based on a determination that the reputation of the external entity associated with the voice over internet protocol connection request does not comply with the policy. 115. A reputation based firewall comprising: a firewall operable to receive a data packet destined for a protected network and determine the handling of the data packet in accordance with a security policy associated with the protected network, the security policy including at least one rule on the reputation of an associated external entity; a reputation engine operable to determine the external entity associated with the data packet and provide a reputation to the firewall based on the determination of the external entity; and The processing step includes allowing the data packet to enter the protected network or denying the data packet to enter the protected network. 116. A system comprising: a security control interface operable to generate a plurality of security control representations, each of the plurality of security control representations operable to control a plurality of security settings associated with the protected entity; and a policy control interface operable to generate a plurality of policy control representations, each of the plurality of policy control representations operable to control a plurality of policy settings associated with the protected entity; A filtering module operable to filter one or more communication flows according to the plurality of security settings and according to the plurality of policy settings. 117. The system of claim 116, wherein the security control representations include a plurality of security slider representations in a plurality of security categories, the security slider representations operable to control of the security settings. 118. The system of claim 117, wherein the plurality of security categories include two or more of a virus category, a phishing category, a worm category, or a Trojan horse category. 119. The system of claim 118, wherein the plurality of security control representations are each operable to adjust threshold sensitivity for an associated one of the security settings. 120. The system of claim 119, wherein the threshold sensitivity includes a level of similarity between communication flow characteristics and characteristics associated with the security category. 121. The system of claim 117, wherein the policy control representations include a plurality of policy slider representations in a plurality of policy categories, the policy slider representations operable to control The policy setting for the . 122. The system of claim 121, wherein the plurality of policy categories includes two or more of a spam category, a content category, a spyware category, or a mass mailing category. 123. The system of claim 122, wherein the plurality of policy control representations are each operable to adjust threshold sensitivity for an associated one of the policy settings. 124. The system of claim 123, wherein the threshold sensitivity includes a level of similarity between communication flow characteristics and characteristics associated with the policy category. 125. The system of claim 116, wherein the protected entity is one of a computing device, a communication device, a mobile device, or a network. 126. The system of claim 116, wherein the security control interface and the policy control interface are controlled by an administrator. 127. The system of claim 41, wherein the security control interface and the policy control interface are controlled by an end user. 128. The system of claim 127, wherein the security control interface includes a plurality of ranges associated with the plurality of security control representations, the security control setting being operable to be adjusted within the ranges. 129. A computer implemented method comprising: Receive multiple ranges from the admin; providing a user with a security control interface comprising a plurality of security control representations associated with a security control, each security control mechanism comprising an associated scope from among the plurality of scopes, the associated scope defining minimum and maximum settings associated with respective security controls; receiving a plurality of security control settings from the user via the security control interface; adjusting a plurality of thresholds associated with a plurality of control settings received from the user, the plurality of thresholds being associated with tolerances for categories of possible security breaches; and Communication flows from protected entities associated with the user are filtered according to the plurality of thresholds. 130. The system of claim 129, wherein the security control representations include a plurality of security slider representations in a plurality of security categories, the security slider representations operable to control of the security settings. 131. The system of claim 130, wherein the plurality of security categories include two of a virus category, a phishing category, a worm category, a Trojan horse category, a spam category, a content category, a spyware category, or a mass mailing category. or more. 132. The system of claim 131, wherein the plurality of security control representations are each operable to adjust threshold sensitivity for an associated one of the security settings. 133. The system of claim 132, wherein the threshold sensitivity includes a level of similarity between communication flow characteristics and characteristics associated with the security category. 134. The system of claim 129, wherein the protected entity is one of a computing device, a communication device, a mobile device, or a network. 135. One or more computer-readable media having software program code operable to effectuate filtering conditioning of incoming and outgoing communication streams, the software program code comprising: Receive multiple ranges from the admin; providing a user with a security control interface comprising a plurality of security control representations associated with a plurality of security control settings, each security control mechanism comprising an associated scope from the plurality of scopes, the associated Associated scopes define minimum and maximum settings associated with respective security controls; receiving input from the user through the security control interface, the input requiring adjustment of the plurality of security control settings; adjusting a plurality of thresholds associated with a plurality of control settings received from the user, the plurality of thresholds being associated with tolerances for categories of possible security breaches; and Communication flows from protected entities associated with the user are filtered according to the plurality of thresholds.

Images