I'm working on a threat modeling/architectural risk analysis (ARA) methodology for the organization I work for. Our business consists of one major product (developed by ~500 developers over a decade). The product contains hundreds of features, most of which are far from the attack surface and work with data of little consequence.

In order to optimize our ARA I wish to implement a feature risk rating method which will allow software architects (which are not security-savvy) to easily assess the impact of the feature they are producing. Based on their score they will either do a lightweight version of ARA, a more detailed version or even consult with the security team (if it is a high impact feature).

Can you recommend any such methodology? The only thing that comes to my mind is a questionnaire where the architect will fill information about the assets with which his/her feature interacts (based on our asset inventory) and, based on the asset impact and a simple formula, the architect calculates the feature impact.

Do you guys have any better ideas?


I would abstract out the 'impact' rating for your users of this rating system. The resulting system needs to be clear, simple, and unambiguous. It also needs to result in an auditable output (something someone else can check).

I have done this by reducing the complexity of analysis to the data and the data systems the feature interacts with. Use your existing data classification and data risk model to define the characteristics of the various data types you have (personal, financial, payment card, health, sensitive, etc.) and define what protections those data should have (encrypted, certain access levels, etc.). You probably already have some level of understanding of the impacts of the various data you have, so just borrow it instead of re-inventing the wheel.

Then you can classify the protection/risk level of the data that the feature touches, either directly or via calls to other features/systems.


The data the feature processes has:

* names or personal identifiers
* payment card data, bank details
* health information
* internal financial information
* internal configuration
* passwords, crypto keys
* ...

The feature interacts with:

* users
* Database A
* Database B
* 3rd party service C
* payment processors
* external researchers
* ...

The result is simple: the dev checks the characteristics of the data the new feature processes and the systems it interacts with, and your checklist should return the classification of the feature. Auditors/peers just need to review that the data indeed has those data characteristics.

All in all, the resulting system is fast, simple, and easy to understand. What makes it work is all the work done previously in identifying the risks and protections required by certain types of data (either by internal risk ratings, laws, regulations, etc.)

If you do not already have a data classification and data risk understanding, it would actually be simpler to create that first, rather than re-inventing that wheel every time you have a new feature to assess. It would also make it easier to update this rating system when things change, like laws or the risk tolerance of the company (three cheers for abstraction and encapsulation!)

An added bonus to the data characteristics inventory approach: if a regulation changes you have a pre-built inventory of data characteristics, so you know the flow of that data through your systems. It's like an up-to-date, organic data flow diagram.

  • If I understood you correctly, the idea behind your method is to see which data the feature touches (directly or indirectly) and to rank the feature based on the data with the highest impact? So, for example, feature A works with data 1 and data 2 directly and with data 3 indirectly (through feature B), where data 1 and data 2 are medium impact and data 3 is high impact. The feature is rated as high impact. Is this what you suggest? – Nikola Luburić Oct 13 '17 at 7:52
  • I'm not so concerned about 'impact' as that can send people down some rabbit holes. Just concerned about a broad 'risk' rating. But basically, yes. That secondary rating through feature B needs to be evaluated in your environment. In a de-coupled design, any feature touching data 3 is automatically high risk, and any other feature needing feature 3 inherits that risk rating (else why need feature 3?). But your implementation might be different. – schroeder Oct 13 '17 at 8:11

I think this should be based on the capabilities of the feature to access various security/data/other areas. Think of it like a mobile phone app requesting various accessed to your phone's specific modules.

So consider what the feature can do/access/alter and assign a risk score to that. Of course, you will have to have a complete picture of the situation, so you can set a number of categories with maximum score for each.

A questionnaire of course can help but only as long as it is completed correctly, considering all aspects involved. Usually this is handled by an assessment team, not only by the architect, as he probably will not consider all implications.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.