Security Case study: Under attack
Introduction
A large fictional banking enterprise is divided into several departments, of which two are the external banking and internal support departments respectively. All local offices belong to the external banking unit. All support activities, such as marketing, sales, and IT, belong to the internal support department. To make the business profitable, the two departments need to work closely together.
Not long ago, the IT department reached an agreement with an ASP to help them introduce new banking solutions. In addition to taking and saving money, customers should be able to perform all banking transactions over the Internet. and the actual solution is even more perfect. Because the first solution is to be performed, all customer accounts must be accessed, and it seems logical that the local office is connected to the ASP to retrieve and modify the information involved in the customer account.
The final network settings are shown below.
If your browser does not support inline boxes, click here to view them in a separate page.
There is a service level agreement (SLA) for the next year between the ASP and the banking enterprise. This SLA includes the service management issues involved (event management, change management, capacity management, availability management, contingency planning, and security management). The service level, reporting time, and the obligations of both the ASP and the bank are defined for all these issues.
The security part of the SLA
In the security part of the SLA, the bank and the ASP agree on what the security policy is and what steps need to be taken to identify the security incident. Together, a communication plan is established to ensure that everyone involved is notified in the right way. There are also technical issues regarding what tools are used to protect bank security.
Attack
One Monday morning, a worker at a local office found it took a long time to get account information. The worker didn't pay much attention to knowing that there were problems with IT in the morning of Monday. He went on doing other work. After some time, he heard his colleagues say they had the same problem in retrieving information. They consulted the IT Masters in the office in the hope of finding a solution. It was noon when the IT master reported that all his attempts had failed. At this point, you get in touch with Helpdesk. The helpdesk asked for some necessary questions and recorded the call. Both sides agree that the impact of the event appears to be small (because account information can also be retrieved), so the event is only identified as low priority. This means that no one will begin to solve the incident immediately.
After one hours, account information cannot be retrieved from any local office. Tests also indicate that customers cannot access their accounts over the Internet. The interface to the bank client was actually shut down. Because there is no urgent step in the local office to handle this situation, this means that the customer is not available for service.
The bank immediately contacted the ASP, and each bank and ASP expert was involved in the effort to resolve the system outage. Within one hours, experts found the cause of the interruption: a virus entered an internal ASP application. The virus generates a lot of data packets, flooding the entire network, resulting in degraded performance. Finally, the ASP's network is paralyzed by overflow. The ASP took two hours to recover the account system and make it rerun. The bank lost millions of of dollars because of the accident.
Where's the mistake?
Although there was an SLA between the bank and the ASP, the attacker reached the goal of letting the ASP's network crash and actually paralysed the bank's operations.
Attack detection: Due to a number of events in the morning of Monday, all ASP administrators are busy addressing "important" issues without being alerted to the warning system. And because users in the bank's organization are accustomed to these phenomena, they do not report the incident and may think others have reported it. So no one is aware of the fact that the attack is underway.
Event Management: Both the ASP's event employees and the employees of the local office agree that the event has little impact (and can also retrieve account information). When the event was logged, the event manager was not enlightened by the CMDB, aware that the incident involved a CI (configuration project), which was part of the bank's core business. The classification for this event is incorrect.
Contingency planning: ASP and banks are affected by system outages. That is to say, the normal operation of two organizations has been disrupted. However, local offices do not have urgent steps to address these situations. Nor does the ASP implement an emergency solution.
Service level management: The service level is not met due to system disruption, which means that the ASP is penalized. When drafting an SLA, the ASP did not take into account possible attacks and what impact this would have on the agreed service levels. Because of this, the bank has turned to another provider.
How to improve?
ASPs need to improve the services they provide to local offices and Internet clients. Since the events of the ASP solution often appear in the morning of Monday, any incidents that occur during the day are not taken seriously.
The ASP needs to install more detection tools in the tools that detect security attacks earlier. For network performance to fall beyond normal, analysis must be done immediately.
The employees of the bank and the ASP need to be aware of the importance of the event, so they want to notify the ASP's help desk in a timely manner about the abnormal situation of each IT service.
The ASP's help desk requires the latest "Configuration Management database" support, where each CI is labeled with a possible security classification. In this way, when a call is made to a CI, the helpdesk staff will understand that the handling of the call must follow the security steps for incident management.
Communication with all involved parties (banks, local offices, and Internet clients) is a crucial factor in the escape of such attacks. The technical solution to the attack is on the one hand, it is much more difficult to solve from the public's concept. The public may remember that the bank was "a company that stopped serving because of a virus". Good communication planning should be established to withstand this loss.
Security measures need to be taken to prevent such an attack from occurring, or to truncate the development of an attack at an early stage where service levels are not at risk. You can choose the following measures:
Let (Professional) hackers test the security measures to see if it can withstand a variety of attacks
Use Intrusion detection box
Implement passive monitoring of performance
Test for virus or other attacks on incoming packets or messages
If you do not consider the measures to be taken when the attack is drafted, you are not aware of the reality. J. Pescatore of Gartner Group made the following strategic planning assumptions in February 2000: "By 2003, 30% of ASP customers will experience an ASP-related security incident, resulting in damage to sensitive data (probability 0.7)." "The ASP has to discuss with the customer what to do in this situation." They need to understand what level of service they can reach and understand that there will be attacks. They have to know what countermeasures to take to make the damage less costly after the attack. When you do this, you need to determine what the ASP and the bank are doing in this situation.
