security management plan example€¦ · web view[agency name]security incident management plan —...

[Enterprise Agency Name] Security Incident

Management Plan

Last Updated:08/08/2017(Version 008)

[Agency name] Security Incident Management Plan — DRAFT

Contents1. Purpose....................................................................................................................................32. Objective..................................................................................................................................33. References and Resources.......................................................................................................34. Definition of a Security Incident.............................................................................................45. Roles and Responsibilities.......................................................................................................5

5.1 Roles Provided by DoIT Security Operations)..............................................................55.1.1 Role: System or Network Monitor.....................................................................55.1.2 Role: Incident Handler.......................................................................................6

5.2 Roles Provided by the Agency.......................................................................................65.2.2 Role: Data Owner(s)..........................................................................................65.2.3 Role: Security Manager.....................................................................................75.2.4 Role: User..........................................................................................................8

6. Incident Reporting and Management......................................................................................86.1 User Reports an Incident................................................................................................86.2 Continuous Monitoring Service Escalates an Alert.......................................................96.3 Incident Handling...........................................................................................................9

7. Reporting and Metrics...........................................................................................................107.1 Reporting on Monitoring and Incident Handling.........................................................107.2 Management Reporting................................................................................................107.3 Regulatory Reporting...................................................................................................10

8. Signatures and Approvals......................................................................................................11Appendix A: Acronyms and Definitions.......................................................................................12Appendix B: Confidential Data Under [Enterprise Agency Name] Stewardship..........................13Appendix C: [Enterprise Agency Name] and DoIT Security Operations Center Escalation and

Contact Information...............................................................................................................14Appendix D: Steps to Preserve State of a Suspect Device............................................................16Appendix E: Incident Parameter Definitions.................................................................................18Appendix F: Security Reporting for the Agency...........................................................................19Appendix G: Incident Response Process Flow Defined by NIST SP 800-61R2..........................20

ExhibitsExhibit 1: Roles and Responsibilities During Security Incident Response.....................................5Exhibit F-1: Incident Response Life Cycle modified from NIST 800-61R2, Computer Security

Incident Handling Guide.......................................................................................................20

document.docx::1/9/2018 5:28 PM

page 2 of 23


1. PurposeSince one of the primary goals for cybersecurity is to ensure the confidentiality, integrity, and availability of data and assets owned by or under stewardship of the Maryland Department of Information Technology (DoIT) Enterprise and its subscribers, the purpose of this plan is to provide guidance for Enterprise agencies and subscribers to effectively identify, report, respond to, and mitigate information security incidents.

Cybersecurity incidents refer to errors or activities that are not part of a standard information technology service operation and pose a risk of compromise or loss of information.

Discovering and reporting incidents as promptly as possible can minimize overall damage (before it “spreads”) and reduce the cost of incident handling. This Security Incident Management Plan provides DoIT and Enterprise agencies with specific contact information to encourage timely reporting and requests detailed escalation instructions to help minimize the adverse impact of security incidents.

2. ObjectiveThe objective of this plan is to identify the policies, services, procedures, and requirements that help provide stable, effective incident management for an agency, and to help meet incident-management requirements in accordance with the Maryland DoIT Incident Response Policy.

Main objectives include:

Establish the organizational obligations for monitoring, reporting, and responding to cyber incidents, including roles and responsibilities for incident reporting and handling (Section 5)

Identify data under agency ownership that must be protected or may require special reporting if compromised (Appendix B)

Identify the persons responsible for cybersecurity within the agency and to provide specific contact information (Appendix C)

Outline steps to preserve incident data when security incidents are discovered (Appendix D)

To identify security reporting for the agency (Appendix F)

3. References and ResourcesThis plan incorporates by reference DoIT cybersecurity policies and their requirements. All agency personnel, business partners, and staff affiliated with third parties who have access to this agency network are required to ensure compliance with these policies at all times.

DoIT Policies and Standards

DoIT Incident-Response Policy DoIT Acceptable Use Policy


page 3 of 23


Regulatory Security-related Requirements

List any regulatory rules in Appendix B that your agency or system must comply with, e.g., requirement to report data compromise or breach of HIPAA information

Reference Standards and Best Practices

Additional security practices and standards may be adopted from resources below.

CIS Security controls, https://www.cisecurity.org/critical-controls.cfm NIST Special Publication 800-12, An Introduction to Computer Security: The NIST

Handbook, November 1995. NIST Special Publication 800-53, Rev. 4, Recommended Security Controls for Federal

Information Systems and Organizations, April 2013. NIST Special Publication 800-83, Rev. 1, Guide to Malware Incident Prevention and

Handling for Desktops and Laptops, July 2013. SANS CIS Top Twenty Critical Security Controls for Effective Cyber Defense,

http://www.sans.org/critical-security-controls/

4. Definition of a Security IncidentAn incident is defined in Government standards as:

An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or [an occurrence] that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. (FIPS 200; NIST SP 800-53)

Incident handling is also defined:

Incident Handling: The mitigation of violations of security policies and recommended practices. (NIST SP 800-61)

Irregular or adverse cyber events may include, but are not limited to:

Denial of system resources Compromise of sensitive information or system integrity Malicious software infection Illegal access or attempted access to a system (either a penetration or an intrusion) Inappropriate access or attempted access to a system (internal, insider threat) Malicious or illegal use of system resources Any activity that deliberately violates any information policy

With regard to a security incident, Appendix D shows how to handle a suspected infected or compromised device and what information to gather for reporting the incident; Appendix E shows the definitions of incident severity and incident categories used by the DoIT Security Operations Center (SOC).


page 4 of 23


5. Roles and ResponsibilitiesInformation security and security incident management both depend upon responsible data-ownership and responsible users. For effective security management, collaboration between DoIT and an agency should establish the fundamental (security) responsibilities described in the roles below.

Exhibit 1 below shows an overview of the roles and responsibilities of participants in security incident response. The following sections provide more detailed descriptions of the actions each role may take.

Exhibit 1: Roles and Responsibilities During Security Incident Response

5.1 Roles Provided by DoIT Security Operations)

5.1.1 Role: System or Network Monitor Work with Data Owner and Security Manager to establish monitoring Ensure that complete and correct information is provided for monitoring


page 5 of 23


Name, type, location, and support-contact information for all hardware devices Documented workflow and criteria for alert notification and escalation

With agency personnel, determine when and how to escalate alerts, and establish a workflow for handling them

Determine when and how to report on “aggregated” security-related activity Work with Security Manager to tailor alerting requirements, i.e., filter out false-positive

alerts and correlate signs of elevated risk

5.1.2 Role: Incident HandlerDoIT will provide typical incident handling services listed below and mange an incident from initial escalation to resolution:

Investigate the incident (causes and impact) Recommend mitigation and support implementation Recommend security improvements based on incident-handling outcomes Ensure data is provided to agencies with regulatory reporting requirements

5.2 Roles Provided by the Agency

5.2.1 Role: Senior Agency Management Authorize and support compliance with DoIT security policies and regulatory

requirements for data management and reporting Establish partnering agreements and terms of collaboration with DoIT monitoring and

incident handling providers Interface with customers and service providers as required Authorize release of security-incident-related information

5.2.2 Role: Data Owner(s) Classify data —Ensures all data is processed, stored, produced, or managed is

appropriately classified and protected as required by policy or regulation Support Security Manager in providing documentation and training for users on how to

protect critical information Work with Security Manager and monitoring organization to identify useful, standard

reports (from monitors) and recommend frequency of distribution Establish a process for regularly reviewing security reports; often, the person who knows

the data and resources is in the best position to recognize suspicious access attempts or abnormal behavior

Provide DoIT Security Operations Center (SOC) with information on type of confidential data the agency has custody of and the criteria for reporting breaches, i.e., compromise or loss; use Appendix B to identify your sensitive data, its location, and the reporting


page 6 of 23


criteria, as well as an agency contact to whom the DoIT Security Operations Center (SOC) will report any data loss or compromise

Agency requirement: Enter agency-specific data classification and location information into Appendix B.

5.2.3 Role: Security Manager Ensure day-to-day operational security

Ensure compliance with agency and DoIT security policies and programs approved by DoIT

Ensure compliance with any applicable regulatory requirements, especially with regard to reporting incidents

Ensure processes exist (or adopt existing processes) and train users on how to operate systems securely, how to recognize an incident, and how to report an incident

Ensure education of agency staff and system users on reportable incidents — reportable security incidents include, but are not limited to: Loss or compromise of confidential data — may require breach reporting Incident affecting more than ten (10) individuals Incident affecting more than a single physical location, business unit, or functional

area Incident is identified, such as an attack on an agency network resource, agency

attacking a third party electronically, any allegation of electronically assisted criminal activity or copyright violation, etc.

Establish and maintain collaboration with DoIT for appropriate monitoring and incident handling services Establish criteria for security monitoring, including devices, ownership, and location;

this may be derived from another source such as an asset management system or data provided for a security evaluation team

Establish criteria for alert notification, including contact names and an escalation preferences

Agency requirement: enter the agency-specific contact information into Appendix C.

Assign or designate an agency representative to work directly with an incident handler to investigate, manage, and mitigate an incident

Ensure all mitigation recommended by incident handlers is implemented and documented

Section 6 below shows the process for the monitoring organization or service to report alerts and the escalation tree

Ensure DoIT is cognizant of any changes in processes and technology that may affect monitoring and incident handling capabilities

See more detail on required information under section 5.1.1 Role: System Monitor

Collaborate with DoIT to establish security reporting


page 7 of 23


5.2.4 Role: User Follow policies and best practices as communicated by agency management and through

security training Understand how to recognize an incident (via security awareness training) Understand how and where to report an incident Be prepared to assist in incident handling and mitigation tasks, e.g., provide information,

submit machine for mitigation or implement other instructions for mitigation

6. Incident Reporting and ManagementAlthough the agency retains the responsibility for protecting its data and assets, it should be prepared to assist incident handlers promptly and thoroughly with incident investigation and mitigation.

Incident reporting can generally go two ways:

1. Either a user or someone on the agency side notices something awry and reports it (see section 6.1 below)

2. Or the DoIT Security Operations Center (SOC) notifies the agency of an observed anomaly (see section 6.2 below).

Appendix C.2 a template that the agency should fill out to provide DoIT with the contact information and escalation preferences for the agency, and appendix C.3 provides contact information for reporting a cybersecurity incident to the DoIT Security Operations Center (SOC).

6.1 User Reports an IncidentIn some cases, a vigilant user will recognize an incident or anomaly that warrants a security threat report.

User recognizes an incident or anomalous behavior

Note: if a device, e.g., workstation or laptop, is suspected of being compromised or infected with malware, follow the steps in Appendix D to preserve the state of the machine for possible forensic analysis and refrain from continued use of the device.

User reports incident or anomaly to Security Manager or directly to the DoIT Security Operations Center (SOC)

Workflow for investigation and mitigation then shifts to the agency Security Manager or (DoIT SOC) incident handler

The overall workflow for reporting an incident is shown below, and Appendix G contains more detailed, NIST-based description of the overall incident response cycle.


page 8 of 23


6.2 Continuous Monitor

ing Service Escalates an AlertThe DoIT Security Operations Center (SOC) will escalate alerts to the agency per instructions provided in Appendix C. The DoIT SOC will be responsible for:

Monitoring security incident alerts — section 5.2.3 identifies the Security Manager as responsible for ensuring that the monitoring service receives the logs it needs to detect security threats and create correlations

Determining the severity of the alert(s) Correlating alert information Analyzing the threat Notifying the agency for mitigation


page 9 of 23


6.3 Incident HandlingIf a formal incident is declared, incident handling will be managed by DoIT with assistance from the agency, as requested (and described in role responsibilities described in section 5 above).

The DoIT incident handler will also provide information on a data breach and support the agency in meeting reporting requirements.

7. Reporting and Metrics

7.1 Reporting on Monitoring and Incident Handling As described in section 5 above, the agency Senior Agency Management, Security Manager, and Data Owner will work with DoIT and agree upon requirements for reporting both system and network health as well as for escalating incidents.

Most monitoring services provide standard security reports based on the logs they receive and the alerts and activity they see.

Appendix F shows the agreed-upon reporting for this agency.

7.2 Management ReportingSenior Agency Management and the Security Manager will determine how incident metrics are to be reported outside their agency. They will establish requirements for the content, frequency, and distribution of all security reporting outside of the interactions with monitoring and incident handling organizations.

Appendix F shows the agreed-upon management reporting for this agency.

7.3 Regulatory ReportingSenior Agency Management and the Security Manager will determine whether the agency or (in-scope for non-Enterprise agencies) system has any regulatory obligation to report incidents, such as IRS 1075 45-day notice of (impactful) system changes. If yes, they will establish criteria and processes to ensure compliance with the regulation.

The agency may subscribe to an enterprise-level managed reporting process, such as Ethics and Compliance Office criteria and processes for reporting breaches of protected health information (PHI).

Appendix B (B.2) shows which reporting requirements are in force for the scope of this incident management plan, the criteria for reporting (may be a reference to an enterprise-level reporting program), and the agency contact to whom the DoIT SOC should report such incidents.


page 10 of 23


8. Signatures and Approvals

[Enterprise Agency Name] Security Managers and Security Plan Approvers

[name][Enterprise agency name] Security Manager

Date

[name][Enterprise agency name] Security Manager

Date

[name][Enterprise agency name] Executive

Date


page 11 of 23


Appendix A: Acronyms and Definitions

Term Definition

Cybersecurity event An observed change to the normal behavior or a system or environment.

Cybersecurity incident A verified event or set of events that has or may result in a change to the confidentiality, availability or integrity of Skyline information systems, networks, or data, and for which a directed response may be required to mitigate the associated damage or risk. An occurrence that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies may also be considered an incident.

Data breach A cybersecurity incident that results in a loss of confidential information to an unauthorized entity (i.e., cyber attacker) and may trigger breach penalties, reporting, and/or notification requirements.

Incident response or Incident Handling

The documentation of a predetermined set of instructions or procedures to detect, respond to, and limit consequences of a malicious cyber-attacks against an organization’s information system(s).


page 12 of 23


Appendix B: Confidential Data Under [Enterprise Agency Name] Stewardship

It is the [Enterprise agency name] responsibility to identify and protect its confidential data; the Incident Handler will report breaches to the agency POC who will be responsible for further breach reporting.

If you need any help or have any questions about the data to be provided, contact the DoIT SOC (contact information in Appendix C.3 below).

B.1 Confidential Data

Type of Data Location Criteria for Notification[Enterprise agency name]

Data Owner

PII [server name, subnet, physical location]

[more than 500 records lost] Full-name:Email:Phone:IM:

HIPAA

Agency proprietary

Etc.

B.2 Incident Reports Required by Regulation, Including for Confidential Data

Regulation Rule Criteria for Reporting Where and How to Report


page 13 of 23


Appendix C: [Enterprise Agency Name] and DoIT Security Operations Center Escalation and Contact

InformationIf you need any help or have any questions about the data to be provided, contact the DoIT SOC.

C.1 Senior Agency ManagementName:

Phone:

Email:

C.2 Escalation Criteria and Path for the [Enterprise agency name][Enterprise Agency Name] Alert Tree Effective date: [yyyy Mon dd][Enterprise agency name] Security Manager (SM):SM Email: SM Phone: nnn-nnn-nnnn

Severity 1 (worst case/critical) Severity 2 (high) Severity 3 (normal)

Escalation Method:

[enter preferred escalation method(s) for each alert-priority level, e.g., Phone primary contact, then secondary]

Email primary and secondary contacts

Email primary and secondary contacts

Primary Contact(s) NamePhoneEmail(copy and insert rows for additional names)Secondary Contac(s) NamePhoneEmail(copy and insert rows for additional names)Additional Contac(s) NamePhoneEmailComments or Instructions

Updated by: [name] [date]


page 14 of 23


C.3 Contact Information for the DoIT Security Operations Center

Appendix D lists the information you should be able to provide when reporting a security incident.

DoIT Service Desk: 7am to 9pm M-FPhone: 410.697.9700Email: [email protected](Optionally) Create a ServiceNow ticket assigned to Cybersecurity Services Assignment group.

or …during DoIT Service Desk after hours, Contact the DoIT SOC directly

Security Operations Center (24x7) Phone: 443.713.4432Email: [email protected]


page 15 of 23

mailto:[email protected]


Appendix D: Steps to Preserve State of a Suspect Device

D.1 Typical signs of an infected system…Some specific behaviors that indicate your system may be infected or compromised include:

Receiving virus alerts or messages from your virus-protection software (McAfee Endpoint Protection)

Browsers are redirected to sites that you did not select or intend to select Data or files that you try to access are encrypted or corrupted The computer is running very slowly but there is no broadcast of trouble from your

network team or service desk The DoIT Security Operations Center (SOC) team notifies you that they have an alert

from your device indicating it is contacting known malicious sites

D.2 What to doIf you suspect your system has been infected with malware or compromised, follow the steps below to preserve the state of the system for forensic analysis, and request assistance from the DoIT SOC.

Keep the device or system up, and “as-is”, without trying to troubleshoot or diagnose the issue before the DoIT SOC provides direction

Contact the service desk and open a ticket for the (Cyber) Security Services team:

DoIT Service Desk: 7am to 9pm M-F

Phone: 410.697.9700Email: [email protected]

or …Contact the DoIT SOC directly during DoIT Service Desk off hours:

Security Operations Center (24x7)

Phone: 443.713.4432Email: [email protected]

Note: contact the Service Desk or DoIT SOC through a medium other than the suspect device, e.g., phone, or you may alert adversaries that they have been discovered and give them opportunity to “escape” or cause irrevocable damage to the system.

Wait for instructions from the DoIT SOC

D.3 Information to Collect for Reporting an Incident Identification and contact information of reporter

Name Role


page 16 of 23


Organization Email address

Phone number Location

Identification and configuration information for impacted device Type (and model) of affected device Whether device contains any confidential or sensitive data Other potentially relevant information

Description of incident or issue Time and location of incident Behavioral symptoms


page 17 of 23


Appendix E: Incident Parameter Definitions

E.1 Incident SeverityIncident severities are generally determined by the ticket creator and verified by an incident handler using the standard definitions shown below.

TBD

E.2 Incident CategoryIncident categories are described below:

TBD


page 18 of 23


Appendix F: Security Reporting for the Agency

F.1 Audit and Control Reporting Determined by Collaboration

Report Name Recipient(s) Frequency Report Provider

[e.g., Log of Access by Users with Admin Privileges]

[name]; [?title] Daily, Weekly, Monthly, Quarterly, etc.

[Monitoring organization]

F.2 Management Reporting Determined by CollaborationReport Name (content) Recipient(s) Frequency Report Provider


page 19 of 23


Appendix G: Incident Response Process Flow Defined by

NIST SP 800-61R2

The following shows the general workflow and progress of incident response (IR) as described by the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-61R2. DoIT incident response will generally follow this workflow, although adjusted to DoIT’s own circumstances, resources, and expertise.

Incident Response Process FlowAn incident response process flow requires an organization to proactively prepare for a cyber incident, as well as to identify, contain, and eradicate the threat or vulnerability and aid in the recovery in the event that data loss or an integrity-impacting event occurs. Post-incident lessons learned will allow for studying why and how the incident occurred and evaluate any changes that need to be made to resources, processes, or technology to mitigate similar events in the future.

Exhibit F-1: Incident Response Life Cycle modified from NIST 800-61R2, Computer Security Incident Handling Guide

G.1 PreparationActivities associated with preparation for incident response are the identification of IR stakeholders and teams, creation and maintenance of IR policies and procedures, as well as ensuring contact information is up to date for all IR stakeholders.


page 20 of 23


G.2 IdentificationThe identification phase involves identifying whether or not an incident has occurred and determining the nature of the incident. Identification begins with an event reported via employees or detected via automatic sources (such as antivirus software). Employees are responsible for reporting any misuse of information or information systems to the Security Team immediately so that an event can be assessed as quickly as possible. Additionally, automatic alerts must be continuously monitored to ensure that events can be addressed in a timely manner.

Not all events rise to the level of being a security incident. It is important for an enterprise to appoint an initial responder to identify whether or not an event should be considered a security incident, to categorize the incident, and to assess the incident’s severity and priority to determine the proper IR response.

Incident CategoriesAlthough the US-CERT has defined incident categories, the DoIT SOC will utilize the modified categories described in Appendix E above.

Events not Considered Incidents If an employee is uncertain of whether an event raises to the level of an incident, the employee should contact his or her manager or a member of the Security Team. Not all events will cause activation of the Incident Response Procedures. Events that do not cause activation, are listed in a non-exhaustive list below:

Physical altercation between two employees Loss of hardware due to theft — If the hardware does not contain any proprietary

information, business information, or other sensitive or confidential information covered under regulation or standards (such as HIPAA and PCI related data)

Any improper usage that, once investigated, is found to not have caused any security vulnerability to the agency or associated information

Incident Severity Incidents may be classified by severity in accordance with NIST categories, but DoIT will use the severity ratings described in Appendix E above.

Incident Priority In the event that multiple incidents occur simultaneously, incidents should be prioritized based on the following three factors:

Functional impact of the incident Information impact of the incident Recoverability from the incident


page 21 of 23


Escalation Procedures An enterprise must establish procedures that establish lines of communication and escalation criteria.

Incident Scoping Incident scoping allows an enterprise to focus resources and effort most-effectively and efficiently. Throughout the length of an incident, re-scoping may be necessary to modify initial estimates. Incident scoping is conducted by the security team.

Incident Tracking and ReportingEffective and up-to-date tracking of an incident provides an audit of the incident should the enterprise want to use it for lessons learned or to provide evidence to relevant law enforcement or courts.

G.3 Containment During this step, efficient containment of the incident/threat allows an enterprise to minimize damage. The enterprise must assess and identify all affected systems of the network so that they can be contained (and repaired) as soon as possible to prevent harm to other assets and parts of the network. Containment processes vary for each incident depending on the severity and risk of continuing operations.

This, along with the next step, eradication, may also be referred to as a mitigation step of incident response.

G.4 EradicationEradication involves removing the identified threat from the network. Eradication measures depend on the incident and number of systems affected. Typical eradication measures include reimaging the infected system and enhancing the monitoring of system activity.

NOTE: Enterprise responders must exercise due care to protect evidence and forensically preserve information during both the containment and eradication phases.

G.5 RecoveryWhen the root cause of an incident has been contained and eradicated, an enterprise can begin the recovery phase. The goals of this step are to: (1) remediate any vulnerabilities contributing to the incident and (2) recover by restoring operations to normal. A phased approach is often used to return systems to normal operation, harden them to prevent similar future incidents, and heighten monitoring for an appropriate period of time. Typical recovery measures include restoring data on systems from clean back-ups or rebuilding systems from gold images.


page 22 of 23


G.6 Post-Incident and Lessons Learned After an incident has been identified and remediated, an enterprise must assess what assets (including information) were affected by the incident. A breach of specific types of confidential information or State and Federal laws and regulations may require compliance reporting or other actions. Confidential information that usually requires compliance with additional requirements and protocols includes, but is not limited to:

Personal Information (PII) – subject to Maryland Protection of Information by Government Agencies, Md. State Govt. Code §§ 10-1301 to -1308

Protected Health Information (PHI) – subject to Health Insurance Portability and Accountability Act (HIPAA)

Payment Card Information (PCI) – subject to Payment Card Industry Data Security Standards

Federal Tax Information (FTI) – subject to IRS Publication 1075

An IR Policy and associated processes is only as good as the ability of an enterprise to effectively “execute”. Conducting post-incident lessons learned will allow an enterprise to:

Review the steps taken during an incident and compare to existing policy and procedure to determine if any policy needs to be modified

Conduct a root cause analysis of the incident, including a discussion on how a similar attack could be prevented in the future

Assess technology, personnel, and processes to prevent similar events in the future

Lessons learned should be shared among security-team personnel and, where applicable, modified and released to employees to educate them on how employee actions can affect the security posture of the enterprise.


page 23 of 23

security management plan example€¦ · web view[agency name]security incident management plan —...

Documents