"They didn't know what their sensitive information assets were, and who had access to them, and they didn't have adequate security controls in place," Taneja said. "Unfortunately for TJX, I suspect they are going to become the poster child for poor data security."
How do you secure data?
You must know where it is. It doesn't help to lock the front door if the back door is open.
"Knowing where the data is" is not easy. Databases with no data dictionaries, flat files with no schema documentation - if this describes your IT organization, then you do not know where your data is. Tribal knowlege does not count, at an enterprise scale. "Go ask Bob" does not work, when Bob gets a job with your competition.
So you need a metadata repository, and an understanding of your logical to physical mappings. You can't secure "Customer" data unless you understand that column CSTR_8XY_R7T_N in table GST_N_DT_TB in database GDB0234 actually contains their Social Security Number. (Yes those are made up names, representative of all too much I've seen.)
If you know where your data is, you still need to consider who and what has access to it. In general, any server can expose that data to any other server, whether it is a flat file or a database. So dependency mapping tools can help, but only partly. You need to define what other servers *should* have access to the data on GDB0234, in order for the dependency discovery tools to tell you there might be unauthorized access. This is a job for your enterprise CMDB.
If individuals have access, either directly or via applications, this has to be managed. Their managers need to be queried periodically to re-confirm that access. Obviously, people who leave need to have their access revoked. This seems basic, but in too many companies, it is only done for the major enterprise directory account held by the departing employee - if credentials are managed at the application level, these may not be purged. This is like only taking back the employee's keys to the front door, while letting them keep the keys to the storeroom.
Finally, you need to manage drift on your servers. Has someone installed a backdoor that shouldn't be there? This requires a defined release and provisioning process, preferably with automated tooling, supporting the detection of unauthorized changes. How do you distinguish "unauthorized" changes from "authorized"? No automatic solutions here; you have to have a strong Change Management process with teeth. Detected changes need to be reconciled to the approval process, and there are no silver bullets. Long term, you go completely "fly by wire" and route *all* server changes through the provisioning tool. Much easier said than done at this time. What servers would be a priority for this level of control? Those containing customer sensitive data - back to the first point above.
Although the vendors still haven't gotten to this point, I continue to advocate my original thesis, that metadata management and configuration management need to converge to solve these sorts of problems.
-Charlie
