Returning from the 2015 North American Shared Services & Outsourcing Week Conference, I felt Robotic Process Automation (RPA) had the potential to be a transformative technology. What I was not sure about was how to get it deployed on our federal network.

As I explained in my last column, “RPA deployment is no different than driving from Mile Marker 1 in sunny Key West, Florida to chilly Fort Kent, Maine on US Route 1. The path is the same for everyone. The car and driver duo make the experience different.”

That said, we all want a safe and secure trip. At the NASA Shared Services Center (NSSC), we were the first car and there was no AAA trip mapping service to reference. When we successfully deployed the first RPA agent in the federal government, we learned a lot. This month, I want to focus on security challenges. While each agency has different processes and procedures for onboarding new technology, the same basic rules apply. Everyone will find the same or similar challenges along their security journey.

My first big RPA question was: How am I going to get the Chief Information Security Officer (CISO) to allow RPA on the network? While I had heard diverse views on CIO and CISO involvement from private sector RPA implementers, with the Federal Information Technology Acquisition Reform Act (FITARA) placing IT squarely on the CIO – and by extension the CISO – I could not afford to think about how to avoid either of them.

"How am I going to get the Chief Information Security Officer (CISO) to allow RPA on the network?"

Bot security needs to be applied holistically throughout your bot’s lifecycle (mind you, in a future article, I will suggest where the CIO’s responsibility ends and your process owners’ begins). Your CISO is your de facto state police on your RPA travels. Your relationship with the CISO needs to be positive and collaborative. An RPA deployment can come to an abrupt halt without this relationship.

Your CISO is your de facto state police on your RPA travels

We were lucky at the NSSC as our CISO looked at bots for the value they brought to the mission. She was willing to keep an open mind and help find solutions to RPA challenges. Her team conducted their normal NIST 800-rev 4 control reviews. Knowing we intended to be the first government agency with a bot, she required a 3rd party penetration team assessment. (Passed it!) She granted temporary waivers through the same waiver process used for all other software, while leading discussions with other Agency IT Security professionals to encourage a cooperative atmosphere. We even had imaginative discussions on how she could use a Security bot to monitor other bots during deployment, or how her bot might be used to provide PIN numbers if we were able to simulate the PIV/CAC two-factor authentication requirements of Homeland Security Presidential Directive 12 (HSPD-12).

Her most creative idea was a CISO bot that would generate and change the passwords for the other bots if two-factor authentication were not overcome. Yes, a strong RPA program starts with strong relationships: build them.

"We had imaginative discussions on how to use a Security bot to monitor other bots during deployment, or how a bot might be used to provide PIN numbers if we were able to simulate the PIV/CAC two-factor authentication requirements of Homeland Security Presidential Directive 12 (HSPD-12)."

Staying on the theme of people, there are three challenges to consider when you start your market research.

We elected to look at RPA by inviting seven or eight vendors whom we had met at that summer’s Shared Services & Outsourcing Network’s Robotic Process Automation Conference in Chicago. Few, if any, RPA products are developed in the United States, which create some potholes for you. Before you start a dialog, you will need to determine if vendors are U.S. citizens or authorized to work in the U.S. While at a conference you are not expected to pre-clear anyone before you discuss RPA. However, you should use good OPSEC with respect to the details of the processes you share.

My biggest lesson was that regardless of whether your invite is for a face-to-face or conference call, you have to pre-clear all participants. I learned this requirement the hard way. A member of the vendor team flew in to introduce their product and was denied facility access because I had not gotten him pre-cleared. An embarrassing lesson. Take the time to check.

A strong RPA program starts with strong relationships: build them

Additionally, the companies themselves have to be incorporated in the U.S. When we started researching vendors in late 2015, not many were incorporated here. That is rapidly changing. Like with any software you have installed on your network, either at the Agency or local CIO site, someone checks the vendor’s supply chain. While many RPA vendors are being judged as fit for federal networks, many have supply chains that are still hosted outside the U.S. Get the supply chain review done early!

In addition to vendor incorporation and supply chain review, you need to consider vendor software support. If you have a problem with the software, you are going to need to call for support. If you are using a systems integrator this issue resolves itself well; but if you are going to sustain your RPA program with your organic staff, you must consider who answers the phone, who helps you, and what you can provide as “break-fix” data when you issue your RFQ (Request for Quote). If you have not put language in the RFQ to account for foreign national call agents and engineers, you may get detoured during your Proof of Concept, your Pilot, when asking your IT review board for an ATO/CON, or after you go live.

These checks (incorporation, supply chain, and vendor support) are not new. They have been requirements for years. The integrity of the federal government’s networks require this rigor. It’s a challenge for RPA vendors only because this software is primarily coming to the U.S. shores from abroad. Including language in your RFQ and addressing what might seem like administrative issues ensures that the federal bots on federal networked severs will protect your mission critical data via strong contractual language.

In January’s column, George Washington was the bot persona we developed to best integrate RPA digital labor into our workflow. This month’s title mentions Martha Washington. Martha is any person (military, government or contractor) using a computer on your network. At NSSC, as vendors came onsite to demonstrate, a very astute contractor working with me said we need to name the bot. I have hence heard argument for and against, but honestly, when we started treating the bot as George Washington and asked how he would operate on the network, we began to realize the answer was simple: What would we do for Martha? Both needed a desktop environment with 256k encryption for data at rest, and a VPN to ensure trust between the desktop and the systems accessed during the workflow. Since, both would be audited by security and internal controls, they needed to present themselves as the same entity in the active directory sharing an email address and a unique identifier number. We knew we did not want to create anything new for the bots. By creating a persona for “George” we could access our exiting Access Control List (ACLs) controls database and approve access just as we would for any person involved in the workflow.

"By creating a persona for “George” we could access our exiting Access Control List (ACLs) controls database and approve access just as we would for any person involved in the workflow."

We even knew, with our pilots initially on desktops, ITSEC required the screen to lock every 15 minutes and the password policies had to be followed with respect to complexity as well as be changed every 90 days. We started to see George as any other teleworking employee in Nebraska. George would execute the workflow just as Martha did, and we already had procedures for approving, auditing and managing Martha. Why create new manual processes for automated employees? When either needed access to a shared drive or an application, we utilized our proven access management system, which meant we already had processes and monitoring procedures in place to evaluate the situation. Digital labor cannot evaluate your control processes and find ways to avoid or sabotage them, but your human workers can. If the processes you have today provide a level of confidence for your staff, adding bots to these processes increases your ability to review and access bots as a part of your normal battle rhythm.

There is one last excursion on the RPA security journey for you to consider. You need to discuss with your Systems Integrator or take the time to really learn how you are going to get an ATO (Approval to Operate), CON (Certificate of Networthiness) or whatever approval your agency requires to get new software on the network.

Start asking how and what artifacts the CIO needs while formulating your Proof of Concept plan and getting project approval. Again, the CISO relationship is key and you really should start the conversation with the CISO, not just bring them in later.

The question you are going to need to answer is simple: Is RPA a system or a tool?

We landed on it as a tool, but I have heard much debate saying it is a system. Either way, you are going to inherit security controls and be in a security plan. George Washington did not create anything new. He was being hired to integrate into the shared services workflow, and nothing more. He used only existing databases, shared files, and team email accounts; had segregation of duties imposed on him; and was granted application credentials just as Martha was when she joined the team. Since nothing new was created, we suggested it was not a standalone system. If nothing new is created when the bot begins to mimic the keystrokes and mouse of your current staff, then does it need its own security plan? Or is it incorporated into an existing one?

Have this discussion early and seek experience from your Systems Integrator. Until you get your digital labor onboarded, you are going to have a solution to a problem that is stalled in traffic. Seek temporary approvals, approvals in certain domains, or just one or two pilots.

"Since nothing new was created, we suggested it was not a standalone system."

It is natural for those that are not familiar with RPA to worry it will go all “Terminator” on their networks. Your RPA project can be agile and proven only if you plan early and seek approval as soon as possible for the software to be on the network.

RPA vendors had not begun seeking Federal Risk and Authorization Management Program (FedRAMP) designation when we started our journey; they are now. The challenge of supply chain is being addressed by vendors wanting to participate in the federal sector. More and more agencies are looking at the promises of RPA, and in time, we will see RPA as commonplace in supporting artificial intelligence and chat bots.

When George Washington planned his journey across the Delaware in 1776, OPSEC was critical to his deployment and success. Your RPA project will start, go to deployment, and be sustained only by partnering with your CIO and CISO now, and by building on the fundamental tenants of strong OPSEC.

Until next month, make your days great.

Main takeaways
• Your first RPA hurdle requires partnering with the CIO and CISO
• Vendor interactions are easy once you have checked their credentials
• Your bot needs a persona so you can best decide how it operates
• Plan to get an ATO/CON or plan to wait to move bots to production