fudsec.com

Showcasing Fear, Uncertainty and Doubt from the Information Security Industry

The Corollary of Fear, Uncertainty and Doubt - False Reassurance

This week, geek reporter Carl Brooks does a turn on the fudsec catwalk.  Carl worked in the trenches for 10 years as an IT consultant/administrator before switching careers.  Here he argues that FUD is less about security, and more about shills selling security to suckers.  He has a point - maybe it's time to "rebrand" fudsec: "Shills and Suckers"?  Thanks Carl!

By Carl Brooks

I’m here to join the long chain of security-minded IT people to straighten out some of the bugaboos of security- where it lies, where you should start looking, and why people really need, at the very least, to understand what to worry about.

I’m no security professional. I’m a middling-to-fair sysadmin with plenty of run-of-the-mill small network experience, but I worked for people to whom computers might as well have been crystal balls and CAT5e was something I named my pets because I was weird. So like many of my ilk, I was the temple guardian for lots and lots and lots of users who trusted everything they read in an email or thought Microsoft ISA was a real firewall because it said so on the box.

This is heart of the problem. Computers are commoditized, networks are commoditized, IT overall comes in a box that you buy off the shelf. Its not news that any old sap can get themselves a full fledged network of computing resources with a call to Dell and a trip to Best Buy. On the way comes fear, uncertainty and doubt about all the things that can go wrong, all the threats out there -- and 99% of them are bogus -- just sales pitches to cram another product in your box or your building or your brain.

Bought a server? The Dell fella sure was helpful, huh? He even said you should get up and running with that antivirus server trial on there, roll it out to all your computers, keep your employees safe! Never mind that you don't know what your router is for - it's got a firewall, says so on the box. Why, without a firewall, you're screwed like a slow ape by a fast gorilla! And backups!!!! Holy DAT, Batman, you need a backup! Yes, plug it in. Phew. Done.

That's the problem, kids. Every user in the world is convinced they need security features, not security procedures. They KNOW this. It's drilled in. tell a manager antivirus is a bow, not the present, or tell him managing backups will take more than one trip, and you've got five heads. He knows he's supposed to be afraid, but you aren't presenting the answers he's primed for. That’s what FUD is for- shape someone's worry, and you've shaped their answer.  

This is why, for the purposes of security, there is only one answer- someone, somewhere, has to know what the fuck is going on with your IT. That responsibility is the only answer to buying 'solutions', because they can, and do, go horribly wrong. It's the corollary of fear, uncertainty and doubt - false reassurance and false confidence lead to consequences you don't understand.

As always, security devolves to fundamentals - and they're usually forgotten after all the dots on the planning chart are connected. Real security is the afterthought until it’s a necessity. Its more common than not that nobody really knows what’s going on in their organization. That is always the real headache around security. It’s almost NEVER a technical problem.
 
Now, here’s a real security problem or two, by way of example:

Back when I worked for a living, we ran ‘outsourced IT’ for small businesses; we also ran a thriving emergency room for computing disasters.

One day we get a server with a failed RAID 5 array, delivered by a guy who pretends he has no idea why he is there. We call the boss, find out he wants the RAID fixed and the data back. Unfortunately, the array has been destroyed despite having two perfectly fine hard drives.

Oh, dear. We naturally ask Mr. Shrugs-a-Lot what led to this turn of events we eventually determine, no thanks to Mr Now-Sweating-Bullets, that he had called his “computer guy” who, over the phone, had tried to help him diagnose and repair a failed disk in a hotswap RAID5 array. Hotswap!!!. “Computer guy" doesn’t know what on God’s green earth he is doing, so he calls Dell support on his other phone, while relaying instructions to Mr Now-Gripped-with-Icy-Terror. Guess what Dell told them to do.

To sum up, my boss worked through the weekend, made a nice fat fee and I had a frank talk with the client company's president. That’s a security problem, people. But, you say, they didn’t know any better, clearly this doesn’t happen in organizations that use process and compliance and have IT staff.

Oh, really?

Ok, one day, in runs a dude we’d never seen before, carrying a circa 1998 whitebox tower. This is in 2006-ish. He is in a panic. He works for a security company, the kind that sits in gatehouses with badges on. It is, naturally, a disaster- failed mainboard, rapidly failing hard drive, years of environmental exposure, frankly worthless. It’s a loss. More panic.  Many cell phone calls, hands waving, and treading circles in the workshop. Turns out there is no replacement for this machine, no backups and no way to reconstruct the configurations.

Windows 98, naturally, with some custom app some nameless developer came up with a long time ago, no docs, no contacts, nothing. They are royally fucked; this is the thing onsite they need to do their job. Well, we perform the specialty of IT all over the world, and pull something out of our asses, locate a chassis and gear that supports this slop, image the drive to a new one, etc.  Off they go, the security folks with their repaired and functional piece of poop. What was it for?
 
It was the sole repository of photo ID and entry and exit badge verification data, including all the photos and employee records, for a single point of entry at a very, very, very large aerospace weapons manufacturer.
 
We did a little work for that “security company” subsequently. Anyone want to guess the admin password on their NETGEAR firewall? Don’t bother, you can look it up.
 
Now THAT, ladies and gentlemen, is a security problem.

The Fallacy of Secure Software

This weeks guest post is by Justin Clarke, an unusual blend of Web Application Security freak and Kiwi.  Justin is the lead author of "SQL Injection Attacks and Defense" - a book that Richard Bejtlich recently voted as his 2009 "Best Book Bejtlich Read" (high praise indeed).  Justin is the man you call when your webapp security program needs to "keep it real" ;-).  Thanks Justin!

So, you've got yourself a security solution for software that your organization develops. Maybe you've just invested in some automated tools, or developer training. Maybe you did hear a bit of FUD in the sales presentation, but it all seemed to make sense? Great! You're going to be producing secure code now aren't you?  Security problem over?

Well, no.

There are a number of problems with solving the problem of insecure software. One of the biggest is that there is no one-size-fits-all solution to the problem, regardless of what some less-than-honest vendors will tell you. All approaches that are parts of solving the insecure software problem have their upsides and downsides. To give a few examples, lets look at some of the popular approaches to assuring software security:

Penetration testing/blackbox testing - probably the most popular and widespread approach to securing software such as web/network applications. For enterprise situations, this would normally be performed near to completion, generally in a user acceptance or pre-production environment. As an approach, it is intended to simulate the risk of an external party (such as an attacker or malicious user of the system) attempting to compromise the system. 

The generally accepted upsides of this approach are that it should give you a good picture of where you are with regards to someone breaking in. Downsides include that it is resource intensive (and therefore expensive), and very dependent on the skill of the people performing the assessment. It is also very late in the development cycle, so in many cases major rework can result in cost and schedule overruns and delays. Very commonly used in environments where the possible loss due to a security issue is high, such as banks and other financial institutions. 

A variation is the use of automation for some or all of the testing. These are generally tools that implement some from of "fuzzing" approach, with the most mature products being those in the web application space from HP and IBM. This provides the ability to cover many more applications in the same amount of time, but seldom with the same level of depth or flexibility that a person performing the same assessment could. Very commonly these are used in conjunction with other assessment approaches in order to provide greater coverage or to find easier to detect issues that would then warrant additional manual attention. 

Code Review - becoming increasingly popular in the United States, and to some extent in Europe, is the review of the source code of an application for security vulnerabilities, either on a manual, automated, or combination of both basis. Manual analysis of source code is extremely resource intensive and as such can be very expensive, however recently a number of static analysis tools (from vendors such as Fortify and IBM) have become effective in allowing the analysis of larger volumes of source code for security issues.

The upside to this approach is that it should provide far greater coverage than black box testing, as all of the code included in the solution and all possible execution paths can be evaluated, potentially allowing a lot more issues to be discovered - including those occurring from edge cases that may not be picked up with other approaches. The downside to this approach is that it can still be resource intensive, even if using automation. Also, the pace of technology change restricts the ability for automated tools to support newer technologies - the wide variety of technologies and frameworks in use means that it is extremely difficult for automated tool vendors to support a wide selection of the technologies that are currently in use. Code review is commonly used in areas where security failure would be especially critical or result in major loss.

Platform Defenses - another area that is seeing increasing use if to have platform (or in some cases, framework) level defenses in place, normally so that some level of protection is afforded to applications running in that environment regardless of whether the application itself is secure. Some widely spaced examples are buffer overflow protections (such as stack canaries and non-executable stacks) and web application firewalls.

The upside to this approach is that, in many cases, the application developer will need to make minimal (if any) changes in order to take advantage of these security features. These can also be a useful approach for providing additional security over applications purchased into an organization. The downside to this approach is that they can only provide a band-aid level of protection if an underlying security issue does exist. Also, for each of the approaches there is generally widely known issues, limitations, and bypasses for getting around that particular control.   

Training - always popular is security training for developers. For enterprise situations this can be customized to be most relevant for the types of issues that are most commonly present in that organization's applications. Upsides to this approach are that a good training program can increase awareness of issues, and change development practices in the short term. Downsides are that training is a point in time activity, and as such must be reinforced or followed up to ensure that new starters are trained and that trained security knowledge is not lost over time.

Architectural/Design Analysis - areas that are increasingly seeing attention are approaches that seek to tackle security issues at the requirements, design and implementation stages. These could take the form of security reviews of the architecture and/or design and threat/risk analysis activities (such as Threat Modeling). 

Upsides to analysis at this level include the ability to detect and correct architectural or design issues that would be extremely difficult (or in some cases, impractical) to address during or after development, potentially leading to significant cost savings over addressing these later in the development process. The main downside of this approach is the difficulty of developing and maintaining these types of analysis with popular development approaches (e.g. agile development approaches), largely due to the velocity of changes to the design during development. 

OK, so those all work then? And other people are using them. OK, I'll pick the best one of these approaches for me and I'll be fine! 

Well, no. Anyone who tells you that, or uses that approach while selling you something is selling you a load of FUD... there is no silver bullet. First of all, there isn't any real amount of scientific research available which would give you any guidance as to what approach would be the best, or the best for you. Also, generally held belief if you have a look at what is available, especially if you look at what information is available on what other organizations (such as Microsoft) are doing would seem to imply that you need to be doing all of these approaches and more. Which would be both far too expensive, and far too much change for most organizations to even consider implementing.

So, is there anything out there that would tell me what I should be doing if I want secure software? Something useful, and FUD-free?

Well, yes and no.

Recently a couple of closely related frameworks have been released that at provide some structure to this question though. Although a number of approaches to the Secure SDLC have been publicly available in the past (notably Microsoft's SDL), these take a different approach of looking at the maturity of security considerations in the development process. These are the Open Software Assurance Maturity Model (OpenSAMM) and Building Security In Maturity Model (BSIMM) models. These two models both look at the processes you would normally expect to see within a "Secure SDLC" at various levels of maturity in a similar way to a Capability Maturity Model. The main difference between the models is that the research that has gone into BSIMM captures actual secure development practice at large organizations with initiatives in place (such as Microsoft, Google, and Wells Fargo) whereas OpenSAMM presents a more academic model of leading practice.

These models are very useful for answering questions about what you could do - especially BSIMM. They are even pretty good at giving you information and materials that would help justify why you would want to introduce certain activities. What they're not good at is providing you with the vision of secure development you'll need for your organization. They are good at providing a framework for tying together disparate efforts into a consistent picture, but you'll have to provide the driving force behind how you will get from where you are now to where you want to be. They are also pretty good for having in your back pocket for after you've got a couple of secure development activities in place (through guerilla means or otherwise) to be able to relate gaps in the organizational processes and skillsets to activities that should be looked at next.

Does this answer the question of what your organization should do? Well, no - what it may do is help you figure out for yourself what would work for the organization. After all, its you who has the knowledge of how the business works that is critical in the success of getting any business change in place.

And after all that, what is the activity that both OpenSAMM and BSIMM both consider to be the most important things with developing secure software? 

Pentesting? 

Code review? 

Nope - its having someone who is championing and driving software security within the organization. Having a group of folks who are ready and willing to shepherd and drive through all of the various changes to how the organization works over time. These are sometimes (in BSIMM in particular) referred to as the Software Security Group (SSG), and in many cases can be make or break in getting adoption and use of security initiatives within the organization.

After all of that, it turns out the best thing for software security in your organization may well be you...

Guerilla Security Leadership

Aaaand we're back - bringing you fresh FUDSEC for 2010.

This week it's the turn of Mike Rothman, President of Securosis.  Mike notes that he "hasn't really met too many people he can't piss off, one way or another".  This obviously makes him a natural FUDSEC guest.  Thanks Mike!

It all started when I read Richard Bejtlich's post on Partnerships and Procurement. This was the "I'm sick of it and I'm not going to take it anymore" moment for me. I mean, come on. We spend billions on security, yet we are not any more secure. We have lots of regulations, but that has created a low bar mentality where the objective is to get the stamp - not protect the private information.

And we've had consolidation. Oh, have we had consolidation. The big vendor swallows up the little vendor. Of course, this has happened since the beginning of time and it's a hallmark of every maturing industry. But in our space this constant consolidation has marginalized security. Security gets buried within these huge companies. Sales reps don’t care whether they sell replacement parts for old appliances or security. As long as they hit the number, it doesn't matter.

From an attack standpoint things are bad out there, and getting worse. Or so it seems. That could be the ambulance chasing media — who in a Twitter manic, Facebook checking, 24/7 mentality finds a lot more sexiness in an attack that requires 3 PhD's, a supercomputer, and a roll of duct tape — than in stories that talk about how to solve problems. Part of me wants to just give up. Get all Zen and relent. What will be will be.

But that's not me. I don't give up. I don't back down. I press forward. But where am I going? Where can/should we tell the industry to go? We've got a distinct lack of leadership in security right now. Sure, we have lots of new vendor offerings built to try and address the latest attack (which still requires the multiple PhD's, supercomputer and duct tape) and lots of consultants to charge big bucks to "assess" an organization's security posture.

As an aside, I can save you folks some money. Write in crayon "You're Screwed" on a piece of paper and give it to the CIO. See, you just saved $100,000 and a couple of reams of paper. The findings won't be any different from the high priced consultant's risk assessment. They just figure out a way to say it with 40,000 words and lots of pie charts.

Who is going to lead us? I remember when we had guys like Jim Bidzos making huge pronouncements (like the idiocy of the US encryption export policies) at industry conferences. The keynotes at the RSA Conference were a who's who of the captains of the technology industry.

Now we get the CTO of 3Com and the guy who runs the security business for CA. Bill Gates and John Chambers they are not.

I'm not sitting here saying that we need vendors to lead us to the Promised Land. We do need to believe that all the inventory big vendors have bought over the past 5 years is amounting to something. But that's not going to happen. Sorry. There is no one minding the security store in the big IT shops.

Who is in charge of IBM's security strategy? HP? Cisco? Oracle? Do they have the ear of the CEO? Do they sit in senior staff meetings? Most importantly, can stop a new product or a deal or some other major endeavor because it presents risk to customers? Yeah, probably not.

Where is the next generation rallying cry? What will be this decade's Trustworthy Computing? Microsoft did a great job driving that concept to every part of the business. I'm not holding my breath for the next generation rallying cry.

If the vendors won't lead us, what about the Federal Government? The grand "recommendations" coming after the high profile White House 60-day review were pretty much toilet paper. Actually, that's insulting to toilet paper. I certainly wish the "cyber-coordinator" Howard Schmidt good luck, but he only warranted a photo with the President. Keep in mind they hold ceremonies in the Rose Garden for the Presidential dog groomer.

To be clear, this isn’t about Howard. It’s about a role with no real empowerment for change. I don’t think Ike (yes, random WWII reference) could have been successful as cyber-coordinator. Looks to me like this position will be yet another eunuch sent to the slaughterhouse in a cloud of beltway politics and bureaucracy.

As for end users, the really smart ones are either too busy to tell us what they’re doing, or hamstrung by the same idiot lawyers who think putting a confidentiality notice on the bottom of an email is actually useful.

Let's all agree the vendors aren't going to get us there. The US Government has a bad case of the blind leading the blind. And too many of the end users that will talk have self-promotion syndrome, always angling for their next CISO gig. Sorry Dorothy, there is no Yellow Brick Road.

Wow, that felt good. I’ve been holding in that rant for 15 months and it’s good to finally get it out in the open. But alas, what makes me feel better doesn’t help you do your job better, now does it? So let’s start looking for solutions. What can we do to make some progress against these enormous obstacles?

Look in the mirror. I'm not kidding. The answer is staring back at you. That's right, don't act so surprised.  There is a revolution coming, and it starts with you.

The general problem is that we as an industry keep waiting for someone to bail our ass out of the fire. Yet, real change never happens that way. Real change bubbles up from the bottom and becomes a movement. The movement gathers steam and starts gaining attention, and then the status quo rises up to quell the change. Only through herculean effort does it become accepted practice. All change has to start somewhere and the nature of our jobs as security professionals is changing. To make things better and to survive, we’ll need to change with it.

Security is no longer a technical discipline. Technology plays a role, of course, but the success of your security endeavors has nothing to do with your technical competence. It has to do with your skills at "playing the game." Basically we have to master the art of persuasion. We have to persuade the movers and shakers in our organizations that security is important and that it helps the business.

But how do we do that? Especially given that business folks don't care about security.

Basically, you need to become a guerilla. Security folks have no "shock and awe." We're lucky to have a BB gun. So we've got to fight smart. We have to fly under the radar. We have to use leverage and magnify our impact. And yes, it's possible.

Some may say guerillas don’t fight “fair.” The fact is most of the folks just don’t have the resources to fight any other way. What they do have are some characteristics that wouldn’t be bad to replicate – like agility, resourcefulness, and persistence. They are visible about their successes and they build their attack plans based on intimate details of their situation and surroundings. Can you do that? Can you be a guerilla?

To clarify things a bit more let's outline a 5-step plan to put this into action. And yes, it follows the general approach of the Pragmatic CSO:

1)   Understand the Business - I'm sure some of you have tried to convince senior management you are great at security because of your 99% AV coverage metrics. Or your 1-day patch window. Right, they don't care. You need to relate security TO THE BUSINESS.

Unless you understand your business, you can't understand the leverage points that will appeal to the business leaders. Read your annual report. Understand how your senior team is bounced. Find out who will get fired if a system goes down. Make like J. Edgar Hoover and start assembling "files" outlining the success criteria and leverage points of the influencers in your organization.

2)   Get face time - Persuasion is not something you do via email or in a bi-annual summary meeting with the board. It's something that has to be done consistently. So you have to befriend the movers and shakers. You have to add value to their environment. You built the file, you know what these folks need to accomplish. Now you have to figure out how to apply security techniques to help them reach their goals. Or potentially position security as a way to ensure an outside influence doesn't stop them from meeting their goals.

3)   Get a Quick Win - Once you have their ear, you need to show the goods. This is the testing phase. So maybe you catch an insider in the act. Or you intervene before an application goes live, which could have resulted in a breach. When you are in the heads of the influencers, these kinds of opportunities present themselves. But don't take a long time because influencers have a short attention span. The Quick Win builds credibility, and with credibility you can take a more strategic and structured approach.

4)   Pitch the Program - After proving your mettle in adding value to the influencer’s environment, then you need to sell a more structured approach. Yes, that means they need to get on board with the security program. Explain to the influencers how the security team does stuff and how they consistently add value - but only if they are IN THE LOOP. That's the objective, pure and simple. To have these bigwigs in the organization actually call BEFORE they do something. It doesn't happen overnight, and you'll need to be patient - but with consistent effort it can happen.

5)   Execute Consistently - That's right, don't screw up. Credibility is kind of like good will. You can spend years building it, and it goes bye-bye in the blink of an eye. Think Tiger Woods. So always manage expectations, always follow-up and show results, and also take some time to pat yourself on the back. The Guerilla Security Warrior is not an overnight thing, so if you've gotten to this point - it's quite an accomplishment.

The bad news is some of you will never have a chance at all. Statistically we smart folks (your read FUDSEC, don’t you?) are surrounded by idiots, and many of them are somewhere in senior management. You know, the Peter Principle in action. While you should make your best effort, for your own health it’s important to recognize that some executives in some organizations will never be receptive to improving security no matter how good you are.

If you’re stuck in that situation, you need to decide if you can live with it (I suggest focusing on your family while covering your ass with documentation at work) or if it’s time to polish up the resume. Life’s too short to come home from work angry every day. I should know; I’m a reformed angry guy.

Let me finish up by reminding you the road to hell is paved with good intentions. Words mean nothing (especially given my living comes from writing words), actions mean everything. I come from the school of leading by example. With security, senior executives will not have an epiphany and get religion overnight. Unless a data breach at your organization becomes front-page fodder. Then you'll be looking for your next job anyway. So leadership starts with you. Leadership is built one step at a time, through consistent value-adding action. Get to work.

Are you up to the task of Guerilla Security Warfare?