Fast-Track Secure Development Using Lite Threat Modeling

New development happens all the time at busy software companies. But is secure development happening as well?

A process called lite threat modeling (LTM) involves stakeholders in secure development, ensuring that security is baked in and not bolted on. What is LTM, and how does it differ from traditional threat modeling?

The Lite Threat Modeling Approach

LTM is a streamlined approach to identify, assess, and mitigate potential security threats and vulnerabilities in a system or application. It’s a simplified version of traditional threat modeling, which typically involves a more comprehensive and detailed analysis of security risks.

With LTM, we’re not manually sticking pins into the system or app to see if it breaks, as we would with pen testing. Rather, we poke “theoretical holes” in the application, uncovering possible attack avenues and vulnerabilities.

Here are some questions to consider asking:

• Who would want to attack our systems?
• What components of the system can be attacked, and how?
• What’s the worst thing that could happen if someone broke in?
• What negative impact would this have on our company? On our customers?

When Are LTMs performed? 

It’s best to perform an LTM whenever a new feature is released, a security control is changed, or any changes are made to existing system architecture or infrastructure.

Ideally, LTMs are performed after the design phase and before implementation. After all, it’s much, much easier to fix a vulnerability before it gets released into production. To scale LTMs across your organization, be sure to establish clear and consistent processes and standards. This can involve defining a common set of threat categories, identifying common sources of threats and vulnerabilities, and developing standard procedures for assessing and mitigating risks.

How to Perform LTMs at Your Organization 

To start performing LTMs within your own organization, first have your internal security teams lead your LTM conversations. As your engineering teams get more familiar with the process, they can begin performing their own threat models.

To scale LTMs across your organization, be sure to establish clear and consistent processes and standards. This can involve defining a common set of threat categories, identifying common sources of threats and vulnerabilities, and developing standard procedures for assessing and mitigating risks.

Common LTM Mistakes to Avoid

Security people are great at threat modeling: They often expect the worst and are imaginative enough to think up edge cases. But these qualities also lead them to fall into LTM traps, such as:

• Focusing too much on outliers. This occurs during an LTM exercise when the focus of the conversation veers away from the most realistic threats to its outliers. To solve this, be sure to thoroughly understand your ecosystem. Use information from your security information and event management (SIEM) and other security monitoring systems. If you have, say, 10,000 attacks hitting your application programming interface (API) endpoints, for example, you know that’s what your adversaries are focused on. This is what your LTM should be focused on as well.
• Getting too technical. Often, once a theoretical vulnerability has been discovered, technical people jump into “problem-solving mode.” They end up “solving” the problem and talking about technical implementation instead of talking about the impact that vulnerability has on the organization. If you find this is happening during your LTM exercises, try to pull the conversation back: Tell the team that you’re not going to talk about implementation yet. Talk through the risk and impact first.
• Assuming tools alone handle risks. Frequently, developers expect their tools to find all the problems. After all, the reality is that a threat model isn’t meant to find a specific vulnerability. Rather, it’s meant to look at the overall risk of the system, at the architectural level. In fact, insecure design was one of OWASP’s most recent Top 10 Web Application Security Risks. You need threat models at the architectural level because architectural security issues are the most difficult to fix.
• Overlooking potential threats and vulnerabilities. Threat modeling isn’t a one-time exercise. It is important to regularly reassess potential threats and vulnerabilities to stay ahead of ever-changing attack vectors and threat actors.
• Not reviewing high-level implementation strategies. Once potential threats and vulnerabilities have been identified, it’s important to implement effective countermeasures to mitigate or eliminate them. This may include implementing technical controls, such as input validation, access control or encryption, as well as nontechnical controls, such as employee training or administrative policies.

Conclusion

LTM is a streamlined approach for identifying, assessing, and mitigating potential security threats and vulnerabilities. It is extremely developer-friendly and it gets secure code moving by doing threat modeling early in the software development life cycle (SDLC). Better still, an LTM can be done by software developers and architects themselves, as opposed to relying on labs to run threat modeling.

By developing and implementing LTMs in a consistent and effective manner, organizations can quickly and effectively identify and address the most critical security risks, while avoiding common pitfalls and mistakes.

Read More HERE