Abstract:
Semantic networks are generated to model the operational behavior of an enterprise network to provide contextual interpretation of an event or a sequence of events that are observed in that specific enterprise network. In various illustrative examples, different semantic networks may be generated to model different behavior scenarios in the enterprise network. Without the context provided by these semantic networks malicious events may inherently be interpreted as benign events as there is typically always a scenario where such events could be part of normal operations of an enterprise network. Instead, the present semantic networks enable interpretation of events for a specific enterprise network. Such interpretation enables the conclusion that a sequence of events that could possibly be part of normal operations in a theoretical enterprise network is, in fact, abnormal for this specific enterprise network.

Description:
BACKGROUND 
       [0001]    Although the Internet has had great successes in facilitating communications between computer systems and enabling electronic commerce, the computer systems connected to the Internet have been under almost constant attack by hackers seeking to disrupt their operation. Many of the attacks seek to exploit vulnerabilities of the application programs or other computer programs executing on those computer systems. Different vulnerabilities can be exploited in different ways, such as by sending network packets, streaming data, accessing a file system, modifying registry or configuration data, and so on, which are referred to as security events. Developers of applications and administrators of enterprise networks commonly go to great effort and expense to identify and remove vulnerabilities because if a hacker identifies a vulnerability which is exploited, it can often result in significant negative consequences. 
         [0002]    This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above. 
       SUMMARY 
       [0003]    Semantic networks are generated to model the operational behavior of an enterprise network to provide contextual interpretation of an event or a sequence of events that are observed in a specific enterprise network. A semantic network is a form of knowledge representation using a directed graph comprising vertices which represent concepts, and edges which represent relationships between the concepts. In various illustrative examples, different semantic networks may be generated to model different behavior scenarios in the enterprise network. Without the context provided by these semantic networks malicious events may inherently be interpreted as benign events as there is typically always a scenario where such events could be part of normal operations of an enterprise network. Instead, the present semantic networks enable interpretation of events for a specific enterprise network. Such interpretation enables the conclusion that an event sequence of events that could possibly be part of normal operations in a theoretical enterprise network is, in fact, abnormal for a specific enterprise network. 
         [0004]    This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0005]      FIG. 1  shows an illustrative enterprise network environment in which the present semantic network-based intrusion detection may be implemented; 
           [0006]      FIG. 2  shows a current method for network-based intrusion detection in an enterprise network; 
           [0007]      FIG. 3  shows an illustrative manner of characterizing an enterprise network using flat, fixed attributes; 
           [0008]      FIG. 4  shows an illustrative general semantic network; 
           [0009]      FIGS. 5 and 6  show illustrative vertices and edges that may be used specifically in semantic networks having applicability to enterprise networks scenarios; 
           [0010]      FIG. 7  shows a flowchart of an illustrative method for enrichment of an attributes set used for interpreting events occurring in the network; 
           [0011]      FIG. 8  shows vertices and edges used in a first illustrative scenario involving a reporting semantic network which models a reporting structure in an enterprise; 
           [0012]      FIG. 9  shows the reporting semantic network; 
           [0013]      FIG. 10  shows a table that indicates examples of use of the reporting semantic network to identify abnormal e-mail messages; 
           [0014]      FIG. 11  shows vertices and edges used in a second illustrative scenario involving a logon times semantic network which models the likelihood a given user will logon to an enterprise network at a given time; 
           [0015]      FIG. 12  shows the logon times semantic network; 
           [0016]      FIG. 13  shows a table that indicates examples of use for the logon times semantic network to identify abnormal logon times; 
           [0017]      FIG. 14  shows vertices and edges used in a third illustrative scenario involving a possession semantic network which models the connection between users, machines, and domains in an enterprise network; 
           [0018]      FIG. 15  shows the possession semantic network; and 
           [0019]      FIG. 16  shows a table that indicates examples of using the possession semantic network to identify abnormal logons of users to machines and/or domains. 
       
    
    
       [0020]    Like reference numerals indicate like elements in the drawings. 
       DETAILED DESCRIPTION 
       [0021]      FIG. 1  shows an illustrative enterprise network environment  100  in which the present semantic network-based intrusion detection may be implemented. In the environment  100 , an enterprise network  105  includes various users  112   1,2 . . . N  who are associated with machines  116   1,2 . . . N  such as personal computers (“PCs”), workstation, laptops and other types of information technology (“IT) assets. While the users  112  are shown as being mapped on a one-to-one basis in  FIG. 1 , this mapping is illustrative as users  112  may often be associated with more than one machine  116 , and vice versa. 
         [0022]    The enterprise network  105  is coupled to external networks to enable the users  112  and machines  116  to connect to various external resources  121   1, 2, N  that may include web sites, databases, e-mail services, and the like. A firewall  125  and network intrusion detection system (“NIDS”)  131  are utilized, this example, to provide security protection for the users  112  and machines  116  in the enterprise network  105 . The firewall  125  is typically located on the perimeter of the enterprise network  105  and monitors traffic flowing between the enterprise network and the external resources  121 . The firewall  125  will commonly permit or block traffic in accordance with a rule set or policies. 
         [0023]    The NIDS  131 , if conventionally arranged, would perform intrusion detection to identify actions or events occurring in the enterprise network  105  that may be associated with a malicious attempt to compromise the confidentiality, integrity, or availability of a user  112  or machine  116  in the enterprise. While intrusion detection is shown as being performed at the network level (i.e., network-based intrusions detection) in  FIG. 1 , it may also be performed at the machine level (i.e., host-based intrusion detection). 
         [0024]    As shown in  FIG. 2 , intrusion detection is conventionally based on two primary approaches: a) checking events against a list of predefined rules ( 205 ); and b) identifying anomalous behavior ( 210 ). Conventional intrusion detection systems are known to have a high rate of false-positives (i.e., benign events that are incorrectly identified as intrusive). Efforts to reduce false-positive rates usually introduce a high rate of false-negative (i.e., intrusive events that are not detected as such). As shown in  FIG. 3  current predefined rules characterize an enterprise network using flat, fixed attributes or metrics (as indicated by reference numeral  302 ) which are generally insufficient to enable the NIDS to separate “good” sequences of events from “bad” ones. 
         [0025]    By comparison to the conventional use of flat, fixed attributes, the present semantic networks for intrusion detection uses an enriched set of attributes. A semantic network is often used as a form of knowledge representation. It is typically a directed graph consisting of vertices which represent concepts and edges which represent semantic relationships between the concepts. A generalized example of a semantic network  400  is shown in  FIG. 4 . As shown, for example, both the vertices “Motorcycle”  406  and “Automobile”  409  have the semantic relationship, or edge, “is a” with the vertex “Vehicle”  412 . 
         [0026]    In the present case,  FIGS. 5 and 6  show illustrative vertices and edges that may be used specifically in semantic networks having applicability to enterprise networks scenarios. Thus, for example, each machine  116  in the enterprise network  105  in  FIG. 1  may be a vertex in the semantic network. Thus, a machine “X” can have an edge “is a” to the vertex “Desktop” (as indicated by reference numeral  500  in  FIG. 5 ) or an edge “is a” to the vertex “Server” (as indicated by reference numeral  600  in  FIG. 6 ). 
         [0027]      FIG. 7  shows a flowchart of an illustrative method  700  for intrusion detection that may be performed using a semantic network. The steps include enrichment of the attributes set used for intrusion detection ( 705 ) by modeling various behaviors of an enterprise network as a semantic network ( 710 ) which may be performed through the application of one or more algorithms to generate the semantic network ( 715 ). Once the model is built, it may be then used for anomaly detection ( 720 ) through interpreting events occurring in the network ( 725 ) using enterprise-specific data ( 730 ). 
         [0028]    Generally, application of this method may take into account events that occur in different levels of the enterprise. For example, a machine might indeed by suspicious if it sends out a lot of data from the network  105  to the external resources  121  and the machine is i) a desktop; ii) this desktop belong to a software developer who typically should not be sending data outside the network  105 ; iii) the origin of the data is a folder that contains sensitive information (e.g., program code of an upcoming product release); and iv) the destination for the data is a public e-mail account. By comparison, a machine that sends out a lot of data will not be deemed suspicious if the machine is i) a server; ii) the e-mail destination is at a legitimate business partner; and iii) the same data was sent to other partners as well. 
         [0029]    The method shown in  FIG. 7  may also generally take into account organization behavior when building attributes that are used for anomaly detection. Semantic networks can be built to model various aspects of such behavior. 
         [0030]    The method  700  may be further illustrated using the scenarios described below. 
         [0031]      FIG. 8  shows vertices and edges used in a first illustrative scenario involving a reporting semantic network which models a reporting structure in an enterprise. Here, a vertex representing a user “X” has an edge “reports to” to the vertex “Y”, as indicated by reference numeral  800 . The reporting semantic network  900  shown in  FIG. 9  uses a tree-like graph to represent the reporting structure of users  112  in the enterprise network  105  that uses a hierarchical arrangement having five levels. In this example, the users  112  are identified by user names (which are sometimes referred to as “aliases”) in the semantic network  900 . The number of edges between vertices represents a “reporting distance” in the hierarchy. Examination of the reporting semantic network  900  will show the following:
       shair reports to urib   ronkar also reports to urib   urib reports to zakiem   The reporting distance between shair and zakiem is 2 (zakiem is in level 3 and shair is in level 1).   The reporting distance between shair and ryanh is 4.         
         [0037]    The reporting semantic network  900  may be used, for example, to identify abnormal e-mail which is assumed to have potential for spreading malicious software (i.e., “malware”). Generally, once a suspicious e-mail is identified, it can be examined more closely to determine if it contains malware in fact. 
         [0038]      FIG. 10  shows a table  1000  that indicates examples of using the reporting semantic network to identify abnormal e-mail messages. An e-mail message from shair to ronkar will not be considered abnormal because these users both report to the same manager urib, so it is probable that they will regularly exchange e-mail. Similarly, as urib is the manager of shair, an email from shair to urib will not be considered as abnormal. 
         [0039]    By comparison, an e-mail from shair to ryanh is considered abnormal as the reporting distance between these users is  4 . E-mails that span such a large reporting distance are extremely rare in the specific case of enterprise  105 . Accordingly, the e-mail from shair to ryanh is suspicious and can be further examined as a source of potential malware, for example. 
         [0040]    An e-mail from shair to alomn will be somewhat suspicious. The common vertex shared by these users is rakeshn at a reporting distance of 3. Shair and alomn are also separated from each other by a reporting distance of 3. Due to this distance, it is unlikely that shair and alomn will have too many things in common. However, the e-mail communication is less suspicious than the e-mail from shair to ryanh described above because both users are at the same level (level 1) in the reporting hierarchy. As a result, there is some expectation that shair and alomn might collaborate from time to time. 
         [0041]    The above reasoning as to why one e-mail is normal but another is suspicious is intended only to be illustrative, and it is emphasized that the reporting hierarchy using a graph to build the reporting semantic network enables such type of reasoning to be formalized and extended, for example, using a computer program. These programs can apply various algorithms to enable semantic networks to be built and used to provide contextual information in an automated manner for a wide variety of intrusion detection scenarios. 
         [0042]    The likelihood of an event (such as an e-mail message being sent between users) being deemed abnormal may also be expressed using a probability. For example, as shown in  FIG. 10 , e-mail can be expressed as “somewhat” or using other terms which indicate some level of uncertainty. The likelihood or confidence of a given identification is termed “Fidelity” here and can be expressed using terms such as “Low”, “Medium”, “High”, etc. Probability may also be more formally expressed using a number between 0 and 1 in some implementations. 
         [0043]    Generally, the detection of abnormal behavior in the enterprise network  105  may be enhanced by cross-referencing between several semantic networks. That is, semantic networks can provide contextual meaning for a variety of behaviors and organizational characteristics of a given enterprise. For example, and not by way of limitations, semantic networks can cover geographic organization (i.e., where users, machines, subnets, domains, etc.) are physically located, project team organization (which users, development groups, support organizations, etc. are involved with a particular project), time-based plans (what is planned to occur in an enterprise and when), and so on. 
         [0044]    Several more illustrative examples of other semantic networks are discussed below. 
         [0045]      FIG. 11  shows vertices and edges used in a second illustrative scenario of a logon times semantic network which models the likelihood a given user will logon to an enterprise network  105  at a given time. As indicated by reference numeral  1100 , a vertex representing a user “X” has an edge representing the probability P YZ  that the user “X” will perform a remote logon to a machine  116  the enterprise network  105  between the times of “Y-Z”. The logon times semantic network  1200  shown in  FIG. 12  uses a graph to represent the probability that the user shair will perform the remote logon during four different six-hour time intervals (i.e., between the hours of midnight and 6:00 am; 6:00 am to noon; noon to 6:00 pm, and then 6:00 pm to midnight). As shown, statistical data that is captured about shair&#39;s remote logon behavior indicate that the probability for these times periods are respectively 0.05, 0.4, 0.4, and 0.15. 
         [0046]    Table  1300  in  FIG. 13  indicates examples of using the logon times semantic network  1200  to identify abnormal logon times. Shair performing a remote logon at 9 am in the morning, is not considered abnormal because this is during the beginning of the workday and shair often logs on during this time period. By comparison, a logon at 3 am is more suspicious. But it cannot be guaranteed that such logon is abnormal and indicative that is may associated with malicious activity because shair has logged in around that same time period in the past, and there could be a project with an upcoming deadline on which shair is working. Accordingly, the fidelity or confidence that the 3 am logon is suspicious is “medium”. If another semantic network covering open projects in the enterprise were built and available, then it could be used as a cross-reference to ascertain whether shair&#39;s remote logon at 3 am could indeed be related to an upcoming deadline. If so cross-referenced, then the 3 am logon could be eliminated altogether as suspicious, for example. 
         [0047]      FIG. 14  shows vertices and edges used in a third illustrative example of a possession semantic network which models the connection between users “X”, machines “Y”, and domains “A” in the enterprise network  105 , as indicated by reference numeral  1400 . The possession semantic network  1500  in  FIG. 15  uses several graphs to show that user savasg users the savasgdev machine in the ntdev domain while users shair and ronkar use several machines each (both desktop and mobile assets such as laptops PCs) that are coupled to the middleeast domain. 
         [0048]    Table  1600  in  FIG. 16  indicates examples of using the possession semantic network to identify abnormal logons of users to machines and/or domains. As shown, shair logging on to his desktop machine shai-desk is not deemed abnormal. Neither would shair logging onto the ron-desk machine as it likely that such logon means that shair is simply dealing with a work item that need to be performed. In addition, if the reporting semantic network  900  is cross-referenced, it would also be known that shair and ronkar are colleagues in the same organization which makes the shair&#39;s logon even less suspicious. Similarly, if a logon times semantic network is arranged to track the frequency of such logons and it is determined that shair is only logging on to ron-desk occasionally, this is further reinforcement that such logons are legitimately work-related and not malicious. 
         [0049]    If shair fails to logon to the shai-desk desktop machine, then suspicion that such events are abnormal increases. The repeated logon failures could potentially indicate that the user attempting to logon is not, in fact, shair and/or shair&#39;s identity has been compromised in some way. As shown in table  1600 , the characterization of the failed logon events uses the term probably (or may be expressed with a Low Fidelity) to reflect the likelihood that shai&#39;s logons are abnormal. 
         [0050]    Using similar reasoning, the probability that the logons are abnormal and merit further investigation increases when shair repeatedly fails to logon to the ronkar-desk machine. Suspicion is increased, for example to Medium Fidelity, because the repeated failures occur on a machine that is not the user&#39;s own. 
         [0051]    If shair attempts a logon to savasgdev, then the likelihood that this event is abnormal is even higher as shair and savasgdev are in two different domains where the usual interaction is very low. The view that such a logon event is abnormal is reflected with High Fidelity, for example, as shown in Table  1600 . 
         [0052]    If shair fails to logon to savasgdev after 10 attempts, then it may be very likely (i.e., Very High Fidelity) that such event is abnormal and could be malicious. Not only are the user and machine in different domains which normally have low interaction, but the inability to logon suggests that the user does not have the correct credentials. 
         [0053]    Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.