Security Manager's Journal: Security bumps up against the way things have always been done

Our manager fields a request to allow an Internet-connected server on the network

Last week I got a request to open up a rule on our corporate firewall to allow Internet access to a new development server that our engineers have been working on. When I tell you that this server lives on our internal corporate network, you can probably guess what I said.

Of course I said no. Any Internet-facing servers need to go on our DMZ. There are too many risks associated with allowing Internet access into our corporate network. For example, if a server were compromised by a hacker or malware, it could be used to attack other critical servers on our network (including financial servers, HR servers, file servers containing sensitive corporate data and intellectual property). It's a basic of information security: Internet-facing servers need to go on a protected network segment, filtered by a smart firewall.

But in a company that never had a formal information security program before I arrived, basic information security is still pretty much ignored. Know what the response was? "We already have other servers set up this way. Can we just do the same thing with the new server?"

It's true that we have servers set up this way. It's the way things were done before I arrived. But the point in bringing me in was that someone was needed to spot the dangerous security practices and find new and safer ways to accomplish what the business needed done. Naturally, I've had my eye on those Internet-facing servers. I want to move every server that accepts Internet connections out to a DMZ, but it's a big project. Some groundwork has been done, and a plan is in place, but the work hasn't been completed. That's why the engineers could point to other servers that are Internet-connected on our corporate network. And until that network migration is completed, I am going to have this problem of people arguing that their request isn't for something that doesn't already happen on our network.

I was facing a couple of options.

I could be firm in my refusal, declaring that things will be done differently from this point forward. I've tried this in the past, with mixed results. Being a hard-nosed naysayer has won me a lot of enemies who ultimately sabotaged my long-term success. Sometimes you have to accept that as just part of the security manager's job, but whenever possible I now try to find a way to work with people to find a more secure approach that reduces risks while still accomplishing what the business is trying to do.

In that spirit of cooperation, I could allow the connection temporarily until we are able to migrate everything to our DMZ. After all, how much additional risk do we take on by adding one more server? But I'm really not comfortable with compounding the problem, and there's a big difference between being stuck with arrangements that predate my arrival and actively approving something similar myself. If I were to say yes to this new request, the decision would be mine, and I'd have to turn in my membership card to the security guild. I'd never be able to show my face to my colleagues again.

My discomfort with setting such a precedent was making me lean toward taking a hard line and telling the engineers to stick their server in the DMZ. The engineers and our IT network team would have to do extra work to figure out how to allow the server to communicate with its back-end support servers through the firewall, but that should be doable. I would draw a line in the sand and say that from this point forward, all new servers that need to accept Internet connections will go in the DMZ.

That was when the other shoe dropped. I found out that the server had already been installed and has Internet access! How did that happen? Seems that IT just goes ahead and sets these things up on request, because that's how they've always done it. And it turned out that the request was not to allow Internet access to the server; the engineers just assumed that was fine and felt no need to ask me about it. What they wanted was to create a DNS entry for the new server. I was floored that they would even consider this. If providing a server with an Internet connection is like leaving your car in a dark parking lot overnight with the keys in the ignition, then creating a DNS entry for that server is like advertising that fact with a large neon sign. A DNS entry would publish to every hacker in the world where to go to attack our server.

There was no way I could allow this, so I took the hard line. I told them to move the server to the DMZ first, and then we could publish a DNS entry. The engineers don't really get why I'm "changing the rules" on them, though I've tried to explain.

What we have now is yet another Internet-connected server on our network. But at least I didn't give the go-ahead for that, and I have stopped the much worse possibility of giving that server a DNS entry. But I need to put a stop to unsafe practices. I just hope I can get the rest of our network squared away before something really bad happens.

This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at jf.rice@engineer.com.

Join in

To join in the discussions about security, go to blogs.computerworld.com/security.

How AI will change enterprise mobility
  
Shop Tech Products at Amazon