Data-themed articles, essays, and studies

While Analysts Watched

I once worked on a short contract for a governent agency, involving their personnel data. The work was fairly routine, but there were two complications. First, the only working system was the production system. Second, for security reasons I would not be allowed to actually see the data I was processing. Few are chosen.

It was ironic that I was there to work on a personnel system, as this place engaged in some remarkable HR practices. As a cost-savings measure, most permanent government personnel had been terminated, and then rehired as temps managed by large government contractors. Each temporary employee could be optionally rehired every two years. The net effect was that the original personnel were often retained, but working for lower pay, for significantly lower benefits, and at notably higher personal stress levels. While it’s possible this process actually saved money, if I were asked about the top three topics of discussion in offices and hallways, I would list benefits, sports, and work, in that order. Motivation was definitely lacking. On the other hand, productivity and creativity do not appear on anyone’s ledger – in that battle-of-the-metrics we can likely guess which will win.

When I arrived on site, I met my temp-employee contact – a nice guy. He explained that I could only test on the production system, but would not be allowed to look at any real data for security reasons. He then let me know that the security office – apparently also peopled with temporary employees – did not want to bother giving me a separate login or workspace, as my stay was likely to be short.

We walked to his cubicle – he was a high-ranking temp, so he had a spacious and high-walled cubicle – and showed me his desk. I then sat down in his place, he logged in for me with the necessary administrative rights, and he asked if there was anything else I needed. To which I thought, That’s it? But I didn’t need anything else particularly. Still, I felt obligated to explain my plan, as minimal as it was: I would poke around a bit to find necessary tools, cobble together a development environment and some fake data for testing, perform the necessasry development, look at the production system (but not their data), and then figure out how to make changes in that system without interrupting the work of 40,000 temp and permanent employees. My method, if you could call it that, was approved – I could start whenever I liked.

Let’s review. I am really just a guy who can read

class security_alert {

};

and know what it means, which in this case is you can’t seriously be giving me this access when you have no idea who I am.

I felt obligated to stop and discuss the security implications, but my friend was well aware that this process might be insecure, and explained that to “assure” the security of what we were doing, he was going to watch me program. As in: he would sit next to me and watch what I was typing into the terminal. (If you’ve never done this, either as the watcher or the watched, my recommendation is: don’t. It’s unproductive and disconcerting for the watched, and boring for the watcher.) We then had this exchange:

I asked, “Do you mind if I ask whether you are you familiar with C++?”

“I am not.”

“Or the development environment?”

“I am not.”

“Or the data we’re operating on?”

“Slightly.”

“Would it be fair to say that I could do anything to your system, and watching me would change nothing?”

“It would be fair to say that.”

“It’s OK with me if you don’t watch – it won’t make any difference, and I don’t want to waste your time.”

“I have to watch you. That’s the procedure.”

That’s the procedure, and right or wrong ,that’s what we did for three days. While he was in his cube, I would program, he watched me quite diligently, and we talked – about benefits, sports, family, occasionally work. When he had to leave for a meeting, he would log me out of my administrative access. The first time this happened, I asked if there was something I should do while he was away. He considered for a moment, and told me I could do whatever I liked – have a cup of coffee, or read a book, or talk with others in the office. I did all of those things, learning a good deal about temporary employee compensation along the way. When he returned, he would log me back in and I would continue. While my analyst friend watched.

After a few days of this, I finished my development, and I tested as well as possible without any actual data to examine. What can you do? So, we plugged my little code appliance into the big world and ducked – absolutely the wrong way to go, but our options were limited. There were a few non-critical problems, related to the inevitable fact that real production data rarely matches the assumptions of development requirements and specifications. But we got through it, and my friend’s cube was once again his own.

From a security perspective nothing happened, but that was really just luck. Some elements of security protocol were followed, but in reality these people were largely indifferent to security – I was the only security they had during the days that I was there. I recalled this experience when I read about another possible security breach in the news – this time involving the NSA. For all of our security technology, my impression is that good data security depends first and foremost on motivated people – data security is difficult and unglamorous work. People concerned about pay, benefits, a possible job change, or other distractions can hardly be blamed when data security is not a critical concern. In cases like that, who can be surprised about a security breach, regardless of the data’s importance?