Why it’s important to have your software developers go through annual secure code training (they should know the OWASP top 10).

Why Annual Secure Code Training is Essential Now, More Than Ever

With our world on Covid-19 lockdown, a vast majority of the global workforce now works from home – remotely tethered to a plethora of interconnected, cloud-hosted applications. While this is a nightmare for in-house IT staff and CIOs, it’s a hacker’s dream come true. So much so that the Center for Internet Security has put out a Resource Guide for Cybersecurity During the Covid-19 Pandemic. Consequently, it’s vitally important – now, more than ever – that software and firmware developers undergo secure code training to keep hackers at bay.

Hacking is a Real Threat in Our Covid-19 World

Insecure Home Internet Connections

When working from home (WFH), employees typically log on to the Internet through wi-fi connections powered by inexpensive ISP-supplied routers and modems, which are relatively easy to hack. As a result, even an amateur can hack into home networks and use them as conduits into corporate systems. If your very first line of defense gets busted, you’ve pretty much lost the battle!

While some tech-savvy and deep-pocketed employers secure employees’ home networks (with robust security protocols, enterprise-grade firewalls, and secure VPN connections), an overwhelming majority of America’s small businesses simply do not do enough to keep their employees’ home networks secure.

In addition, with companies routinely hiring freelancers and contractors in an increasingly gig economy, corporate networks continue to be susceptible to exploitable security holes from non-employees.

Sharp Jump in Exploitable Third-Party Apps

Even if employers do all they can to secure home networks and their own IT systems, Covid-related WFH has led to a massive surge in demand for third-party apps for file sharing, video conferencing, remote collaboration, etc.

This swift transition to WFH has led developers of popular apps to focus on quickly rolling out products and features to gain market share early in the game. As a result, many popular apps are in relatively early stages of development – focused on showcasing minimally viable functionality, without having given adequate attention to security vulnerabilities that come with large-scale deployment (ever been Zoom bombed?)

For instance, app developers may not adequately encrypt data at rest, or may incorrectly implement user authentication and session management, or not fully secure their APIs… all of which exposes data, tokens, and passwords to hackers.

Data Interchange Lapses and Other Laxities Add to Security Risks

Where platforms and apps may intrinsically be secure, attackers look for vulnerabilities in data interchange protocols (such as poorly designed XML processors or APIs), in poorly enforced user access controls, or in code development libraries, plug-ins and IDEs.

Moreover, as businesses specialize on micro-niches, they rely on multiple developers and multiple platforms collaborating to deliver partnered solutions within and across enterprises, potentially creating exploitable gaps.

Small Businesses Are Particularly Vulnerable

Additionally, small businesses are notorious for not properly securing their IT systems on an ongoing basis. While they may initially hire an IT consultant they rarely invest in ongoing IT support to update security protocols and conduct periodic network penetration testing. As a result, within months of founding, small business networks and systems become easy targets, and conduits that attackers use to target juicier targets.

Developers Must Undergo Annual Secure Code Training

To meet increasingly granular information security standards, programmers must be fully aware of secure coding best practices within their own tech stacks, and be intimately well-versed in shared security standards so different languages and protocols securely connect with each other without leaving loose ends.

While organizations such as the CISA keep us apprised of the latest threats and breaches and help developers quickly plug known vulnerabilities, breaches are typically discovered months after they take place, when most of the damage has already been done.

One of the best ways developers can proactively secure networks and systems is through annual secure code training offered by the non-profit Open Web Application Security Project (OWASP). The OWASP Top 10 lists the most recent, most critical web application security risks, which goes a long way in helping web developers and technologists develop secure code.

As of May 2020, the OWASP Top 10 included:

  1. Injection
  2. Sensitive data exposure
  3. Broken access control
  4. Cross-site scripting (XSS)
  5. Using Components with known vulnerabilities
  6. Broken authentication
  7. XML External Entities (XXE)
  8. Security misconfiguration
  9. Insecure deserialization
  10. Insufficient logging & monitoring

Sadly, software learning curriculums focus primarily on delivering functionality, with only a brief module typically devoted to security. As a result, over 70% of new applications fail to meet coding security standards such as those from OWASP. However, developers made big improvements when they got the security training they needed.

Consequently, organizations must be cognizant of training shortcomings and work to overcome them.

Everyone involved with software or firmware releases – from the CIO to coders, UI designers, QA testers, product managers and business analysts – should be aware of OWASP secure coding standards, with the CIO championing secure coding at the executive level, and empowering and funding the development of secure and robust software and firmware for the organization’s best long-term interests.

At the end of the day, CEOs are aware of the heavy toll that cyber security breaches can take on their organizations. Consequently, they must make IT security a strategic priority, and adequately fund engineering and development so they do not have to compromise on an organization’s IT security needs.

Sources: