Continuous Software Assessment for Highly Secure Web Applications

If your organization isn’t being systematic and proactive when it comes to securing your web applications, you’re not doing everything that can be done to defend systems and data. And that could lead to interruption in software services, stolen data, lost revenue, or the embarrassing and costly exposure of customers’ personally identifiable financial information.

No good. Now, while a lot of attention has been devoted recently to mobile security, IoT, and Industrial Internet security, that doesn’t mean that Web application threats have gone away. They’re not new attacks, but they are all too common. And they go by names such as cross-site scripting, SQL Injection, or directory transversal.

Fortunately, mitigating the risks associated with web application vulnerabilities and attacks needn’t be beyond the capabilities of any company. Traditionally, an application security assessment is the way that organizations identify the mistakes in application logic, configurations, and software coding that jeopardize the security and stability of applications.

The longstanding way to vet web applications for security flaws is a web application assessment. It still is central to these efforts, and it requires a web application vulnerability scanner as well as an expert adept in the technical aspects of application vulnerabilities and how attackers exploit them. Web application vulnerability scanners excel at identifying technical programming mistakes and oversights. These include coding quality errors, such as not checking input strings, or failure to properly filter database queries.

Applications that need to be assessed are typically those that are accessible from the Internet. In years past, it used to be enough to assess periodically. But in today’s enterprise, continuous integration and continuous deployment are the norm to keep an eye on the state of security.

There once was a time when assessments were periodic; now they are continuous. In an ideal world, web applications are vetted for vulnerabilities while they’re being architected and developed. In this way, potential vulnerabilities are identified early, when they’re cheaper and faster to remedy, and they pose no risk to the organization.

With that in mind, here are seven ways to help keep applications continuously secure:

Assess newly bought software and services.

The fact is that, more often than not, commercially-developed software is shipped with vulnerabilities. Every application you purchase and deploy should, at the very least, be scanned for potential vulnerabilities before it’s deployed.

Within the Integrated Development Environment (IDE).

Development teams often find that by conducting security reviews within the IDE, they detect many security-related errors before the software is even sent for review by security teams. Also, security holes are filled along with all other software defects, which helps to reduce technical debt and improve software quality.

It also helps to avoid bottlenecks with traditional code reviews that come later in the development cycle, and to pull that work earlier into the process where it is both easier and cheaper for the developers to fix it. Long-term, not immediately but as technical debt is reduced, developers will be spending more time to develop the software the business needs to compete, rather than fill technical holes that should never have been dug.

Before the software moves to production.

All applications should be checked before they go live. This assessment certainly should not be conducted by developers but by an independent team within, or form without, the organization. The application also should be examined again right after it’s been deployed.

Regular and periodic checkups.

You need to determine, based on business criticality, how often to check your applications. All business critical applications, or those with high value assets (CC and other financial info, links to proprietary information, and other apps crucial to the function of your business) should be evaluated in depth monthly or, at the very least, quarterly.

The need for manual reviews.

Unfortunately, software coding errors aren’t the only problems that create security weaknesses in software.

There are business logic errors that create security holes, such as ways attackers could trick the software into doing something the owner probably wouldn’t appreciate, such as altering inventories, tricking price changes, and such. Application vulnerability scanners are not especially good at identifying these types of errors. Expert application security professionals should be.

Conduct continuous software assessments.

The ideal state today is to have automated assessments of software and systems that are continuously looking at internal and external systems for flaws such as new vulnerabilities that may creep into software, configuration errors, or other things that knock the systems out of compliance with a policy. This is also a good way to spot new and unsanctioned or unvetted applications and servers that have a way of springing up in organizations.

Consider a bug bounty and the need for external eyes.

You do everything you can in your organization to ensure the software is designed, built, deployed, and managed securely. Security teams worked on the design; your developers are coding security in their IDE; the QA team blessed the results, and the continuous software testing shows the code to be clean. But something still goes wrong and security-related vulnerabilities are identified – only this time it’s from an independent security researcher. Many organizations shun these researchers and their findings, but more are turning to bug bounties as an incentive rather than fight legitimate independent software researchers.

Broadly speaking, bug bounty programs are programs that formalize incentives to security researchers who find vulnerabilities in websites, applications, and devices.

With the community of security researchers evaluating software for potential flaws, these programs can help to improve software security and it’s why more enterprise web sites, software vendors, and others are providing bug bounty programs.

Conclusion

Enterprises and software makers are a long way from creating software that is bulletproof from attack. Perhaps that day will come when machines are designing code and managing systems for us. But that’s probably a long way away. For now, we have to be constantly diligent and create, deploy, and manage software to be as reasonably secure as we can produce. The seven pillars outlined in this post are a good place to start.