Sometimes I get the feeling I should walk in and back out when dealing with corporate security leaders. I’ve been in the unhappy position of having to show management where someone did something they shouldn’t have done and have watched those people get walked out the door. I’ve also been in the position of having to do something insecure because a manager who does not understand the risk has told me I must and personally dealt with the repercussions when the manager gets to stay. These experiences over the past couple of decades have brought me to a point in my career where I realize there is more ignorance to security than enlightenment.
Take my current situation as my excuse for writing this blog. Because of a security mandate, I am working on a project to restructure our deepest internal networks. This mandate came from someone with great intentions and I believe a strong fundamental desire and ability to make security better. Even though the source is solid, let me be clear that an edict came forth from the mountain saying thou shalt do X, which will cause you to have to do SOMETHING to make whatever it is you do as a business still happen. Let me also be clear that just prior to these big sweeping changes being communicated to my level, all but 8 people in my entire IT department were shown the door in the “spirit” of “synergy”. My disdain for this kind of corporate double talk is fuel for an entirely different rant. This is about security, so let’s focus on that.
I know every company, no matter how much money and effort they spend on security has a fundamental flaw in their security armor. Namely, people get lazy and arbitrary deadlines rule emotions. You can write a gleaming bright example of a security policy, chock full of good intentions and even better best practices but eventually, one of these things will happen as surely as death and taxes:
- When the policy says NO, someone’s mama (higher up) will veto the policy…
- Someone will open up a huge hole in the company because they are either too lazy to do it correctly or they wither in apathy because of absolutely moronic vendors who have no idea what their products DO, or…
- A deadline will loom and a big security risk will be assumed in the interest of a temporary fix that will live forever as a permanent solution.
There are other problems that will come out of the woodwork, but rest assured these three things will happen daily to any company with an IT department. There is very little you can do to guard against these things occurring unless you have a dyed in the wool dedication to security from the ground up, including most importantly the layers of crusty management. The fact is that an infrastructure must be built in support of the security policy AND the business requirements. That infrastructure must have hooks into productive solutions for whatever the business MUST have. It is unfortunate that most infrastructures are built around the concept that security is an optional component which can be minimized because of a low incidence of known compromise. The managers you choose to lead your company must also be dedicated to both security and the business as well. This appears to be the single biggest issue with security from where I am sitting. Security ignorance in a worker bee can be corrected. Security ignorance in management will spread and be much more painful to correct.
Even if you have a huge security team, dedicated to pen testing, code reviews, firewall change approvals, architectural reviews and policy management and enforcement, those three pitfalls listed above will all happen and they will be approved by your security leadership, in error.
Would you rather your company IT staff implement a business function that brings your payroll information dangerously close to compromise (perilously close) or would you rather that business function only be deployed when the proper security review has occurred and all concerns are eliminated?
I know how difficult and hypocritical this blog may seem, but there is a sincerity in what I am writing that is yielding an increasingly strong aversion to security laziness in me as time goes by. Anyone who has had to deal with a security compromise has had to admit to themselves there was a problem they either didn’t realize was there, or that there was a problem with an assumption they have made or a risk they have accepted willingly. Sometimes I wonder if people accepting this risk has had the pleasure of having their cyber underwear drawer rifled through by parties unknown. How many of them have seen their own systems taken over as attack systems or used to do illegal things? I doubt very many of them have, but I have seen it first hand. I also know that if those ignorant yet responsible leaders were confronted with this situation their choices as to what risk they wish to willingly assume would change.
Here are a couple of things I believe anyone with IT infrastructure should consider:
1) A security risk should be viewed as a bad check. You should not write bad checks. You should only produce a product (write a check) when you have money in the bank (all security risks eliminated). (Note that I said eliminated and meant it.)
2) A deadline should not be agreed upon until the entire project has been reviewed by your security staff and all time necessary for compliance testing and approvals are added to the plan. Your security team should be your inspectors. They should inspect everything from the footers and foundations, all the way to the top of the smoke stacks. They should also be there during initial planning so you streamline the process. No dates without proper security planning. None.
3) Security show stoppers should stop the show until a proper and unabridged solution is developed and approved. If a firewall modification is necessary and the requirements are unknown, a wide open hole is not an acceptable solution to the problem.
4) Architecture solves some problems that vendors create and refuse to make better. It is excruciating to see a vendor with a captive market create a product that has no viable competition that violates or ignores security best practices. The rapid growth of IP network technology is being seen in ever single technological vector in our existence. Most of these vertical technology market providers are stuck 10 years behind the curve for the average (not uber, but average) Internet Protocol hackers and crackers. The only thing still valid from 10 years ago is the statement that the only secure computer is the one disconnected from the network entirely. Everything else is crap, so catch up. If you must deploy an inherently insecure application within your environment, don’t connect it to anything. Don’t default to adding it to your network in any normal way. Instead, build your infrastructure in a way that is able to handle the problems, but don’t give up on beating your vendor(s) regularly. In my mind, you should post every single vulnerability you find to Full Disclosure, just make sure not to sign any contracts saying you CAN’T do that.
5) Inspect contracts with vendors and negotiate security language into that contract. Argue for support to be granted in spite of reasonable security controls they normally do not support. You cannot connect a Windows XP environment to your network without virus and malware controls at every layer of the OSI model, for example, but a huge number of vendors refuse support if you have those controls in place. This is a trend that must change. You shouldn’t deploy a UNIX environment without these controls either, btw.
5) The next time someone asks for a high risk change, stand your ground which should be rooted in a good security policy. The fact is if you give in to every hack job tech project manager who comes along you will have to eventually admit to yourself you are just a network bitch. Don’t be anybody’s bitch. Instead, be quick to do the following:
- Explain in clear and concise language why their request is impossible to complete given security policy and if necessary explain to them why the policy exists and how important it is. Do this calmly and without emotion. Smile and subtly nod your head yes and in record time they will think it is their idea not to do what they came to ask you to do.
- Be prepared to document the request to your manager with the information they need to fully understand why they should back you up. Sometimes the request is not defended against directly by any written policy. Be sure you are clear, concise and correct.
I’m tired of writing and I feel better.
