The Security Product Engineering Certification Gap Analysis—The Proverbial Elephant in the Room (G12b)
In an ideal world, products which are slated to be subjected to formal security certification processes (e.g., FIPS 140, CC, etc.) would be architected, designed, built, tested, QA’d and delivered with the relevant security certification standards in mind from the very initial onset of product conceptualization. In this ideal world there would never be a need for a security product engineering gap analysis since security would be “baked in” from the very beginning. Now let’s face reality … we don’t live in this utopia and therefore the gap analysis is a cold and hard fact of life which many of us are forced to deal with on a recurring basis. Nobody really wants to perform a gap analysis, or deal with the consequences resulting from the recommendations contained within the summary pages of a gap analysis report since it takes both valuable time and resources away from both the security certification and the product develop teams. Truth be told, there has rarely been a gap analysis which has not had some negative impact on either product development cost or the overall project delivery schedule.
Since it is a necessary evil and thus the proverbial elephant in the room, the speaker would like to a step back and place the gap analysis process under a microscope and propose a number of enrichments which could very likely improve this much maligned process, minimize impact on both product development and certification, and perhaps (and the speaker say this with the utmost humility) elevate the gap analysis from being a dreaded pariah to the status of being an essential and perhaps even enjoyable part of the product development lifecycle.