We've done a good job of getting security reviews into all phases of our project cycle, including the concept stage. That means we've been able to avoid most last-minute security roadblocks. So, how did this one fall through the cracks?
Maybe because it's a third-party application that's accessed over the Internet via software on end-user systems. People tend to think of that sort of implementation as a hands-off situation. Of course, most people don't think like a security manager.
When I look at what's planned with this implementation, I see data -- in fact, employee payroll information -- being sent to a third party. I see a looming nightmare, since the company that hosts the financial application in question seems to have no understanding of, or ability to provide, encryption.
As soon as I heard about this (secondhand), I asked for a meeting with the project manager. I couldn't believe what I was hearing. Employee names, Social Security numbers and pay amounts were going to be transmitted over the Internet, with no encryption.
I told the project manager that we'd need a minimum of file-level encryption, preferably at the point where the data is created (in this case, in ). And I added that it should not be decrypted until it is used, ideally within the third-party application itself. I'm willing to compromise on exactly where the data is encrypted within our perimeter, but once it gets out to the Internet, it needs to be protected, in an unreadable form.
I wasn't saying anything new. Last year, we forced file encryption on many projects that involved third parties handling our sensitive information. In fact, this same project manager was involved in one of those earlier projects, so he knows all about this. I'm disappointed that so little of my message got through the first time, but at least I don't have to spend a lot of time educating him this time around.
It's too late for this project, though. The contract has already been signed, and the implementation is ready to go live. After I got involved, we had a couple of discussions with the vendor, which seems to have no idea how to use encryption software.
Vendor Woes
The vendor's reps claim that it's processing unencrypted payroll data from other customers. I'd like to think that's a dubious claim, but I know better. In any case, I don't care what other customers are doing; I only care about protecting what's within my realm of responsibility.
So right now, we're struggling with getting the vendor up to speed on how our encryption will interface with its software.
Just to make things more challenging, our end users are expected to export data from PeopleSoft into a file on their desktops and use the third-party software client to import that data directly into the application. Educating our end users, who are not technically inclined, on the use of PGP or something similar will be an uphill climb. But so will getting the vendor to build encryption capability into its service offering.
By the way, after a little digging, I discovered that this vendor doesn't seem to have any large clients, so we get to be the guinea pig. I'm sure that once it establishes encryption capability, its application will be much more marketable. So it's to the vendor's benefit, really. But this would all be much easier if we had had this discussion at an earlier stage, such as during vendor selection.
Well, I guess I picked a career that doesn't have a lot of easy answers. I'm confident we'll get this resolved, but not without delays to the project and another black eye for security, as we reinforce our reputation for slowing things down.
"J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at .
Join in
To join in the discussions about security, go to