Emergency Incident ResponseReport a Confirmed or Potential Breach? Call +1 770-870-6343
0 Results Found
              Back To Results
                Close
                Fundamentals

                How You Define “Incident” Can Have Unwanted Repercussions

                Top 5 Findings from Secureworks’ Proactive Incident Response Engagements, Part 1 By: Donald Allison

                The Secureworks® Incident Response proactive consulting practice develops incident response (IR) plans, performs IR plan gap analyses, and facilitates tabletop exercises featuring various security risks to the more than 4000 customers in our base. Over time we have analyzed findings from each engagement. And it is from those findings that multiple patterns emerged showing consistent challenges to our customers’ security posture and response capabilities.

                These patterns showed differences between the top performers versus those who have gaps that need to be closed. Patterns were reviewed across business type, size, geographic distribution, as well as compliance and regulatory requirements to determine the top five challenges faced. This effort is part of Secureworks’ initiative to define what is “normal” for security in an industry.

                It is worth noting that the organizations reviewed in the data had at least one of the top 5 challenges, including the highest performers. The top 5 were selected for their potential impact to the security and IR posture. Impact was determined from business, legal, and security factors associated with each customer in the dataset. Where appropriate, comparison with industry accepted standards such as NIST, ISO, and others were included in the impact determination.

                The top 5 are not presented in any particular order. To varying degrees, they all have a potential impact on an organization. All five of the challenges must be addressed to assure a more complete, robust security environment which supports the business needs of an organization.

                This first of a series of 5 blogs will look at what should be considered the basic foundation of any security practice: the definition of “incident.”

                Words have meaning. The use of a word in a particular circumstance may have an oversized impact on an organization. There are many definitions of “incident” in the context of security.

                The National Institute of Standards and Technology in special publication 800-61 Revision 2, “Computer Security Incident Handling Guide,” defines incident as follows: “[a] computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.”

                The International Organization for Standardization (ISO) in ISO/IEC 27000:2018 defines an incident as “single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information.” Here the definition for security event is “identified occurrence of a system, service or network state indicating a possible breach of information security, policy, or failure of controls, or a previously unknown situation that can be security relevant.”

                HIPAA defines security incident in 45 CFR § 164.304 as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.

                This list could go on for quite some time; however, note the differences between the definitions.  All organizations need to review their regulatory, compliance, legal, contractual, and business obligations to determine their own definition for an incident. Once a definition (or in some cases a set of definitions dependent on specific factors) is determined, the declaration of an incident should only be performed by an approved entity to assure the appropriate obligations are being met.

                For example, New York State Department of Financial Services 23 NYCRR 500, “Cybersecurity Requirements for Financial Services Companies” states in Section 500.17:

                (a)        Notice of Cybersecurity Event. Each Covered Entity shall notify the superintendent as promptly as possible but in no event later than 72 hours from a determination that a Cybersecurity Event has occurred that is either of the following:

                (1)        Cybersecurity Events impacting the Covered Entity of which notice is required to be provided to any government body, self-regulatory agency or any other supervisory body; or

                (2)        Cybersecurity Events that have a reasonable likelihood of materially harming any material part of the normal operation(s) of the Covered Entity.

                Where as part of its cybersecurity program, each Covered Entity shall establish a written incident response plan designed to promptly respond to, and recover from, any Cybersecurity Event materially affecting the confidentiality, integrity or availability of the Covered Entity’s Information Systems or the continuing functionality of any aspect of the Covered Entity’s business or operations.

                To top it off, a Cybersecurity Event means any act or attempt, successful or unsuccessful, to gain unauthorized access to, disrupt or misuse an Information System or information stored on such Information System.

                If you are considered a Covered Entity, and you refer to an incident or even an event in your communications, you are potentially on the clock to report within 72 hours of that use of the term.

                So in all, the simple definition of “incident” may have some not-so-simple repercussions in your environment. And I will add in one more item. When consulting with customers I throw “business impact” and “reputation” into the mix as well. What may seem like a relatively trivial technical issue could have far greater reputation impact on a business. Conversely, a large technical problem may not have the same impact on business operations.

                Work on that definition.

                Such content herein is provided “as is where is,” and Secureworks makes no representations or warranties about the accuracy or completeness of the content contained herein.  Additionally, although the content set forth in this blog may discuss or relate to legal issues, SecureWorks does not provide legal advice or services, and none of such content shall be deemed, construed as or constitute legal advice. You are ultimately responsible for retaining your own legal counsel to provide legal advice. Furthermore, this content shall not be deemed to be legal opinion and may not and should not be relied upon as proof, evidence or any guarantee or assurance as to you for legal or regulatory compliance.

                Related Content