Andy ITGuy – Information Security Blog

Timing is everything. Sometimes it works in your favor and sometimes it sneaks up and bits you in the butt. I wrote this last night (Thursday) and didn’t get around to posting it and then today I see several people pointing to this video on the very topic I wrote about. Oh Well, here it is a day late and a dollar short.

I’ve been thinking a lot lately about “Risk management”. After all that is the core of a security professional is supposed to do. We help the business manage the risk that they face. Sounds great in theory but how well does it really work. What I’m seeing is a not real risk management so much as compliance management. We are tasked with ensuring that the business doesn’t fall below the compliance threshold and that is considered risk management. We talk to the business about issues and give them our input on what needs to be done and we are told “that’s not required by regulation X or policy Z” so the business will approve the minimum that gets them “compliant” and they then go on about their merry way.

Some will say that if this happens then you are just ineffective in selling your program or solution and maybe that is the case from time to time but I think it’s a much deeper problem than that. The business is focused on doing business and they push back on those things that they see as being a hindrance. They are more concerned about ensuring that Customer Connie and Client Clint don’t have to do anything themselves to protect their interactions with the business. They don’t want to negatively impact the customer experience and I get that. Very few people like it when they are constantly being asked to verify their actions online and they will go elsewhere if given the opportunity. The problem is that the business has taken the hard line and wants security to be completely seamless and invisible to the customer. Now the business has become the department of NO. No, we don’t want to deploy something that requires the customer to take action. No, we don’t want to deploy a solution that will slow the transaction by 1/2 a second. No, we don’t want to change the way we code we want you to install something that fixes (or hides)our mistakes for us.

The business has fully bought into the compliance mentality and doesn’t want to go beyond it. They tell us that they want us to manage risk but what they really mean is that they want us to ensure that they are not at risk of being out of compliance. Unless of course the compliance requires too much of them they they want either a compensating control or to accept the risk and hope that it never comes back to bite them. Then once it does they blame security because we didn’t push hard enough or didn’t inform them of the potential for it to be this bad. Of course the 20 different emails and slide decks where we laid all of this out doesn’t matter at this point. It’s still our fault for not doing our job.

Everyone said it would happen. One day I would open my eyes and see the light. I’d have a sudden urge to rush to the local Apple Store and run up to a sales clerk (or do they call them “sales genius”?) and utter those magical, mystical words “I want a Mac!”

Well, I’m thinking that the time may be upon me even as I type. I’m giving serious consideration to going out and buying not one, not two, not three……. but FOUR Macs. One for each separate household in my family. That way when they have computer problems they will no longer be able to call me for help because I can’t work on them, won’t work on them and refuse to work on them! My sister got one a few months ago and I haven’t talked to her since. Not because I refuse to but because she knows that I can’t and won’t help her with Mac problems. One of my Brother-in-laws got one a year or so ago and now when he calls we actually talk about things other than his computer problems. If it’s worked out so well in those two cases it’s bound to make my extended family relationships much better if they all have one.

Thanks You Mr. Jobs! I can’t believe it took me this long to see the light.

I had the honor of being interviewed by Michael Fornal for his blog “Fighting In.Security”. He has just posted the interview here if you care to check it out. Read some of his own writings while you’re there. It’s more interesting than an interview with me.

One of the things that we are faced with is meeting goals that often change depending on lots of different things. Current threats, business goals/needs, projects, etc… We all have the ultimate goal of securing the data and systems that we are responsible for, at least I’d hope that we all shared that common goal. How we go about this varies greatly, again depending on lots of different factors. I’m not one to criticize someone for doing their best but I will point out areas that I take issue with. Especially when I feel that they are doing something that ultimately will cause larger problems or are making statements that I consider to be detrimental to security, others, or even just themselves.

I ran across a blog post the other day that caught my eye due to the title “Mitigating OWASP top ten without any code.” So I saved it to read later since it is relevant to my interest and potentially to doing my job in a more efficient way. (not that I code. I tried my hand at that many years ago and discovered that I don’t think like a coder and would be miserable and probably very bad at it). But I am responsible for protecting sites, apps, and systems that are potentially impacted by the OWASP Top Ten.

As I read the post it both impressed me and made me scratch my head. I know that the author says that these things have and are working for them and I think that is great. I’m not sure that I would have done it the same way and when you add all of these things together it could be quiet costly to implement. I do love the fact that it does implement defense in depth which is still very important. The more hurdles an attacker has to jump over the less likely he is to keep after you.

What really bothers me about all of this is the final paragraph.

All the key controls are implemented in the infrastructure. Developers can be left to coding the functionality and improving performance.

I have a hard time with this because it gives developers a free pass. Don’t worry about writing better and more secure code just finish quicker or add more “features” so we can market them to increase sales. It also allows poorly written code into production where it is vulnerable to new attacks and also the potential failure of one of your layers of defense. Are you going to fail closed if something fails and risk shutting down the site/app until it is fixed or allow access to insecure code with no protections in place (Just like the old days).

If we continue to allow (or encourage) poor coding practices then we will always be behind the curve and playing catch-up with the hackers. I’m all for infrastructure protections but not if it means we give developers a pass on writing secure code. I know code will always have errors and vulnerabilities in it just as infrastructure and other areas where we implement protections will always have their shortcomings.

The very last part of this post does give a little hope though.

The security controls can also be implemented at a company level, with minimal security involvement required per project.  Is it just that when all you have is a hammer, everything looks like a nail or is this truly a better approach?

It shows that they realize that their solution may not be the best or only answer and that they are open to suggestions. So my suggestion is train your developers on secure coding practices while implementing these other controls so that one day you may just be able to reduce the number of total controls because your software is well written.

To quote @Armorguy….

OMG! OMG! OMG! OMG!

A little over a year ago Martin Fisher (@armorguy) and I decided to start a security podcast. We invited our “News Yankee” Steve Ragan (@steved3) to join us and we started recording. We knew only a little about podcasting and we knew that we wanted to do something a little different from most of the other security podcasts out there. We decided to focus on areas that we knew best which are leadership, management and operations.  As time went on we decided to add a “young whipper snapper” to the crew and Joseph Sokoly (@jsokoly) joined us. We’ve had a blast doing it and enjoyed interacting with listeners and with our guests. One thing that we never even considered is that a year later we would actually be honored to be listed as one of 4 finalists in the Social Security Awards for best security podcast.  We I read the post from Alan Shimel my heart stopped and jumped all at the same time. Especially when you see who the other finalists are.

1. Pauldotcom Security Weekly
2. The Silver Bullet Security Podcast
3. CERTS Podcast Series

WOW! what company to be in.

Obviously we would absolutely love it if you would vote for us but even more importantly keep listen (or start if you haven’t been) and tell your friends about us.

To cast your vote you can do so from this link.