The first rule of FinTech security

The first rule of FinTech Security is we don’t talk about FinTech security!  The second rule is everyone must have security.  Sound familiar?  That’s how it feels in many technology circles.  Today’s information security world is booming with not just products and services, and the security threats therein, but multiple interpretations of the word “security”.

The Problem

Ever get the feeling no matter how much is done with security, it’s never enough?  Your information security people are not satisfied, or are approaching your meetings with more bad news?  Where does practical application versus security goals align with risk avoidance?  Here is a reality:  To sell a product or service means to engage in risk.  Technology is a market and delivery mechanism, and threat vector.

Cue Gene Kim’s book The Phoenix Project.  Gene Kim got his start in Information Security with open source Tripwire software.  His career is peppered with work in IT controls and standards, making a career of showing how the compliance industry is woefully behind.

Probably the single most prolific example of information security practices gone afoul is the character in the book, John, where risk avoidance and security compliance wins over business value and productivity.  Stifling!  With PCI compliance and vulnerability issues, John constantly reminds leaders in his company of the risk to security.  Coming from auto lending, John’s perception of security is alive and embraced by many.  Not only is that character hard to read, I drew parallels having worked in FinTech.  I’ve often threatened security teams with buying the book and dropping on their desk so they understand where the rest of the company is coming from.  Clearly, there are opportunities.  Not one admitted to reading it.

What to do?  Here are a couple of thought strategies.

Security Alignment Strategies

1. Do security people understand the business?  If no, start immediately.  How can you secure that which you do not understand?  Like all other areas of the business, competency must be shown first before security engineering can begin.
2. Are you hiring ethically salient security people or questionably ethical characters with security knowledge?  Two different things.  If your security team disappears in your office supply or broom closet for hours and looks like a 80s rock band, you may have a problem (i.e, Fifth Estate — Wikileaks).
3. Understanding what DevSecOps is trying to do.  The need for Agile and public cloud services is not going away.  In fact, companies like Microsoft are enticing organizations there as IT transitions from ownership to right to use subscription models.  DevSecOps is a cooperative system where business operators are supplied with tools and processes to help with security decision making – not leaving it up to security staff members to manage alone.
4. How many tools do you really need?  If you have more than seven toolsets that are large portions of IT spend, you may have a problem with a runaway security program.
5. Information technology’s primary role is making sure projects return business value.  IT is responsible for making sure projects are done in a supportable manner, which includes security.  I recommend reading Mark Schwartz’s book, The Art of Business Value for more information on IT’s role in business.

These thought strategies are a good start understanding the business, recognizing technology needed and implementing security that works for the business at hand.