In a post last month I mentioned an impromptu talk given by Marcus Ranum at the Institute for Applied Network Security’s Mid-Atlantic Information Security Forum. I noticed today that Marcus posted an MP3 of the talk on his website.

Definitely check it out. It’s well worth a listen.

The House Government Reform Committee released its latest FISMA grades, for Federal agencies, and the results were not good. Here is a link to the report.

After reading my previous post, IT Security Improving in Government, you might be thinking that this seems contradictory. Remember that FISMA looks at more than just C&A, including developing/maintaining inventories of systems and configuration management plans, training employees, and other areas of security.

Ironically this article was released while the DHS Software Assurance Forum was taking place. I was at that forum, and while this didn’t come up, rest assured that many folks are tasked with improving the situation. The forum itself was interesting, though some of the talks seemed to be blatant advertisements for LSIs and what not. There are many efforts taking place (some of which are coordinated) to improve software quality and testing. Hopefully next year those grades will improve.

Before continuing, I need to state that the proceedings of IANS forums are confidential. As such, I can’t (rather, won’t) communicate the details of the proceedings.

After a great keynote by Ken Minihan, today was about two things: focus topics and solution providers. The solution provider panel was quite interesting and was a unique experience. Picture an Army drill sergeant grilling a bunch of vendors.

My session went very well, I thought. We got a late start because the afternoon keynote (Bob Woodward) went long. So we ditched the slides and took a more informal approach to the topic. I find that people want to talk about certifications (or, more accurately, security testing, which encompasses more than just FIPS 140-2 or Common Criteria). It’s hard stuff. But it’s always an interesting topic because there are so many different experiences, insights, and visions.

The session concluded with a delegate-only debrief of the solution provider sessions. Again, very interesting stuff, and I apologize that I can’t summarize the details.

I really like the IANS approach in constructing these forums. The faculty is brilliant, and the delegates exhibit a level of experience, intelligence, and talent that made the event one of the best conferences/forums I have ever been involved in.

The first day of the Mid-Atlantic Institute for Applied Network Security Forum was, in short, fantastic. The forum brings together end-users from telco, finance, healthcare, energy, and (of course) Federal, State, and Local government. The discussions with these groups have been fascinating.

I supported the Security Management & Operations track with Fred Avolio and Becky Bace. Here were a few topics of discussion:

• Where does security belong in the organization? Is a centralized or decentralized model preferable?
• Security cannot be 100% - but it doesn’t have to be
• The largest issues organizations face regarding is awareness, communication, understanding of roles, implementation, and ownership (I could talk about this for hours and we essentially did)

Fred’s focus topic on wireless security was entertaining. Nothing really new or technically earth-shattering, but hearing accounts from the end-user community about policy, implementation, cost, auditing, etc. was quite interesting.

Marcus Ranum gave an eye-opening talk at dinner. His points were simple: we’re going out information security the wrong way. Software development sucks, infosec implementation sucks, and consumers suck for buying sucky software. Good engineering takes place from the bottom up. Start with good design of components, and that will more than likely yield a successful end product. His example was Personal Observations on the Reliability of the Shuttle by Richard P. Feynman. I just read this paper - it’s just as excellent as Marcus boasted it was. Marcus also asked why software engineering can’t follow the civil engineering model. Civil engineers design the hell out of bridges before building them. As such, they don’t malfunction. Buildings don’t just collapse. We have a stringent set of building codes. Compare that with software, which is designed “top-down” … meaning, “just start coding the system and we’ll work out the kinks later.”

I always enjoy hearing what Marcus has to say. He challenges conventional thinking, which is a good thing.

I’ll try to provide a more detailed report in a later post.

Next week I will be a faculty member for the Institute for Applied Network Security’s Mid-Atlantic Information Security Forum. On Monday I will support Becky Bace and Fred Avolio on the Security Operations track, and then on Tuesday I will lead a focus topic titled Navigating the Security Product Certification Process. Here’s a general overview of my Focus Topic:

Various organizations certify security solutions based on specific criteria. This session will explain some existing certification designations, what specific issues they address, and how to discern whether a solution actually meets certification requirements. Starting with a quick overview of the FIPS 140 and Common Criteria, this session will address the origins of technical requirements and the common practices for assuring that the products you use are compliant to leading standards.

I’ll spend a brief time talking introducing FIPS 140, Common Criteria, and likely ICSA certification… but the main take-away will be the discussion of best practices for pursuing these certifications and how to programmatically minimize long-term costs and expedite time-to-certification. These are concepts I developed building and running the certifications program at Cisco Systems (and what Apex Assurance Group delivers for clients), and they go beyond typical “certify more often” consulting advice from labs or consultants. And given the fact that there will be considerable representation from the end-user community in the audience, we will spend time talking about issues affecting end-users. Come to the session… we’ll have a good time.

During and after the forum, I will update the blog with forum highlights. I’m looking forward to supporting the event; it should be a good opportunity to educate and to be educated.

There are some interesting sessions on security certifications and assurance at this year’s RSA Conference. First, there is a tutorial on Monday titled Implementation and Selection of FIPS 140-2 Modules: … and Benefits gained! This talk is at 9am on Monday the 13th and is led by Allen Roginsky, Jean Campbell, and Randy Easter.

Steve Lipner from Microsoft is on a panel on the 14th to talk about Government Information Security and the Need for Software Assurance … this should be quite interesting.

The 16th has some interesting sessions, including “Security vs. C&A” Celebrity Death Match 2006 and Federal Information Processing Standard 140-3 - A Standard for the Future … unfortunately both of these talks are at the same time! Two other potentially interesting talks are Managing Business Risk via Information Classification and How I Learned to Stop Worrying and Love ISO17799.

Also consider these talks on Friday: A Primer to Global Compliance Landscape should provide a nice introduction to non-government compliance regulations. Information Access Implementation Strategies for FIPS 201 looks like an interesting talk.

We have been asked about IPv6 transition/implementation (especially in the US Federal government). Friday’s Federal Agency IPv6 Transition Challenges and Potential Solutions talk should hopefully provide a nice overview of the issues.

We found another summary of our Security Product Testing and Certification BoF at ShmooCon 2006. Here is an extract of the major discussion points around Common Criteria:

* what is the practical usefulness of Common Criteria or any other certification other than its mandated use in government installations?
*a reminder that crypto is not part of the Common Criteria, nor is Common Criteria certification meant to be an assurance of security
*vendor writes a target (e.g. ST security target) which asserts claims of product’s features and certification verifies that the vendor complies with its stated target
*probably the biggest drawback is that certification can’t address the end-user; meaning the product may provide secure features but be misconfigured
*however, separate tools exist to address end-user configurations; an example is FISMA
*certification is often an afterthought instead of a part of the design process
*the real value is often going through the process and the lessons learned in order to get the product certified
*there are no studies showing that certified products are safer than non-certified products
*certification is often mandated by people who don’t understand technology and its limitations
*there is a need for dynamic time-sensitive certifications: by the time a product is certified it is obsolete and the code has exploits

Obviously there is ample material from the Shmoo discussion to provide the basis for future posts on this blog. Stay tuned for our thoughts and insights on these issues!

Updated January 18, 2006: Interesting comment posted

Apex Assurance Group was at ShmooCon to talk about Security Testing and Certification. The panelists were as follows:

• Al Potter - ICSA Labs
• Bruce Potter - Booz Allen Hamilton (and Shmoo Organizer)
• Ray Potter - Apex Assurance Group

Note: there is no relation between the panelists. And why get that many Potters in one room? Because we could.

The discussion was in BoF format, and it was certainly one of the more useful, enlightening, and entertaining discussions around security testing we’ve seen recently. First of all, *everyone* in the room was familiar with the FIPS 140, Common Criteria, and ICSA programs. And judging by the insightful comments, it was clear that the audience read the standards, understood their purpose, and implemented/configured certified products.

Must of the discussion centered around Common Criteria, where the group discussed the following:

• Certified products are not necessarily secure

  There is no conclusive research that certified products are more/less vulnerable than uncertified products. FIPS 140 and Common Criteria are about assurance, not about security. One BoF participant made the comment that the programs are for point products, and hooking certified products together will not make the system secure. This is a very true and valid point; Apex Assurance Group would like to remind readers that FIPS and Common Criteria are only a part of systems security design and engineering.

  One suggested resolution was to have a group of independent, certified, firewalled (”ed” - not “firewall”) experts to conduct a series of vulnerability assessments and penetration testing on the product under test in paralle to the work done by the Common Criteria evaluation and testing team. This could provide a more “security” meat behind the assurance certification. Not a bad thought, actually. The devil is in the details and the execution, of course. But it’s a valid concept.

• The value of certification is over-substantiated (or just not understood)

  Surprisingly, FIPS 140 and Common Criteria weren’t faulted in their delivery of security assurance. The audience widely agreed that FIPS 140 and Common Criteria do not meet the security needs of end users. The perception and marketing of these programs took the most criticism.

From our point of view, the main take-away from the discussion is that security assurance and security testing are complex topics. There are misperceptions about the purpose and value of FIPS 140 and Common Criteria, and while they are valuable, there is vast potential for improvement in how these programs can meet the security needs of end users.

Finally, hats off to Bruce Potter and the Shmoo Group for putting this conference together. The con was well organized, well attended, and very well managed.

Apex Assurance Group was invited to speak at the Infosec Conference in New York City this week. The conference was well attended, and the sessions were excellent as usual. Ray Potter, Managing Director of AAG, presented an overview of product assurance programs such as FIPS 140, Common Criteria, and ICSA. The presenter addressed the typical costs, timeframes, and processes with each certification program. The presentation concluded with a discussion on the value of product assurance programs in overall systems assurance and common issues/best practices for pursuing these security certifications. A copy of the presentation can be downloaded from AAG’s library of presentations and whitepapers.

The conference sessions had high attendance, which attested to the strength of the curriculum and breadth of tutorial offerings. Unlike other conferences, the session tracks were not disguised as advertisements for sponsors or speakers. Of the attendees polled in AAG’s session, most felt that the program was strong and would recommend it to a colleague.

At the tradeshow floor, most of the usual security vendors were present, and some new vendors were in attendence as well. Network management and monitoring solutions were the most prevalent, followed by secure email/messaging solutions and proxy solutions such as URL filtering, spam filtering, and virus detection.