Shared security models
Why your business should have one.
In 2022 and beyond, cybersecurity is going to be an ongoing topic of discussion between essentially every business and their customers.
Buyers of pretty much any type of good or service - not just software - will be interested in the ability of their vendors to protect the confidentiality, integrity, and availability of their data. These organizations are certain to have widely varying levels of sophistication and needs when it comes to cybersecurity, ranging from asking the occasional question, requiring the completion of detailed security questionnaires, provision of external audit reports, or even conducting technical due diligence.
Addressing customer and prospect security concerns can at times become all-consuming for software vendors, especially smaller ones without dedicated information security teams. To assist in addressing this problem, I would highly recommend that you implement a relatively simple and effective tool: a shared security model. Doing so will:
Actually improve your and your customers’ security posture
Preempt prospect and customer questions
Show organizational maturity
A shared security model answers the question “who is responsible for what specific tasks in securing customer data?” While the answer might seem obvious to some, when you start drilling down into the details, things get quite complex very rapidly. I think this is especially true for Software-, Platform-, and Infrastructure-as-a-Service (SaaS, PaaS, and IaaS, respectively) offerings.
For example, who is responsible for applying updates to patch vulnerabilities? Well…it depends who is hosting the application. For traditional customer-managed deployments, the vendor will need to release a new software build and the customer IT team will need to apply it. For SaaS deployments, however, this is entirely on the vendor.
Similarly, who is responsible for enforcing password complexity requirements (assuming you believe this to be important/a good idea)? If the application has a basic username/password login interface, this is entirely on the vendor’s end to enforce. But if the customer uses an external identity provider like Azure Active Directory or Okta to facilitate single sign-on across their enterprise, then user authentication is entirely at their discretion, including the characteristics of user passwords.
Improving security
Understanding how to securely operate your product is an absolute requirement for your customers to have any chance of protecting themselves against digital threats. While optimally your applications should come completely pre-configured and -hardened “out-of-the-box,” there are almost certainly going to be steps the customer needs to take to install them correctly. For example, how should the customer think about hardening the operating system upon which the application (or container, if applicable) runs? Are there any ports that should be specifically allow- or deny-listed?
Similarly, while in operation, your software should run securely by default, but again, this represents an ideal. Things to consider are questions such as whether the application validates any external code (plug-ins, extensions, etc.) that can run on top of/within it and what vetting a customer should do of these beforehand. Similarly understanding how and where to report security vulnerabilities or bona fide incidents is a critical piece of information.
Putting all of these things in an easily accessible format, especially one that links to more detailed sources of information, can go a long way towards enhancing security.
Polishing your image
Nothing says “we take security seriously” like having a detailed security model that explains the relevant roles and responsibilities. For younger businesses that are trying to establish themselves in the market, security is often a challenging topic during the sales cycle. Buyers generally have multiple competing solutions that they need to vet, and demonstrating competence and confidence up front can help prevent you from getting singled out for “special attention” from their information security team.
Pre-answering questions
As part of the sales process as well as throughout your relationship with customers, you are likely to get a steady stream of questions regarding your organizational policies and practices. Unless there is a specific reason to keep the answer confidential and protected under an NDA, then it makes sense to add it to your shared security model, if appropriate. “Self-service” information sources save time for both your team as well as the customer’s, preventing time-consuming back-and-forth discussions over simple issues.
Conclusion
Based on the above benefits, I think that publishing a shared security model represents an easy win for pretty much every software vendor. In terms of examples, I believe the “big 3” cloud providers, Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) were the first to develop their own models, due to the complex nature of the services they offer. Many organizations have followed suit, and I developed and implemented the ThingWorx shared security model while at PTC as well the Privacera equivalent. Take a look at any of these for benchmarks and ideas, but adapt your model to your own business conditions and customer requirements.