If you're a technologist, you've probably noticed (or have been asked about) a few new things associated with Chrome 68's release last month. One of the more notable changes is that it now uses a "not secure" indicator for any site not using HTTPS. So instead of providing a notification when a site is HTTPS, it now provides the user with a warning when it isn't.
This change has been quite a long time in the making. Google spelled out the details earlier this year. Following quite a bit of feedback, discussion and gnashing of teeth, the change finally arrived. Predictably, not everyone was prepared -- and a subset of website users now get the "not secure" warning for sites that, prior to the change, seemed hunky-dory.
One of those groups is users of U.S. state and local government websites. For example, the front pages of 14 states (including, for example, California, Florida and Ohio) do not have encryption enabled and are therefore have been generating a "not secure" warning for site visitors, according to the Center for Digital Government .
Likewise, four of the 10 biggest U.S. cities do not have it enabled as yet. The warning itself represents an arguably somewhat minor user interface issue, though it's one that nevertheless is important to address. Users receiving those warnings, particularly those who are less technology-savvy, may have legitimate concerns about a site now can be classified as "not secure."
The UI impact is important to note and subsequently address. The shift itself is a good one, as it incentivizes enhanced security of websites. Neither of those things is why I'm calling it to your attention, though. Instead, I'm mentioning it because it puts into sharp relief another issue that may seem unrelated at first blush. However, it is important to address it generally and to view it as a useful earning moment for enterprise security practitioners. Specifically, the issue is election security -- that is, ensuring secure, reliable, free and fair elections.A Learning Moment?
This may strike some as a contentious thing to say at first. After all, the front page of a municipality, state, or even a civilian federal agency almost certainly is not a participant in the election process in any real or direct way.
For example, the server that runs California's homepage ( www.ca.gov ) is almost certainly not used to directly support any election in California. It is unlikely to be part of the same infrastructure, and it's a good bet it's not even in the same datacenter.
Still, looking at the Chrome 68 HTTPS notification change could be a useful learning moment. Why? Because, despite a significant amount of time to prepare -- and vocal warnings from the technology community at large -- not every state was able to prepare equally.
This is in part because there's a sizable surface area involved: Each state and municipality is responsible for ensuring that its own resources are taken care of and moved to HTTPS within the time window. Because that responsibility is distributed, each set of personnel is responsible for getting learning about the change, understanding its significance, and taking the right action to address it.
This is, in fact, similar to where the U.S. is with election security. I've made the point in the past that election security is a fairly asymmetric contest from a security perspective. Meaning, on offense you have one or more nation states that are well funded, that operate around the clock, that are sitting on a stockpile of zero-day vulnerabilities, and that have dedicated engineering staff that are among the best in the world at breaking into stuff.
On defense you have a state or municipality -- say for example Manchester, New Hampshire. Is it reasonable to expect an individual state or city to defend against a dedicated target attack under the circumstances outlined? It's difficult, because responsibility and resources for defense are spread thin and are distributed, while the offense is centralized and coordinated.
What I think really drives the point home is that replacing a certificate on a website is a relatively trivial affair, while securing the technology side of a major election is anything but. The fact that the U.S. demonstrably has been having challenges doing the easy part doesn't inspire confidence about the ability to do the hard part down the road. When the stakes involve a minor website UI issue, maybe that's OK. When it's instead the fundamental principle on which your system of government rests, maybe it's less so.Adapting for Businesses
Of course, while election security is interesting from a theoretical point of view, the more salient point for security practitioners is how we can adapt these implications and lessons into securing our businesses.
There are, after all, situations that occur in business that have similar dynamics to both election security and the HTTPS issue. For example, you may have multiple business units that are distributed. You may work for a holding company or other organizational structure where distributed security-relevant tasks need to be performed by multiple different people throughout the organization. If so, there are a few things you can do to help ensure a positive and consistent outcome.
First is to improve communication. Having a reliable mechanism for sharing information about security-relevant tasks -- both what needs to be done and how to do them -- is a useful starting point.
Second, establishing clear accountability and ownership for security tasks ensures that as staff members become alerted to what they need to do and how to do it, they can be chartered with executing to make sure it happens.
Third, where there's asymmetry -- for example situations in which individual business units or departments are likely to be attacked by adversaries that disproportionately are better equipped than they are -- introducing an element of standardization or centralization can help offset an attacker's advantages.
At the end of the day, we can take away quite a few lessons. Paying attention to how these two issues interrelate both informs us about the seriousness of election security and gives us information that we can adapt for defending the organizations we're chartered to protect.
The opinions expressed in this article are those of the author and do not necessarily reflect the views of ECT News Network.
Ed Moyle is general manager and chief content officer at Prelude Institute. He has been an ECT News Network columnist since 2007. His extensive background in computer security includes experience in forensics, application penetration testing, information security audit and secure solutions development. Ed is co-author of Cryptographic Libraries for Developers and a frequent contributor to the information security industry as author, public speaker and analyst.