PV Fleet Security: Layers of Separation

PV Fleet Security: Layers of Separation

Protect your fleet from hacking or intrusion with these 7 scenarios.

By: Adam Baker

 

We’ve been working on a couple projects lately for big energy companies that want to add monitoring systems on what would traditionally be smaller solar assets not tied into the corporate infrastructure. I wanted to discuss some of the security scenarios and layers of separation between the site, third parties (such as O&M companies), and the corporate entity that protect the fleet from hacking or intrusion.

 

SCENARIO 1:

Traditionally, the site connects (through a cellular connection) to a cloud app. The cloud app pulls data from the site and corporate reads data out of the cloud app. They can allow third party O&M providers access to the cloud data to see what’s going on.

The problem is, corporate requires good analytics. Good analytics require high fidelity data (1-second data). Cloud apps typically only give you 15-minute (sometimes 5-minute data) from devices running at the site. Even if an app could reduce that to 1-minute data, you lose a lot of data resolution and can’t really see how individual inverters perform through clouds, changes in voltage, or other events.

So, going through a third party cloud app doesn’t work for these kinds of applications.

 

SCENARIO 2:

We were going to put in a router with a cellular connection so corporate could get in through a VPN connection. Third parties would come in through the same router, but with a different set of credentials.

The problem with this architecture? Once the corporate connection to the router was established, the third parties were essentially on that network. This was unacceptable.

 

SCENARIO 3:

What if we also added a router in front of the third party? Now the third parties come into the second router through the VPN connection.

Unfortunately, we have the same problem. There is still the potential that third parties can go through two routers and get onto the corporate network. This still isn’t a sufficient level of separation.

 

SCENARIO 4:

We added a SCADA computer configured with two network interface cards (NIC). That way router 1 could talk to SCADA through a NIC, and the corporate network could also talk to SCADA through the other.

The problem here? The SCADA computer could be hacked to enable routing and bridging, potentially linking those two networks.

 

SCENARIO 5:

If we put a firewall between the router and SCADA, and another firewall between SCADA and the corporate network, now we have the ability to manage connections and IP addresses that come in from both places.

This approach probably works for most applications. But if you wanted to add in a further level of security…

 

SCENARIO 6:

Replace SCADA with an OPC server, and move the SCADA computer between the router and firewall on the third party side. Router talks to SCADA, SCADA talks to firewall, firewall talks to OPC.

As an ADDITIONAL layer of security, the firewall on the third party side can be configured to only allow OPC traffic, and the firewall on the corporate site can be configured to only allow Modbus traffic.

Now we have a layer in the middle that only allows one protocol on one side, and another protocol on the other side. This gives us sufficient separation where it’s impossible to get from the third party into the corporate network to do any damage.

This works for most customer applications.

 

SCENARIO 7:

For an even further level of security, you might want to put a firewall between the router and SCADA system. Now you have a third party connecting VPN to a router going through a firewall allowing them only to talk to SCADA, SCADA is only allowed to talk to the OPC server, and the OPC server is only talking the protocol that allows it to collect the data from the devices at this particular site.

Whew!

 

Security/cost balance

As you can see through these seven scenarios, we can easily go from one connection to multiple devices in a network infrastructure. But there’s a balance between the level of security/separation, and cost of all this infrastructure. A 5MW solar site might only have a $60,000 budget for SCADA and controls, and scenario 7 might be $60,000 worth of network infrastructure equipment sitting on top of what was already deployed for the SCADA system.

There are tradeoffs between cost and security, but the degrees of separation achieved between a corporate network and third parties to allow site monitoring and corporate network protection are varied. It’s totally going to depend on corporate requirements for NERC CIP, the budget, and what the already-existing infrastructure allow.

 

 

Adam Baker - PV Solar | Affinity Energy

Adam Baker is Senior Sales Executive at Affinity Energy with responsibility for providing subject matter expertise in utility-scale solar plant controls, instrumentation, and data acquisition. With 23 years of experience in automation and control, Adam’s previous companies include Rockwell Automation (Allen-Bradley), First Solar, DEPCOM Power, and GE Fanuc Automation.

Adam was instrumental in the development and deployment of three of the largest PV solar power plants in the United States, including 550 MW Topaz Solar in California, 290 MW Agua Caliente Solar in Arizona, and 550 MW Desert Sunlight in the Mojave Desert.

After a 6-year stint in controls design and architecture for the PV solar market, Adam joined Affinity Energy in 2016 and returned to sales leadership, where he has spent most of his career. Adam has a B.S. in Electrical Engineering from the University of Massachusetts, and has been active in environmental and good food movements for several years.