Granularity for data assets when determining risk during software development

Question

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:

1. Enter assets into an asset inventory as the system is constructed;
2. Determine security goals for each asset (and implicitly the criticallity of the asset);
3. 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.

Answer 1

The way I'd reason about this is to go back to the initial decision, which was to focus on assets. Asset-driven approaches to threat modeling tend to end up with a problem like yours, which is "Make a list of everything." That long list makes it hard to focus. (The other problem they encounter is "what's an asset?")

Most engineering groups find it easier to make changes in the areas that they're making changes to the system, and so focusing on the software/system that's in scope for the current sprint/iteration helps you find threats that become actionable.

If, rather than focusing on the asset, you focus on the software, and ask "does this expose us to new threats" then your question is easier to answer. For minor modules, that question can be focused on "does this add an API, change an API arguments, or change the data this module is processing?"

If so, you can use a mnemonic like STRIDE to look for spoofing, tampering, repudiation, info disclosure, denial of service or elevation of privilege to examine the changed elements.

Additional Answers (SE lost my previous attempt at this; this is shorter)

First, if your client is demanding that you provide a threat model focused on assets, then that's your answer to what matters. You absolutely run the risk you identify, "we risk missing out on specific assets which might turn out insufficiently protected," but if you have no budget, you face that risk anyway. SE cannot tell you what asset categorization rules will make your customer happy. (bold text added here to fix an edit failure)

Second, it sounds like you're trying to do something like risk=probability*impact. Neither input is defensible. You need to fix the easy stuff, and then focus on having a dialog about the potentially difficult fixes.

Lastly, your third question puts the cart before the horse. You threat model to determine what's important, not determine what's important, then threat model that. If you're focused on assets, what assets does your active directory hold? What does your firewall hold? I bet both are important to keeping your system secure, not because of the assets they store.

Lastly, if your issue is budget, the changes you're making, as you document, are not fixing that problem. You need to find a way to get some quick wins, and use those to justify appropriate budget.

Answer 2

That's a very good question. Risk management is a tricky business. In lifecycle process, You should find the balance between the detail level inventorying the assets.

The definition of asset is Any resource or information an organization needs to conduct its business. Based on this, you should categorize the assets introduced by developers in order to know if they are really assets. To identify an asset, ask yourself: "What are you trying to protect?". And to try to identify the associated thread, ask: "What are you afraid of happening?". If you can't find clearly the answer for a concrete case, don't put it on your inventory. Maybe this method can save you time.

We can't know from here how complex is your project. But you should follow the "manual". Threat modeling is something that must be practiced again and again to be improved. Never there are 100% universal truths.

Consider to study a certification focused on this kind of things. For example, CSSLP (Certified Secure Software Lifecycle Professional) is an ISC certification. There is a complete section talking about risk management. There you can learn methodologies, processes and some tips and hints to follow.

Hope it helps. But as I said before, I think nobody has the perfect answer for this.