Security: Show Me The Code

This seems to be a recurring theme, lately. I'm one of a team of dozens working on a large project and we have a handful of "security professionals" assigned to the team. We have just finished writing a design document and the security section is just huge; directly proportional to the number of people working on it. Anyhow, a bit of stage setting is necessary. I'm participating in a conference call, we have webex running and a collaborative whiteboard plus document sharing.

Me: "This is a big section on security but, it's not complete."

Security Professional: "Oh, what's missing?"

Me: "Software security."

Security Professional: "What do you mean, there's a whole section on how to configure each part of the software stack!"

Me: "No, I meant the software itself, especially the custom software that will need to be developed."

Security Professional: "As long as it's configured properly ... blah blah blah"

I cut/paste a snippet of code for a SQL injection attack onto the whiteboard.

Me: "How do you detect and prevent this?"

Security Professional: "What's that?"

Me: "Code for a SQL injection attack."

Security Professional: "Oh, I don't know anything about that type of security."

Me: "Security isn't a black box."

After that, I let the silence speak for itself. I recommended that as a start, they visit John Viega's outstanding contribution to the security community and re-visit their section of the document.

Money Saving Tip #1

The only beneficiaries of creating a model of the as-is enterprise architecture are the consultants you hired to create it! Please note, I'm an enterprise architecture consultant.

I was on a sales call the other day and we were chatting with our prospective customer about IT strategy and they wanted some help defining and describing their strategy and lots of help with enterprise architecture. When I asked them where they were in the process, they replied that they were just starting to document the as-is architecture and were following the classic path of as-is, to-be, gap-analysis, etc. and wanted to know how we could help them out. I replied that they needed to choose one of two answers, either the consultant-as-staff-augmentation or the consultant-as-adviser model. When asked what the difference was, I replied "Several hundred thousand dollars."

Naturally, they wanted the less expensive option and I stated if that were really what they were interested in, why do they want to start the process with the as-is architecture? Instead, they could save a truckload of money by starting with what everybody wants to know, the to-be architecture.

You could have heard a pin drop if if were not for the furious typing of the sales rep sending me some rather unflattering IMs questioning my sanity, legitimacy, etc.

"You mean we should not take a comprehensive approach?" asked the CIO.

"Let me put it this way," I replied, "when you go on vacation do you start with a complete survey, inventory and appraisal of your house?"

"Of course not," replied the CIO, "but you didn't answer my question."

"Well, you actually asked 3 questions," I countered. "First, start with your target and then work backwards. Second, only go into as much detail as necessary to make substantial progress. Third, this is unlike most other approaches but unlike others, it won't have the same high chance of failure."

"Thank-you very much, you have given us a lot to think about," was his response.

Much to the shock and surprise of the sales rep, we have been invited to attend some in-depth discussions with several other team members and stakeholders. I anticipate having a discussion about tools, approaches, etc. that will look a lot like this thread in the Enterprise Architecture Network.

Once again, that money saving tip is: "The only beneficiaries of creating a model of the as-is enterprise architecture are the consultants you hired to create it!"

Process vs. Product Quality

I just finished having a short, hallway conversation with some of my colleagues and it's worth sharing. I was on my soapbox about process quality vs. product quality and I recalled one of the other places I have worked at. It was a matrix organization with a CMMI Level 5 rating, however, we only had a marginally better project success rate than the industry average. I recalled this to my colleagues and asserted that even back at a previous employer, we were CMMI Level 5 because we always made the same mistakes, consistently. Even better, no matter which people we swapped into or out of the process, we still made the same mistakes.

It's perfectly feasible to have a high-quality, consistent GIGO process. Where's the value in that?

IV&V

I had an opportunity to meet with Mike Rollings of the Burton Group the other day and had a very interesting conversation, touching lightly on several topics.

Regarding enterprise architecture maturity models, he agreed that every model that is currently available is either wholly or largely process-centric and in most cases is not what customers want. They want a quality-based, more tangible maturity model. As a consultant, when I get asked to perform an architectural analysis, the questions my customers inevitably want answered include what's working (and how well), what's broken (and how badly), what can I salvage, what can I exploit, what do I toss, what can I buy, what do I have to build?

Regarding enterprise architecture frameworks in general, he noted a distinct lack of pragmatism in many of them. He agreed that the various framework stewards, including the Open Group, are confusing comprehensiveness for consumability. I wondered aloud if the current frameworks are really being shaped by the (in)ability of the current suite of vendors to implement various, pragmatic facets.

Without answering my question about frameworks, he commented on the almost ubiquitous frustration most enterprise architects have with the existing tools. I'll take that as a diplomatically indirect answer. My major complaints about existing tools are threefold. First, they don't allow complete round-trip visibility from business idea to production. Second, they fall apart when trying to model systems-of-systems. Third, they are built for the needs of modelers, not the needs of the end-customers who need to understand the models. Hmm, just like most of the EA frameworks. Notice the link?

I wanted to chat about business processes, security and the malleability of architectural models but, we ran out of time. It's always good to get some independent validation and verification of one's sanity from a fellow practitioner. Hopefully, we can continue this conversation in the near future.

Security Professionals and Software

James McGovern simply confirmed what I have observed all along:

I then asked, how many of them actually had a software development background and pretty much every single hand in the room dropped.

This is why we, who do have a software development background, pretty much discount just about everything "security professionals" say. Not only are the overwhelming majority of "security professionals" ignorant of software development and actual code, they seem to be intimidated by anything that's not sold in a black box that they can push buttons on.

Instead of focusing on what not to do, perhaps they should start focusing on how to do something securely. And at the very least, learn enough SQL so a properly parametrized query can be illustrated on a whiteboard.

I have yet to come across a "security professional" I can't send packing after speaking 3, simple words: "Show me code."