Technical Glitches: Coincidence or Cyberattack?

This week we read about four major internet outages that caused a wide amount of consternation and worry: United Airlines, the NYSE, the Wall Street Journal and today, Ameritrade. While these events appear to have been “technical glitches” with software and/or hardware, the potential enormity of these events regarding air travel, reporting and the financial industry is disconcerting.

At this time, according to the affected entities, and U.S. Authorities, there are no indications that these events were cyberattacks and all of these companies eventually moved to backup systems or fixed these issues in what seemed to be a timely manner. While the NYSE was down for 4 hours, there was minimal impacts to the stock markets as they were able to get systems working in prior to the end of the trading day.

However, just because these seem to be coincidences, doesn’t mean we shouldn’t consider the possibility of a coordinated cyberattack and what the response should be. The suspicious twitter feed that the hacker group Anonymous placed the day before these events should be taken seriously as an indicator that maybe there was knowledge of an impending cyberattack. Authorities should investigate this as the possibility that an insider from one, or all of these entities may have provided the knowledge is conceivable. U.S. authorities, to include DHS, DOJ and the military should be considering how they would respond to a similar event with such disparate, yet economically critical industries being affected.

It is also good time, if you own a company, especially a Small to Mid-Size business to look at the potential crises that could result from such a “glitch”. All companies, in some way or another, are dependent on technology for their success and that technology will not remain the same forever. Whether it’s a standard update of that technology or a migration to a new or better one, there is a need for “worst case” scenario planning and preparation.

First, do an assessment of the impact of any updates or migration prior to actually testing the upgrade. Some of the questions to be asked are:

  • What would happen if this particular segment of my IT architecture doesn’t work? Will other components be affected?
  • Who will be affected? How will we notify them?
  • What is our backup plan? How long will it take to get back up?
  • How will we test and will the test place the same load on the software as a live engagement?

These questions should form the background for the implementation plan and a recovery plan for the update.
Second, validate the software (patch) for authenticity and test the patch in a development environment before pushing the upgrade to production. Most issues are identified here and can be expected or corrected prior to the production system upgrade.

Third, backup all data that could be affected by the upgrade. Ensure that this is done before and after the upgrade.

Fourth, have a Change Management plan, process, and execution which will include a set date and time of the upgrade, fall back plan in the event of a failure, and notifications sent before and after to any affected parties.

Fifth, after the upgrade, continue to test for data integrity and that all critical features or known issues/workarounds are working before the upgrade is marked as complete.

Having a plan in place greatly reduces the risk that IT “glitches” associated with upgrades or migrations will occur and cause reputational damage.

Leave a comment