And will that even be enough?
In last week’s post, Application Risk Landscape (in)Visibility, I wrote that
Applications … stress every facet of effective risk management practices and tools.
This is never truer than when the applications in question are third-party applications (or offered as managed services).
Enterprise risk management begins by first establishing an enterprise’s mission, strategy and objectives. (Getting Started with Risk Management page 10, ISACA (c) 2018)
There is simply no scenario where two enterprises operating in distinct industries under entirely separate management would ever share common objectives, paint the same risk landscape, or have the same risk appetite (or tolerance), and so on and so forth.
The $64,000 question that each enterprise needs to answer for itself is under what circumstances might these differences matter?
For example, a near universal gap sits between an enterprise’s rationale for licensing software and the vendor’s warranty for that same software.
An enterprise may standardize on a particular publishing tool to ensure cost-effective document auditability, yet the “mission and strategy” of the publishing tool vendor dictates that the vendor explicitly limit the warranty to exclude suitability for that very purpose.
To be clear, this is not shady behavior. If the vendor has thousands of clients, how can it possibly warrant that the tool (designed prior to licensing the product) will meet these divergent requirements?
If you think this is a contrived example, I challenge you to find a Commercial Off The Shelf (COTS) software license agreement that does anything more than suggest that their software will mostly match its documentation.
See the Limited Warranty that comes with Microsoft Publisher 2010 (and all of their other offerings). It includes:
“LIMITED WARRANTY
G. … MICROSOFT EXCLUDES IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.”
Microsoft licenses a product called “Publisher” but explicitly states that the limited warranty excludes suitability for a particular purpose (like publishing?!).
Of course, Microsoft (in this example) has a commercial incentive to add features that delight their users – but there is no reliable means to ensure that an enterprise’s publishing control requirements will remain aligned with the Publisher product road-map over time.
Secure Development Lifecycle: What will it take for software governance to catch-up to pharmaceuticals or our food supply?
Every ingredient and process that goes into producing pharmaceuticals is monitored and controlled because the scale and severity stemming from ingesting a compromised drug is incalculable.
Are enterprises any less dependent upon software?
GDPR calls out processors but also ups the burden on owners to verify that their processors are using “state-of-the-art” technology and processes.
PCI Council, NIST, and numerous US State legislatures are giving heightened attention to software development practices (more detail to come on this).
However, unlike pharmaceuticals that come with a label explicitly stating what they are suited for, application vendors limit their warranty to the greatest extent possible.
What kind of visibility into supplier development processes (data) is appropriate?
Who inside your risk team will know how to interpret that data in the context of your risk matrix?
What about the risks that result when a strategic vendor CAN’T meet these emerging requirements?