Do You Have An Established Security Program? Are You Sure?

Everyone’s answer to the title’s question is usually 'Yes', but as my experience seems to prove, yes apparently means many things to many people.  Seldom does their assurance meet my criteria, usually defined by my security team’s Third Party Risk Assessment (TPRA) requirements.  Our Information Security Management System (ISMS) isn’t unique and is based on the same industry maturity model methods that most other security-aware companies adhere to (ISO/IEC 27001).  Why is it then so difficult for vendors to complete a reasonably short risk assessment to gain an enterprise customer?  Most of the time I find out they simply don’t have a defined security program or it’s so anemic they’d fail most enterprise risk assessments.

There’s our problem.

In the rush to market, apologies are acceptable to investors in lieu of properly defining, implementing, and documenting an ISMS.  Only after a breach or expanding sales channels into compliance-controlled environments is security properly addressed.  We’ve seen it with several popular consumer applications, but laissez-faire security methodologies are increasingly tolerated by enterprise-focused application providers, only because they haven't had anything bad happen… yet. This last year I’ve had two increasingly common situations where I’ve tried to implement some popular applications into our team to then have our InfoSec TPRA process stall implementation.  Where some would say InfoSec’s strict program is blocking the next cool app that I can brag about to my fellow nerdlings, they’re only trying to prevent a security train wreck.

Scenario One:  I was stakeholder for a project to adopt a popular agile solution, and instead of using an on-premise solution we opted for a SaaS solution to keep IT costs down (standard reasoning). This started a TPRA process that was immediately met with issues.  Our interface with the vendor was almost completely automated and finding a live person was near impossible.  After several web tickets through their support teams to find an account representative able to discuss our risk assessment needs, it was pretty much a non-starter because: A) they didn’t have educated staff to complete the assessment with confidence, and B) there was no compliance documentation or process to address my need.  Due to non-existent PI or corporate data being stored in the SaaS solution, my team was able to complete a risk acceptance, having to accept a reduced integration feature set because of the vendors inability to meet a common standard of compliance.  What did the lack of security program cost them?  Who knows, the failure to comply to an initial TPRA probably prevents potential customers from even touching their sales pipeline.  I could guestimate millions in unrealized revenue but I'll bet the sound of their channel guys tears weeping at the GSA dollars far off in the distance is proof enough.

Scenario Two:  I am still sponsoring this project, much to the delay of another “cool app” vendor who’s security program is so overwhelmed they’re many months out from starting my risk assessment.  In this case, they did have a quick response and after a few back and fourths, I did receive some preliminary compliance documentation from the get-go.  Mind you, this was quickly accessible because the company experienced a very public breach the previous year, so their ISMS program was defined and improved only after the wake of a public security failure.  This already raises a flag with me and my InfoSec but the app is quite useful so we press on.  Rather than complete my TPRA, they want to use their documentation instead, but as they don’t define maturity models, yet my InfoSec team still required our assessment to be completed.  I side with my team on this, given the application’s EULA concessions and the previous security breach.  If we don’t use their application in the end, so be it, the gains don’t outweigh the risk.  Our alternate to their desire to not complete our risk assessment is the standardized Consensus Assessments Initiative Questionnaire (CAIQv3.0.1).   This behemoth is 298 questions (with multiple part-answers) and is what we use when someone fails our TPRA, and something other companies use instead of their own vendor-friendly questionnaire.  30~ questions isn't so unruly.

If I’m flustered over just a few risk assessments, think of your own InfoSec team, having to deal with multiple departments all wanting the next neat app for the often the most mundane business need.  Thanks to innocently formed Shadow IT programs, risk assessments are usually initiated after data exposure is complete.  What options exist for us when business processes become fragmented between small application publishers whose definition of security is sometimes the stuff of nightmares?

• For the customer: have a backup/alternative plan.  It’s your money, it’s your reputation, and it’s your data.  If that means not using a collab-agile-devops-snap-insta-swag-app, so be it.  You’ve survived up to this point so you’re doing something correctly.
• For the customer:  Work with your vendor to help understand your need with respect to their security model’s maturity level.  In scenario one, I had few con-calls with their enterprise team (once they had one established) to help them understand why we ask the questions we ask, and how we define our security measures and what to expect from similar customers.  F5 was a good customer to talk to given our industry and customers we serve.  Don’t be the typical holier-than-thou InfoSec person if they’re at a lower maturity than you.  It’s in everyone’s best interest to solve the problem and be good security stewards.  It may accelerate their program to comply with your requirements and everyone wins.
• For the vendor:  We know InfoSec costs money and it may be lower on your 5 year plan but as we’ve seen, growth for an application can exceed your operational plan by leaps and bounds.  Be prepared to ramp up your ISMS requirements to follow unexpected growth.  As in scenario one, they were leaving millions on the table by not anticipating basic security standards for their SaaS solution and because they couldn’t document this gap, there was no visible lost revenue and thus no perceived urgency to fix the problem.
• For the vendor:  In my scenario two, I feel the vendor was frustrated that we still wanted our own process to be completed in lieu of their provided documentation.  In my experience this process is how most enterprises with even basic security programs work, and it will continue to remain that way.  It’s their data and they’ll protect it accordingly.  Data security should not be viewed as an inconvenience.  Given the vendor in scenario two already experienced a security breach, I didn't take their documentation as a sufficient altnerate to our risk assessment.  Again, money left on the table because the vendor's InfoSec team was understaffed and overwhelmed by the increased security demands larger customers expect.

Security programs are a good thing.  If your InfoSec seems to get like an overbearing or demanding parent, that makes you the child that wants the new shiny toy.  Do we give the children whatever they want?  Of course not!  You make them re-shingle the roof or pour a foundation for a new hot tub if they want to.. oh, I don't know… eat?  Customers need security programs to protect users from themselves and from the data they inadvertently expose.  Vendors need security programs to onboard customers they don’t even know they’re missing.  Immature security programs cost me as a customer the ability to use current and cutting-edge applications thus making my life easier.  My plead to vendors is to get on the ISMS train sooner than later and let me use your products!