A lack of communications enables breaches and helps derail cybersecurity projects

A lack of communications enables breaches and helps derail cybersecurity projects

Communications issues are one of the less obvious challenges associated with the deployment of any new technology. A lack of end-user communications inevitably limits the adoption and usage of new security technologies, and a lack of understanding gives users reason to circumvent new security controls. However, this does not have to be the case, and this article will examine the effects of communication (and lack thereof) on two different client projects.

The client was a mid-sized financial company in the eastern United States. They purchased a technology product to help address their cybersecurity risks associated with managing escalated user privileges, and they sought to run the project as a technology project. An initial set of administrators were trained on the product. Despite recommendations from the vendor, the client chose to not   involve their PMO and to not produce any end-user training or communications other than a hastily-composed email informing each user that they would have a new method of gaining escalated permissions. This email was to be sent out five minutes before each server deployment and only to the users affected. Similarly, the client chose to disregard recommendations that they notify the help desk of any new troubleshooting procedures.

It would be an understatement to say that the project did not start well for the client. I met with the client several years after their initial deployment of this technology to find that they were still struggling with end-user adoption. Users claimed the technology made their jobs more difficult, and each line of business could delay and push back against the adoption of this technology. At least one known instance of data exfiltration had occurred on a server where the solution had been delayed due to end user opposition. The CSO had written off the technology and was actively pursuing new vendors to replace this failed deployment.

In comparison, the second company was a retail company in the western United States. They had chosen to deploy a security product to achieve regulatory compliance on a limited subset of high-visibility servers. After several discussions with the CSO, a VP, and a senior manager, the client agreed that they would not treat the project as a technology deployment but rather as a business program, despite it being limited to less than 10% of the servers in their compute estate. A project manager from the PMO was assigned to the project and immediately grasped the need for adequate communications.

An initial email introducing the program was sent by the CSO to the administrators and users on the servers within the scope of the program. A follow-up meeting was held, with several senior managers explaining to their staff why the program was necessary and how it would help them address regulatory concerns and also the risks associated with data breaches. These sessions were recorded for staff who could not attend in person.

Each server where the technology was being deployed followed a standard communications template:

  • One month before the deployment date, the change management board was notified and would often approve the deployment

  • At the same time, the help desk and provisioning teams were notified that support and provisioning procedures would be changing for that server

  • Three weeks before the deployment date, the users were notified of the pending deployment and asked if they had any questions. This notification came in the form of an email, and in some cases, was integrated into standing staff meetings

  • Two weeks before the deployment date, the users were sent an email with the email address, phone number, cell phone numbers, and war room location of the project team. This way, in case anything was perceived to have gone wrong, users could pick up the phone or walk over to discuss the issue immediately with the project team.

  • A week before the deployment date, the users were sent another reminder about the pending server deployment.

  • On the day of the server deployment, the help desk updated their support procedures so that, for the following two weeks, all calls about the deployed server would immediately be routed to the project team

  • On the day of the server deployment, users were sent an email before deployment and then post deployment. In cases where standing staff meetings were scheduled on deployment days, managers would remind their staff as part of the agenda.

  • Two weeks after the server deployment, the help desk would resume handling support cases associated with the deployed server.

The advantage of this emphasis on communications was clear both during the initial phases of the project and several years later when I met with the client for a follow-up over coffee. The two-week help desk transfer of ownership to the project team helped to define and build internal support procedures for the new security technology and led to an internal FAQ where users would often be able to solve their own problems. The project manager had been recognized and promoted for their contributions to this essential cybersecurity program. And the external audit firm retained to verify quarterly regulatory compliance had no findings associated with these critical servers after years of operation.

When planning any migration or deployment of new technology, businesses should carefully consider the best way to communicate the intent and need of the new technology to those users affected by it, as well as to those who work in supporting roles. Otherwise, businesses may find their best-in-class security solutions stymied by mediocre basic communications.

Interview on Cheddar TV

Interview on Cheddar TV