Cybersecurity – Why updating your Toad® matters – Part 2

Part 2. With the rise of cybersecurity threats, application security is certainly getting more attention. CIOs, CISOs and other executives, responsible for implementing data protection strategies in their company, need to make sure they are protecting their corporate data, comply with the appropriate data privacy regulations such as GDPR, HIPAA, PCI and others and prevent breaches, fines and reputational damage that could seriously impact their business.

Some industry sectors, such as financial services, are increasingly being mandated to apply security patches to operating systems and desktop software to minimize any vulnerabilities.

In Part 1 of this three-part blog series, I introduced the need for tighter application security and why it’s incumbent on software vendors like Quest® to ensure their applications are as secure as they can be.

In this part, I’ll walk you through some of the other security controls Toad® by Quest has in place to ensure we adhere to current software security standards for continually testing and delivering versions of Toad products that you can safely install and run.

You’ll also see a compelling argument for staying up to date with the frequent releases of Toad products so you can avoid vulnerabilities and security threats in the future.

Security controls for preventing supply chain attacks

Most IT administrators are occupied with plugging security gaps among different applications installed on different platforms. That’s why Quest believes in making security practical by releasing products that are secure in the first place.

The table below shows the security controls that every release of Toad undergoes.

In this blog, we’re going to look at the next three security controls (outlined in red above) and how Quest Software implements each of these controls for Toad products.

Security control #4: Vulnerability scanning

Quest has defined processes around SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) scanning, using external tools.

SAST is a form of white-box testing. A tester using SAST examines the application from the inside, searching its source code for conditions that indicate potential security vulnerabilities. DAST is a form of black-box testing, from the outside as an attacker would see the application. A tester using DAST examines a web application when it is running and tries to hack it as an attacker would.

SAST tools assist in identifying weaknesses found on a list known as the common weakness enumeration (CWE). The tools are limited in their handling of issues of logical flow, authentication and authorization, which are better suited to penetration tests (see below) or manual source code reviews. DAST scanners, interacting with a web application from the outside, rely on HTTP and are technology-independent.

For Toad products, tests are conducted using SAST and DAST tools.

Security control #5: Third-party penetration testing

Penetration testing demonstrates real-world impact if a vulnerability or process weakness were to be exploited. It is designed to assess security before a bad actor strikes. A penetration test is not an automated scan of an application or its source code, but a next step after automated vulnerability scanning (see above).

For Toad products, penetration testing is conducted annually. The tests, a combination of manual and automated testing, are designed to uphold software security standards in the following areas of the product:

• Application logic
• Code injection
• Local storage
• Binary exploitation and reverse engineering
• Excessive privileges
• Unencrypted storage of sensitive information
• Unencrypted transmission of sensitive information
• Weak encryption implementations
• Weak assembly controls
• Weak GUI controls
• Weak or default passwords

In most cases a penetration test follows a specific framework depending on the target application or infrastructure, and tactics vary depending on the adversary being mimicked. 

Security control #6: Malware scanning of software builds

When the development team package Toad ready for release, they first scan for malware following a consistent process that includes these security control steps:

• Install packages are hashed using the SHA-256 algorithm before scanning, and the hash must match the final, published hash on the package.
• All software builds are scanned for malware before they are released for install.
• All files packaged into an installer are first scanned for malware.
• Automated malware scanning is performed

Next Steps

In Part 3 of this blog, I’ll talk about some additional security controls that Toad has in place for code signing, software integrity and FIPS compliance.

For more detailed information on how Toad addresses desktop security through SSDLC, read this Technical Brief.

Watch the free webinar, "Why do you need to update your Toad for Oracle today?"