Same thing, different day: Hackers break into a reputable company’s network through zero-day vulnerabilities and demand millions of dollars in exchange for not publicly released proprietary files – making HBO the latest COTS (Commercial Off-The-Shelf) software victim. HBO follows a long list of high-profile hacks via COTS software, including the famous Target breach perpetrated via HVAC (heating, ventilation, & air-conditioning) software from Fazio Mechanical Services. Unfortunately for HBO, Target, and others like them, it’s their brand reputation that gets dragged through the mud as a result of a data breach. Truth be told, they weren’t overly diligent with sensitive data nor the software they deployed to manage and protect it.
Buying and deploying COTS software doesn’t make your infrastructure any more secure than if you built the application in-house. In this edition of buzzword bingo, I’m going to make COTS a double entendre to also mean Co-Own The Security.
Despite some negative public backlash, many independent software vendors (ISVs) are investing heavily in software security, which is not easy to get right – we know, as we’re in the business of helping ISVs and others secure their software products. This is why organizations need to make sure their COTS risk management strategy doesn't rely solely on a patch management program. Patches come from ISVs after they know of a vulnerability and have had time to develop a fix.
Once 3rd party software is part of an organization’s system they are ultimately responsible for understanding and managing the risk associated with it. Our security services team test hundreds of applications every year and many contain vulnerabilities introduced by third-party components that our clients are surprised to hear about. Testing third-party software components for security flaws is no different from testing your own software – the same attack methods apply. However, because you don’t have access to the source code to fix vulnerabilities in COTS software, you need to implement controls to reduce those risks as best you can. This makes risk mitigation strategy for a COTS software tedious – but achievable.
Doing Your Homework Ahead Of Time
Organizations should have sufficient knowledge of where and how the COTS software will be deployed. This enables risk analysis with respect to other assets that may be compromised in the network segment or datacenter in which the COTS software is deployed. Also, review of known vulnerabilities is important. Many ISVs publish a list of vulnerabilities and patches (when available) for each version of COTS software they sell and maintain.
Also consider the following:
- Is it possible to test COTS software for security flaws in a pre-production environment?
- Will the software and/or plugins be publicly accessible?
- How can known vulnerabilities be mitigated, e.g., by using a web application firewall, application allowlisting, or some other operational control.
- What is the vendor’s patch management strategy, Service Level Agreement (SLA) terms, and secure software development standards?
Threat & Risk Identification
Having an accurate and complete inventory of all your COTS applications is a key component. Make sure you are aware of all the libraries and components that are being used to make up the software by the third-party vendors.
You can better understand risks by conducting a variety of analysis and testing techniques including:
- Security audit and reviews. These can be as simple as questionnaires as opposed to technical analysis.
- Threat Modeling. It’s important to know all the critical assets COTS software will interact with. These assets can be identified through threat model exercises:
- Analyze entry and exit points.
- Create risk profiles for each key asset.
- Once you have you analyzed and evaluated risks, rank them and address the highest priority risks first.
- Watch video on Threat Modeling
- Conduct Penetration Testing. You may find vulnerabilities the ISV doesn’t know about. Responsibly disclosing vulnerabilities to the ISV can help cement a stronger partnership and facilitates open communication with the vendor. Learn about our software penetration testing approach.
- Conduct red teams and attack simulations on your IT infrastructure with very specific goals in mind (i.e. stealing your most sensitive IP) to understand which 3rd party (and even internally developed) applications are putting your enterprise most at risk. Attackers often use a vulnerability in a low risk application to gain access to more valuable targets via escalation of privilege and application traversal. This isn’t limited to COTS software or internally developed applications… to an attacker, all applications are potential entry points.
Mitigating And Reducing Risk
A primary tenant of security is limiting your attack surface. This can be accomplished by applying the principle of least privilege in several ways. First, remove all software from clients and servers that aren’t required. Consider Adobe Flash – it is found on almost every computer, and not usually necessary for day-to-day operations. Yet, it is riddled with security vulnerabilities and significantly expands your vulnerability footprint. Additionally, uninstall and disable features of software and services that aren’t essential. For example, most Java vulnerability exploits are carried out via web browser plug-ins. Most browsers allow the ability to disable plug-ins in the security and privacy settings. Make this part of your Information Security policies and review.
Additional measures to reduce risk include:
- Assign owners for your riskiest 3rd party applications for regular testing, analysis, and vendor communication
- Segregate data and encrypt everything you can, both at rest and in transit. This has the addition benefit of helping you comply with industry regulations, such as PCI-DSS, HITECH, and others that require encryption of sensitive data.
- Implement an application security training program for your development and IT operations teams. “An investment in knowledge pays the best dividends” – Ben Franklin
- In addition to the application-specific controls mentioned above, consider endpoint and content filtering solutions as part of a defense-in-depth strategy, e.g., antivirus, web filtering, DLP, IPS, etc.
The risk mitigation strategy for COTs software can be truly tedious, but if organizations take the right approach it can certainly be achievable. Fundamentally, testing third-party software components for security flaws is no different from testing your own software – the same attack methods apply. Remember, that it’s important for organizations to have sufficient knowledge of where and how the COTS software will be deployed as well as a review of known vulnerabilities. Organizations can also mitigate and reduce risk by limiting their attack surface. This can be achieved by removing all software from clients and servers that aren’t required and uninstall and disable features of software and services that aren’t essential. Taking these crucial steps can help organizations reduce the inherent risks associated with using COTs software.
