Researchers have discovered another bug in a WordPress plugin. A vulnerability in the MainWP Child plugin allows attackers to take full control of a website. This is an easy to exploit vulnerability and is estimated to impact upwards of 90,000 websites. If you are using WordPress, check to see if you are using the MainWP Child plugin and upgrade to version 18.104.22.168 to mitigate the vulnerability.
This is just the latest example of the supply chain introducing risk into enterprises. During the recent Superfish kerfuffle, CNET noted that an insecure supply chain is the “biggest problem in software”. And just like Lenovo, WordPress is taking the brunt of the bad publicity for the vulnerability, not the creator of the plug in. Because enterprises do not have control over the development process or security of third-party applications and plugins, securing the supply chain is notoriously difficult and exposing them to unnecessary risk.
So what can you do to protect your enterprise? Here are six tips for embedding security into your procurement processes so that you can reduce the risk introduced by your supply chain.
Define criticality of your purchased applications: not all applications are equal and a vulnerability in a calculator app is not as important as a vulnerability in your authentication system.
- Criticality can be based on PII, pervasiveness of the application, or even spend on the application, but it must be applied to all your applications
Define a third party application security policy
- What vulnerabilities are acceptable vs. what must be addressed (i.e. all OWASP top 10 flaws must be remediated or mitigated before software is acceptable).
- If software fails to meet this policy in an independent test, how are they required to respond and in what timeline?
- What is the escalation policy if software fails to meet this policy and a satisfactory response from the supplier is not received?
Establish verification procedures and criteria for delivered products and services
- What level of artifact and detail is required to verify that this software has been built to secure standards?
- What is an acceptable third party attestation provider?
Define when, how, and with whom the software supplier or the enterprise will communicate in the event of an incident.
- What are the supplier’s incident response methods
- How does the enterprise coordinate incident response with the supplier
- How does this effect system integrators, other suppliers, and external services provides
Define acceptable standards for software maintenance. Understand the mechanisms for updating firmware and software elements:
- How are updates performed? Are they pushed or pulled?
- What channel do they use, and from what location?
- Can my organization block updates and coordinate these centrally?
- How is authentication performed? If certificates are used, what type? How are certificates managed?
- How is integrity of the conversation protected from snooping and tampering?
- If the platform (Google’s Android, in this case) provides code update mechanisms, why aren’t they used?
Require a “bill of materials” aka the defined external components within the purchased software.
- What open source libraries/components/etc. are leveraged?
- How are these maintained?
- When a vulnerability in one of these components is discovered, when and how will a fix be pushed?
For more tips and information on creating a successful third-party security program read the guide: