Securing my LCNC – Where to Start?

When working with security teams and application security analysts, the new world of low-code/no-code development presents new questions that invariably begin with ‘where do we start?’ With so many new applications, automations, and more that are introduced to the corporate environment, it can seem like an endless pit of concerns about data flows, user permissions and potential security risks introducing my organization that need to be analyzed and brought under management. The primary problem we see is that traditional application security tools are not designed to keep up with low-code/no-code development, which, as the name suggests, minimizes the amount of code that is written to create these applications, and also completely does away with the software development lifecycle as we know it.

Based on our experiences of working with many of the world’s largest and most complex organizations, we have compiled the three main pillars of what organizations need to account for and enact when it comes to securing and governing low-code/no-code development.

Pillar #1: Visibility

One of the oldest security adages is that we cannot secure what we do not know exists. This is of particular note within low-code development, because of the volume and speed at which applications, automations, and other resources are being built. In order to fully understand the total inventory of resources that are being built, we suggest starting by determining how many resources (i.e. applications, automations) have been created across all the low-code/no-code platforms. 

One layer deeper is to understand these resources’ relationships with other corporate resources and data and their business criticality. By determining what type of endpoints are connected to those applications and automations, if they interact with sensitive data, perform critical functions (i.e. vendor payment, processing transactions, etc.), or with SQL servers, Sharepoint sites or more, security teams can start to prioritize where to start.

These types of questions are important to understand the business criticality of those resources which will help us later on when prioritizing the risk we will find. 

Another important item when it comes to visibility is determining the business users that are leveraging low-code/no-code platforms to build these resources. It is important to differentiate between professional developers and citizen developers and create profiles for the top builders within the organization. When evaluating professional vs. citizen developers, the primary and fundamental difference is the technical knowledge and training that professional developers have, that citizen developers often lack. Professional developers are innately aware of the security risks that application development can expose the organization to, whereas citizen developers can be users from finance and sales departments which have no knowledge about app-security and what to avoid in order to not expose the organization to security risk. While both user groups leverage low-code platforms to build useful business applications, citizen developers are less likely to be trained to think about the different  stages of the software development lifecycle. 

Understanding who the developers are will help us later on when wanting to communicate with them to educate on how to fix the issues that are found in resources across the different platforms.

Pillar #2: Risk Assessment

Once inventory has been established, security teams will want to double down on what the specific security risks are within low-code/no-code development, and which of those risks expose the organization to the most potentially severe security breaches and compliance failures.  Here, we will provide three common examples that stem from low-code/no-code development.  All of these components can be of high severity, particularly when they are identified within resources that are flagged as being business critical. 

• Sensitive data exposure. The power of low-code/no-code development is that anyone can create applications and automations. It also means that resources can easily be built that connect to corporate resources (i.e. databases, end points, other apps) which contain sensitive information and data. Whether that be  financial information like bank account numbers or credit cards, to personal health information (PHI), customer data, or other personally identifiable information (PII). When approaching security for low-code/no-code development, security teams must be sure that any created resources that interact with sensitive data will not expose the organization to any data leakage, or data exfiltration to the automation run logs. This is particularly critical when evaluating which low-code/no-code resources are exposed to other users or to outside of the corporate network.
• Hard coded secrets. When developing applications and automations that are connected to third-party end-points, builders need to provide credentials or login information in order to connect. Most low-code platforms will not advise builders to use other connections or services to securely store credentials, and will simply prompt users to add their username and password, which then gets embedded into an application or automation, and be a sitting duck for attackers and lateral movement. The best practice can take place in multiple forms, including using personal tokens to run API calls or opening a ticket in ServiceNow or zendesk with a username/password combination. There are best practices when it comes to storing your secrets/passwords securely in low-code platforms and it is important that both professional and citizen developers will be aware of these practices, and for the security team to enforce it. 
• External access. Enterprises usually rely on a diverse workforce with many different types of vendors and external users that require access to corporate resources. Sometimes, we will need to allow those external users access to applications or automations that were created using low-code platforms. While this is crucial for innovation, security teams need to be very careful when allowing external users to access and create low-code resources. Particularly because they have a higher likelihood for importing/exporting data from external email addresses, the data that each application aggregates needs to be separated and insulated from exfiltration. It is very common for data leakage to occur, with a common use case being syncing calendars or sending important information outside of the network. A common example to illustrate this would have a user connecting between their corporate account and their personal account and creating a flow to copy any incoming emails to their personal account, or create a new invite in their personal calendar whenever they have a new invite coming to their corporate account. As explained before – those resources can contain business information about the organization which need to be carefully revised if allowed to be shared or not. 

By continuously assessing the risk of each resource that is created, security teams can start to prioritize where they should start and be sure that they are maximizing output and effort.

Pillar #3: Governance

After visibility has been established, and each resource is evaluated for risk, comes the crucial step of ongoing governance. Due to the speed of low-code/no-code development, security and risk teams need to stay vigilant against emerging threats, and the best way to do that is by being proactive and prescriptive, rather than reactive. When approaching governance, security teams should approach this from two perspectives, first through dealing with existing risk, and second from risk that is yet to be introduced. 

For the first approach, we want to make sure we have processes in place to notify the people building apps and automations about the security risks they created, as well as guidance on how to fix them and who to reach out to for any questions (remember that the maker can be someone from the finance team who will need assistance when it comes to security issues and how to mitigate them). This is helpful to build awareness for business users so that they are provided the training needed to create useful and secure resources. An even better practice would be for security teams to also perform automatic remediation for risky resources like stopping the automation, masking hard-coded secrets, or deleting external connections. These types of automated remediation steps can be the difference between stopping attackers in their tracks and a nasty breach and is a critical step to get to in the overall security posture of low-code/no-code development. 

When approaching risks that are yet to be introduced to the organization, security teams will want to make sure that they have guardrails in place to prevent risks from accumulating in the first place. This means to be involved as part of the security development life cycle and have running tests to make sure that new applications or automations that are being developed will not expose any vulnerabilities and will be aligned with the organization’s security policies. 

In Conclusion

Focusing on the 3 pillars of visibility, risk assessment, and governance will help any application security team or low-code administrators begin their journey of improving the organization’s overall security posture, meet compliance, and empowering professional and citizen developers to securely build the resources they need to be their most productive selves. 

If you’d like to learn more about implementing a foundational approach to securing and governing low-code development, please get in touch with us!