Are You Following These Top 10 App Protection Practices?

Despite the rising costs and impact of application compromise — recent data found that 58 digital records are stolen every second and breaches cost companies an average of $3.6 million — many best practices and procedures for securely designing, developing, testing and protecting applications are largely ad-hoc. As noted by Tech Republic, in fact, exactly ZERO percent of organizations say their security needs are fully met by their current infosec strategy, down from just 11 percent last year.

Some respondents pointed to a lack of skilled resources while others cited budget constraints, but regardless of origin the outcome is clear: Hastily-designed app protection procedures that don’t meet current needs and can’t keep up with evolving demands.

Need a helping hand with your application protection process? We’ve compiled some of the best practices of leading-edge companies into a top-10 list. Let’s get started.

 

10. Educate developers on safe coding & security code reviews

First up? Educating developers on safe coding and security code review practices. Here’s why it matters: As noted by CA Technologies 2018 Insider Threat Report accidental insider threats top the list of corporate worries, and “lack of training and expertise remain the biggest barrier to better insider threat management.”

While many organizations (correctly) link accidental insider threats to staff sending secure data via plaintext emails or falling victim to phishing attacks, poorly-secured or tested app code can have the same effect: attackers are able to breach corporate defenses and access critical information. As a result, it’s essential for all security staff to receive regular training about app coding best practices. These include:

• Effective error handling — How do applications handle errors? Do systems “fail closed” or open potential holes for attackers?
• Continuous logging — Ensuring that all actions are logged and include tags such as date and time, initiating action and user creates both an auditable database of activity and informs ongoing code development.
• Remote admin limitations — Does code permit remote admin execution? Under what circumstances? How is remote management secured (VPN, tokens, etc?)

Better training for developers means more secure apps, in turn making all other app security benchmarks easier to achieve.

 

9. Threat Awareness

To effectively defend apps from malicious actors, companies must develop broad threat awareness. Some threats are common knowledge, such as the use of popular open-source software in app development which may contain critical flaws.

Others remain ongoing concerns. As noted by SANS, vectors such as cross-site scripting (XSS) and buffer overflows remain popular. While defeating many XSS attacks is relatively simple, organizations must understand both the prevalence of this threat and existing application issues to effectively reduce risk. Also essential? Keeping track of emerging trends such as fileless malware and account takeover attacks which attempt to compromise applications without triggering infosec alerts.

 

8. Static application security testing (SAST)

Static application security testing focuses on application source code before it’s been compiled. This offers both the benefits of early use — SAST techniques are viable even in the first stages of the software development lifecycle — and the ability to quickly detect early-stage vulnerabilities. With approximately 80 percent of attacks now targeting the application layer, SAST testing is a cost-effective, simple way to save time on detection and money on costly bug fixes. It scales well and is useful for finding common security flaws such as buffer overflows and SQL Injection Flaws.

 

7. Dynamic application security testing (DAST)

Dynamic application security testing (DAST) is — not surprisingly — the other side of the app testing coin. Here, applications are tested while in operation to detect vulnerabilities which occur only when the app is executing. Essentially, DAST attempts to pierce the running application in various ways to determine potential vulnerabilities and it doesn’t require direct access to the binaries or source code.  

Although DAST comes with limitations, since it can only find flaws in code currently being executed, it provides a more organic way to test application behavior. Why? While SAST evaluates the component parts of applications, DAST reveals flaws that only occur when critical variables — end users — are part of the equation.

 

6. Penetration testing (pentest) – Bring in the humans

While SAST and DAST testing can be fully automated, the pentest includes the human element creating a simulation of security outbreaks against the application. The pentest is a key component of effective application security. The challenge for most organizations? Ensuring that pen testing efforts properly address the scope of potential system issues.

What are top-tier companies doing that others aren’t? Implementing penetration testing processes that come with a clear C-suite mandate and plan of action. According to Business Computing World, this means both creating a regular testing schedule — every quarter to every six months, at most — in addition to testing all aspects of their network and applications. Why is this important? Because many businesses assume that certain portions of their infrastructure or code are “infallible” since they’ve never been breached. The hard truth? They aren’t — they’ve just had good luck. Include everything in your pen test efforts to ensure optimal results. See our blog on Mobile Pen Testing Tips.

 

5. Data encryption / masking

As noted by Forbes, “data encryption is among the most effective strategies for mitigating the damage caused by data loss.”  Many emerging federal regulations and industry standards now require the use of data encryption to demonstrate due care in protecting user data and safeguarding critical application processes.

Companies that excel at data protection share a common practice: They encrypt everything. Files at rest. Files in transit. Session tokens. Mobile data. Connection information. The caveat? Companies tend to trust encrypted data, leading to a rise in SSL and TLS attacks — malicious actors are often able to bypass common security measures by encrypting infected code using commonly-accepted methods. For organizations, encryption is a two-way street: outgoing data and data-at-rest should always be encrypted, while incoming data must always be inspected.

In addition to data encryption, it’s also critical to build in processes which help mask and obfuscate critical data. According to Tech Target, this starts with discovery: companies need to find the data they need to protect within their application. Ideally, this occurs during the design process rather than after the fact. Either way, the Tech Target piece suggests such identification takes between 10 and 20 percent of total project efforts.

 

4. Application hardening / shielding

Attackers are looking for the fastest, easiest route to data breach and application compromise. If an application is easy to reverse engineer, it is easy to steal IP and find vulnerabilities. The result? Employing app hardening and shielding techniques can help convince hackers that your app is more trouble than it’s worth and instead move on to more vulnerable targets.

OWASP speaks to the industry consensus for application hardening, which includes:

• Layer multiple defenses — OWASP notes that “app hardening and shielding along with layered security measures are recognized as a critical component of overall IT compliance.” Wherever possible, companies should implement more security than they believe they need to reduce total risk.
• Leverage obfuscation and encryption — As noted above, both of these techniques are critical to protect apps from hackers and encourage them to find other targets.

For code running in an unprotected environment, find and deploy a reliable code obfuscation tool which modifies files so they’re no longer useful to hackers but remain fully functional in your application.

 

3. Application integrity protection or RASP (runtime application self-protection)

Gartner defines Runtime application self-protection (RASP) as a security technology that is built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks.

Examples of client-side steps an app can take to try to prevent attacks include:

• Keep an app from running on a compromised (or rooted) device where its underlying data and communications may be easily compromised.
• Prevent a production application from being inspected in a debugger or an emulator. Hackers probe applications with debuggers to discover critical flaws and vulnerabilities that they can exploit.
• Stop a tampered version of an application from running or reduce its functionality. Tampered versions of applications can include malware and the end user is unaware.

Examples of server-side steps an app can take to try to prevent attacks include:

• Stop the execution of instructions to a database that appear to be a SQL injection attack.
• Detect misconfigurations that might create vulnerabilities to attack.
• Detect possible fraud and terminate the user session.

 

2. Web application firewall (WAF)

Traditional firewalls rely on perimeter defenses to detect incoming threats and block suspicious actions. The problem? These firewalls have limited efficacy for Web applications located outside the typical network DMZ.

Web application firewalls (WAFs), meanwhile, are network-, host- or cloud-based solutions placed in front of web and mobile applications to actively scan incoming data packets. Their positioning and scanning process allows them to reliably detect potentially malicious behavior and deal with high-risk threats such as zero-day attacks. These attacks are often devastating for organizations because they emerge after applications go live. WAF tools are designed to identify strange app requests, prevent them from executing and then notify infosec teams. In addition, these next-gen tools can be configured to inspect for other threats such as XSS attacks, SQL injections and buffer overflows.

 

1. Compliance Research

Last but (absolutely) not least? Ongoing compliance research and revision.

Compliance expectations such as those from PCI DSS and HIPAA are a good starting point, along with any data that’s company-specific or critical to basic app functioning. Also, consider the EU’s new General Data Protection Regulation (GDPR). Not only does it stipulate that users have the right to request their personal data from companies at any time, but it mandates that any organizations handling or storing the data of an EU citizen — even if the business isn’t located the European Union — must securely store that data and respond to breaches within 72 hours or face significant monetary fines. Meanwhile, new credit data regulations from PCI DSS mandate ongoing protection — with the potential for random audits and compliance checks — rather than once-a-year demonstrations of application security.

The result? It’s critical for companies to regularly review their application security protocols, compare them to existing legislation and make necessary changes.

 

Better Protection, Better Outcomes

Bottom line? Applications are now critical to the success of your business — but without the right security procedures in place these apps may pose the biggest risk to your organization. For many companies, the sheer complexity of their app environment makes the development and adoption of new infosec processes a daunting task.

Start with our top 10 app protection checklist to discover where your security hits the mark, where it needs improvement and where existing process need a complete overhaul.