Home Source code Why software developers need to keep cybercrime in mind

Why software developers need to keep cybercrime in mind

0

The risk of cybercrime is too great to allow trust. Although business relationships, especially business-to-business, can be based on trust, this leaves open the debate on how to manage software vulnerabilities.

Blasting whistleblowers creates a dangerous landscape

Let’s start by identifying and disclosing software vulnerabilities. Researchers and developers are vying for responsibility for early detection and disclosure. The software supply chain attacks did not surprise the cybersecurity community at all. Developers are terrible at testing their own software for vulnerabilities and glaring holes are left open for years. When researchers find them, they are often torn between making them public anonymously or telling the developer. Indeed, the developers have sought cease-and-desist orders or filed criminal charges against the researchers disclosure. This has even been the case when bug bounty programs are in place. Overall, the laws protecting vulnerability disclosure are weak, and developers often act to suppress the disclosure rather than properly placing it in the MITER CVE vulnerability database. This disagreement has caused vulnerabilities to persist, allowing further attacks.

Software developers are wrong. Delay in disclosure can open liability to fines for SEC violations. Legal and financial liability is already clear and reinforced by court decisions that set precedents. More of them turn a corner as shareholders weigh in with a brighter media spotlight.

These are just the table stakes. The people at risk are the customers, the companies that use the software. Where are they in this debate? Should a company take responsibility for finding vulnerabilities in the products it purchases? They certainly won’t have a testing and research arm, so they have to rely solely on finding known and disclosed vulnerabilities. However, there is no obligation for the developers to provide them. The charge then falls to the customer without declaration.

Know outsourcing vulnerabilities and plan for them

Companies that outsource part of their operations may think they are outsourcing security and software management, which they are to some extent, but they retain the legal liability. As a legal officer, it is in their own interest, if only financially, to hold themselves responsible for detecting attacks.

Detection should be a layer on your network regardless of any known or unknown vulnerabilities.

Vulnerability scanning tools and Disclosed Indicators of Compromise (IOC) are the source of information and rely on public disclosure to automate detection; no company could provide a detection function without them. It is essential that suppliers adopt this ecosystem.

Click here to learn more about the different supply chain technologies:

Open source opens the door to transparency

While we can shift the scale to the developer for vulnerability identification and disclosure, we need to shift to the customer for mitigation. This is not the case for software as a service (SaaS), where patches are managed by the vendor. On-premises or privately hosted software cannot be vendor dependent for deployment and patching. Too many dependencies create complexity that the provider can only solve. Any automation they provide for patches is concerning and should be performed under the watchful eye of good change management. They’re not off the hook because they need to make patches and fixes easy and supported and they absolutely need to raise the bar on communication and transparency. This is something they can learn from the open source movement.

While it’s reasonable to assume that a lack of transparency will remain an integral part of doing business for most companies, it’s for this reason that open source software has become a viable option. The open source movement exists in part because of the lack of transparency in the software supply chain. Large vendors with a large market reach typically guard their software, fearing that the proprietary intellectual property will be scrutinized by competitors or malicious actors with malicious intent. Open source software, on the other hand, is transparent, allows for external study, and encourages the discovery and discussion of software vulnerabilities.

The concern with the lack of transparency is that disclosure of vulnerabilities and attacks may be delayed or hidden in order to protect a vendor’s reputation. The law is already very clear on the disclosure requirement and the SEC recently fined companies for failing to disclose violations and was accused of defrauding investors by hiding such data. Without access to the code, there’s no real way to know what’s in the black box. It might even be a backdoor, which is why some Chinese products are banned by our government. Researchers can do incredible things even with a black box, but developers who provide their source code get more help finding holes and are therefore more reliable.

Politics as effective policing

One solution would be to create and support auditing organizations capable of instituting software testing standards. Testing could be performed either with the cooperation of software developers or by external auditors alone, although regulations may require developers to submit to testing, assuming that software testing does not become an expected part of the conduct of business. At a minimum, a software BOM could be provided, as recently advocated by CISA.

As cyberattacks increase in scale and scope, and as law enforcement agencies take them more seriously, there will be a greater requirement for data retention for forensic examination and investigation purposes. legal discovery. Appropriate detection by all parties aids the investigation, informs the security operation, and can protect the company from legal liability. Additionally, by establishing a data retention system for this purpose, an organization is relieved of the burden of scrambling to collect data, delaying any forensic work, and creating a grand project for your team while trying to dampen any potential. attacks or breaches.

Risk mitigation requires improved detection and communication

In the business world, self-preservation will always be king. Outsourcing work does not mean outsourcing risk, and it is unwise to assume that a vendor will look out for you and your organization’s interests. Your organization’s cybersecurity should be a priority, and anything vendors might do to protect you should be seen as an add-on, because legally, financially, and reputationally, the responsibility rests with you.

In addition to ensuring that your organization is “covered”, collaboration and transparency in identifying vulnerabilities and detecting the network actually improves the security of all parties involved. The integration of intelligence and telemetry on the provider side is necessary to have global coverage and to be truly able to detect compromises from all side, entry and exit points on the network and workloads hosted. This may require regulation and compliance to encourage vendors to be open with their customers about software vulnerabilities and to embrace researchers, or it may become a standard part of good business, but this collaborative effort will be essential in the fight against cybercrime. An unknown vulnerability or missing IOC is a detection gap that attackers can take advantage of.