by Joe Bauer
| December 23, 2016
In the previous (second) blog in this series, we discussed using the NIST Special Publication 800-171 Appendix E to list all possible cyber security requirements. We then down selected the entire list of 123 items into roughly 60 that may directly impact the software development process. Now, we will cover how the impact of those 60 items could possibly be included in a TruePlanning® estimate.
I will offer three primary methods for accounting for additional effort of cyber security requirements. We will look at modeling the requirements as individual cost objects in the estimate. We will then consider setting inputs at the software component level that may represent the additional security needed. Finally, we will look at a global input that may be used throughout the model.
We could structure the PBS itself and model the additional requirements for cyber security as discrete software components. The benefit to this method is that we could provide inputs and see results for the added requirements, either as a whole or individually. The disadvantage for this option is the potential for unnecessarily expanding our PBS and overshadowing the primary deliverable in the project. Also, we would need to understand the functionality and size for each requirement….something we are unlikely to know very early on.
The second approach focuses on impacting specific inputs at the software component level that reflect unique security requirements. There are two inputs directly related to this issue: Security Level and Security Process Level. These two inputs essentially ask two important questions: What level of security do I need to get to, and what level of security am I good at right now? If there is a need for a higher security level and I am not qualified to generate software that meets the higher security level, my estimate will reflect the additional hours needed to make it happen. The advantage to this approach is that we can tailor specific cost objects that require cyber security protection, leaving others alone. The disadvantage to this approach is that we would have to relate yet another industry security standard (Evaluation Assurance Level) to the cyber security requirements listed in NIST Special Publication 800-171.
Finally, we can treat the cyber security requirements as just that…additional requirements. There is a specific input at the System and Assembly cost object to address the number of equivalent requirements. Adding the ~60 new cyber security requirements to this input may provide a way to model additional requirements for cyber security without necessarily impacting how we normally estimate software in TruePlanning®. The advantage to this is simplicity. We can make the change at the top level in our estimate and/or at each subassembly. The disadvantage to this approach is the cyber security requirements are modeled as any other requirement. There is limited research available to show whether the results from the model are comparable to actual values seen in programs.
Are you currently estimating cyber security requirements for your program? If so, we want to hear from you! Feel free to contact the author at 937-258-7187 or 1-800-43PRICE.