Over the last year, the world saw a number of major security breaches in the news. Some notable ones include the SolarWinds attack, Colonial Pipeline Hack, and JBS U.S. Beef plant attack. Unfortunately, attacks are nothing new. Other major attacks over the years have included the Equifax data breach, Uber data breach, and WannaCry cyber attack.
While each of these had its own unique security vulnerability that was exploited they all shared in at least one commonality — they experienced a security incident (i.e. information security or cybersecurity) that would have required reporting as a result of SOC 2 Guidance changes that occurred in 2018. In this post, we will talk about cyber security incidents, the change in incident reporting expectations, implementing the new guidance, and disclosure requirements.
What are Security Incidents?
The definition of an incident can vary depending on your company and the multiple factors at play. With that said, NIST defines an incident 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 that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.”
What Are Some Examples of Security Incidents?
Using the definition defined above we will dissect the named incidents identified above.
- SolarWinds: In the spring of 2020, SolarWinds provided its users with what appeared to be a normal software update. Software updates generally include security and bug fixes, and feature updates or enhancements. This update, however, was no normal update.
- In this instance, hackers were able to add malicious code which was released as part of the software update. Once the attack was reviewed, it appeared that about 100 companies and 13 government agencies were compromised. Because a hacker was able to add malicious code into the release, this was a security incident that impacted not only SolarWinds but a large number of companies as well as government agencies.
- Colonial Pipeline Hack: The Colonial Pipeline, one of the largest petroleum pipelines in the country, shut down after a ransomware attack took a portion of its system offline.
- In this case, an old account that was once appropriate was not removed upon the termination of that employee. Additionally, multi-factor authentication was not utilized. Using the old credentials, the bad actor was able to gain access to the system and then ultimately shut everyone out until the ransom was paid. Because unauthorized credentials were used to access the system and the availability of the services being provided was halted, this is considered a security incident.
- JBS Beef Plant: The JBS meat plant was another ransomware exploit. Similar to the Colonial Pipeline, the hackers were able to enter the system and encrypt the information, and ultimately shut down its locations.
- The only way to get operations back up and running was by paying its ransom. Due to unauthorized access to the system, this is considered a security incident.
- Equifax Data Breach: During the Equifax data breach, about 145 million U.S. consumers and businesses had their information hacked as a result of a known vulnerability that existed on their web portal that was not patched in a timely manner.
- Because of this breach, the confidentiality of consumer data was jeopardized, making this an incident.
- Uber Data Breach: During the Uber data breach, hackers accessed a server that stored personally identified information (PII) by gaining access to their code repository which contained login information needed to gain access to Uber’s production environment.
- Like the Equifax data breach, the confidentiality of Uber’s client information was jeopardized, making this an incident.
- WannaCry Cyber Attack: The WannaCry attack was a particularly notable attack as it used a logic known as worm tactics which allowed it to hop to other users through LAN and WAN connections.
- This allowed the attack to disrupt entire networks for some that were infected. It spread through a known exploit within an old file-sharing protocol found in Windows systems released for over 15 years. During this attack, the integrity and availability of the system were affected, making this an incident.
Old vs. New SOC 2 Incident Reporting Expectations
Up until the latest version of the SOC 2 guidance, which officially went into effect December 15, 2018, service organizations receiving SOC 2 reports were not required to disclose major information security or cyber security incidents that occurred either as of the date of the system description or during the audit period the report covered. The only time it would have been mentioned is if the incident was the result of a control failure due to poor design or if the control did not operate effectively.
According to current guidance, management is required to include specific information about incidents that (1) occurred as a result of a failure in the design or operating effectiveness of one or multiple controls or (2) upon occurrence resulted in the company not being able to meet service commitments and system requirements.
According to the AICPA, reportable security incidents should include the following information:
- Nature or description of the incident
- Timing around when the incident occurred
- The consequence the incident will have on the service organization, service organization’s users, and any disruption to service commitments and system requirements.
How to Implement the New Guidance?
The AICPA has an Assurance Services Executive Committee which works on different tasks that are designed to offer guidance, criteria, and tools to support members of the AICPA in implementing requirements published by the AICPA. This includes the Description Criteria for a Description of a Service Organization’s System in a SOC 2 Report. Within this publicly available document is guidance around implementing the new requirement of adding incidents to the system description.
Something important to note is that the AICPA understands that not all incidents are major and require reporting to their users. The new Description Criteria provides considerations that management can use when determining whether an information security or cyber security incident response is warranted, and therefore meet the reporting requirements noted in the section above. The considerations are as follows:
Incident Response Considerations:
- Was the incident a result of controls that were either not designed properly or did not operate as intended?
- As a result of the incident, was the service organization not able to meet the service commitment and system requirements guaranteed to their users?
- Are there any laws or regulations which will force the incident to be publicly disclosed, if it has not been already?
- Has or will the incident impact the financial stability or long-term operations of the service organization and will this require a financial statement disclosure?
- Did the incident require any type of legal or regulatory sanction?
- Has or will the incident cause the service organization to cancel any major contracts?
If the answer to any of these considerations is yes, then it is likely that the incident needs to be reported within the upcoming SOC 2 report.
Who Should Report Any Suspected Security Incidents?
If you think that your organization has been the victim of a security incident, it’s important to notify key individuals within the organization that has the authority to take required action. Generally, this person(s) is either part of an organization’s information security team or part of the information technology team. Specific titles may include: security officer, privacy officer, CISO, VP of Technology, CTO, etc.
So that employees know who to report incidents to, it’s important that key personnel are communicated across the organization. If you are unsure of who this person is in your organization, ask management. Having this information prior to an incident is key in the identification and containment of cyber security incidents.
Why is it Important to Report Security Incidents Immediately?
The sooner an organization knows that a possible cyber security incident has occurred, the sooner action can be taken to stop the damage that is occurring and determine how much damage has occurred, if any. Even if a security incident has not occurred, it’s important to notify the person(s) responsible for cyber security incident triage as they are trained to take proper action.
I Have a Reportable Security Incident – What Now?
If by going through the considerations in the previous section and through conversations with the appropriate personnel it is decided that an incident does need to be reported, it is important to understand what that should look like.
When a company reports an incident, the information reported should be presented at a high level for a number of reasons. The first reason is that certain details could provide parties with bad intentions enough information needed to further exploit the system. Second, the reporting of incidents is only intended to provide readers with the description of the incident, timing, and any consequences the incident has caused.
Service organizations that determine they have a reportable incident should work with appropriate personnel such as their auditor and legal team to ensure that the information provided will not result in further damage to their system.
Preventing & Handling Cyber/Information Security Incidents
While my hope is that hacking and cyber security incidents do not continue to occur, the reality is that the threat is out there and only seems to be growing. The best way to ensure that your service organization lowers the risk of having to report on a security incident is by having a security management team with a policy and plan that continues to identify, analyze, and remediate risks that can negatively impact users and the system. But in the case that a security incident does occur, it is also important to understand the requirements of disclosure as a means to avoid unnecessary exposure.
For more information, check out some other Linford & Company posts about cyber security incidents and securing your environment. In addition, please feel free to contact our team if your organization is interested in retaining our audit services.
- Insider Threats in Cyber Security: The Risks They Pose and How to Mitigate Them
- Mobile Device Management (MDM): Securing Your Mobile Workforce
- What is Containerization? Security & Benefits
- Reporting on an Entity’s Cybersecurity Risk Management Program and Controls (SOC for Cybersecurity)
This article was originally published on 5/23/2018 and was updated on 10/13/2021.
Jaclyn Finney started her career as an auditor in 2009. She started with Linford & Co., LLP. in 2016 and is a partner with the firm. She is a CISA with a special focus on SOC, HITRUST, FedRAMP and royalty examinations. Jaclyn works with her clients to provide a process that meets the needs of each customer and generates a tailored report that is useful to the client and the users of the report.