Skip navigation
All Places > PI Developers Club > Blog > Author: Bryan Owen
1 2 3 Previous Next

PI Developers Club

34 Posts authored by: Bryan Owen

At vCampus Live 2011 you might remember Joel’s (aka SCADAhacker) demo scenario starting with a corporate user who opens a poisoned PDF. After loading a RAT (remote access Trojan) to reliably control the victim machine, he shows the ‘Pass the Hash’ technique for pivoting within corporate networks using legitimate credentials. In the classic PtH scenario the attacker takes control of a domain. 


The tools used in Joel’s demo are readily available to 'casual' attackers. More to the point, attack tools continue to evolve with more powerful exploits. In fact, the latest WCE tool is now kerberos aware. So too, our cyber defenses must evolve.


Since the PI System and most corporations rely heavily on Windows integrated security you should be in the know about Pass the Hash. In my view, Microsoft has declared war on Pass the Hash. The purpose of this post is to call your attention to the TechEd 2013 session featuring detailed information and mitigation advice regarding PtH.


“Pass the Hash and Other Credential Theft and Reuse: Preventing Lateral Movement and Privilege Escalation”


I highly recommend viewing the TechEd recording and slide deck.  Here’s my take on the top 3 mitigations with some PI System spin:

  • Mitigations 1 and 2 are quick wins. Don’t be administrator, at least, not all the time! Enable full UAC in Windows Vista and later.  The same is true for the PI System.  Administrator and piadmin access should be reserved for initial provisioning and disaster recover tasks. Don’t put your data (and systems) at risk due to unnecessary use of full permissions.
  • Mitigation 3: Restrict inbound traffic using Windows Firewall.  Your organization needs a way to impede unapproved lateral movement on the network. The Windows firewall is built-in... just do it.  While you’re there, get tough on outbound rules too, at least for your servers and interface nodes.

If you’re like me, you’ve learned to appreciate system defaults whenever possible. Outbound connections are allowed by default so you know there is going to be some extra effort and testing to block by default.  The observations below are meant as a starting point especially for those with a dedicated PI Server. Other apps running on the machine may require additional rules.


Observations with Windows Firewall Outbound Connections set to Block by Default

  1. Perhaps the first thing you might notice on a test VM is loss of network connectivity. Like a real server you’ll want to configure a static IP so the DHCP ports need not be open.
  2. Assuring kerberized logins with the domain controller are possible was a more obvious need. Sadly none of the built-in rules seem appropriate. Instead 2 rules were added to allow outbound connections to the following remote ports. Scope these rules for connection to domain controllers. You might need a third if your DNS is separate from AD.
    1. UDP rule – Local Ports: All, Remote Ports: 53, 88,123,389,464,3268
    2. TCP rule – Local Ports: All, Remote Ports: 88,389,464,3268
  3. Group policy support is recommended for domain members but not required. The following 3 built-in rules should be enabled to allow processing of group policy.
    1. Core Networking - Group Policy (LSASS-Out)
    2. Core Networking - Group Policy (NP-Out)
    3. Core Networking - Group Policy (TCP-Out)
  4. You might be expecting the PI Server to require a 5450 outbound rule. Not so, inbound rules are sufficient to allow the PI Server to respond to client connections. However a PI HA Secondary server will need an outbound rule to allow connections to the primary.  Similarly PIAFLink replication also needs an outbound rule to connect to a remote AF service. As such the rules should allow outbound connections to the following remote ports for PI and AF respectively. Incidentally, these rules are also applicable to interface nodes and other PI System roles acting as a client.
    1. TCP rule – Local Ports: All, Remote Ports: 5450
    2. TCP rule – Local Ports: All, Remote Ports: 5457, 5459

As a final tweak the above rules can be assigned to the applicable service. First though you’ll need use the Windows Service Control utility to ‘unrestrict’ the service. Then select the respective PI service on the Programs and Service tab of the Window firewall rule wizard. Yes, we are planning for ‘restricted’ mode services but that is a future discussion.

  • SC sidtype pinetmgr unrestricted
  • SC sidtype piaflink unrestricted

In summary, Microsoft's top 3 PtH mitigations make sense for a modern PI System and are in direct alignment with OSIsoft best practices. I hope this post was useful for understanding some of the relevant changes in our cyber ecosystem and helps you identify synergies for more efficient defensive initiatives.  Thanks for listening.



Before taking a stab at telltales of a fragile system, why is a cyber security guy talking about fragility anyway?


The process control engineer in me is more accustom to the idea of system stability. Think about system response to a bump test when you are tuning loops. Ever have one get away from you? Set off an alarm? Or even cause a trip? Perhaps it’s at these times that system instability flirts with fragility.


But wait, there is more to fragility. Fragility has an aura of permanence like broken glass. What about the fabled blue screen of death (BSOD)? BSOD is certainly more than just bad luck and most would agree the experience is a hassle. I once experienced a BSOD during defrag resulting in a system that could no longer boot.


Perhaps instability and a fragile system make a perfect storm?


Back to why a cyber security guy is talking about fragility. Fragile can be used to describe systems that are both easily trashed by malicious or inadvertent activity and are hard to recover.


So with that intro, what are the telltales of a fragile PI System?

  1. If you’ve never tested disaster recovery… your PI System might be fragile.
  2. If everyone runs as administrator or piadmin… your PI System might be fragile.
  3. If you open shares to folders on the PI Server… your PI System might be fragile.
  4. If all PI Server archive files are writeable… your PI System might be fragile.
  5. If your servers are running Windows NT or 2000… your PI System might be fragile.
  6. If your only server reboots are due to power outage… your PI System might be fragile.
  7. If the PI Server out of order event count is high… your PI System might be fragile.
  8. If you discover applications that you don’t know where they came from… your PI System might be fragile.
  9. If you have to take a laptop with you on vacation… your PI System might be fragile.
  10. If your home PC is more powerful than your PI Server… you might be a geek!

All kidding aside, as a security guy the main reason for this post is to strongly urge you to plan a disaster recovery drill in the near future. This week’s copycat cyber-attacks in Korea are reported to include the destructive wiper virus. If you’ve been lax on PI System backups now is the time to review your plan.


While fragility is seemingly unavoidable in environments tied to plant operations, good preventative maintenance practices are still necessary. Of course, avoiding fragility isn’t the goal. You’d rather operate with stable and resilient systems that you can count on when you need them the most!

“Security in Knowledge” – Commentary from RSA Conference 2013


At over 20,000 attendees, RSA USA is arguably the largest annual gathering of folks in the cyber security industry.


Like last year, I grazed on the periphery of RSA. Other OSIer’s had full conference access. The B-Sides SF event continues to provide the most bang for the buck ($20 instead of $2000 registration). Likewise the California PUC thought leadership series event on cyber security was free. Both of the former were tight knit and provide good interaction. The RSA Expo was extremely busy but complimentary passes make it a bargain too – these include access to many of the keynote presentations.


Rhetoric and hype are consistently in excess at RSA and rose to new found levels this year. The recent State of the Union Executive Order announcement with a presidential directive on critical infrastructure resilience probably would have been enough to keep the spin room busy. But it was Mandiant’s carefully timed APT1 report that seemed to whip the conference into a state of frenzy.


Suddenly, critical infrastructure protection is ‘cool’ for mainstream cyber security pros. This buzz almost stole the show from the conference theme related to big data security.


The Mandiant booth was packed. APT1 fact sheets were very well done, with one case illustrating the details of espionage attacks on the energy sector. In short this is spooky stuff. The problem with creating so much fear is it can be paralyzing. OMG, everyone is getting hacked, these guys are unstoppable – why try?


In one form or another I heard this concept play out over and over. Top experts are struggling to answer the question: “Are we more secure than we were 10 years ago?” Several of these security leaders are calling #FAIL on themselves and the whole security industry.


Cisco’s John Stewart seemed to handle the question better than most. After suggesting the question is rigged for good debate he offers sobering advice: a sure way to get hacked is to do nothing on cyber security.


This gets me to the main topic of this post. If you are wondering what to do relative to PI System security, your plans should include updates as a priority. PI Server 2012 provides significant security benefits. Also we continue to recommend Windows Server Core as the most secure operating system platform for PI System servers.


Finally, if you find yourself paralyzed by all the hype please contact us.  We do offer security advice for the PI System.  Let’s have a conversation about PI System security.  Or come join your peers at the OSIsoft Users Conference security workshop and training. I’ll see you there!

BlueHat v12 included a broad spectrum of topics. In addition to Microsoft’s usual gathering of top experts on hot topics like mobile and cloud the program also featured a sobering look at security fundamentals like passwords, pass the hash, and social engineering.


Perhaps nothing new for folks used to the BlackHat/Defcon experience but social engineers are just plain scary! Chris Hadnagy, Chief human hacker at Social-Engineer, wowed the audience with his real life pen-test tales. The clever tricks used to impugn and abuse good natured people are enough to lose sleep over.

  • Chris did a fine job of not blaming end users – it seems humans are just wired to be trusting creatures.  SE’s pen-test engagements are always successful.  In the case history he presented 99 out of 100 employees in a company as ‘drinking the cool aid’. In this case logon to sign up for a new company iPhone. After recognizing the initial phish many employees changed passwords. The pen tester then called the victim posing as help desk – just run this tool (unsigned and hosted on my private FTP site) to clean up your machine. Audio playback of the 1 who stood her ground garnered applause!
  • The key takeaway for me isn’t so much about awareness programs (which are necessary and valuable) rather as a priority accept that social engineering will succeed. Mature security programs must include detection and response capability for such intrusions.

Continuing on with fundamentals was an interesting demo pitting a ‘Pen-Test sniper’ versus ‘Forensic Analyst’. In short, a sniper uses passive techniques as much as possible. The idea is to remain hidden and gather enough information to ‘go native’ by masquerading as a legitimate user. Forensic analysis is way more difficult when a sniper uses harvested credentials. The demo highlighted two common sniper tactics.

  • The first is identifying network traffic to databases.  Unencrypted traffic is studied for weak authenticators and exposure to SQL injection. Only then would the sniper go active to establish a MitM position to attack the database with intent to pwn the server.
  • The second common target is spoofing network shares. A network broadcast signals when users attempt to access a share; if the spoofed response is fast enough an attacker can readily capture the client hash when the authentication method is NTLMv1. Pwnage!

The security fundamentals deep dive featured ‘Pass the Hash’ (PtH) with Mark Russinovich demoing a well-known post exploitation attack tool by Amplia Security called Windows Credential Editor (WCE).

  • PtH attacks have been around for a long time and will continue to be a top threat. Microsoft formed a cross functional task force to fully describe the issue (misconceptions are rampant), prioritize effective mitigations, and provide a focal point for ongoing activities. The recent white paper on PtH is the first work product.
  • The 1st mitigation on restricting highly privileged domain accounts has potential impact related to the PI System. In particular, domain service accounts represent attractive targets for PtH. While most PI System services logon using built-in service accounts, some allow use of domain service accounts. It is important such accounts are configured for least privilege.
  • Similarly, the 2nd mitigation on restricting local administrative accounts also has impact related to the PI System. In particular converting to PI Buffer Subsystem is recommended (configuration for the older PI Buffer Service was logon as administrator). While Microsoft’s advice is especially focused on accounts enabled for remote desktop access it is important to realize service account hashes are also exposed to PtH.
  • The 3rd mitigation recommends restricting lateral movement on the network using Windows Firewall. Inbound network ports used by the PI System are well documented and pose no impediment for implementing Windows Firewall.
  • Summary: Microsoft purposely advises low effort and effective mitigations for PtH risk and impact. It was refreshing to see consensus on the value of SSO as a business imperative. It seems reasonable and practical for recommendations to affect administrative roles rather than standard users.

What you say?  Enough with the fundies, show me the other cool stuff!  You bet. BlueHat v12 delivered on the cutting edge of security as well. Here are my favorites (with luck online sessions will be available soon).

  • Great idea: Gavin Thomas of Microsoft presented on using Windows Azure for fuzz testing. Microsoft requires a minimum of 500,000 iterations on a bug fix to pass SDL. MSRC is using hundreds of machines to fuzz update candidates. Using Azure has been an efficiency boon in time and resources. When you think about it – adversaries have almost infinite time and resources to find vulns, they may even use the cloud to attack. Using cloud resources for fuzzing makes sense. I will be recommending cloud based fuzzing over our current approach.
  • Best scoop: Building Trustworthy Windows Store Apps. You’d expect some hype on Windows 8 at an event like BlueHat. We got the news straight from the Microsoft security designers Crispin Cowan and David Ross. Windows 8 was described as a fresh start. Developers should expect some security rework when porting Win32 applications. In addition, every app in the store requires the compiler defenses. The scrutiny you should expect depends on the capabilities enabled for an app. It’s better to just not use capabilities, be especially careful when enabling the ‘File’ and ‘Network’ capabilities. David Ross posted this best practice article:
  • The new new thing: Chris Hoff, Senior Director and Security Architect, Juniper Networks on the disruptive technology called SDN – Software Defined Networks. Although this talk was a bit like drinking from a firehose, Hoff warned that for SDN we need to learn from virtualization and cloud initiatives. While these innovations offered undeniable benefits but also some security failures. Something as simple as ‘how does a guest VM know that host resources are exhausted?’ were overlooked in the rush to virtualize. Hoff cited his previous BlueHat talk ‘Cloudifornication’ for similar cloud based concerns. It’s likely SDN is something that will touch all of our worlds. His presentation might not be the best introduction but it did put SDN on my security radar.
  • Most sobering: HTML5 to the rescue for XSS? Hardly. Mario Heiderich, security lead at, answers the question about how vulnerable are ‘No Script’ webapps?  Although safer without Java Script, XSS bugs still prove to be quite fatal. For his demo, Mario used regex support in CSS3 to crack a ‘strong’ password in the DOM. I was surprised to see how fast this happened – a user would never notice. Then, to exfiltrate the sensitive data he made use of standard SVG methods.  Yes I am totally freaked out by this. Anyway, in a nutshell HTML5 is coming. HTML5 adds support for powerful features. It doesn’t matter if you use them or not, the hackers can and will. Aside from a good SDL to avoid introducing XSS, Mario’s call for action cited the need for more participation in the HTML5 spec. In the meantime, you might want to buy stock in web application firewalls – although imperfect WAFs can restrict use of HTML features that are not needed in a given web application.

Three very different cyber security hands on labs were offered at VCL12:

  • Improving the Security of your PI System Infrastructure: Whitelisting, Firewalls, & Windows Core (Level 100)
  • Security for PI System Administrators (Level 200)
  • Web Application Security: Introducing the OWASP Tools (Level 300)

Whitelisting, Firewalls, & Windows Core


Every workstation was busy for Improving the Security of your PI System Infrastructure class by Jim Davidson. As an extra surprise many folks were getting their first look at Windows Server 2012!


Jim started with a primer explaining application whitelisting and why this approach is strongly recommended by OSIsoft and other reputable sources (eg SANS, Australian Defence Signals Directorate). The class then began to explore various configurations of Windows Applocker.


Exercising automatic rule generation was a snap.  The most tedious part was assigning the rules to specific groups.  For instance, the rules required for a PI System Manager were generated by scanning the PI and PIPC folders and then granted to a Windows group corresponding to PI System Managers. Finally you set rule enforcement options. We choose to audit Applocker by logging any rule exceptions.  This step helps you verify Applocker won’t interfere with normal operation.


An interesting part of the Windows Firewall lab was about enabling outbound rules. Blocking outbound network traffic goes a long way toward containing post exploitation activity. Especially if the attack relies on outbound access to download additional attack payload.


Jim saved one more surprise in the Windows Core exercise. Server 2012 has a command to add or remote the desktop GUI (most of us didn’t hit enter since it takes a while). But still, converting to ‘core’ has never been easier!  Server Core remains a top recommendation for improving the security of your PI System infrastructure.


Security for PI System Administrators


PI System security is no small task and the exercises in this lab focused on security tools and scripting to help manage the hundreds to thousands and potentially millions of related settings. No wonder this lab garnered an encore session.


We started by working with the official security baselines provided by Microsoft’s free Security Compliance Manager (SCM) tool.  While SCM is very useful for compliance documentation and security hardening tasks, the effort is still significant. This is another proof point supporting Windows Core as the quick and easy approach for a secure PI System server platform.


Our approach uses scripts and utilities to examine security settings embedded in various application and database stores.  The lab highlights scripts driving the recently updated ‘Bandolier’ audit checks.  Anyone using ‘Bandolier’ should welcome the lab manual as useful documentation for the PI scripts.


This lab also introduced Powershell as the successor technology for PI system management scripts. My intention is to sponsor a vCampus community project as the official home for the ‘Bandolier’ PI scripts. Knowing Mathieu and crew it won’t be long before all these scripts are available as cmdlets! Thank you in advance vCampus contributors.


Introducing the OWASP Tools


Most folks don’t come to vCampus Live to learn how to hack. We were compelled to make an exception this year in context of incident response to breach of the OSIsoft partner website.


This lab seemed to attract a tight knit crowd (perhaps it was the focus on a web application or the intensity of 300 level materials).  Imagine my surprise when we learned to hack a web site using a single key stroke!


Once the bug was found it was just natural to see what could be done with it. We followed along as tips from the SQL injection cheat sheet were demonstrated using an image our vulnerable web site.  


Now that the audience was hooked they were guided into the world of OWASP.  Lab machines were loaded with SamuraiWTF and each tool of the web testing framework was introduced. The materials from OWASP include test applications to help understand different classes of defect.


The question I remember most: Is it okay to do this on the internet?  The answer came in a chorus of Nooo!

 “What’s Wally doing? Kill Wally!” was overheard from Team 4 during the VCL12 Security Hackathon Day 0 event.


The team was referring to a possible breach of their PI System by an intruder (OSIsoft red teamer’s Bryan Pope and Luis Moux-Dominguez) using commandeered accounts.  The cast of accounts for the faux company were based on Dilbert cartoon characters. In this challenge, Wally was supposedly off duty and many teams picked up on the unexpected login.  Hooray!


Too bad Wally’s account had domain administrator rights.  Blue teams competing in the security hackathon practiced facing a nightmare scenario – a totally ‘pwnd’ domain. 


Each blue team had an embedded OSIsoft engineer providing technical support (shout out to Brian Deslatte, Dan Fishman, Gary Lee, Hahnming Lee, Jonathan Silvestre, Lily Wong, and Mariana Sandin). Many lasting friendships were made over the course of the 8 hour event… perhaps some rivalries too! 


About half of the security hackathon involved preparing for the red team challenges (instrumenting the system baseline, creating operational dashboards, and adding defenses). Teams could earn points by documenting what they did to prepare.


During the challenges points were awarded based on PI System health and sustained operation. Scoring factors relied on basics like archival rate, connections, uptime, and % good data. Performance indicators were periodically delivered as PI notification content to an automated scoring server.


The day is long and competition intense for a hackathon.  I saw this first hand as teams continued to detect and defend even with the lure of the opening reception during the last two challenges.


At the end Team 2 were top point earners and prize winners.  During the debrief session it was especially interesting to hear about what defenses seemed to work best.  The red team reported once people started changing passwords on the domain accounts it really stopped a lot of things.

Imagine you are the OSIsoft technical support engineer answering an urgent call for help from a customer who has discovered malware on their PI Systems. Yikes!


This is not a drill; a few cases of this type have been reported recently. Given the rarity of such calls we don't have a set playbook. Formal incident response plans are something we are actively working on. So what was observed and how did we do in these cases?


Observation #1 - OSIsoft 24x7 technical support access was essential for timely response.


Perhaps it's just my skewed memory but emergencies seem to occur more frequently afterhours, weekends and holidays. Irrespective of coincidence or malicious intent, problems with mission critical systems demand a timely response.


In one of the recent cases, OSIsoft communication with the customer 'followed the sun' to prescribe advice and address concerns raised in follow up questions.


Observation #2 - Disaster recovery takes on some extra considerations.


Lingering concerns about system security are among the more insidious consequences of cyber breach. Extra security tasks after disaster recovery include making sure credentials that could have been exposed are changed.  In addition to Windows service accounts, attackers gaining full administrative access could potentially harvest credentials from the PI System. Of particular concern are credentials configured for external data sources (AF tables, data sets, and interfaces).  These credentials should be changed regardless of encryption technique. Auditing and security monitoring should be instrumented to alert on attempts to use the presumed compromised credentials.


Observation #3 - Reluctance to share indicators of compromise is common.


While it is good advice to avoid sharing unnecessary details of cyber breach this posture can partially hamstring subject matter experts (kind of like a patient not sharing all symptoms with the doctor).  My advice for critical infrastructure operators is to seek guidance from a professional incident response team. Certainly if there is any indicator specifically related to an OSIsoft application it is appropriate to facilitate community level awareness and response.




Corporate IT departments and anti-virus companies have carried the ball for years in responding to 'run of the mill' computer viruses. Today, this seemingly endless game of cat and mouse has expanded into the realm of industrial software applications and critical infrastructure operators.


Metaphorically like risk of fire... strategies to help prevent, detect and respond to cyber incidents make sense. Specifically for response we intend  to follow a well-developed incident response plan and avoid the proverbial chaos of 'shouting fire in a movie theater'. While cyber incidents affecting our customers continue to be quite rare, recent trends suggest OSIsoft technical support engineers will indeed be among first responders.  From these cases we've identified opportunities to improve especially along the lines of communication norms and disaster recovery procedures.

12-Jul-2012 A Short Story: Vulnerability in Windows Common Controls


Those of you who frequent the OSIsoft technical support site may have noticed the security bulletin related to vulnerability in Windows Common Controls.  Yep, these are the venerable VB runtime ActiveX controls that have been so much fun for first timers and professional developers alike.  Do you remember the cheap thrill the first time you 'programmed' a Listbox?  I do and I owe it all to PI Processbook!


As you might expect the Windows Common Controls are very popular and to this day many applications still depend on VB6 runtimes. At first mention, depending on technology so far past its prime seems a bit tenuous but Microsoft's VB6 support statement comes to the rescue:


The Visual Basic team is committed to "It Just Works" compatibility for Visual Basic 6.0 applications on Windows Vista, Windows Server 2008 including R2, Windows 7, and Windows 8.


That policy got the acid test in April with Microsoft Security Bulletin MS12-027 announcing the update for a critical vulnerability in Windows Common Controls.


So what's the rest of the story?


A common pitfall for developers working on security issues is assuming the job is done when the patch is released. Actually patch availability is a 'hand off' to operational teams. You guessed it, fumble (or 'knock on' for rugby fans)!


In this case a security conscious customer observed the MS12-027 patch for MSCOMCTL.OCX was missing on a few machines.  These machines were part of a PI System and thankfully the customer reported the issue to OSIsoft technical support.  It turns out downstream from Microsoft, our developers had some work to do to repackage the Microsoft update.


For PI System partners and developers in the vCampus community it's possible you have products with the same issue. 


No worries. The OSIsoft prerequisite patch scope applies to the entire machine. The mitigation is complete so long as your app runs on the same machine.


Is that the end of the story?


Well, I'd like to tell you this could never happen again. Oh-no, here we go again. Look at Microsoft updates for 10Jul and the MS12-046 vulnerability in Visual Basic for Applications.  We are testing and watching closely for reports of missing update cases. In addition, a new VBA SDK was made available and will be considered to bundle the security updates in a future release of Processbook.


Moral of the story: a developer's job is never done!


Servicing software is essential for security. Unfortunately, servicing is imperfect today and requires extra effort to close the gaps. Where we can help each other it makes sense to do so.


As a closing nugget, the emerging DevOps movement directly addresses the fumble prone hand off between development and operations. It's too soon to know if DevOps will be more than next year's buzz word but the more I learn about it the more I believe in this approach. [DevOps, Rugged Software, SecDevOps, Visual DevOps, are frequent search words dedicated to this movement].

Many vCampus members are active in other social media communities such as LinkedIn.  As such today's news about a massive breach of LinkedIn user accounts might affect you. It's time to change your password, right?


Probably right for most of us but surprisingly some security experts say not so fast.  How could this be good advice? 


One scenario assumes LinkedIn is totally pwned.  If true, changing your LinkedIn password is a waste of cycles (or worse if on reset you happen to expose a password that is used by your accounts elsewhere in cyberspace).


That being said, if your normal practice is to use a common password across certain web site genre it is a good idea to change those other passwords.  I'll confess, in my case, LinkedIn and Twitter were using the same password.  Yes, that practice is past tense as in dead and buried with Twitter sporting the new password.


As for my LinkedIn password, it is reset but not used elsewhere and assumed compromised until more details emerge. Certainly I expect we will learn more about the LinkedIn breach in the coming days.


In fact there is a bit more right now.  Unfortunately some poor security hygiene at LinkedIn has been reported. Apparently passwords are stored using a straight unsalted SHA1 hash. Hackers have posted millions of hashes on the web like a trophy.


Out of curiosity, I wanted to check if my password was cracked.  The first step was to compute the hash for my password.  While there are plenty of utilities like Microsoft Sysinternals Sigcheck that compute hashes for files, I failed to find one for a password. So here is a code snip that computes a hash for a given plaintext string:

Imports System
Imports System.Security.Cryptography
Imports System.IO
Imports System.Text

Public Module secaudit

Sub Main()

Dim data() As Byte
Dim sha1() As Byte
Dim pass As String = String.Empty

Call ReadPlainText(pass)
If pass.Length > 0 then

'Console.WriteLine("pass:" & pass)
data = Encoding.UTF8.GetBytes(pass)

Dim sha As New SHA1CryptoServiceProvider()
sha1 = sha.ComputeHash(data)

Dim sb As New StringBuilder(sha1.Length * 2) 
For Each b As Byte In sha1 

Console.WriteLine("SHA1:" & sb.tostring())
end if

End Sub

Sub ReadPlainText(byref pass as string)
Dim info As ConsoleKeyInfo

'use ReadKey for computing password hashes
Console.Write("Plaintext: ")
    info = Console.ReadKey(True)
    If info.Key = ConsoleKey.Enter Then
        Exit Do
        pass &= info.KeyChar
    End If
End Sub
End Module

You really don't need to write code since this function is available on the web but it just didn't feel right to enter my password on a hacking web page.  Regardless, the very next place I went is to test the hash at a web site called md5decrypter.


The site has a fairly extensive set of tools. This form will allow you to compute hashes.  This one will check to see if the SHA1 hash has been decrypted.  Note, not all IT departments allow access to dual use hacking tools, such as those found at


If the hash is cracked on this site or not is a bit moot.  SHA1 is known to be insufficient for today's computing power and all LinkedIn passwords should be assumed compromised until more details are made public.  However, this exercise does help illustrate one benefit of choosing a good password!


PS. Curiosity killed the cat.  Indeed, my password was cracked.


Update1:  (forwarded from Paul Gusciora)


LinkedIn investigating reports that 6.46 million hashed passwords have leaked online (update)




Website  will check if your password can be found on the list of stolen hashes. Bear in mind if you have a common password a positive result may not mean that your account has been compromised




Slashdot discussion:        LinkedIn Password Hashes Leaked Online


 Update2:   <--- be sure to use an "i" not an "l" ; "i" is a legit site.


Update3: CNET is recommending



Bryan Owen

2-May-2012 NERC Updates

Posted by Bryan Owen May 2, 2012

Spring has sprung in most of the US and so have a plethora of bulletins from NERC – the North American Electric Reliability Corporation.


I suspect NERC is off the radar for many in the vCampus community. So as creators of cool apps for the PI System, I thought you might appreciate a roundup of recent updates from NERC.  After all the North American grid is often touted as the biggest machine ever created by humans. With that awesome factoid we can expect to find some points of interest and targets for your next innovations.


The first update topic involves the NERC critical infrastructure protection (CIP) standards. Revision 4 of the standard is now law per FERC order 761. This revision codifies “bright line” criteria on what assets are considered critical to the bulk electric system. The new criteria results in about about 29% of the installed US generation capacity designated as critical (version 4 adds about 146 generators).


Critical assets are then reviewed for critical cyber assets (CCAs) like industrial control systems with external routable connectivity. CCAs and nodes on the same network are subject to the NERC CIP requirements which include a strict auditing regime.


One of the most recent rulings from NERC involves a clarification on remote access (NERC Project 2009-26). In short, remote access creates a significant compliance burden under the existing rules. My advice for solution developers: build as much instrumentation into your application as you can.  To reuse a comment made at the UC, it is much easier to bring the bits to the experts than it is for experts to have access to critical systems.


Also buried in FERC order 761 are strong reminders to NERC to continue fixing other deficiencies in the CIP standard.  Version 5 is currently in a 2nd ballot and comment phase.  A fundamental change in version 5 is adoption of High and Medium asset classifications (everything else is considered Low). Essentially ‘everything’ will be in scope. The version 5 drafting team is also working on details in the standard that have proven to be problematic in practice.


While obvious changes are needed it is far from clear if the CIP standards are heading in the right direction to improve grid reliability. I make this comment in context of the Arizona-Southern California Outage report just released by NERC.


More than 100 notable events occurred in less than 11 minutes on September 8, 2011 that left over a million people in the dark. The report especially highlights the importance of prior planning because there was so little time for operators to react. Like the 2003 outage, automated protection systems using very conservative settings is one of the reasons operators were unable to prevent the cascading affect. In this case some of the protection schemes were found to no longer serve a valid purpose. If you are an engineer, I think you’ll enjoy reading the entire report. Otherwise, jump to appendix B and C for a quick look at the findings.


Like NERC CIP, one of the biggest challenges is knowing what parts of the bulk electric grid are critical at any given time (and understanding what that means operationally). For power grid reliability the path forward includes using more real time data and simulations tools.


Why should security be any different?

March Madness is a wrap, did your picks do well? You can consider the Pwn2Own competition at CanSecWest as a cyber security version of March Madness.


In continuation of a global trend, this year signaled a change in the 'sport of hacking'.  Move over undergrads. Pwn2Own has become a professional contest. It was Vupen's dedicated exploit team versus Google's Chrome security team (both declared victory but Vupen's story won better news coverage).


So yes, cyber security is a team sport.  It is complete with talented athletes, coaches, and trainers. Let's not forget the fans, institutions, regulators, media and the rest of the eco system.   Do you have PI System security superstars on your team?


I'm very pleased to call out a strong cyber security line up for User Conference 2012:


Day Zero


1:45 PM - ISA 99 Workshop sponsored by WBF.  Learn about the ISA 99 standard approach for cyber security.


Graham Speake (Yokogawa), Joel Langill (SCADAhacker)


Day 1


12:45 PM - Product Expo PI System Security Booth


"Open topics like: Architecture, Firewalls, Compliance, Windows Server Core, Services"


Bryan Owen, David Casazza, Gary Seifert, Jim Davidson, John Stawiarski, Martin Bryant


3:55 PM - "Have you done enough with Cyber Security?" (vCampus Live! 2011 encore presentation)


Bryan Owen (OSIsoft), Joel Langill (SCADAhacker)


Day 2


9:40 AM - "Secure, Manageable Application Integration at Detroit Water and Sewerage Department"


Biren Saparia (Detroit Water) and Andrew Ginter (Waterfall Security Solutions)


5:00 PM - Keynote closing panel  "Data-Driven Decision Making"


Panelist Marty Edwards, DHS Control System Cyber Security Program Director


Product Evaluation Day


8:30 AM - PI System Security Workshop


Jed Haile (Idaho National Lab) with Anthony Tang, Dario Amiri, and Omar Shafie (OSIsoft)


Panel from the field: What works, what's challenging, and what can be done to save time and effort.


Panelists (TBA)


In summary, OSIsoft User Conference 2012 is the place to be if you are charged with cyber security for the PI System.  We will make a best effort to share these materials with those who can't attend but contributing in person is the way to get the most benefit from these highly professional resources.


If you are a vCampus member but aren't the 'security guru' - please let them know the place to be and people to meet for PI System security are at the UC.


Your teamwork makes a difference with Cyber security!

Rodney Dangerfield was a hit with his "I don't get no respect" jokes. Maybe every profession needs to lighten up a bit - especially security professionals and hackers. 


But first let's qualify hacking a bit more.  As Joel Langill summarized in his vCampus Live! presentation, when a hacker gains access is the point of no return and the activity becomes an attack. Of course perpetrators of malicious attacks are criminals and for this discussion no longer considered hackers. Criminals are definitely in the naughty category, but what about hackers?


Hackers often exploit bugs that can lead to full control of an application, server, or even a control system. In this light, bug hunting is a profession that is kind of dangerous and doesn't seem to get respect.  Think about it, a hacker does all this work to find a big, scary bug but then what?  If a hacker doesn't tell anyone the bug might go unnoticed and not get fixed (thus remain open to criminals).  On the other hand someone else might find the same bug and receive credit for all that hard work.  Obviously there is lots of incentive to report the bug.


However, how a hacker chooses to disclose vulnerability is often a matter of philosophy or in some cases a business policy. Regardless who should be told remains a very controversial topic. In the case of industrial control systems, ICS-CERT provides an official channel for vulnerability disclosure. Nice hackers report to ICS-CERT.


Like hackers, vendor coordination with ICS-CERT is voluntary. OSIsoft and other major vendors in the industrial control system community of interest have well established channels with ICS-CERT.


In other words, the effectiveness of ICS-CERT in providing good information to operators of critical infrastructure relies on nice hackers and respectful vendors. So be nice everyone and give a hacker some respect.


Happy holidays and best wishes to all of you.



Of the 'community of interest' conferences out there Microsoft's BlueHat feels most like vCampus Live! 


Don't let the spot light on security fool you. It's more about sharing amongst the elite in their disciplines... folks who instinctively push the limits of technology.  Some are expert in finding seams between networked systems while others are masters of reliable system implementation and management.


For the 1st BlueHat in 2005, the idea of inviting external security researchers on campus was quite 'edgy'.  Today it's clear this quest to build bridges between Microsoft developers and executives, key security program partners, and members of the security research community is resulting in more reliable products.


Here are my favorites from this year's conference by category:

  • Most shocking: John Walton, Principal Security Manager, described Microsoft's cyber 'wargaming' approach on the production cloud for Office 365. I doubt we'll see this trend anytime soon for critical infrastructure but it peaked my interest when he started talking about MTTR metrics and findings they would never have identified using a test environment.
  • Most enlightening: Marcus Niemietz and Mario Heiderich both from Ruhr-Univeristy deep dive into click-jacking and XSS defenses. These topics were a big eye opener to the web security initiatives at While HTML5 is bringing a lot of functionality it comes with complexity; these experts suggest it will be very difficult for developers to get security right. Continuing to be very wary of web technology inside the most critical layers of automation systems seems to make sense.
  • Most sobering: Tie. Jeremiah Grossman of WhiteHat Security on recent web vulnerability trends and statistics. On average 230 vulnerabilities per internet website are observed. Banking is a best performer by sector with an average of 30 vulnerabilities per site. Joe McCray of Strategic Security reinforced this message with his entertaining "You Spent All That Money And You Still Got Owned?" presentation from DefCon.

There were many other great presentations and plenty of opportunities to talk to Microsoft developers.


In turning attention to vCampus Live! 2011, I hope we offer a similar vibe for the community of PI System experts. vCampus Live! is a conference where you can really learn about new technology, what works well, and what can be done should function fall short of expectation.


As a performance domain defined by your most knowledgeable people (and conversely your worse practitioner) information sharing is especially important for cyber security. This year our security focus includes presentations from Joel Langill of Joel is passionate about critical infrastructure protection and has many years of practical industrial experience. 


His research will go into detail on how the infamous STUXNET worm spreads; indeed almost all facilities are exposed in similar ways.  In a second session we'll describe important security practices related to network architecture and active directory.  In particular, we'll highlight what hackers call 'pivot attacks', why you should care, and what can be done to mitigate them.


I look forward to seeing you at vCampus Live 2011!



Graybeards remember when RS232 breakout boxes and protocol analyzers ranked as ninja tools for commissioning PI System interfaces.


Ideally there was a dedicated port for the interface and cabling was a simple matter of determining DTE or DCE pin out.  For alarm printers we would customize a Y cable so the PI System could eavesdrop on an existing serial link (PI event logger and PI UFL stream loader are the usual interfaces). In this latter configuration the trick was to snip the transmit wire to help avoid a signaling disturbance returning from the interface node that could lock up the printer, fill print buffers and generally get you in hot water with the operators.


Fast forward to unidirectional security gateway technology. The data transmission path is usually provisioned with a single strand of optical fibre. Network security enforcement is simple because the destination system has no return into the protected network.


So there it is - a simple idea for security that is too good to just fade away.  Can it really be that simple? Hear all about it in a Webinar on Thursday, September 15, 2011 "Strong Cybersecurity: Power Plant Case Study" from vCampus members Andrew Ginter of Waterfall Security Solutions and Denis Kilgore of DLL Solutions.



It's been just over a year since news of "Stuxnet" rocked the world and the industrial control system community.  How did this destructive computer worm change your profession?


On personal introspection developers of mission critical applications might look back at the year and believe nothing has changed because of Stuxnet... after all, their code wasn't the target. Perhaps others can honestly reflect on having taken a pragmatic approach in review of Stuxnet related exploits and their development practices: no hard coded credentials in my app ; my program files can't be easily spoofed or planted ; my code signing key is secure ; my application doesn't require administrator ; my application always shows correct information .


Kudos if you fall in the latter camp and believe Stuxnet is a call to action for building more secure applications.


Unfortunately, it's my opinion the profession of criminal hacking was most lifted by Stuxnet.  We may never agree on why programmers might choose a career path that can result in such perilous consequences.  The bigger question is how well and how quickly our profession adapts to overcome the will of intelligent cyber adversaries.


Learning more about offensive cyber tactics and forcing security failures can help us improve defensive programming skills.


One idea is to occasionally offer contest based challenges within the vCampus community. Some of the contests would be targeted to advance more secure PI Systems. We don't envision anything as intense as Defcon's 'capture the flag' but we hope there will be enough intrigue to capture your interest and participation.


Feel free to comment on merits of this approach and post ideas you think might be useful.  For preparation in the meantime you might want to brush up on SQL injection tactics!

Filter Blog

By date: By tag: