Communicating difficult changes

Part of working in security is delivering news people don't want to hear.

Examples: You can't use this software, your corporate laptop needs monitoring, you can't check in this sketchy 3rd party library.

Internal reputation is a valuable thing for a security team. It makes everything we want to accomplish either easier or harder. A, maybe the, primary way to harm that reputation is to fumble a rollout, especially of “bad” news.

Some things that help:

1. Bad news up front

2. Whats the reasoning? Make company more secure?

3. How well considered were the tradeoffs?

4. Is there data to support this?

5. How fixed is the decision? Might it change?

6. How will we know if this was the right decision 6mo from now?

7. Rollout.

 a. Seek feedback from strongest expected critics first.

 b. Q/A section in announcement.

 c. Don't roll out change right after announcement.

 d. Don't do announcement right before a weekend.

Thats great in abstract, but lets explore what an announcement of a new policy that you can't download applications on your work laptop might look like:

On $future_date unapproved applications will no longer be allowed on company computers.

Because of the risk and maintenance burden we've made the hard decision to disallow any applications on company computers not on $allow_list.

The main reason is risk. Every application increases the attack surface. This is not abstract, in the last 6mo there have been xx security incidents stemming from such software, typically malware or attackers exploiting vulns. The increasing prevalence of such incidents is prompting this change now.  

We will expand $allow_list over time and you can add an app for consideration $here. The steps for something to get on $allow_list are a,b,c and typically take x weeks.

This decision came after considerable investigation and discussion. Out of 10,000 employees 2% had installed applications not on $allow_list.  We had a few focus group meetings with samplings of employees from that 2%. We learned

1. Of the now disallowed apps, most could be categorized the apps as for productivity or $activity.

2. Of the disallowed apps, ballpark estimates of time saved were 1 hour a week per person.

3. In some cases after discussion some of the disallowed apps could be replaced by apps on $allow_list

Next steps

This change will happen on $date. At that time if any disallowed apps are on your computer they will stop working via $device_management_software. The user experience for having an app not work in this way is described $here. If you want to suggest an app to move to the allow list go to $url.

We will be paying close attention to how these changes affect folks. 6 months from now we will judge if this decision was the right one by

• Estimating if risk was reduced. We will compare before/after of the # of security incidents handled where the primary cause was an application in the now-unapproved population
• Polling our focus group participants again on their experience and productivity.

This decision was not taken lightly. I understand being annoyed by this decision. The goal is not to hinder productivity, its a conscious tradeoff given the increased risk to our company if we continued with the status quo.

Any feedback (good, bad, ugly) please don't be shy and submit it $here.