Those who have been following my posts know I have an evolving love/hate relationship with online security questionnaires. Done well, they can speed up the process for the client and service provider and establish a properly shared understanding of where risks lie and how those can be managed over time. Done badly, they can be time-consuming hair-pulling confusing torture to fill in, that does little to really get to the point of how risks are managed.

This leads to an interesting point, how risky is it to use an online security questionnaire to collect, collate, and maintain such security-critical information? Such questionnaires often cover everything from how people are hired to how data is stored and to what mechanisms are used to store security keys and the overall system architecture. All are VERY useful to hackers and competitors alike.

Remember, an online security questionnaire service provider is just as much a third-party provider to you as any other SaaS provider. In fact, given you will be using them to assess all your other third-party providers, I think it is appropriate to be rather demanding on the security controls they employ.

In my previous article on security questionnaires, I listed a baseline of security controls security questionnaire providers should follow, I would like to update it, make it more specific, and include some data usage checks. This is detailed in the section below. Feel free to use this ‘as is’, the security requirements below are yours to use as you see fit.

Security Requirements for Security Questionnaire Providers

• All the questionnaire data entered MUST BE cryptographically strong encrypted both in transit and at rest (both in the production and backup environments).
  • This implies the questionnaire data MUST NOT exist in any other environment, such as test or staging.
• Access to a questionnaire to fill in MUST require a distinct account for the organization filling in the account, and direct email linkage to the questionnaire MUST NOT be done as it is not considered secure.
• Software Developers for the security questionnaire application MUST NOT have access to the production environment and in particular the production environment data storage and backup storage environments.
  • This means in practice there needs to be a distinct DevOps function apart from the Software Developers.
• The source code for the Questionnaire Service MUST BE maintained in a secure repository that utilizes distinct Software Developer logins with MFA.
• On the pages where questionnaire data is directly entered and then subsequently displayed, 3rd party tracking libraries MUST NOT be used. Likewise, 3rd party tracking libraries MUST NOT be present in login pages and any pages where passwords are entered or controlled.
  • This is to reduce the risk of a 3rd party tracking library either capturing sensitive information or credentials.
• All passwords MUST BE stored using a cryptographically strong one-way hash.
  • Passwords MUST NOT be stored in plain text or using a weak hashing algorithm (for instance md5!)
• Passwords MUST NOT be less than 10 characters in length and tested for complexity.
  • This is to ensure setting the password to ‘password’ and similar obvious words or phrases is not possible.
• Failed password account attempt lockout MUST BE implemented (either as an absolute lockout or a timed lockout) after 3 attempts.
  • This is just basic good security.
• Password reset MUST BE achieved by a password reset email with a time-limited reset token link.
• Questionnaire data when deleted or no longer required MUST BE wiped and then deleted to ensure there is no residual data. This includes backups (which implies per client questionnaire encryption keying of backups, or distinct per client backups);
• An External Pen Test summary report enacted in the last 12 months MUST BE provided in which no critical or high issues are left unresolved and confirmed fixed.
  • The system needs to be proven to have a regular test for baseline security.
• All entered questionnaire data MUST remain the property of the provider who entered the data at all times and cannot be considered an asset of the business operating the Security Questionnaire service. It MUST NOT be given or sold to any other party either in part or whole (excluding the client who requested the questionnaire).
  • This stops the business from providing the Security Questionnaire service on selling the information entered in the questionnaires. Better safe than sorry!
• Summary information from the questionnaire MUST only be used by the client who requested the questionnaire for the purposes of security risk assessment, it cannot be given or sold to any other party.
  • This is to stop the client who requested the questionnaire on selling the information entered in the questionnaires. Again better safe than sorry!
• The business providing the Security Questionnaire service MUST HAVE a suitably qualified person whose role specifically covers the responsibility of maintaining the security of the online service.
  • This is to ensure there is a security resource within the business and security is not an ‘assumed’ undertaking.

Now some may consider this a long and difficult list of controls to adhere to, but, given the security-sensitive nature of the information being held in such a system on potentially many businesses – I think it is wholly appropriate. Such systems need to be held to a higher standard and provably so. If such a system was to be compromised the potential damage could be significant and widespread! The old way of doing things used to primarily depend on the security stance of the client and vendor, as they exchanged the information directly, now an additional 3rd party is playing piggy in the middle (for a fee of course); that additional dependency needs to be tightly managed for everyone’s benefit.

---

If you do find the controls above useful, please like this article. If you have any feedback, please message me on LinkedIn or drop me an email. I’ve also enabled commenting on this article if you want to discuss it more publically.