Abstract
Since the inception of the SSE-CMM program in 1993, there have been some misconceptions
within the computer security and evaluations communities regarding its intended purpose.
Evaluators in particular have expressed strong resistance to this effort due to the
perception that the SSE-CMM is intended to replace evaluated assurance with developmental
assurance. That has not and never will be the case. The SSE-CMM efforts can greatly
enhance government, corporate, developer, user and integrator knowledge of security
in general. As such,the efforts of the SSE-CMM development team are intended to provide
significantly improved input to system developers (internal assessments) and the higher level
assurance activities (e.g. evaluations, certification, accreditation) efforts (third party
assessments). To best address the needs of our customers, the efforts of SSE-CMM and other
assurance efforts must grow to complement each other. It will take focused effort from
the security community and developmental assurance organizations, as well as industry
partners to achieve this goal.
Evaluated assurance, provided by programs like the Trusted Product Evaluation Program(TPEP),
has become widely accepted throughout the computer security industry. However, as the
state of technology has advanced, the current process and methodology used by the
evaluation community have been unable to keep pace with the accelerated development
cycles of the advanced products that computer-security customers desire. The deficit
of security expertise, as well as unclear and at times inadequate guidance and requirements
within the industry and from government agencies has lead to the persistent practice among
development organizations developing security as an afterthought or add-on to an existing
product. Such practices make correcting security flaws that affect the underlying product
expensive, difficult, and time consuming. All of these factors have forced evaluators
to carry out duties and activities for beyond the scope of pure evaluations and to take
on the roles of trainer, developer, writer, and quality assurance inspector for the
various products that they have been evaluating.
Given these sometimes conflicting demands on the evaluation process, it has become
problematic if not impossible (in some cases) to expect the current evaluation approach
to continue providing all the product security assurance and keep pace with the increasing
demands of computer security customers (i.e. they can not produce enough evaluated products
to meet the demand). That is where the concept of an Assurance Framework comes in. Each
activity within the security arena (e.g. CMMs, ISO9000, Evaluations) brings with it a
certain level of assurance. The composite view forms the Assurance Framework in which a
customer can pick and choose products to support their mission based on their risk
tolerance and product cost. by allowing certain activities, like the CMM efforts, to
address specific assurance needs, the strain on the evaluation community may be alleviated
a little thereby allowing evaluators to focus on the high assurance products while the
lower assurance products undergo a less rigorous assessment / certification process.
In the form of the SSE-CMM, developmental assurance can accomplish many needed improvments
in the way that INFOSEC products and systems are produced. These improvements may well
have a direct impact on the quality of the product's security development and can assist
vendors by better preparring their teams for an evaluation. At the higher maturity
levels, some of the work now required of evaluators for low assurance products, such
as IV&V functions and general security knowledge, can be accomplished during the initial
product development. This will allow evaluators to concentrate more of their efforts
on evaluation activities and less on security education and or product development
for the vendors. The SSE-CMM is a metric for an organization's capability to develop
a secure system. Wouldn't it be nice to know an organization has the capability to
build secure systems prior to accepting them into a rigorous evaluation activity?
