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