presented by the oispp team and guest speakers the benefits of incident reporting
TRANSCRIPT
September 2008 www.infosecurity.ca.gov 2
Discussion Topics What is an Incident? Metrics -Why it is important to track
and report incidents Why employees should be trained to
recognize and report Why it is important to have an
incident response plan Roles and Responsibilities
September 2008 www.infosecurity.ca.gov 3
Discussion Topics The State’s reporting process What’s coming from OISPP on
Incident Management? Additional Resources Case Studies Open Discussion
September 2008 www.infosecurity.ca.gov 4
What is an Incident? The definition may differ among
organizations and their employees Definitions may be very specific and
granular or broad and all-encompassing
Or something in between Let’s look at a few examples
including Events versus Incidents
September 2008 www.infosecurity.ca.gov 5
Examples An event is any observable occurrence in a system or
network. Events include a user connecting to a file share, a server receiving a request for a Web page, a user sending electronic mail (email), and a firewall blocking a connection attempt.
Adverse events are events with a negative consequence, such as system crashes, network packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malicious code that destroys data.
Source: National Institute of Standards and Technology (NIST) www.nist.gov
September 2008 www.infosecurity.ca.gov 6
Examples (Continued) A computer security incident is a violation or imminent threat
of violation of computer security policies, acceptable use policies, or standard security practices.
Source: National Institute of Standards and Technology (NIST) www.nist.gov
A security incident is an alert to the possibility that a breach of security may be taking, or may have taken, place. A breach of security is where a stated organizational policy or legal requirement regarding Information Security, has been contravened. However every incident which suggests that the Confidentiality, Integrity and Availability of the information has been inappropriately changed, can be considered a Security Incident.
Source: ISO 17799 Toolkit – Glossary and Reference Manual
September 2008 www.infosecurity.ca.gov 7
Examples (Continued) Incident: 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 that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.
Source: FIPS 200
Incident: An occurrence that could have led, or did lead, to an undesirable outcome.
Source: CERT/Coordination Center www.cert.org
September 2008 www.infosecurity.ca.gov 8
Reportable Under Current State Policy Loss, theft, damage, misuse, or inappropriate use
of state information assets Information Assets is defined as: (1) All categories
of automated information, including (but not limited to) records, files, and data bases; and (2) information technology facilities, equipment (including personal computer systems), and software owned or leased by state agencies.
http://www.oispp.ca.gov/government/definitions.asp
September 2008 www.infosecurity.ca.gov 9
Criteria For Reporting Incidents (SAM Section 5320.2)
State Data (includes electronic, paper, or any other medium).
Theft, loss, damage, unauthorized destruction, unauthorized modification, or unintentional or inappropriate release of any data classified as confidential, sensitive or personal. (See SAM Section 5320.5).
Possible acquisition of notice-triggering personal information by unauthorized persons, as defined in Civil Code 1798.29.
Deliberate or accidental distribution or release of personal information by an agency, its employee(s), or its contractor(s) in a manner not in accordance with law or policy.
Intentional non compliance by the custodian of information with his/her responsibilities. (See SAM Section 5320.3).
September 2008 www.infosecurity.ca.gov 10
Criteria For Reporting Incidents(SAM Section 5320.2) Inappropriate Use & Unauthorized Access - This includes actions of
state employees and/or non-state individuals that involve tampering, interference, damage, or unauthorized access to state computer data and computer systems. This includes, but is not limited to, successful virus attacks, web site defacements, server compromises, and denial of service attacks.
Equipment - Theft, damage, destruction, or loss of state-owned Information Technology (IT) equipment, including laptops, tablets, integrated phones, personal digital assistants (PDA), or any electronic devices containing or storing confidential, sensitive, or personal data.
Computer Crime - Use of a state information asset in commission of a crime as described in the Comprehensive Computer Data Access and Fraud Act. See Penal Code Section 502.
Any other incidents that violate agency policy.
September 2008 www.infosecurity.ca.gov 11
Clarification on Criteria For Reporting Incidents Unauthorized access includes access which exceeds
the limits of an individual’s authorized access to information or information systems (e.g., snooping)
Other criminal activity, such as fraud and embezzlement
Any other incidents that violate agency policy, such as unauthorized use of peer-to-peer technology, copyright infringement, and obscene/offensive material
September 2008 www.infosecurity.ca.gov 12
Alignment with the NIST and ISO Standards Definitions Adverse event – Events with a negative consequence,
such as system crashes, network packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malicious code that destroys data.
Computer security incident - A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.
September 2008 www.infosecurity.ca.gov 14
Helps reporting organization to: Measure organizational performance Pinpoint business problems, risk and
liabilities Control losses and risk management costs Comply with legal and policy requirements Demonstrate due diligence Improve its monitoring and prioritization of
threats and vulnerability management
September 2008 www.infosecurity.ca.gov 15
Entity responsible for taking the report may be able to: Provide technical assistance in responding to the
incident Put you in touch with others involved in or having had
a similar experience Collect and distribute better information about lessons
learned through its statistical reports Prepare and distribute better information about
mitigation strategies through its guideline documents Provide a larger picture of the State’s overall security
posture
September 2008 www.infosecurity.ca.gov 16
Why it is important to track and report incidentsIncidents Impact the Business’ Bottom Line Tracking and reporting…
Identifies “business problems” Provides metrics that substantiate cost associated
with correcting or not correcting a “business problem”
Establishes accountability We learn much from them
September 2008 www.infosecurity.ca.gov 17
And…Oh By the Way… Enhanced security may be the solution or part
of the solution… Being the solution or part of the solution is a
good place for security to be!
September 2008 www.infosecurity.ca.gov 18
What we have learned thus far There are benefits to knowing about them Response activities can be and often are costly The human factor is the weakest link The “heads-will-roll” approach does not
prevent a recurrence of an incident or serve to promote a willingness by employees to report incidents
September 2008 www.infosecurity.ca.gov 19
What we may still have to learn from incidents The true cause of an incident – in some cases
it may be a long and arduous road The true cost of a broken process, procedure,
and/or system “Three feet of ice does not result from one day
of freezing weather.”- Chinese Proverb
Its relation to other incidents across jurisdictions (city, county, state, country)
September 2008 www.infosecurity.ca.gov 20
Other Sage Advice Emphasize flexibility and re-looking at
problems vs. a quick fix or one-shot solutions. Adopt a systems approach to problem solving.
Look at the whole system, not just your piece of the problem in developing solutions.
Utilize the planning process to forge better relationships with your partners, key stakeholders, and community networks.
September 2008 www.infosecurity.ca.gov 21
Why employees must be trained to recognize and report Definition may be unclear Culture may be counter intuitive
Perceived lack of concern by management Perceived as negative impact to the bottom line Fear of reprisal
Need to reaffirm agency’s reporting requirements and needs for employees
Why it is important to have an incident
response plan
No wind is favorable if we do not know into which port we are trying to sail.
-Rev. Dale Turner
September 2008 www.infosecurity.ca.gov 23
An Incident Response Plan A document that:
Identifies the organizational approach to handling security incidents
Identifies the incident response team Identifies team member roles and responsibilities Is adaptable and flexible
September 2008 www.infosecurity.ca.gov 24
An Incident Response Plan Brings needed resources together in an organized
manner to deal with an adverse event Limits impact of adverse event to customers/partners Speeds response and recovery efforts Aides investigations, preservation of evidence, and
determination of how it occurred and how to mitigate against recurrence
Brings needed resources together in an organized manner to review post-incident lessons learned
Incident Reporting Roles and Responsibilities
“I say Who's on first, What's on second, I Don't Know's on third.” -Abbott
September 2008 www.infosecurity.ca.gov 26
State EmployeesRole Users of information assets to
support business services
Responsibility Use assets appropriately for state
purposes Comply with security and
privacy laws, rules policies Report threats, vulnerabilities,
and security weaknesses to departmental ISO
Report actual and suspected security breaches to departmental ISO
Source: (SAM 5320.4)
September 2008 www.infosecurity.ca.gov 27
State AgenciesRoles Managers of an organization. Owners of state assets and/or
data.
Responsibilities Establish the following:
Security policies and procedures
An incident response plan A security incident response
team Ensure all employees are aware
of the policies and procedures and incident response plan.
Train all employees on how to recognize a security incident and who/when to report it.
Create a Communication Plan.
September 2008 www.infosecurity.ca.gov 28
State Agencies (cont.)Responsibilities Verify that an incident has
occurred. Determine the following:
What type of incident has occurred?
How did the incident occur? How much damage or harm
has occurred? What is the current status of
the incident? Gather and preserve evidence.
Responsibilities Determine what steps will need
to be taken to contain the incident from creating additional damage or harm.
Mitigate the incident. Test and validate to ensure the
vulnerability has been fixed. Return to normal operation.
September 2008 www.infosecurity.ca.gov 29
State Agencies (cont.)Apply Lessons Learned Exactly what happened, and at what
times? How did staff and management perform
in dealing with the incident? Were the documented procedures
followed? Were they adequate? What information was needed sooner? Were any steps or actions taken that
might have deterred the recovery? What would the staff and management
do differently the next time a similar incident occurs?
What corrective actions can prevent similar incidents in the future?
What additional tools or resources are needed to detect, analyze, and mitigate future incidents?
Source: NIST SP 800-61
Follow-up Paperwork To OISPP
An Agency Information Security Incident Report (SIMM 65C) outlining the details of the incident and corrective action to be taken must be completed within 10 business days following the incident, per SAM Section 5350.1.
To CHP Std. Form 99
To DGS Std. Form 152
Additional follow-up documentation may be required to other entities.
September 2008 www.infosecurity.ca.gov 30
California Highway Patrol (CHP)Authority Government Code Section 14613.7(a) requires
state agencies to report to the California Highway Patrol (CHP) all crimes on state-owned or state-leased property where state employees are discharging their duties.
Title 13, California Code of Regulations, Division 2, Chapter 12, Section 1875 requires the reporting of computer crimes involving state computer resources.
September 2008 www.infosecurity.ca.gov 31
CHP ENTAC v. CHP CCIUEmergency Notification and TacticalAlert Center (ENTAC):
Role Provides 24 hours a day, seven days a
week availability to state agencies to report information security incidents.
Responsibility Provide initial report intake and alert
notification support to CHP-CCIU and OISPP as it relates to information security incidents.
Computer Crimes Investigations Unit (CCIU):
Role Investigates computer crime, particularly
those that violate any section of California Penal Code Section 502, subsection (c).
Responsibilities Primary responsibility for investigating
incidents involving any type of crime against state assets, including computer crimes.
Provides Departments with recommendation and guidance on gathering and preserving evidence, and responding to an incident.
September 2008 www.infosecurity.ca.gov 32
Important
Notification of a security incident to someone outside of the CHP ENTAC process (e.g., a local CHP
representative or other law enforcement agency or IT related investigative task force) does not relieve state agencies of their obligation to notify the CHP
and OISPP through ENTAC.
September 2008 www.infosecurity.ca.gov 33
Office of Information Security & Privacy Protection (OISPP)Roles Issues security and privacy polices
and standards. Provides guidance and assistance
to state agencies. Provides training and awareness
tools to ensure state agencies understand their responsibilities.
Tracks and monitors reported incidents across the state.
Conducts compliance reviews, assessments, and audits to ensure state agencies are in compliance with laws, policies, and standards.
Responsibilities Communicates with Departments
to obtain important information regarding the incident.
Identifies Incident Response and Communication Plan within 24 hours.
Provides Departments with recommendations and guidance on handling incidents and notifying the affected individual(s).
Notifies the appropriate entities. Prepares statewide incident
management reports for executive management
September 2008 www.infosecurity.ca.gov 35
Reporting Process Affected user immediately notifies the
Departmental ISO. ISO notifies the CHP ENTAC.
Other individuals who may also need to be notified: Department Director and/or Public Information Officer Agency Director and/or Public Information Officer Governor’s Office and/or Public Information Officer Affected Individual(s)
September 2008 www.infosecurity.ca.gov 36
Report Process (cont.) ENTAC notifies the OISPP and CCIU. OISPP and CCIU acknowledge the report to
ENTAC OISPP may notify the following entities:
California Office of Health Information Integrity (formerly CalOHI)
California Office of Privacy Protection California Office of the State Chief Information Officer
Agency Information Officers and/or the State Chief Information Officers
Multi-State Information Sharing and Analysis Center
September 2008 www.infosecurity.ca.gov 38
SIMM 65C – Required Information Reporting Agency Name and Organization Code Incident Number that is assigned by OISPP Section A - Date CHP ENTAC was notified Section B - Incident Information and Estimated Cost
of Incident Section C - Corrective Actions Planned/Taken and
Estimated Cost of Incident Section D – Signatures (must map to SIMM 70A)
September 2008 www.infosecurity.ca.gov 39
Have No Fear… OISPP Is Here!
New Tool to help: Estimate cost of
incident Estimate cost of
corrective actions
http://www.oispp.ca.gov/government/library/documents/incident-cost-estimator-tool.xls
September 2008 www.infosecurity.ca.gov 40
What is coming next from OISPP on Incident Management Two Management Memo’s
Safeguarding Against and Responding to a Breach of Personal Information
Incident Management Update to Definitions Update to Reporting Criteria
Comprehensive Training – First Quarter 2009
September 2008 www.infosecurity.ca.gov 43
Additional Resources GoRIM – State Agency Incident Management Policy
and Resourceshttp://www.oispp.ca.gov/government/go_rim/go_RIM-section5350.asp
U.S. Computer Emergency Readiness Team (US-CERT) http://www.cert.org/csirts/Creating-A-CSIRT.html
SANS Reading Room on Incident Handling http://www.sans.org/reading_room/whitepapers/incident/
NIST ITL: Updated Guidelines Handling Computer Security Incidents (March 2008) http://csrc.nist.gov/publications/nistbul/b-March-2008.pdf