Malicious v. Unintentional - How to tell and does it matter?
With the expansion of insider risk tools and programatic advancement greater insight is being gained. However, this has created a significant challenge, whether or not an insider is acting maliciously or if the threat was unintentional. This can have a significant impact on how an insider risk program informs policy, process, technology, and training. How is your organization making the distinction between malicious and unintentional insider threats? Do you make the distinction? If you do or do not, how does that impact incident response?
Jake DeWoskin
Director - Security Success Engineering
-
From a programmatic and process standpoint we certainly contemplate both malicious and non-malicious insider risks. We know that the vast majority of insider risk is going to be non-malicious (e.g. a well intentioned employee trying to do their job who makes a mistake) but well intentioned mistakes can be just as damaging to an organization as a malicious event. So, to a large extent it is really more event driven. Each event carries unique risks based on the associated data, the user and the vector; and all of this context is an important factor that influences response actions, whether the event is malicious or non-malicious. This is where it is important to have the right response playbooks established ahead of time so that you can take action quickly and proportionately based on the risk associated with the context of the event.
Todd Thorsen
Director, Information Security, Risk Management and Compliance
Code42
-
This is a very good an important question. I agree, and focus my teams results on driving policies, just as much as recovering data that has left our control. Once we identify an event of interest, we take a wide look to see if the organization is using the service, assuming its movement to a cloud based service. If there are folders that suggest this is a business activity event such as /work /project /events, we can make an accurate assumption that we have a business process failure, or a new service that is being used, especially if a majority of a business unit is moving data to that location. In the case where we do not see this and suspect this event is intentional by the employee, we take a look at the timing of the event; was it close to term or hire dates? Are there other events that we identify such as suspicious outbound emails, or attempts to access resources. If we determine that the process is mostly a business failure, or the employees have a need that is not being addressed by the current software stack, we work with IT and the Security Architecture team to understand why we had a failure and if we can make improvements. It is difficult to tell a well intentioned employee they can no longer use a service, and not provide them a service. There would be a careful and longer approach to these events, while closing the data hole. If the intent appears much more intentional, we try to setup an interview within 24 hours, or less.
Please sign in to leave a comment.
Comments
2 comments