Web application security: Creating a strong digital battlefront — GCN

application security  (Ditty_about_summer/Shutterstock.com)


Web application security: Creating a strong digital battlefront

  • By Setu Kulkarni
  • Jun 26, 2018

As citizens become more accustomed to a digital world, public-sector agencies are expected to keep pace and deliver. We can summon food and coffee at the push of a button or even get a ride to the airport from a stranger in the blink of an eye. In this on-demand society, waiting in line at the Department of Motor Vehicles or sitting on hold to get a simple health care question answered  seems borderline archaic.

According to IDC, more than 70 percent of the U.S. workforce will be mobile by 2020. To improve the citizen experience — and productivity internally — many agencies are adopting enterprise-oriented apps that increase efficiency by cutting down on paperwork and other manual processes. Web and mobile apps for parks, libraries and the DMV, for instance, provide citizens with information and services faster than ever — letting people use online chat features to have questions answered or digitally update their car registrations. But the software enabling these conveniences may lack the security features required to process sensitive data.

The software security problem

Modern organizations deploy a plethora of web applications, accessible from any location. These are an easy target for hackers, who can exploit them and gain access to back-end corporate databases.

In fact, WhiteHat Security’s annual Application Security Statistics Report examined “windows of exposure” across multiple industries each year and found a consistently high rate of web applications that are always vulnerable — every single day of the year. Many recent breaches like the massive Equifax incident were caused by easily fixable web app vulnerabilities.

This year’s Verizon Data Breach Investigations Report, just released in April, reiterated the frequency of web application security incidents, showing alarmingly high correlations to the number of breaches in a variety of verticals. Nearly 30 percent of the breaches Verizon tracked (414 reported) were caused by web application compromise. Of all of the methods used, stolen credentials is the top hacking method used in breaches involving web applications, followed by SQL injection.

In the public sector in particular, cyber espionage remains a major concern, with 43 percent of breaches being motivated by espionage. However, it is not only state secrets that are a target: Personal data of citizens is also at risk.

Security activities historically revolved only around the most critical web applications. However, recent attacks have proved that attackers can and will target non-critical ones. This is a major issue for the government sector, which is notorious for implementing new technology then leaving it to age, with possible misconfigurations and unpatched vulnerabilities waiting to be exploited.

In 2017, for example, the Russian hacker Rasputin compromised 63 federal, state and local government agencies and universities via SQL injection. By using a SQLi tool he developed himself, Rasputin found and exploited vulnerable web apps — making the attacks simple to complete but very expensive to defend against.

So why are organizations and government agencies still making these fatal web application errors, despite public evidence that they can be massively disruptive? These mistakes continue because teams often follow a policy-based approach to cybersecurity — meaning they adhere to requirements from regulators and lawmakers, often just checking the boxes and not accounting for the gaps.  

Security throughout the software development life cycle

As cyber threats evolve and agencies keep pace with digital transformation to improve citizens’ experiences, public agencies should look at developing software that is secure by design.

Web application development is a continuously evolving domain given the need for creating and sustaining high user engagement. In addition, in the pursuit of user adoption, web-delivered systems are now being integrated via application programming interfaces to create more complete, seamless and harmonious systems that simplify and aggregate otherwise complex and seemingly disparate interactions. As such, formal processes and best practices for developing modern software are still being defined, but companies and agencies looking to create their own app must ensure security is present throughout the entire software development life cycle.

Important considerations include these initial areas:

Training. Everyone involved in web application development should receive basic security training. Scalability and repeatability are critical aspects of effective security training programs. Traditionally, security training was done live, but today e-learning and computer-based training can help ensure consistency, reproducibility and regularity of training across the entire IT workforce.

Requirements. As software requirements are defined, security requirements should be defined right alongside. For example, if sensitive customer data will be collected and stored, policies on how the data should be encrypted, both in transit and at rest, should also be established as a requirement.

Design. Once the application requirements are captured, an architecture is created that should correspond to the software requirements. At this development stage, necessary security controls should also be identified and allotted as part of the architecture design.

Implementation. After requirements have been determined and an architectural design is in place, constructing the software begins. Ideally, developers should receive security feedback while they are coding — as early and often as possible. Because this phase is often the most labor-intensive, continuously running automated security assessments allows developers to address issues in near-real time. Without that continuous feedback, organizations will develop applications built on faulty code, with security as an ineffective afterthought.

Comments are closed, but trackbacks and pingbacks are open.