12.07.2015 Views

CERT Resilience Management Model, Version 1.0

CERT Resilience Management Model, Version 1.0

CERT Resilience Management Model, Version 1.0

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

RESILIENT TECHNICAL SOLUTION ENGINEERINGEngineeringPurposeThe purpose of Resilient Technical Solution Engineering is to ensure that software andsystems are developed to satisfy their resilience requirements.Introductory NotesSoftware and systems are pervasive organizational assets that automate services andsupport business processes to help organizations meet their missions. The importance ofresilient technical solutions—software and systems that resist threats, function satisfactorilyin the face of adversity, and continue to help services meet their missions under times ofstress—cannot be overstated.Resilient software and systems do not become survivable and resistant to threat without anorganizational commitment to address resilience throughout the development process.These assets must be specifically designed and developed with consideration of the types ofthreats they will face, the operating conditions and changing risk environment in which theywill operate, and the priority and needs to sustain the services they support. Typical softwareand systems development life cycles understandably focus on identifying and satisfyingfunctional requirements; that is, most of the effort goes into defining and designing what thesoftware or system must do to fulfill its use case, purpose, objectives, and ultimately, itsmission. However, requirements for quality attributes such as security, availability,performance, reliability, and the ability to sustain software and system assets can in the longrun be equally important to the usability and longevity of software and system assets andrequire considerable resources to address in the operations phase if they are not consideredearly in the development life cycle.Unfortunately, quality attribute requirements can be harder to define, design, and implement,and in many cases require significant business impact and cost analysis up front to ensurethat they are worth investing in. This leads to a tendency to ignore these requirements earlyin the development life cycle and to bolt on solutions to address them later in the design andimplementation phases, when they are more costly, less effective, and typically harder tomanage and sustain in an operational mode. The failure to consider requirements for qualityattributes is a primary reason why software and systems in operation are subjected to highlevels of operational risk resulting from failed technology and processes. This expands analready complex operational risk environment brought about by the integration of softwareand systems with other technology assets such as information, hardware, networks, andtelecommunications. In essence, ignoring quality attributes creates additional security,continuity, and other related operational risks that must be managed in the operations phaseof the life cycle, typically at higher cost, lower efficacy, and potentially increasedconsequences to the organization. In some cases, these problems may be so significant asto shorten the expected life of the software and systems, diminish their overall operationalresilience, and result in cumulatively lower than expected return on investment.178 | CMU/SEI-2010-TR-012

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!