The role of consultants

The team I support deals in matters of regulatory and security compliance. We have specific competencies in privilege management and auditing of privileged users. It's an honor to be the trusted advisors to Fortune 500 and Global 1000 companies.

None of these topics are new. We've had external market regulations and security policies for years, and organizations have had varying measures of success in keeping up to date with their internal and external compliance needs. We've had security software in this space, too. While Centrify's software is certainly disruptive, we wouldn't be the market leader if there wasn't a market to begin with. We've had security consultants and bad actors, too.

Last year I met a nice system administrator from a Federal agency. She told me that when she joined her part of the organization they had ninety Active Directory domain administrators. She had a background in computer security, and she had to politely point out to her supervisor that it was absurd to have administrative assistants and external contractors with the highest level of privileges in Windows. This isn't an isolated story about the Federal government, either; I visited a manufacturing facility last year where the developers had root in production. They struggled organizationally with trying to reduce people's permissions, because they'd never done that before, and it was uncomfortable, having to tell people they had a normal user account. This is particularly difficult news for software developers.

What I've seen over the years is that successful organizations understand and commit to cultural change and process change as the main part of the project. The software's easy - an operator tells the machine what to do. Actually determining who should be able to do what, and who can approve that - that's harder, and someone has to give it some thought. The hardest part is actually committing to that change, specifically deciding that employees should have the permissions to do their jobs effectively, but no further, because that carries with it the perceived risk of failure. That the database operator can't restart the database, that the financial server goes into the endless reboot cycle and that no one can do anything because of some restrictive security policy.

That's what my team mostly focuses on these days - securing that organizational commitment to changing from the old ways of doing things. Software gets deployed or upgraded along the way to enact those agreements of cultural change, but it's not the focus. The risk of a temporary failure pales by comparison to the longer term business goal of running a secure and compliant business. A user not being able to log in for a few minutes is an inconvenience, as is the user who needs to file a change control record before getting root equivalent access. A culture that allows a bad actor to steal proprietary data, personal information, or payment information - that's inexcusable in today's market.

Organizations could do this on their own, but I've found that they often are not introspective enough to recognize a new way of doing things. Instead, they focus on what they can see - the software - rather than what they can't see - secure processes of authorizing and auditing privileged users. That's where the team I support brings external perspectives, and can offer our collective and individual experiences,  and what we've seen at other organizations. This helps organizations to apply the state of the art software efficiently and effectively.

Compensation plans and job descriptions

Staff retention and measurements