PI and the Killer Robots, Inc. CTF Environment, Part 0x02

Blog Post created by hpaul Employee on Dec 14, 2016

Are you looking for an edge in the PI challenges of the S4x17 CTF competition?  If so, you’ve come to the right place!  Herein lie PI security principles and architecture information that will benefit any taking on the challenge.  If you want a refresher on what the CTF event is all about and the Killer Robots, Inc. environment, see last week’s post which gave background on the competition and what is at stake.


PI Security Primer

While there have been volumes written on PI security, we have provided a distilled view of the most pertinent and frequently requested information.  The one-stop shop for quick access to all things PI security is the PI System Cyber Security page on the support site.  If you work with (or in the case of the CTF competition, against) PI, then I highly recommend bookmarking this page, which connects you to documentation, KBs, tools, alerts and more.


For a prospective competitor looking for a crash course on priority defensive measures for a PI System, KB00833 – Seven best practices for securing your PI Server is a great place to start.  In this KB and across our resources you’ll find that Windows Integrated Security is a focal point.  Adoption of this authentication protocol to the PI Data Archive over trusts and explicit login provides stronger authentication and enables features such as transport security.  You may also want to add KB01295 - Risks of using the PI System as an input for a control system to your short list for review, to familiarize yourself with the risks and defensive measures associated with output points.  The coveted Golden PI flag may not be possible otherwise....



With respect to architecture, the PI System can be logically represented as three functional layers based on the roles of components: Collection, Management and Delivery.  Each layer is represented graphically in Figure 1 below with the relevant software components at each layer.

  • Collect - PI Connectors and PI Interfaces pull in data from many disparate sources.
  • Manage - PI Server (PI Data Archive, PI Asset Framework) store, aggregate and contextualize data in a common format.
  • Deliver - PI Coresight and other access tools allow users to visualize data.

Figure 1: Functional layers of the PI System.


What a lovely graphic... but let's get to what this audience cares about.  Now that you have the functional layers and the related components, the next logical question is where they reside in a deployed system.  The OSIsoft environment submitted to the CTF competition for the S4x16 Conference in 2016 was modeled after a traditional operation scenario for the PI System, where the data is collected, managed and delivered in the OT space to be consumed by operators and engineers at a plant or facility.

Figure 2: PI System Roles in an Operations Scenario


An example architecture using this paradigm is represented below in Figure 3.  This more tangible example was taken from the Life Sciences Industry Reference Architecture.  Note that there are other reference architectures for several industries available here on PI Square, compiled based on best practices for the PI System and the needs of the specific industry.


Figure 3: Operations PI System deployment from Life Sciences reference architecture.


The highlighted components in Figure 4 are the minimum representative components that the OSIsoft team chose for the simplified architecture in the S4x16 CTF environment.  A few notes about each of the components are included below.  The flags superimposed on the image correspond to the placement of challenge flags throughout the environment.  Some of the flags deeper in the network could only be exposed after capturing flags upstream. 

  • Terminal server: provide access to PI utilities and thick clients such as PI ProcessBook.
  • Web server: host the PI Coresight web application for visualization of PI data.
  • PI Data Archive: provide access to historical and real-time data
  • PI AF Server: model physical assets to provide context to data streams, including PI AF Server as well as the PI Analysis Service
  • PI Interface node: feed data to the historian through the PI OPC DA Interface and a local OPC Server to act as a mock data source to represent information from the control system


In S4x17, we are expanding the environment to include the business network as well.  In this Operations and Business scenario, data from one or many sites, presumably separate plants or facilities, is sent to a centralized location for consumption. This architecture spans both the IT and OT networks.  The next post will show how the CTF environment architecture was updated for this scenario and start talking about kill chains


Figure 4: PI System Roles in an Operations and Business