Does the ever-growing risk of cyber threats bother you? Did you notice how some of the major banks, airlines, hotel groups, social media giants, telecom companies, oil and gas companies, were all victims over time? Did you wonder if your company will be next? Or are you already a victim even after all the spending on security, and wondering what did you not do to prevent it? Then read on.

Where is the chink in your armor?

Almost all these victim companies have some good security budget that increases every year. They spend a lot of money to deploy the typical security controls (firewalls, IDS / IPS, Secure Content Management, anti-malwares, SIEM solutions, etc.). Yet attackers find a way in. How?

The answer is simple. Hackers always try unconventional multi-vector attack techniques. So, while companies kept spending more and more money on traditional defensive measures, the hackers turned their attention to other not-so-secure assets.

Today’s businesses are run by their applications. These applications are not limited to secure data centers anymore. They are on cloud, on our mobile phones, in our watches, and even microwaves and doorbells. Most of these applications use personal and business-sensitive data. These data can sell for millions of dollars in the online black market and is the main motivation behind hackers to steal these data. Yet, to operate as expected these applications need to have their ports open in the firewall and allow traffic through the perimeter defenses. The hackers have thus started preferring this path of least resistance, to gain access to corporate database. Sadly, these applications end up being the proverbial ‘chink in the armor’ of an enterprise security program and are a major contributor to global data breaches and ransomware attacks.

Your production applications are probably vulnerable.

You are scanning your applications for OWASP top 10 vulnerabilities before they go to production, right? Is that enough?

Throughout my career, I have seen several Fortune 500 companies struggling to get this right. Developers are always under immense pressure to deliver within a deadline. Speed to market is critical to maintaining a competitive edge. And right before a new feature can go live, comes this scan report with hundreds of security issues to fix.

Hackers always try unconventional multi vector attack techniques. So, while companies kept spending more and more money on traditional defensive measures, the hackers turned their attention to other not so secure assets

This is so late in the project timeline that even fixing the true critical issues causes major delays and loss of revenue for the business. So, they sneak in the insecure code to production to meet the delivery deadline.

My stakeholders often ask me to guide developers early enough so that there are no issues detected so late in the game. The industry calls this as ‘Shift Left’ approach. Many enterprises answer this by adding more scans (e.g., Static Scan, Open-Source Scan, etc.) earlier in the life cycle. Although more scans mean more issues identified and more work for the developer, this is still much better – we are now talking about integrating security controls in different phases of Software Development Lifecycle (SDLC). Industry calls this ‘Secure SDLC’, which is not a new practice either. I have been personally associated with Secure SDLC projects for more than a decade now. So, why do we still have so many application-based attacks? What’s still missing?

Can security shift any more left in the SDLC? Yes, it can!!

An SDLC starts with ‘Requirements Analysis and Design’, then shouldn’t a Secure SDLC start there as well? What you are probably not doing at this stage is - ‘Threat Modeling’.

Threat Modeling is also sometimes called ‘white board hacking’. It’s the process of understanding the application architecture, its interconnecting components, the supporting infrastructure, the users, the data flow and storage, and the overall application behavior. The aim is to predict (‘model’) type of attacks that are possible on this application based on its attributes. Then you find out what security controls are available that will prevent that attack and if a control is not present you write that up as a potential ‘threat’ to the system. An explanation for impact if the threat is exploited and a remediation recommendation is also provided.

These recommended security controls end up being the ‘security requirements’ for the project. An application architect needs to make sure the ‘security requirements’ are met in the design. When this application is finally scanned for vulnerabilities using a Dynamic Scan– the number of issues found are significantly reduced. Leading to a more manageable chunk of remediation work for the developer. It saves a lot of money for the business that would be otherwise attributed to the delay in release.

Threat modeling – the secret sauce to produce secure software

The industry considers - Application Threat Modeling to be one the most underrated yet one of the most effective controls to produce a secure and resilient software.

This doesn’t mean that you don’t need any other security control in the enterprise. You do need your firewalls and anti-malwares and the whole nine yards. You need your other scans throughout SDLC as well. However, now you know how to find things early, fix things early and your application is ‘secure by design’.

Companies who have already been on this path, want to do more and apply the model to every system development, enhancement projects. The need of the hour now is to automate threat modeling to scale it at the speed of DevOps and enable developers to do a lot of it themselves. That’s exactly where I want the industry to head to. But, if you are not doing Threat Modeling at all, it’s never too late to start. Get your white board ready and go - do some white board hacking!!