Developers are learning hard lessons in app security

The risk posed by unpatched software applications was pushed into the spotlight following the Equifax breach when 146 million customer records were exposed after a known vulnerability in Apache Struts was exploited.

Even with that stark reminder fresh in most of our minds, the reality is, the sheer number of both internal and external applications in-use at the average enterprise makes application security difficult.

That difficulty is ramped up even further when you consider legacy enterprise applications that are no longer under active development. Attackers know these legacy apps are often left unpatched in forgotten corners of the enterprise network and represent a prime target of opportunity. While Equifax is an extreme example, it is critical for organizations to develop a comprehensive application security strategy that includes the security of applications currently under development and legacy applications.

One of the keys to this strategy can be found in DevSecOps programs that help mitigate the risk to new applications by building security directly into the fast-paced development process often found in today’s cloud-native and DevOps focused environments. However, while DevSecOps may improve the security of new and actively managed applications, it does little to solve the problems associated with legacy applications. 

Transparency is vital to app security success

To properly protect the corporate IT infrastructure – whether it is on-premises, hybrid, or in the cloud – IT and security teams must first know what applications are installed on it. Most application inventories include apps that may not have had a code change in years, the main reason why many businesses are hesitant to even undergo the first step in pursuing a sound application security strategy. However, the risk of a large-scale data breach is more than enough of an incentive for this bit of IT housekeeping. 

Companies must realize that risk is likely lurking in the dusty corners of their infrastructure. IT and security teams should be wary of apps that are still used by employees but are no longer under active development, leverage old Open Source code, or those that may be forgotten in production environments. 

Organizations that don’t want to be victimized by a legacy app-related incident should focus their immediate energy on establishing full-stack security observability. This enables the enterprise to maintain visibility into every aspect of the corporate IT environment and understand how apps operate within their stack to develop a baseline for what is considered “normal” for their infrastructure. 

Start by creating and maintaining a single catalog of applications and dependencies running in the corporate environment – including third-party apps and components. List each application’s name, technology stack, purpose, users, and who in the organization may have first-hand knowledge of its implementation. This can be an arduous task, but if businesses employ policies to keep their inventory current after the initial lift, ensuring that every new app is accounted for and thus won’t become a risk down the road – it’s worth it.

SEE ALSO: Enterprise security must catch up with API innovation

Implement security policies for removing legacy apps

Organizations that create an app inventory put themselves in the best position to eliminate software that is either seldom used or has been replaced. Remember, any application – no matter how big, small, old, or new – is fair game for cybercriminals so businesses can shrink their threat surface by removing any potential footholds into their infrastructure. IT and security teams need to implement a plan and process for regularly reviewing their technology stack and sunsetting applications that no longer serve a business function. 

Address tech debt regularly and incrementally

There’s no escaping the fact that updating, monitoring, and maintaining legacy and active apps requires a significant amount of time and resources. As the saying goes, however, a stitch in time saves nine. Rather than procrastinating to the point where the work becomes overly onerous, IT and security teams should dedicate a portion of the development team’s time to keep up with application security. There are two common ways that enterprises can handle these tasks:

1. Create a dedicated sprint team that owns the initiative and allows their colleagues to focus on app security; or
2. Have the entire team dedicate a small percentage of their time to make sure all apps are under control.

IT and security leaders should implement a strategy that works best for the staff and the solutions they have available. 

Leverage standards and compliance requirements

Associations like the National Institute of Standards and Technology (NIST) establish security specific guidelines and regulations to help organizations achieve sound security postures. Cross-referencing legacy code against industry-approved frameworks can be a good method for identifying security flaws. Conducting a complete security audit becomes a less daunting task if the organization makes use of public resources.

Most data breaches aren’t the result of a highly sophisticated attack executed by a state-sponsored group of trained cybercriminals. Truthfully, more often than not, breaches are made possible by a business either ignoring or neglecting basic security fundamentals. 

App security may be viewed as thankless grunt work by developers, but it has significant upside for the business. The key to a solid security strategy is to align people, technology and processes to minimize the more menial app security tasks. Making app security an everyday responsibility – rather than a giant chore – is critical to protect a company’s infrastructure.

The post Developers are learning hard lessons in app security appeared first on JAXenter.