Navigating an Industrial Cybersecurity Proof of Concept (PoC)

This is the second of our two-part series on how to use Proof of Concept (PoC) and Proof of Value (PoV) processes to evaluate industrial cybersecurity solutions. 

A Proof of Concept can help you determine if the product you’re evaluating for operational technology (OT) security is the right one for your organization. Prepare, deploy, execute and summarize to get the most out of your PoC experience.

In part one of our two-part series, Proof of Concept (PoC) vs. Proof of Value (PoV): What Do They Mean for Your Business?, we explore the differences between PoC and PoV. While PoC and PoV outputs are different, they can both be accomplished in similar ways.

Here, in part two, we’ll look deeper at what it means to navigate a Proof of Concept for industrial security.

Proof of Concept Phases

To begin, let’s break down a PoC into four simple phases:

1. Preparation
2. Deployment
3. Execution
4. Summary

Before we get to the first phase, here is a tip for initiating your PoC with a vendor. When you begin, you should receive the following:

• Summary of requirements 
• Pre-install checklist
• PoC sample evaluation criteria (to help you with product evaluations and defining use cases)

Phase 1: Preparation

Defining objectives is the first step in the preparation phase. What do you want your PoC to accomplish? This will help hone and establish your success criteria. 

Here are some success criteria examples. The PoC should:

• Provide visibility and create an audit trail of engineering actions on industrial controllers.
• Detect attacks on the industrial networks resulting from successful hacking operations, malware, ransomware or trojans.
• Identify Indicators of Compromise (IOCs).
• Identify Indicators of Attack (IOAs).
• Develop a complete asset inventory of everything on the industrial control network.
• Gain deep level insight into the industrial network.
• Validate that the correct version, firmware and patches are on the industrial controllers.

After identifying your success criteria, it is time to focus on project scope. A proper scope will ensure you have enough resources to accomplish goals from your success criteria, as well as prevent open-ended product evaluations.

At this stage, you can determine if there are any operational risks that need your attention. If yes, put these in writing as a safety measure. Consider factors such as:

• Planned maintenance periods
• Human risks
• Environmental dangers
• Existing work tickets
• Scheduling or resource constraints

By combining your success criteria and scope, you can determine which parts of the industrial enterprise need your focus. This information is particularly handy during your PoC kick-off call.

Phase 2: Deployment

The deployment phase starts when the vendor’s engineer arrives on site and works with your team to rack and stack equipment. The engineer should configure the equipment, connect it to your network and check it for operational readiness along with tuning.

The engineer should also work with you to navigate the product, provide basic training and help you move toward accomplishing your previously defined success criteria.

Phase 3: Execution

The execution phase is “go time.” It is when the product or service in question gets turned on and the product does what it is designed to do.

During the execution phase, it’s important that the product operates in an uninterrupted manner and is given enough soak time to demonstrate its value. 

Organizations can fall into a common trap during this phase if the product gets pulled out of the environment too early and/or does not get a typical atmosphere in which it can demonstrate its value. 

A typical “day-in-the-life” test for more than one day is essential so you’ll get a good idea (based on the results) about what the product can do for your organization and the value it delivers. 

Phase 4: Summary

Once you complete the run time for the test, your vendor should provide you with a summary. This summary should include a report. The vendor should deliver it to you during a PoC read-out meeting. 

During a PoC read-out meeting, you should be able to see how the solution achieved your defined goals, identified risks and revealed other findings you may need to review or investigate. 

Even though your vendor gives you a summary, this is the time to drill down and ask any (and every) question you have. 

At the end of the summary, you should have a full understanding of the capabilities (and limitations) of the product as it applies to your specific operating environment. No question is too insignificant or silly to ask. Your vendor should be ready, willing and able to answer every question or concern you have. Your vendor wants to be confident that its product is the right one for you, so do not cut this last part of your PoC short. 

A clearly defined project scope, along with preparation, tuning and project execution, will help you complete an efficient PoC to determine if the product you’re evaluating is the right one to secure your operational technology (OT) environment. Are you ready to include OT in your comprehensive cybersecurity strategy? Check out this on-demand webinar: Cybersecurity in Operational Technology: 7 Insights You Need to Know.