The hole are any third party applications (like who doesn’t have a few in their portal?). I am always encouraging buy versus build, as your business should be putting jam into jars or running a bank, not writing software applications. Particularly ones that face the customer . Face it, most internal apps have grown organically and they are sink holes of development cash. And they have not upgraded their facade technology. At best, they are working through a re-skinned technology layer that you are not even sure who built it.
A customer relayed an interesting scenario that occurred recently that might keep you up at night. They are in the financial business and offer services in a rather full service portal. Part of that portal is a external agent management and fulfilment application that they have contracted to use for years and now offer over their portal. The application vendor was well known, well accepted, and had been a good partner for years.
After a recent compliance audit of the site, they received notification from the auditor that the third party application had an administrator account in it of an employee who had not worked for the company for six years. The account was a “privileged account”, a rather impressive marketing sounding term but means someone is too lazy to secure the OS with separation of duty policies and gives out root or system access to accounts and does not track them closely. The “privileged account” has access to PII information, clients personal data and account information. Someone using that account could log in and download a lot of information the should not be free (apologies to my open source brethren).
Remediation time – no problem. Ask the third party vendor to scan the audit logs and see if anyone has used that account in the last six years. Dust for fingerprints and you are done.
But here is the rub – the third party vendor was not following the clients data center policies on logging and auditing. In order to save storage space, thus money (thus price to the customer), their application was not set to log as much information on use activities as it could. Therefore (wait for it), nobody was sure if someone had used the privileged account for evil.
And in the binary business of security, without a way to prove a breach was not exploited, one must assume it was. Thus, the client was forced to implement a remediation plan for several million customers to the tune of several millions of dollars and some pretty irate customers. A hefty price to pay for a security breach that may have never even occurred.
Needless to say, our customer is implementing a security review of all third party applications in their infrastructure and insuring they are abiding by the security policies of the data center. There is a cost involved, but not as much as the above remediation.
So when you look at your GRC policies, remember to include third party applications and their vendors and insure they are abiding by the same rules as every other application in the house. Add components to your identity framework, such as SSO or federation, that can externally aid in identity forensics. And by all means, insure the policies you place on your internal applications are enforced to the same level with any vendor who supplies an application to your company.
More Here
Courtesy:http://dseanoneill.wordpress.com/
0 comments:
Post a Comment