Does A Tight Budget Or A Time Crunch Mean It’s Okay To Compromise Security?

Ignorance? Tight budget? A lack of management comprehension?

I’ve just walked out of a meeting in which I drew upon the largest dose of self-control in my young career. The topic was expansion – new network, new designs, new servers. Factor in some delicious VMware server clusters and possibly some 4500 series switches, and this isn’t a project to gawk up. What has got me riled up this morning is the fact that all anyone wanted was the end result. They also wanted it, you guessed it, yesterday! No matter what corners were to be cut, the project was required to be done. The biggest corner cutting came at security.

I raised this point and asked, “It’s nice to want all this, and this is how we are going to achieve our end result, but what has my red flag raised is security. Nothing you have mentioned addresses this.” The curt reply was to make it work within the budget. This off-the-cuff, flippant response irked me, but I know not to fight fire with fire.

I have thought about how to solve this roadblock while teaching my colleagues/superiors about the importance of security. I want to do this in a way that highlights the need for security, as well as the steps that can be taken to minimize compromise and theft. I know currently that management are of the mindset, “A breach hasn’t happened to us.” A cotton-wool protected cocoon safely tucked away inside of virgin-guarded Internets has people foregoing firewalls and IDS/IPS systems. But generally, it’s not “if” an attack happens, it’s “when.” Gosh, I know my 1841 router at home shows port scans against it more commonly than Lady Gaga wears crazy outfits, let alone an enterprise Internet-facing device.

Now, sitting back at my Macbook, I am currently calming down. But I am adamant that the next meeting I walk into, I will be armed with reasons why we need security. Hopefully, I can find information about breaches into companies similar to the one I am assigned. Maybe then, reason will be seen just as light is seen when a light switch is flipped on. Things like:

  • Why you can’t put a price on security, but what you can expect from spending X,Y, or Z amounts.
  • Why you can’t pretend you will be okay.
  • You wouldn’t expose your own body to harm. Why expose your network?

I’ve put this post out to the Packet Pushers community, and have some questions.

  • Have there been situations where you have needed to calm yourself and recollect before trying again? I’d love to hear about it.
  • Currently, I am working with the minuscule budget figures that are left over to implement a rock-star security solution. How have others dealt with similar situations?
Anthony Burke
ABOUT ANTHONY - Network Engineer, blogger and CCIE wannabe. I am a guest blogger on PacketPushers, my own content over at blog.ciscoinferno.net and on Twitter @pandom_
  • Pingback: Mrs. Y Throws Down the Gauntlet

  • http://twitter.com/cloudtoad Derick Winkworth

    “Tyranny of the Now” and “Can’t cost more than you can raise with a bake sale” are two massive challenges many organizations face.  Managers manipulate young go-getters into slamming some bull$h!t together right now and reward them and praise them for failing utterly to consider what it means, not just for security, but for the environment in general.

    These same managers will not be around to see the consequences of their actions.  They’ll get some positive bullets, a bonus, and move on.  *sigh*.

  • http://twitter.com/Vegaskid1973 Matt Thompson

    Regarding security, there are two types of companies. Those that know they have been hacked and those that don’t.

    It’s a sad fact of life that on IT projects, when time is squeezed, the first things to be pushed out are documentation and testing so you end up with an implemented infrastructure that nobody can really rely on and the first time it inevitably falls over, nobody knows how it was put together which makes troubleshooting a right pain.

    When its the money being squeezed, the design as a whole can suffer and security is one of the more costly solutions meaning its the first thing to go. Add on top of that the ignorance many people have on this topic and you get a general feeling of apathy. As you state, the “we’ve not been attacked yet” attitude is misguided. Although my first sentence was written a little tongue in cheek, the fact is that part of a solid security solution isnt just stopping people getting in, its knowing when they try and also when they were successful.

    My approach would be to get a list of all the assets on this infrastructure. That includes the hardware but perhaps even more importantly the data. Then create a risk assessment document which assigns a value to each of these assets and determines the risk of each being compromised with the current design. You then decide, based on these combined factors, whether you should mitigate the risk, avoid it, accept it etc.

    If this is an area you haven’t covered before, there are many templates available online to help make this a less painful task. At the end, you should have something you can present to the project teammanagement that says something on the lines of:

    Risk A should be mitigated by implementing technology X
    Risk B should be avoided by implementing process Y
    Risk C can be accepted

    The worst case scenario? You get laughed at, the decision to implement as is doesn’t change but you have a document where at least somebody with accountability has signed off the risks. The same document you can pull out at a later date which shows you carried out due diligence and it was ignored.
    Hope this helps. If it doesnt, then perhaps this will: it is a sad fact that I have only ever had the fortune of working at a company that took security seriously once and I’m no longer there. ;-)

  • Adrian Skinner

    Like Matt says below, get it on the risk register for the project. One of the issues I come across is where the senior non technical people in charge of the money/project are not interested or can’t understand the technical risks. As such the risk needs to be presented in a manner they can understand, i.e in terms of the impact to the bottom line such as loss of service, reputation etc, versus the cost of mitigation.

    Giving the senior managers the chance to understand the risks in terms they can grasp easily means you can allow them to make a business decision as to what risks they can afford to take with their eyes open, and you can take comfort in that you did everything you could in ensuring the business has made the correct decision.

7ads6x98y