Insider attacks – No one is safe

I have written earlier about insider attacks and the need to protect data and resources from employees and others within an organization just as they would be against external threats. There have been several publicized breaches involving insiders, such as when Verizon employees looked up Obama’s records.

Google has fired an employee in Seattle after it was found that he had accessed Gmail and Google Voice accounts of several children. It is not clear what he did after he got into the accounts, but apparently it was reported by the parents of the children. What is worrying here is that this was not picked up by Google before the issue was reported to it.

In any organization, there have to be some people that have to be entrusted with a higher level of access. This engineer was responsible for checking the health of Google services. But all access by these individuals have to be audited regularly. In this case, it was not regular enough or not thorough enough. According to reports, this was not the first time a Google employee has been dismissed as the result of a privacy breach.

This is not restricted to large companies. Being a PCI QSA, I come across many small companies that have very few employees. In many cases, there is just one person in a role. For instance, there may be only one person developing applications and only that person may be able to read and write code in the entire organization. This situation is in direct conflict with PCI requirements that someone else test the application and do code reviews. And I run into resistance when I mention getting a 3rd party to do it.

Another issue I encounter is that the same people manage the development network as well as the production network. There are specific requirements in the PCI DSS on separation of duties and separation of the development/test and the production environments.

It is important that any role with higher privileges is audited more thoroughly. This does not mean that they are not to be trusted, but if someone was able to steal their credentials, they could cause more damage. Audit trails are very important for tracing what happened with the system. A lot of thought has to go into the roles and privileges at the design stage to ensure that there is sufficient granularity and that the roles are appropriate.