Have you ever developed an application that will need to connect to a Secure Sockets layer (SSL) enabled endpoint? If you answered yes, then you might agree with me on how all that red tape will keep slowing your development progress down. As a result of SSL being enabled, you could experience the following concerns:

• Server always validating SSL certificates
• Certificates not trusted
• Client side application will have to support SSL/TLS protocols

Developers may get frustrated with all the mentioned concerns where they would have to decide to disable the SSL checks made by the server. When the code goes through the different stages of the pipeline you get to find that they have forgotten to turn the SSL certification checks back on. You find most organizations deploying high-risk security prone applications into a production environment.

A recent study by “WhiteHat Security” shows that on average, critical vulnerabilities will stay open for 875 days. What was alarming about these findings, was that these open vulnerabilities are found in the Information Technology industries.

In most organizations, security has little or no sense of urgency and is rarely considered when developing applications. The only time they consider it, is when they have to pass some security audit or they are facing urgent security escalation from customers. To some organizations, security is just like that unwanted cousin in the family. But with the recent Sony, Apple iCloud and Ashley Madison hacks, we can agree that it is a little more than just an embarrassing experience that could be detrimental to the business and the customers. Some of the many ways we can try to circumvent security loopholes are to put processes in place and one of these processes can be Threat Modeling.

Threat modeling is a process used to allow an organization to apply a structured approach to designing and building more secure systems/applications. This is achieved by analyzing the security aspects of the application to be developed, identifying potential vulnerabilities and defining countermeasures to prevent or mitigate effects of the threats. Security issues are usually discovered in later stages of development or close to go-live. Usually resulting in extended deadlines that can be prevented by adopting this practice.

What are the benefits?

• Helps us size our stories - no one cares about the security requirements and their testing efforts when sizing stories. Testing is mainly concerned about functional testing efforts, leading to cross-functional testing efforts becoming an afterthought.
• Helps us better sell our work - by letting the client understand that security is not just a byproduct but an integral part of the solution they are trying to build.
• Helps us build the practice into our DNA - software development teams within an organization should start writing security acceptance criteria that will form part of the normal functional acceptance criteria.

Why do we do it?

• To ensure that all applications are built with security in mind from the onset.
• To identify and address threats that could have a potential negative impact on your application.
• To deliver a more secure and reliable product to our clients.
• To detect security loopholes and correct them during development, at a stage where it is less costly.

When do we do it?

As we all know the old cliché “prevention is better than cure”. So with that being said, the earlier we start the process of detecting security loopholes, the more time we have to find and fix security defects that may loom up.

Threat modeling can be grouped into 3 high-level steps (not set in stone):

1. Decompose the application:

• Analysis and in-depth understanding of the system and how it interacts with external entities.
• Identifying entry points to systems that can be exploited by a malicious intruder, service or resource.
• Identifying access and trust levels of the system.

2. Determine and rank threats:

• This compliments the above-mentioned level. Once we find threats when decomposing the system only then can we determine the risk that comes with that particular threat?
• Tools such as STRIDE or Application Security Framework are used in the industry to determine the risk fact of each threat. We can use these tools to better classify each threat we find.

3. Determine countermeasures and mitigation:

• Risk mitigation measures may include evaluation of the business impact each threat poses and then working to reduce that risk.
• Putting counter-measures in place that will aid in detecting and avoid the threat.
• Sometimes we may even choose to do nothing if the risk poses no business impact to the organization, customers or the application itself.

With all this said, Security should not be a “byproduct” of systems we build. It should be baked with the product that is being built. This will increase confidence in the product with concerns related to security. If we start encouraging these principles, organizations could avoid loss of revenue, data breaches and public relations nightmares caused by security loopholes that are baked into the applications being built while reducing the reliability on external security companies to ensure that their products are secure before every production deployment.

Manyano Gwele