Are you Falling for these 12 Common Myths and Misconceptions about RPA Security Myths?
Businesses strive hard to maintain the best security for their systems without having to compromise on business agility. Over the past decade or so, the hype around RPA has continued to grow increasingly louder.
Along with the many known benefits of RPA — there have also been several RPA Myths, Misconceptions being perpetuated which has led to many savvy professionals feeling leery about adopting this innovative technology.
With that being said, we’ve identified 12 of the most common misunderstandings and the real truths behind each of them.
Myth: Bots can be designed, developed, and deployed into the production environment after UAT sign-off without visiting security considerations
Fact: In most RPA CoEs, an ‘Authorization to Operate’ (ATO) is required before bots can be deployed into the production environment. Before that, the process owners or the business Analyst ensures that system access is granted only after proper code review and testing.
Myth: RPA Security is the sole responsibility of IT Security or Cybersecurity department
Fact: RPA security impacts overall security. Different employee roles have the responsibility to ensure RPA security. The Information Systems Security Officer (ISSO) monitors the approvals at all stages of development and deployment of the RPA software. All RPA Artefacts — UAT results, workflow diagrams, configurations details, data models, and recordings should be provided to the ISSO. The ISSO liaises with the Process Owner, Process Analysts, Process developers (including bot orchestrators), and the Privacy office for security and privacy-related assessments. More complex bots may require the services of more than one ISSO who report to the Information Systems Security Manager (ISSM). The ISSM is an approval authority and has the responsibility of reviewing and enforcing business SOPs.
Finally, the ISSO must prepare a new Systems Security Plan (SSP) or update the previous version for any systems that Bots interact with to identify any vulnerabilities and prevent exploits in the interaction. The ISSO is also tasked with the responsibility to define baseline attributes such as expected run time, expected run frequency, file access reads and writes, etc. that describe the expected behavior of the Bot that later can be used for monitoring and subsequently controlling the bot effectively.
Myth: There is no harm in executing bots directly on user workstations
Fact: Business SOPs recommend that the server on which the bot is deployed is segregated from human work and isolated from human interference as much as possible. This ensures event log hygiene, helps perform accurate security traces and safeguards the system from employee-influenced fraud.
It is also practical to monitor is a single server hosting different bots rather than monitoring the bot on a different user workstation. Changes and updates can be easily pushed to the host server, unlike client desktops which run into issues such as employee unavailability, machine availability, and remote work using the public internet. The next best alternative is to use the Virtual Desktop Infrastructure (VDI) environment. But executing bots on user-workstations is clearly not a good practice.
Myth: Bots can be executed on systems that are not updated regularly.
Fact: RPA automation must be developed using approved software. A list of all technologies, applications, packages, integrations, and APIs approved and deployed for RPA should be maintained and periodically reviewed for updates. Organizations should encourage CERT secure coding practices and undertake a comprehensive product vulnerability analysis using industry best-practice security methodologies.
Myth: User Credentials can be used in a Bot-Executed Process as it is secure enough
Fact: System access and authentication requests for bots should be approved in a similar way as approved for human users. An ‘Active Directory’ account for the bot must be created. ‘Active Directory helps to manage and control Bot access in accordance with the organization’s security policy.
RPA Bots use credentials (basic authentication username and password) stored in a Password Vault or a Credential Manager like CyberArc Credential Manager uses a password vault, for secure storage of usernames and passwords.
Single Sign-on (SSO) capabilities mapped to the Robot user AD account can also be enabled wherever necessary. Credentials stores in the credential manager should be available to processes executed by the current Robot AD user and should not be shared with other Windows users or any other OS users. Also, RPA tools provide the ‘Secure String’ datatype to process sensitive data which can be used to save passwords other than System user passwords.
Myth: Log management is old school and expensive effort-wise
Fact: It is recommended that there should be logging of Bot Activities and Orchestrator events. There must be periodic log reviews. Audit and monitoring capability need to be enhanced to identify abnormal spikes in activity, unauthorized access of specific systems, and misuse of privileged accounts.
Myth: There is no need to revisit the security review for bot change control
Fact: The Bot must be put through the full Bot Development Lifecycle if any new changes are to be incorporated with the relevant procedures and approvals. The newly submitted package should specify all the changes made to the Bot for a faster review by the ISSO and ISSM. Any new interfaces, connections, or access to new applications should be reviewed. Whether encryption is done using recognized standards should also be checked. Bots should also successfully pass through the annual Bot review to continue being operable.
Myth: RPA security is distinct from cybersecurity and there need not be any compulsion to comply with cybersecurity policies and control
Fact: RPA and Cybersecurity are both concerned with the overall security of an organization. RPA developers must make use of secure webhooks, APIs, secure transmission protocols, and security certificates. Software or physical token and encryption can enhance RPA Security. RPA can check for broken links, maintain password hygiene, and validate API endpoints. Security certificates like SSL and TLS can be implemented for runtime resources requiring HTTP and TCP communication protocols used in an RPA created web session. Most organizations expect RPA CoE to meet cybersecurity standards and policies.
Myth: My system is unlikely to be compromised as the data isn’t worth much
Fact: Nothing comes cheap and even a simple list of names and addresses may be of more worth than you would imagine. Going lax on the security of a system creates a gateway for attackers to intrude into the organization’s network, exploit a wider set of vulnerabilities, and steal data easily. It should be ensured that the system is compliant with all required security policies regardless of how much one thinks the values of the data of that System’s processes might be.
Myth: Bot -traffic is bad. If your site or service uses bots, it will get blocked by anti-malware and anti-bot agents
Fact: Yes, it’s true that there are bots that probe for vulnerabilities steal information, or corrupt information systems.
However, not all bot traffic is considered bad. Informed users recognize that bots such as Shopping bots and Chatbots can help businesses and consumers alike. Anti-malware software creators have an elaborate process to identify bad bots from good ones and update their definitions accordingly. And if you get blocked doing honest business, you can report to the software company.
They‘ll respond either by unblocking the bot or inform you regarding the vulnerabilities in continuing the use of the bot. However, regaining customer confidence is what matters. Customers tend to go with the notion that Bots are malicious intelligent, capable of becoming more malicious and compromise device security, system security, and network security. They believe processes run by Bots are inherently insecure leading to identity threats and fraud. It takes a bit of educating to alleviate these misplaced fears.
Myth: Access, Authentication, login is important. Logoff and Killing open applications are not
Fact: Not logging off applications and stray instances of applications’ processes can result in serious security breaches. The risk ranges from stealing data, loss of data, manipulating account and profile information, changing configuration settings, changing passwords to make resources inaccessible, and so on. A simple ‘Log Off’ and ‘Kill Application’ activity can save a great deal of trouble and embarrassment.
Myth: Business is not liable for bot failure or bot security breach
Fact: This is a widely debated issue s to how much a company is liable for a bot mal-performance. Most Companies making use of bot put out an explicit agreement on Bot Use, liability, and limitations on liability. Bot providers get into SLA contracts which explicitly mention the permissible downtime and liability for business losses.
Be sure to know, this isn’t the end-all of RPA Security myths. RPA is as risky or even less so when compared to other technologies in the IT landscape. Unlike other automation technologies, with RPA it is easy to maintain data-hygiene associated with front-end user-based access to information. Eventually, RPA security depends on the knowledge, the implementation effort, and due diligence in-line with the IT Security SOPs.
Shake off these RPA Security Myths. Realize the Reality of RPA and just how beneficial it can be for your organization with us!
