Getting a company to embrace information security on a corporate level requires luck, as you will need to engage upper management and gain their support. With these you will at least be dealing with people bound to follow the same set of rules and corporate policies.
Ensuring vendor, consultant and contractor security requires another level of maturity and effort. Properly managing information security aspects within the complex relations with third parties such as service/outsourcing providers, merged or acquired organizations, or even a temporary partnership with another company will require a clear set of rules and leadership. One of the first steps is understanding the concept of downstream liability, and the fact that your company may be found responsible and even pay damages for something done by a third party.
A CISSP candidate is required to completely understand all aspects involved on vendor, consultant and contractor security, be able to contribute to personnel security policies and also identify/implement the necessary security controls in order to minimize the risk when dealing with third parties. This topic is a part of CISSP’s Common Body of Knowledge (CBK) Domain 1: Security and Risk Management.
The complexity of interactions with third parties
In most cases, working with the aforementioned business partners will mean that interactions will be a part of your day-to-day operations. Consider this: you may be required to share office space, software/hardware/firmware, access to information systems and, most obviously, the information itself, including sensitive or even confidential data that–if not handled securely–can cause severe negative impact to your company. And all of this with someone who is not a direct employee of your company and may even be using a device which you do not have any sort of control over.
Understanding and managing these interactions, and how they can affect company data protection, is your goal for vendor, consultant and contractor security. The golden rule is quite simple to grasp: There is no reason you should accept a level of security and controls from any thirdparty other than the same, or even above, as what you have defined as the baseline for your company. The problem is, due to the complexity in interactions with third parties, for some cases this is usually easier said than done.
For instance, you might have selected an outsourcing service in a foreign country. This means that you are required to understand international laws, regulations and even particular aspects of doing business in those countries such as the local culture. These aspects may prove to be a challenge when forcing contracts or specific security requirements in different countries.
A great idea for dealing with third-party security risks is using a defense in deep approach. The different layers of security you will be enforcing for internal employees can, and should, be extended and customized for use with outsiders.
Image 1 – Use a defense in deep approach for both employees and third parties
Assuming third-party personnel will have some level of interaction with sensitive information, they should be trained and made aware of risks and controls quite the same way as employees are. Depending on the level of access, background checks should be considered. Also, information security policies, procedures and guidance should apply just the same. Actually, some additional policies must be enforced, including defining clear rules regarding data ownership and intellectual property, and even operational aspects such as where, when and how a third-party may access or store company data.
All these aspects must be well covered during risk assessments, and since you do not have direct access and control other than within your own organization, this cannot be properly done without a formal Service Level Agreement (SLA).
Service Level Agreement (SLA) and how to benefit from it
As ITIL1 defines, service is a means to deliver value to customers, facilitating outcomes, but without the ownership of specific costs and risks. Therefore, an SLA is nothing other than defining the rules on how this service is expected to be delivered.
Whether you are contracting or providing a service, it is essential that all parties involved completely understand, agree upon and formalize all aspects of service delivery, including information security requirements. As mentioned before, vendors, consultants and contractors will introduce new risks to your organization, so before signing off a contract, all of those must be accessed and the required controls should be reflected on your SLA’s terms and conditions.
Whenever using contractors of any form, you should ensure that you have controls in place to meet corporate due diligence requirements. Exercising due care during the selection of third party individuals is a major concern, because you and your company could be liable for their actions. Again, ensure that your SLA covers all these aspects.
Some issues can be easily addressed in SLAs, such as:
Defining clear security levels: There should be enough information on your SLA to provide confidence that third parties will follow your required levels of confidentiality, integrity and availability whenever handling or storing corporate data.
Compliance with policies, laws and regulations: This item is especially important if you are outsourcing to a foreign country. While it is not mandatory to mention specific laws or regulations, your SLA can be used to define a set of rules that will ensure compliance. It is important to remember that certain laws (e.g., HIPAA, SOX 404) are not internationally applicable, so the third party involved may not be used to that type of compliance or even have no specific knowledge on how to achieve it. Your SLA must be sufficiently clear to address this.
Metrics and on-site assessment: Metrics can be specified within your SLA. You should have the right to perform on-site assessments and test for compliance at the contractor facilities. In some cases you can go as far as defining what sort of forms and tools should be in place to allow for short/long-term assessments or even remote monitoring.
Document exchange and review: Defining a formal process for exchanging data and documents with vendors, consultants and contractors is a great way of ensuring information is complete, truthful and accurate. Controls should be defined to certify that third parties will only have access to information they are allowed to access. If necessary, you can also define what kind of audit trails must be in place.
The right to audit: Your SLA should include a right to audit clause, so that your team or even an independent company can to go to your contractor facility and perform an independent audit to make sure they are complying with the contract and that their facilities are appropriate for the level of security required by your organization.
Incident handling: Even with proper security, incidents are to be expected. Your SLA should define a clear process on how they are handled, communicated and mitigated.
Penalties: In any case where SLA clauses are not met, penalties should be applied on your discretion. These can vary depending on their nature and level of impact. While a smaller incident (e.g., individual malware infection of no consequence) may be dealt with a small discount or even overlooked, severe cases such as data loss/breach should be considered and have proper penalties defined (e.g., unilateral contract ending, financial compensation).
These are just a few of the issues that an SLA can address. It is important to understand that no matter if you are dealing with a corporate-sized vendor/contractor or with an individual freelance consultant, information security controls must be defined based on a proper risk assessment and be formally agreed upon. This is the most efficient way to ensure your corporate data is protected.
It is easy to understand why third parties are such a concern for information security. Having to deal with a whole new set of risks, while having almost no direct control over countermeasures will not make your InfoSec team sleep any easier.
Ensuring vendor security can definitely be a tough challenge, but in no way an impossible one. Having proper risk management and service level processes in place is an essential first step, but it is critical that you understand that your company is the one dictating the rules, and these should be strong enough to do well against any risk scenario.
Just remember that aspects such as due diligence play a major role in interactions with third parties, particularly whenever crossing international borders. Contracts and SLAs are your most important allies, and should be tailor-made to the needs of your organization.
Some important issues you should consider when assessing third party security:
Have we defined what risks arise from third party interactions and the necessary countermeasures?
Are vendors, consultants and contractors been adequately trained on corporate policies and procedures?
How will we handle vendor logical and physical access control?
Are the vendor’s systems secured and interconnected?
Have we defined what sort of data can be accessed by or stored by vendors?
Can a breach at the vendor’s end result in a breach at our organization?
Who is responsible for operational aspects such as patching and securing vendors systems that are stored at our site?
How regularly should we be performing independent vendor security reviews/assessments/audits?
How regularly should we be performing SLA reviews and updates?