Skip to content

Solving Paper Cuts

Solving paper cuts

I was reminded last week that small decisions I make can significantly impact how effective or efficient other people are when doing their jobs.

As a security professional, it’s very easy to say no to a proposed design or process and use a specific interpretation of IT policy to justify your decision – and I’ve worked with many ‘old school’ security architects who take that exact approach.  It’s much more challenging to work within the bounds of policy so the business gets what it needs while ensuring identified risks have been controlled to an acceptable level – your classic win/win scenario.

But sometimes, even the business has been conditioned not to question the word of the ‘mighty’ security architect.  I learned last week that a decision I had made years ago meant that when users entered a comment into a free text field of a SaaS solution, they cannot use more than 15 digits.. not just 15 consecutive digits, but 15 digits in the entire text field.  If they exceed this limit, a redaction rule is triggered, which changes all but the last four digits to an X.

This was because there was a decision made not to store credit card numbers – which, of course, are 16 digits in length.  You can educate the user base about not entering credit cards, but sometimes people forget, so there was a decision made (by me) that anything over 16 digits should be reacted – and an overly aggressive redaction rule was put in place because “security said so.”

I discovered that users have been battling this issue for years, and I’ve been unaware.  A workaround was implemented, and users were forced to split a single comment into multiple comments, making things more difficult for everybody to follow.  Oh, and did I mention that this client is a bank?

I’ve been listening to a lot of podcasts recently, and I came across a concept called a ‘paper cut problem’.  This is where a new person joins a company and is told how to perform a specific task or process, and their first reaction is to say, “You do what now??” – because to an outsider, the process seems overly complex for no good reason.  Then, after they settle in and get comfortable, the problem they initially identified slowly fades away as it just becomes part of the regular way of doing things, and they only ever think about it when some new starter joins and they tell them, “Oh yeah, that’s the way it’s always been”.

I thought to myself well, if I’ve had this problem, perhaps others have experienced it too?  So, I addressed this in the best way I know how and… I sent an email.  In it, I asked the leads for each engineering team:

  • What are the top 2 or 3 issues that continuously impact your staff’s day-to-day tasks that they would like to change but can’t because they think security has said no.
  • Ask them to be specific and scope the problem down – this exercise isn’t meant to fix large-scale issues (and hopefully, those problems have already been identified and are being treated)
  • Take the consistently identified problems to the security architect you’re working with on the program and have a chat to see if a small change could potentially make a significant impact.

There are probably a lot of problems that annoy people that you can’t change, but perhaps it might still be worth identifying where those issues are and who knows, maybe one day you can?

And yes, at a superficial level, you might think that I’m solving a problem that doesn’t exist –communicate better, and all these problems go away.   And you would be right!  I don’t know about you though, but I know that for me it helps that I’m reminded of this sometimes.. to lift my head up and see the forest so to speak.

So perhaps have a think about some of the decisions you’ve made in your current role and ask yourself – How many people have you cut with paper lately?

Leave a Reply

Your email address will not be published. Required fields are marked *