TAME YOUR ASSETS

SUMMARY

DAM system vendors often employ open-source third-party apps and code to meet important business requirements but their decision introduces risks to a system’s security and roadmap.

Why are we talking about this?

Managing risk should be at the top of our list of considerations when selecting and using a digital asset management (DAM) system. One such risk is open-source third-party software and code. Take, for example, a DAM system vendor that offers optical character recognition (OCR). The service is likely offered by leveraging third party software by established companies like ABBYY or open-source code libraries such as Tesseract. The same can be said about image processing (ImageMagick) or embedding metadata (EXIFTOOL). These third-party purpose-built tools often do a better job than something a vendor can develop and are much cheaper to use. However, adopting these solutions also introduces risk that companies must protect against. You may have heard of Log4j vulnerabilities which have been covered extensively in the news recently. A simple tool that saves developers crucial time coding logging programs, Log4j has been found to trigger the code it is monitoring, which may include malicious software (malware).

What are the risks?

There are four different types of risks that ought to be considered. Let’s talk about security first. Copying and pasting someone else’s code makes a program more susceptible to potential future vulnerabilities. We can turn to the Log4j example again. Once experts identified vulnerabilities in its code, patches were written and released to address the issue. However, at the time of this writing, these patches and fixes were slowly being released and turned up additional issues that need to be addressed. What about the risk to your business? If your system uses third-party apps or code, chances are you will have little control over feature development. I’ve banged on this drum in meetings with vendors who use third-party open-source code but their hands are tied: they can only put in a request to the community of coders who maintain the tool or create their own branch of the software. This last option will require they maintain the code forever. Regardless, the vendor will be slow to fold in and deploy new updates to third-party components reducing a business’ operational efficiency. Keep in mind: this new code, like any other, takes time to deploy, test, and debug. In a sense the vendor and, by extension, your company is outsourcing its IT infrastructure by incorporating third-party apps into one if its business system. There’s a legal risk too. Managing open-source licenses and ensuring your compliance with them is like patting your head while rubbing your tummy. I’ve never heard of a legal action happening but it’s a risk worth listing in your mitigation strategy (more on that in the next section).

How can the risks be managed?

The process of managing risk can be broadly organized into three steps: identification, assessment, and action. You’ll need to start by asking your vendor or DevOps team whether they use third-party code and, if they do, what it is (asking about their risk management strategy is helpful too!). Review publicly disclosed open vulnerabilities. If the source code is on GitHub, I look through the comments logged under the issues tab. If you are working with a DAM system vendor, ask to review their code. Granted, this is a huge undertaking and the vendor may not allow you take a peak under the hood, but this request becoming more and more common. I am aware of at least one company that requested and was granted this privilege. Collate your list of risks. Next, weigh the impact and probability of each risk. I assign numbers to each of these aspects and multiply them to help prioritize the risks. For example, if a risk’s impact is moderate (3) and probability is insignificant (1), its score (3) would probably mean it’d deprioritized. Some folks suggest using an outside (non-biased) resource to conduct your risk assessment. Though I’ve had success doing this on my own, your company or client may have these resources to offer you. Once you arrive at your prioritized list, decide on a risk mitigation strategy for each item. First off, keep track of third-party code and software by maintaining an inventory. This can be helpful if you are ever (urgently) asked for this information. The mitigation strategies I use are:

• Avoid: Eliminate the risk or withdraw the requirement
• Reduce: Optimize process or requirement to bring down impact and severity of risk
• Share: Share the burden of the risk with additional resources to lessen the impact and severity
• Retain: Accept the risk and budget for it

Going through this exercise shouldn’t be a one-and-done project and should be done periodically: changes to third-party service level agreements (SLAs) and non-disclosure agreements (NDAs) frequently have an impact on risk. Oh, and communicate your risk assessment approach to your vendor or DevOps team if you’ve a bespoke DAM system. They are your partners in managing this risk and should contribute effective strategies of their own.

Conclusion

You’ve uncovered risks, prioritized, and laid down a plan of addressing them. What now? You can wait to see what happens or, as some companies do, plan to build your own DAM system (if you haven’t already). This approach certainly gives you much more control over the risks of using an outside DAM system provider but comes with a hefty up-front and ongoing cost.

How do you perform a risk assessment? What mitigation strategies do you use?