O'Reilly logo

PRAGMATIC Security Metrics by W. Krag Brotby, Gary Hinson

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

385
Appendix C: Capability
Maturity Model (CMM)
In Information Security Governance (Brotby 2009b), Krag described the CMM pro-
cess as follows.*
Level 1–Initial
At maturity level 1, processes are usually ad hoc, and the organization usually does
not provide a stable environment. Success in such organizations depends on the
competence and heroics of the people in the organization and not on the use of
proven processes. In spite of this ad hoc, chaotic environment, maturity level 1
organizations often produce products and services that work; however, they fre-
quently exceed the budget and schedule of their projects. Maturity level 1 organiza-
tions are characterized by a tendency to overcommit, abandon processes in times of
crisis, and not be able to repeat their past successes. Level 1 software project success
depends on having quality people.
*
People interpret and sometimes extend the CMM concept in subtly different ways. For
example, in Information Security Governance: Guidance for Boards of Directors and Executive
Management (ITGI 2005), the IT Governance Institute added a level 0–nonexistent at which
risk assessment for processes and business decisions does not occur. e organisation does
not consider the business impacts associated with security vulnerabilities and development
project uncertainties. Risk management has not been identified as relevant to acquiring IT
solutions and delivering IT services. e organisation does not recognise the need for infor-
mation security. Responsibilities and accountabilities are not assigned for ensuring security.
Measures supporting the management of information security are not implemented. ere is
no information security reporting and no response process to information security breaches.
ere is a complete lack of a recognisable system security administration process. ere is no
understanding of the risks, vulnerabilities and threats to IT operations or the impact of loss
of IT services to the business. Service continuity is not considered as needing management
attention.”
386 ◾  Appendix C
Level 2Repeatable
At maturity level 2, software development successes are repeatable. e processes
may not repeat for all the projects in the organization. e organization may use
basic project management to track cost and schedule. Process discipline helps ensure
that existing practices are retained during times of stress. When these practices are
in place, projects are performed and managed according to their documented plans.
Project status and the delivery of services are visible to management at defined
points (e.g., at major milestones and at the completion of major tasks).
Basic project management processes are established to track cost, schedule, and
functionality. e minimum process discipline is in place to repeat earlier successes
on projects with similar applications and scope. ere is still a significant risk of
exceeding cost and time estimates.
Level 3Defined
e organizations set of standard processes, which is the basis for level 3, is estab-
lished and improved over time. ese standard processes are used to establish con-
sistency across the organization. Projects establish their defined processes by the
organizations set of standard processes according to tailoring guidelines. e orga-
nizations management establishes process objectives based on the organizations set
of standard processes and ensures that these objectives are appropriately addressed.
A critical distinction between level 2 and level 3 is the scope of standards, pro-
cess descriptions, and procedures. At level 2, the standards, process descriptions,
and procedures may be quite different in each specific instance of the process (e.g.,
on a particular project). At level 3, the standards, process descriptions, and proce-
dures for a project are tailored from the organizations set of standard processes to
suit a particular project or organizational unit.
Level 4Managed
Using precise measurements, management can effectively control the software
development effort. In particular, management can identify ways to adjust and
adapt the process to particular projects without measurable losses of quality or devi-
ations from specifications. At this level, organizations set quantitative quality goals
for both software process and software maintenance. Sub-processes are selected
that significantly contribute to overall process performance and are controlled
using statistical and other quantitative techniques.
A critical distinction between maturity level 3 and maturity level 4 is the pre-
dictability of process performance. At maturity level 4, the performance of processes
is controlled using statistical and other quantitative techniques and is quantitatively

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required