5.2Vendor and Supply Chain Management

No matter how thoroughly a company secures itself, outsourcing part of its operations means the management level of that vendor directly becomes the company's own risk. As supply chain attacks (attacks that use a vendor or software supplier as a stepping stone toward the real target) increase, how to design the process of selecting, contracting with, and auditing vendors is important practical work for an information security manager.

5.2.1Vendor selection and contractual security requirements

• At the vendor selection stage, evaluation must cover not just price and lead time but also what kind of information security management structure the vendor has--whether it holds ISMS certification, its history of past incidents, whether it conducts employee training, and so on. Because switching costs are high once problems surface after selection, due diligence before the contract is important.
• The contract must spell out security requirements explicitly, not just the scope of the outsourced work. Specifically, it should cover the scope of handling, storage location, and restriction of who has access for the entrusted information, the notification deadline in the event of an incident (for example, reporting within 24 hours of discovery), and data return and reliable erasure at contract termination. With a verbal agreement or vague clauses, it becomes hard to hold the vendor to a breach of contract even if its response is inadequate.

5.2.2Managing re-subcontracting and the division of responsibility in cloud use

• Re-subcontracting is when a vendor further outsources part of the work to another party (a re-subcontractor). Because the re-subcontractor is not someone the company itself selected or contracted with directly, the standard practice is to restrict re-subcontracting in the contract in advance, requiring prior written consent whenever it does occur. When re-subcontracting chains multiple layers deep, it becomes hard to confirm whether the company's security requirements have reliably reached the re-subcontractor at the end of the chain.
• The division of responsibility in cloud use (the shared responsibility model) is the concept of clarifying, between a cloud service provider and its user, how much the provider protects and from where the user must protect it. Generally, the safety of the physical infrastructure, hardware, and hypervisor is the cloud provider's responsibility, while data encryption settings, access permission settings, and OS/middleware patching (in the case of IaaS) are the user's responsibility--and importantly, the dividing line shifts depending on the service model (IaaS/PaaS/SaaS).

5.2.3SLA and security requirements; audit and reporting obligations

• An SLA (Service Level Agreement) is an agreement that numerically promises the quality level of the service a vendor provides. Including security-related items in the SLA--frequency of vulnerability assessments, response time in the event of an incident, an obligation to cooperate with audits, and so on--not just uptime and response time, turns "please handle this properly" from an abstract request into a verifiable standard.
• An outsourcing company has a responsibility to conduct regular audits of its vendor (on-site audits, document audits, verification of third-party certifications, etc.) to check whether the security requirements set out in the contract and SLA are actually being met. It is also important to spell out the vendor's reporting obligation in the event of an incident in the contract, arranging a staged reporting flow--an initial report within a set time of discovery, followed by a detailed report--to prevent a delayed initial response when damage is spreading.

Consider an e-commerce company that outsources payment processing to an external cloud-based payment agency service (SaaS). At the vendor selection stage, the information systems department conducted due diligence on three candidate companies, checking for ISMS certification, past disclosed incident history, and whether employee training was in place, and selected a provider that held certification and had no major incidents over the past three years. When concluding the contract, the SLA explicitly stated, with numbers and deadlines, "quarterly reporting of vulnerability assessment results," "an obligation for an initial report within 4 hours of an incident being discovered," and "an obligation to cooperate with an audit once a year." Once operations began, the information systems department correctly understood the division of responsibility: because the payment agency service is a SaaS, encryption of credit card data and the physical security of servers are the payment agency's responsibility, while what the company itself directly manages is mainly limited to managing the API keys passed from its own site to the payment agency service and the front-end implementation on its own side within the payment flow. One day it came to light that the payment agency was planning to further re-subcontract part of its log analysis work to another vendor, but because the contract included a clause requiring "prior written consent from the outsourcing company for any re-subcontracting," the e-commerce company was able to follow a process of checking the re-subcontractor's security posture before consenting. Without this clause, there would have been a risk of the company's customer payment data passing, without authorization, to a re-subcontractor that had never gone through a selection process. At the regular audit six months later, it came to light that the SLA's "quarterly reporting of vulnerability assessment results" had been missed once, and the information systems department treated this as a contract breach and issued a corrective request. Designing this whole flow--due diligence at selection -> spelling out requirements in the contract -> correctly understanding the division of responsibility during operation -> prior consent for re-subcontracting -> verification through regular audits--allows an organization to keep tracking changes in a vendor's management level and any chain of re-subcontracting.

5.2.4Section summary

• Due diligence before the contract matters at vendor selection. Security requirements must be spelled out in the contract
• Re-subcontracting is restricted in advance by contract, and written consent is required whenever it occurs
• The cloud's division of responsibility (shared responsibility model) shifts by service model (IaaS/PaaS/SaaS). Include security items in the SLA and verify them through regular audits