Not long ago, I ran across an email on a cryptography mailing list that made reference to the Rivest-Shamir-Adleman encryption algorithm. This reminded me of an experience I had at a former place of employment, where the the term “RSA” came up in reference to improving the security policy for employee access to computing resources.
I was the network administrator and IT resource manager for the company; I won’t mention which company, of course. The Vice President called me in for a meeting, along with the head of the software development department, to discuss future security technology implementation. About twenty minutes into the discussion, the conversation had moved into discussion of securing mobile resources — a lot of the developers had high-end ThinkPads running one of two Linux distributions as their primary workstations. The VP turned to me and said “What do you think of RSA?”
There wasn’t a lot of context for this question, so I was (understandably, I think) caught slightly off-guard and a little confused. I responded with an implied question of my own: “That depends on what you want to use it for.”
This time, it was his turn to blink at me with a look of confusion. Naturally, the software guy leaned back in his chair and waited to see whether we’d ever reach a point of mutual understanding, since he knew even less about what was going on than I did.
I did my best to lay out the basics of what I knew about RSA encryption for him in terms a layman could understand. I thought it was odd that a nontechnical manager — user of one of about eight or ten MS Windows machines on the whole company network, if that gives you an idea — would want information about the uses and strengths of an encryption algorithm, but he asked, so I tried to answer. He chipped in with some attempts to help redirect the focus of the discussion to what he wanted, such as “. . . but what about using RSA for secure access on the laptops?” Of course, I thought that’s what I had already been talking about, but apparently not in a way that was helpful to him.
It was several minutes of talking past each other before it finally dawned on me that the Vice President wasn’t asking me what I thought of the Rivest-Shamir-Adleman encryption algorithm. Actually, it dawned on the software guy, who was sitting outside the discussion watching what was going on, and he asked the VP a quiet, seemingly innocuous question that cleared up the confusion for me in an instant.
“Do you mean RSA Security, the company?”
I could have smacked myself in the forehead with the palm of one hand, but figured that would only annoy the VP. Instead, I said “Oh, RSA Security! I thought you were asking about the RSA encryption algorithm.”
At that point, I got to explain the difference between an encryption algorithm and an encryption product. All this time, the VP was asking about RSA Security’s line of SecurID hardware tokens (for one-time password, multifactor authentication) that he had seen in a magazine advertisement. This seemed like a much more likely question for a nontechnical manager to ask than the similarly named RSA encryption algorithm, after which the company had been named.
I told him I would have to do some research on the products to really give a reasonable judgment of their suitability for our purposes. This research, I informed him, would have to include talking to the people that would be using them (since willingness to properly employ security measures is an important part of evaluating whether to deploy them) and determining whether they were compatible with the system configurations we used.
The moral of the story is that, as technically oriented IT professionals — especially subject matter experts such as security professionals — we must ensure we are aware of the potential for misunderstanding between us and the nontechnical people with whom we work. Misunderstandings can lead to wasted time talking past one another at best, and to unmitigated disaster at worst. Managers and technologists, in many ways, live in different worlds. It takes extra care to ensure we’re speaking the same language when discussing technical matters.
Disclaimer: The above quotes are paraphrased from memory. I do not claim that they are one hundred percent accurate recollections of the discussion.