3rd Party Changes to Infrastructure

[Shiner3lima]

A question for the forum.

What would be the Change Control policy to control the use of VPN tokens for use by 3rd Party service providers?

I am trying to introduce a new method of controlling the access to our infrastructure by comms and network providers and some software houses who have been allowed to remedy problems to their services by use of a VPN token. I want to centrally govern the use of these tokens but in some cases the ability to fix a problem quickly out of hours does enable me to ensure there is very little disruption. However, I feel that any disruption to service should not overcome the issues of security.

There is a very real point of using common sense here. As it seems to me that although the distributing of tokens to 3rd parties has been allowed to happen in the first place, I think I should advance a policy that puts me back in control of who is connecting to my network by restricting this type of access.

I would be very interested to hear from anyone who might have had this same problem in the past and has introduced a similar policy.

Does anyone out there have a solution in place that makes this issue null and void?

Regards,
AndyW.

[jpgilles]

I would separate the issue in 2 pieces:

1) Security Management: determine who, when and how people are allowed to get remotely conected as well as for what purpose. Most important: how to log their connections and actions.

2) Change Management: your process should have planned for Emergency Changes that are implemented first, documented and replicated in your CMDB afterwards.
The point you are probably missing is how to handle the ECC (Emergency Change Committee) in such cases: whatever the nature, impact and urgency of the problem to be solved , NO change (even urgent) should be made without being formally authorized. You probaby need to introduce an Emergency Change Manager on-call schedule to cover all cases.

Ideally (you need to see how it can be implemented from a technical and organizational point of view) access to those 3rd parties shoud only be granted under authorization of the change manager.

I know it can seem a little bit heavy, but you can really jeopardize your operations if people are allowed to connect and make chances overnight as they think is appropriate without proper control, especially if people coming in the next morning might not be aware of the changes... The whole purpose of change management (to me) is to avoid this type of situations...

Hope it can help...

b.r.
JP
_________________
JP Gilles

[Shiner3lima]

Thanks JP. As the Change Control Manager it is my responsibility
to ensure that any changes to my infrastructure are controlled. These guys are able to do what they want, when they want, right now.
It may mean I get a call at 2am but I would rather that than find out
someone logged in maliciously and trashed our network.

Thanks again,

AndyW.

[Globis]

[Ed]

Hi Andy

As a Change Manager myself, I feel your pain.

If you are unable to take control of your tokens, then it comes back to old fashioned trust.

You trust all your techies to abide by the Change Management Policy, or you hit them with a big stick.

What is the difference between your techies and the 3rd party ones?

We have agreements from our 3rd Party engineers that they will abide by our CM processes or we go after them, just as we would for our own.

As JP has said Retrospective completion of Emergency Out of Hours Changes has to be allowed for. The alternative is just not tenable.

It comes down to trusting these engineers that what they are doing is needed now.

I hope this helps

Regards

Ed

[Shiner3lima]

Thanks Ed. I think Dave's point about the security policy is right. I cannot create the policy only enforce it. But right now, no one is looking at these things to create policy on. On the subject of trust. I can't get to grips with that one. I don't trust them. It is too easy for them to say they forgot about the process. What I dont want to do though, is put myself in the target area. It is not an easy one really.

AndyW.

[Ed]

Andy

I know what you mean. All you can do then is educate, educate, educate, and then use your big boots - That is your job. You are the gatekeeper for the environment - you have to be prepared to stand up and say No!

I have in the past had very stern meetings with everyone at a 3rd party to ensure that they knew they had to comply.

Do you not have a contract with them. You should have an underpinning contract with them that give you some teeth!

The trust comes later if they really are cowboys.

Have their company agreed to conform to your processes? If so approach their bosses or your Customer Service Manager from their company. Get nasty politely. apply as much pressure on him/her as you can. Let him fight your battles for you.

Or are you saying that whoever wrote the contract from your company has left you without any recourse?

Regards

Ed

[Globis]

There is always a degree of trust involved, otherwise very little would ever get done. However, at the same time you need to know if that trust is being exploited, therefore you have incident and change management so you can track these things.

Ed is absolutely right in that there should be an underpinning contract that governs the scope of activities of the 3rd party, and a signed 3rd party access agreement that makes your trust a little more easily granted!

Of course as change manager you can simply refuse to allow any changes implemented until these issues are sorted out. But be prepared for pain, suffering and hassle; and be careful as this is brinkmanship and depending on the importance of the services the 3rd parties manage, dangerous.

However, the usual -safer- corporate way to do this is to email everyone and his auntie about your 'grave concerns of potential security disasters', and desperately search for a suitable person/dept to push the problem onto. Then implement whatever controls you see fit whilst saying that you are waiting for the definitive policy from the aforesaid sucker whose problem it now is.

[jpgilles]