RFI's are a PITA

Because I’m  old and  in the way, I’ve been in the business since 1983. I believe the first time I got a list of questions from a boss with the instructions, “Fill this crap out,” it was 1985. This was my first Request for Information, or RFI. If there’s pricing or what-not, it’s a Request for Proposal, or RFP. Either way, as an engineer, I’m stuck with dozens of tedious questions, such as “Does it run on Solaris?” or “Will in integrate with my Salesforce deployment?” or “How much does your software weigh?”

RFI’s are a necessary evil. They get you past the first look-see. If you fail the RFI, you’re likely doomed. You won’t make it to the Proof of Concept (POC). Even if you  have a connection higher up, the lower-downs who actually read the RFI’s will tell the boss, “It won’t work.” Last year I competed with a huge software/hardware vendor whose acronym is three letters and whose company color is blue, and even though they were the incumbent and knew everybody and their mom on the customer’s executive board, their tech team did such a horse manure job on the RFI that they lost the opportunity for a decent-sized deal in a subsidiary of the customer.

Always remember, the customer’s techies may not be deciders, but they can sure be influencers.

So here’s my trivial rant for the day, based on recent experiences: a company looking for a solution of any kind should NEVER, EVER, EVER submit an RFI in Excel spreadsheet format.

The reasons are many. First off, they’re hard to read. The last one I got had way too many columns. Basic subject matter of the question, more details on the question, drop-down box with “yes-no-N/A,” a column for more detail, and a last column for the reader to add his opinion on the vendor’s response. In order to read ALL THIS CRAP, I had to shrink the font down  to nothing, or else scroll back and forth.

The customer also asked some very involved questions. This meant that when I stuck my answers in, the cells got very long-faced. Long, thin column taking up almost a whole page. As a regular paragraph in Word, it would have been three or four lines. Who wants to read that !!#@!?

They also asked for a flowchart, an org chart, and a functional diagram.. so there was a whole lot of a “See attached.” I ended up with thirteen external docs.

When my contact at the customer started going through my response, he joked  with me on the next call that “This really sucked to read.”

I told him, “This really sucked to fill out. Let me guess, the person who put it together isn’t on the team who has to read the response.” And this was true.

 There are a lot of other things I hate about RFI’s, such as the inclusion of generic, boiler plate questions that don’t apply to most vendors. My product doesn’t maintain Private Health Information, so please don’t ask me how I secure it. Oh, and RFI questions that must be answered online are AWFUL. This process takes forever, for several reasons.

Keep it simple, send out a Word doc with your questions, and everybody will be much happier.

I'm schizo and so am I

I recently visited a friend’s shop where they outsource a whole bunch of things. This is increasingly common, of course. They uploaded data and object code to a service. They also uploaded health data. They downloaded reports, and in one instance, they downloaded XML to plug into their own report writer. Their own customers uploaded data as well.

Sounds like business in the cloud, right? Well, yeah, except that they violated a basic rule. They pay for seats on their cloud vendors’ systems. Their customers paid for seats as well. But it’s all on the cheap. They want a couple of dozen users on each site, but pay for only three or four. This means what?

Account sharing.

Doesn’t sound like such a bad thing, except for the AUDIT TRAIL. If we all log in as John Smith, and one of us does something bad, which John Smith is responsible? How do we pinpoint the doer of bad deeds if we all use the same credentials?

It’s a sensitive enough matter that in my current organization, we get asked all the time about how strongly we secure customers’ data, and we are specifically asked in RFI’s about whether we allow account sharing. As well we should.

Identifying situations in which individuals are sharing accounts is not easy, although the Oracle Adaptive Access Manager (a great product with a terrible name) tries very hard to do so, looking for varying patterns of use within a single id. But even then, it's no walk in the park.

It’s hard to enforce policies, which entail accountability and possible consequences, if you can’t tell who to hold accountable. This means everybody should get their own name and password. If you’re only going to have one identity, then only one user should make use of it. That’s why it’s called an identity.

Nobody else has my fingerprints, face, credit history, or wonderful posture. I sure don’t want anybody else taking my credit, or my blame. And I’m pretty sure nobody else wants my face.



When you're gone, you should be really, really gone

I recently attended a CISO forum in Texas. The food was great. George W. Bush was speaking nearby, and shortly thereafter, a veritable horde of GOP donors came streaming through the lobby. There were lots of large old men escorting blonds half their ages. It was actually hilarious.

But wait, I digress. One of the speakers was the CISO of a gargantuan global food company. He said that every year, his company has to decommission literally hundreds of thousands of IDs. Hundreds of thousands. It’s inconceivable to me to work at an organization that large. That’s probably why I’ve been at so many startups.

After my last move, I was shut down from a variety of services fairly quickly. But some things stuck. Not that I took advantage, but it was amusing. I logged into a couple of things just to see if I could. I even reported them, and still they didn’t take care of business. It’s nuts. Had I been a nefarious, scheming, opportunistic scumbag, instead of just a run of the mill jerk, I could have done some damage.

This is why Jesus invented attestation. At least I think he invented it. Anyway, something or somebody has to periodically review who has access to what. It helps to compartmentalize it, so that managers who are familiar with their people can make the decisions on these things. It’s that time of the year, or the month, or the business cycle, so send me a list of everybody under me, and I’ll review who should and shouldn’t still have access.

Maybe I own an app. Show me who’s got access to it, and I’ll figure out who to give the boot to. Or maybe I’m just the admin, I run the servers, so I don’t make the business decisions regarding who has that access. So send the lists to the managers who own those users.

I worked with a role management tool for years and competed with Vaau. Then Sun bought them, and the competition got more fierce. Then while with Oracle, I saw them buy Sun, and the old Vaau product became the new role management component in the Oracle identity stack. It’s got a great attestation piece to it. But any great tool is only as good as the data and/or policies you feed into it.

So this is the crux of it: you have to decide on those policies. You have to decide how the thing’s going to work. But too many organizations don’t make those decisions. They think things just happen. I can provision and de-provision. And sure, that works, but only manually. I visited a manufacturer once where all provisioning was still manual. No workflow, no connectors, just fat fingers. Wow. In this day and age. I have no idea how an outfit like that passes an audit. They even joked, “Don’t tell our auditors.”

Productivity is an important thing. You want people to be enabled. You can waste time and effort when users can’t use. But even uglier is the other end of that spectrum, when users have stuff they shouldn’t have. An ex-employee or ex-contractor, especially a disgruntled one, can hurt you badly when he or she can still get to a resource without accountability.

POLICY. Make sure you have a POLICY. “Every month, manufacturing reviews all access. Every other week, accounting does their review.” And so on. Before really bad crap happens.

Loose lips hack chips

An old boss of mine likes to post on Facebook. All the time. All day long. I’ve told him, you’re like a sixteen year old girl. If you’re at Disney with your kids, or hiking, or hosting your three-year-old’s birthday party, STOP FREAKING POSTING. Pay attention to your kids. The whole world doesn’t need to know all this crap. My brother calls it, “Ate a banana and scratched my ass. Ate a banana and scratched my ass.”

It reminds me of an old SNL skit in which Robin Williams is videotaping his wife as she’s about to give birth in the hospital. When he has to help wheel her gurney down the hall, he hands her the camera and, as she’s shrieking in pain, he implores her to “Keep me in focus, honey!”

Not everybody has to know what you’re doing all the time. So it really surprises me when, at various functions, CISO’s and other security-minded folk start trading intimate details of their security infrastructures. This is one of the reasons RFP’s come with NDA’s. 

ON THE OTHER HAND … if the security perimeter you’re running is strong enough, you should have the confidence to say, this is my protection, and you can’t get past it. Depending on the access management product you’re using, you should be able to easily retrieve the cookie and figure out what it is: OAM, SAM, SiteMinder, etc.  

Remember the LifeLock CEO? He put his social security number on the side of a truck, to advertise it, and dare hackers to try to use it. Of course, LifeLock was banned by the Federal Trade Commission from lying to customers. Fred Thompson, possibly the worst presidential candidate ever, and Rush Limbaugh have shilled for them as well. Anyway, just because in theory you can publicize your private info doesn’t mean you SHOULD. And sure enough, the LifeLock guy had his SSN stolen. This is on top of the news that one of the co-founders had to resign when it came out that he’d stolen his own father’s id to obtain an AMEX.

At one customer, where my team was building an access management perimeter, the project manager handed me a DVD with every name and password in the place. HOW he had the passwords, I could not understand (but I guess that’s another story). I once had on an older box the entire network configuration, including IP addresses, routers, you name it, of a major metropolitan airport, because the partner thought I should have it. Turns out he was in violation of three different NDA’s.

And remember Kevin Mitnick, who became a sort of poster boy for hackers. Upon release from prison, he was ordered to not touch computers for a while. But guess what? He barely used computers for his deeds. He was a master at social engineering.

So what’s the moral? Keep your damn mouth shut. Put up a firewall, put up an application gateway, implement IAM, and keep your damn mouth shut. If people don’t need to know things, don’t tell them. That means, keep your damn mouth shut.

I'm not opinionated, I'm just always right

I belong to a writers’ group that meets at our local library, and each week we read our latest brilliance to each other. One young lady is writing a vampire story. In her latest installment, she wrote about how a nasty young vampire beat up an older vampire. One guy in the group said, “That makes no sense. The older vampire should be the most powerful one.”

Instantly I asked, “Why?”

The answer was, “Well, everybody knows that?”

I countered, “Huh? I have a boxed set of all the Universal horror movies, including Bela Lugosi’s ‘Dracula,’ and I also have a beautiful copy of ‘Nosferatu,’ and the subject never comes up. Does there exist somewhere a vampire wiki  that says older bloodsuckers are stronger than younger ones?”

It turns out that in one of the many, many, many vampire book series, this is the rule. Older is better. And this somehow has become the accepted dogma.

I was recently in a meeting in which somebody who didn’t seem old enough to shave insisted to a co-worker that because their company was required to be compliant with PCI, there was a definitive way for them to create policies, and he knew this because he read it in a book.

Is there a RIGHT way and a WRONG way to create security policies? Is there a magic blueprint for how you should configure a security perimeter and subsequently enforce it?
Nope. Even if you’re subject to SOX, or NERC, or HIPAA, there’s still no “standard” set of policies. Now, you could say that PCI or NERC spell out policies very clearly. But what they really do is tell you at a fairly high level what the requirements are. HOW You get there is a different story.

HERE is what is important: that you HAVE a policy, that it covers all the security and compliance basics to which you are subject, that this policy is documented, and that the policy is ENFORCED. The details have to be there, but as the security guru, YOU are the one to devise them, relative to your organization’s needs. In my book, I recommend that dreaded last resort of scoundrels, COMMITTEES. But peer review is always a good thing. "Hey, guys, let's all put on the table what we think should be in our policy." Then you beat it up, vote on it, whatever. Find out what every corner of the org absolutely needs, devise a policy that covers all the bases, and where you can, you fit in the nice-to-haves. Then you document, implement, and enforce.

Even then, policies aren’t necessarily carved in stone. Things change, right? BUT … if  there are changes, they must be vetted, run through a review, documented and agreed upon, and then OFFICIALLY made part of the new policy. That’s what makes your changes part of the “right” policy.

And you Do want to be right, don’t you?