December 20169The return on investment for operating system upgrades is generally zero (or worse). It is disruptive to our regular projects, to our end users, and, sometimes, to our customers. It is true that the day after support ends, nothing untoward happens ­ there's nothing magic about the date. However arbitrary the end-of-support date is, it serves an important function of being a line in the sand. On one side of the line, we know the vendor is doing what they can to keep the technology current and safe. On the other side, the vendor is doing nothing at all. With 6,419 new vulnerabilities published in 2015, it is a very good bet that there were also a large number discovered that were not published. Staying current with versions and patches is just good risk management. The more time the bad guys have with a system, the more likely they are to find vulnerabilities. Balanced against the risk of system disruptions caused by bleeding-edge software, it makes sense to stay with the most current stable versions available.Even though simple risk calculations tell us to stay current, there are plenty of organizations that choose to stick with older versions. Many years ago, I was with a group of security executives getting briefed on the new security features in Windows Vista (which were pretty impressive at the time). When asked what we thought about this and when we might start to convert, one of my colleagues said, "This looks great and we like what you've done with security here, but there's nothing here that will help my company sell more of our products so we will upgrade when you put a gun to our heads and pull the trigger." That attitude, which is perfectly justified and completely reasonable in context, is the reason we are asked to demonstrate our record of keeping things patched and to show that we have completed our upgrades.If, on the other hand, we started planning now for our conversion to Windows 10, if we were proactive about patching, if we used our innovative energies to find new ways to protect our customers, we might find ourselves in a very different environment.The headline on this piece is intended to be provocative, but the idea is very straightforward. Focusing on the mandates is less productive than focusing on doing the right thing. Sure, there will likely always be the one-off item that needs to be done so you can check a box, but the vast majority of "compliance" is really just doing a good job of managing the resources we are entrusted with. Should you have a change management regime because the auditors and examiners say you should have one? I submit that we should have a strong change management regime because we will have less downtime, smoother upgrades, greater collaboration between departments, and increased visibility into our organization's needs. It is possible you might need to tweak something to satisfy an outside evaluator, but more likely they will spend their energy elsewhere.Vendor management came into vogue a few years ago; following some high profile incidents where corporate networks were breached because of insecurity at vendors that had access (remember the reason for the rule). Banks that recognized the potential for this threat vector long ago were well-positioned to meet the new requirements and may not have had to change anything. Other institutions that did not recognize the risk had to implement new and expensive programs to introduce monitoring. Those who waited to be told they had to do it also had the pleasure of having time pressures to respond. Plenty of consultants made good money helping banks respond to the "new" requirements.For too long, our industry has been reactive to the demands of auditors and regulators. The time has come for us to take proactive steps to ensure the safety and soundness of our institutions' IT. In the long run, it will be cheaper and more effective for our industry than continually playing catch up.BCBalanced against the risk of system disruptions caused by bleeding-edge software, it makes sense to stay with the most current stable versions availableScott Blake
< Page 8 | Page 10 >