Skip navigation
All Places > Security > Blog > Authors hpaul


12 Posts authored by: hpaul Employee

There are a couple options to learn about PI System hardening on day 3 of PI World 2018. 

  1. The session Extreme PI System Hardening in developer track 4 at 10:30 AM is a “How-To” session that will take you step by step through hardening a system from the ground up.
  2. The PI System Anti-Hackathon lab on at 1:30 PM is a “Hands-On” session where you can learn about system hardening by experimenting in a sandbox environment with experts to guide you.

Both sessions will make heavy use of the PI Security Audit Tools.  Many are familiar with the audit module of the PI Security Audit Tools, which is used to identify gaps between the current state of a system and best practices.  At PI World 2018, we will introduce the PI Security DSC module which enables PI System administrators to manipulate the security configuration of their PI System components with PowerShell Desired State Configuration (DSC). By leveraging this module, PI System hardening can be implemented in a “configuration as code” paradigm.

Why use DSC for your PI System, you ask?

  • It’s declarative, separating intent, “What do I want to do?” from execution, “How do I want to do it?” This results in:
    • Less complex automation
    • More agility
    • Consistency across environments
    • Functional documentation
  • It’s broadly applicable, allowing you to cover broad scope with the same technology:
    • Use with applications and the underlying OS
    • Establish baselines or harden systems

Want to know more?  Full descriptions for each PI World session below!


How-To: Extreme PI System Hardening (Developer Track Presentation)

High value systems warrant hardcore hardening measures. The PI System resides at a critical junction, communicating across strict network boundaries. Under this paradigm, the PI System acts as a 'safe harbor' for data, defending critical systems by reducing the number of users inside the security perimeter while enabling growth in the number of users getting value from OT data. An application can only be as secure as its operating platform, so this session will start from the ground up. We will establish a solid foundation with advanced hardening measures for the Windows operating system that OSIsoft has collected over many years working with the platform, such as security baselines, PowerShell’s Desired State Configuration, and arcane corners of the Windows Advanced Firewall. With the platform locked down, we will explore application hardening measures built within and tailored to the PI System. Emphasis will be on using the latest technology and tools available to embrace agility and configuration as code. Examples from session demos will be available on GitHub for administrators who want to try them at home.


Hands-On: PI System Anti-Hackathon (PI System Admin Lab)

In this lab you will be served a big, soggy mess of a PI system – it’s your job to whip it into shape, by applying modern security techniques and best practices. You will have some help - handy scripts to identify the security holes are, references, resources, tips and coaching to help you accomplish your task. Participants will earn points based on the amount and the severity of security issues addressed. At the end of the lab, prizes will be awarded to top scorers. Moderately experienced administrators may have an advantage, but participants at all experience levels will learn concepts applicable to their systems back home.


Go here to register for the PI System Anti-Hackathon lab today!

US-CERT released the alert, Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors, on Thursday, March 15th.  The technical alert includes indicators of compromise (IOCs), technical details on the tactics, techniques, and procedures (TTPs) used by the actors, and security best practices relevant to the campaign. DHS and FBI published this alert with the expressed goal of empowering defenders to reduce their exposure to malicious activity.


Though the Systems Affected section of the alert explicitly identifies Domain Controllers, File Servers, and Email Servers as in scope, many of the defensive measures are relevant to the PI System as well.  The goal of this post is to highlight the measures in the General Best Practices Applicable to this Campaign section of the alert that are relevant to the PI System and point to resources that may assist with defensive efforts.


“Prevent external communication of all versions of SMB and related protocols at the network boundary by blocking TCP ports 139 and 445 with related UDP port 137. See the NCCIC/US-CERT publication on SMB Security Best Practices for more information.”

  • PI System core functionality does NOT require SMB, however SMB is a default feature of Windows and may be enabled on your system.  For guidance on SMB and the PI System, see AL00318, WannaCry Ransomware Attack FAQ.


“Segment any critical networks or control systems from business systems and networks according to industry best practices.”


“Ensure the use of PowerShell version 5, with enhanced logging enabled. Older versions of PowerShell do not provide adequate logging of the PowerShell commands an attacker may have executed. Enable PowerShell module logging, script block logging, and transcription. Send the associated logs to a centralized log repository for monitoring and analysis. See the FireEye blog post Greater Visibility through PowerShell Logging for more information.”

  • Most PI System administration tasks for the PI Data Archive and PI AF Server can be performed remotely with the PI System Management Tools, PowerShell Tools for the PI System, or PI System Explorer over PINet.  For remote administration to the OS, the MSDN blog post PowerShell Security at Enterprise Customers  is a comprehensive overview of the security features that make PowerShell the best choice.  Given the manageability and security benefits, we recommend installing the PI Server on the latest release of Windows Server Core and performing remote administration via PowerShell.


“Implement the prevention, detection, and mitigation strategies outlined in the NCCIC/US-CERT Alert TA15-314A – Compromised Web Servers and Web Shells – Threat Awareness and Guidance.”

  • We recommend installing PI Vision on the latest version of Windows Server Core for the reduced attack surface area.  Additionally, guidance for web security in PI Vision is covered in KB01631.


“Implement application directory whitelisting. System administrators may implement application or application directory whitelisting through Microsoft Software Restriction Policy, AppLocker, or similar software. Safe defaults allow applications to run from PROGRAMFILES, PROGRAMFILES(X86), SYSTEM32, and any ICS software folders. All other locations should be disallowed unless an exception is granted.”

  • Guidance for configuring application whitelisting on systems with PI applications using AppLocker is provided in  KB00994.


“Block RDP connections originating from untrusted external addresses unless an exception exists; routinely review exceptions on a regular basis for validity.”


“Ensure applications are configured to log the proper level of detail for an incident response investigation.”

  • Default configuration provides significant information.  See PI Data Archive monitoring in the LiveLibrary for more details on all PI Data Archive monitoring capabilities through PI Message Logs, Connection history and Windows performance counters.  PI System administrators can opt into PI Auditing, which records the data that is added, edited, or removed from database files, as well as other events or changes to configuration that occur in the PI Data Archive to satisfy FDA Title 21 CFR Part 11 auditing requirements.  See Auditing the PI Data Archive in the LiveLibrary for more information.  Enabling PI Audit is not recommended unless the default monitoring is insufficient.  PI AF Server client connectivity logging is covered in KB00412.   PI AF Audit Trail is described in the Audit Trail implementation  section of the LiveLibrary.


“Consider implementing HIPS or other controls to prevent unauthorized code execution.”

  • There are no known compatibility issues with Host Intrusion Prevention Systems and the PI System. Guidance for antivirus and antimalware solutions and the PI System provided in KB01062.


“Establish least-privilege controls.”

  • Permissions required for tasks in the LiveLibrary describes permissions required for common administration tasks. A practical role-based access implementation for Windows Integrated Security in the PI System is described in the PI Data Archive Field Service Technical Standard in KB01702.


“Based on the suspected level of compromise, reset all user, administrator, and service account credentials across all local and domain systems.”

  • Since the PI System leverages Windows authentication through PI Mappings, reset of Windows principals will impact PI System components.  In the event where this course of action needs to be taken, please contact tech support so that important aspects of recovery relevant to the PI System are not overlooked.


“Create and participate in information sharing programs.”


Hopefully the resources in this post help make the best practices relevant to this campaign more actionable for your PI System deployments. 

An updated version of the PI Security Audit Tools is available for download from the tech support site here.  For a list of the changes/improvements in this version, check out the release announcement.


There is also an exciting opportunity to learn more about PI System security and baselining with the PI Security Audit Tools from Anna Perry at the upcoming UC 2017 lab, Extending the PI Security Audit Tools to Meet the Needs of Your Environment at 2:15 pm on the day 3 agenda.  I've included the description below.  If this topic interests you, please sign up when you register for UC 2017!


"How do you baseline the security of your PI Systems? How do you evaluate which defenses should be prioritized? These are questions every PI System administrator faces. The PI Security Audit Tools are a framework for security configuration auditing of PI System components in the form of a PowerShell module. In the first half of this lab, participants will learn how to use the existing tools to evaluate their PI System deployments and use the output to plan and prioritize improvements to their defenses. The second half of the lab will focus on the tools' extensibility. Participants will learn how to extend the PI Security Audit Tools existing libraries to include validation checks specific to their organization's needs and how to implement their own libraries with the tool."

Welcome to the final post of the Killer Robots series!  If you don’t already know about Killer Robots, Inc., see the December 7th post for an introduction.  The December 14th post provided last year’s system architecture and some PI security resources.  Last week’s post introduced this year’s environment and modeled the traversal to the web server with an early flag.


This week, as foreshadowed, we must go deeper.  The web server access following the compromised user was possible due to poor credential theft defenses in the environment.  Credential theft was the path of least resistance due to other defenses in place, such as authenticated access from normal users being limited to the client application since the admin site is implemented separately, strict import folder access preventing access to modify imported displays and IIS hardening to ward off attacks to the platform.


To control the impact of this user’s credentials falling into the hands of our competitors, the environment is set up with delegation, point level permissions and limited access assigned to the user.  Just what they need to do their job.  Or maybe slightly more…


While we took the above precautions, in the event we underestimated our competitors or overestimated our defenses, we also have snapshots of the environment, offline backups and a disaster recovery plan to restore the environment to them with minimal downtime to other competitors.


When putting together your toolkit for the CTF, you’ll want to include the following for taking on the PI challenges:

  • A machine or VM running a Windows operating system with PowerShell available
  • Windbg or your preferred tool for analyzing memory dumps
  • Your favorite network capture tool
  • Link to key PI security references


This concludes the PI and the Killer Robots, Inc. Environment series.  For any taking on the challenge, best of luck and I’ll see you in Miami January 10th!

Hopefully you are here for more of the inside scoop on the S4x17 CTF competition!  Last week’s post provided a primer on PI Security and the system architecture for last year.  This week you will get a sneak peek at the updated environment. If you don’t already know about Killer Robots, Inc., see the December 7th post for the first installment of this series to get up to speed.

When examined from the perspective of the functional layers of the PI System, the S4x17 CTF environment utilizes the operations and business scenario, where the data from one or many disparate sites is sent to a business network. This adds another collection layer in an intermediate DMZ as well as additional management and delivery on the business side.

The diagram below shows an architecture loosely based off the Life Sciences Reference Architecture.  The blue boxes represent assets that are deployed in the virtual environment for the CTF competition and the red flags indicate the quantity of relevant flags for each component.  As indicated, the challenges span the entire environment, from OT to IT.  So many f1r3w@llz, so little time!

But, as we all know, f1r3w@llz != security, they only represent one of many aspects. Our S4x16 environment architecture had 6 steps between the external users and the control system.  The new architecture, with proper network segmentation, lengthens the attack path by 2 layers.  The added components, PItoPI and the site PI Data Archive are framed below in green.  At each of these layers there are many potential threats, and our CTF competitors need to see which ones are missing barriers that allow them to traverse to the next layer.

A skilled attacker will follow the path of least resistance.  To provide a tangible example, let’s look at Bow Tie diagrams for the first two steps of the chain to illustrate the additional dimensions that can be successfully attacked when a system does not have a well-rounded security strategy. 


In the S4x16 CTF competition last year, the competitors needed to gain access to the web server. To do so, they first needed to compromise a user account as the first flag.  While there are many methods they could use to compromise a user, enumerated in the Bow Tie on the left below, there were defenses in place for almost all of them. The environment machines had application whitelisting enabled with AppLocker, firewall rules in place to limit traffic, antivirus, all recent OS patches, among other defenses.  Although none of these defenses are absolute, they increased the difficulty of other attacks such as infecting the system with malware.  The path of least resistance was insecure communication to the web server.  Competitors got a capture of snooped network traffic, where they found a connection to a web server using Basic authentication without TLS, which is of course a huge faux pas. 


Once the credentials were obtained from the network capture, the competitors could access the web server simply by logging in.  No need to find a 0-day and the firewall allows the requests since they appear as normal traffic.  The credentials obtained were for a non-administrative user, but the competitor could now see data and some configuration information that they could recon as they worked towards pivoting to the next layer.

While basic or forms authentication without TLS is an extreme example, it does happen, and the same concept applies to other attack vectors such as phishing or mismanagement of credentials. So, even with gratuitous firewalls, an environment is not impenetrable if other aspects are ignored. To make matters worse for the Killer Robots in S4x17 (or better for humanity if you’re the “glass half-full” type) the CTF network will be exposed to the players as a cross-section, so the CTF competitors will have direct access to several endpoints to attack… 

If you enjoyed reading this penultimate post, tune in next week for the final installment where we’ll dive a layer deeper into some of the specific barriers targeted by flags and give some tips for putting together your toolkit!  In the meantime, you can also check out the S4CTF twitter feed for updates about the other challenges.

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


If you are a PI System administrator, System Integrator or an otherwise security focused professional, you may be interested in the PI System environment at Killer Robots, Inc., the misanthropic company competitors will attempt to compromise at the S4x17 ICS Security Conference Capture the Flag (CTF) competition in a battle for the survival of mankind.  Aside from aiding in the struggle to liberate humanity from the merciless machines, this 3 day event is also a unique training opportunity, as it allows competitors to learn about PI security by going on the offensive on a live PI System environment submitted by OSIsoft alongside other vendors.


The OSIsoft team sought to create a PI System environment that highlights common mistakes, misconfigurations and misuse in a way that is both informative, and hopefully jarring. Inspiration was drawn from case studies, security engineering, 3rd party reports and our own experiences with vulnerability disclosure, so the exercises are grounded in practical application.


What does the CTF offer for a PI System administrator?

  • Exercise your skills in a simulated environment:  Not everyone has a development system or sandbox environment, so this is your opportunity to get a hands on experience exploring a PI System.
  • Cross-train with both IT and OT technologies: The CTF flags include targets against client applications such as the PI Coresight web application in the corporate zone, all the way back to output points associated with a PI OPC Interface in the plant network.
  • See some of the latest security features in action: Features such as transport security will be on display as well as the impacts when they are not.
  • Explore PI System internals: There are some gems hidden in the environment for the most avid PI geeks, such as some exploration into the SQL back end of PI Coresight.
  • Interact with developer technologies: Some exercises will require leveraging developer technologies such as the PI Web API.
  • Work on your OPSEC: Since many attendees are well versed in the art, you may even pick up some social engineering tricks to improve your OPSEC skills.


Throughout the month of December, we will discuss the philosophy, methodology and motivation behind the creation of the Killer Robots, Inc. PI System environment.  To a clever reader, these posts could provide a valuable primer for the competition, but to a clever competitor, the event should provide a better understanding of the PI System security.  The PI System challenges in the CTF will require a breadth of skills and knowledge from the competitors related to basic network packet and memory dump analysis, RESTful web services, PowerShell scripting, arcane ciphers, and most prominently, PI System administration. 


Tune into next week’s post for a survey of reference architecture, security engineering and best practices (or lack thereof) that informed the deployment of our target virtual PI System.  In the meantime, if this post has piqued your interest, check out the S4x17 Conference Site for more information or to register for the event.


PI Challenges at the S4x17 CTF

Posted by hpaul Employee Dec 5, 2016

Brian Bostwick posted earlier about the S4x17 ICS Security Conference (original post here) and I'd like to elaborate on the OSIsoft CTF environment.


The S4x17 Killer Robots CTF environment is designed to be an interactive, fun source of industrial security challenges.  After all, CTF is a great way to explore and defeat ‘forever’ day configuration issues. This year the OSIsoft team has improved and expanded the PI System environment, planting flags inspired by case studies, new security features and threat models.


Below we have a summary of the PI challenges from last year. OSIsoft provided 11 of the 43 total flags for the competition.  There were 5 flags left standing at the end of the competition and 4 flags that were only solved by one team.  The most successful competitor captured 450 of the possible 2025 points from the PI challenges.



Reviewing the logs in our environment revealed that many teams did perform reconnaissance, but did not progress.  Perhaps the low success rate of the competitors has gone to our heads, so this year we are upping the ante.  The first (if any) team that captures the mysterious, illustrious “Golden PI” flag, will win the opportunity to deliver ~3.14 pies to the faces of the OSIsoft security advisory team in attendance.  You heard right, this is your opportunity to exact sweet revenge on a vendor!


Want to learn more? Every Wednesday in December we’ll give an inside look at the CTF environment on the PI Square Security Forum, providing background and perhaps even a few hints along the way.  Search for the S4x17 tag to get all posts related to the event in the coming weeks.


Edit: First post in the series is out. PI and the Killer Robots, Inc. CTF environment, Part 0x01

Bow Tie for Cyber Security Series:

     0x01 - How to Tie a Cyber Bow Tie

     0x02 - Hardcore PI Coresight Hardening

     0x03 - Attack Path of Least Resistance? <-- You are here.


In the last installment of this series, we took a look at a Bow Tie diagram of a PI Coresight deployment and walked through some basic evaluation of the coverage.  In this installment, we’ll talk about how Bow Tie diagrams fit into visualizing attack paths and the cyber kill chain concept!


For the uninitiated, the cyber kill chain is a concept defined by Lockheed Martin which describes the process that a miscreant must go through in order to achieve their desired effects on a system.  You can check out Lockheed Martin’s dedicated page on the cyber kill chain for a rigorous discussion of the topic.  The SANS Institute published an excellent White Paper [PDF] that discusses the Cyber Kill Chain within the context of ICS.


Let’s start with a simple network architecture. We have a business zone with several client machines and a web server, a DMZ with a database server and a single workstation, and finally a control zone with an interface node and our control system (yes, profoundly generic, I know).  We’re going to explore a scenario where a miscreant sabotages the control system to cause physical damage and potential human hazards.

Two possible attack paths traversing our simplified network to the control system are drawn in the figure below.  For each node in the attack path, a miscreant must:

  • Perform Reconnaissance
  • Identify an exploitable vulnerability
  • Exploit the vulnerability to gain a foothold on the system
  • Escalate privileges where necessary
  • Pivot and begin the next attack


If we can detect and block these activities, then we can halt their advance before they reach the crown jewels, our precious control system.


The first attack path begins with an attack from the outside world to a client machine in the DMZ.  This could result from a firewall configuration issue, stolen VPN credentials or perhaps infected removable media.  Once the client node is compromised, the attacker must then go through the steps in the cyber kill chain in order to pivot and attack the next component in the network.  During reconnaissance the miscreant determines the client is running PI ProcessBook, and from the machine it can connect to the PI Data Archive, which would bring them one step closer to their ultimate goal, the control system.  Once they successfully escalated privilege and pivoted to the PI Data Archive machine, they again must progress through steps in the kill chain to pivot and attack the interface node.  Finally, once the interface node has been compromised, the miscreant can mount an attack on the soft and chewy control system, which is now in striking distance.

In the case of the second attack path, the attacker is not able to compromise a client node in the DMZ.  Perhaps that workstation is properly isolated and the controls with respect to removable media are being followed.  In this case, the attacker has to start with a client in the business network.  The attacker could gain their foothold on one of these clients with any number of methods, including phishing or a watering hole attack.  The next closest node that the business network workstations can communicate with is the web server.  Similar to the previous path, at each node, the miscreant must go through the steps of the cyber kill chain to pivot and mount the next attack deeper in the network.

Hopefully a few things stand out from these example paths: 

  • There is benefit in building a defendable architecture.  If the control system has components connected to the internet or the business network machines can make direct connections to machines on the restricted network, then the work of an attacker is simplified dramatically.
  • Attacking even a fairly simple system can become a complex challenge!  There is a reason that the world doesn’t end when a CVSS 10.0 is discovered.  A single exploit can give you a foothold on a machine, but identifying relative position in the network, escalating privilege, and mounting attacks deeper into the network all while maintaining communication externally and evading detection is another challenge entirely.  Even in this brave new world of APTs, there are still opportunities for defense to win.
  • Lastly, in the second attack path, there was an additional layer that the attacker needed to progress through, the web server.  That layer offers many defenses and impact reductions (highlighted in Hardcore PI Coresight Hardening) that could stop an attacker from completing the steps in the cyber kill chain and progressing.


In a few discussions I’ve had with system administrators and security professionals regarding this topic, they’ve indicated that there are plenty of other machines on their network, some of which may be remotely accessible.  Since this approach is modular, this revelation does not interfere from a modeling standpoint.

If there are other machines on the network that are either internet connected or subject to poor controls that could allow compromise through removable media or foreign devices connected to them, these other machines could allow shorter paths to the high value target of the control system.  If we have a Bow Tie for each component, we can use the superposition of Bow Ties in a given path to evaluate the defenses relative to other paths identified.  By looking at the security posture within the context of the full attack paths, we can target weaknesses within the context of the system and prioritize defenses to fortify them.


In the next installment of the series, I’ll discuss some of the implications of this path based approach and how we believe it can provide a common language between the opposing sides of the “IT/OT civil war”.  In the meantime:

  • This example centered around a control system as the high impact target.  What other high impact consequences should we reverse off of to generate paths?
  • Are there any other methodologies you use to evaluate the path of least resistance?


Update: Replaced broken link for Cyber Kill Chain.

Bow Tie for Cyber Security Series:

     0x01 - How to Tie a Cyber Bow Tie

     0x02 - Hardcore PI Coresight Hardening <-- You are here.

     0x03 - Attack Path of Least Resistance?


In my last installment, How to Tie a Cyber Bow Tie, we discussed Bow Tie methodology and how it can apply to software.  As promised, in this installment, I will share an example diagram of a PI Coresight deployment.  Since PI Coresight is a web application hosted in IIS, it is exposed to many of the same challenges, so I started with the enumerated threats and impacts from the web server example in the last edition.  After brainstorming several barriers, I then settled on my four favorite for each threat and impact, displayed in the updated diagram below. 


Barriers that were favored for effectiveness, ease of implementation and wide support of configurations.  For example, one threat is "Exploit Vulnerable Product or Service", essentially the risk is that there is a vulnerability present in PI Coresight or the components it depends on and a miscreant determines a way to exploit it.  Selected barriers against this include:

  • Software Updates: using the latest version of the application which has the benefit of bug fixes and defenses implemented through SDL.
  • Windows Server Core: provides reduced surface area to contain exploitable code.  See Coresight Squared by Lubos Mlcoch for a comprehensive guide on setting up a deployment on Windows server core.
  • Firewall Restrictions: a host-based firewall allows a great deal of granularity, not only limiting the accessibility to incoming threats, but also limiting outbound traffic a malicious application might use to call home for a malicious payload or communicate with a C&C server.
  • Application Whitelisting: can offer significant protection since it can prevent both known and unknown malicious software from executing.  For a primer on setting AppLocker rules on a PI Data Archive, see KB00994.  The same concepts can be applied to other PI components such as PI Coresigh as well.

A few honorable mentions that did not make the list for this particular threat are Device Guard due to limited supported configurations presently and Antivirus as it can only protect against known threats.

Looking at the Bow Tie without any barriers in place can be daunting since there are so many ways in which disaster can strike, but hopefully this diagram with barriers in place tells a different story, showing both the breadth and depth of defenses you have at your disposal.  This huge array of security options is encouraging in theory, but if you only have 24 hours in a day, where do you start?  How do you prioritize which measures make it into your deployment?


A logical first step is to evaluate what is already in place.  Let’s look at the type of coverage we would have after a basic installation, and for the sake of this post, I’m defining a basic installation as follows:

  • Using the most recent release of PI Coresight
  • Applying Windows updates
  • Host based firewall is enabled allowing inbound connections to port 443
  • Delegation configured for the PI Coresight web application
  • Service account given documented level of access to the PI Server

In the diagram above I’ve highlighted the areas that will be covered in this basic scenario.  While there is significant coverage, the first thing you may notice is that there are no barriers currently in place for the threat “Overload Server Resources”. In the previous edition, we identified four possible barriers for this particular threat:


You may also notice that there are several barriers that cover multiple threats and impacts.  These are great candidates to investigate.

  • IIS Role Hardening – 4 (Overload Server Resources, Unauthenticated Access, Authenticated Access, Unauthorized Access to Data)
  • Application Whitelisting – 3 (Client to Another Resource, Spread Malware, Exploit Vulnerable Product/Service)
  • Windows Server Core – 3 (Client to Another Resource, Administrative Access, Exploit Vulnerable Product/Service)
  • Backups – 2 (Tainted Data, Manipulation of Configuration)
  • Credential Theft Defenses – 2 (Administrative Access, Authenticated Access)


Given the combination of the coverage that IIS Role Hardening gives, coupled with the fact that it provides a barrier for our most exposed threat, it is probably a good measure to address first.  Incidence of a barrier is just one of many factors we can consider once our options have been enumerated.  If we can effectively consider the relative effort and effectiveness of each barrier, then that can further aid with prioritization as well.


Hopefully this piqued your interest!  Now that we’ve drilled into a more detailed example with PI Coresight, the next installment in the series will dive into attack paths and start chaining Bow Ties together to get a closer representation of a full system deployment’s security posture, rather than an isolated component.  Until next time, a few questions for discussion:

  • What are some barriers you use which aren’t represented here? 
  • Do you see other applications for this technique that could be useful in planning or analyzing your deployment?


Update: Added links to other parts of the series.

Bow Tie for Cyber Security Series:

     0x01 - How to Tie a Cyber Bow Tie <-- You are here.

     0x02 - Hardcore PI Coresight Hardening

     0x03 - Attack Path of Least Resistance?


Welcome to the first installment in our Bow Tie for Cyber Security series, where we will focus on the use of the risk assessment methodology of Bow Tie analysis to examine the attack surface of software installations and discuss how we’ve used the technique at OSIsoft to examine our own software.  The technique aims to improve the reliability and resiliency of a system to threats overall, regardless of attribution.  While I’ll be sharing this material within the context of countering malicious actors, these same measures can protect against insider or incidental threats to the system as well. 


To put this approach in context, in the early 90’s Bow Tie methodology was adopted and developed into an industry standard by Shell as a technique to analyze and manage risk.  Traditionally Bow Tie has been used within the realm of safety, but the technique is broadly applicable to any situation where there is the potential for harm.  With the convergence of IT and OT, safety and security are becoming more aligned; it’s time that we apply analysis tools from each area for common goals. 


Bow Tie methodology provides a framework to assess risk by identifying the relevant threats, defenses against those threats, impacts and methods to reduce those impacts for any negative event associated with a hazard.  In concept, by placing defenses and reductions in place as barriers, we both reduce the likelihood of the event and lessen the impact of the event should it take place.  The example below is the simplest representation of a Bow Tie diagram.  Within the context of security, we could conceptualize the approach as “keeping the bad guys out” with the measures on the left side of the diagram and “limiting the damage if they get in” with the measures on the right side.


Let’s take a look at an example.  To construct a Bow Tie diagram, we must first identify the hazard.  The hazard could be anything with the potential to cause harm, high pressure steam in a pipe, driving a car, etc.  Next we identify the event, which is an occurrence where control is lost over the hazard such as a pipe bursting, or losing control of a vehicle.  In this case, let’s consider running a web server as our hazard and a web server compromise as our event.  With the event identified, on the left side we can enumerate the all of the threats that could potentially cause the event and on the right side we enumerate all of the potential impacts that could result should the event occur.  After taking some time to brainstorm and research, I end up with a diagram like the one below.  Here I’ve chosen to use broader categories of attacks, but depending on the use case, more granularity can be used when enumerating the threats and impacts.  For example, a developer may want to map specific examples of potential exploits to investigate, while an administrator may find categories more actionable since many specific attacks can be blocked by similar defenses.


After the threats and impacts are enumerated, we can identify defenses to place as barriers between the threats and the event, as well as impact reductions to act as barriers between the event and the impacts. For this post, I chose to focus on a single threat and one of the associated impacts.  The diagram below provides 4 barriers each for the threat “Overload Server Resources" and the potential impact of “Service Delayed or Unresponsive”. 



For defenses, to prevent the server from becoming overwhelmed, we can: implement HA, harden IIS, set up Dynamic IP Address Restrictions or throttle the CPU.  In the event the server is overwhelmed, some examples to limit impact include automatically recycling the application pool, or measures which facilitate response such as event logging, diagnostic data like performance counters and a notification system (pardon the shameless plugs) to alert of anomalous behavior.  This list is by no means exhaustive, but reflects a few effective barriers for an IIS based web server.


This simplified example provides one threat and impact, but there is not a 1-to-1 correspondence between threats and impacts in general.  One of the main benefits of Bow Tie analysis in cyber security is that it provides a way to visualize multiple facets of the security posture of a software module together. Security is about more than passwords and firewalls, but those are too often the only aspects that get attention.  To get a more thorough picture with the web server Bow Tie, we still need to enumerate the barriers for each of the other threats and impacts, which is precisely what we'll do in the next installment.


So, I played it safe this time with a DoS example for a generic IIS web server, but keep an eye out for the next entry in the series where I’ll go into a deeper analysis of PI Coresight with a diagram.  In the meantime, it would be great to hear your comments. In particular:

  • Are you using Bow Tie for your work? 
  • If so, what areas have you applied the methodology? 
  • What are some of your favorite DoS defenses?


Update: Added table of contents with links to other posts in the series.

In an effort to demystify PI security and help our customers assess the security posture of their systems, we’ve developed a tool to help baseline the security configuration of PI System components in the form of a PowerShell module.  The tool performs validation checks for the machine, PI Data Archive, PI AF Server, SQL Server and PI Coresight, indicating areas where the security configuration is out of compliance with best practices, and providing actionable information to address the issue.


If this is sounding familiar, then you have probably seen the announcement for first iteration of this tool on PI Square (OSIsoft Community at the time) or when it was debuted at vCampusLive! 2013.  You may be wondering: what are we doing differently this time around?


For this iteration, we’ve taken the solid framework provided by the original version and enhanced the tool with updates, including:

  • Improved User Experience: a detail report with recommendations for all issues identified during the audit (see attached examples)
  • Enhanced Capabilities: new validations added to several modules based on best practices
  • Expanded Scope: a new module has been added with validation checks for PI Coresight
  • General Improvements: bug fixes and enhancements to the infrastructure
  • Digital Signature: the module is signed to give confidence the scripts have not been altered


Although we’re excited about the improvements to the tool itself, we’re most excited that the tool is now available on GitHub, allowing for continuous improvement, structured feedback and transparent updates.


So, without further ado, please check out the new PI Security Audit Tools repository on the OSIsoft space on GitHub.  There you will find the tool and Wiki with documentation/tutorials for users and contributors alike.  We’d love to get your feedback as a user or your contributions if you’re interested in developing the tool further along with us! 


PI Security Audit Tools Team

Harry Paul Harry Paul

Lubos Mlcoch Lubos Mlcoch

Vincent Kaufman Vincent Kaufmann

James Dryden James Dryden

Ricky Sun Ricky Sun


Update: for those interested in contributing to the project, Anna Perry put together an introductory video PI Security Audit Tools: How to contribute improvements using Visual Studio


Update 2: made updates to the PI Security Audit Tools team roster.