Every company I have worked for has had some degree of friction between sales and marketing teams. While their organizational charters are to support one another, sales always has some disagreement about how products are positioned, the quality of competitive intelligence, the quality of leads, and the lack of <insert object here> to grease the customer skids. Marketing complains that sales does not follow the product sales scripts, doesn’t call leads in a timely fashion, and don’t do a good job of collecting customer intelligence. Friction is a natural part of the relationship between the two organizations, so careful balancing is necessary.

I was reading George Hulme’s interview David Litchfield on securing the data castle this morning, which provides basic security steps every organization should take. There’s also a list of intermediate Oracle security controls (PDF). But the real challenge was not performing Litchfield’s steps – it’s managing the resulting friction. The issue is that problems arising between database administrators and everybody else. Litchfield says:

Beyond patch updates and good password management, what else can organizations be doing that they’re not? Use the principle of least privilege within their applications. This is a very important one. People are pressured into getting their applications running as quickly as they can. However, when they try to manage permissions properly, that good practice can delay deployment slightly. So they say, “Oh look, let’s just give users all the permissions. The application seems to work with these settings. Let’s shove that into production.” Not a great approach. If you don’t want a breach, it’s really worth spending the extra time to design an application that operates on least privilege.

Which is all true, but only one side of the coin. For example, setting permissions is easy. Managing and maintaining good permissions over time is more work and creates friction between organizations. Most DBAs face user calls on a daily basis, asking for added permissions to complete some task. Users look at permissions – or their lack – as impediments to getting their jobs done. Worse, should the DBA decline the request, the DBA takes the blame for lost time. DBAs need to add the permissions and then – at some prearranged time – revoke them. But most DBAs, looking to avoid future calls to add privileges, never revoke them. It’s easier and less hassle, and users are happier. Face it – a few minutes of wasted time for both parties, especially with hundreds or even thousands of users, adds up to a lot of time. Who’s going to notice?

Patching is the same – upgrade an application or database revision and stuff breaks. Or just as bad, the application works differently than before. New features and functions create complaints like “What happened to X?” and “It used to do Y, but now it doesn’t!”, so for several weeks the help desk is swamped with calls. And password rotation and long password requirements both generate help desk calls by the dozen.

So what’s the result? User complaints. Systems are not reliable, which results in the poor DBA getting a poor ‘performance’ rating. Which is sad because the friction between user demands for everything and DBAs holding the line for security is a sign that DBAs are doing their jobs. But doing their jobs gets them dinged on performance, so they don’t get raises, so they leave for other jobs.

Any good DBA understands that there is a correct degree of friction in their role for security. It’s not just planning for the security measures you want to put in place, but understanding how to mitigate their impact on the organization. Plan ahead and don’t let security be “your fault”.

Share: