I sometimes get questions about the applicability of secure software standards and guidelines to work described as innovation or innovative. Sometimes these interactions begin with an outright rejection of “legacy” risk management in the context of an emerging new “thing.” I believe that under most circumstances, any conflict that begins here is voluntary and avoidable. As global financial services organizations, our risk management obligations remain in force for mature & stable development projects as well as for innovation-oriented efforts.
In any discussion of innovation, I arrive with my own set of assumptions:
- Innovation can occur at all levels of the human, business, operations, technology stack, and often requires concurrent change at multiple layers.
- Innovation, in any context, does not invalidate our risk management obligations.
- One of the most common and insidious innovation anti-patterns is constantly looking for the next hot tool that’s going to solve our/your problems.*
Software-centric innovation may generate new or help highlight existing gaps in your secure software standards/guidelines.
If there are gaps in your existing secure software guidance — so that the new “thing” seems to be out of phase and disconnected from that legacy, those gaps need to be closed.
Sometimes gaps like these appear because of changes in vocabulary. This is generally an easy issue to deal with. If all involved can agree on the trajectory of the innovative development, then you can begin with something as simple as a memo of understanding, with updates to secure software standards/guidelines to follow at a pace determined by the priority of that work (if there is a formal, fines & penalties regulatory compliance issue involved, it is a higher priority than if were only an exercise in keeping your documentation up-to-date).
Other times an organization is introducing a new business process, a new type of business, or a new technology that does not map well to the existing concepts and/or assumptions expressed in your secure software standards/guidance. An example of this situation occurred as we all began to invest in native mobile apps. At that time, mobile app ecosystems did not incorporate a lot of the common security mechanisms and capabilities that had been in place for server and desktop environments for a long time. This type of change requires a mix of simple vocabulary and content change in corporate secure software standards/guidance. Again, if those involved can agree on some fundamental assumptions about what the new software is doing and where it is executing, along with sharing an understanding of its external behaviors (passing data, resolving names, signaling, trusts, etc.), you can take a multi-step process to get secure software guidance synchronized with your business environment. The first step being some sort of formal memo of understanding, followed by the research, collaboration, and writing required to get your secure software standards/guidelines and your business operations back into phase.
Is it possible that your enterprise could introduce something so alien and so disruptively new that there was just no connective tissue between that investment and your existing secure software guidance? Sure. What if financial services enterprises decided that they needed to begin building our own proprietary hardware (from the chips all the way up the stack to network I/O) to deal with the combination of gigantic data-sets, complex analyses, and extremely short timelines (throw in some ML & AI to add sex appeal). Our current generation of secure software standards/guidelines would not likely be well aligned with the risk management challenges presented by microchip architecture, design, implementation and the likely tightly-coupled low level software development that would be required to use them. I would not be surprised if much of what we have currently published in our organizations would be virtually unrelatable to what would be needed to address the scenario above. I think that the only businesslike path to dealing with that secure software challenge would be to acquire highly-specialized, experienced human resource to guide us through that kind of dis-contiguous evolution. That would be a material challenge, but one that our business will not often face.
Given the current state of our secure software training and guidance resources, it seems like most of us in global Financial Services enterprises should expect to find that most innovation efforts are aligned-enough with the existing secure software standards/guidelines, or (less frequently) only somewhat out of sync because of differences in vocabulary, or misaligned underlying assumptions or concepts. Those are expected as part of our evolving software-driven businesses and the evolution of hostile forces that our businesses are exposed to.
So, innovate! Any of our success in the global financial services marketplace is not guaranteed. And, dive into working through decision-making about your architecture, design, and implementation risk management obligations. And finally, use the existing technical and human resources available to you to deal with any new risk management challenges along the way.
* Rough quote from: “Practical Monitoring: Book Review and Q&A with Mike Julian.” By Daniel Bryant, Nov 07, 2017. https://www.infoq.com/articles/practical-monitoring-mike-julian.