Patching security vulnerabilities in software and releasing software updates routinely can be challenging, but they are imperative to maintain cybersecurity for startups. Security patches fix coding mistakes or errors that can make software vulnerable to exploitation by malicious actors. Patching vulnerabilities found in software, operating systems, and embedded systems will enhance a startup’s security posture.

What is a security patch?

Think of software as a car that requires maintenance to stay running, security patches as a tune-up, and a software developer as a mechanic. When your car (software) has been running for a while and needs an oil change (update), your mechanic (software developer) can replace the oil in your oil tank with new oil. Similarly, when a mechanic has decided to check everything in your car to ensure there is nothing wrong that is hidden and must get fixed, then discovers an issue with your transmission that wasn’t noticeable to you or anyone, they can fix the problem before it’s too late and your car breaks down.

Why it’s critical for startups to patch security vulnerabilities

A startup should follow best practices for vulnerability patching in their software and release updates for their customers as soon as possible to avoid falling victim to malicious code attacks. Vulnerability scanning is among those best practices, which is like a mechanic who scans your car with a diagnostic tool, and checks for any problems unbeknownst to you or anyone. Fixing these problems and applying automatic updates from within trusted networks can prevent malicious attacks.

N-Day vulnerabilities

N-day vulnerabilities or 1-day vulnerabilities are a type of security weakness a software developer or hardware manufacturer recognizes and is discovered by a vendor or cybercriminal. Zero-Day vulnerabilities are the opposite of an N-Day, which are security weaknesses unknown to vendors. As for N-Day vulnerabilities, patches may already be issued or are in the process of being created and applied. 

The biggest challenge of patching N-Day vulnerabilities is closing the gap between the time patches are released and how long it takes to apply them. Malicious actors and advanced persistent threats or APT groups can exploit the unpatched N-Day vulnerabilities.

To explain how this works, let’s use an example scenario with the fictional company (Company A) that uses a third-party product (Product X).

Let’s say there was an N-Day vulnerability found in Product X on day 1 by a security researcher. The security researcher reports the identified vulnerability to the vendor of Product X. The vendor began creating a patch immediately and released it on day 4 for Product X. Product X’s vendor notifies companies that use its products to update Product X and apply their new patch. Some companies respond by immediately patching Product X on their devices, some take a while, and some never update and patch Product X on their end.

Company A, in particular, uses Product X and has delayed applying its patch for 60 days after being informed by the vendor of its release. This means that cybercriminals had 60 days to exploit this vulnerability in Company A and cause damage to the company. 

EternalBlue 

EternalBlue was a hacking tool created by the US National Security Agency (NSA) and stolen by the cybercriminal group Shadow Brokers. EternalBlue was targeting a 0-day vulnerability in the server message block (SMB) version 1 or SMBv1 file sharing protocol.The Shadow Brokers group released the EternalBlue to the public, after which Microsoft released a patch for this vulnerability. From this point onwards, the vulnerability became categorized as 1-day (or n-day) vulnerability. This however, did not stop cybercriminals from exploiting the vulnerability and using EternalBlue to run ransomware campaigns. Different cybercriminal groups used EternalBlue three months after the patch release for the 2017 WannaCry ransomware attack. 

Unpatched Windows servers connected to the Internet continued to get threatened by the EternalBlue exploit, and over 100 different sources used it to attack systems daily. In May 2017, hundreds of thousands of computer systems continued to become infected, destroying their data and disrupting their operations. Additionally, more than 600,000 servers continued to allow server message block (SMB) connections on the public Internet. Part of this was because some companies needed to keep the SMB port open to support critical legacy applications. 

N-day vulnerabilities become easily exploited when companies do not patch them, allowing more time for malicious actors to take advantage of them. Furthermore, the reality is that malicious actors on the dark web can sell and download exploits for N-day vulnerabilities as part of their Ransomware-as-a-Service (RaaS) subscription model services, which is why patching vulnerabilities as soon as possible is advisable.

Vulnerability scanning tools

Using a vulnerability scanner is a simple and critical method for checking for security vulnerabilities, which also provides insights into potential security weaknesses of a startup or organization’s security posture. They are primarily used to scan for security vulnerabilities in networks and web applications.

Listed below are vulnerability scanners a startup can use:

• Nmap
• BurpSuite
• Tenable Nessus
• Acutenix
• beSECURE
• GFI Languard
• Frontline
• Tripwire IP360
• OpenVAS
• Qualys Guard 
• Qualys Web Application Scanner
• SAINT
• Nexpose

Patch management

The patch management process for startups may require significant effort, but it may not be a requirement for maintaining a good security posture in some. In other startups, it may be worth implementing a simplified patch management process. The procedures and implementation of the patch management process are up to the startup’s discretion. For that reason, I present a generic description of the patch management process for mature organizations. In cybersecurity for startups, it is advisable to identify the crucial components of the patch management process and implement them.

Patch management done in mature organizations remediate security vulnerabilities found. Patch management is valuable for enhancing security, improving performance like system uptime, adhering to compliance standards, and opens up opportunities to include feature/functionality updates after fixing software bugs. Aside from boosting an organization’s security, customer satisfaction may improve when they are happy with the results of software updates. In other words, the patch management process is a win-win procedure.

The following steps describe the patch management process:

1. Develop an up-to-date inventory of all your production systems: You can monitor what assets exist in your ecosystem by maintaining an up-to-date inventory of all your production systems. Being diligent with keeping up-to-date with your asset inventory allows you to have an informed view of your assets.
2. Devise a plan for standardizing systems and operating systems to the same version type: Standardize your asset inventory in a manageable number to make patching faster and more efficient, even though it can be challenging. Standardizing systems serve as a timesaver for your remediation process and accelerate the remediation process as new patches are released. 
3. Make a list of all security controls that are in place within your organization: Keep track of your firewalls, antivirus, and vulnerability management tools. Know where they are, what they protect, and which assets are associated with them. 
4. Compare reported vulnerabilities against your inventory: Use your vulnerability management tool to assess which vulnerabilities exist for what assets in your ecosystem to aid you in understanding the risk in your organization’s security posture. 
5. Classify the risk: Prioritize what vulnerabilities get remediated first based on the order of their severity. Through vulnerability management tools, you can easily manage which assets you consider to be critical to your organization. It’s valuable for a startup to know which patches are the most critical. A helpful tool is the Common Vulnerability Scoring System (CVSS), which rates the severity of security vulnerabilities across a wide range of software products. Read more about CVSS here from one of our previous articles.
6. TEST! Apply the patches to a representative sample of assets in your lab environment. Stress test the machines to ensure that the patches will not cause issues in your production environment.
7. Apply the patches: Apply the patches to reduce security risks in your environment after prioritizing what gets remediated first based on the level of criticality. More advanced vulnerability management tools also offer the ability to automate the time-consuming parts of the patching process.
8. Track your progress: Reassess your assets to ensure patching was successful. 

Best practices of the patch management process

When implementing patch management, it’s equally important to adhere to these best practices for an organization’s team:

• Set clear expectations and hold teams accountable: Leveraging organizational agreements, such as a service-level agreement (SLA), will give an organization’s technical teams something to follow, so that they will actually implement the work that reduces security risks.
• Work collaboratively with technical teams to ensure a common language: Security teams often refer to software errors as a “risk,” while IT/DevOps teams may use another term like “patch.” The difference in language used can create communication issues. A successful patch management process is possible when everyone on an organization’s team understands one another and all value the importance of patching.
• Establish a disaster recovery process: In the event that a patch management process fails and causes issues, always have a backup plan.

Meet compliance requirements with patch management

Patch management must adhere to compliance standards such as PCI DSS Compliance Requirements 6.1-6.7. 

The following PCI DSS Compliance Requirements are:

• PCI DSS Requirement 6.1: Establish a process to identify vulnerabilities using reputable outside sources and assign a risk ranking to newly discovered vulnerabilities.
• PCI DSS Requirement 6.2: Ensure that all system components and software are protected from known vulnerabilities by installing the applicable security patches provided by the manufacturer. Install critical security patches within a month.
• PCI DSS Requirement 6.3: Develop internal and external software applications securely.
• PCI DSS Requirement 6.3.1: Remove development, test or custom application accounts, user IDs, and passwords before applications become active or available to customers.
• PCI DSS Requirement 6.3.2: Perform code reviews before applications are become active or released to customers to identify possible coding vulnerabilities.
• PCI DSS Requirement 6.4: Follow change control processes and procedures for all changes to system components.
• PCI DSS Requirement 6.4.1: Separate development and test environments from live environments and implement separation with access controls.
• PCI DSS Requirement 6.4.2: Separation of duties between development, testing and live environments is required.
• PCI DSS Requirement 6.4.3: Production data (live PANs) are not used for testing or development.
• PCI DSS Requirement 6.4.4: Test data and accounts must be removed from system components before the system is enabled before going live.
• PCI DSS Requirement 6.5: Address common coding vulnerabilities in software development processes.
• PCI DSS Requirement 6.5.1: Consider injection flaws, specifically SQL injection, also OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.
• PCI DSS Requirement 6.5.2: Buffer overflows
• PCI DSS Requirement 6.5.3: Insecure cryptographic storage
• PCI DSS Requirement 6.5.4: Unsecured communications
• PCI DSS Requirement 6.5.5: Inappropriate error handling
• PCI DSS Requirement 6.5.6: All “high risk” vulnerabilities identified during the vulnerability identification process must be addressed.
• PCI DSS Requirement 6.5.7: Cross-Site Scripting (XSS)
• PCI DSS Requirement 6.5.8: Inappropriate access control
• PCI DSS Requirement 6.5.9: Cross-site request forgery (CSRF)
• PCI DSS Requirement 6.5.10: Broken authentication and session management.
• PCI DSS Requirement 6.6: Constantly address new threats and vulnerabilities for Internet-facing web applications and ensure that these applications are protected from known attacks.
• PCI DSS Requirement 6.7: Ensure security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.

Cybersecurity risk management

Cybersecurity risk management is an ongoing process of identifying, analyzing, evaluating, and addressing the cybersecurity threats a startup may face. The role of teams in cybersecurity risk management is dependent upon its organization. For some organizations, risk management is solely the job of the security team. For other organizations, it can be split between DevSecOps and DevOps teams for example. Often, collaboration between teams plays a significant role in risk management. In addition, providing cybersecurity awareness training to all employees in various departments can help lessen the risk of cybersecurity threats, especially phishing attacks. 

Here are some key risk management action components startups and organizations should keep in mind:

• Development of robust policies and tools to assess vendor risk
• Identification of emergent risks, such as new regulations with business impact
• Identification of internal weaknesses such as lack of two-factor authentication
• Mitigation of IT risks, possibly through training programs or new policies and internal controls
• Testing of the overall security posture
• Documentation of vendor risk management and security for regulatory examinations or to appease prospective customers

End-of-life software

End-of-life (EOL), when referring to a piece of software or product, is referring to the end of its lifecycle. A software vendor may end or limit its support on software or products and/or its versions to focus on new innovations. This can create issues for customers who continue to use outdated and obsolete software because they become vulnerable to malicious attacks when vulnerabilities are no longer patched. As malicious actors become more creative and advanced over time with the advancement of tools and access to more resources, it creates more opportunities for them to exploit outdated software. It is strongly recommended to keep up to date with the latest version of software and when software has reached end-of-life, finding an up-to-date alternative is pragmatic.

Five end-of-life software dangers also include:

1. Incompatible software — New releases of software have been optimized for the most recent operating systems. With an EOL OS that you cannot upgrade, you may be forced to continue running older applications. These apps themselves are probably facing their own EOLs, too.
2. New vulnerabilities — When a vendor stops issuing security patches, your system becomes a sitting duck for cybercriminals—who will quickly start searching the globe for people who continue to operate in this defenseless mode. Using firewalls and anti-malware countermeasures are not enough to protect your servers from attacks that exploit unpatchable vulnerabilities.
3. Added expense — The operating costs required to maintain and fix bugs on an OS that’s post-EOL can be quite high. In addition, you should estimate the business impact, in dollars, of an outage caused by the EOL OS.
4. Compliance challenges — Regulatory compliance frameworks usually mandate regular patching.  The audit and certification process for systems in regulated industries like healthcare and finance may prohibit the use of EOL systems.
5. Poor performance and reduced reliability — Running legacy apps on EOL OS’s leads to performance and reliability issues. Aging systems tend to break down more often than their more up-to-date and patched counterparts. It’s wise to think through the effects of the inevitable downtime that will come with an EOL OS.

Summary

Security vulnerabilities in software must be addressed as soon as possible, and should not be ignored by an organization or startup because the clock is ticking as time passes for a malicious actor to leverage them and execute a malicious code attack. By implementing patch management and risk management, following best security practices, adhering to compliance standards, including keeping up-to-date with software updates from within trusted networks, and staying informed on a constant basis of inventory assets, the security posture of an organization or startup will boost at an accelerated pace. All of this may require significant resources, however knowledge about all those aspects and selecting the most important ones will increase cybersecurity for startups.

Sources:

• https://zigrin.com/vulnerability-severity-in-web-application-penetration-testing-cvss
• https://www.cisa.gov/uscert/ncas/tips/ST04-006
• https://www.rapid7.com/fundamentals/patch-management
• https://www.coresecurity.com/blog/top-14-vulnerability-scanners-cybersecurity-professionals
• https://www.techtarget.com/searchsecurity/answer/Testing-a-security-patch
• https://retaintechnologies.com/en/how-to-easily-update-and-maintain-asset-inventory
• https://hyperproof.io/resource/cybersecurity-risk-management-process
• https://endoflife.software/what-is-eolhttps://blog.cloudlinux.com/5-risks-of-using-end-of-life-operating-system
• https://www.darkreading.com/vulnerabilities-threats/eternalblue-longevity-underscores-patching-problem
• https://usa.kaspersky.com/resource-center/threats/ransomware-wannacry
• https://www.crowdstrike.com/cybersecurity-101/ransomware/ransomware-as-a-service-raas