As Shadow IT is exacerbated by low-code, how do the most successful security teams get ahead of the risks involved?
Sort by:
If you have a certified platform to build low-code applications, then the central enterprise architecture team and security architect can coordinate and incorporate the relevant security policies into that particular platform. The danger lies in people using standalone low-code tools and then building applications here and there. Even writing an Excel macro can be treated as a Shadow IT application.
The other issue with the Shadow IT applications is there's no maintenance. If someone writes a Shadow IT application that is not part of the corporate standard or deployment guidelines, and then that person leaves the organization, then it's an issue. Now nobody knows how to maintain that code. We have to find the source codes and figure out how to enhance it. That's where building things outside the standard corporate guidance becomes an issue in addition to the security issues involved. Having a good platform will solve most of these issues and standardize the way individual groups build applications and make it part of the enterprise architecture—a standard bill system, standard deployment system, as well as documentation of most Shadow IT applications and their capabilities.
I often wonder how does one differentiate between Shadow IT and Ingenuity/Creativity? Sometimes, it's just a matter of perspective.
I think the keys to success here are pretty simple (to say, not to do) - being involved in the process as early as possible (shifting security left); embracing change (we can't solve new problems with old thinking); acting as an enabler (not as a department of NO).
One of the biggest things I would advocate for is getting started with the Governance and Risk Management early and evolving along the way. Think about the broadest and the most important "guardrails" to put in place first and get more and more granular as things progress. This is not an advice for all circumstances, but in my experiences those monumental GRC efforts, before a single line of code is written, are some of the biggest demotivators.
As I have written in another post, at this point in time citizen developers are mostly mythical creatures. Things will go south, the quality of most solutions will be questionable, supportability problems will arise. But set those biggest, broadest "guardrails" and let things evolve. Inevitably, useful patterns and interesting solutions will emerge.