Posts Tagged ‘ data loss ’

Broken Processes and Broken Systems

New URL, same post.  Anyways…

Over the past ten years there has been a dramatic shift in information security and the importance it plays in business continuity. This change has moved information security from being widely regarded as an irritating necessity to a mission critical component. With big names and massive breaches, such as T.J. Maxx and Heartland Payment Systems, there is increasing pressure from both consumers and shareholders to better protect corporate and personal assets.

I think we can all agree that more intelligent and more rigid security measures are, well, better, but there’s one major problem: a majority of this new security is so poorly implemented and maintained that it’s really only providing an illusion of security. In my opinion, this is more dangerous than acknowledging that an organization is failing to adequately secure its environment. I mean, if you’ve kind of sort of “secured” this sensitive information once, it’s secured for good, right? What’s even worse is that a majority of the people responsible for propagating such poor security practices are those who have been tasked with securing these valuable assets in the first place! In my experience, this occurs for a variety of reasons which probably aren’t worth getting into right now, but suffice to say that when it comes to the infosec community, there’s a lot of things we need to change – and they need to change fast.

Unfortunately, I don’t have all the answers; in fact, I might not have any answers but I do have some ideas. I think in order to be a successful practitioner of any discipline, one must have rules – beliefs which serve as the basis for your methodology and things which make you a true professional. Many people in the community have grown disenchanted with the attempts made at effective security and many are new to the community and haven’t had the experiences yet to form their own ideas. There’s also a large majority of people who don’t bother with ideas, and just do the things they do because of vendor favoritism, common practices, and even out of pure laziness. The fact of the matter is that there’s no best vendor for everything, common practice does not necessarily mean best practice and if you’re lazy, well you’ve probably stopped reading by now.

I’ve rolled around a lot of ideas in my head for quite awhile now and after some time, it’s all starting to make more sense. Here are some things to think about…

  1. It is important to patch the application and patch the OS, but it is more important to fix the broken process which allows these problems to exist.

This is possibly my biggest concern in information security; the process does not get patched. Vulnerabilities are transient, system state is always subject to change, and you cannot account for every bug and every attack vector, but there is a lot to be said for trying. If you examine any environment, you will find that there is always a tremendous amount of change and these changes are often not properly reviewed in the context of security. Let’s do a walkthrough on this one, and an overly simplified one at that.

Bob is a security engineer at Frobnitz Inc. and he is in charge of quarterly vulnerability scanning and remediation tracking. At the start of the quarter, Bob has scanned all relevant systems and has a nice executive summary complete with some pretty graphs and pie charts. The bad part is that there’s a lot of high and medium severity vulnerabilities in these pies and that’s not a good thing. Now that vulnerability scanning has completed and management is aware of Bob and his red pies, the next logical step takes our friend to remediation efforts. Let’s move the situation along and just say that remediation is a huge success and completes in the most expeditious way (hah). At the end of the quarter, Bob proudly presents his new green pies to management and there is much celebration. With this task completed (for now), Bob goes back to managing the firewalls, IDS/IPS, AV, etc., putting all this silly vulnerability stuff behind him.

As time goes on, Bob finds himself entering Q2 and it’s time to start vulnerability scanning for the quarter. Just like before, the scans complete and Bob has new reports for a quarterly update with the boss. Only there’s one problem, Bob’s green pies are getting red again and just like before, the last thing Bob needs is more red pies. So, in keeping with tradition, Bob goes back to the task of remediation, presents the final report, basks in his green pie charts and waits for next quarter.

Now, there is one major problem here which I would hope many would have noticed:

Insanity: doing the same thing over and over again and expecting different results.
~Albert Einstein

Our fictitious friend parallels many people’s efforts in the field in an unfortunate way. You see, too often people don’t stop and ask the important question of “Why?” when looking at something like scan results, the vulnerabilities are easy to see but taking the time to understand them and furthermore, how to correct the cause takes more effort. Situations such as this are incredibly common; so common that they eventually just become accepted and that’s just about as useful as a bunch of red pies on your weekly/quarterly/whateverly scans, but that’s what you will end up with.

To complicate matters even further, the root cause of such things is often fairly far from your immediate scope and effectively suggesting and implementing these changes can be a full-time job with a lot of push back in no time at all. On this note, it’s important to realize something; everything is within scope. You see, when you provide security services, especially as an internal consultant, all of the teams that are “unrelated” to your work may be introducing new security flaws to the environment. As a result, it’s now related, you need to be involved, and it’s important to exercise your expertise and guide neighboring teams in an effort to improve or even fix the processes and systems. And I feel the need to make this known, but trying to push these changes isn’t the fast track to being the cool kid (sorry). Most people are inherently resistant when it comes to change and that holds very true in IT. From software developers, to the patch management people, to architecture teams and even the guy in marketing who gets told that he can’t run uTorrent at the office anymore, people will likely not enjoy these changes. Please keep one very important thing in mind, our job is to enhance and supplement the integrity and security of the environment and you cannot do that by turning a blind eye to broken processes which expose corporate assets and jeopardize the confidentiality of sensitive information.

Now that expectations have been set and we’re aware it’s not easy to be well liked and be in information security at the same time, what do we do? Well, this goes back to what I said before and that is to say that I don’t have all the answers. But for what it’s worth, I will describe an approach which has worked for me in the past. Be diplomatic, understand the concerns regarding the implementation of your ideas from other teams, establish a rapport so that your ideas will be well-received, and lastly, in subtle ways, be sure to remind others that while you may technically be on different teams, the bigger picture is that you’re all on the same team. Some people might feel like you’re creating more work for them, and at face value, that’s probably true. But if you were to ask someone whether they want to enhance the patch management and system deployment processes or play catch-up with hundreds of machines after quarterly vulnerability scanning, which do you think they would pick?

I think I am out of energy to write down more points, but hopefully I can post them in the near future, time permitting of course. In the meantime, thanks for reading.

Advertisements