Re: [foxboro] Foxboro I/A OPC
- From: "Cossitt, Howard" <howard.cossitt@xxxxxxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 10 Mar 2006 15:29:23 -0500
My 2 cents for what it's worth.
Right off the bat, I must admit that I work for Invensys. I am not involved
in any present security effort so I still feel my opinion is unbiased with
the following statements:
- Invensys (Foxboro) does have both a team and an approach towards security
effectively taking responsibility for security on the customer's system.
They are actively involved in multiple international security focus groups
globally
- There is an entire security section on our customer satisfaction website
dedicated to our philosophy and approach.
- One example of taking responsibility is equipping every shipped windows
based operator and engineering workstation with antivirus software.
Additionally, you may download updates for this software form our customer
satisfaction website with the assurance that we have qualified it. It's our
demonstration of responsibility towards providing you with a more secure
system without throwing the ball in "the other guys" backyard.
- Another example is the section on our customer satisfaction website for
downloading Microsoft Windows updates. We qualify them through testing and
make them available for you to download with information on the test result.
If testing fails, you also get to see these results ensuring you don't
install these. It is rare to see someone not put the responsibility on "old
Bill" but we provide customers with this service.
- Last but not least, our security team does provide hardening and security
services. These are not just networking experts; these are "process
control" people with security knowledge so they actually do understand that
what applies to IT might not be simply transposed to a control station.
I must agree this says nothing on vision or development with regards to the
products.
I also do not doubt that someone at one time may have made customers feel
like it was someone else's problem.
It is just not the case today.
From our security page, you may contact our security team with your
concerns, they will be more than happy to pass on their knowledge and help
anyone out.
I will e-mail some general info I have with regards to passing data from the
control system to the plant network to you off list (so I may attach some
files) if that can serve as guidance.
Best regards,
Howard C. Cossitt
National Training Coordinator, Lifetime Learning Center
Invensys Systems Canada
Phone: +1-514-421-8095
Fax: +1-514-421-8059
Email: howard.cossitt@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of tjvandew@xxxxxxxxx
Sent: Friday, March 10, 2006 3:04 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Foxboro I/A OPC
Marcel,
Your statement about security issues sums up the story we have been
hearing from Foxboro for as long as I can remember and yet, probably
every reader on this list has their Foxboro control system connected to
another system. Does anyone out there have:
- a Solaris based Foxboro box connected via a 2nd Ethernet port to a
corporate network that also has Internet connectivity?
- a Windows based Foxboro box connected for the same purpose?
- both Windows and Solaris Foxboro boxes connected for the same purpose?
- Any foreign device gateway that passes data to/from the control system?
Only Foxboro users that have no, (and I mean NONE), external
connectivity to any outside network need respond to these questions.
All the rest of us need to worry about security. And we have been. So
it it high time we address the issue, with or without Invensys help.
Security has always been a primary issue with users but Foxboro has
copped out and said that any external connectivity issues are at the
RISK of the users and recommends not connecting to external systems
through one side of their mouth while espousing their great connectivity
advantages through the other. Foxboro should have been working closely
with customers to provide security for their systems because most of
their customers need to pass data to a corporate network. The Solaris
2nd Ethernet solution at least allows the user to create unique login
access and password protection. The Default login and password on the
Windows side of things makes external connectivity a huge risk and
frankly it is inexcusable for a vendor to provide such an interface as
the only solution to its customers.
Using browsers for an HMI would be a huge risk if you weren't going
to
put any access limitations on who the data was served to, and based on
how little Foxboro has paid attention to basic security in their
external connectivity offerings, I'm not going to expect that they will
get a lot better in the future. That will still be left to the users.
But, I think the MESH network infrastructure provides an excellent
opportunity to build a single access point, GB uplink firewall, between
the Foxboro system and a corporate or process information network that
will allow throughput, while at the same time provide excellent access
control to the critical data within the control system. That is what
will be needed if companies really want to get the most out of their
control systems in the future. Data will need to pass seamlessly, but
securely, between the systems.
I wish there was someone from Invensys that was interested in
digging
deep into a solution that could be embraced by both the users and
Invensys. This is not new technology or rocket science but it is of
extreme importance. So far all I've read about the MESH is:
- Don't connect it to any other system, and
- don't EVER run a VLAN on it's infrastructure.
To expect that the need to pass data to external systems will go
away
when the MESH is installed is a pipe dream. Invensys is missing a
golden opportunity to sell their systems if they don't address this
global need. Will someone from Invensys please tell me what their
recommended method is to pass data from the MESH to a corporate system?
I haven't seen a single presentation on this aspect. If you have a
clue, share it with the rest of us!
Here is a simplistic conceptual structure that is being used by the
rest of the modern world today. The worlds entire monetary trade system
uses this model so I think it might possibly be able to be used by our
control systems. Yes, it is complicated, so lets get with the program
an start to address it. How about some support and commitment Invensys?
[VPN Accessibility]
[Business Firewall]
[Business WAN]
^
|
v
[Process Info Firewall]
[Process Info LAN]
^
|
v
[Control System Firewall]
[Control LAN (MESH]
^
|
v
[Your Process Controllers]
It is my vision that the InSQL Server and browser based access to
information would reside on the Process Info LAN. Validated browser
based clients on the Process Info LAN would have access to pull or push
data from/to Wonderwares InSQL or to/from the Business WAN through
firewall accessibility. Wonderware/InSQL would suck data up from the
MESH through the Control System Firewall using a dedicated API. I
realize that this model may not seem pertinent to smaller operations but
if you are connecting upward to any other systems the security
provisions that this model will put in place should be helpful for you also.
Instead of saying connectivity is too risky, and then connecting our
control systems to other systems, lets say: "We are going to connect our
control system to other systems, and then focus on what will make those
connections secure! This concept seems "elementary" to me. What about
all you other users and Invensys?
Cheers,
Tom VandeWater
Weiss, Andreas wrote:
> Hi Marcel,
>
>
>>Is everybody wanting this well aware that this opens the DCS=20
>>systems to an
>>uncontrolled and unsecure platform which is subject for=20
>>hacker attacks?
>
>
> the DCS systems including AW51C with solaris 2.5.1 are already open for
> hackers!
>
>
>
>>Noone from wonderware or Invensys or Foxboro can support any kind of
>>problems on the browser side that may arise from this=20
>>approach.
>
>
> It depends on the way of thinking how Invensys is interested to sale
> support and products.
>
>
>
>>this approach would be chosen, all DCS data would have to be=20
>>exposed to the
>>browsers on a webserver. How can this made really secure and=20
>>stable? Do we
>>want to rely on this technology for business-critical applications?
>>=20
>
>
> Amazon for example has his business-critical application (a book shop)
> already working in the INTERNET. Working for a lot of years.
> Ok, you are right it is not an easy job but it is a task for EVERY
> company in the future.
>
>
> Andreas
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
