We're currently constructing a security development lifecycle in our software development corporation. Our main idea is to have an asset-driven approach, where we:
- Enter assets into an asset inventory as the system is constructed;
- Determine security goals for each asset (and implicitly the criticallity of the asset);
- Follow the critical assets throughout their lifecycle and apply appropriate mitigations where we deem necessary.
While assets such as hardware and the general infrastructure are mostly secured following system hardening and other checklist-based activities (as well as physical security), we are particularly concerned with electronic data assets, used and manipulated by the software.
As the system is quite large and there is a lot of data going around we found that maintaining the asset inventory can be a strenuous activity. Namely, there are a lot of data assets which require high integrity as this is a critical infrastructure system, so we can't afford to overlook these data assets.
In our approach each asset has an owner, a person who is responsible for introducing the asset to the inventory, and this is most often an architect who understands the broader picture of the component. However, our developers are free to add new minor data assets in the form of data structures for holding calculation or partial calculation results. The question then becomes - should these be added to the inventory?
Essentially, this is a question of the granularity of data assets in our inventory. If we go too much into detail we create documentation which is not maintainable, but if we group specific assets into categories of assets we risk missing out on specific assets which might turn out insufficiently protected.
What would be an optimal level of granularity? How would you reason about this?
Additional information regarding our previous software-centric approach
The MS threat modeling method (described in Threat modeling: Designing for security) was something we initially implemented. We developed training materials and used the MS Threat Modeling Tool in the process, which was taught to our software architects. Unfortunately, the project wasn't a success due to several factors, most notably proper funding.
We found several issues with this approach, which we couldn't properly address (due to our lack of experience). This includes:
- Security assurance - it was hard to convince the client that particular data assets were protected without tracking the assets;
- Risk analysis - without examining the assets that a software component was manipulating (and how a threat might endanger a security goal of that asset), we weren't able to reliably determine the risk level.
- Threat modeling priority - without assets we weren't able to determine which components were "more critical", meaning which components required deeper threat analysis and the help of the very limited resources of the security team.
Once again, all of these issues might have been caused by our inexperience with the method, and not by any fault of the method itself.
