Creating Passionate Users has an excellent post about Knowledge Management and the Wisdom Hierarchy.

Knowledge Management is an exciting area, and yes, security is crucial in the field - especially with regard to regulatory compliance. I first studied principles of Knowledge Management while at Ernst & Young, and I still occasionally read papers and essays on the subject in my spare time.* “Working Knowledge” by Davenport and Prusak is an excellent source of information (or rather, knowledge) on the subject. Harvard Business Review also has a slew of publications to discuss KM strategy, best practices, and lessons learned.

Anyway, I thought that the overall concept of the CPU post is very relevant to why Apex Assurance Group was started. There are plenty of other companies who specialize in harnessing the Data, Information, and Knowledge concepts as they relate to security certifications, systems assurance, and risk management. But no one in the certifications space really delivers the Wisdom and Understanding components.

The core of our business is to help product vendors, government agencies, and end users understand the need for and value of security certifications and assurance through education, business intelligence, strategic planning, program management, and cross-functional team building and integration. We provide consulting services to help customers achieve compliance while developing long term strategies. Our business model definitely falls in line with what the folks at Creating Passionate Users were discussing.

From the post:

Remember, kicking ass and creativity usually doesn’t happen at the data, information, and even the knowledge level.

Now, of course, there is an element of creativity in meeting such requirements as FIPS 140, Common Criteria, FISMA, etc. - but not much. The real elements of Understanding and Wisdom happen at the strategic/corporate level, and these elements play an even bigger role in areas such as systems assurance and risk management.

Knowledge management, security, business strategy, execution, quality - I love how it all comes together. If I had more time, I’d write a 20 page white paper on this.

Anyone want to sponsor it?

*It’s worth noting that my daughter owns a shirt that says “My Dad Is A Geek”

I ran across this post on Microsoft Technet’s Regulatory Compliance blog. The conceptual, high level thoughts don’t detail a “how-to” guide for compliance, but they do get the brain cells moving somewhat.

In a previous post, I made the comment “security is a business issue, not a technical issue.” So where does Security fit within an organization? I’ve talked with a lot of people about this; it’s a fascinating concept.

I’m not talking about a security product vendor or a security services organization. Let’s assume we’re talking about, say, a financial institution. Security is a horizontal effort, meaning it spans multiple business units, multiple divisions, branches, etc. Of course, each of these entities must abide by the company’s security policies and procedures, and there is a technical component to this compliance. So if we’re thinking about an org chart, where does Security fall?

Well, even if run horizontally or by committee, the Security org needs executive leadership and management. This individual could report into the organization in a number of ways and hold one of several titles:

1. The Chief Security Officer (CSO) can report directly to the CEO
2. The CSO could report directly to the Chief Information Officer (CIO)
3. The CIO can own all Security
4. It can be non-existent
5. Any other combination (or bastardization) of the above

I don’t think there is one right approach. Organizations will adopt a model that works for them. I think the right solution will vary based on company size, complexity, and culture.

The 7th International Common Criteria Conference is at the Canary Islands in Spain this year. Here is the website.

Call for papers is open until May 31. I’ve got several ideas, but the problem is finding the time to craft the submission!

I led a presentation at the (ISC)² Security Leadership Series in Ottawa. Here is the abstract:

A sound security posture includes a detailed process to assess risk and counter threats via policy and technology. Systems owners in Federal agencies and in the commercial sector are under increased pressure to identify and mitigate risk, and the US government is at the forefront in establishing such processes and testing requirements. This presentation will explore risk assessments, including the benefits, methodologies, and policies/regulations as well as discuss product testing in a security/risk context, including ways to define requirements for security products deployed in a system. The presentation will conclude with an analysis of how security testing methodologies fit into the risk assessment/systems accreditation environment and with a group discussion of experiences, issues, and best practices for security testing and risk assessments.

This was a fun session. I wanted to keep it informal and diverge from traditional uni-cast speaking styles. The audience was quite involved, asking questions, providing real-time feedback, and posing challenges to the concepts. At the end I opened the floor to a forum-style discussion, where I encouraged the group to discuss what they’re doing with regard to risk management, how/if security testing plays a role, then discuss common issues. And the group did just that.

Some highlights:

• Everyone unanimously agreed that security is a business issue, not a technical issue. I posed that concept expecting a great deal of controversy. Ah well, it’s always a pleasure to talk with enlightened folks.
• Communicating results of threat/risk assessments in a way that can be understood and adopted by both senior/executive management and by technical folks is consistently a major issue.
• The group was well-aware of FIPS 140, Common Criteria, and other testing methodologies, and they agreed that these programs are not always used effectively.
• We discussed spending on security and how that affects an organization’s risk management program (via mitigation, acceptance, etc.). If dollars are spent correctly, then the graph for risk reduction versus dollars spent looks like this:
  

This presentation can be requested at the Presentations & Whitepapers page.

Also, Mark Fabro from Bearing Point gave an excellent presentation on SCADA. Not only did he know his process control stuff, but he was able to back that up with impressive technical expertise. SCADA is not an easy subject to present, and he did a fantastic job.

[From a bar in Newark International Airport]

After one of the worst travel experiences of my life, I have asked myself the question, “Why do I do what I do?”

Well, rock stardom is out of the picture. And I don’t have enough time to play golf to think of it as a career possibility. I don’t see my photography being able to support my family. So why the security assurance space? Well, I enjoy it. Yes, as crazy as that sounds, I really enjoy this line of work. Why? Allow me to answer that with the assistance of a couple of pints of Guinness.

1. Information security, and especially security assurance, is constantly changing and evolving. Technology changes, which requires creative solutions to meet customer needs. End-user requirements change. Federal mandates change. Business processes change (or worse, don’t change). There is opportunity. There are also problems, many of which are very difficult to solve. No certification project is the same. No strategic consulting engagement is the same. But that is what keeps it new and fresh.
2. The people are interesting, not only because they are typically very intelligent but also because they take interest in a variety of other activities. Here’s a representative sample of the types of folks I work with:
   • A sea captain and celestial navigation expert
   • A botanist who grafts different species of fruits and vegetables to develop the perfect crop
   • An airplane pilot (there are a few of these, actually)
   • An accomplished photographer (there are also a few of these)
   • A watercolor and ink pen artist
   • A fashion mogul
   • A semi-professional golfer
   • A true entrepreneur who knows everything about building, growing, managing, buying, and selling businesses
   • A wine and beer maker
   • A restorer of old cars (especially 1960’s Mustangs)
   • Musicians, musicians, musicians. Technology and music do work similar (or perhaps complementary) sides of the brain.
3. I consider myself a generalist when it comes to security and technology, and this line of work provides exposure to such a wide range of products and solutions.
4. I can deduct this beer from my taxes.

I do think that assurance is valuable and can positively impact our technology and business processes. Is the implementation or understanding where it needs to be? No. I also think the world of security assurance has some tough times ahead. Look at all the reports on FISMA grades, or the current culture of “Common Criteria is the answer, now what was the question?” (A former co-worker coined that phrase). But again, there is opportunity.

We all have existential dilemmas, but now I’m fired up! Only two more hours before my connecting flight, and I have plenty of work to do.

Stay tuned… You’re going to see a lot from Apex.

Fred Baumhardt of Microsoft wrote some interesting comments on his perception of the Common Criteria - see Common Criteria - IT Security Certification, or Shiny Sales Sticker?

His conclusion points are spot-on:

So before you buy a common criteria product you should do two things –

1 – Check how you will deploy the product – and ensure that the entire infrastructure is going to be secure, don’t assume that a CC sticker will mean instant security.

2 – Check here for the list of what level the product has been reviewed at, and WHAT FEATURES (security target) were reviewed. Open the documents for your product and read the public sheet of what the sec target was, and more importantly, what wasn’t in the evaluation.

I’ll likely add a few thoughts on each point in a later post.

I do realize that this came out a month ago; its reference here was delayed because I have been extremely busy and I was just looking for a good time to post it. I figured posting this on the heels of my latest Thoughts on GAO NIAP Report makes sense.

Update: comments posted

The GAO NIAP report referenced in this post yielded two recommendations for executive action. Here are my initial thoughts and comments:

1. Coordinate with vendors, laboratories, and various industry associations that have knowledge of the evaluation process to develop awareness training workshops for program participants.

I like this idea in principle. But here’s a question: Can we get all of these stakeholders to actually agree on a training curriculum? As far as the basics- yes. It’s easy to develop a seminar to talk about Security Targets, how the CC is structured, etc. But the real value in education is to discuss lessons learned and to highlight best practices. Add strong personalities, mixed levels of experience, ego, and hidden agendas, and this idea quickly turns into a debacle.

2. Consider collecting, analyzing, and reporting metrics on the effectiveness of NIAP tests and evaluations. Such metrics could include summary information on the number of findings, flaws, and associated fixes.

This is hard. This is very hard. Slight tangent, but I’ll tell you how I measured the effectiveness of CC at Cisco: revenue. Yes, dollars. We didn’t measure the success of Common Criteria by the documentation we produced, the interviews we conducted, the site visits we ran, or “flaws” found in documentation or code. Why? I didn’t care. We didn’t care. This may offend some of the CC zealots out there, but Common Criteria wasn’t about improving our process or making a more secure product. It was about selling.

This idea of defining success metrics is important, and it definitely needs to be explored. I do believe vendors can realize benefits by pursuing Common Criteria, and I’d love to see a data points that show how Common Criteria can make a difference (past revenue impacts). But for this recommendation to even begin to be considered, these “metrics” need to be formalized. For example, what is a flaw? If a vendor makes a source code change to comply with a broken, dated Protection Profile written for a specific customer’s specific environment, does that mean they fixed a flaw? I sure hope not.

These are difficult problems that are not easily solved. Well, not easily solved if the solution is to have any value. And we want this to be of value, right?

I have my own thoughts and ideas on how we can make these recommendations work. Maybe you’ll see them on the blog, maybe not.

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.