Home Computer Science Securing Systems Applied Security Architecture and Threat Models
Why Do Good Requirements Go Bad?
One or more requirements may not be implementable as written, possibly not build- able at all. There are many reasons why requirements don’t actually get built that have nothing to do with how well the requirements are written. For instance, there may
be changes in the business context that cause schedule, budget, or resource shifts. Or assumptions that a design has been built upon may turn out to be incorrect, invalidating requirements based upon those design assumptions.
Let me offer an example: A java application came through that claimed complete adherence to the J2EE* specification that our external, Java runtime was built on. It was a simple blog application, which used a DB for posts (and other data), and the application seemed to consume the infrastructure’s authentication. No additional security requirements were added. The application appeared to adhere to the existing security standards.
But when the application was put into the test environment, the assumptions that its security posture was based on were false. The implementing team had not done a thorough enough examination of the actual architecture of the application. It required a local DB, which was disallowed in the infrastructure. In addition, it could not consume infrastructure authentication. Rather, it implemented its own user store, which also stored credentials in clear text. Both of these needs were against the security standards. The situation was a mess; the application could not be deployed as built. People make mistakes. Early mistakes influence what happens downstream.
|< Prev||CONTENTS||Next >|