For a long time, the development of scripts, software, or small bits of automation has been relegated to software engineers. However, the introduction of low-code/no-code applications has helped the development-opportunities pendulum swing to roles that don’t require software backgrounds. These low-code/no-code applications enable people to automate parts of their day-to-day jobs and bring their creativity to figure out how to make their jobs easier to bear.
These applications typically function by allowing a user to connect the functionality between their daily tools to one another, creating a flow. For example, Slack connects to email, which connects to the calendar, and then connects to Box, and so on. Additionally, small pieces of automation can be shared among users within an organization.
This article will explore several areas of risk that can emerge with the adoption of low-code/no-code applications and includes areas that security teams may benefit from considering in the risk assessment and threat-modeling process.
Permissions
Low-code/no-code applications typically get their start through a series of integrations. The integrations depend on the particular automated workflows that interest users. Authorizing a tool may very likely be an all-or-nothing decision. In an effort to achieve the intended automation benefit, knowing the applications they need to work with, we can draw from observations about how users have dealt with permissions in mobile applications.
Educating users on the permissions they are potentially enabling through the use of these applications is important. Similarly, security teams need to be cognizant of these integrations and the permission boundaries that could exist with these applications.
Cross-Team Access
Authorized applications and the permissions associated with them become associated with the low-code/no-code application in use. Teams that collaborate on automated workflows are able to tap into the originally authorized permission. This can prevent issues considering one user’s resources being exposed to another. This becomes more troubling if the originally authorizing user happens to have heightened permissions within the authorized application.
For example, a Slack administrator authorizes Slack and is collaborating with multiple team members to build automated workflows between Slack and other applications. That original authorization has heightened permissions associated with it. If abused by any of the other team members, the potential impact could be much higher.
Data Storage and Boundaries
Processes by their very design take place over multiple steps. The state needs to be stored throughout that process, which is likely going to be handled by the low-code/no-code application being used to drive the process. Output from one integration passed into another and so on until the final decision or action can be performed. Where that state is maintained matters; data flowing to unexpected places can be problematic for organizations with strict compliance requirements. This can also be problematic when attempting to determine system boundaries and gain a realistic appraisal of the environment, whether that’s for threat modeling or audit purposes.
This particular part of the low-code/no-code solution space is challenging. Creating enforceable policies around the intersection of permissions of a given application, data flows, and user roles is not something that exists in a mature state today. Security teams are, therefore, left to respond with their best effort; “enable the business” but also protect the business. This is hard when the tools are unavailable to set effective guardrails, however, security teams can employ other approaches such as awareness training, restrictive admin access, or threat modeling to manage risk.
Concluding Thoughts
The growth of low-code/no-code solutions in today’s market is exciting. Security teams have a big opportunity to rally behind the empowerment position by safely supporting these solutions in their environments, potentially leveraging them for their own business processes. Careful thought is needed, though, as to how these solutions get deployed, how they are managed, who is allowed to use them, how data flows through them, and how the permission boundaries evolve because of them. These are all important considerations in the “yes and” conversations that the security community continues to engage in.
Want more cybersecurity insights? Visit the Cybersecurity channel:
