Managing a Computer Security Incident Response Team - Research Paper Example

Information Security Incident Management Affiliation] Managing a Computer Security Incident Response Team (CSIRT A Practical Perspective 1. Introduction This Research Paper summarizes the current body of practical information in the area of information security management, using a CSIRT as a case study. From a practical workplace perspective, the over-riding principle that must be kept in mind at all times is that a system can only be reliably cracked from the inside!. This because, providing that the firewalls’ rules are updated, preferably on a daily basis (and the Liability Insurers will surely insist on this!) and that the enterprise in question has robust direction finding and traffic analysis applications in place (these are often combined in specialized systems) any cyber-attacks mounted from outside the enterprise’s systems can only slow down the website performance, for example. Even the latter risk is successfully mitigated by employing servers with a large reserve in processing power - a surprisingly inexpensive procedure, given the commodity status of modern computers. Therefore, the way forward is to take measures to mitigate the risk of ‘internal’ attacks. The first principle is to indoctrinate the enterprise’s employees in Information Security (IS) being about people rather than hardware and software. Employees must therefore always think about IS when performing their daily tasks. For example, employees must never connect their own personal devices (such as smartphones) to the Company’s network, and only Company-approved laptops and tablets are to be connected to the Company’s network by, for example, sales staff ’on the road’. One obvious HR process to be adopted, particularly for employees handling financial and commercially sensitive material, is three-monthly Probity Checks, which basically means vetting such employees against the industry’s master database of alcoholics, gamblers and sexual offenders. It must also be stressed at all times that the enterprise’s Liability Insurers, Bankers and Payment Care providers will absolutely insist on at least the industry-standard IS benchmarks being in place within a given enterprise, or they will withdraw facilities, or, at least, levy punitive financial and legal sanctions. 2. Literature Review The works of Blackley, Peltier & Peltier and Layton date from 2003 and 2007 respectively, and while they are standard works on the basic principles of information management (that have not really changed since at least the 1940s) are nonetheless some what behind-the-times with respect to current issues and opportunities in the information security management domain. An opportunity has therefore been taken to present a representative sample of the current practice and solutions in this area, using computer information security as the background, as ICT in general is the key information repository for all forms of non-historical information, no matter what the subject. The work of Killacree [Georgia Killacree, 2006] shows that the IS main threats to an enterprise come from Disgruntled Employees (often the chief source of internal threats - a critical tasks for enterprise HR!) so-called ‘hackers for hire’, organized crime, competitors, cyber vandals and governments (the latter particularly applies to technology developments, as the rewards accrue to those who apply and sell a new technology rather than those who develop it!). Of these, to a typical enterprise, the most severe IS threat comes from competitors, who may be so unethical as to suborn ‘home’ employees - another key reason for carrying out three-monthly Probity Checks. Killacree makes it abundantly clear that CSIRTs in general need to react quickly - in a manner of minutes if a major cyber attack is being mounted. The response needs to include : immediate notification, automated incident handling, easy and efficient collation and interpretation of key information, and effective mechanisms to share collated and interpreted information. The work of Kabay [M. E. Kabay, PhD, CISSP, 2009] explains the key tasks in organising a CSIRT in order to carry out the roles outlined by Killacree [2006]. These fall into two basic categories : proactive services (or preventative tasks) and security quality management services (remedial tasks, in other words. Kabay [2009, Page 5] defines the proactive services as : announcements , technology watch , security audits or assessments, the configuration & maintenance of security tools, applications and infrastructures, the development of security tools, intrusion detection services and security-related information dissemination. These fully accord with practical IS workplace experience. Kabay defines the key security quality management services as : risk analysis , business continuity and disaster recovery planning (also vital in case of physical risks to the enterprise’s data center), IS consulting (something best placed in the hands of outside experts in smaller enterprises), awareness building (usually done through regular seminars conducted by the enterprise’s ISO), education and training (likewise), and IS product evaluation or certification (also a key ISO task). The work of Profitt [Timothy Proffitt, 2007] builds on the themes defined by Kabay [2009], but places them in the specific context of a large enterprise. Profitt defines three categories : passive services, such as vulnerability assessments, announcements and information disclosure, and an intrusion detection service. His second category is active services, which would comprise : incident handling, vulnerability handling, evidence handling (this would, in practice include preparing material for legal and Police reports) and lessons learned reporting, which basically means hammering home to the staff as a whole what happened, why, what needed to be done to fix it, and what needs to be done in the future to stop it happening again! Profitt’s final category is management services. This would comprise : awareness training, (a follow-on from the ‘lessons’ learned’ seminars), risk assessments and compliancy certifications. An excellent example of the letter is the Payment Card Industry Data Security Standard (PCI-DSS) certification, which particularly applies to larger enterprises that hold ‘merchant’ status with respect to the major payment cards and who hence hold key financial data for customers Profitt builds on this by defining the key CSIRT Policies, such as an Incident Response Policy, an Incident Response Standards & Procedures, a Code of Conduct, a Disclosure Policy, a Disclosure Procedures to External CSIRTs document and evidence handling procedures. It must be borne in mind that all these policies and procedures apply with equal force to smaller enterprises, particularly those that deal in advanced technology, although the ISO may, in fact, be one of a number of ‘hats’ worn by the business owner. The work of Cormack, Maj, Parker and Stikvoort [Andrew Cormack, Miroslaw Maj, Dave Parker, Don Stikvoort , 15 September 2005] defines a code of conduct that codifies the work of Kabay [2009] and Profitt [2007] above in particular. This CSIRT Code of Practice sets out the CSIRT definitions that an enterprise’s CSIRT should employ, the legal requirements that the CSIRT needs to satisfy (this is of particular relevance when mounting prosecutions against hackers and competitors, not to mention erring employees!), how the CSIRT should conduct itself overall, how individual CSIRT members will conduct themselves, how the information handling function is to be carried out in practice, along with the service specific requirements in terms of incident handling and vulnerability handling. This Code of Practice would therefore serve as an excellent basis for CSIRT operations within technology enterprises in general. The University of Scranton CSIRT Information Security Office [1/27/2009] sets out such standards in a particularly clear and precise form and would serve as an excellent benchmark for any other enterprise. Page 3 of this document defines a CSIRT as being responsible for establishing, overseeing, and carrying the enterprise’s IS procedures top ensure the availability of the enterprise’s ICT assets and/or resources. The CSIRT would work closely with the enterprise’s ISO on the development of operational procedures for and documentation of incidents. CSIRT members would develop policies and procedures for the prevention, identification, analysis, containment, and eradication of security threats. They would restore the affected ICT asset to an operational state as quickly as possible while preserving forensic data. CSIRT members also serve as liaisons to the enterprise’s teams where the incident has occurred throughout the response process. The overall goals of the CSIRT are defined as protecting and preserving the electronic information and network assets to ensure the availability, integrity and confidentiality of the enterprise’s electronic information and network assets. Page 4 of the document defines the five primary objectives of a CSIRT as:- 1. Control and manage the incident 2. Timely investigation and assessment of the severity of the incident 3. Timely recovery or bypass of the incident to normal operating conditions 4. Timely notification of serious incidents to senior management 5. The prevention of similar incidents in the future Page 4 of the document also defines the CSIRT as CSIRT as the operational team of specialists responsible for conducting an incident investigation and recommending measures to correct or bypass a problem or condition relating to the incident. The nature of the incident will determine the actual role the CSIRT will have in respect to implementing all corrective or preventive actions. The full team would consist of a both core team who are assisted by support team comprised of subject matter experts (SMEs) appropriate to the the nature of a particular incident under investigation. The Scranton University document, in general, serves as an excellent benchmark for a technology enterprise’s CSIRT in particular and is well worthy of emulation. The work of Gonzalez, Qian and Sawicka [Jose J. Gonzalez, Ying Qian, Agata Sawicka, n.d.] introduces the concept of CSIRTs as being security incident handling organizations that either serve an enterprise or as a constituency within a trade association working within the same domain. Gonzalez, Qian and Sawicka maintain that CSIRTs struggle coping with the increasing number and sophistication of incidents due to staff being overloaded with work and managers over-utilizing their teams. It has to be said that, in practical workplace terms, these conclusions are, to say the least, debatable, and would be circumvented by a truly competent enterprise ISO. Sawicka, Gonzalez and Qian [n.d.] further state that such CSIRT mismanagement problems may be expressed as a case of corporate resource mismanagement. Previous studies have suggested that misperceptions of team and departmental relationships may contribute to mismanagement of corporate resources. Again, a truly competent enterprise ISO would be able to prevent this. Gonzalez, Qian and Sawicka [n.d.] have replicated Moxnes’s 2004 experiments, in the process redefining the one-stock reindeer rangeland management case study as a challenge in sustainable CSIRT management. Their results suggest, firstly, that misperceptions of applicable processes and procedures persist when the problem context changes, and, secondly, that people employ a simplistic anchoring-and-adjustment decision rule to deal with such problems, and, thirdly, that their conclusions do not support Moxnes‘s contentions. Gonzalez, Qian and Sawicka [n.d.] ultimately conclude that the observed misperceptions might at least in part depend on the way in which the task was presented. It is therefore a key task of any enterprise ISO to prevent this. The work of Schreiber and Reid [n.d.] defines a set of tables of information security incident challenges, including the importance of specific categories of incident and all the most likely computer information security incidents that an enterprise will encounter on a daily basis. Schreiber and Reid maintain that it is critical for the CSIRT to provide consistent and timely solutions to all incidents, and that sensitive information is handled according to company classifications. Their document provides the guidelines needed for CSIRT Incident Managers (IMs) to classify the case category, criticality level, and sensitivity level for each CSIRT transaction. This information will be entered into the enterprises Incident Tracking System (ITS) when an incident is created. Consistent case classification is required for the CSIRT to provide accurate and regular management reporting. These classifications also provide CSIRT IMs with the appropriate incident handling procedures and would form the basis of service level agreements (SLAs) between the CSIRT and other enterprise departments. All incidents managed by the CSIRT would be classified into Incident Category Sensitivity, and Description Schreiber and Reid [n.d.] define the criticality matrix as the minimum acceptable customer response time and ongoing communication requirements for an incident. The criticality level should be entered into the ITS when an incident is created, and it must not be altered in any way during the incident lifecycle except when it was incorrectly classified in the first place - which must be recorded as a Change Request within the enterprises CMS. The IM will determine the criticality level. In some cases it will be appropriate for the IM to work with the customer to determine the criticality level. The criticality matrix will comprise : Level, Criticality Level Definition, Typical Incident Categories, Initial Response Time, Ongoing Response (Critical Phase), Ongoing Response (Resolution Phase), Ongoing Communication Requirement CSIRT IMs must always apply the “need to know” principle when communicating incident details with other parties. The sensitivity matrix defines “need to know” by classifying cases according to sensitivity level. The ‘Required’ column defines the parties that “need to know” for a given sensitivity level. The ‘Optional’ column defines the other parties that may be included on communications, if necessary. Typically the IM will determine the sensitivity level. In some cases it will be appropriate for the IM to work with the customer to determine the sensitivity level. The sensitivity matrix comprises : Level, Sensitivity Level Definition, Typical Incident Categories, Required On Case Communications, Optional On Case Communications, and ITS Access. The work of Santos [Omar Santos, Oct 12, 2011] maintains that it is unfortunate (to say the least) that so many large Fortune 500 companies do not have a Computer Security Incident Response Team (CSIRT). He states that, on some occasions, their CSIRT consists of one part-time employee. Their Liability Insurers, Bankers, and Industry Regulators have much to say about this, no doubt, and the negative impact on the bottom line of the Companies in question (due to penal insurance premiums and regulatory sanctions, not to mention lost legal cases) must be considerable(!!). It is therefore critically important to have management support when creating CSIRTs. It is difficult and problematic, so say the least(!) to create a CSIRT without management approval and support. Also, such support must stretch far beyond budgets. It must include executives, managers, and their staffs committing their time to participating in the planning and improvement processes. Furthermore, it is equally crucial to get management commitment empower to the CSIRT - particularly as practical workplace experience shows that CSIRTs tread on some very senior feet indeed!! An effective CSIRT must always have the authority to make an emergency change within the infrastructure if the organization is either under attack or has been the victim of an attack!! Santos [2011], quite rightly, emphasizes that CSIRTs operate differently depending on the organization, its staff, their expertise, and budget resources. On the other hand, the best industry practices he describes apply generally to any organization. An extremely useful practice in practical workplace IS management is adopting the medical practice of triage. This is amply illustrated by Kabay [M. E. Kabay, PhD, CISSP-ISSMP, September 18, 2007], who emphasizes that the medical principle of triage applies equally well to computer information security incidents. He explains that during busy times and major incidents, prioritizing the CSIRTs responses is absolutely essential so that the CSIRT can make the best use of its time. The basic principle is to consider which systems and incidents need treating immediately and which can wait for the Team can get to them. After all, it is essential to seal the intrusion entries before fixing the servers, or the whole process will have to be repeated again later. Kabay[2007] considers that the triage principle is most appropriate to computer information security incidents, and works well for most types of emergency response. Taking a few minutes to analyze the situation and prioritizing the Teams responses will save far more time and effort than that immediately expended, as well as producing a far better work product. Kabay [2007] further emphasizes that no matter how well-honed an organizations processes and procedures are, every incident will be different. However, even with a single, simple incident, a CSIRT needs to look at and see how their procedures fit into the response. With a large-scale incident, it gets much trickier. As can happen in medical emergencies, there will most likely be not enough responders to go around. A CSIRT cannot possibly fix everything at once, so having a CSIRT that is skilled at triage is extremely important. Kabay [2007] summarizes his arguments by stating that triage is an essential element of any incident management capability, particularly for any established CSIRT. Triage helps to identify the most serious potential security problems and hence prioritizes the workload. 3. Defining Practical Computer Security Management Issues & Their Solutions When justifying setting up a formal CSIRT within an enterprise (this applies particularly to larger organizations), it must be made abundantly clear to the key decision makers that the enterprise’s Liability Insurers, Bankers and Industry Regulators will expect that such a capability is in place, well resourced and constantly updated technically. Otherwise, punitive legal and financial sanctions will be levied, which will also certainly put the organisation out of business(!). To begin with, a full-time enterprise ISO must be appointed, backed-up by a Director with specific IS responsibilities, who is therefore in a position when a particularly serious incident is underway and immediate Board-level decisions need to be made. The enterprise ISO must then form the CSIRT, which must consist not only of full-time IS experts, but must also have access to software and data communications experts in particular, as the most serious incidents will undoubtedly mean changes to the enterprise’s applications. As well as the team, the ISO must pay close attention to the technology, As well as having firewalls in place, whose rules are updated at least as frequently as the vendors and regulators demand, there must also be specialised systems that are able to analyze the traffic generated when a cyber-attack impacts the enterprise and also determine from where (particularly in terms of IP addresses) the attack was mounted. Having the team and technology in place, the necessary incident handling processes and procedures must then be put in place and regularly reviewed. This will mean an automated Incident Handling & Tracking system, which must not only record the details of the incident but also the measures taken to resolve it along with the progress of these. There must also be a process to disseminate the solutions to IS incidents and to ensure that those solutions are applied, promptly, decisively and without question. The ISO will also be responsible for training the enterprise’s staff in IS, in order to make them ‘think IS’ as they go about their daily tasks. This must cover not only specifically technical issues, but also the potentially suspicious behavior of the enterprise’s clients, both potential and actual. These points need to be hammered home by illustrations of what can happen when an IS incident gets out of control. The final, and in many cases most delicate, aspect of the ISO’s role is in liaising with the enterprise’s HR department regarding the human element. As well as the three-monthly Probity Checks mentioned above, measures must be taken to forestall issues that may result in employees becoming prejudiced against the enterprise, and hence open to overtures from not only competitors, but also hackers, criminal elements of all kinds, and even hostile political bodies (the latter applied with particular force to enterprises involved in Government work). The objective is to forestall the much-feared ‘inside job’ that is, in practice, the only viable way to ruin an enterprise’s information systems, external threats being a significant inconvenience by comparison. 4. Conclusions The works of Blackley, Layton and Peltier & Peltier are clearly backed-up by a very large body of practical workplace-based IS advice and experience, but almost entirely from a technical aspect. The sources examined in [2] above form a good sample of the amount and scope of IS work available and on which to build. That said, the concentration on technical aspects appears to have neglected the ‘human’ aspects, such as training, and further examination of material concerning IS training for modern enterprise’s is one obvious next stage in the overall IS incident management research process. Another aspect that will reward further examination is the psychological aspect, most notably how to maintain staff morale in a modern enterprise. Disgruntled and/or suborned employees have always been an often spectacular problem, but with modern technology and all key business and financial data how being held electronically as well as hard copy, the scope for data theft and the harm it will cause is far greater than it used to be, and all reasonable (and legal!) measures need to be taken to forestall it. Finally, the sources examined in [2] above give an excellent grounding in the practical measures that need to be taken to implement an effective information security incident management process, and hence will form an excellent foundation for a newly-appointed enterprise ISO to implement a truly effective system when one does not exist, as Kabay [2007] implies is often the case in [2] above. References Andrew Cormack, Miroslaw Maj, Dave Parker, Don Stikvoort . 15th September 2005. CCoP - CSIRT Code of Practice – approved version 2.1 v2.1/ Approved Version 15 September 2005. Retrieved from : https://www.trusted-introducer.org/CCoPv21.pdf Jose J. Gonzalez, Ying Qian., Agata Sawicka. n.d.. Managing CSIRT Capacity as a Renewable Resource . Management Challenge: An Experimental Study. Retrieved from : http://www.systemdynamics.org/conferences/2005/proceed/papers/SAWIC336.pdf M. E. Kabay. September 18, 2007. Network World. CSIRT Management: Triage. Students discuss triage in a CSIRT. Retrieved from : http://www.networkworld.com/newsletters/2007/0917sec1.html M. E. Kabay, PhD, CISSP-ISSMP . Assoc Prof of Information Assurance. School of Business & Management. Norwich University. 2009. CSIRT Management. Retrieved from : http://www.mekabay.com/infosecmgmt/csirtm.pdf Georgia Killacree. 2006. CERT. CERT/CC Overview & CSIRT Development Team Activities. Retrieved from : https://www.enisa.europa.eu/activities/cert/events/files/ENISA_An_overview_of_CERT-CC_Killcreece.pdf Timothy Proffitt. 2007. SANS Institute InfoSec Reading Room. Creating and Managing an Incident Response Team for a Large Company. Retrieved from : http://www.sans.org/reading-room/whitepapers/incident/creating-managing-incident-response-team-large-company-1821 Gavin Reid. Dustin Schieber, n.d.. CISCO. CSIRT Case Classification (Example for Enterprise CSIRT). Retrived from : http://www.first.org/_assets/resources/guides/csirt_case_classification.html Omar Santos. Oct 12, 2011. Cisco Support Community. Creating a Computer Security Incident Response Team (CSIRT). Retrieved from : https://supportforums.cisco.com/blog/150836/creating-computer-security-incident-response-team-csirt University of Scranton Information Security Office. 1/27/2009. Computer Security Incident Response Team Operational Standards. [Online]. Retrieved from : http://www.scranton.edu/pir/documents/CSIRT%20Operational%20Standards%20Manual.pdf Further Reading Blackley, J. A., Peltier, J., & Peltier, T. (2003) Information Security Fundamentals, 1st Edition. Boca Raton, FL. Auerbach Publications. ISBN: 08493-19579-9780849319570 Layton, T. (2007). Information Security: Design, Implementation, Measurement, and Compliance. Auerbach Publications Taylor & Francis Group. ISBN 08493-70876 Read More