IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS FOR STRATEGIC OPERATORS

Transcription

1 IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS FOR STRATEGIC OPERATORS A basic guide fr the prtectin f critical infrastructures January 2014

2 CONTENTS THE GUIDE S OBJECTIVE... 3 ACTIONS TO BE TAKEN IN THE EVENT OF AN INCIDENT... 4 RESPONSE... 4 IDENTIFICATION... 5 CONTAINMENT AND MITIGATION... 6 DATA LEAKAGE AND EVIDENCE GATHERING... 7 RECOVERY... 8 DOCUMENTATION... 9 REPORTING OF INCIDENTS HOW TO REPORT REQUIRED INFORMATION CLASSIFICATION AND PRIORITISATION SCALE OF INCIDENTS TYPES OF INCIDENTS CONCLUSIONS Authrs Jesús Díaz Vic Daniel Fírvida Pereira Marc Antni Lzan Merin Crdinatin Elena García Díez IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 2

3 1 THE GUIDE S OBJECTIVE This basic guide fr the prtectin f Critical Infrastructures, regarding the identificatin and reprting f security incidents fr Strategic Operatrs, is intended t serve as an actin guide fr the reprting and management f incidents related t Critical Infrastructures (CIs) and Strategic Operatrs, thrugh INTECO s Centr de Respuesta a Incidentes de Seguridad (Cmputer Emergency Respnse Team) (INTECO-CERT). It shuld be emphasised that the respnse t incidents in CIs is carried ut by INTECO in clse cllabratin with the Natinal Centre fr Critical Infrastructure Prtectin (CNPIC). The peratin f this service includes reprting security incidents t INTECO-CERT and CNPIC, the analysis f incidents, the extent t which their reslutin needs managing, and a respnse n the part f INTECO-CERT, including recmmendatins t reduce the security risk such incidents may suppse t peratrs. Fr easing the effective management f such incidents, this dcument sets ut guidelines and prcedures which thse peratrs wh suffer an incident may fllw, alng with an assessment f the severity f the incident. This infrmatin will be generated thrugh the assessment f incidents thrugh a system f incident management (in what fllws RTIR Request Tracker Incident Respnse). In this guide fr the identificatin and reprting f security incidents, althugh specific matters which deal with cncrete cases are included, cmmn criteria related t generally recgnised gd practices fr the management f incidents are defined, such that they may serve as a reference fr the design and implementatin f this type f service n a wider scale. This technical publicatin falls within the specific actin framewrk set ut by the Security and Industry CERT as defined by the agreement n Critical Infrastructure prtectin signed in Octber 2012 by the Secretaría de Estad de Seguridad (Secretary f State fr Security, SES), rgan dependent n the Ministeri del Interir (Interir Ministry), and the Secretaría de Estad de Telecmunicacines y para la Sciedad de la Infrmación (the Secretary f State fr Telecmmunicatins and the Infrmatin Sciety, SETSI), rgan dependent n the Ministeri de Industria, Energía y Turism (Ministry fr Industry, Energy and Turism), fr effective cperatin between CNPIC, law enfrcement agencies and INTECO in cybersecurity matters. IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 3

4 2 ACTIONS TO BE TAKEN IN THE EVENT OF AN INCIDENT In the event f a security incident, the main bjective is t recver the nrmal level f functining f systems r services, with respect t their quality and availability, minimising lsses as much as pssible. The prcess f being able t recver this level f nrmal activity, alng with actins t mitigate the incident s pssible cnsequences, and the prcess f acquiring and analysing evidence, make up the set f actins that need t be carried ut in the event f a security incident. What fllws here is a descriptin f the actins t be carried ut t mitigate the effects f security incidents and recuperate the affected systems, alng with an illustrating flwchart. RESPONSE The main phases f respnse fllwing an incident, shwn in figure 1, can be summarised as: identificatin, cntainment and mitigatin, preservatin f evidence and legal cnsideratins, recvery and dcumentatin 1. Figure 1: Actin flwchart in the event f a security incident 1 IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 4

5 IDENTIFICATION T identify a security incident, determine its extent and the systems affected by it, evidence can be gathered in a variety f ways determined by the nature and type f the incident. One f the main methds is the analysis f lgs and ther surces f infrmatin fr detecting anmalies. Such surces include: Anti-virus cnsles. Intrusin Detectin and Intrusin Preventin Systems (IDS/IPS). Security Infrmatin and Event Management (SIEM) warnings. Inspectin f audit lgs t identify attempts at unauthrized access. Lgs f cnnectins blcked by firewalls. Lgs f cnnectins made by crprate prxies. Data Lss Preventin (DLP) tl lgs. Blcking f user accunts r ther anmalies reprted t the CAU r which imply risks such as lss f USB devices r laptps. Sudden and excessive use f memry r server disc space. Traffic anmalies, such as cnsumptin peaks at unusual times. Netwrk dumps, thrugh, fr example, prt mirrring, which may allw the cnfirmatin f a suspected incident. The detectin f these types f anmalies allws the identificatin f a pssible security incident, alng with its nature and extent. Shuld any f these recrds present anmalies, a mre detailed analysis t determine whether there actually has ccurred an incident will need t be carried ut. Such an analysis may be carried ut, fr example, thrugh the detectin f malicius netwrk traffic, identifying the affected infrastructure, the hst and destinatin addresses, the used prt values, TTL, prtcls, etc. These actins will help t determine if there has really been a security incident, and its nature. At a system level, ways f finding ut if the incident has been having effects include: Unusual r especially privileged user accunts. Hidden files, r files that appear suspicius because f their size, file name r lcatin, pssibly indicating a data r lgs leakage n the part f malware. Files with unusual permissins, with SUID r GUID, with unusual paths, rphan files, indicating the pssibility f sme kind f intrusin r rtkit. Suspicius registry entries, mainly in the case f Windws systems with malware infectins, this being ne f the main ways malware assures its persistence in the infected system. Unusual prcesses and services, nt nly listening services but thse with cnnectins t prts r hsts that are strange, unusual, r which appear n blacklists f Cmmand and Cntrl servers used by btnets. Excessive disc r memry lads, which may be prvked by a security incident invlving malware, denial f service r intrusins. Sessins in a device pened by ther devices, ARP table anmalies, unusual shared flders, an elevated number f anmalus active TCP cnnectins, which may indicate a denial f service attack. IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 5

6 In the case f user equipment r mbile devices, the fllwing may indicate sme kind f system infectin, amngst thers: anmalus sharing f applicatins, navigatr pp-up windws, slw cnnectins, rebts r applicatins which clse withut warning. Scheduled tasks r unusual activity in lg files, which may indicate an abnrmal system functin r intrusin attempts int a given service thrugh, fr example, brute frce. Alerts f the crprate anti-virus platfrm, r ther tls nrmally deplyed t identify rtkits, t carry ut integrity checks n files, binary file signatures, etc. Installing such tls n pssibly infected systems ad hc is nt recmmended, since access dates may be altered, and evidence lst. In additin t these measures t identify security incidents in affected devices, it cannt be ruled ut that an incident may be identified by means f an external data surce, a CERT reprt, r a reprt frm anther bdy, r frm a user external t the rganisatin, etc. CONTAINMENT AND MITIGATION Once the incident has been identified, it is necessary, using the data already gathered, t cntain it and mitigate its effects. In rder t d this it is essential t define the extensin f the incident, the kinds f devices affected, and their cmmn characteristics in rder t be able t islate the incident accrding t this data. In additin, it is imprtant t be well prepared befre the event. Tls such as an up t date inventry f assets, a map f the netwrk architecture, IDS/IDP intrusin detectin, event management tls (SIEM) and firewalls will help t determine mre precisely the character f the incident and hw t cntain it. Once the incident has been detected, it is key t define its extent, whether an infectin is being dealt with, the type f equipment affected, identifying cmmn characteristics (perating system platfrms, the specific type f wrkplaces, single servers, etc.) in rder t determine the extent f the infectin and be able t take measures t islate it accrding t the cnfiguratins identified. The mst imprtant recmmendatins fr the cntainment and mitigatin f a security incident which may be applied at this stage are: Discnnecting the equipment r netwrk segment frm the rest f the rganisatin s netwrks. This can be dne, in the case f an islated device, by directly discnnecting the netwrk cable, r islating a netwrk segment in a VLAN r similar. In the case f the infectin ccurring in a critical device, strictly necessary traffic may be islated thrugh setting up a firewall between this element and the rest f the netwrk, allwing nly traffic strictly necessary fr the system s functining. If the type f incident has been identified, and technical details are knwn, such as the malware s spread vectrs, the behaviur pattern f a denial f service, r the characteristics f an intrusin attempt thrugh brute frce, it is pssible t apply cntainment measures mre apprpriate fr a given set f circumstances. Fr example, blcking specific s, the access t shared equipment, utging cnnectins, r any malware infectin vectr thrugh firewall plicies and rules. In the same way, it is pssible t prgramme filter rules fr denials f service r attempts at intrusin. In the case f a vulnerability which culd result in intrusin r denial f service, all IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 6

7 the mitigating prcedures recmmended by the manufacturer have t be applied, and the recmmended patches installed. If the system is a critical ne, in which, fr whatever reasn, it is nt pssible t apply the patch r the threat mitigatin measures, the manufacturer will need t be cntacted s that alternative slutins may be evaluated and btained. DATA LEAKAGE AND ACQUISITION OF EVIDENCE T avid data leakage it is fundamental t identify the leak vectr and then adpt the apprpriate technical measures t limit its explitatin, whether these be restricting access t shared flders, disabling prtable strage systems (USB devices, fr example), blcking URLs r , etc. In additin, the repercussins f the leak will have t be quantified. It may result that the data leak is related t the access credentials f a given user f a given system in the rganisatin, which have been made public. In these cases, it may be necessary t cnsider invlving the rganisatin s legal resurces, and thse f Human Resurces and cmmunicatin in rder t utline a glbal strategy t deal with the leak. Once the security incident and the equipment affected have been identified, and the latter islated frm the rest f the netwrk, the next step is the preservatin f data fr frensic analysis f the incident. Vlatile data will have t be extracted frm memry befre shutting dwn the system. The data stred in the equipment s memry may turn ut t be very imprtant in analysing cases f malware r intrusins, and, n shutting the system dwn, they will be lst. Thus, as far as pssible, measures fr their acquisitin will have t be taken befre shutdwn. T acquire this data frensic tls designed fr this end may be used. Nevertheless, neither the system nr its data shuld be altered in this prcess, since imprtant data, such as file access dates, may be crrupted, r evidence lst. Once this data has been acquired, mechanisms fr preserving their integrity have t be put int effect, thrugh the applicatin f apprpriate cryptgraphic hash functins. In ding this, there are varius criteria that have t be taken int accunt. On the ne hand, mst frensic analysis tls supprt the MD5 and SHA1 functins, while mre advanced functins, such as thse f the SHA2 family, are less widely supprted. On the ther hand, MD5 and SHA1 entail a lwer cmputatinal cst, in return fr a smewhat lwer level f cryptgraphic security as well, while SHA2 functins are mre cllisin resistant, at a cst f being mre cmputatinally intensive. This is an imprtant factr, given that memry dumps are typically greater than 512 MB. Therefre, while the final decisin will depend n the resurces (tls and cmputing capacity) available, it will be necessary t balance cst and security. In mst cases, btaining bth MD5 and SHA1 hashes fr the data t be backed up will prvide a slutin acceptable bth in terms f rbustness and cst. IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 7

8 The main tls fr the acquisitin f vlatile data frm memry are: In the case f UNIX/Linux systems, LiME 2 run frm a USB device cnnected t the cmprmised system, taking int accunt that the tl has t have the same kernel as the cmprmised system cmpiled and that the necessary libraries have t be included in the USB device. The Vlatility 3 tl is als available fr UNIX/Linux systems, and can als be run frm a USB device. Again, the same kernel has t be cmpiled, and the necessary libraries included. Fr Windws systems, tls such as FTK Imager 4, DumpIT 5, Memry DD 6 Memryze 7 can carry ut a system memry dump, r dumps f paging files and prcesses. Again, using Vlatility, an analysis f the data extracted can be carried ut. In virtual systems, RAM is fund in.sav files in VirtualBx, and.vmen files in the case f VMWare. Once the prcess f vlatile data acquisitin has been cmpleted, the system can be shut dwn. In rder t avid any unexpected behaviur n the part f any malware r rtkit used fr intrusin in ding this, cutting the pwer t the system, by directly unplugging the pwer cable, is recmmended. RECOVERY Once evidence has been preserved and the incident reprted, the next step t be taken is t recver the affected systems. In the case f incidents caused by an intrusin r the intrductin f malware int a nn critical system, nce the infectin r intrusin vectr has been detected and the pprtune crrective measures t prevent the incident ccurring anew established, the system affected by the incident may be restred using a backup carried ut prir t the infectin. In the case f critical systems which are nt high availability, the value f realising peridic cpies f the whle system (and nt just f data) may have t be included in business cntinuity plans. This wuld allw the recvery f nrmal activity in the case f incidents ccasined by malware r intrusins, taking int accunt that the riginal attack r infectin vectr will have t be prevented r blcked. In any case, with critical systems, the manufacturer s instructins fr recvery r reinstallatin will have t be fllwed, prgramming the crrective maintenance and dwntime necessary in rder t recver frm the incident. In the same way, in incidents related t vulnerabilities the manufacturer s recmmendatins fr mitigating r slving the vulnerability will have t be fllwed, applying the fficial patches released by the develper. 2 LiME: 3 Vlatility: 4 FTK Imager: 5 DumpIT: 6 Memry DD: 7 Memryze: IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 8

9 DOCUMENTATION In the management f security incidents it is f great imprtance t dcument all that has been learned frm previus incidents. These lessns learned may prve vital in aviding future security incidents r reslving new incidents f similar characteristics It is imprtant that this dcumentatin be detailed, such that it be knwn which tls were used and hw, the investigatins which were carried ut and what their results were, the partnerships that were necessary, the dcumentatin used t reslve the incident, the time line f actins fllwed, etc. All this serves t identify with precisin the nature and type f the incident, its characteristics, the malware r intrusin infectin vectrs, nt nly t be able t cnfigure security systems adequately but als t carry ut rganisatin-wide awareness campaigns fcused n what the weak pints f the system are and hw t prtect them. In additin, this infrmatin allws the perpetratrs f such attacks, their strategies, and denial f service patterns t be knwn. Identifying new vulnerabilities which affect the mst critical systems f an rganisatin will als help in great measure t avid and reslve pssible security incidents. All these technical and prcedural steps f an rganisatin always have t take int accunt nt nly the legal cnsideratins relevant fr the rganisatin accrding t its sectr and scpe but als principles f privacy f cmmunicatins and f persns, the penal cde, etc. These cnsideratins need t be taken int accunt thrughut the reslutin f an incident, and especially when acquiring data in the case f a frensic analysis. IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 9

10 3 REPORTING OF INCIDENTS One f the tasks f INTECO-CERT and CNPIC is respnding t security incidents reprted as ccurring in Critical Infrastructures by users f this service, and ensuring that the relevant infrmatin is stred in RTIR. In what fllws, a descriptin is given f the infrmatin necessary bth t crrectly realise an infrmatin reprt n the part f the peratrs, and t facilitate cmmunicatin between INTECO-CERT, CNPIC and the peratrs This descriptin fllws the scheme shwn in Figure 2. Figure 2. Steps t reprt an incident IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 10

11 HOW TO REPORT Security incidents are reprted thrugh the user wh, having been identified as a pint f cntact f the invlved rganisatin, and acting as a representative f it, accesses the incident reprting service thrugh an sent t pic@cert.intec.es. With this infrmatin an Incident Reprt will be generated in RTIR. All infrmatin exchanges with the user will be perfrmed by frm RTIR, frm the address pic@cert.intec.es., with the standard subject-line field [INTECO-CERT/CNPIC #***] (*** being the reprt number created by the user). In this way, all exchanged s will be stred in the same reprt, allwing their full mnitring. As an exceptin, if the incident is cnsidered sufficiently relevant, cntact will be made with certain users by telephne. This cntact will be cnsidered cmplementary t the prcedure detailed belw. All s sent frm the pic@cert.intec.es accunt will be digitally signed with the private key that belngs t that accunt. In additin, when the exchanged infrmatin is cnfidential (lgs cntaining credentials, cnfidential r persnal infrmatin), the relevant s will be encrypted by the INTECO-CERT technician wh carries ut the ntificatin. REQUIRED INFORMATION The infrmatin that has t be included in a reprt f a security incident, s that a reprt be generated in the RTIR tl by the INTECO-CERT technician, has t include all the infrmatin that the user cnsiders necessary fr the incident s reslutin; fr example, a descriptin f the incident, the elements invlved, sftware versins, the nature and type f incident (if knwn), the IPs and hsts invlved, etc. With this infrmatin, the mderatr f the RTIR incidents queue wh has received and lgged the reprt will create a new incident frm the user s reprt. The incident will include the fllwing data: Subject: This is a sentence which describes the incident in general frm. This field will be inherited by all the investigatins pened in assciatin with the initial incident. By default, the subject field appears in the reprt frm the pint at which it is created, fr which reasn it can be either kept r replaced by a mre explanatry name with the fllwing frmat: [Cmpany name]* Textual descriptin f the incident * Only if identified Descriptin: This is a brief descriptin f the incident. The mderatr f the queue will use this field t make imprtant cmments abut the incident. Functin: Cnsultatin r Incident. By default, Incident. Classificatin: This defines the incident accrding t the categries defined in the Types f Incidents sectin f this dcument. IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 11

12 Level: This indicates the level f supprt the incident requires, accrding t the levels defined in the Scale f Incidents sectin f this dcument. By default, this is set t level 1. Message: By default, the bdy f the message reprting the incident sent by the user. The mderatr will add cmments if necessary and if necessary remve thse fields left blank by the user. This message will als include all the infrmatin which the persnnel f the strategic peratr have been able t identify during the identificatin f the incident, including files, memry dumps, and any ther infrmatin relevant t the incident. Pririty: This indicates the level f pririty f the incident. The levels f pririty are defined in the Classificatin and Priritisatin sectin f this dcument. CLASSIFICATION AND PRIORITISATION Fr INTECO-CERT t be able t supply cnsistent and pprtune respnses/slutins t the user and ensure that sensitive infrmatin is managed apprpriately, incidents have t be classified and priritised crrectly as sn as they are recrded in RTIR. Nevertheless, INTECO-CERT will be able t mdify the classificatin and priritisatin f security incidents during their reslutin, the values referred t remaining recrded in RTIR. Accrding t an incident s pririty, the levels referred t are the fllwing: - High: Incidents which affect systems r data critical fr the peratr, and which may have a ptential impact n the business. These incidents are typically: destructive malware, denial f services r cmprmised system, and certain cases f hacking and plicy vilatins which affect critical systems. - Medium: Incidents which affect systems r data which are nt critical fr the peratr r whse impact des nt have direct business repercussins. In this categry are included the majrity f hacking and phishing incidents, alng with, in certain cases, plicy vilatins and ther cnsultatins. - Lw: Pssible incidents in nn-critical systems, investigatins requiring frensic analysis whse time scale is prlnged, r general cnsultatins regarding security. This level includes the majrity f cnsultatins and invasive attacks, alng with incidents f any ther type which affects systems with a lw level f imprtance r little business impact. The different types f incidents cntemplated here are set ut in the Types f Incidents sectin f this dcument. SCALE OF INCIDENTS Here it is defined the methdlgy f grading security incidents, s that supprt be given and incidents managed n the part f INTECO-CERT. Level 1: Level 1 security peratrs carry ut primary care activities with respect t the reprts and cnsultatins that INTECO-CERT receives and take actin in the cases f the mst trivial incidents (incidents which d nt require and expert security level). IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 12

13 They mnitr all pen reprts and incidents and generate all necessary dcumentatin. They respnd t and give supprt fr attacks r incidents such as: Respnses t requests fr infrmatin (cnsultatins). Knwn attacks r attacks whse identificatin is immediate. Mnitring and respnse t public vulnerabilities. Identificatin f defects and risks in the netwrk tplgy r security systems. Identificatin f defects and incidences f internal security prcedures and plicies (systems, develpment, security, etc.). Incidents which require a high level f expertise in security are classified at level 2. Level 2: This is an expert team which respnds t incidents which require a high level f expertise in security. Incidents are scaled up frm level 1 t level 2 by the level 1 team. The level 2 team analyses and respnds t security attacks r incidences such as: Unknwn attacks, r attacks that are difficult t identify. Analysis f suspicius vulnerabilities r incidents that require expert knwledge. Supprt and cnsultatin n existing netwrk tplgy r the adequate cnfiguratin f security devices. Identificatin f relatins between incidents and defects in security and supprt prcedures and plicies. Evaluatin f risks and the impact f vulnerabilities and attacks. Intrusin Tests. Analysis f the impact and real risks f existing vulnerabilities. CNPIC: In additin, CNIPC s Servici de Seguridad Lógica (Lgical Security Service) will be infrmed by means f , and may see itself invlved in the management f an incident, cntributing its specific experience in sme f the main issues related t the prtectin f critical infrastructures, such as: Previus experience in industrial cntrl systems. Prviding cntacts with ther centres and peratrs in rder t facilitate a mre effective incident management. Ntifying cntacts f peple inside rganisatins, with whm there already exists a previus relatinship, in case f need. Legislatin applicable t Critical Infrastructures Prtectin in Spain. IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 13

14 4 TYPES OF INCIDENTS The incident s characteristics determine what actins have t be undertaken t reslve it. In general, the fllwing types f incidents shuld be cnsidered: - Denial f Service: Incidents related t denial f service attacks (DS) r distributed denial f service attacks (DDS). These are very dangerus, since they are able t affect the availability f Strategic Operatrs critical systems. - Malware infectins: Incidents prvked by malware (viruses, wrms, trjans, lgic bmbs, spyware, rtkits, etc.). The severity f these depends n the malware; they can result in data theft, r can affect system availability. The mst cmplicated aspect here is detectin and identificatin, wing t the incrpratin f rtkits. - Cmprmised systems: Any cmputer system, piece f hardware r sftware, which is being r has been successfully attacked. Examples: theft f cnfidential infrmatin, changes in system cnfiguratins, etc. - Hacking: Any suspicius activity r traffic which can alter the functining f a system and which is related t an attempt at intrusin. Examples: attempted unauthrised system access r service scans - Malware distributin: Incidents in which an rganisatin s public server is used t distribute malware. These incidents put third parties at risk. - Plicy vilatins: Inadequate use f system assets, such as unauthrised scaling f privileges r attempts t circumvent access cntrls systems. - Invasin attacks: Any kind f attack against authrisatins, authenticatins, permissins, rights ver files r interceptin f . - Vulnerability: Any type f incident prvked by the explitatin f a system vulnerability. In additin t these categries, which may be cnsidered cmmn, the evlutin f technlgy and the cmplexity f attacks mean that ther types f incidents will inevitably ccur. IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 14

15 5 CONCLUSIONS This guide has set ut the steps that have t be taken in rder t identify and manage security incidents. Cncretely, the measures t take in the case f an incident are cmpsed f its identificatin, cntainment, the preservatin f evidence, and legal cnsideratins. The prcess t fllw in rder t reprt incidents has als been set ut, using as a principal frm f cmmunicatin the pic@cert.intec.es mailbx, which cmmunicates with the RTIR (Request Tracker Incident Respnse) system. The user wh reprts the incident will include in the reprting all the infrmatin cnsidered necessary, which will in turn be used by the RTIR incidents queue mderatr t create a new incident. The general steps that will be fllwed in the prcess frm the initial reprting f the incident t its reslutin are: receipt f the user s reprt, identificatin and relevance, analysis f the reprt, classificatin, triage, reslutin and clsure f the incident. In additin, in rder t assist in the management and reprting f incidents, a general classificatin, based n the main characteristics which pssible security incidents may present, has been put frward. Cncretely, incidents including thse f denial f service, malware infectin, cmprmised systems, hacking, invasin attacks and vulnerabilities have been defined. As a guide fr the identificatin and reprting f security incidents, althugh specific matters which can nly be applied in cncrete cases as they develp have been dealt with, the general criteria set ut meet the standards f generally recgnised best practices fr the management f incidents, and, as such, may serve as a reference fr the design and implementatin f this type f service in ther fields. IDENTIFICATION AND REPORTING OF SECURITY INCIDENTS A basic guide fr the prtectin f CI 15