What you need to know about robotic process automation security
Organizations now face a choice of over 45 claimed robotic process automation products — all varying significantly in quality, design and approach. So, picking the right option is critical to achieving long-term success. However, with approximately 30% of all data breaches occurring as a result of vulnerabilities at the application layer, purchasers clearly require greater insight to correctly gauge the security credentials they require from various RPA vendors.
Gaining clarity on RPA security is a major issue; especially as the majority of newer offerings, such as robotic desktop automation (RDA), or desktop robots, don’t offer the same security capabilities as connected-RPA. These RDA tools promise quick wins that may sound compelling, but as organizations attempt to scale these tools to achieve greater business goals, their design limitations become increasingly apparent. For example, organizations get little business benefit if there is an inherent lack of central process design control, security, audit and governance.
Security problems with desktop automation
Unfortunately, the majority of newer RPA-labeled offerings, such as RDA, involve multiple short, record and replay tactical automations for navigating systems on desktops that can create security risks. This is because with desktop recording, a single human user is given autonomy over a part of the technology estate, which introduces a lack of central control. This obscures a robot’s transparency and hides process steps, which when duplicated over time becomes a potential security and compliance threat while limiting scale.
If a software robot and a human share a desktop login, no one knows who’s responsible for the process. This creates a massive security and audit hole and introduces shadow IT into a business, which is potentially very damaging for an organization. Restricting automation to a multi-desktop environment outside of the IT department or any central control means that RDA vendors are effectively sanctioning and using shadow IT as part of their deployment methodology. This is potentially very damaging for an organization as shadow IT, in the context of RDA, means unstructured, undocumented systems that become part of the process flows of a business which are uncontrolled.
For example, say the creator of a desktop automated process leaves the company or an organization changes. This can lead to audit failure due to an unknown fulfilment activity taking place, as well as security holes, such as passwords embedded in these lost processes, fraud and denial of service. If your business allows departments to build these recorded RDA scripts, then over time you not only create a shadow IT nightmare without realizing it, but you also create a massive technical debt that your business will have to resolve.
Why connected-RPA is more secure
Connected-RPA is different as it was designed from the start to carry out tasks securely, in the same way humans do: via an easy-to-control, automated “digital worker.” These digital workers are trusted to operate within the most demanding enterprise environments, as although they are run by business users through a collaborative platform, they still operate within the full governance and security of the IT department.
With connected-RPA, business users train digital workers without coding, so the system infrastructure remains intact. That’s not to say that APIs, web services and other traditional components can’t be used on the platform, but they are gated — controlled and provisioned by technologists for the business to consume, but not change.
For connected-RPA to deliver security, longevity and resilience at scale, automations should be carefully planned, modeled and designed. This means that business users can create automated processes by drawing and designing process flow charts that are intuitive and then used by the digital worker to automate a task. Documentation of a task becomes the actual task — change the documentation and the task is instantly changed.
The process models run by the digital worker are made explicit in the process flow chart for each process automated. The process flow chart is subject to audit and change control, as well as security with dual-key authentication. This approach is highly secure and compliant, as all documentation is securely managed within a connected-RPA platform, and protects the business from rogue employees, rogue robots and rogue shadow IT.
Connected-RPA also enables business users to collaborate by adding their automations into a central pool of capability managed and reused by the whole business. Digital workers’ decisions and actions are centrally captured and audited, too, and so is their training history conducted by humans. Crucially, this gives a comprehensive, cast-iron audit of all activity across the entire connected-RPA platform.
Organizations should also only consider RPA vendors that can demonstrate the highest level of Veracode Verified, a program that validates a company’s secure software development processes. This certification not only demonstrates an RPA vendor’s focus on providing an authentically built, enterprise-grade, secure system, but is also part of the company’s intrinsic product development methodology.
By completing and passing rigorous testing, the Veracode Verified program moves an RPA vendor beyond point-in-time security testing into a mature application security program that enforces secure development practice across the entire software development lifecycle.
Ultimately, RDA tools limit the scale and potential of RPA solely to the confines of the desktop and introduce a variety of risks too. However, connected-RPA provides a platform for collaboration — securely and at scale — where across many large organizations human workers, systems and applications are already creating a powerful, intelligent, safe ecosystem of partners that enable a real digital transformation.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.