As Robotic Process Automation activities expand within businesses, not all bot developers are well versed in best practices for developing secure and auditable bots. While enabling federated development to many business groups within the organization has its benefits – namely increased productivity and speed of execution for redundant processes – it can come at the potential risk for data loss and an overall decrease in the confidentiality of business data. Many businesses attempt to overcome these challenges through the use of a Center of Excellence (CoE) that reviews bots and may run code scanning analyzers in an attempt to increase adherence to corporate and IT standards. This helps to minimize the risk. However, more can and should be done in the design of a bot to help ensure businesses can continue to receive the value from RPA while mitigating as many risks as possible. The following are some additional guidelines that can be followed to mitigate risks:
Don’t use external files for Personal Identifying Information (PII) data
A common approach used by many bot developers is to put the complex logic of data modeling, communications, and computation into external files, such as spreadsheets. These files are then stored on shared storage services, such as Google Drive, Dropbox, or SharePoint, and emailed to others in the organization. RPA is often used to extract data from other sources, such as human resources and customer service systems, and plug it into these documents. This approach can lead to a loss of privacy and confidentiality. An alternate approach is to operate on a need-to-know basis and let RPA manage the creation and distribution of this information based on common data protection factors. Allow the PII data to remain within the systems of record and facilitate access back to these sources in the created documents, which would require the individual accessing this information to have appropriate credentials.
Leverage centralized logging
Work with IT to set up centralized logging services. Many bots run locally and leave critical information on the machine on which the bots were run. In the cases of non-persistent virtual devices, this data will be destroyed upon exiting the virtual session. In other cases, confidential information could be left lingering around on the machine. By using centralized logging only those with appropriate credentials will have access to the logs generated by the bot limiting the possibility for loss of confidential data. Make sure that bot developers use the centralized logging Task or Command Package to capture any log-based data that will be created by the bot. Additionally, be sure that the data being logged doesn’t contain any of the PII data we just discussed in the previous point. This includes both logging/audit data as well as any screenshots which may be captured as a part of your error handling. It is important to be aware of what may be on the screen at the time that a screenshot is recorded.
Utilize the credential vault
Don’t store credentials or PII information in the bot or in a configuration file in the control room. Instead, use the credential vault and leverage those credential vault values within the bot. This will have the additional positive impact of limiting failures at runtime when credentials change as they will only need to be changed in one place (the credential vault). This also helps to reduce the likelihood that a bad actor may obtain that data and use it for nefarious purposes should someone have unintended access to your control room. For additional information on the credential vault, check out the Automation Anywhere documentation portal.
Consider immutable storage
If bots are dealing with data that might impact activities such as SOX compliance or financial auditing, blockchain-based hyperledgers are a great way to capture key auditable data in a source that is considered immutable, that is it cannot be changed. There are multiple ways to incorporate hyperledger technologies into Automation 360 bots to store data such as the date and time of bot execution, which systems were touched, and markers that denote data was read or written.
Use Try/Catch/Finally blocks
When bots fail without completing their tasks, they can sometimes lead to corrupted data or data left around in temporary directories that would have been otherwise cleaned up at the end of the bot. When you use Try/Catch/Finally blocks and the bot fails, the bot will execute the logic in the Catch block only when an error occurs. This is a great opportunity to log some details about the specifics around where the error occurred within the bot, what data the bot may have been working with, and possibly capture a screenshot of the machine’s state for future debugging (again, use your best judgment here to be sure that you aren’t possibly capturing PII data which could be on screen). A Finally block should also be implemented to delete things like temporary files that may have been used during bot processing and to ensure that all applications/windows which may have been opened, are appropriately closed. The code in a Finally block executes regardless of the bot succeeding for failing – so code for things like cleaning up temporary files would only need to be written once instead of in multiple places within the bot. For more details on the Error Handler Package, check the Automation Anywhere documentation portal Bonus Pro-Tip - Beyond just adding some commands to close windows by titles – you should consider using if statements to be sure such windows exist first – this can help prevent a fatal failure from occurring within your Finally block.
Validate data
Checking to see that data is valid is an important aspect of information security. Entering poorly-formed data into a system can result in corrupted records, downstream processing failures, and potential security breaches. The Table Analytics package that is available in the Bot Store provides the means to help users validate data prior to its use. Validation is simpler to use than IF actions because they have very narrowly-defined purposes. For example, the Number Validator helps to perform various types of checks against numbers, such as checking if they’re positive or negative, if they fit within a range, or if they have equality with another piece of data. If these conditions are not met, they will throw an exception, which should be caught with a Try/Catch block. Performing validation can limit your bot failing from attempting to update a system with invalid data and having to develop additional error checking for these conditions. Additionally, consider what other actions your bot could take to help validate data wherever the bot exists within a greater business process – which could mean doing customer ID validations against a system of record, validating addresses match across multiple systems, or ensuring transactional data is within a certain normal range. All of these checks can help to ensure that fraudulent transactions are not taking place and that bad data is not being propagated out to additional downstream applications.
Conclusion
Bots (Digital Workers) are rapidly becoming an important component of the corporate landscape. In response to this, it’s important to follow some basic guidelines to ensure that confidentiality and privacy are maintained; especially in light of the fact that many of these tasks are touching critical corporate data, such as finance and human resources use cases. If you would like additional information or would like to talk with someone regarding how to develop your Automation 360 bots to better support privacy and confidentiality, please reach out via our A-People network or talk to your customer support manager. Go build safer, more secure bots…and go be great!