77

Facts:

  • Mid-sized company with multiple branches.
  • I wrote the access-control (among other things) powering the smart readers and I'm entitled to a master-token.
  • Brother of CEO is employed as well in a minor position due to family ties.
  • That brother asked me to lend him my master-token to the CEO's office because he doesn't have access and needed a key for one of the company cars (which he's entitled to).
  • I gave him the token trusting him and thinking blood is thicker than water.
  • Was surprised/baffled that it takes ten minutes until he returned the token.
  • Now I'm thinking what he's been doing in the office that took him so long.
  • My question is if I should inform the CEO that his brother was in his office and what caveats I could expect?

For clarification:

  • I wasn't in the office with him - I stayed in my office
  • I designed the system - so all access-attempts are logged (granted & denied) including the token-code and the respective owner (in that case me) and can be distilled into a report for admin-users
  • CEO has admin rights to the access-control-system

  • The CEO was not available to me or him since he's on a business trip and I didn't expect any malicious intent under brothers.

  • Maybe a little naive but I try to see the good in people until they prove me wrong.
  • I also was a bit afraid of the consequences that could have happened if I deny access (maybe a rant against me from the CEO why I didn't let his own blood&flesh into his office to get a key)

Follow up:

I just talked to our CEO along the lines David K. mentioned in his very helpful answer and 'reported' the incident. He seemed vaguely interested and only advised me to give his brother full access - and that's what I did..

Conclusion:

We also internally agreed on evaluating our current access policies to cover all possible incidents and creating a set of rules/methods to be applied in specific edge-cases.

7
  • 64
    What does the access control policy say about sharing master access tokens?
    – user44108
    Commented Jun 28, 2019 at 14:15
  • 1
    Generally it's not allowed - so everyone has to use his token to access only his zones - but given that they are brothers and work together since 15+ years and trust each other, I dind't expect any malicious intent and made an exception..
    – iLuvLogix
    Commented Jun 28, 2019 at 14:21
  • 85
    You made an exception? On what's supposed to be a secure and rigid security system?
    – user44108
    Commented Jun 28, 2019 at 14:23
  • 4
    As I mentioned in the clarifications I was afraid of the consequences that could have happened if I deny access since they trust each other..
    – iLuvLogix
    Commented Jun 28, 2019 at 14:26
  • 3
    Forgive my ignorance... What are the company policies on the matter? Does the company have policies and procedures for the incident? This is likely a security incident and it needs to be formally reported. Don't make one bad decision and follow it with another bad decision. Simply follow the company's policies and procedures.
    – user25792
    Commented Jun 29, 2019 at 5:20

5 Answers 5

156

It's not a bad idea to mention it off-hand, but I wouldn't make a big deal out of it at all. You need to make sure this comes off as an FYI, and not any sort of accusation. Next time you see the CEO, just casually mention it.

Hey boss, just so you know I let your brother into your office last week so he could get the keys to the car. Didn't want you worrying in case you noticed things had moved.

Next time, don't give him your token. Instead you should have gone with him or offered to get the keys for him. The whole point of having unique tokens is so that you know who has accessed what. It would be similar to letting him use your logged-in admin account and then walking away from the screen for 10 minutes. Now any place he accessed has your name tied to it. Yes, you trust the brother, and it doesn't appear he accessed anything he shouldn't, but it's really bad security practice to be sharing your personal access token. You should have refused on those grounds alone.

8
  • 12
    I did check immediatly in the db - he only accessed that one reader of his brothers office..
    – iLuvLogix
    Commented Jun 28, 2019 at 14:23
  • 4
    Good answer. This is what I was thinking. Depending on how familiar he is with the CEO, he could mention it very casually, which is how I'd try to present it.
    – Keith
    Commented Jun 28, 2019 at 14:50
  • 53
    I like this answer as well as the one from Lucas - would accept both if I could ;) Maybe a combination like: "Hey boss, should I generate a token for your brother? He needed to access your office, so I had to lend him my own so he could get the keys to the car. Didn't want you worrying in case you noticed things had moved.."
    – iLuvLogix
    Commented Jun 28, 2019 at 14:53
  • 6
    I would also add a clear "in hindsight, not the best choice, wont do this again"
    – Martijn
    Commented Jun 29, 2019 at 18:01
  • 18
    ...no need to resort to self-accusation ("won't do this again"), but maybe an open question to the boss: "I felt uncertain about that; can we talk about creating a standard procedure for cases like that?"
    – jvb
    Commented Jun 30, 2019 at 9:17
62

First, you should not have given him your token. If he needed to get in the office, he should've asked his brother for permission, which then would've probably contacted you to give him a token with access to his office.

But now that you've done it, informing him would probably be the smartest decision. A simple, "Hey boss, should I generate a token for your brother? Yesterday he needed to access your office, so I had to lend him my own." explains the situation well enough.

4
  • 4
    To clarify: His brother (the CEO) was not available to me or him since he's on a business trip and I didn't expect any malicious intent under brothers - maybe a little naive but I try to see the good in people untiol they proove me wrong. I also was a bit afraid of the consequences that could have happened if I deny access (maybe a rant against me from the CEO why I didn't let his own blood&flesh into his office to get a key)
    – iLuvLogix
    Commented Jun 28, 2019 at 14:18
  • 12
    @iLuvLogix can't see the point of your clarification, the answer is clear enough. To put it simply, you messed up and the evidence shows that you were in the office... The brother just says "was not me" and you are in the frame. The CEO trusted you and that is why he asked you to set up the security as he wanted.
    – Solar Mike
    Commented Jun 28, 2019 at 15:14
  • @iLuvLogix: Well, another option might have been to temporarily grant the brother's access token the right to access the CEO office (if that is techncally possible). That way everything would be logged properly.
    – sleske
    Commented Jul 1, 2019 at 9:15
  • This is a simple case of "cover your own ass". @iLuvLogix needs to make sure his boss knows he was not personally in his office, and why his badge was used in the act.
    – Rich
    Commented Jul 1, 2019 at 13:25
34

Absolutely yes.

You can't control the information here. As mentioned elsewhere here, if anything untoward happened in the CEO's office, it will seem like you did it. If you don't have a contemporaneous record that you gave your token to the brother, you will have essentially no defense against an accusation that you did it.

Even if nothing odd happened at all, the brother could easily mention something about you giving him your token ("Oh, don't worry if you forgot your token today. iLuvLogix will just help you get around the security system if you need it, like he did for me."). If anyone in the company cares about the security protocols, that's not a great look for you.

What I would do to bring it up would be to describe the incident to the CEO, explain why you made the decisions you did in this one, isolated case where it seemed like there weren't any other options, and then ask the CEO to collaborate with you to create policies that will address similar situations in the future. That will shift the focus from

I did something that might have been a mistake

to

We have an edge case in our security setup, revealed through this incident, and we should decide on a policy to deal with it when that case comes up again

The latter expresses what happened, so the CEO will be aware, points out the problem in a general way and presents it in a constructive light, and gets the CEO involved in solving the problem going forward (rather than having to just accept a mistake).


More tangentially, this comment leapt out at me:

I didn't expect any malicious intent under brothers - maybe a little naive but I try to see the good in people untiol they proove me wrong

This does not strike me as an attitude or approach suitable to someone in charge of restricted access protocols or security more broadly. The situations where such an attitude is harmless are ones where security doesn't matter. Situations where it's not benign are exactly the situations security protocols exist to address.

This attitude is not something I would mention to the CEO, nor one that I would use to guide my decision-making in similar cases in the future.

18

A simple "I am afraid I cannot lend you the master token but sure get the keys for you" would save a lot of trouble.

If the Boss later asks why his blood and flesh was not granted access (probably he will understand your reasons since he asked you to design the system) you can offer to create a token for the brother.

1
  • 28
    +1 Security Officers are supposed to be assholes with thick skin who do unpopular things,
    – RonJohn
    Commented Jun 29, 2019 at 19:24
8

You've done a security violation. You report it.

On the long term: you've demonstrated that you can't trust yourself with a master token. Arrange to pass it to someone else, eg your boss. If it's even necessary to exist, as in properly designed system there is no place for magic bullets. This way nobody can ask you for such favor in the future. Giving the master token was the effect, the cause was having it in the first place.

It might feel cool to wield the power of keys to the kingdom. But feelings are not worth it. Remember the mantra: the lesser the responsibility, the lesser the worries.

3
  • 7
    Also, if the person who wrote the security system overrides it whenever he feels it is convenient, the rest of the employees will quickly come to think of the security measures as "optional". People with responsabilities in the security system should be giving good example, not bad example.
    – SJuan76
    Commented Jun 30, 2019 at 10:52
  • 2
    It seems a bit of a long shot to conclude from this single incident that OP "can't trust yourself with a master token". Especially as OP has thought about the incident and asked here. Plus, it's part of his job to have one, so asking to give it up might be equivalent to resigning his position.
    – sleske
    Commented Jul 1, 2019 at 9:17
  • @sleske He described his job as "writing the system" so I conclude he's and IT guy. It's highly unusual for an IT person to double as a custodian. I don't consider my words as a long shot. Master token is a huge responsibility that should not be taken without compensation.
    – Agent_L
    Commented Jul 4, 2019 at 10:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .