ENTERPRISESECURITY,PATCHES, ANDVENDORMANAGEMENT

Patch management is a critical aspect of Enterprise Security in all industries. Enterprises should already have a patch testing and deployment policy in place. In most enterprises, the enterprise has business relationships with 3rd party software vendors. However, these software vendors may try to dictate a patch approval policy or expectation that you only deploy patches approved by that vendor to systems with their software installed, under the threat of refusing support for their product. In cases such as these, the vendor’s patch
approval policy should adhere to the enterprise’s internal patching policy, or the onus should be on the enterprise to implement their own designated patch approval and deployment system for that software, or terminate the business relationship with the vendor.

Risk Management
Day in and day out, companies and enterprises engage in Risk Management. Many of them do so responsibly, and knowingly. Some engage in risk management without realizing that’s what they’re engaging in. The concept of risk management is just what it sounds like. In cyberspace, organizations are
faced with the reality that if they are using information technology, they will eventually be victims of a cyberattack. Risk Management is the process of mitigating risk, or accepting it, and being prepared for the inevitable.
One of the facets of risk management or cybersecurity in a broader sense is patching software. Organizations must routinely patch software on their machines, or face an ever-growing probability that they will be easy targets of a cyberattack. However, there is more to it than that. A responsible security
analyst or system administrator must take into account which vulnerability the patch is designed to plug, and then assess the risk of that vulnerability going unpatched. If they determine reasonably that the vulnerability could severely impact their organization they have a responsibility to patch the vulnerability. But wait a minute, not so fast, don’t go deploying the patch to all systems right away. Many patches wind up introducing entirely new vulnerabilities. Even if they don’t introduce a new vulnerability they can still
be buggy, or cause other software to stop operating the way it was designed. This is where a test and deployment strategy comes into play.

Patch Testing and Deployment
If your enterprise security team has reasonably determined a patch must be rolled out, they should have identified the vulnerable systems already. Having identified the systems impacted by the vulnerability, the next step is to test the patch with these systems. Ideally, one would have a separate isolated but identically configured network where they can deploy the patch without impacting operations. This is best-case scenario, and best practice. In reality, many environments simply don’t have the resources to implement this. In those cases, at a minimum they should deploy the patch in stages. Define a “test-group” or subset of the impacted systems to deploy to first, preferably deploying to less operationally critical systems to monitor performance for a designated time before rolling it out to all systems. These standards are considered best practices in the IT industry, and are widely recognized in business at this time. One issue arises when you introduce 3 rd party proprietary software vendors.

Vendor Management
Let’s say you work for Enterprise A, and your company has a specific business need for a product to implement Process B. They have contracted with Vendor C to provide proprietary 3 rd party software to meet the requirements of Process B. Great! A business relationship well done. Not yet. Many software vendors providing this type of service will include a support contract. This is
extremely helpful as an IT manager having a fallback if something goes wrong with the product. However, often times these support contracts require that you not apply operating system or other software patches to systems with their software installed under threat of refusing support or cancelling the contract. This is unfortunately a reality when the business world meets the IT industry. However, any good security professional will tell you that this leaves a sour taste in their mouths. This means that now not only do you have to wait for software vendors to release patches for vulnerabilities, but you also must wait for the patch to be approved by the vendor you’ve contracted with to approve this patch before you can deploy it. Legally speaking, the onus is on the vendor to provide this service to you. In terms of risk however, we’re diving into murkier waters. This could potentially leave your enterprise
open to a known cyberattack much longer than you as a security professional are comfortable with. In cases such as these, I strongly believe that the onus is ultimately with the enterprise to guarantee to their customers, or their employees, or both, that they are following best-practices as closely as possible. To combat this scenario, I would urge Business and IT managers to refuse contracts with vendors who require you adhere to their patch approval policy, unless their policy meets criteria defined by your internal patch testing and deployment policies. Meaning if you have defined your company policy to test patches for 5 business days, and have them deployed within 30 days of release, and the software vendor only takes 5 days to approve patches, then
they are adhering to your policy. However if they only provide quarterly update approvals, then the contract should be cancelled or refused.

Summary
Ultimately, it doesn’t matter who is legally responsible for your patches leaving your organization vulnerable. If you as an enterprise manager trust a 3 rd party company with your patching process, it is akin to an individual trusting an organization such as Facebook with their personal information. You will be viewed as responsible for the cyberattack if one occurs, even if on paper, the liability was with your vendor. If you are responsible for security, you should take that role seriously. Sometimes that means working a
little harder to find a vendor reliable enough to not dictate a patch approval policy, or to dictate one that adheres to your existing standards.