Best Practices for Secure and Effective Third-Party PoCs

Establishing a proof of concept (PoC) with a third party presents several security challenges, including granting access to network resources and sensitive data. This piece explains how to balance the needs of the business and security by establishing policies, procedures and resources for safe and effective PoCs.

PoC Risk Assessment

We suggest the security and sourcing team establish an initial risk assessment to discern the level of risk the third-party PoC presents to the organization. Consider incorporating the following questions into the PoC risk assessment prior to moving forward:

• What is the business objective of the PoC?
• What type of data is required to support the PoC (i.e., sensitive, personal or anonymized data)?
• What level of access is required (onsite vs. remote)?
• What is the expected duration of the PoC?
• What is the internal resource requirement?
• Are measurable outcomes established to support the PoC?
• What’s the definition of success?

PoC Access Requirements

Next, establish access required for the PoC. Typically, most PoCs falls into three categories:

1. Administrative accounts. These are user accounts with elevated privileges and access to all standard user and privileged operations.
2. System accounts. These accounts are built into systems or applications, for example, root on Unix/Linux systems or administrator on Windows systems.
3. Operational accounts. These are user accounts with elevated privileges for managing software installation and remotely supporting other systems. Operational accounts include both shared accounts and service/app accounts.

Securing Access for PoCs

Once you understand the access required for the PoC, you need to secure it. At a minimum, consider:

• Implementing robust controls over configurations at both ends of the connection to prevent potential malicious use.
• Logging and monitoring all PoC access communications.
• Securing remote access devices by deploying localized defenses that restrict access.
• Restricting the access: Limit access to specific times and to only the applications necessary for the PoC.
• Using robust authentication methods for access and encryption to secure communications.
• You should also focus on securing any privileged accounts required. This should be a two-step process:
  1. Enforce strong authentication for the PoC, using multifactor authentication (MFA), digital certificates, etc.
  2. Establish granular authorization controls. The more granular the authorization settings, the better the security. Elevated privileges should be granted following the principle of least privilege, whereby minimum access privileges are granted on a business-need-to-know basis for the limited period needed to complete the PoC. This access should be contained to a specific network segment combined with singular server access that’s time-limited.

PoC Risk Management Principles

Specific vendor risk management principles should be established prior to commencing with the PoC. Ensuring the prospective vendor does not have excessive access to network resources and data should be a priority. These risks can be mitigated by:

• Performing preliminary due diligence. The security and sourcing team should establish an initial set of due diligence on the vendor prior to gaining access (and prior to any contractual agreement). This should range from ensuring the vendor is financially viable to independently assessing its security posture. This will help ensure any material findings are addressed prior to the agreement and can be used as leverage to remediate.
• Establishing an environment dedicated to PoCs. Consider using a virtual or cloud environment stood up temporarily in support of the PoC with the appropriate security controls, such as:
  • Monitoring sensitive data.
  • Establishing access controls.
  • Monitoring access to the platform.
  • Detection of the introduction of malicious code.
  • Ensuring the full deletion of data once the PoC ends.
• Leveraging policy and contracts: Spell out your expectations clearly within the contractual agreement. Requirements should include:
  • Some form of non-disclosure language.
  • Right to audit the PoC vendor’s environment.
  • Specific data safeguards, such as the use of encryption.
  • Background checks on individuals who will be granted access.
  • Just as with the technical environment, deletion of data once the PoC is completed should also be stipulated in the contract.
• Balancing access controls with business requirements. Ensure the controls are not onerous and do not impede on productivity. The introduction of onerous security controls will undermine the PoC and business objectives that can cause friction across the organization.

Successful, secure PoCs require striking a balance of security and productivity, so the business can meet its objectives and continue to conform with security policy.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.