Scripted attack

Paul received a call from the Network Operation Centre at a very inappropriate time in the morning. It was at 2:00 am when Paul answered the call of Susan Carter who worked in the third shift at Network Operation Centre. An incident occurred due to fire but after the operations were normal, the employees began to work on normal schedules. The problem that arose at this hour was occurring in DOS that got slammed. Paul was asked to solve the problem and the suggestion he gave was to filter the traffic or to reconfigure the outside firewall but Susan replied that she had already tried that and the problem was coming from another port and it was the third time in an hour that she had to face this problem.

Paul at one go, understood that it was a live attack. Previously he had observed that when there was a scripted attack, filtering out the port or the network address on which the attack was coming mostly stopped for a while and if it changed, it was due to an orchestrated attack. To solve the problem, Paul logged in to his laptop PC and scanned the logs on the firewall and border gateway over his VPN connection and he came to a conclusion that all attacks came in ranges and he asked Susan to filter the ports on the range of 1400 to 2200. After Paul came to know about this problem he was a bit worried and he thought about the new vulnerability he read about in the last few days. After a few seconds only, Susan exclaimed that the problem was solved by putting the range.

The incident response team is formed either by the employees currently hires or by outsourcing a team. The phases of the incident response development system in this case started from the time when an error occurred in the system and the second phase was when the supervisor called Paul for assistance. This phase took place at a very appropriate time but Paul had to be approached in order to rectify the problem that had occurred. The third phase of incident response development system was when Paul was notified about the problem and Susan asked for assistance from him. The fourth phase occurred when Paul suggested Susan to filter the traffic or to reconfigure the outside firewall. However, Susan complained that both the suggestions had already been tried and both did not work. The fifth phase was when Paul logged onto his laptop and scanned the logs. After this, in the next phase he discovered that the attacks came in range. The sixth and the last phase of incident response development system was when Paul told Susan to filter the ports on the range of 1400 to 2200.

The total number of phases therefore in the whole process was six and all of them had their own critical elements in each phase. In the first phase, the critical element was basically the problem that erupted in the system. In the second phase, the critical element was the timing at which Paul was approached as the timing at which he was called was not a suitable time to call but according to Susan, the problem had already occurred three times in an hour. Therefore, it was necessary for her to ask for assistance from Paul. In the third phase, the critical element was to convey the correct message to Paul so that he could provide help. In the next phase, when Paul made a suggestion to Susan i.e. he asked her to filter the traffic or to reconfigure the outside firewall, the critical element was when Susan said that it was already tried by her and it did not work. In the fifth phase, the critical element was Paul suspected what the problem can be. In the last phase, another suggestion made by Paul to Susan i.e. to filter the ports on the range of 1400 to 2200 and this was the critical point.

The general phases followed by incident response committee were when Paul received the call from Network Operation Centre at the time he was sleeping and he turned in his bed twice before he finally received the call after he checked the number that was from Network Operation Centre. The next phase was when he received the call, was told about the problem that persisted followed by the next general phase when he suggested the solutions. However, as they were already tried by Susan, they did not come up to be productive due to which Paul had to log on to his laptop and discover what the problem was. In the next phase, he suggested one more suggestion and asked Susan Carter to filter the ports on the range of 1400 to 2200.

The stakeholders are all the people who were related to Network Operation Centre in any way; however the stakeholders of the incident response process were Susan, Paul and the other people affected by the problem that had occurred. The role of the stakeholders is to collect information for which they are responsible and to fulfill their responsibilities. The people who have interest in the business i.e. different stakeholders are mentioned below.

1. General management – this group needs to understand the task the team has to perform and preauthorize interaction between the business functions and the actions that are needed to be taken to mend the incident.
2. IT management – the specific demands placed by the team and the resources that are required to respond to the incident. Moreover, they also have to approve the actions the team will take especially when they have an impact on the networking functions and connections.
3. Info Sec management – this group has to understand the resources that are needed after the incident and how should they be accessed.
4. The legal department – they need to understand the procedures and steps of the team and ensure that they follow the legal and ethical aspects.
5. The human resource department – they are responsible for acquiring personnel who are not available to complete the team. The task of the HR department is to prepare job descriptions and to conduct interviews before hiring the candidates.

Just like all the other polices need to gain support of the top management, the IR policy must also gain full support and it should be clearly understood by everyone especially the people who have more interest in the business when changes are being made in the business practices or in the information technology infrastructures. In this case, for instance if the management decides to secure the network from various attacks, an appropriate document has to be signed and the rules must be implemented as well as this would not only prevent any attack, but it will also protect the team that is performing outside the authorization. Moreover, it also prevents the misunderstandings to grow. Some of the basic IR policy elements are mentioned below.

1. Clear
2. Concise
3. Necessary and sufficient
4. Usable
5. Implementable

Clarity is important because it is necessary for every team member to understand the policy well. It is always best to avoid jargons and to use short sentences so that people can easily comprehend and implement them. A good policy is always short while a long policy is a bad policy as it includes many procedures that may become confusing for the employees. The policy that has been designed should contain all the appropriate information and all topics must be covered. Moreover, it should be useable i.e. should not be meaningless and should be interpreted well by the people for whom it is designed. Sentences written should be common and it is wise to use sentences that are commonly shared by the people. It is not just important to design a policy but it should be such that it can be implemented and controlled. After the policy is designed, it is good to monitor the results closely so that any weaknesses or defects can be mended. (Mattord & Whitman, 2006).

In the end, I would conclude by saying that it is always advisable for every organization to prepare contingency plans so that the problems can easily be dealt with in the time of need, the employees can easily respond to the incident and recovery the disaster.

References

1. Mattord, H. J. & Whitman, M. E. Principles of Incident Response and Disaster  Recovery. 1st Edn. Course Technology (2006).