Information Security Incident Management Guidelines. e-governance

Transcription

1 Information Security Incident Management Guidelines for e-governance Draft DEPARTMENT OF ELECTRONICS AND INFORMATION TECHNOLOGY Ministry of Communication and Information Technology, Government of India.

2 Document Control S/L Type of Information Document Data 1. Document Title 2. Document Code 3. Date of Release 4. Next Review Date 5. Document Revision Number 6. Document Owner 7. Document Author(s) 8. Document Reference Document Approval Sr. No. Document Approver Approver Designation Approver ID Document Change History Version No. Revision Date Nature of Change Date of Approval For Internal Use Only Page 2 of 17

3 Table of Contents 1. INTRODUCTION SCOPE PURPOSE ROLES AND RESPONSIB ILITIES INCIDENTS AND INCIDE NT RESPONSE CLASSIFICATION OF SE CURITY INCIDENTS INCIDENT CATEGORY INCIDENT TYPE RECORDING AND ROUTIN G AN INFORMATION SEC URITY INCIDENT RESOLVING SECURITY INCIDNET IT SECURITY INCIDENT NON IT INCIDENT CLOSING SECURITY INCIDENTS ESCALATION M ATRIX POST IMPLEM ENTATION REVIEW REFERENCE For Internal Use Only Page 3 of 17

4 1. INTRODUCTION Any event which is not part of the standard operation of a service and which causes or may cause an interruption to or a reduction in the quality of that service is referred as an incident. Any incident which compromises the confidentiality integrity and/or availability of e-gov service delivery operation and has a negative impact to e-gov service delivery is to be considered as an incident. Depending the area of the incident, there may or may not be a requirement to report an incident.. 2. SCOPE This Procedure applies to all e-gov service delivery employees, service providers, System Integrators, consultants, temporary staff and other individuals even if, affiliated with Third Parties, who have access to e-gov service delivery Information/ Information Processing Facilities. 3. PURPOSE This procedure is used for detecting and reporting incidents relating to exceptional situations in day-to-day administration of operational services. It should be ensured that the incidents are reported in time to the appropriate persons /authorities and corrective actions are taken immediately to avoid the recurrence of such events in future. For Internal Use Only Page 4 of 17

5 4. ROLES AND RESPONSIBILITIES User User reports the Security Incident via the various sources of reporting including , Telephone, etc. Service desk Log a ticket for every security incident reported Classify the security incident as either Non-IT ( Physical) or IT based on the description Inform user of the ticket being logged Incident Manager Incident Manager must be selected from composite team in the data centre. Classify the security incident in terms of the parameters: Category, Impact, Urgency, Priority based on the description Delegate/ assign the security incident to the appropriate second level support in SIRT. Inform user of the incident being assigned to the respective second level support Security Incident Response Team (SIRT) Security Incident Response Team (SIRT) is a group of people responsible for responding to a security incident reported or detected in the organization. SIRT is essential for a prompt and correct response to an information security incident so it can be contained, investigated and recovered from in a timely manner thereby reducing loss to the organization. Investigate and Diagnose the security incident For Internal Use Only Page 5 of 17

6 Collect information/evidence Preserve the information/evidence securely Perform Root Cause Analysis of security incidents Provide recommendations for closure/resolution of security incidents In case the incident has a Extensive/ Widespread impact, then send the recommendations to CISO for review On approval of the recommendations, resolve/ recover the security incident Prepare a CAPA for the security incident Prepare a document on lessons learned from the security incident Inform the user of the resolution/ recovery of the incident 5. INCIDENTS AND INCIDENT RESPONSE A computer security incident is defined as: A real or potential violation of an explicit or implied security policy. Some examples of categories of security Incidents, but not limited to list below are: Attempted or successful unauthorized access, use, disclosure, modification or destruction of information. Interference with information technology operation. Violation of explicit or implied acceptable usage as defined in the e-gov Security Policy. Unauthorized use/disclosure of information. Compromised user account. Loss or theft of information assets. For Internal Use Only Page 6 of 17

7 Unwanted disruption or denial of service attack. Changes to information assets without the owner's knowledge, consent, or instruction. Possible virus/spam in s. Loss or theft of critical data. 6. CLASSIFICATION OF SECURITY INCIDENTS A security incident is defined as the act of violating the security policy. The following is an illustrative list of what actions can be classified as incidents: Attempts to gain unauthorised access to a system or its data; masquerading, spoofing as authorised users; Unwanted disruption or denial of service; Unauthorised use of a system for the processing, transmitting or storing data by authorised/ unauthorised users; Changes to system hardware, firmware or software characteristics and data without the knowledge of application owner; and/ or Existence of unknown user accounts 6.1 INCIDENT CATEGORY Service Desk team shall refer the Categorization Matrix to categorize the identified Security Incident. Incident manager shall guide the service desk to in categorization of incidents. Categorization helps incident staff for identifying the service impacted, and assigning the call to right resource for quicker resolution Impact For Internal Use Only Page 7 of 17

8 For the purpose of measuring service level, all logged problems shall be classified as per the following definition: 1 - Extensive/ Widespread 2 - Significant/ Large 3 - Moderate/ Limited 4 - Minor/Localized The classification will be decided by the Incident Manager and may change based on the perception of the problem. Urgency In order to assess the urgency of resolution for business, all logged problems shall be classified as per the following definition: 1 - Critical 2 - High 3 - Medium 4 - Low Priority Service Desk shall then refer the Prioritization matrix to prioritize the identified / qualified Security Incident Call. Prioritization is done based on the urgency and impact to business as per the following scale: 1 - Critical 2 - High 3 - Medium For Internal Use Only Page 8 of 17

9 4 - Low 6.2 INCIDENT TYPE The reported incident can be classified as a Non IT security Incident or IT Security Incident if it violates the e-gov Security Policy. This classification is done by the Service Desk. IT Security Incident: an event which has a notable negative impact on the Organization s information security. An IT security incident falls under any of the following types: Unauthorized access into IT Systems (such as intrusion, virus attack, etc.) Exploitation of security weaknesses / vulnerabilities Misuse of information systems resources Violation of e-gov security policies and procedures Violation of applicable legal laws and other regulatory conditions Human Errors Uncontrolled system changes Service, facility or equipment loss Non-IT Security Incident: any event which has a notable negative impact on the Organization s information security and information/it assets and is non-technical in nature such as: Lapse in physical security Thefts Fire For Internal Use Only Page 9 of 17

10 Environmental hazards Critical information security incidents - Incidents which lead to major financial loss / business disruption / compromise of confidentiality, integrity and availability of business resources are critical incidents Non Critical information security Incidents Incidents with low or minimal financial / business impact are non-critical security incidents. For Internal Use Only Page 10 of 17

11 Table Information Security Incidents Classification Non-IT Security Incidents IT Security Incidents Non-Critical Critical Non-Critical Critical Employee, contract staff, visitor without identification tag Information through: leaked Computer system break-in Visitor unescorted in sensitive areas Oral / verbal communication Forgotten password Unauthorized use of user accounts Unsupervised visitor movement Unauthorized equipment brought into secure areas by employee, contract staff or visitor Unauthorized use / removal of storage media Photocopy Document transfer Fire Natural disaster (Flood, earthquake, etc.) Theft Physical damage Internal E- mail spamming Anti-virus software not updated on desktop Hacking / Phishing Unlicensed software loaded Denial of service (DOS attack) Virus attack 7. RECORDING AND ROUTING AN INFORMATION SECURITY INCIDENT For Internal Use Only Page 11 of 17

12 All users of information and IT assets of the e-gov service delivery will inform Service desk immediately on actual or potential occurrence of security incident in either of following ways to: XXXXXXXXXXXXX Telephone: XXXXXXXXXXX Anonymous reporting through drop box which will be opened mid-day and EOD Incidents reported to Service desk will be recorded by Service desk. If security incident is reported through a call, then Service desk personnel will listen patiently to the caller note incident location ensure that the same incident is not recorded twice record the call in the Security Incident register Classify as IT Security Incident or Non-IT Security Incident generate an incident ticket If security incident is reported through a /drop box then Service desk personnel will note incident location ensure that the same incident is not recorded twice record the call in the Security Incident Register Classify as IT Security Incident or Non-IT Security Incident generate an incident ticket For Internal Use Only Page 12 of 17

13 Service desk will Forward the incident to nominated persons of SIRT for action. 8. RESOLVING SECURITY INCIDNET 8.1 IT SECURITY INCIDENT SIRT team will analyse the incident for its impact investigate the source and cause of the incident resolve the incident and implement corrective action by consulting technical team such as system administrator, Network Security Team identify existing vulnerabilities resulting in the incident and implement preventive action if possible record the action taken Inform Service desk for closure the incident call. Resolving Critical IT Security Incident Incident manager will inform Information Security Steering Committee (ISSC) and CISO about the severity of the incident SIRT will will forward the incident to SIRT identify the root cause of the incident in consultation with NOC In- Charge implement corrective action Report to CISO about closure of the incident. For Internal Use Only Page 13 of 17

14 identify the existing vulnerability that caused the incident and a preventive action and inform the same to CISO Incident Manager record the action taken Inform Service desk for closure the incident call. maintain the Corrective / Preventive Action Report for all such non-it security incidents. submit a summary report of security incidents along with Corrective Action and Preventive Action (CAPA) to CISO and request approval and resources/fund for implementing the preventive action implement the same if approval is received 8.2 NON IT INCIDENT SIRT will analyze the incident for its impact and urgency. investigate the source and cause of the incident identify existing vulnerabilities resulting in the incident Incident manager will determine and implement corrective action if any and close the incident if possible prepare the Incident Summary Report and the same to Service desk for resolution and preventive action forward incident report to HR Department if disciplinary action is required ISSC if resources/funds/legal support required to implement corrective action to close the incident and preventive actions to ensure the incident does not recur For Internal Use Only Page 14 of 17

15 on resolution will inform Service desk to close the incident will maintain the Corrective / Preventive Action Report for all such non-it security incidents. will submit a summary report of security incidents along with Corrective Action and Preventive Action (CAPA) to CISO. 9. CLOSING SECURITY INCIDENTS Service desk personnel will Update the knowledge base for future reference. close the incident and update the Security Incident Register For Internal Use Only Page 15 of 17

16 10. ESCALATION MATRIX Following is the escalation matrix department-wise, which shall need to be revised appropriately whenever there is a change in role or attritions by means of posting / transfer etc: Sr. No. Department Escalation - 1st Level Escalation - 2nd Level Escalation 3 rd Level Name: Name: Name: 1 ID: ID: ID: Contact No: Contact No: Contact No: 11. POST IMPLEMENTATION REVIEW Once the incident issues are addressed, follow up activity must be done for critical incidents that improve the incident handling procedures. Follow-up activity is intended to include the following: Analyzing what has transpired and what was done to intervene Was there sufficient preparation for the incident? Did detection occur promptly or, if not, why not? Could additional tools have helped the detection and eradication process? Was the incident sufficiently contained? For Internal Use Only Page 16 of 17

17 Was communication adequate, or could it have been better? What practical difficulties were encountered? Was the incident caused due to negligence or malicious intent on part of an employee? If suspected guilty, PIR report must be forwarded to HR for initiating disciplinary proceedings How much is the associated monetary cost/ time? How much did the incident disrupt ongoing operations? Were any data irrecoverably lost, and, if so, what was the value of the data? Was any hardware damaged? "Lessons learned" must be included in the Security Incident Summary Report The Incident Summary Report must be prepared by CISO/Designated personnel and shared with the Information Security Steering Committee (ISSC) Developing effective policies and procedures is an iterative process in which feedback from follow-up activity in the form of discussion on Incident Summary is essential. This activity will be performed by ISSC in its meetings. "Lessons learned" contained in the Security Incident Summary Report form will be used as the basis for modifying the activity's incident response policies and procedures. Below Template can be used as a Post Incident Review report: Post Incident Review_ TEMP V 0.1.docx 12. REFERENCE Information Security Incident Mange policy in e-gov Security Policy For Internal Use Only Page 17 of 17