Malcolm Levy, Certification Manager, Check Point Software Technologies. This presentation the speaker will recount experiences with FIPS 140 and offer some observations of ways that the encounter can be more rewarding and add genuine value to the production of IT security products. FIPS 140 doesn’t evolve fast enough. Having a stable standard should make it easier to evaluate to, but it doesn’t. It leads to more prescriptive evaluations that all too often get bogged down in the detail, and a one size fits all approach that stifles innovation. Evaluation takes too long. When the certificate is issued, the module, all too often is redundant. Firmware and software often needs to be updated monthly or even weekly to address security threats that emerge in the environment. There needs to be a way to keep a module certified when the product it is running on changes rapidly. If FIPS 140 allows the operating system that a software module runs on to be constantly updated and the module to still be certified, then why not be more flexible about vendor code changes? What happens to a module when it is certified? Does anyone use a module in its FIPS mode of operation? Shouldn’t there be more emphasis on integration in the real-world installations? Hardware can get to level 4, software can’t. The speaker proposes abandoning the overall level in favor of having a common baseline for all evaluations while still allowing vendors to achieve higher levels for individual sections.