When handling multiple incidents simultaneously, prioritization is necessary. The rationale for assigning priority is the level of importance of the error to the business and to the user. Based on dialogue with the user and in accordance with the provisions of Service Level Agreements (SLAs), the Service Desk assigns priorities that determine the order in which incidents are processed. When incidents are escalated to a second, third or more support line, the same priority must be maintained, but can sometimes be adjusted in consultation with the Service Desk.

incident impact: the degree of deviation from the normal level of service delivery, expressed in the number of users or business processes affected by the incident;

urgency of the incident: An acceptable incident resolution delay for a user or business process.

Priority is determined based on urgency and impact. For each priority, the number of specialists and the amount of resources that can be directed to resolving the incident are determined. The order in which incidents of the same priority are handled can be determined according to the effort required to resolve the incident. For example, an easily resolved incident may be handled before an incident that requires more effort.

In Incident Management, there are ways to reduce the impact and urgency, such as switching the system to a backup configuration, redirecting the print queue, etc.

Rice. 4.2. Determining impact, urgency and priority

Impact and urgency may also themselves change over time, for example as the number of users affected by an incident increases or at critical points in time.

Impact and urgency can be combined into a matrix as shown in Table 1. 4.1.

Table 4.1. Example of a priority coding system

Escalation

If the incident cannot be resolved by the first line of support within the agreed time, additional expertise or authority must be brought in. This is called escalation, which occurs in accordance with the priorities discussed above and, accordingly, the time to resolve the incident.

There are functional and hierarchical escalation:

Functional escalation (horizontal)– means involving more specialists or providing additional access rights to resolve the incident; at the same time, it is possible that there is an extension beyond the boundaries of one structural IT department.

Hierarchical escalation (vertical)– means a vertical transition (to a higher level) within the organization, since there is insufficient organizational authority (level of authority) or resources to resolve the incident.

The Incident Management Process Manager's job is to proactively reserve functional escalation opportunities within the organization's line units so that incident resolution does not require regular hierarchical escalation. In any case, line units must provide sufficient resources for this process.

First, second and n-line support

The incident routing, or functional escalation, was outlined above. Routing is determined by the required level of knowledge, authority, and urgency. The first line of support (also called Level 1 support) is usually the Service Desk, the second line is IT Infrastructure Management, the third is Software Development and Architecture, and the fourth is vendors. The smaller the organization, the fewer levels of escalation it has. In large organizations, the Incident Management Process Manager may appoint Incident Coordinators in appropriate departments to support his activities. For example, coordinators may play the role of interface between process activities and line organizational units. Each of them coordinates the activities of their own support groups. The escalation procedure is graphically presented in Fig. 4.3.

Rice. 4.3. Incident escalation (source: OGC)

The goal of the Incident Management Process is to restore the normal Service Level as defined in the Service Level Agreement (SLA) as quickly as possible, with the minimum possible loss to the business activities of the organization and users. In addition, the Incident Management Process must maintain an accurate record of incidents to evaluate and improve the process and provide necessary information to other processes.

4.2.1. Benefits of using the process

For business in general:

Timely resolution of incidents, leading to a reduction in business losses;

Increased user productivity;

Independent, customer-focused incident monitoring;

Availability of objective information about the compliance of the services provided with the agreed upon agreements (SLAs).

For an IT organization:

Improved monitoring, allowing for accurate comparison of IT system performance levels with agreements (SLAs);

Effective management and monitoring of implementation of agreements (SLAs) based on reliable information;

Effective use of personnel;

Prevent incidents and Service Requests from being lost or incorrectly recorded;

Increasing the accuracy of information in the Configuration Management Database (CMDB) by checking it when registering incidents in relation to Configuration Items (CI);

Increased user and customer satisfaction.

Failure to use the Incident Management Process may result in the following negative consequences:

Incidents may be lost or, conversely, unreasonably perceived as extremely serious due to the absence of those responsible for monitoring and escalation, which can lead to a decrease in the overall level of service;

Users may be redirected to the same specialists “in a circle” without successfully resolving the incident;

Professionals may be constantly interrupted by phone calls from users, making it difficult for them to do their jobs effectively;

Situations may arise where several people work on the same incident, wasting time unproductively and making conflicting decisions;

There may be a lack of information about users and services provided to support management decisions;

Due to the above potential issues, the cost to the company and IT organization to support services will be higher than what is actually required.

In Fig. Figure 4.4 shows the inputs and outputs of a process, as well as the activities that the process involves.

Rice. 4.4. Incident Management Process Statement

4.3.1. Process inputs

Incidents can occur in any part of the infrastructure. They are often reported by users, but they can also be detected by employees of other departments, as well as by automatic management systems configured to record events in applications and technical infrastructure.

4.3.2. Configuration management

The Configuration Management Database (CMDB) plays an important role in Incident Management as it defines the relationship between resources, services, users and Service Levels. For example, Configuration Management shows who is responsible for an infrastructure component, making it possible to distribute incidents more effectively across teams. In addition, this database helps resolve operational issues such as redirecting a print queue or switching a user to another server. When an incident is registered, a link to the corresponding Configuration Item (CI) is added to the registration data, allowing more detailed information about the source of the error to be provided. If necessary, the status of the corresponding component in the CMDB can be updated.

4.3.3. Problem Management

Effective Problem Management requires high-quality recording of incidents, which will greatly facilitate the search for root causes. On the other hand, Problem Management helps the Incident Management Process by providing information about problems, known errors, workarounds and quick fixes.

4.3.4. Change management

Incidents can be resolved by making changes, such as replacing the monitor. Change Management provides the Incident Management Process with information about planned changes and their statuses. In addition, changes can cause incidents if the changes are made incorrectly or contain errors. The Change Management Process receives information about them from the Incident Management Process.

4.3.5. Service Level Management

Service Level Management controls the implementation of agreements (SLAs) with the customer regarding the support provided to him. Personnel involved in Incident Management must be familiar with these agreements in order to use the necessary information when contacting users. In addition, incident records are required for reporting purposes to verify that the agreed Service Level is being met.

4.3.6. Accessibility Management

The Availability Management Process uses incident logs and status monitoring data provided by the Configuration Management Process to determine service availability metrics. Similar to a Configuration Item (CI) in a Configuration Database (CMDB), a service can also be assigned the "out of order" status. This can be used to check the actual service availability and response times of the provider. When carrying out such a check, it is necessary to record the time of actions that occurred during the incident processing process, from the moment of detection to closure.

4.3.7. Capacity management

The Capacity Management process receives information about incidents related to the functioning of the IT systems themselves, for example, incidents that occurred due to insufficient disk space or slow response speed, etc. In turn, information about these incidents can enter the Incident Management Process from the system administrator or from the system itself based on monitoring its condition.

No rice. 4.5. the process steps are shown:

Rice. 4.5. Incident Management Process

Acceptance and Recording– the message is received and an incident record is created.

Classification and Initial Support– the type, status, degree of impact, urgency, priority of the incident, SLA, etc. are assigned. The user may be offered a possible solution, even if it is only temporary.

If the call concerns Service Request, then the corresponding procedure is initiated.

Binding (or Matching)– checks to see if the incident is already a known incident or a known bug, if there is an already open problem for it, and if there is a known solution or workaround for it.

Investigation and diagnosis (Investigation and Diagnosis)– in the absence of a known solution, an investigation of the incident is carried out in order to restore normal operation as quickly as possible.

Resolution and Recovery– if a solution is found, then work can be restored.

Closure– the user is contacted to confirm acceptance of the proposed solution, after which the incident can be closed.

Progress monitoring and tracking– the entire incident processing cycle is monitored, and if the incident cannot be resolved on time, escalation is carried out.

4.4.1. Reception and registration

In most cases, incidents are registered by the Service Desk, where incidents are reported. All incidents must be recorded immediately upon notification for the following reasons:

It is difficult to accurately record information about an incident if it is not done immediately;

Monitoring the progress of work to resolve an incident is possible only if the incident is registered;

Logged incidents help in diagnosing new incidents;

Problem Management can use logged incidents when working to find root causes;

It is easier to determine the degree of impact if all messages (calls) are recorded;

Without recording incidents, it is impossible to monitor the implementation of agreements (SLAs);

Immediate incident logging prevents situations where either multiple people are working on the same call or no one is doing anything to resolve the incident.

The location of the incident is determined by where the message about it came from. Incidents can be detected as follows:

Discovered by user: He reports the incident to the Service Desk.

Detected by the system: When an event is detected in the application or technical infrastructure, for example when a critical threshold is exceeded, the event is recorded as an incident in the incident reporting system and, if necessary, escalated to the support team.

Detected by Service Desk: The employee records the incident.

Discovered by someone in another IT department: This specialist logs the incident into the incident reporting system or reports it to the Service Desk.

Double recording of the same incident should be avoided. Therefore, when registering an incident, you should check whether there are similar open incidents:

If there are (and they relate to the same incident), information about the incident is updated or the incident is registered separately and a connection is established (link) to the main incident; if necessary, the impact level and priority are changed, and information about the new user is added.

If not (different from open incident), a new incident is registered.

In both cases, the continuation of the process is the same, although in the first case the subsequent steps are much simpler.

When an incident is registered, the following actions are performed:

Assigning an incident number: In most cases, the system automatically assigns a new (unique) incident number. Often this number is provided to the user so that he can refer to it in future contacts.

Recording Basic Diagnostic Information: time, signs (symptoms), user, employee who accepted the issue for processing, location of the incident and information about the affected service and/or technical means.

Recording additional information about the incident: Information is added, for example, from a script or polling procedure or from a Configuration Database (CMDB) (usually based on Configuration Item relationships defined in the CMDB).

Alarm Announcement: If a high impact incident occurs, such as a critical server failure, an alert is issued to other users and management.

4.4.2. Classification

Incident classification aims to define its category to facilitate monitoring and reporting. It is desirable that classification options be as broad as possible, but this requires a higher level of staff responsibility. Sometimes they try to combine several aspects of the classification into one list, such as type, support group and source. This often causes confusion. It is better to use several short lists. This section addresses issues related to classification.

Central processing system– access subsystem, central server, application.

Net– routers, segments, hub, IP addresses.

Work station– monitor, network card, disk drive, keyboard.

Usage and functionality– service (service), system capabilities, availability, backup (back-up), documentation.

Organization and procedures– order, request, support, notification (communications).

Service Request– a user request to the Service Desk for support, information, documentation or consultation. This can be separated into a separate procedure or handled in the same way as a real incident.

A priority

A priority is then assigned to ensure that the support team gives the incident the attention it needs. Priority is a number determined by urgency (how quickly it needs to be fixed) and impact (how much damage will be done if not fixed quickly).

Priority = Urgency x Impact.

Services (services)

To identify the services affected by the incident, a list of existing Service Level Agreements (SLAs) can be used. This list will also allow you to set the escalation time for each of the services defined in the SLA.

Support Group

If the Service Desk cannot resolve the incident immediately, a support team is assigned to resolve the incident. The basis for incident distribution (routing) is often category information. When defining categories, consideration may need to be given to the structure of support groups. Proper distribution of incidents is essential to the effectiveness of the Incident Management Process. Therefore, one of the key performance indicators (KPIs) of the Incident Management Process may be the number of incorrectly allocated tickets.

Deadline for decision

Taking into account the priority and SLA agreement, the user is informed of the maximum estimated time to resolve the incident. These deadlines are also recorded in the system.

Incident ID number

The subscriber is informed about the incident number for its accurate identification during subsequent calls.

Status

An incident's status indicates its position in the incident handling process. Examples of statuses could be:

Scheduled;

Appointed;

Active;

Postponed;

Allowed;

4.4.3. Binding (mapping)

After classification, a check is made to see if a similar incident has occurred before and whether there is a ready-made solution or workaround. If an incident has the same characteristics as an open issue or known error, it can be linked to it.

4.4.4. Investigation and diagnosis

The Service Desk or support team escalates incidents that do not have a solution or are beyond the capabilities of the person working with them to the next level support team with more experience and knowledge. This team investigates and resolves the incident or escalates it to the next level of support team.

During the incident resolution process, various specialists can update the incident record by changing the current status, information about actions taken, revising the classification and updating the time and code of the employee.

4.4.5. Solution and recovery

After successfully completing the analysis and resolving the incident, the employee records the solution in the system. In some cases, it is necessary to submit a Request for Change (RFC) to the Change Management Process. In the worst case, if no solution is found, the incident remains open.

4.4.6. Closing

Once a solution is implemented to the user's satisfaction, the support team escalates the incident back to the Service Desk. This service contacts the employee who reported the incident to obtain confirmation that the issue has been successfully resolved. If he confirms this, then the incident can be closed; otherwise, the process resumes at the appropriate level. When an incident is closed, it is necessary to update the final category, priority, service(s) affected by the incident, and the Configuration Item (CI) that caused the failure.

4.4.7. Solution progress monitoring and tracking

In most cases, the Service Desk, as the “owner” of all incidents, is responsible for monitoring the progress of the resolution. This service should also inform the user about the status of the incident. User feedback may be appropriate after a change in status, such as escalating an incident to the next support line, changing the estimated resolution time, escalation, etc. During monitoring, functional escalation to other support groups or hierarchical escalation to make executive decisions is possible.

The basis for process control are reports for various target groups. The Incident Management Process Manager is responsible for these reports, as well as the mailing list and reporting schedule. Reports may include specialized information for the following functional units:

The Incident Management Process Manager needs the report to:

Identification of missing links in the process;

Identification of violations of Service Level Agreements (SLAs);

Tracking the progress of the process;

Determination of development trends.

Management of Linear IT Departments– report for support group management; it can also be useful in IT Department Management. The report must contain the following information:

Progress in resolving incidents;

Time to resolve incidents in various support groups.

Service Level Management– the report must, first of all, contain information about the quality of the services provided. The Service Level Management Process Manager must receive all information necessary to prepare Service Level Reports to customers. Reports to customers should provide information on whether Service Level agreements are being met within the Incident Management Process.

Managers of other IT Service Management processes– reports for managers of other processes should, first of all, be informative, that is, contain all the information they need. For example, an Incident Management Process based on incident records could provide the following information:

Number of incidents detected and recorded;

Number of resolved incidents, divided by resolution time;

Status and number of unresolved incidents;

Incidents by period of occurrence, customer groups, support groups and resolution time in accordance with the agreement (SLA);

4.5.1. Critical Success Factors

Successful Incident Management requires the following:

An up-to-date Configuration Database (CMDB) to help assess the impact and urgency of incidents. This information can also be obtained from the user, but in this case it may be less complete and quite subjective, which will lead to an increase in the time it takes to resolve incidents.

To evaluate process performance, it is necessary to clearly define control parameters and measurable scores, often called performance indicators. These metrics are reported regularly, such as once a week, to provide a picture of changes from which trends can be identified. Examples of such parameters are:

Total number of incidents;

Average time to resolve incidents;

Average time to resolve incidents by priority;

Average number of incidents resolved within SLAs;

Percentage of incidents resolved by the first line of support (without referral to other groups);

Average support cost per incident;

Number of resolved incidents per workplace or per Service Desk employee;

Incidents resolved without visiting the user (remotely);

Number (or percentage) of incidents with initially incorrect classification;

Number (or percentage) of incidents incorrectly assigned to support groups.

4.5.3. Functions and roles

The implementation of processes takes place on a horizontal plane through the hierarchical structure of the organization. This is only possible with a clear definition of the responsibilities and authorities associated with the implementation of processes. To increase flexibility, a role-based approach (i.e. defining roles) can be used. In small organizations or in order to reduce overall costs, it is possible to combine roles, for example, combining the roles of Change Management and Configuration Management Process Manager.

Incident Management Process Manager

In many organizations, the role of Incident Management Manager is played by the Service Desk Manager. The responsibilities of the Incident Management Process Manager include the following:

Monitoring the efficiency and rationality of the process;

Monitoring the work of support groups;

Development and maintenance of the Incident Management system.

Support Group Staff

The first line of support is responsible for recording, classifying, matching (linking), assigning to support groups, resolving and closing incidents.

The remaining support teams are primarily involved in investigating, diagnosing and resolving incidents within established priorities.

4.6.1. Expenses

Costs associated with Incident Management include initial implementation costs (eg costs of process development, training and coaching of personnel), selection and procurement of tools to support the process. Selecting tools can take a significant amount of time. In addition, there are operating costs associated with paying staff and using tools. These costs largely depend on the structure of Incident Management, the range of activities included in the process, areas of responsibility and the number of departments.

4.6.2. Problems

When implementing Incident Management, the following problems may arise:

Users and IT professionals work around Incident Management procedures– if users resolve errors themselves or directly contact specialists without following established procedures, the IT organization will not receive information about the actual Service Level provided, the number of errors, and much more. Reports to management will also not adequately reflect the situation.

Overload with incidents and procrastination “for later”– if there is an unexpected increase in the number of incidents, there may not be enough time for correct registration, since before the end of entering information about the incident from one user, it becomes necessary to serve the next. In this case, the entry of incident descriptions may not be accurate enough and the procedures for distributing incidents to support groups will not be carried out properly. As a result, decisions are of poor quality and the workload increases even more. In cases where the number of open incidents begins to rapidly increase, a procedure for emergency allocation of additional resources within the organization can prevent staff overload.

Escalation– As is known, escalation of incidents is possible within the Incident Management Process. Too many escalations can have a negative impact on the work of specialists, who are therefore taken away from their planned work.

Lack of a Service Catalog and Service Level Agreements (SLAs)– If the services and products supported are not well defined, then it may be difficult for those involved in Incident Management to reasonably refuse assistance to users.

Lack of commitment process approach on the part of management and staff– resolving incidents using a process approach usually requires a change in culture and a higher level of responsibility for their work on the part of staff. This can cause significant resistance within the organization. Effective Incident Management requires employees to understand and truly commit to a process approach rather than simply participate.

Notes:

The “chain” refers to the chain of creation of surplus value. – Approx. ed.

In the ITIL literature, the concept of “function” is associated with a vertical (line) division of an organization that performs the corresponding functional responsibilities and is actually synonymous with it. – Approx. ed.

Service Request.

Request for Change (RFC).

Configuration Item (CI).

Key Performance Indicators - KPIs.

Performance Indicators.

Effectiveness and Efficiency.

Those. software. – Approx. ed.

Ensuring business information security Andrianov V.V.

4.1.4. Examples of incidents

4.1.4. Examples of incidents

General information

This section describes published details of some of the high-profile incidents. At the same time, generalization of incidents provides a whole bunch of circumstances characterizing the variety of information security threats from personnel, both in terms of motives and conditions, and in terms of the means used. Among the most frequently occurring incidents, we note the following:

Leakage of official information;

Theft of clients and business of the organization;

Sabotage of infrastructure;

Internal fraud;

Falsification of reports;

Trading in markets based on insider and proprietary information;

Abuse of authority.

annotation

In retaliation for a too small bonus, 63-year-old Roger Duronio (former system administrator at UBS Paine Webber) installed a “logical bomb” on the company’s servers, which destroyed all data and paralyzed the company’s work for a long time.

Description of the incident

Duronio was dissatisfied with his salary of $125,000 a year, which may have been the reason for the introduction of the logic bomb. However, the last straw for the system administrator was the bonus he received in the amount of $32,000 instead of the expected $50,000. When he discovered that his bonus was much less than he expected, Duronio demanded that his boss renegotiate his employment contract at $175,000 a year or he would leave the company. He was denied a salary increase, and he was also asked to leave the bank building. In retaliation for such treatment, Duronio decided to use his “invention,” introduced in advance, anticipating such a turn of events.

Duronio implemented the “logic bomb” from his home computer several months before he received what he considered to be a too small bonus. The logic bomb was installed on approximately 1,500 computers in a network of branches across the country and set to a specific time - 9.30, just in time for the start of the banking day.

Duronio resigned from UBS Paine Webber on February 22, 2002, and on March 4, 2002, a logic bomb sequentially deleted all files on the main central database server and 2,000 servers in the bank's 400 branches, while disabling the backup system.

During the trial, Duronio's lawyer pointed out that the culprit of the incident could not have been the accused alone: ​​given the insecurity of the UBS Paine Webber IT systems, any other employee could have gotten there under Duronio's login. Problems with IT security at the bank became known back in January 2002: during an audit, it was found that 40 people from the IT service could log into the system and obtain administrator rights using the same password, and understand who exactly did it or any other action was not possible. The lawyer also accused UBS Paine Webber and the company @Stake, hired by the bank to investigate the incident, of destroying evidence of the attack. However, the irrefutable evidence of Duronio's guilt was the pieces of malicious code found on his home computers, and a printed copy of the code in his closet.

Insider Opportunities

As one of the company's system administrators, Duronio was given responsibility for and access to the entire UBS PaineWebber computer network. He also had access to the network from his home computer via a secure internet connection.

Causes

As stated earlier, his motives were money and revenge. Duronio received an annual salary of $125,000 and a bonus of $32,000, while he was expecting $50,000, and thus avenged his disappointment.

In addition, Duronio decided to make money on the attack: anticipating a fall in the bank's shares due to an IT disaster, he made a futures order to sell in order to receive the difference when the rate dropped. The defendant spent $20,000 on this. However, the bank's securities did not fall, and Duronio's investments did not pay off.

Consequences

The “logic bomb” planted by Duronio stopped the work of 2,000 servers in 400 company offices. According to UBS Paine Webber IT manager Elvira Maria Rodriguez, it was a disaster “a 10-plus on a scale of 10.” Chaos reigned in the company, which took 200 engineers from IBM to eliminate for almost a day. In total, about 400 specialists worked to correct the situation, including the IT service of the bank itself. The damage from the incident is estimated at $3.1 million. Eight thousand brokers across the country were forced to stop working. Some of them were able to return to normal operations after a few days, some after a few weeks, depending on how badly their databases were affected and whether the bank branch had backups. In general, banking operations were resumed within a few days, but some servers were never fully restored, largely due to the fact that 20% of the servers did not have backup facilities. Only a year later, the bank’s entire server park was completely restored again.

During Duronio's trial in court, he was accused of the following charges:

Securities Fraud - This charge carries a maximum penalty of 10 years in federal prison and a $1 million fine;

Computer Fraud - This charge carries a maximum penalty of 10 years in prison and a fine of $250,000.

As a result of the trial in late December 2006, Duronio was sentenced to 97 months without parole.

"Vimpelcom" and "Sherlock"

annotation

For the purpose of profit, former employees of the VimpelCom company (Beeline trademark) offered details of telephone conversations of mobile operators through the website.

Description of the incident

Employees of the VimpelCom company (former and current) organized the website www.sherlok.ru on the Internet, which the VimpelCom company learned about in June 2004. The organizers of this site offered a service - searching for people by last name, phone number and other data. In July, the site's organizers offered a new service - detailing telephone conversations of mobile operators. Call detailing is a printout of the numbers of all incoming and outgoing calls, indicating the duration of calls and their cost, used by operators, for example, for billing subscribers. Based on these data, we can draw a conclusion about the subscriber’s current activities, his area of ​​interest and circle of acquaintances. The press release from Directorate “K” of the Ministry of Internal Affairs (hereinafter referred to as the Ministry of Internal Affairs) clarifies that such information cost the customer $500.

Employees of the VimpelCom company, having discovered this site, independently collected evidence of the site’s criminal activities and transferred the case to the Ministry of Internal Affairs. Employees of the Ministry of Internal Affairs opened a criminal case and, together with the VimpelCom company, established the identities of the organizers of this criminal business. And on October 18, 2004, the main suspect 1 was detained red-handed.

In addition, on November 26, 2004, the remaining six suspects were detained, including three employees of the subscriber service of the VimpelCom company itself. During the investigation, it turned out that the site was created by a former student of Moscow State University who did not work for this company.

The paperwork on this incident became possible thanks to the ruling of the Constitutional Court in 2003, which recognized that call details contained the secrecy of telephone conversations, protected by law.

Insider Opportunities

Two of the VimpelCom employees identified among the participants in the incident worked as tellers in the company, and the third was a former employee and was working at the Mitinsky market at the time of the crime.

Working as tellers in the company itself indicates that these employees had direct access to the information offered for sale on the website www.sherlok.ru. In addition, since a former employee of the company already worked at the Mitinsky market, it can be assumed that over time, this market could also become one of the distribution channels for this information or any other information from the VimpelCom company databases.

Consequences

The main consequences for VimpelCom from this incident could be a blow to the reputation of the company itself and the loss of customers. However, this incident was made public directly thanks to the active actions of the company itself.

In addition, making this information public could have a negative impact on VimpelCom’s clients, since the detail of the conversations allows us to draw a conclusion about the subscriber’s current activities, his area of ​​interest and circle of acquaintances.

In March 2005, the Ostankino District Court of Moscow sentenced the suspects, including three employees of the VimpelCom company, to various fines. Thus, the organizer of the group was fined 93,000 rubles. However, the operation of the website www.sherlok.ru was stopped indefinitely only from January 1, 2008.

The largest personal data leak in Japanese history

annotation

In the summer of 2006, the largest leak of personal data in the history of Japan occurred: an employee of the printing and electronics giant Dai Nippon Printing stole a disk with private information of almost nine million citizens.

Description of the incident

The Japanese company Dai Nippon Printing, specializing in the production of printed products, allowed the largest leak in the history of its country. Hirofumi Yokoyama, a former employee of one of the company's contractors, copied personal data of the company's clients onto a mobile hard drive and stole it. A total of 8.64 million people were at risk because the stolen information included names, addresses, phone numbers and credit card numbers. The stolen information included customer information from 43 different companies, such as 1,504,857 American Home Assurance customers, 581,293 Aeon Co customers and 439,222 NTT Finance customers.

After the theft of this information, Hirofumi opened trade in private information in portions of 100,000 records. Thanks to the stable income, the insider even left his permanent job. By the time of his arrest, Hirofumi had managed to sell the data of 150,000 clients of the largest credit firms to a group of fraudsters specializing in online purchases. In addition, some of the data has already been used for credit card fraud.

More than half of the organizations whose customer data was stolen were not even warned about the information leak.

Consequences

As a result of this incident, the losses of citizens who suffered due to credit card fraud, which became possible only as a result of this leak, amounted to several million dollars. In total, customers of 43 different companies were affected, including Toyota Motor Corp., American Home Assurance, Aeon Co and NTT Finance. However, more than half of the organizations were not even warned about the leak.

In 2003, Japan passed the Personal Information Protection Act 2003 (PIPA), but prosecutors were unable to apply it in the actual trial of the case in early 2007. The prosecution was unable to charge the insider with violating PIPA. He is only accused of stealing a hard drive worth $200.

Not appreciated. Zaporozhye hacker against a Ukrainian bank

annotation

A former system administrator of one of the large banks in Ukraine transferred about 5 million hryvnia through the bank where he previously worked from the account of the regional customs to the account of a non-existent bankrupt Dnepropetrovsk company.

Description of the incident

His career as a system administrator began after he graduated from technical school and was hired by one of the large banks in Ukraine in the software and hardware department. After some time, management noticed his talent and decided that he would be more useful to the bank as a department head. However, the arrival of new management at the bank also entailed personnel changes. He was asked to temporarily vacate his position. Soon, the new management began to form their team, but his talent turned out to be unclaimed, and he was offered the non-existent position of deputy chief, but in a different department. As a result of such personnel changes, he began to do something completely different from what he knew best.

The system administrator could not put up with this attitude of management towards himself and resigned of his own free will. However, he was haunted by his own pride and resentment towards management, in addition, he wanted to prove that he was the best in his business and return to the department where his career began.

After resigning, the former system administrator decided to return the former management’s interest in his person by using the imperfections of the “Bank-Client” system used in almost all banks in Ukraine 2 . The system administrator's plan was that he decided to develop his own security program and offer it to the bank, returning to his previous place of work. The implementation of the plan consisted of penetrating the Bank-Client system and making minimal changes to it. The entire calculation was made on the fact that the bank would have discovered a system hack.

To penetrate the specified system, the former system administrator used passwords and codes that he learned while working with this system. All other information necessary for hacking was obtained from various hacker sites, where various cases of computer network hacking, hacking techniques, and all the software necessary for hacking were described in detail.

Having created a loophole in the system, the former system administrator periodically penetrated the bank's computer system and left various signs in it, trying to draw attention to the facts of hacking. Bank specialists were supposed to detect the hack and sound the alarm, but, to his surprise, no one even noticed the penetration into the system.

Then the system administrator decided to change his plan, making adjustments to it that could not go unnoticed. He decided to forge a payment order and use it to transfer a large amount through the bank’s computer system. Using a laptop and a mobile phone with a built-in modem, the system administrator penetrated the bank's computer system about 30 times: looked through documents, client accounts, cash flows - in search of suitable clients. He chose regional customs and a bankrupt Dnepropetrovsk company as such clients.

Having once again gained access to the bank’s system, he created a payment order in which he withdrew 5 million hryvnia from the personal account of the regional customs and transferred through the bank to the account of the bankrupt company. In addition, he purposefully made several mistakes in the “payment”, which in turn should have further helped attract the attention of bank specialists. However, even such facts were not noticed by the bank specialists servicing the Bank-Client system, and they calmly transferred 5 million hryvnia to the account of a defunct company.

In reality, the system administrator expected that the funds would not be transferred, that the fact of hacking would be discovered before the funds were transferred, but in practice everything turned out differently and he became a criminal and his fake transfer escalated into theft.

The fact of hacking and theft of funds on an especially large scale was discovered only a few hours after the transfer, when bank employees called customs to confirm the transfer. But they reported that no one had transferred such an amount. The money was urgently returned to the bank, and a criminal case was opened in the prosecutor's office of the Zaporozhye region.

Consequences

The bank did not suffer any losses, since the money was returned to the owner, and the computer system received minimal damage, as a result of which the bank management refused any claims against the former system administrator.

In 2004, by decree of the President of Ukraine, criminal liability for computer crimes was strengthened: fines from 600 to 1000 tax-free minimums, imprisonment from 3 to 6 years. However, the former system administrator committed a crime before the presidential decree came into force.

At the beginning of 2005, a trial of the system administrator took place. He was accused of committing a crime under Part 2 of Article 361 of the Criminal Code of Ukraine - illegal interference with the operation of computer systems causing harm and under Part 5 of Article 185 - theft committed on an especially large scale. But since the bank’s management refused to make any claims against him, the charge of theft was removed from him, and part 2 of article 361 was changed to part 1 - illegal interference in the operation of computer systems.

Uncontrolled trading at Societe Generale bank

annotation

On January 24, 2008, Societe Generale announced a loss of 4.9 billion euros due to the machinations of its trader Jerome Kerviel. As an internal investigation showed, for several years the trader opened above-limit positions in futures for European stock indices. The total amount of open positions amounted to 50 billion euros.

Description of the incident

From July 2006 to September 2007, the computer internal control system issued a warning about possible violations 75 times (that is how many times Jerome Kerviel carried out unauthorized transactions or his positions exceeded the permissible limit). Employees of the bank's risk monitoring department did not carry out detailed checks on these warnings.

Kerviel first began experimenting with unauthorized trading in 2005. Then he took a short position on Allianz shares, expecting the market to fall. Soon the market really fell (after the terrorist attacks in London), which is how the first 500,000 euros were earned. Kerviel later told investigators about his feelings about his first success: “I already knew how to close my position, and I was proud of the result, but at the same time I was surprised. Success made me continue, it was like a snowball... In July 2007, I proposed to take a short position in anticipation of a market decline, but did not receive support from my manager. My forecast came true, and we made a profit, this time it was completely legal. Subsequently, I continued to carry out such operations on the market, either with the consent of my superiors or in the absence of his explicit objection... By December 31, 2007, my profit reached 1.4 billion euros. At that moment, I did not know how to declare this to my bank, since it was a very large amount that was not declared anywhere. I was happy and proud, but I did not know how to explain to my management the receipt of this money and not incur suspicion of conducting unauthorized transactions. Therefore, I decided to hide my profit and conduct the opposite fictitious operation...”

In fact, in early January of that year, Jerome Kerviel re-entered the game with futures contracts on the three Euro Stoxx 50 indices, DAX and FTSE, which helped him beat the market in late 2007 (though he preferred to go short at the time). According to calculations, on the eve of January 11, his portfolio contained 707.9 thousand futures (each worth 42.4 thousand euros) on Euro Stoxx 50, 93.3 thousand futures (192.8 thousand euros per 1 piece) on DAX and 24.2 thousand futures (82.7 thousand euros per 1 contract) for the FTSE index. In total, Kerviel's speculative position was equal to 50 billion euros, that is, it was more than the value of the bank in which he worked.

Knowing the timing of the checks, he opened a fictitious hedging position at the right moment, which he later closed. As a result, reviewers never saw a single position that could be considered risky. They could not be alarmed by the large amounts of transactions, which are quite common in the index futures market. He was let down by fictitious transactions carried out from the accounts of bank clients. The use of accounts of various bank clients did not lead to problems visible to controllers. However, over time, Kerviel began using the same clients' accounts, which led to "abnormal" activity observed on these accounts and, in turn, attracted the attention of controllers. This was the end of the scam. It turned out that Kerviel's partner in the multibillion-dollar deal was a large German bank, which allegedly confirmed the astronomical transaction by email. However, the electronic confirmation raised suspicions among the inspectors, and a commission was created at Societe Generale to verify them. On January 19, in response to a request, the German bank did not recognize this transaction, after which the trader agreed to confess.

When it was possible to find out the astronomical size of the speculative position, the CEO and chairman of the board of directors of Societe Generale, Daniel Bouton, announced his intention to close the risky position opened by Kerviel. This took two days and resulted in losses of 4.9 billion euros.

Insider Opportunities

Jerome Kerviel worked for five years in the so-called back office of the bank, that is, in a department that does not directly conclude any transactions. It deals only with accounting, execution and registration of transactions and monitors traders. This activity allowed us to understand the features of the control systems in the bank.

In 2005, Kerviel was promoted. He became a real trader. The young man’s immediate responsibilities included basic operations to minimize risks. Working in the futures market for European stock indices, Jerome Kerviel had to monitor how the bank's investment portfolio was changing. And his main task, as one Societe Generale representative explained, was to reduce risks by playing in the opposite direction: “Roughly speaking, seeing that the bank was betting on red, he had to bet on black.” Like all junior traders, Kerviel had a limit that he could not exceed, which was monitored by his former colleagues in the back office. Societe Generale had several layers of protection, for example traders could only open positions from their work computer. All data on opening positions was automatically transmitted in real time to the back office. But, as they say, the best poacher is a former forester. And the bank made an unforgivable mistake by putting the former forester in the position of a hunter. Jerome Kerviel, who had almost five years of experience in monitoring traders, did not find it difficult to bypass this system. He knew other people's passwords, knew when checks were going on at the bank, and was well versed in information technology.

Causes

If Kerviel was involved in fraud, it was not for the purpose of personal enrichment. His lawyers say this, and representatives of the bank also admit this, calling Kerviel’s actions irrational. Kerviel himself says that he acted solely in the interests of the bank and only wanted to prove his talents as a trader.

Consequences

At the end of 2007, its activities brought the bank about 2 billion euros in profit. In any case, this is what Kerviel himself says, claiming that the bank’s management probably knew what he was doing, but preferred to turn a blind eye as long as he was profitable.

Closing the risky position opened by Kerviel led to losses of 4.9 billion euros.

In May 2008, Daniel Bouton left the post of CEO of Societe Generale, and was replaced in this position by Frédéric Oudea. A year later, he was forced to resign from his post as chairman of the bank's board of directors. The reason for his departure was sharp criticism from the press: Bouton was accused of the fact that the top managers of the bank under his control encouraged risky financial transactions carried out by bank employees.

Despite the support of the board of directors, pressure on Mr. Bouton increased. The bank's shareholders and many French politicians demanded his resignation. French President Nicolas Sarkozy also called on Daniel Bouton to resign after it became known that in the year and a half before the scandal, Societe Generale's computer internal control system issued a warning 75 times, i.e. every time Jerome Kerviel carried out unauthorized transactions. possible violations.

Immediately after the losses were discovered, Societe Generale created a special commission to investigate the trader’s actions, which included independent members of the bank’s board of directors and auditors PricewaterhouseCoopers. The commission concluded that the bank's internal control system was not effective enough. This resulted in the bank being unable to prevent such a large-scale fraud. The report states that “bank staff did not conduct systematic checks” of the trader’s activities, and the bank itself did not have “a control system that could prevent fraud.”

The report on the results of the trader's audit states that following the results of the investigation, a decision was made to “significantly strengthen the procedure for internal supervision of the activities of Societe Generale employees.” This will be done through a more strict organization of the work of various divisions of the bank and coordination of their interaction. Measures will also be taken to track and personalize the trading operations of bank employees by “strengthening the IT security system and developing high-tech solutions for personal identification (biometrics).”

4.2.2. Typology of incidents Generalization of world practice allows us to identify the following types of information security incidents involving organization personnel: - disclosure of official information; - falsification of reports; - theft of financial and material assets; - sabotage