December 13, 2019//Tony HowlettLast Updated: June 04, 2021
Most compliance programs start out with the best intentions and everyone on the same page with the ultimate purpose of the program. This is especially true of third-party vendor access programs where the vendor is usually highly motivated to agree to whatever policies and procedures requested in order to get the deal done. Plus, the internal application owner is willing to accept all commitments and attestations at face value since there is usually some sort of excitement around a new feature, capability, or cost savings the vendor will bring into the organization.
But over time, adherence to the program and its standards and requirements can “drift” as the reality of operating in the real world takes over and practicality takes the place of prudence and compliance. This is where third-party vendors accessing your most critical systems and networks can also bring in security incidents along with all those wonderful things they promised in the sales presentation. This can mean compliance findings, citations, or worst case, a major breach. Let’s examine some of the reasons for a “compliance drift” as it relates to third-party remote access and countermeasures to keep your compliance on track and as originally designed.
Making improvements in your communications, education, technical and audit controls, and ultimately in your program is the only route to continuous improvement and better third party compliance and security.
In many cases, vendors or users ignoring compliance requirements do it out of ignorance. The old “I just didn’t know we were supposed to do that” reason is often truer than an excuse. When rolling out your program, it’s important to communicate with all stakeholders before, during and after the implementation. Following this up with training, repeated more than once, will seal the desired practices into regular operations. Simply hoping that everybody read the new policy and understands how to do it is not enough.
If the vendor offers professional services for implementation including training, this can often be made part of the contract. This makes everyone happy, as the job gets done without any additional workload on IT and the vendor takes responsibility for getting their product properly implemented according to all compliance standards.
While policies and procedures are a necessary base for any program, without the proper technical controls built around them, you are counting on 100% compliance which never happens. Technical controls can be Access Control Lists (ACLs) which prevent vendors from access certain parts of the network or application ports, or they can be limitations placed on user groups or other technical settings.
Like a speed governor on modern car accelerators, technical controls help keep our vendors out of trouble and in compliance. Without them, your compliance can start to drift almost immediately after program implementation.
In conjunction with technical controls any properly designed third-party compliance program should include audit controls. This allows you to review vendor activity and see any attempts to violate policy. This can uncover errant vendors or employee actions, insider threats, and malicious outsiders in your systems so can you discover bad actors (intentional or otherwise) before they can cause a major incident.
Also, most compliance and audit standards, such as NIST or ISO, are going to require audit capabilities on third party activity. And the more granular the audit logs, ideally full videos or keystroke logs, the more valuable they will be in the effort to keep your third-party compliance from drifting away. And good audit reviews should have the possibility of consequences for violators. Paired with well-written policies, this can allow you to enforce your compliance program versus having a set of toothless policies. Audit controls combined with regular reviews and policies that are enforced are the check that catches your third-party compliance program when it starts to drift and brings it back inline.
There is a lot of blame to go around when your compliance is out of whack. Careless vendors, arrogant end-users, and unsupportive management can all contribute. But if an element of your program is consistently ignored, you have to ask yourself if it is an appropriately designed policy. Sometimes users and vendors work around compliance requirements because there is simply a better (and sometimes more secure) way of doing things. Using the controls described above you can capture these potential flaws, analyze them to see if it is the fault of the program or the violators. A compliance program should never be written in stone and evolve over time to meet new requirements or realities on the ground.
Some compliance “drift” is natural in any new program, whether through imperfect design or lack of the aforementioned controls. Making improvements in your communications, education, technical and audit controls, and ultimately in your program is the only route to continuous improvement and better third party compliance and security.