An improvement of Intrusion Detection System using HCI - Essay Example

Topic: An improvement of Intrusion Detection System using HCI User Profile With the wide use of computer systems, security management has gained much interest. People use Intrusion Detection System (IDS) applications as assistant tools to detect illegal activities that will cause damage to their computer systems or networks. In the last few years, a variety of approaches have been taken to develop IDS to better serve different sectors: education, research, business, healthcare, and government, etc. In each area, IDS users could take many forms: network/system security specialists who are dedicated to identifying attacks, network/system administrators who detect intrusions as a part of their job, computer system owners who want to keep their systems safe. Network/system specialists and administrators mostly know more about computer networks and systems than regular computer system owners. Some IDS users may have different duties than others. Therefore the time and effort required to detect attacks may not be the same. IDS users can be categorized from two perspectives: (1) their knowledge about network/system security management; and (2) the time and effort that they could put into intrusion detection. From the first perspective, different knowledge levels divide users into advanced, intermediate, and novice levels. From the second perspective, we see them as three types: keen users, regular users, and casual users. User levels by knowledge Advanced users: have good experience and deep understanding of computer network/system security management. Intermediate users: have some experience and knowledge of computer network/system security management. Novice users: barely have experience and knowledge of computer network/system security management. User levels by work effort Keen users: constantly and consistently use IDS to detect attacks, i.e. use IDS several hours a day. Regular users: follow a timetable to use IDS, i.e. spend a few minutes to check attacks every morning before work begins. Casual users: follow no definite routine, i.e. check intrusion activities when attacks happen. General User Tasks An IDS interface is expected to support numerous actions. Generally, the interface shall apply both graphs and text to help present information. SnortReader shall support adaptable functionality, which means that users are able to change its look and the behavior according to their needs. Another important point is that SnortReader shall provide real-time intrusion status information and enable users to locate intrusions quickly and accurately. All user actions are divided into two types: configuration related and data-navigation related. General configuration related tasks include operations like changing Snort engine settings, editing Snort signatures and modifying interface settings. Data navigation related tasks are comprised of actions such as routine checks of intrusion status; attack searches by particular alerts, or alert searches by specific conditions. Configuration Related Tasks Modify Snort configuration files — most Snort settings are stored in a configuration file. Edit signature files — Snort is a rule-based IDS application. It generates alerts when there are network activities that match predefined rules in signature files. Users need to modify signature files to keep the Snort engine capturing intrusions as they desire. Set the format of alert information to be displayed — user interests may vary from time to time in alerts. Users may want to change the representation of alert messages as needed. Start/stop Snort application — Snort does not support runtime interactions. Users need to stop and restart to have new settings take effect. Data Navigation Related Tasks View overall intrusion status — SnortReader shall give users a quick view of alerts on monitored networks. Any alert may be a potential intrusion causing big damage to networks/systems. The interface needs to keep users updated on alert information in real-time. Locate alerts of interests — this operation plays a major role in the interface. Through SnortReader, users need to look through generated alerts to identify actual intrusions. View raw traffic data — Snort generates readable alert messages. In order to understand the complete situation, users need to look at the original traffic data on which alert messages are based. Goal Setting The overall requirements for SnortReader are: (1) allow users to locate intrusions among Snort alerts in a short time; (2) allow users to change the behavior of the interface; and (3) provide help information to identify intrusions and how to use the interface. The false-positive rate of Snort is very high: according to Kayacik & Zincir-Heywood (2002), only less than 1% of Snort alert messages are accurate. A search tool that can quickly find interested data and allow users to separate alerts by a variety of key attributes is very necessary. The interface shall provide a search tool that will accept time, network, and system-relevant numbers as factors to perform searches. Such a tool shall also be available anytime in the use of the interface. In addition to text messages, graphs should be available to help users acquire intrusion information. Colors and visual shapes shall be applied to assist in describing situations because visual perception is one of the factors that affect a users feeling about the interface. Since this varies from one person to another, users shall be able to change the shapes or colors of visual objects. For example, if we use color to indicate the alert level, many people agree that red is the most serious level. However a small portion of people may feel more comfortable using blue for the highest alert. In situations like this, we can use red as the default color for the highest level and provide an interface to allow users to set it to any other color. SnortReader should contain online help that will explain network security management knowledge and provide the guidance in using SnortReader. Sometimes users were stuck with applications because they did not know how to continue the ongoing process. Users either did not understand the scenes they saw or did not know what steps to take. This may have been due to unfamiliarity with the application or a lack of knowledge to solve the problem. To support multiple remote users, SnortReader will be a Web application. Users should be able to access the interface through HTTP call from any computer that has access to the Internet. Conceptual Design SnortReader shall provide users with entries to perform tasks listed above. These entries make user tasks organized and simplified. We divided entries into three categories: (1) navigation entries, (2) configuration entries, and (3) help entries. (1) Navigation entries Display overall alert status — it will allow users to see potential intrusion status of monitored networks and provide users with information namely: the overall number of generated alerts, the time the activity happened to cause the earliest or the most recent alert, the most serious alert being generated, and the time data is refreshed. Display the running status of Snort — it will show users Snort running information such as if Snort is running, when Snort is stated, etc. Refresh displayed data — it will allow users to update alert information anytime other than waiting for its auto-updating. SnortReader continuously updates alert information with a configurable time interval. However, only status information gets refreshed. Result data of user operations will not be overridden. A compact alert searching tool — it will accept a variety of criteria, in any combination, to search alert messages of interest. Certain criteria could be any type of information used to form an alert message. Decide the display of alert search result — it will allow users to choose the format of alerts and where to display it. If possible, the sorting functionality will be provided to help organize displayed alerts. For example, users can sort alert messages by the time they were generated. (2) Configuration entries List or edit Snort configuration files — it will allow users to view or modify directives in the configuration file. These directives determine the behavior of Snort application. Manage Snort rule files — it will allow users to list, created, modify, or delete Snort rule files. Snort rule files tells Snort what traffic is harmful. Start/Stop Snort — it shall toggle the active state of the Snort application on the monitored networks as desired. Set time interval of status update — it will allow users to control the alert status update. Set the default alert display — it will allow users to control the format of alert messages, order of them, and where to show them - in the work area or a new window. Change default status levels — it will allow users to set alerting levels according to their needs. For example, if users did not run a web service on the monitored network, they should be able to exclude web service related alerts from any levels. In other words, discard them. (3) Help entries User manual — it will tell users how SnortReader work and how to use it. Users shall be able to access it anytime and in any stage of an operation. Help to security management — it will give users network security knowledge relevant to the current information they see. Historical information — it will tell users what happened and what they have done. Quick help — it will give direct instruction to users about how to continuing their work. User Interface Design SnortReader is a web application. Users are able to use it through browsers. Both entries to perform user tasks and data information are to be put into web pages. SnortReader pages consist of three parts: header, tool panel and worksheet. We believe such page construction will help users find and recognize entries to perform tasks. It will allow different types of information to be displayed separately. In the page, result data and actions taken to get them are segregated. Then every time new data is displayed users will not lose track on how it is obtained. As well they are able to initiate the next action when they are looking at the previous action result. Header Header displays the name of SnortReader. Because it will be appearing on every SnortReader page, a user manual entry will be created in this area. It will allow users to reach the help anytime in the middle of any process. Tool Panel Tool panel is to be a centralized area of task entries. It will be displayed on every web page. From tool panel users can find task entries or configuration entries that they need to carry out their work. Along with task entries, there shall be entries to quick help. Tool panel will be the core of the user operations. It is organized as three sections: Status Display, Quick Alert Search, and General Operations. Status Display is the area showing user an overall view of intrusion on the monitored network. A graphical object (alert status map) is used to represent the whole network under monitoring. A color schema is used to reflect the alert status. Every color is to be associated with an alert level, which can be set by users. In order to avoid the confusion at which color means which alert level, legend information is displayed along with the visual object. To further help users read the alert status, there is an entry to online help that tells users how to read the alert status. Next to the status display, an entry is placed to lead users to a page to update alert level settings. In addition to the graphical object, the status display area will have descriptive text to tell the detail of intrusion in general such as the total number of alerts, the earliest and latest time of alert generated, when the displayed data is last updated, and if Snort is running. Alert Search will support user finding particular alert messages with given criteria, which are componential elements used to form Snort alerts. Intrusion Detection Working Group of IETF (Curry & Debar, 2002) suggests that alert data shall contain following information: Analyzer - identification information for the analyzer (Snort component) that originated the alert. Create Time - the time the alert was created. Detect Time - the time the event (s) leading up to the alert was detected. Analyzer Time - the current time on the analyzer. Source - the source (s) of the event (s) leading up to the alert. Target - the target (s) of the event (s) leading up to the alert. Classification - the name of the alert, or other information allowing the manager to determine what it is. Assessment - information about the impact of the event, actions taken by the analyzer in respond to it, and the analyzers confidence in its evaluation. Additional Data - information included by the analyzer that does not fit into classes above. SnortReader will allow users to initiate an alert search with following key values: the classification of the alert, the detect time of the alert, the source of the alert, the target of the alert, the relevant port of the alert, and the level of the alert. Except for the classification, other key values can be given as value pairs that define the range of values to search. E.g. using two detect time values for a search, the result will contain alerts detected from the smaller value time to the bigger value time. General Operations area contains entries to user operations relative to the intrusion detection. Besides the quick search above, users can start alert navigation here. This area also contains entries for users to re-configure Snort application or SnortReader. Worksheet SnortReader separates user operations from general status information and task entries. Certain type of information is always to be displayed in certain areas. The word of Worksheet pretty much tells us what it is used for - it is where users view alert messages, configure Snort, or change the behavior of the interface. We know that security managers wish to be aware of the network condition all the time. To have a designated area for performing operations and showing temporary results allows them to keep an eye on the entire network - from Tool Panel - while conducting an operation. They can see change of intrusion status during any process and make decisions like whether response to the new problems or continue the current work. For example, when a user is trying to find alert messages that cause serious level alert, the alert level could escalate to extremely serious because of newly detected activities. Therefore, the user must choose either continuing the current search or starting a new search for the higher-level alert. In operation screen, buttons, checklists and select lists will be provided to avoid user-typing mistakes. Some operations can be completed by mouse-clicks. For unpredictable user-inputs, such as IP address, will be validated before being used. For example, a valid IP address is in format n.n.n.n where n is integer from 0 to 255. SnortReader will tell the error when users type in an IP address 10.10.10.300. SnortReader will allow users to associate alert messages to physical computer systems/networks. When users choose to navigate alerts in graphical form, alert messages are mapped into computer systems/networks that they are from/to. The graph will be consists of a number of unit graphs, which represent sub-network blocks relative to generated alerts. Every unit graph uses the same color schema as used for alert status map to report the highest alert level. According to their needs, users are able to change the network size to report on. Alternatively, they can get comfortable granularity by changing the unit size. Along with graphical objects, the graph uses text as navigation aid. For example, individual unit graphs lacks of identifiability. It is the IP address that associates abstract objects to physical systems/networks. Users can see IP addresses by point mouse cursor over unit graphs. Implementation SnortReader is a web application. With a computer station connected to the network, users can access it by opening a web browser, where users send requests and receive results. System setups Operation System — Red Hat Linux kernel 7.0 Web Server — Apache HTTP Server 2.0 Compatible browsers — Microsoft Internet Explorer Browser 5.0+ Security issues Since The Apache HTTP Server has a good record for security and a developer community highly concerned about security issues ... (Apache Group, 2003), we will rely on Apache HTTP Servers security mechanism. User access control — a user group will be created to allow the access to SnortReader. A web user can use the SnortReader only when it is in the group and passes the authentication. Data definition Timestamp — a character string used to represent the time when events happen. The standard format is YYYY/MM/DD HH(24):MI:SS.SSSSSS IP Address — there are two standard formats for it. One is an unsigned long type integer. It is used to for IP calculation. Another is a character string used to display IP addresses. The standard format is nnn.nnn.nnn.nnn where nnn is a number between 0and255inclusive. Alert Classification — the name of the alert, it is a character string used to name an alert type. Alert Assessment — the impact of the activity or the severity of the alert defined by Snort, it is an integer number. Rule — the signature file that identifies activity, it consists of Alert Classification and Alert Assessment. Port — the network port that activities are from/to, it is an integer number between 0 and 65535 inclusive. Source — the origin of the activity, it consists of IP address and Port. Target — the destination of the activity, it consists of IP address and Port. Alert — the aggregation of alert information, it consists of Rule, Source, Target, and Timestamp. Alert Level — user defined severity of the activity, it is an integer number from 1 to 3 (users can define as many level as they want, but this prototype application only provide 3 levels). Color — used for the alert level, it is a character string. The standard format is xxxxxx where x is between 0 and F inclusive. Status Level — there are three levels: Level-1, Level-2, and Level-3. Each one of them consists of an Alert Level and a Color. Alert List — a linked-list of Alert type, it is used to store a list of alerts. Main Methods Definition getRequest — it reads HTTP request and retrieves application request from it. readAlert — it reads in Snort data and stores them in an Alert List. reportStatus — it returns two types of information - application status and alert status. By calling a shell program, it retrieves running status of Snort and SnortReader. reportStatus searches for alert messages with the highest Alert Level in the Alert List. It generates the status map based on the search result.searchAlert — it reads Snort data and returns result. searchAlert takes Status Level, Rule, Timestamp, Source, Target, and Port as input. Except for Rule, others are value pairs that allow users to search by ranges. When there is an input field not given, it means that the method can ignore this condition and accept anything for it. Therefore, if there is no input to the method, it will return all alert messages generated by Snort. sortAlert — it sorts the alert messages. The method uses 5 keywords - Rule, Level, Source, Target, and DetectTime. Here, Level is Alert Level of the activity and DetectTime is the time that activity was detected by Snort engine. All alert messages can be sorted by one of these key information in ascent/descent order. showAlertText — it displays generated alerts in standard text format. When showing the detail of one alert, it prints out the data packet that leads to the alert. When showing a list of alerts, key values - rule, level, source, target, and detecttime - are used to identify each one of them. showAlertGraph — it displays generated alerts in a topology map. All alerts are categorized into network blocks (the size can be changed). Only network blocks that have alert generated will be displayed. In addition, the highest alert level will be used to represent the block. configApp — it changes directives in Snort or SnortReader configuration files in terms of user requests. buildPage — this method creates result pages for end users. According to user requests, it reads in templates files and constructs web pages with result data. Evaluation In order to evaluate this system design an empirical experiment. In so doing, the researcher will apply IDS heuristics by adapting Nielsens general heuristics. The IDS heuristics are specifically designed to serve IDS usability evaluations. Putting together the available features of common IDS applications and feedbacks from some IDS users, we formed IDS heuristics that can help build IDS applications. Besides of identifying usability problems, these rules will hint designers of user-wish-to-have features to increase the efficacy in handling intrusions. We believed that they would serve an important role at usability consideration of IDS development. Although we have seen positive numbers in the heuristic comparison we wanted to get feedback from a wide range of people. SnortReader is a Web-based interface to Snort. It is designed to help users identify pertinent alert messages quickly and accurately. The adaptable feature will allow users to change its behavior to best fit their needs. The development of SnortReader considered the usability problems existing in several common IDS applications. Solutions to these problems were included in the implementation. However, we needed to determine whether the approach provided better result at the end. We wanted to evaluate it through a formal inspection process. SnortSnarf is a Web-based application created to improve the user of Snort. Having both evaluation results of SnortReader and SnortSnarf would give a clear view about whether our work benefits IDS users. Heuristic evaluation (HE) is a widely accepted discount evaluation method for diagnosing potential usability problems in user interfaces. It is economic and very popular with both academic and commercial users. IDS heuristics are developed for a specific application domain. Therefore, general usability evaluation guidelines (Nielsen, 2003) are also applicable for them. Referring to the methodologies used by Baker, Greenberg & Gutwin (2002) and Mankoff et al. (2003) in developing specialized heuristics for groupware and ambient displays respectively, we designed an experiment to both examine our IDS heuristics and evaluate SnortReader. We recruited 12 computer professionals. Some of them were human-computer interface (HCI) experts and some of them were network security experts. Their experience and knowledge varies. With the given materials and instructions, they collected information from evaluations. We put together acquired information, and drew the conclusion on our IDS heuristics. Participants There have been different views on what number of participants is necessary to conduct an effective evaluation between Nielsen & Landauer (1993) and Woolrych & Cockton (2001). We will recruit twelve participants who are user experts from two fields: network security management (NSM) and human-computer interaction (HCI). Among them 5 were HCI experts and 7 are network security experts. Because of different background and experience, their knowledge at NSM and HCI may vary. Procedure Participants will be asked to evaluate SnortSnarf and SnortReader using Nielsens and our IDS heuristics. Each one of them completed the evaluation individually, and was allowed to spend as much time as needed to finish the test. Before the evaluation, every participant will be given a package through the email. The package includes a consent letter, a brief introduction to our project and the instruction to conduct the evaluation, a result sheet to record results, and materials needed in the evaluation. Contact information will also be provided when there was a need to ask questions or reporting problems. The consent letter will be sent as a plain text attachment. Other information will be placed in a web site created for the use of the experiment exclusively. This measure guarantees that every participant will get identical information for the experiment. The experiment package will show participants the objective of our study - find a way to develop better user interface for IDS. And the purpose of this experiment - to evaluate IDS heuristics; to evaluate SnortReader. In order to help participants conduct the evaluation, the package will include reference to heuristic evaluation. Other detail information about the experiment will be given in the website where the evaluations will be carried out. On the introduction page of the website, participants would be provided a list of tasks they ought to complete in both SnortSnarf and SnortReader. Participants could go to the actual websites of SnortSnarf and SnortReader by clicking the links on the introduction page. Any usability problems identified in the evaluation will be requested to be recorded in a given result sheet. Along with the result sheet, there will be a description of how to record evaluation results. Separately as Baker, Greenberg & Gutwin (2002) did in their research, I will conduct an informal review using Nielsens methodology (1990) to generate a master list of issues and each one of them will be rated with relevant severity (from 1 to 5). Severe issues - ratings of 4-5 on a 5-point scale – will be problems that might substantively discourage users from using IDS. Moderate issues - ratings of 2-3 – will be ones that might decrease the speed or accuracy of identifying intrusions. Minor issues - ratings of 1 – will be problems caused by the misunderstandings about how applications will work or the restrictions of web pages. All identified problems would be rated upon the severity from participants perspectives. It will allow me not only to see the problems discovered in the experiment but also to be aware of what kind of problems which are more critical to IDS applications. Personal Reflection and Future Work The main objective of this project is to find an effective way of improving IDS. I have attempted to achieve the goal from HCI perspective and hold the potential of being effective as it combines both theoretical and practical knowledge. In the early stage of my work, I conducted a survey on the state of the network security management. I discovered that the poor situation of security management was due to the lack of suitable tools. I reviewed a few IDS which were widely used. Usability issues were major concerns that restrained network managers from using them. Although there were a lot of research groups working on improving IDS, all of them (as we knew) were focusing on the side of improving the detection engine. I do not suggest that improving the ability of detecting intrusions is not important. I think that with improved usability there will be more network professionals starting to use IDS as a regular tool to monitor their networks. In such way, IDS designers will be able to receive more requests and feedbacks on their systems. I believed that providing a good tool to IDS designers will make their products have fewer problems. A suitable heuristic set will help designers alleviate many usability issues during the development phase. General heuristics can be applied to any software buy they are focused on systems with clearly defined user tasks. Although the principles of heuristic evaluation can be applied to all interface software, general heuristics are not necessarily suitable for the specific problem domains. The major difference between evaluating IDS and evaluating applications of other domains derives form the types of users and the tasks those users need to undertake. Based on Nielsens heuristic set, I plan to develop my IDS heuristics which are specifically designed for IDS applications. In experimental evaluations, both Nielsens and our IDS heuristics were able to identify the usability problems caused by the interface designs. To this end, the proposed set of heuristics identified more specific violations, which I believe, in return, can improve the design and development process of IDS. I feel that this will also be proved in my experiment. References Apache International (2006). Apache HTTP Server documentation. Retrieved June 1, 2007, from http://httpd.apache.org/docs/2.2/ Baker, K., Greenberg, S. & Gutwin, C. (2002). Empirical development of heuristic evaluation methodology for shared workspace groupware, in Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work, 96-105, New Orleans, Louisiana, USA. Curry, D. & Debar, H. (2003). Intrusion Detection Message Exchange Format: Extensible Markup Language (XML) Document Type Definition. Retrieved June 1, 2007, from http://xml.coverpages.org/draft-ietf-idwg-idmef-xml-01.txt Kayacik, G. & Zincir-Heywood, A. N. (2002). A case study of three open-source security management tools. In the Eight IFIP/IEEE International Symposium on Integrated Network Management, 101-105, Colorado Springs, USA. Mankoff, J., Dey, A. K., Hsieh, G., Keintz, J., Lederer, S. & Ames, M. (2003). Heuristics evaluation of ambient displays, in Bellotti, V., Erickson, T., Cockton, G. & Korhonen, P., ACM Conference on Human Factors in Computing Systems, 169-176, Ft. Lauderdale, FL, USA. Nielsen, J. (n.d.) , Heuristic Evaluation. Retrieved June 1, 2007, from http://www.useit.com/papers/heuristic/. Nielsen, J., Landauer, T. K. (1993). A mathematical model of the finding of usability problems, in Proceedings of ACM INTERCHI 1993, 206-213. Woolrych, A. & Cockton, G. (2001). Why and when five test users arent enough, in Proceedings of IHM-HCI 2001 Conference, 2, 105-108. Read More