Shifting Security Left Into the Application

How do you:

• Ensure you don’t join the trash heap of hacked enterprises?
• Make security is part of the SDLC from the get-go and not an afterthought?
• Address the latest attacks that bypass traditional network security protections?

You need to make a paradigm shift in your application security.

Organizations have been moving security controls left in the software development lifecycle. Now it’s time to consider baking security in from the start before a single line of code is written.

Move Controls From the Network Perimeter to the Application

Historically, security has been enforced outside of the application. This is particularly true at the edge of the network where traffic flows across trusted and untrusted network segments. Security outside of the application was accomplished by using various tools such as network or application specific firewalls (e.g. web application firewalls, or email gateways). These tools would analyze traffic and look for malicious payloads. In addition, vulnerability scanners and intrusion and malware detection tools have been used to scan for suspicious content or activity. When suspicious content or activity was found alerts were raised, which, at best, resulted in some form of blockage or quarantine.

These controls act from outside of the application and do not have the visibility from inside the application. And you need an ‘inside view’ to truly understand what is taking place or whether the perceived attack was successful or not. For example, an IDS or vulnerability scanner may observe a security issue based on the configured rules or the attack signatures and raise an alert. However, due to a lack of a visibility from within the application, such tools cannot determine with 100% certainty whether the attack succeeded or not. Having an internal view paints the most accurate picture of potential security issues as opposed to an outside view which gives a good guess at best.

Shifting Security Left

In addition, statistics have shown that bolting security on as an afterthought to the application is costly to an organization. It is more expensive than taking security controls into consideration early on and “baking” them in from the beginning. Applications should be architected and designed with security in mind. This means that all possible threat scenarios are considered up front. And mitigating controls and compliance requirements are built-in to counter threats before they occur.

Shifting your security left gives you a forward view of security. This means that more secure applications are produced, costly inefficiencies are avoided, and organizations receive a better return on their investment. This does not mean that security controls outside of the application are not needed. Security should follow a defense in depth approach and be applied at all layers where possible.

Secure Package Management and Enforcement of Policies

As the focus on security shifts to the application layer, one of the key concerns is the use of packages and libraries within those applications. One of the advantages of modern day software development is access to a vast array of modules, packages, and libraries. These can all extend the features and functionality provided by the core language or framework used to build applications.

While this provides great benefits and flexibility, it also brings about challenges when it comes to security. Many of these packages are open source, created by multiple contributors and may not go through a strict security review process. This results in undetected vulnerabilities. Moreover, even if packages have gone through a security assessment in the past they may contain new vulnerabilities not yet known. And these new vulnerabilities will not be detected by existing tools and processes. In order to address these issues, organizations should enforce policies to prevent the use of vulnerable packages, modules, and libraries; maintain an up-to-date inventory of packages used by applications; and perform regular checks for vulnerabilities based on trusted sources of information. If any of the packages are found to contain a vulnerability, patches must be applied and new versions deployed.

As discussed earlier, “baking” security into the application and having an insider real-time view from within can provide an accurate picture, allow enforcement of the required policies, and assist in maintaining inventory and addressing vulnerable packages as early as possible.

For a deeper dive into this subject, watch our on-demand webinar, Inject Security Into Source Code: How 2018 Will Shift Your Application Security Priorities. Watch Now.