CyberSecurity Is Not Someone Else’s Problem

CyberSecurity Is Not Someone Else’s Problem

We have definitely entered a period of CyberSecurity fatigue. When Capital One’s (tkr: COF), stock barely gets hit in the aftermath of a significant CyberBreach you know many investors – as Rhett Butler once said – “don’t give a damn”.

CEO’s need to “own” CyberSecurity and operate it like a line of business. Customer PII data needs to be protected at all cost. Our recommendations follow:

  • On-board CyberSecurity experts to your staff. The CyberSecurity Chief ought to report directly to the CEO. Regular dialogue should occur about threat levels, nature of threats (type, origin, etc), proactive measures, remedies and disclosure policy to customers, employees, Board members and shareholders.
  • Embed CyberSecurity swat teams in each business unit. Large companies like Equifax and Capital One ought to have cyber experts deployed full-time in each business unit working proactively to identify potential cyber threats.
  • Cyber teams ought to regularly run “hacking” exercises to identify potential weak spots. Be proactive in identifying potential cyber threats.
  • Information sharing. Cyber teams must share information across business units and outside of the company’s walls to promote best practices.
  • Leverage off-the-shelf CyberSecurity tools and services. Understand what it is that third-party vendors provide as products and services. You will likely require multiple vendor relationships to address all potential threats. CyberSecurity tools and services are getting more advanced. Many leverage machine learning for pattern recognition/ threat detection. Similarly, cloud service offerings are becoming more advanced and also leverage machine learning to proactively find and eliminate threats (see Oracle’s “autonomous database“).
  • Hold vendors accountable (or as Jamie Dimon once said: “Fire the vendor. Fire the ***holes folks”). I’ve read a number of accounts concerning the Capital One breach and it appears Amazon Web Services (“AWS”), was aware of the AWS configuration flaw. Reading between the lines my best guess is AWS did not want to proactively resolve the configuration flaw because:
    • A new configuration would have meant new scripts and workflows for customer/partner organizations. Why invest in new code and workflows when a band-aid will do? (cue sarcasm) and/or
    • If word got public that AWS had a configuration flaw, it may have jeopardized AWS’s effort to win the $10 Billion Department of Defense “JEDI” contract.

Advertisements