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