fudsec.com

Showcasing Fear, Uncertainty and Doubt from the Information Security Industry 

Customer-Induced FUD

We're breaking rank and posting a day early this week.  Why?  To give this post some time to breath before a small gathering in San Francisco of security wonks.  My thanks to Jeremiah for this post, and I fully agree with his call to action!  You?

By Jeremiah Grossman

I’m told fudsec is a place to float, among other things, half-baked and incomplete security ideas. I’ve no shortage of those I assure you. Fortunately the infosec community is not shy about telling you so. For today’s thought let’s provide some background...

A few weeks ago a consultant by the name of Larry Suto published, “Analyzing the Accuracy and Time Costs of Web Application Security Scanners,” [1] which reviewed desktop black box website vulnerability scanners: Acunetix, IBM AppScan, BurpSuitePro, Cenzic Hailstorm, HP WebInspect, NTOSpider, and Qualys WAS (Software-as-a-Service). Larry faced off these products using the vendors’ very own public-demonstration, vulnerability-laden “test websites” as the scan targets. For those curious, WhiteHat Security politely declined to participate because Sentinel is delivered as SaaS solution and not a product like the others tested. [2]

You may read the report yourself, but I’ll save you the suspense. The results for nearly all scanners were basically horrible. Large percentages of vulnerabilities were missed, there were false-positives galore, and significant human configuration time was required. Perhaps these are benefits if you are looking for tools to help fill the gaps in your day and provide job security. Several vendors wasted little time in defending themselves, attacking the report’s methodology and Larry himself, which is presumably to be expected anytime you call someone’s baby ugly.

The conclusion from the vendors: Don’t take these results seriously. For best results, scan real-live production websites, like your own environment, and not test websites.

You know, I can agree with that! I’ve been recommending the same for quite some time. First though, try something a little different. Turn the tables around. Instead of running your websites through the gauntlet, risking downtime from intrusive scans, only to discover you have vulnerabilities just like everyone else -- how about making the vendor eat their own dog food.

Ask the sales rep for a trial license and permission to scan THEIR production commerce website(s). That’s right, scan the vendor! Imagine their FUD-induced response. If they really believe in their product’s capability, safety, and marketing hype this shouldn’t be an unreasonable request. A “right to test” is no more than any reasonable cloud computing client would ask for. Right? Plus, doing so will provide a good reference point for when you scan your own websites, if, in fact, Larry’s results were atypical. The sales rep might say they don’t have authority to grant such authorization. Fair enough, but go ahead and press a little. It’s not like the bad guys are asking permission to scan these sites everyday anyway. Just ask [3] xssed.com [4].


[1] http://ha.ckers.org/blog/20100203/accuracy-and-time-costs-of-web-application-security-scanner-report/
[2] http://jeremiahgrossman.blogspot.com/2010/02/wheres-whitehat-re-scanner-comparisons.html
[3] http://www.xssed.com/search?key=hp.com
[4] http://www.xssed.com/search?key=ibm.com

Loading mentions Retweet

Comments [1]

The Broken Windows Economics of IT Security

What type of vendors are you dealing with?  Type A or B?  

Amrit is back with a post that highlights the link between economics, security and vendors.  Thanks Amrit!

By Amrit Williams [reposted with permission]

To economists, the term “Broken Windows” refers to the question that if a shopkeeper pays a glazier to repair a broken window at his store, does this deliver an economic benefit to society? Many people would say yes, because it generates demand for glass and work for the glazier.

Have you ever been witness to the fury of that solid citizen, James Goodfellow, when his incorrigible son has happened to break a pane of glass? If you have been present at this spectacle, certainly you must also have observed that the onlookers, even if there are as many as thirty of them, seem with one accord to offer the unfortunate owner the selfsame consolation: “It’s an ill wind that blows nobody some good. Such accidents keep industry going. Everybody has to make a living. What would become of the glaziers if no one ever broke a window?

Excerpt from the 1850 essay “That Which is Seen and That Which is Unseen” By Frederic Bastiat 

The majority of economists, however, would say that it is a fallacy to believe that the broken window generates economic good, as it forces the shopkeeper to expend resources to fix something that wasn’t broken and functioned perfectly well before small boys began playing baseball in front of the shop. Paying for repairs reduces his/her business’ ability to spend money on more rewarding alternatives—financing inventory, expanding the shop, etc.

But if, by way of deduction, you conclude, as happens only too often, that it is good to break windows, that it helps to circulate money, that it results in encouraging industry in general, I am obliged to cry out: That will never do! Your theory stops at what is seen. It does not take account of what is not seen.

It is not seen that, since our citizen has spent six francs for one thing, he will not be able to spend them for another. It is not seen that if he had not had a windowpane to replace, he would have replaced, for example, his worn-out shoes or added another book to his library. In brief, he would have put his six francs to some use or other for which he will not now have them.

Society loses the value of objects unnecessarily destroyed, and at this aphorism, which will make the hair of the protectionists stand on end: “To break, to destroy, to dissipate is not to encourage national employment,” or more briefly: “Destruction is not profitable.”
IT security has evolved into a classic broken windows business. It exists to repair things that shouldn’t break in the first place. Furthermore, every dollar that a business spends on Security subtracts a dollar from expenditure on more worthwhile alternatives—product innovation, improved public services, higher salaries, dividends to investors, etc.

Every so often someone gets up and claims that good IT security pays for itself. Nonsense. Every CEO, CIO, and CFO I have ever met resents every dollar they have to spend to protect themselves from the oversights of system architects, software developers, and product designers. They know that IT security is a wound that never heals, and that while they need to be lucky all the time, a hacker needs only to be lucky once to do serious damage to business processes, balance sheet assets, and/or marketplace reputation.

Realistically, IT security is going to remain a significant budget item as far as the eye can see. But I believe two types of security solution vendors have emerged. While they still make up a majority, Type A vendors sell paranoia. They harp endlessly on the mortal threats of thumb drives, social media sites, and satanic plots spawned by hackers of disparaged nations and ethnicities. Shattered windows are their business and they love the sound of breaking glass. Established type A security vendors simply have too much to lose by helping their customers eliminate or reduce the potential for broken windows events and thereby enabling companies to reduce their IT security budgets.

Type B vendors recognize the market opportunity to help customers reduce the cost and complexity of IT security. Make no mistake. Profit motivates Type B vendors every bit as much as Type A counterparts. It’s just that they mix some enlightenment with their self-interest. Type B vendors are the ones advocating ways to efficiently minimize target surfaces, radically change their security programs, and perform mundane but necessary system management processes as thoroughly and friction-free as possible.

While generalizations are slippery, such vendors will always be in the minority and tend to be the innovative upstarts of the industry. They are not part of the PCI collective, they find it difficult to swim against the rising tide of broken glass marketing, they offer viable alternatives to the current <glass breaks – repair glass – add more glass – glass breaks – repeat> cycle the IT security industry has created.

As I write, the RSA Conference is getting ready to open soon in San Francisco. Hundreds of vendors will convene to spend millions of dollars to convince public and private sector managers to continue to spend billions of dollars on various IT security widgets, left-handed monkey wrenches, and foo foo dust. They will do their best to drown out voices that say it doesn’t have to be this way that there are viable alternatives to the never-ending IT security hamster wheel of pain. What a waste.

Loading mentions Retweet

Comments [2]

Casual Hex and the Failure of Security Awareness Training

This week I'm pleased to announce that this weeks guest haxxor, Larry Pesce from PaulDotCom, was able to extract himself from the Matrix for this post.  This is all the more remarkable when you consider the availability of free beer within the matrix (Larry, I'll buy you a beer the day we meet, so long as you promise not to Shmooball me).  My thanks to Larry!  Please leave your comments below...

by Larry Pesce

I've been preaching education for end users for quite some time, knowing that having educated users would help them from getting owned, either at home or at work.

I'm beginning to think that user education is a losing battle.

We've preached to our users about safe internet practices. We tell them to examine SSL certificates. We tell them not to open e-mail attachments from people that they were not expecting.

What do they do? Exactly the opposite of what we say. Why? Human nature I suppose. In 99% of the cases the users we are supporting are not what you call tech savvy. Sure they can set the clock on their VCR nowadays, but they don't know how to use the computer to do much more than the job at hand. They just want that new piece of technology (computer or otherwise) to work. They want to get their job done, communicate with their friends or do something cool.

When we do convince them to click "NO", and it doesn't work or do something cool, they try again and click "YES". Nothing Advanced or terribly Persistent about it. Yes, it is still a threat.

So why doesn't user education work? No matter how many seminars we give, pamphlets we distribute, or posters we hang quite frankly our users don't care.

I used to think that if the education worked for just one person in an organization it was all worth it. The problem is that all of that education is a lot of work to develop and deliver to reach one person out of fifty. With persistent education, maybe we will get three out of those fifty. Scale that up a bit and those aren't very good odds in helping protecting your organization.

Let's draw a parallel to the recent compromises at Google. Not having worked there, I have to make some assumptions about the skill level and caring of the staff there. One has to figure that most of the employees are pretty technical and get the risk. They, for the most part don't need the user education. The problem is there are a whole bunch of people that help that business run that aren't techies. That's who get owned. I'd imagine that Google has a pretty darned good internal user education program. They still got owned.

So, how do we save the users from themselves? Maybe this whole internet fad is out of hand. We can spend metric assloads of money on security technology and the people to appropriately staff them. Or we can change the way people thing about the internet in general in a work environment. Instead of the user education for everyone connected to the internet at the office, how about we make the use of the internet a privilege, not an inalienable right.

Now the user education for the few people in the organization that actually do have access to the internet will hopefully have a little more punch, potentially reduce our costs on some security technology and staffing, as well as potentially changing our overall security posture.

Best of luck on whichever direction you choose. It is just a matter of time before we're all compromised no matter what we do.

Loading mentions Retweet

Comments [8]

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.

Loading mentions Retweet

Comments [0]

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!

By Justin Clarke

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...

Loading mentions Retweet

Comments [7]

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!

By Mike Rothman

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?

 

Loading mentions Retweet

Comments [2]

FUD and Other Sales Errors

Security product testing criteria have always struck me as quite odd.  Why *just* focus on the product or even the vendor financials?  I mean, the product is wrapped up in a sales cycle, a marketing program and sometimes, an entire belief system.  Then there is the on-going relationship...

Vince Tuesday has been around the block.  He's heard what you have to say my dear vendor.  He knows your script, in fact, he's probably reading ahead.  The sad truth is you already lost his attention 5 minutes into your sales pitch.  He did briefly perk up as you enthusiastically sprayed your enthusiasm towards him - but this was merely to avoid getting his suit wet.  As you posture to impress him, he's figuring out whether to eat the left over Chinese food for lunch or go down the pub.  He's already decided if he's going to take you up on your offer of lunch.  Sharing food does not mean you are any closer to a deal.  It merely means he is more likely to fall asleep when you insist on using up more of his precious time by ordering desert as a tactic to "keep him in play".

Vince makes purchasing decisions that sales people would die for.  But to get to the sale, the path is narrow...and winding as you'll see below.  Thanks Vince - I owe you a beer!

By Vince Tuesday

I am a security manager with a secret identity, Vince Tuesday. He comes out when I have things to say that it would be inappropriate under my work identity. You may also know him as a 2003 East Coast Region ASBPE Silver award winner for “The Strange Case of the Phantom Intruder”, no? You surprise me. When KingCloud (as I like to call Craig) approached me about FUD I dithered but the promise of international fame and fortune was hard to resist, so I’d like to talk to you today about more than just FUD (although FUD will be a part of it). I’m going to do a top ten of “Things I never want to hear from my vendor”. It may be when I get into the flow I go beyond 10…

  1. "You can write your own templates/scripting language"

  2. Not only great for your professional sales organisation but I also can extend my vendor lock to you in by forcing all my team to learn your stupid re-invention of perl/bash and better yet you can hide behind the fact that you haven’t incorporated decent features by claiming I can add my own. I can even pay extra for training from you – so be sure to change the scripts on a regular basis so you can make that a recurring revenue stream. Also, when you release the new version of the product then make sure my scripts stop working and don’t dare give me things like import/export and change control.

  3. “We wrote our own crypto”

  4. Sure, you did an MSc from some European country, maybe you even read “Applied Crypto”, you might even own the Brucie action figure – what could possibly go wrong? I’m sure there is no reason that the solution to every software problem from a security point of view (see Gunnar Peterson’s excellent critique) is Network Firewall and SSL. Why would we like SSL? – sure it has problems but they get fixed. Your own implementation is never going to have any problems and even better if there was then you’ll never know and never fix them – less patches, love it! Better yet are those security products that don’t even include authentication or confidentiality in their own connections and therefore add security risk to the environment. That kind of stuff is just hard to configure and adds overhead, doesn’t it? No better way to convince me your security tool is a must have if it lacks any security over the features it offers.

  5. “Sorry, We forgot to encrypt the laptop”

  6. Along with not bothering to embed security features in your security product it is even better when security vendors and consultancies don’t take security seriously in their work and own infrastructure. I’ve found vendors with my staff and clients’ personal data stored in their environment without full disk encryption on their laptops and thank goodness – no pesky keys to protect if you don’t bother to encrypt. Also it would be a waste of time to have some modicum of physical security for your office and your data centres – you’ve a mission to spread the knowledge of your product to the world so what better way than having my data stolen and published? It’s like cheap advertising, no?

  7. “We have a great console”

  8. When start-ups build in their environment they make a nice whizzy front end that they use for a few minutes on a local network link to the back-end and with a small set of test data from a few end point systems. In our enterprise environments we have WAN links between desktops and backend, sometimes over satellite from remote areas, we have hundreds of admins, 100ks of endpoints and terabytes of data flowing through our systems. We also have hundreds of security systems to integrate and limited analyst time in the SOC. So I’m dying for a new front end that I can’t integrate with my existing management framework and toolset – then I’d never see your badly rendered pie charts that I can’t cut and paste into my other reports.

  9. “The front-end is web based”

  10. Oh great, slow Java pages that don’t load and work properly on the ancient version of IE we get on our desktops. Lovely,

  11. “The front-end is thick client”

  12. Oh great, a patching and update nightmare that also means I get some painful licensing and DR site version errors and have to pay extra to get the client packaged and deployed. I’m an easy customer to make happy, aren’t I?

  13. “It's in the cloud”

  14. Thank goodness because if you hadn’t mentioned cloud I might have forgotten it is 2009. Either you are using this as a marketing buzz word in which case well done for firmly sitting on that bandwagon or you are not building out your own data centre so you can respond to demands of growth – you’re probably using mains electricity and have an office near public transit – why not include that in your sales pitch as well?

  15. “It has an alerting tool for the desktop”

  16. If I thought having a management client for my desktop wasn’t enough of a thrill ride then I definitely want an alerting system –something proprietary and heavyweight or extremely configurable like a hard coded email address (and just one, why waste time supporting multiple addresses?) in every end point for where the alerts are forwarded. Don’t worry about throttling or summary – I love getting 9000 emails/minute when your system has a hiccup as it provides a useful replacement for your failure to include a heartbeat in the communications protocols.

  17. It works via "secret sauce" or "magic"

  18. That reassures me that they don’t waste valuable time and money training pre-sales staff to actually understand or be able to communicate the details of the product. Why would I want that? If you did that and your sales team had integrity you might actually tell me when the product wasn’t a good fit rather than sell me any old nonsense and then were would your IPO be?

  19. "The next version will support that."

  20. Good, let me give you my money for all the things it doesn’t do, in fact why not show me the same 5 year roadmap for 2 years running but just slip the start date each time, that convinces me to invest exactly as much in your product as you are and saves you time and thinking bothering with a decent plan.

  21. "Dave at XXX is one of our reference sites"

  22. Wicked, when I do buy your product then I’m going to be keen to be a reference site – to feed my own ego and try to convince more suckers to deploy it so I look like a visionary (call it twisted skin in the game) so I enjoy knowing that you bandy your highly confidential client contact details to entirely un-validated prospects.

  23. "Here is a picture of our head office"

  24. I bet your VCs loved having this in their pitch, and it certainly makes exactly as much sense to show me the picture of the outside of a managed office in a business park. You may be very proud of your move out of your carport or your ability to search on google images but with only 20 slides you’ll definitely not get closer to a close if you tell me about the product so better to show me stuff I just don’t care about but that looks pretty.

  25. "Here are our key clients and customers.”

  26. I love a page of badly cut'n'paste logos, mostly at web quality dpi so they look ugly and old versions that break brand guidelines as much as anyone. A particular pleasure is when people pitch with our own logo on the page, sure we are a big company but you’ve got to be gutsy to attempt to get us to pay for your licenses twice – let’s face it, if I’m going to buy it’s all going to be because you spent a long time on the graphic design and look and feel of that page, isn’t it?

  27. "It has no CPU impact"

  28. It’s great to come with a hardware upgrade but isn’t that going to be expensive to deploy, oh hang on, what you are really saying is “we don’t bother doing stress tests in a range of circumstances to be able to give you meaningful capacity planning information as you might realise it’s a bloated pile of crap that doesn’t scale beyond 5 users if we published anything like that”. I agree the other wording is better.

  29. "It automatically updates"

  30. Great, I do enjoy troubleshooting problems on a Monday mid-morning at peak business hours because all your agents decided to use some insane Hawaiian time zone to schedule their updates. And change control is for companies who don’t really bother with availability, isn’t it?

  31. "It doesn't automatically update"

  32. Marvellous, I do love a steadily increasing TCO based on dedicated teams of people packaging, and deploying new versions containing features I don’t want but some big prospect in Japan wanted. For bonus points make sure old agents don’t work with new central servers so I have to do a big bang high risk upgrade or add gaps in coverage if I want up to date versions. Also great to have updates work only from scratch so I have to uninstall the old version and install from scratch so I can lose all my configuration and customisation work each time

  33. “No, I don’t think it is covered by any export restrictions”

  34. Yes, I’m certain your intuitive grasp of State Department rules and regulations is spot on because they are instinctive and clear and spending any time or money understanding them and making your product workable isn’t going to be helpful to a global buyer.

  35. “Let me do a demo…I just need unfiltered, broadband connectivity right now”

  36. Absolutely, I’m going to allow you to connect your ropey laptop to my corporate network and thanks for not bothering to tell me so I could have got you a wifi guest login or god forbid you bother to set up a WebEx demo or bring a 3g card rather than make it my problem for you to be able to do the demo.

  37. "It's common criteria/ITSec certified"

  38. Spiffy, I do enjoy it when you meet some outdated self-defined model rather than actual business needs. Also good to spend your limited funds with certification agencies to chase a government market rather than add features and improve the product. Even better for you to have a strong incentive not to issue substantial security updates to your product because they would invalidate your certification.

  39. "It can log everything"

  40. Just make sure you do it in your own proprietary format and ensure all the logging is done locally, we all need to drive a bigger security market so everyone needs to do their bit for log aggregation tools. Also make it so you spread alerts over several lines and change the headers of your data layout between versions. I don’t have any desire to automate this stuff, my SOC teams can’t get enough of this as it really uses their skills in the right way..

  41. "It has a very granular access control database so you can control exactly which menu items each user can see"

  42. Brilliant, more professional services, I can see your IPO going better and better, I am visionary to have selected your product, just make sure you don’t add any sensible roles so everyone gets to be admin under a shared account. And as a large enterprise I don’t have enough different stores of user credentials so don’t integrate with any of them. I want a whole new username and password and a system of groups. Who wants all their eggs in one basket?

  43. "It scales without limit"

  44. I’m glad the laws of physics and 60 years of IT experience don’t apply to your product. Clearly you tested it on 1, 2 and 3 users so by proof by induction means it scales without limit and make sure you confuse “XXX company was stupid enough to buy a 100,000 user license that now sits on a shelf” with “XXX company has 100,000 users using it”.

  45. "Company X has tested it and found no security holes"

  46. You paid someone to say it was brilliant, and they did. That _was_ money well spent. There is nothing as independent as paying someone to say you are lovely, might I suggest you get your mother to test it next time as she’ll be cheaper and I bet she thinks it is really secure as well. Even better if you save money by picking a name of someone I’ve never heard of or go for a big name but a very limited scope so it comes with so many caveats that the testing is worthless.

  47. "We ran a contest to show it was hack proof"

  48. Even better if you make the prize be a pile of gold or don’t pay the people who win the contest. I like your gutsy approach of either a) nobody breaks in as organised crime thinks it can get more out of exploiting your product in live or b) some script kiddie owns you entirely and then you have to whine on about how they didn’t follow the rules – because attackers are always following the rules!

  49. "It solves/prevents problem X"

  50. Yep, you are actually selling a combined magic beans/silver bullet that will also make coffee. Nothing convinces me you are a well researched and sensible sales organisation as when you convince me it will solve a problem it can’t. PGP ran some great ads about how important full disk encryption at border crossings was after customs accessed data on disks. The fact the customs agents have the legal right to demand the keys doesn’t make that advert bizarre at all. A nice 20/20 hindsight variety is "If only so-and-so had had it then <big bad thing> wouldn't have happened!"

  51. "It fixes HIPAA/Sox/BASEL II"

  52. All the better if I’m not in healthcare/listed company/regulatory capital regime. And won’t it be great for me to look down my nose at those companies hiring hundreds or thousands of compliance staff and running holistic programmes across technology and the business when all I needed to do is buy your one niche security product – cost saving!

  53. "It's much better than product Y"

  54. I love it when you competition bash because clearly you have many great bits of your product if you use your time trash talking other products. Nothing adds to your credibility if you used to work for product Y company and only a few weeks ago were trying to sell that to me.

  55. "Do you like Golf?"

  56. Now we are stepping towards the inducement and bribe approach to selling product, nice. It’s not like I’m well paid and successful so a day of golf is more than enough to make me change my mind and risk my integrity and job. I was going to make a joke about a certain company here but I actually don’t even want to risk my integrity and job for a joke.

  57. "Vince, Vince, blah, Vince"/ NLP

  58. It is true that people who trust each other use their first names more frequently in conversation, however you’ve delightfully confused symptom with root cause and I love your cargo cult-style approach of repeating the symptoms in the hope of reaching the cause. Add a little mirroring of my body language and we’ll build so much rapport that I’ll pile my entire budget into your in-tray.

  59. What is your no. 30? Add it in the comments below.

Loading mentions Retweet

Comments [6]

FUD Just Feels Right

When you need to get things "in", "on time"...what tactics do you employ and where did they come from?  When you present to decision makers, how do you frame your request for the pot of gold?

I came across Ewout a few years back on a course in preparation for a popular certification.  He'd paid for it himself and consequently he was getting stuck in, challenging some of the not-so-great material on the course (in a blunt, yet respectful way).  Initially, I rolled my eyes - "this course will never finish" I thought.  Anyway, a few coffee break discussions later and I was joining in.  We somehow managed to suspend our Infosec belief system just enough to convince the people reviewing our test papers that we "got their religion".  Anyway, we've been good friends ever since.  it gives me great pleasure to share a "Mokum joint" with you.  Thanks Ewout!

FUD Just Feels Right [Or how the FUD card was created by the end user and since we couldn't beat them, we joined them.]

By Ewout Meij



My first assignment as a coder, done while still a teen in a programming language that was already old by then, was to decipher barcodes stuck on carts entering and leaving the company's delivery platform to keep inventory of said carts. There was just one single user of the application. All he had to do was check the inventory and enter a cart number by hand if it had bypassed the scanners somehow without being registered.

The reading of the serial data was simple, the requested totals where even simpler. What took me three weeks to complete was the user interface.

Since 'my office' [think of an empty box floating in a giant hall, formerly used as storage for… crap] was right above the work floor I just had to jump down to show my latest incarnation of the interface and get feedback from my user. This proved more cumbersome then I ever imagined. I am not a certified Asperger unlike most of my buddies, but dealing with the ever changing requirements and wish list of my sole user grounded my productivity to a halt.

Bigger letters, larger numbers, less options ["Maximal 2 and not 3 items in the list please"], an amber not green monochrome screen, a clicking keyboard with larger keys: the requests for changes where endless and I would respect each and every one of them. The customer was my senior in age, like 3 times, on IT-literacy I was his to the third power.

One day my boss [there were no managers at the time, they were bosses and owned your ass 120 hours a week if they so pleased] walks in, asks me with a smug smile about the progress of the juniors' assignment and I told him about the logic being up and running for weeks, but the interface issues I was having.

Long story short: next day there was a 16 year old behind the amber screen with one of the first incarnations of my application front end.

This introduction to the awesome powers of the IT wizard shocked me, for all I had faced until that moment was the magic of turning human readable code into pure binary. What I liked so much about hacking for fun and profit was the fact that the box would do exactly what I did, mistakes and surprises included. The spill over from the confined, well-known, trusted, reliable, "turn on and off-able" world to real life was unprecedented and unforeseen.

Loads of water under the bridge since, but what has actually changed?

I dropped the “security” part as description of what I do as I got bored with explaining the exclusivity, availability & integrity trinity, now I call my current role “site reliability engineer” as it better fits the underlying desire of the companies I work for. It boils down to the same old, same old, but it gives me a nice platform to reiterate the importance of all aspects and not just focus on the exclusivity aspect. As a freelancer I face a plethora of issues, companies & people. 9 out of 10 times the intake conversation goes something like "We have an issue with product X and need you to solve it. Get it done!" What happens next is that for a couple of hours, days or weeks even, I'll be given a guided tour through the organization and try to get acquainted with the problem at hand. Very soon the nice technical issue will turn out to be of an inter-departmental process challenge more than anything else. Long time operator|department X|Y|Z will not accept change A|B|C and thus resorts to pure guerrilla tactics, added with a splice of artillery, to prevent change A|B|C to be successfully implemented.

The tricks are basically the same: make it take too long, come up with endless prerequisites, show another far away department's form does not fit the new requirements or call in sick 'at the right' moment.

Here is where not 'we', but the 'user' is playing the FUD card. They've done this since day one, and we are so accustomed to the procedure and its inherent effectiveness that there was no other option than to use it too. But does it work as well?

As a reliability professional part of our job is to come up with metrics for FUD. We show tons of events being generated and… forgotten about. We show intriguing scans of systems, clever IP ranges & routes. We come up with 'simple' solutions to stop XSS, buffer overflows, DOS and try to make the decision makers listen and pay for what we come up with. Multiple Internet gateways, DMZs, proxies, scanners, redundant paths, enforced paths, black hole routers, IDS, firewalls, end point isolation, private IP space and duty segregation. I have done presentations, enthusiastically explaining 'man in the browser' attacks against a particular bank to people so alienated from society, they had a stylist visit me a couple of days before the planned presentation to make sure I looked the professional they expected to see.

With all the tools & smart tricks that we have at our disposal it is of no surprise that a frequently asked question is: "If we let you do this, when will you be here again asking for more?" The famous "Security is not a project, but a state of mind" line does not cut it in that case. It feels like you're asking for a blank check, something not too many BODs are happy to hand out to people who do not have a handicap in golf.

In situations like these only the money oriented approach will swing the doubters over. Get a couple of 'verifiable metrics', divide & multiply, pinch in some climate-gate trickery and show the result to be positive in one form or another. But will it make your customer safer in the real world?

For each and every hurdle we put in place, a de-tour will be found. Example? We have been issuing identification papers for 100's of years and make them more and more fraud resistant. What does Mr. Foo do? He hacks the issuing process.

FUD is something we all use, abuse and understand and it is a Good Thing[™] as long as it motivates action and does not lead to submission.

Loading mentions Retweet

Comments [0]

Liberate Yourself: Change The Game To Suit Your Needs

I'm very pleased to have Rocky as this weeks "Fudsec Friday" guest.  I've had the pleasure of meeting Rocky in a business context.  I quickly came to appreciate he is one of the minority: an information security professional providing true insight and solutions based on real world experience of what works.  To put it simply, Rocky "gets it".  If you read just one blog post today, read this one.  Thanks Rocky!

By Rocky DeStefano

Recently, I was fortunate enough to have the opportunity to listen in on a speech from General Hayden (former Director of the NSA and CIA, in addition to his service as a four star general in the US Air Force).  This man has executed at a level most of use only see through fiction writers and movies and he has done so for 30 + years.  I provide that backdrop only to say that when General Hayden speaks, I not only listen, I listen intently and replay his words and overall sentiment in my head very carefully.  What he said at this event was encapsulated very well by Richard Bejtlich in this blog post so I won’t go into all the areas described in this post.  In short, General Hayden’s speech sparked some long-dormant thought in my feeble brain.  His thoughts energized me to refocus my thoughts and actions to go beyond the day-to-day struggles we constantly fight.  I was stuck in a rut and didn’t even realize it.

In order to navigate our world and interact with it and one another, we as humans had to learn to fly, we had to learn to navigate the oceans, and we had to learn to overcome distances and difficult terrain, by creating solutions to work with the landscape.   We’ve done something quite unique though, we created a new terrain and new domain.  The domain we’ve created is fundamentally different while at the same time it is every bit as tangible as the natural domains we exist in.  The difference is that this information domain is of human ingenuity and therefore in addition to building tools to work within the landscape, we can actually alter the landscape as we see it.  This information domain also exists separately as its own entity and as such evolves at a rate much different than the physical domains.  Perhaps most importantly this information domain evolves, dies or otherwise is influenced based on our human interactions.  It is moldable.  Sure I can agree that humans might affect the temperature of the planet every few thousand years by a fraction of a degree, but we can fundamentally change our information domain on a daily basis if we chose to.   Think about it, we all know that, it isn’t new, but at the same time it’s quite liberating to think about the fact that we can change the entire game to suit our needs, versus playing by rules we can’t change or worse yet play in an environment that highlights the strengths of our adversary.

As this domain has evolved we have set in motion a series of evolutionary steps based on tactical requirements without really having a strategic plan for where it should be headed.  We made decisions along the way that were necessary to get us past a hurdle, but without much rational thought about the impact.  To put it simply there is no city planning going on.  We’re continually developing “solutions” to meet short term needs.  Granted these are real needs, no question, but who is providing the strategic vision of how our decisions will affect how we interact in the future?  For far too long we have applied “fixes” that fit the bounds of the information domain as it exists today.  It is time to start looking at how we can transform the domain itself to more appropriately suit our needs moving forward.  I’m convinced we are in the very earliest of stages in the evolution (perhaps on the doorstep of revolution) with regard to this domain, but unlike evolution on the natural plain this domain can’t and won’t change itself, we must act to influence it to better meet our needs.

Much to my own amusement I see this domain much like a scene from a kids movie - when Jafar turns is transformed into genie in Disney’s Aladdin and he boasts something like “The Power, The absolute Power, The universe is mine to command, to control, to create” and we get it without the constraint of living in a bottle.  The constraints that apply only exist in our minds and actions.  We need to get out of the mindset of applying protection techniques based on physical realms and focus on evolving the entire environment to better suit our needs moving forward.

I’m certain as we start this dialogue that more fundamental aspects will arise – which is exactly what I hope to elicit from this dialogue but here his where my current thought process has lead me to consider with regards to how to step out of our box and move our eyes towards the horizon.  I’ve bundled my thoughts into a few categories, leadership, research and information sharing.   I’m sure your thoughts will help us all to refine this into much more!

LeadershipI’ve come to realize that there is no one coming to save us from ourselves here.  No government czar, compliance initiative, nor vendor product suite is going to pave the way.   Homeland Security, NSA, Military, Congress, The White House – they’ll all continue to play their part, but let’s be honest here they have not and should not drive the overall thought process here.  We must all define how we chose to exist in this domain.

Certainly we should encourage government and legal involvement along the way so that they can contribute as appropriate.  In the end the government should be involved to enable us to succeed in this domain, not to define how it should be crafted – at least not without our agreement.  Yet we wait the announcement of the all mighty czar… it’s crazy.  I believe that we can lead from right here, wherever here happens to be.  There are dozens of examples, but I chose just a few to highlight some of the decisions we’ve made and how we can start making better ones moving forward.

1. Information Security Leadership.
  We need to start pushing back at all levels here.  It’s my opinion that business’s need to care much less about being compliant and more about being fundamentally secure – or if you prefer having better visibility into real risk.  Risk to the mission, risk to the business not the risk to an asset.  We continue to create irrelevant measurements – irrelevant because they are point in time, against a less-than secure model and on a playing field that is skewed towards the success of our adversary. 

As information security professionals how on earth did we let the primary financial driver for security spending be compliance initiatives?  We sold our souls because we lacked the knowledge of the business and how to apply what we do in a meaningful way to the business.  We let compliance initiatives that promised “measurable” results have their way because we thought we could tag along for the ride and implement best possible solutions given the situation. As I see it we are no better off for this and now our teams have either competing agendas or more work to drive us away from protecting our organizations. Sure we’ve created some “building codes” but do “point in time” snapshots matter anymore when the attacker can mold his approach on a whim?

Partners, Vendors play a critical role in helping us reach our goals; they should also play a role in the thought leadership moving forward. Product and solution vendors have done a great job in developing solutions to meet our defined needs along the way as we’ve evolved in our usage of information systems.  We’ve all witnessed some seriously cool steps forward over the last 15-20 years, but recently many of those solutions have been evolutionary in nature, not necessarily innovative, but more and more they are band-aid fixes for problems we’ve encountered or realized.  

Don’t get me wrong it is a very necessary evolution, but we’ve hit a point that we need to start thinking about long-term health and welfare of how we interact as humans.  We need to find ways to encourage that vendor thought leadership onto a larger more strategic problem-set.  I would encourage those customer facing people with consulting and/or vendor organizations to take a very basic consultative approach on a daily basis: listen to your customer’s actual needs, not always what they state as a need (PCI Compliance, etc) but to the goals they are really trying to solve and communicate those findings inwardly to your organization (and in general terms externally to the community).  The more inputs for this information stream the more refined the thought process can be.  You can’t imagine the amount of information that some of these folks have in their heads they just haven’t been heard appropriately.   

To those that manage consultants - please encourage your staff to listen and enable meaningful communications, in fact I would challenge you to incentive your staff to provide this input.  Give them the opportunity to buy in to more than just a single technology, but into solving a much greater problem.  This may mean some major internal change in thought about how to approach management of teams, customer engagements, support, product development, etc – that’s exactly the point – we need to learn to listen better to the larger picture and not the point in time snapshot.   

Those were two very basic examples of how we can lead from wherever we sit in the organization there are literally thousands of other examples out there.   I hope you can see that I’m suggesting leadership by example – you can still enable business using these techniques, you just have to get past “the way its been done”. 

2. A key component in moving forward has to be a dedicated focus on Research and Development.  I mean significant investment in R&D on a national and international scale, information sharing about current and proposed strategies across industries, etc.  We need to be pushing our employers, VC’s, governments into broader research initiatives.  We need an innovation revolution at this point, not just evolutionary point solutions. 

There are some very recent initiatives that show promise, like the announcements by Northrop Grumman that NG is sponsoring information research in conjunction with Carnegie Mellon, The Massachusetts Institute of Technology and Purdue University.

If you will, think of these research opportunities as form of health care for our future, I don’t care how it’s justified but we need to act in support of efforts like this in every way we can, perhaps by offering state or federal tax credits?  Certainly I can agree that we need to watch spending and as such we should have to pay for performance, but we need to encourage strategic innovation versus tactical evolution (band-aids).  The investment in long-term strategy has been anemic at the federal level.  We’ll spend millions on watching the effect of gnat bites on mouse nuts, but we haven’t found the necessary stomach to pay for the ability to effectively comprehend where we’re headed as a species as it relates to communications, business and everyday life. 

3. Perhaps the most immediate thing we can influence is better Information Sharing.  We need to start thinking about how we can change the IT Domain into something that allows for a level playing field.   The old adage “The enemy of my enemy is my friend” applies very well here.  It’s ridiculous to think that our teams are better off not talking with industry competition about defensive strategies. The other side is free to share, adapt and overcome as they see fit, yet we tie our own hands and ask for beatings – and hope they don’t hurt too much.  I’m really not into S&M.  I’d rather retake control – how about you?

A few good examples to learn from already exist, the Defense Industrial Base (DIB) has an information sharing related to APT (Advanced Persistent Threat) detection profiles, and workshops like SANS “What Works” or IANS Summits are a great beginning to this conversation,  but in reality they are very limited in reach and only relevant at a point in time.  We need to develop more daily interaction at a deeper level.

Summary:  I’m in no way suggesting I’m intelligent enough to have all the answers, or to have even fully described the problems, I’m simply stating that we need to elevate our thinking and we must invest in the thought process and commit to the information sharing required to make the decisions necessary so that we may shape our own destiny.  As I see it we must all act on the relevant fronts (Leadership, Research, Information Sharing, others?) to better comprehend the changes and position ourselves to be able to make the changes necessary in the future.  That’s my starting point, how will you enhance the conversation?
 
Disclaimer:
The opinions expressed here are my personal opinions. My views and opinions are subject to change based on the input I consume and the analysis I apply to those inputs.  Content published here is neither read nor approved in advance by my employer and does not necessarily reflect the views and opinions of my employer. 

Loading mentions Retweet

Comments [4]

Reloading Risk Back Onto The Utilities

I'm delighted to welcome back Nick Selby, now Managing Director of Trident Risk Management, for a special fudsec Thanksgiving edition.  Thanks Nick!

Update 30th November: modified text at request of Nick re: mitigation to avoid distracting from the main point of the post - Ed

By Nick Selby

The critical infrastructure security debate has reached, well, a critical juncture. However in the United States, the debate has been limited to either more government regulation or proactive mitigation on the part of private utilities. Since I write from America on the day we Americans give thanks for that which founded our country and made it great, let's attack this issue from a third front.

Let's get the customers pissed off, so that they vote with their wallets.

Because the US' infrastructure is mainly privately owned, the only way utilities will upgrade or properly configure their systems is under pressure of market demand for it. If the US business community, armed with the understanding of the risk of utility interruption to their enterprises, demands better service - that is, they demand that their businesses are better protected by those they pay to provide them with power - then the utility markets that are the most competitive will become the safest.

There's a strong business case here: many exploits of the vulnerabilities in our electrical power grid cost little to mount and cost a lot to remediate. As security researchers, practitioners and thought leaders, we can articulate a business case to American business leaders:

  • You're being forced to accept risk. Utilities are offloading risk of an outage to their customers, by charging for power and reliability and not mitigating even obvious, well-known risks;
  • The risks are to your people, your property and your profits - that is, they are to your brand. If your business relies on power for mission-critical or safety processes, the failure on the part of utilities to remediate means your customers and your brand are at risk - on the terms of the utilities, not your business' risk managers or your shareholders;
  • Cleaning up after the risk becomes reality is a hidden tax on your business and on you. The consequence management aspect of a loss of the power grid of even 20 minutes are massively high in terms of life, safety, profits and our national sense of well-being and safety. By not remediating these risks, utilities are offloading to us taxpayers the cost of clean-up and restoration after a catastrophic failure.

With respect to the last point, I seem to recall us fighting a war over taxation without representation. I submit that this is another one. I know that some utilities will be mad at me for saying this, but as far as I can tell, they've had their chance to take action. Now it's our turn.

Some high-level context
This may be stating the obvious, but what's obvious to people who look at this problem a lot is not obvious to people who don't.

For years, public and private security researchers have been pointing out that the networks at electric utilities were reliant on the thinnest veneer of security - if that. This was not because utilities didn't care, it was because utilities built themselves for the functionality of production of electricity in an age when their networks were truly air-gapped - that is, they were physically separated from the Internet.

To further state the obvious, one big problem is that these networks haven't been truly air-gapped for years and years, but the utilities continue to behave as if they are. And there's a great deal of reliance on plain old security-through-obscurity.

The government can make recommendations and even some regulations, but at the end of the day, and here's another obvious statement, the reason the majority of electric utilities in this country haven't upgraded their security is because doing so is expensive and there's not been any publicly released information about a compelling reason to spend the money.

Hacks or DOH! - Cause Is Less Important Than The Impact
Whether a successful attack on a US utility has happened already, it will happen (not for nothing, but there are active investigations of such attacks underway now). Regardless of the cause, bringing down power networks has life-and-death consequences. Security professionals sometimes forget the 'A' part of the CIA triad (of confidentiality, integrity and availability).

I wrote recently that in 2008 an ice storm blacked out much of my county for eight days - my family spent eight days with sub-zero temperatures and no water, heat (except my woodstove) or even telephone. Life changed dramatically for us, very fast. It is, being obvious again, very important that we safeguard against attack or misconfiguration or any other event that brings down the power grid.

In a recent post on Errata Security, Robert Graham rightly pointed out two important things:

As a pen-tester, I know that our power grid is insecure...I know I can hack in from the Internet and cause power outages. However, government regulation isn't the answer.

Not only has government regulation not been the answer, but private industry has ignored, largely, government initiatives of exactly the kind I would expect would resonate with the security community and the public at large. In many cases, the guidance is specific, limited in scope to what is necessary, driven by expert analysis and input from leaders in security research, vendors, private and public employees and regulators; in short, it's the findings that come after Mr Smith went to Washington.

And still, it's pulling teeth.

A Good Example: Aurora
A perfect example is the Aurora vulnerability (See the Power Point here, page 8, for more), because it has been public knowledge for about two years, the cause is understood and the mitigation is straightforward and well-understood. There's so much great published research and congressional testimony on the problem and its solution that I cannot believe that there has been such low takeup in doing that.

In just two days of scouring open source, unclassified documents I was able to put together a basic mitigation strategy sheet (and to scare the crap out of myself about how easy and inexpensive it would be to mount an Aurora attack). Yet, anecdotally, it seems that only a really small percentage of substations have been protected against this well-known vulnerability. By the way, I don't charge customers to see this remediation sheet.

What Is To Be Done?
After consulting with a number of people in and out of governments, I've decided that the best way to use this information is, at no charge to them, telling businesses which depend for mission critical processes on the public power grid. The at-no-cost part is important to me, because I believe that this is an issue too important not to share.

It's my hope that in sharing this information, outlining the issues and explaining to business leaders how they can and should raise them with their utilities, the utilities will see that there is in fact customer demand for mitigation, and come at this from the market side.

I had asked for a debate and a discussion, so here's my contribution: I'm suggesting all pen-testers and consultants who've looked at this to get vocal - find something within the field that raises your level of concern, something that can be mitigated rather easily.

Then, as opposed to trying to monetize that knowledge directly, help your customers articulate concern in a way that matters to the private utilities: "We, your paying customers, find this to be a risk that you should mitigate. Please do so." We should also help the utilities find federal money to contribute to their effort to help mitigate these risks. Hell, if they're going to throw all that money around on "infrastructure" projects let's at least get some in this area - the government has made it clear that it would like to.

If many of us who have the ear of the customer and the knowledge of the issues do this in a constructive way, we can go a long way to raising the bar. In the end, the real questions remain,

  • How hard is it to exploit vulnerabilities in our system?
  • How can we make it harder?
  • What help is there for private industry to raise its bar?

Many have said that action is not that important, because "no attacks have happened yet on American soil." Arguments about whether attacks have happened are for another forum, but if your main argument against mitigation is justifying the cost with evidence of an attack, I'll ask you this question:

What is the cost of wrong?

Loading mentions Retweet

Comments [3]