Blue Collar and White Collar Security in Manufacturing

I first used these terms in a conversation with a friend of mine who is an internationally recognized expert in security.  We were discussing security in manufacturing and I made the distinction between blue collar and white collar security.  My friend commented it was an interested way to state the problem.

The more I thought about it, the more this might be the right model for manufacturing to ultimately think about security.  This is the first blog post on this topic, with more posts expected, but I wanted to lay out the foundation in this post.

At the 100,000' view, just as all towns look the same, and all security problems look the same.  With security, the canonical advice is that you must protect data at rest and data in-flight.  Stated another way, if you are moving data it must be encrypted and if you are storing data it must be encrypted.  One might ask, "well, does that about cover everything?"  The answer is no.  The obvious example is when processing is occurring ie data is in memory and  not encrypted.  In manufacturing, there are use cases (examples) where, because of the age or type of equipment, it is not possible to have the data encrypted directly to the device.  I will go more into that a little later.

First, let's define blue collar and white collar security in manufacturing.

• Blue collar security would be those individuals who either are physically or need remote physical access on the shop/plant floor to devices and device data.
• White collar security would be those individuals who are in the back office or non-plant floor management.

In large manufacturing plants, the will likely have someone that is IT person that does system administration, system security, networking, and basically gets involved with anything that is a computer or needs to talk to the network.  In very large plants, there will be a team that is typically sub-divided in terms of IT responsibilities.

A key point is that the blocking and tackling of system and network security still apply here, but there are domain challenges that also come into play - as you would see in any vertical.

It is interesting that networking companies like to distinguish between Information Technology (IT) security and Operational Technology (OT) security, but this is not the model I am referring to.

Just as a reminder on OT and IT:

Wikipedia defines Operational technology (OT) has "hardware and software that detects or causes a change through the direct monitoring and/or control of physical devices, processes and events in the enterprise."

Wikipedia defines Information technology (IT) has "the application of computers and internet to store, study, retrieve, transmit, and manipulate data,^[1] or information, often in the context of a business or other enterprise."

In these definitions, OT is a subset of IT and is defined primarily at the hardware/software transactional layer versus the blue collar and white collar security which is at the business security layer.

A simple example regarding some of the challenges in manufacturing regarding security is the network movement of part programs.  A part program is the low level G-Code that is what is sent to the machine tool to actually make the part. 

How this typically works, when either the part is too large for the memory of the CNC controller or there is a need for centralization of part programs, is that a Direct/Distributed Numerical Control (DNC) system is used to make life easier for the operators. Typically, an external computer is connected via RS-232 to the CNC and it is the external computer that feeds (drip feeds) that part program to the CNC.  There is a central server someplace in the plant where the part programs are stored.

That is all fine and good, but then the question becomes, "are these part programs encrypted on the disk of the remote and local systems?", and "are these part programs encrypted when they are moved across the network?"  The answer is typically no.  I bring this up because the attitude is sometimes, "well if it is not encrypted from the computer sitting next to the CNC when it moves over the RS-232 link, then why worry about it in other areas?"

Going back to the blue collar versus white collar discussion, who should have what access to which files on what systems? The policies and governance become critically important.  Simple concepts such as network segmentation and DMZ's (Demilitarized Zones) could mean the difference between losing your IP and keeping it.

This example further brings out why most people in manufacturing are scared to death of the cloud.  They believe it opens up their plant floor, with all of its lack of security issues, to the bad guys.

At the [MC]2 2016 conference, I presented with Bryce Barnes of Cisco on the topic, "Manufacturing Cyber-Physical Security".

•The “Orange Book” was the bible for computer system security in the 80s, 90s and early 2000s

• A — Verified protection

• B — Mandatory protection

• C — Discretionary protection

• D — Minimal protection

• The industry needs a Manufacturing Trusted Plant Evaluation Criteria Standard

     The summary point of this first post on Blue Collar and White Collar Security in Manufacturing is that while the challenges are complex and cannot be adequately defined at 100,000', deciding to not digitize your plant or shop is not an option if you want to stay in business.  This is why thinking about your plant from the blue-collar and white-collar perspective might the conversation to have regarding your plant's security.
 

The Hacking of John Podesta's Email and Security Lessons Learned

I happened to fly back with John Podesta back in May of this year after attending Dr. Dave Patterson's retirement weekend.  The photo is a little blurry because the plane was moving around a little bit.  The point of the photo, before talking about the security around John Podesta's email, is that this is a very smart and nice man and this could happen to most people.  He was in the middle seat because he had to make a last second flight.  I did not recognize him immediately, but then when I did I said, "you know, I thought you were somebody."  To which, he just laughed.  Also, we did not talk about email :-)

It came out yesterday reported at The Hill:

"The hack and eventual release of a decade’s worth of Hillary Clinton campaign chairman John Podesta’s emails may have been caused by a typo, The New York Times reported Tuesday in an in-depth piece on Russian cyberattacks.

Last March, Podesta received an email purportedly from Google saying hackers had tried to infiltrate his Gmail account. When an aide emailed the campaign’s IT staff to ask if the notice was real, Clinton campaign aide Charles Delavan replied that it was “a legitimate email" and that Podesta should “change his password immediately.”

Instead of telling the aide that the email was a threat and that a good response would be to change his password directly through Google’s website, he had inadvertently told the aide to click on the fraudulent email and give the attackers access to the account.

Delavan told the Times he had intended to type "illegitimate,” a typo he still has not forgiven himself for making"

While this brief article makes one feel very bad for Charles Delavan, John Podesta, and most likely the world as we know it (but I digress :-) it does bring out one very solid piece of advice, but leaves out a even more important security suggestion from my perspective. 

The solid piece of advice is what I highlighted in bold above:

•  "A good response would be to change his password directly through Google’s website."

 I would argue that the first advice that the security people on Clinton's team should have insisted upon would be two-factor authentication for EVERYONE's email and communication systems.

Just as a reminder, two-factor authentication or 2FA, is when the ability for you to login requires two different methods to authenticate or ensure who someone really is. In other words, just knowing the login and password is NOT enough.

The most popular for 2FA is using your phone with a token.  For example, you are traveling and you sit down at computer in your hotel to print out your boarding pass and you decide to check your email.

With single factor authentication, only your login and password are asked for to allow you in to your email.  With 2FA, the email service would essentially state, "you have not logged in here before, please send me the 6 digit token I just sent to your smartphone." 

If you have your phone, you see the 6 digit token come up, you then enter it in.  At that point you are asked, "do you want to trust this computer going forward?"  In other words, you will NOT have to put in a new token each time you login.  If this is a hotel computer, you would NOT want to trust this computer, whereas if it was your new MacBook Pro you just purchased, then you would say "yes."  By saying yes, you will not have to enter in the 6 digit token again.

Certainly the advice on going directly to your email provider or going directly to your bank's login (if you received an email from your bank that wanted you to change your password) is the correct advice. BUT, I would argue that ANY online service that offers 2FA, take advantage of it!

So far we have not seen too much in the area of triple-factor authentication:

1. Something you know - your password.
2. Something you have - your smartphone where a one-time token can be sent.
3. Something you are - a biometric such as a fingerprint or retina scan.

Triple-factor authentication is used in intelligence agencies and areas where information protection is at a premium.

An area where many companies could do a much better job is account recovery.  Too often, 2FA might be used for login but NOT for account recovery - which is obviously brain-dead.

 

Four year anniversary of the massacre at Sandy Hook

Today is the four year anniversary of the massacre at Sandy Hook.
Below is from Newton Patch: 

"It doesn't get easier," said Nicole Hockley, mother of 6-year-old Dylan and co-founder of Sandy Hook Promise.

Nelba Marquez-Greene said on the Remembering Ana Facebook page, "People remember our daughter. And we are grateful. No child should die from gun violence. Thank you for still remembering and honoring her."

For more information on all victims of 12/14 on a family approved page, visit here:

 

Home - My Sandy Hook Family

 

This website is intended to serve as a singular place of sharing, communication, and contact with the families of those who lost their lives that day.

 

mysandyhookfamily.org