.jpg)
You've probably gotten your fill of security best practices. Their goal of helping enterprises avoid disruptive cyberattacks, data breaches, and other business-crushing dangers is admirable, but bad security practices may be a better place to start, a new report from the U.S. Cybersecurity and Infrastructure Security Agency (CISA) suggests.
Chris Hughes, CEO of Aquia, said application security (AppSec) practitioners have an abundance of best-practices guidance, from the likes of the Open Worldwide Application Security Project (OWASP), the National Institute of Standards and Technology (NIST), and the Cloud Security Alliance. But, he said, "the issue is organizations generally are not implementing them or are not doing so effectively."
“We have no shortage of best-practices guidance. I like to say we are best-practices rich but implementation poor."
—Chris Hughes
The recent CISA report highlights this, with a clear focus on software security, which is front and center for cybersecurity teams. The nine-page report, "Product Security Bad Practices," provides startling examples of AppSec gone wrong.
Hughes wrote about the new CISA report in a recent LinkedIn post, noting the three key areas of focus:
- Product properties, which describe the observable, security-related qualities of a software product
- Security features, which describe the security functionalities that a product supports
- Organizational processes and policies, which describe the actions taken by a software manufacturer to ensure strong transparency in its approach to security
Here are the eight worst software security practices to kick-start your AppSec strategy.
[ Learn more with our Essential Guide: Software Supply Chain Security for Dummies ]
1. Using memory-unsafe languages
One of the worst security practices is using computer languages that aren't memory-safe, including C and C++, for applications aimed at critical infrastructure inside enterprises, government, education, and elsewhere, the report states.
For existing products that are written in memory-unsafe languages, companies should maintain a published memory-safety road map that outlines the manufacturer’s “prioritized approach to eliminating memory safety vulnerabilities in priority code components written in memory unsafe languages,” the report continues. “Manufacturers should demonstrate that the memory safety roadmap will lead to a significant, prioritized reduction of memory safety vulnerabilities in the manufacturer’s products and demonstrate they are making a reasonable effort to follow the memory safety roadmap.”
Memory-unsafe code vulnerabilities must be mitigated in the short term — and eliminated in the long term — the report continues, by methods such as writing new code components in memory-safe languages and concurrently implementing hardware or compiler controls to mitigate memory-safety vulnerabilities.
2. Leaving the door open to malicious SQL injections
Another major common security risk, the report continues, is “the inclusion of user-provided input directly in the raw contents of a SQL database query string” in applications used for critical infrastructure or functions. To resolve these preventable threats, software makers must build their applications “in a manner that systematically prevents the introduction of SQL injection vulnerabilities, such as by consistently enforcing the use of parametrized queries, prepared statements, or consistent use of an object-relational mapping (ORM) library that automatically generates parametrized queries.”
3. Allowing for direct command injections
The inclusion of user-provided input directly in the raw contents of an operating system command string is particularly dangerous and vulnerable when used for critical infrastructure or functions, the report states. To resolve these threats, software makers must systematically prevent command-injection vulnerabilities by “consistently ensuring that command inputs are clearly delineated from the contents of a command itself; using built-in library functions instead of running a command, when available; and using restrictive allowlists that only allow alphanumeric characters and underscores to sanitize user input.”
4. Leaving default passwords in your code
It seems difficult to imagine, but many companies and users still need to be told that maintaining a more secure infrastructure starts with the simple process of eliminating default passwords. But this is an important recommendation in the CISA report, underscoring its continuing prevalence today.
Software manufacturers should ensure that default passwords are not present in a product by providing random, instance-unique initial passwords for the product, the report states, as well as by requiring the application’s installation only after the user creates a strong password to begin the process. Software makers can also provide time-limited setup passwords that disable themselves when a setup process is complete and require configuration of a secure password or more secure authentication approaches, such as phishing-resistant MFA, according to CISA.
5. Not actively participating in open-source communities
When using open-source software, enterprises must be involved in the communities behind the applications, the report notes. Companies must “responsibly consume and sustainably contribute to the open source software that they depend on” to ensure that they watch and contribute to its security and safety, according to CISA. This includes making reasonable efforts to evaluate and secure their open-source software dependencies by maintaining a software bill of materials (SBOM) for critical applications. The SBOMs should be maintained in an industry-standard, machine-readable format describing all first- and third-party software dependencies, both open source and proprietary. The SBOMs should then be provided to all customers, the report states.
Companies that use open-source applications must also perform other steps, including running security scanning tools on each open-source software component that's selected, including its dependencies and transitive dependencies, and each subsequent version when updated, CISA said. Enterprises must “select open source software projects that are well-maintained, and – when appropriate – contribute to the project’s ongoing maintenance to sustain the expected standard of quality.”
6. Using old and ineffective cryptographic algorithms
Enterprises and organizations that run critical infrastructure using known insecure or deprecated cryptographic algorithms are increasing their security risks and vulnerabilities from the start, the report continues. To bolster these preventable situations, users must use modern cryptographic algorithms that can ensure that all sensitive data is protected in transit and at rest, providing tighter defenses and stopping threat paths. This means avoiding and removing references to known insecure or deprecated algorithms such as Transport Layer Security (TLS) 1.0/1.1, MD5, SHA-1, and Data Encryption Standard (DES). Instead, organizations should support standardized post-quantum cryptographic algorithms consistent with NIST guidance.
7. Skipping default multifactor authentication
Not using MFA in software is dangerous and significantly elevates risks to organizations, the report continues. Software manufacturers should natively include and support MFA in their applications, including phishing-resistant MFA, and allow administrators to require MFA for users in their organization, if applicable.
8. Not publishing and maintaining timely CVE reports
To prevent widespread security dangers and vulnerabilities to users of commercial applications, software makers must issue timely Common Vulnerabilities and Exposures (CVE) reports describing and offering resolutions for all critical or high-impact vulnerabilities that are reported for their products, the CISA report states. This important step better protects users and can reduce security dangers for other users.
Rethink your software security from the ground up
The advice and examples in the latest CISA report provides plenty of fodder for enterprises to dramatically fix and avoid some of the worst security bad practices being used every day, for a variety of reasons. Maybe they do not know they are skipping critical security steps and leaving their organizations vulnerable. Maybe they are not aware of new and advanced security policies that they are not incorporating.
Hughes said software security teams should root out these worst practices to bring about needed changes — one at a time. “Start small, focus on what you can control and what is practical for your organization, team, budget, resources, and constraints,” he said.
“We often see SMBs being told to be more like the Googles of the world, when the two organizations could not be more different in terms of financial resources or internal security expertise. Organizations need to focus on what is practical and realistic for their unique circumstances and build from there on sound foundational practices that are sustainable.”
—Chris Hughes
In other recent CISA guidance, "IT Sector-Specific Goals (SSGs)," the agency strongly states that companies need to go beyond traditional AppSec practices and get serious about software supply chain security by establishing a formal program to tackle these risks. These programs should be designed to integrate supply chain risk management practices directly into the software development lifecycle, including regular code testing and auditing of supply chain risks.
One of the more significant aspects of recent federal guidance on software supply chain security from the Enduring Security Framework is the recommendation of binary analysis and reproducible builds as best practices.
Saša Zdjelar, chief trust officer at ReversingLabs, said the recommended use of binary analysis and reproducible builds marks a significant step forward in ensuring better software supply chain security. AppSec practices such as static application security testing (SAST) and dynamic application security testing (DAST) typically apply only to a small subset of internally developed systems and applications at many organizations, he said.
Legacy application security testing is out of sync with modern software development because it does not cover software developed by commercial providers and other third parties, Zdjelar stressed.
"Our ability to analyze binaries is key to understanding risk in third-party software."
—Saša Zdjelar
