Deploy Red Team to root out excess privilege — or end up red-faced

Deploy Red Team to root out excess privilege — or end up red-faced

I have been working on fleshing out the duties of an internal Red Team. Many organizations use outside firms to perform periodic attack and penetration tests. Some, like Stratfor, do not — much to their chagrin when they become the target of an attack. While outside pen testing is important, it does not address the bigger problems facing the enterprise today: sophisticated attackers who use escalated privileges to subvert business processes.

The Red Team has a different focus. They look inward. They scan the internal network for holes in the defenses and new vulnerabilities. They engage in attack and penetration exercises to test defenses. They evaluate new IT projects to ensure that authentication, authorization and defenses are included in the initial design all the way through to deployment. While they may not be part of the software assurance process for developing secure applications, those applications would be targets for investigation. Just knowing that the Red Team is out there will keep the software developers on their toes.

By working with each internal program, especially at the early phases of a project, the Red Team can take advantage of their knowledge of business process hacking (BPH) to identify “trust vulnerabilities”. These are the connections within a business process that fail because too much trust is granted to particular users. Some classic examples:

Trusted customers. It is assumed that because there is a contractual relationship with customers: Once they have been granted access to a particular application or service, they will not abuse the relationship. But attackers can and do pose as customers. The data services company Lexis-Nexis had this problem when they launched a monthly access to their comprehensive database of US court documents. Attackers provided a credit card(stolen) to pay the $250 fee and proceeded to run scripts to download as much of that data as they could in a month.

DBAs. Most large projects, including enterprise financial systems, customer relations and manufacturing system rely on back-end databases. Database analysts often have unrestricted access to this key information, often with shared credentials.

Vendors. Also falling under the realm of privileged users, vendor support personal often have access to internal systems that is not tracked.

Third parties. These could be health care providers, supply chain participants, government regulatory agencies, even external auditors. Even if the third parties themselves do not engage in malicious activity, they could succumb to attacks that in turn compromise the enterprise. I had great satisfaction, back when I was at PwC, in writing up a client for having an unsecured network connection to their human resource management provider. The third party was a division of PwC!

Outsourcing providers. In 2008, spyware was discovered throughout the World Bank’s network, including within their treasury operations. The World Bank had outsourced all of their IT operations to the Indian outsourcer Satyam (now defunct). Several Satyam employees were implicated, and Satyam was barred from doing business with the World Bank. In a properly secure environment, of course, there should be no difference between the security controls over direct and contracted employees.

Executives. It is surprising how often executives are granted privileged access. A business process hacker would identify this special privilege and attempt to exploit it.

Only an internal team can gain full knowledge of how your business operates. Sure, a Red Team will make it feel like the Gestapo is watching your every move. But it may be a good thing to keep everyone on their toes.


This post is adapted from the upcoming Cyber Defense: Countering Targeted Attacks (Government Institutes, 2012)