About a year ago, our system had a security audit. We failed in quite a few areas. The client directed us to plug these security holes. One of the weak areas was logging. We write a log file to the local disk on the workstation. It contains sensitive information. And the file itself has no protection.Our boss thought it might be prohibitive to plug these gaps. He thought we might have to go through every place in all our applications where we do logging. Then after analyzing all that code, we could find the places where we log sensitive data. Finally we could change that code. This would take forever since we log stuff all over the place in the code.
There is a simpler way I thought. So I pitched an idea. We could make some modifications to the common routine that write the log information to the disk. We code add a parser at this layer. The parser could scan the text being logged for sensitive information. It could then strip out this information prior to writing to the log file.
This technique has a number of benefits. First of all, this sounds like a fun project. More practically, it cuts down on the time for analysis versus the manual method. We actually don’t need the sensitive information in the logs. We are pretty sure we know most of the patterns where the log information contains sensitive info. It should be a snap to write a parser that strips this information out.
My other idea was to encrypt the file. The security folks would love that. This helps us lock down the logs pretty easily. I envisioned another fun software project where we could invent and implement a new encryption method. However the boss said the security guys would not go for that. Ok. We can take whatever algorithm they recommend, and implement that. Not as fun. But it is still easy to do.
There are many instances where the right outlook on a problem can reel the cost estimates in significantly without increasing risk. Isn’t that why they pay us designers the big bucks? I will let you know as soon as my company starts paying me them
