Once we have the product under monitor and also are demonstrating auditing process, then we next need to talk about incident management. Before exploring too far, we need to get a couple of terms defined. These are terms that some folks tend to try to use interchangeably. The three terms are: events, alerts, and incidents. However, the three are actually different from each other. Events are neither positive nor negative. They simply represent a change in state. So, when a system starts or when a service starts, it’s an event. It’s neither positive nor negative. Then, when there are multiple events then it’s considered an incident. Typically, it’s that the events are adversely affecting the system as well as being present in multiple cases. Last, then the alert is usually configured to trigger a warning in case the incidents occur. An alert might be set up for me, for example to send me an email message when there’s no more space on the hard drive, for example.
So there are many types of incidents out there. When there has been an incident, then there is an incident response that we are expected to give. The attack which could be a malicious intrusion of either the denial of service or distributive denial of service types of attacks. Both are mainly to affect the availability of the system rather than actually negatively affect the system, itself. These two types of attacks are referred to as either the DoS or DDoS types of attacks. The attacker is looking to take Google offline for two minutes or something, as an example. For example, some of the members of Anonymous that’s been in the news lately with their “vigilantism” like vigilante and activism smashed together. Some other folks refer to it as “hacktivism”. They’re expressing their political frustration by hacking into servers of people they believe worthy of being hacked into.
For an example of some of their activity, the founder of Wikileaks was determined by their members, to be unfairly persecuted and prosecuted and so they did a DDoS where they took several of the major credit card companies offline for a period of time over one morning. The purpose wasn’t to steal or divulge the private information. It was for the sole purpose of showing the company their collective brains and to demonstrate those credit card companies with a loss of profit because of the glitches with the credit cards not being able to function since they were considered “offline”. One or two minutes on my website doesn’t cost me, because it might several days in between when I access the material. However, when it’s a website like Amazon or one of these other credit cards, they can lose a significant amount like in the millions of dollars.
The incident was the credit cards companies being offline for a good portion of the morning in response to Wikileaks’ founder Julian Assange’s alleged persecution and definitely prosecution. Even just being off 3,4 or so minutes could lose hundreds of thousands for some of these companies. So, the malicious code that the Anonymous group could have been presented in a number of different ways. Some of the different ways of injecting malicious code are by: worms, viruses, Trojan horses, logic bombs and many others. So, basically looking at exploiting any vulnerability in order to gain access to a system. Other types of incidents may include unauthorized access to a system. Also, there’s inappropriate system usage as another means of an incident type. These are the two we are going to discuss next.
In an unauthorized access to a system, a subject that shouldn’t be authorized or allowed into a system to access something, ends up getting authorization. It could easily be through social engineering where someone isn’t as wary or as diligent about their password, might allow unauthorized access. Other possibilities include perhaps a person has just simply guessed at the password. Remember that the authentication actually happens after the authorization process. So, perhaps there is a mechanism in place to pick up the authorization as they’ve authenticated to be you. So, there’s all kinds of methods of gaining the information and be allowed access to a system that they shouldn’t be able access.
In terms of authentication, biometrics is a good way to ensure integrity of the system. For example, where it requires my signature. So my signature is going to authenticate me. So when I sign like the digital signature or compare to the digital registry/ template and if look close enough, then allowed to gain access. As an attacker, perhaps they have created a reasonable forgery and then gained access. When an attacker is successful, regardless of whatever means, then they have unauthorized access. Again, this is that someone has gained access when they shouldn’t have that ability to get into the system, the network, or the applications.
The last incident type is associated with inappropriate system usage. The acceptable use policies of a service or of a mechanism is violated. When those are violated, then we refer to that as inappropriate usage. The incident response usually entails four major steps: preparation; detection and analysis; containment, eradication & recovery; and then last with post-incident review.
The first step is preparation. Now with preparation, I basically need to assemble a team together and make sure that all the policies and procedures are in place. Preparation is where more of the energy, resource and effort will be utilized. If we’re not well-prepared, then we will end up making mistakes. There’s possibilities of losing valuable evidences, losing valuable data and we may even give the attacker the opportunity to be aware that we’re tracking their movements and they could end up cleaning up lots more after their future attacks which eliminates better possibilities for our prosecution and litigation purposes. Without being prepared, we could end up doing more damage even more than with even no response at all. So, we need to be well prepared.
The second step is detection and analysis. After we prepare, we look to detect and analyze the incident, so we want to figure out what systems are affected. To be as successful as we can be, we will want to look to the root cause and do the analysis there. We have several questions which would need to be answered such as how the code got onto our network in the first place, and then also the scope and nature of attack. The third step is containment, eradication & recovery.
So, the third step is more about getting the whole thing up and running. Once we’ve monitored, documented, analyzed for our incident response, the next step is all about restoring back to the environment prior to the attack. After this, of course is the review. This is a post-incident review and it is the fourth step.
The final step of an incident response is the post-incident review. This is the debriefing step of the process. We can create a document titled Lessons Learned. We want to document how the attacker was successful. We want to document to what degree was their success as well as what tools and what internal vulnerability. In the debriefing, it gives the team a sense of what steps can we take on this piece of software or network to increase security and improve to make a stronger, better environment as we move forward. As the incidents are successful in attacking our system, our own knowledge increases and allows us to be better fit and stronger in our security systems as preventative and maintenance against possible future attack.
One last term to define before leaving this part completely is the term problem. Problem is when there is an incident with an unknown cause or origin. This is a major problem because we don’t necessarily understand why it’s happening the way it is and if we go to the root of the problem, it may be one that isn’t as understandable as others. So, there may be issues trying to devise and implement solutions. So, there’s problem management to help us with root cause analysis and then also with solution implementation and continuing to monitor for any other events, incidents, or problems.