In my last article (“The Future of the Enterprise – An ‘Orchestrator’ of efforts”), I talked about how Enterprises are starting to shift towards an Orchestrator model rather than having everything in house. So I then started looking at that future and wondering “How would security work in that model?”. It’s an interesting question that I’m getting asked more and more about by Security people in different companies. And I’m wondering if I found another issue that doesn’t support the ‘Orchestrator’ business model and will lead to a security solution.
In Security, there are any number of standards. There’s the ISO 27000 series. There’s NIST. There are other standards. But they are all based on a common concept – create a policy in-house and then prove that you are meeting your own policy. Your policy may be as simple as ‘have passwords’ and your password could be something like ‘123’ and you are meeting your policy. That doesn’t mean, though, that you are secure.
But those standards begin to break when you shift to the Orchestrator model. If, in the Orchestrator model, you have 2 different organizations following their OWN policies and those policies aren’t aligned (eg. Password with 8 alphanumerics vs Passwords with 12 alphanumerics and special characters), how do you deal with that? In both cases, you may have companies that are in compliance with ISO or NIST or something else. But in the Orchestrator industry model, who’s to say which implementation of a standard is correct?
I believe that there is a need to shift the industry standards to create a base line that companies are then measured against. For the longest of time, I wondered by there wasn’t an Underwriter Labs (UL) or Canadian Standards Association (CSA) group that certified IT products as being safe from a cyber security point of view. There’s an actual standard, ISA99, that tests industrial automation equipment for known and unknown vulnerabilities.
When you talk about true technical standards like XML or SAML or OAuth or (list your TECHNICAL standard here), you actually have multiple companies coming together on a technology so that each company’s solution can work with the other solutions. These are true, cross company collaboration into standards. But, keeping in mind that everything is a solution and has 4 components (people, process, technology, governance), those technical standards are just focused on 1 area of a solution.
The Orchestrator model is actually all 4 components of the solution and we’ve been using ISO27000 series, NIST’s CSF, and others, to measure the people, process, and governance aspects with some technical thrown in. I would suggest that for the Orchestrator model to continue, there will be a change in the view of the security model to looking at the individual solutions rather than the operational models of each company. When doing a Risk Assessment of a SaaS vendor, you often end up getting a SOC(2) certificate saying that the company is meeting their Policies. But that doesn’t talk about the design of their solution.
Here’s my proposal – I think there needs to be a ‘technical’ standard with baselines for all solutions. Not for the operational model but for the actual technical solution. Think an extension of the various technical standards but to full design, not just interaction between two systems. Actually, while writing that, this is actually what I’m proposing. We’ve created standards for communication between systems, there’s no reason why we can’t create standards of communication between companies.
Think of it this way – we already have de facto standards; Password structures, FW implementations, use of AV, etc. But we continuously have to communicate from one SaaS Vendor to one Customer what those implementations are. If SOC(2) certificates are being communicated for the operational side of things, should we also have a ‘Technical Risk Assessment of Solutions’ certificate be sent? Just think of the ROI that it would create.
Each Customer does a Technical Risk Assessment (TRA). Each Vendor has to communicate to each Customer about their security posture. There’s a real ROI for both the Customer and the Vendor to just communicate a TRA certificate created by a Trusted 3rd party. But how do you measure to create that certificate? SOC(2) certificates can be created measuring against ISO or NIST or SOX or HIPPA or something else. What do you measure technical solutions against?
Here’s what I propose – we come together to create a standard for measuring designs against from a security perspective. And before you say “we can’t measure designs”, we already do. That’s why we have things like ARBs or Technical Risk Assessments. We just don’t measure them against an industry standard. If Building Architects have standards to meet yet are still able to bring some artistry to their work, there’s no reason why we can’t either.
My next article will break down what I propose an Industry Standard baseline should be that we can measure against. I’d REALLY like to hear your feedback on this concept, so looking forward to hearing from you. In the meantime,
Hope this helps,