One of the big changes in security I have seen over the years is a significant increase in the use of security questionnaires. Much of this is understandable and is a result of an increase in the importance of security to information systems and an increase in regulatory regimes that include scrutiny of security practices. Another factor of late is the increasing move to cloud services by many businesses.  Not surprisingly, cloud services customers want to do their due diligence in vetting what a service provider does to secure their cloud services and the critical business data contained therein.

One of the challenges in the increased use of security questionnaires involves the relevancy of the questions as it pertains to business risk, and more specifically whose risk is being assessed.  It’s perfectly reasonable, of course, for customers to ask questions pertaining to their specific risk of using a product or service. It’s less useful to ask about all business risk of a supplier, because much of that risk is the supplier’s risk, and not the customer’s risk.   Additionally, the time spent culling through those answers when they aren’t really relevant costs customers valuable time and resources.

To use an analogy, consider daycare providers. Any parent with a child is understandably going to check out a daycare provider (and the provider’s facilities) very thoroughly before dropping off a child there. The parent might like to know whether the daycare provider is licensed. Also, what the facilities look like – are they clean? Safe? How many children is the provider caring for at one time? A parent is assessing the risk to his child and the degree of confidence in the provider to keep the risk minimal and acceptable. All of which is reasonable and understandable. Now, suppose a parent wants to assess not the daycare provider’s home but the provider’s vacation home. That would clearly be out of scope: while the daycare provider (as a vacation home owner) might have some risks (rattlesnakes below the porch, mountain lions in the area, etc.), those risks are not relevant to a parent because the vacation home isn’t where the daycare services are provided.

Another challenge is the proper scoping of security questionnaires. Customer’s risks (and responsibilities) are different between on premises and cloud services, as well as different across cloud service types largely because of the degree to which the customer is managing a system vs. a supplier managing it.  Security questionnaires that ask the supplier to answer questions for “all products and services” are generally unworkable for that reason. Also, a security questionnaire initially designed for cloud services is largely irrelevant for on premises products, e.g., “how often/how quickly do you (the supplier) apply patches?” With on premises, it is - of course - the customer who is responsible for applying patches.

Another challenge is security questionnaires that attempt to glean supplier answers for “all products and services,” since these services are likely very different as to feature/function as well as operational security practice (and for good reasons). Think about a vacation home/resort builder with properties in Hawai’i, Idaho and California. Those properties are likely to be built very differently because of reasons including climate (not much snow in Hawai’i, except on Mauna Kea), threats (lava flows and hurricanes in Hawai’i, earthquakes and wildfires in California, avalanches in Idaho) and so on. There are good reasons why both the building designs and “operational practice” at the resorts are different. If you want to know about the Hawai’i resort, you should only ask questions about that resort. To get back to the tech realm, a single questionnaire is unlikely to be useful or generate meaningful responses for “all products and services offered.”

Another challenge is nomenclature. Terms can vary wildly according to who is asking a question and what his/her context is. To use an example, many military pilots refer to aircraft as “birds.” Obviously, this usage of “bird” is a lot different than what an Audubon Society member denotes as a “bird.” If you don’t know what is meant by X, the answers to questions involving X are not necessarily going to be accurate. Terms in questionnaires should be defined very clearly, ideally upfront. For example, what is meant by a “vulnerability?” Is this a configuration weakness? Does it refer to any coding error? Or is a vulnerability a coding error that specifically leads to a security weakness?  What does “software testing” refer to? Regression tests? Penetration tests? Static code analysis? Dynamic code analysis? Spelling out what terms mean upfront, with examples, helps everyone stay on the same page in terms of “I am concerned about X,” which can be responded to by “… and here is how we handle X.”  

One of the best things vendors can do is promote the use of standard templates where possible: that is, a set of security questions that have been broadly adopted across industry. One such example for cloud services is the Consensus Assessment Initiative Questionnaire (CAIQ), which was developed by the Cloud Security Alliance (CSA). The advantages of a standard security questionnaire such as CAIQ are multiple. For one, having answers to commonly-asked security questions at the ready gets everyone to the finish line faster.  If you anticipate reasonable security questions your customers ask, and you answer them in advance in a standard format, you can make them available easily and quickly. Maybe even just publish them. Reasonable transparency inspires customer confidence and it also is much more efficient than responding to multiple one-off security questionnaires that kinda sorta get at the same concerns, only the questions are phrased slightly differently. Standard questionnaires also help ensure customers and vendors are speaking the same language. It’s also much easier for customers to compare apples to apples (Vendor X answered this question one way, Vendor Y answered the same question differently). Customers can far more easily determine how different suppliers address specific areas of concern.

Knowledge is power, definitely, and asking meaningful security questions is part of customers knowing what they are getting and better gauging their risk. “Meaningful” includes customers scoping questions to specific products and services the customer either uses or is contemplating licensing. “Meaningful” also means asking questions pertaining to risk to the customer, not all business risk of the supplier, and making sure the terms are well-defined. The more we – vendors and customers – can make this dialogue meaningful and smooth, the better off we all are in getting to Yes. Or even “Yes, but I have just one more question.”

For more information:

Oracle’s corporate security web site is located at https://www.oracle.com/corporate/security-practices/

More information on Oracle’s security solutions can be found at https://www.oracle.com/security/