Managing low-code/no-code security risks

Continuous threat exposure management (CTEM) – a concept introduced by Gartner – monitors cybersecurity threats continuously rather than intermittently. This five-stage framework (scoping, discovery, prioritization, validation, and mobilization) allows organizations to constantly assess and manage their security posture, reduce exposure to threats, and integrate risk management into a continuous assessment and action loop.

A prime candidate for inclusion under the CTEM umbrella is software created in low-code/ no-code (LCNC) and robotic process automation (RPA) environments.

With easy-to-use interfaces aided by generative AI, LCNC development platforms have expanded attack surfaces in most organizations, often beyond the visibility of security staff. That’s because they allow any employee – i.e., “citizen developer” – to create and deploy apps or RPAs for automating business processes such as data integration, form automation, custom reporting, and more.

This “shadow engineering” has been embraced by management— 64% of CIOs say they have or will deploy LCNC technology within two years—but it complicates cyber risk management by allowing code to slip into the network unchecked, including potentially dangerous software vulnerabilities.

Bringing LCNC apps and RPAs under the purview of CTEM helps organizations pinpoint vulnerabilities and exposures, correlate them to potential attack vectors and exploits, prioritize based on business impact and assets’ criticality, and validate remediation efforts.

Here’s how to align the five-stage CTEM approach to LCNCs and RPAs:

Scoping

Begin by assessing which LCNC and RPA assets should be managed by CTEM based on their business criticality. Scoping may include choosing groups of users, connections, connectors, apps, flows, and automations. These could be sliced by business context, business unit, platform environment, or geography.

Discovery

In this stage, the goal is to catalog and discover visible and hidden assets, vulnerabilities, and misconfigurations. Lack of visibility into LCNC applications and automation can make it challenging to map LCNC activities and maintain an up-to-date inventory of all assets associated with these platforms.

Threats, risks, or any security issues should be continuously scanned and engaged with all stakeholders with as many details as possible to support the next stages of the model. The discovery of issues may require applying a policy engine based on rules or AI logic, fed by application security research and knowledge.

Prioritization

Handling security exposures requires assessing urgency, severity, available controls, risk appetite, and the organization’s overall risk level. Predefined base security scores are insufficient; prioritization in LCNC should combine traditional risk-based scores with platform-specific and organization-specific inputs.

Using an established scoring method like CVSS as a starting point is recommended. Still, scores should also be influenced by accessibility, whether apps are enabled or disabled, and the deployment environment (e.g., production vs. development). Prioritization is crucial in LCNC due to the large scale of threats and issues detected, numerous assets, and app creators’ relatively limited security expertise.

Validation

The validation step aims to achieve three critical objectives. First, confirming whether attackers can exploit known vulnerabilities. Second, the worst-case impact of defenses failing should be assessed. Third, processes must be ensured to respond to any security issues.

While validation practices for LCNC applications generally mirror those of traditional application security – such as penetration testing, red team exercises, and simulations – they introduce specific challenges that demand tailored validation techniques. These include considering visual development interfaces, rapid deployment cycles, and the reliance on pre-built components.

Mobilization

Involving business users and citizen developers is crucial in LCNC. Security teams alone can’t handle the numerous issues due to their unfamiliarity with LCNC platforms and specific permission models requiring owner involvement. Mobilization can be manual or automated, but it must provide clear context, including threat explanations and remediation steps.

Adopting CTEM for LCNC security

To integrate LCNC and RPA security within CTEM, consider the following best practices:

Integrate with existing workflows: Ensure LCNC and RPA security is incorporated into CTEM remediation and incident response workflows, specifically focusing on identifying vulnerabilities, automating threat detection, and ensuring continuous monitoring of human and machine interactions.

Enhance visibility: Implement monitoring tools that provide visibility into LCNC and RPA deployments, ensuring they are supervised.

Prioritize high-risk assets: Identify and prioritize the most critical vulnerabilities in LCNC and RPA environments by focusing on areas with the highest potential impact on the business and target remediation efforts on these high-risk areas first.

Continuously adapt: Use each CTEM cycle to generate new insights, refine LCNC and RPA security measures, and adapt to new threats and vulnerabilities as they arise.

Collaborate across teams: Foster a culture of collaboration between security, IT, and business teams. Ensure that all stakeholders are aware of the CTEM process and understand their roles in maintaining security for LCNC and RPA assets.

With LCNC app development is an emerging discipline, it’s important to remember that CTEM is a continuous process. By focusing on these best practices, CISOs can effectively manage the security risks introduced by LCNC apps and RPAs under a CTEM program that provides an integrated approach to cybersecurity.

from Help Net Security https://ift.tt/Rb3PAug

Related Items