Introducing the Lite Threat Modeling Approach To Software Development

 

As 2023 lumbers along, one of the key issues that will need to be addressed, and to some degrees it is, is that of source code security, especially when it comes to the use of APIs.  Software developers were never really held accountable for any kind of security standard, so there is probably a lot of source code out there is still vulnerable to a major hack job. 

Because of this, DevSecOps has become quickly adopted, and this is where the IT Security Team, the Operations Team, and the Software Development Team all come together to make sure that the source code has been checked on multiple levels.

There are also automated tools out there that can help with this process, but now, it seems like there is yet another new that has just come to market.  It’s called “Lite Threat Modeling”, also known as “LTM” for short.  As its name implies, it is actually a watered-down version of the actual Threat Hunting exercises which take place. But interestingly enough, this process uses more of the cognitive approach rather than real world simulations.

For example, rather than examining the modules of source code that are harnessed through, an LTI will take a holistic approach, and examine the project from the entire perspective.  For example, here are some of the questions that get typically asked:

*What kind of Cyberattacker or hacking group would want to break into this application?

*What parts of the Web app can be easily be broken through, and how can that be done?

*What is the worst-case scenario that can happen?  In other words, what is our tolerance to risk in these cases?

*What kind of impact will this have on our brand and customer reputation?

According to experts, a LTM is best used when your company is throwing around the idea for launching a new Web app, whether is for internal purposes or it will be external facing where clients and prospects can get direct access to it. 

It should also be used throughout the Software Development Cycle (SDLC), and any vulnerabilities or weaknesses that are discovered because of it must be remediated before it can be released into the production environment. 

At this point however, it is up to and your team to try come with a set of best standards in order get the maximum use of the LTI approach.  Examples of this include the following:

*Determining the various threat categories;

*Identifying the sources of threat vectors which could impact the Web app;

*Developing the methodology as to how the threat vectors will be fought off.

Also provided below are some tips that you can use for your LTM processes:

1)     Stay on the world real threats:

Face it, Cyber experts love to plan out every threat vector that is possible, even those that seem to be too farfetched.  That’s fine, but for the purposes the LTI, you need to stay focused on the here and now.  One way to do this is to comb through your log files and determine where all of the suspicious behaviors lay at.  A great tool to use here is your SIEM.  Also, examine what security breaches you have fended off in the past.  Focus on this.  Once you have a bearing of what is going on, then look towards the future vectors.

2)     Don’t get technical:

Another thing that Cyber folks love to do is always find a solution once a problem has been discovered. Of course, this is a very good attribute to have, but for the LTM, it is overkill at this point.  Why do so I that?  Well, these are just theoretical threats.  So, how can you find an answer some thing that doesn’t even exist yet?  Therefore, at this point you and your IT Security team just need to be focused on risk, and how much of it you can tolerate of it.

3)     Tools aren’t everything:

Because software developers have become so reliant on automation, they think that tools can are magic cure all.  But truth to be told, they are not.  Technology can only go so far, and it has breaking points.  Therefore, a human touch is also needed.  That is why so many companies are now embracing the concept of DevSecOps.

4)     It’s not a onetime deal:

TML is by no way is one shot project.  The Cyber world is always changing and you need to keep using this model as many times as you can.  Ideally this should be done at the start of every software module.  So as you finish one, all of the vulnerabilities and gaps that are found should be remediated, so there will be no cascading effects in subsequent modules.  This applies to all other forms of testing, especially that of Penetration Testing.

5)     Don’t get too bogged down:

It’s very easy for a Threat Researcher to get bogged in every minute detail.  But this is not what the LTM is designed to do.  It is effective at high level thinking.  In other words, keep thinking about the macro strategies that will make your Web a successful one.  This all comes down to determining the right mix of controls that you need, from both a technical and non-technical angles.  This will include such items as encryption, security awareness training, etc.

My Thought On This:

I have written a lot about Threat Hunting, and in fact, I have a whole chapter just devoted to it my upcoming book on the Zero Trust Framework.  I for sure have my views on the LTM, but I will reserve on saying more about it until I see more people using it.