Download doc - itk.ilstu.edu

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.