* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download doc - itk.ilstu.edu
Survey
Document related concepts
Entity–attribute–value model wikipedia , lookup
Microsoft Access wikipedia , lookup
Oracle Database wikipedia , lookup
Commitment ordering wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Ingres (database) wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Functional Database Model wikipedia , lookup
Relational model wikipedia , lookup
Serializability wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Versant Object Database wikipedia , lookup
Database model wikipedia , lookup
Clusterpoint wikipedia , lookup
Transcript
Why Monitoring Database Application Behavior is the Best Database Intrusion Detection Method Clay Brockman ITK 478 Fall 2007 Introduction Every business uses databases for a variety of reasons. Most of them contain information such as employee IDs, passwords, lists of products or procedures, etc. All of this information is important to the company because it allows the company to keep track of things and allows them to continue to grow and prosper. Because of the value of all of this information, every business must constantly take steps to ensure that their database is secure at all times. The purpose of this paper is to evaluate 2 different types of intrusion detection methods. After explaining each, I will give reasons why I feel that monitoring database application behavior is the best way to detect intrusions. What are intrusions and how do they relate to security? Before being able to select a way to detect intrusions in a database, it’s important to know what constitutes an intrusion and how security needs to be involved. First, it’s important to understand some of the aspects of security. Vieira and Madeira (2005) pointed out that “Security is an integrative concept that includes the following properties: confidentiality …, authenticity …, integrity …, and availability” (p. 350). What they are trying to point out is that security is not one single thing that needs to be considered, but it is comprised of many different things, any of which can cause problems for a company and its database. An example of confidentiality might include an important business process being disclosed to an unauthorized user who could then use it for their own gains. Authenticity relates to the information being real. If someone intrudes into a database, they may be able to put false information into the tables which may cause the company problems. Integrity relates to modifying data. So, as opposed to someone adding false information, an attack on the integrity might include changing existing data such as prices or product availability. Finally, availability would deal with the company not being available to conduct business as usual. Depending on the company, this can cause them to lose many customers or cause their reputation to be hurt. An intrusion is when someone is able to cause one of the above security problems by gaining access to the database. This can come from the person finding out a user ID and password or possibly from an employee in the company opening an email that either intrudes on the database or returns information to the sender that they can use to access the database. Intrusions can typically occur in one of the following ways. The first way is “intentional unauthorized attempts to access or destroy private data” (Vieira and Madeira, 2005, p. 351). An example could be where a hacker or even an unhappy employee is able to gain access to information not usually available to them through a password. The second way is “malicious actions executed by authorized users to cause loss or corruption of critical data” (Vieira and Madeira, 2005, p. 351). Vieira and Madeira (2005) suggested an example of this type of intrusion might be a “system manager that have legitimate access to database servers but should not access database data” (p. 351). So in this case, the user is authorized because he is a system manager that works for the company. But he could cause something to happen to the data in order to hurt the company in some way. The final way is “external interferences aimed to cause undue delays in accessing or using data, or even denial of service” (Vieira and Madeira, 2005, p. 351). As this one states, the intruder would be someone outside the company who tries to slow the company down. Intrusion Detection Methods Now that it is known what constitutes an intrusion and what the security aspects are that the intrusion can affect, it’s important to find ways to detect intrusions in order to make sure the database is protected. A main focus of the research was to reduce the numbers of false positives and false negatives. A false positive is when the detection system reports an intrusion but the action is really a legitimate request (Afonso, et al., 2006, p.37). So a legitimate user sends a request that is perfectly fine, but for whatever reason, the system notifies the administrator that it is an intrusion. Afonso, et al. (2006) claimed that this type of result accounts for 17% of recorded events (p. 37). A false negative is the exact opposite of a false positive. For a false negative to occur, the system will allow a malicious request to pass, identifying it as a legitimate request (Afonso, et al., 2006, p.37). According to Afonso, et al. (2006), this accounts for about 12% of recorded events (p. 37). Monitoring Database Application Behavior This method was developed by José Fonseca, Marco Vieira, and Henrique Madeira. In order to detect an intrusion, this method “adds concurrent intrusion detection to DBMS using a comprehensive set of behavior abstractions representing database activity” (Fonseca, et al., 2006, p. 383). Their idea is that, when a command comes from the user, it will be checked at different levels in order to verify if it is valid or if it is an intrusion. If it’s ok, then it is processed accordingly. If not, the administrator is notified and it is up to them to take action against the threat. The levels the message is checked at are the command level, transaction level, and session level. Fonseca, et al. (2006) wrote that at the command level, the mechanism “checks if the structure of each executed command belongs to the set of command structures previously learned” (p.383). So after the mechanism has learned what is the acceptable structure, if it discovers a command that doesn’t have that same structure, it will sound the alarm. Next, they went on to state that at the transaction level, the mechanism “checks if the command is in the right place inside the transaction profile (a transaction is a unit formed by a set of SQL commands always executed in the same sequence)” (Fonseca, et al., 2006, p. 383). So if the intruder attempts access but does not have everything in the right place, the mechanism will realize that somebody is trying to access the database improperly and will notify the administrator. In the final level, session level, the mechanism “checks if the transaction fits in a known transaction sequence. It represents the sequence of operations that the user executes in a session” (Fonseca, et al., 2006, p. 383). So since the mechanism knows what to expect from the user, if there is any deviation from that, the administrator will be notified. To test this, the authors sent in many requests with differences to them. Some were perfectly normal, while others had slight changes or were in a random order. For the normal requests, the authors found that one of the requests was found to be malicious (Fonseca, et al., 2006, p. 384). So this resulted in only one false positive. For the requests that had slight changes, they found that their mechanism was 100% accurate (Fonseca, et al., 2006, p. 384). The final group, which used correct SQL commands but put them in a random order making them invalid transactions, resulted in 4.2% false negatives (Fonseca, et al., 2006, p. 384). So that means, 4.2% of the requests were allowed to go through, even though they were invalid. The final test they did was to manually inject 50 malicious commands as opposed to having a system run them over a set time period and they found that all 50 were detected as intrusions (Fonseca, et al., 2006, p. 384). Time Signatures This type of intrusion detection involves using time signatures on requests. The database expects requests to come in at certain times. When certain types of requests come in at times that are not correct, the system should notify the administrator that there is a possible intrusion. The authors discuss the need and benefits of their idea based on a real-time database, but this would be beneficial to any database that uses set times to process requests or updates. The real-time database would be used when there is a real world object that matches up with the data in the database. The authors use examples of the stock market, air traffic control, and electrical power grids (Lee, et al., 2000, p. 126). They state that, when the “real world object changes, the data that describes this object should change as well, but a certain lag between the moment of change in the real world and the updates in the database is unavoidable” (Lee, et al., 2000, p. 126). Using their example of the air traffic control, as a plane moves through the air, there will be some type of lag time between when it moves and when that movement is updated on the air traffic controller’s screen. As the authors point out, if intruders are able to change the values of the real world object, they could change the airplane’s coordinates on the screen (Lee, et al., 2000, p. 126). Obviously, this could be tragic if it were to happen. To test their ideas, the authors used two different types of intrusions. The first was to disguise them as user transactions. Lee, et al., (2000) explained that “in this scenario, the characteristics of an intruding transaction are identical to a user transaction except for the data object access pattern” (p.128). What they mean by this is that the intruding transaction will attempt to make a change in a way that regular user transactions don’t ordinarily do. The second test was to disguise the transactions as sensor transactions. Sensor transactions are different than user transactions in that they read a sensor periodically to check for updated information as opposed to needing a user to enter the transaction (Lee, et al., 2000, p. 127-128). Their goal here is to have the intrusion arrive randomly, which should signal the system that they are not normal. The authors’ tests showed that the system did very well for limiting the number of false positives. At one point, the false positive rate was as low as 0.36% (Lee, et al., 2000, p. 129). The rate of false negatives, however, increased as time went on. That rate was as high as 5.5% (Lee, et al., 2000, p. 129). Conclusion As the results show, both methods proposed by the two groups of authors greatly reduced the numbers of false positives and negatives. Monitoring database application behavior, however, created the greatest reduction. The false positive rate was about the same as the other method but the false negative rate was lower by almost 1.5% which is a lot if there are thousands of requests being sent in. This is important because it limits the number of malicious requests being allowed and it can let the company research to find out more information on those requests to hopefully be able to block them in the future. References Afonso, J., Monteiro, E., Costa, V. (July 2006). Development of an Integrated Solution for Intrusion Detection: A Model Based on Data Correlation. IEEE International Conference on Networking and Services. 37-42. Fonseca, J., Vieira, M., Madeira, H. (December 2006). Monitoring Database Application Behavior for Intrusion Detection. IEEE 12th Pacific Rim International Symposium on Dependable Computing. 383-386. Lee, V. C. S., Stankovic, J. A., Son, S. H. (May 2000). Intrusion Detection in Real-Time Database Systems via Time Signatures. Sixth IEEE Real Time Technology and Applications Symposium. 124-133. Vieira, M., Madeira, H. (December 2005). Detection of Malicious Transactions in DBMS. IEEE 11th Pacific Rim International Symposium on Dependable Computing. 350-357.