What is the best technology and configuration to protect SCADA systems from unauthorized person (outsider and insider) beside using ID and password in SCADA systems? Where can I found more detail about it (technology, product, provider) ?

Q : What is the best technology and configuration to protect SCADA
systems from unauthorized person (outsider and insider) beside using ID and
password in SCADA systems? Where can I found more detail about it (technology,
product, provider) ?


_______________________________________

A : This is a sore subject. There is no good answer to your query. The first
thing I would do is set up your SCADA system on a physically separate LAN and
install a firewall between the two corporate LANs. This will keep casual snooping
from employees and from outside hackers to a minimum. This firewall will have
to be locked down very tightly and administered with care.

Another measure: If you use the Corporate WAN, use a tunneling protocol and
SSL to encrypt. It’s not foolproof, but it will stop most folks from monitoring
internal SCADA traffic on the Corporate networks.

A third measure: Avoid all but the most critical interconnections with other
corporate infrastructure. Keep track of each one, and who has access.

As you see, there is not something you can purchase out of a box.

This is a state of mind in SCADA systems which until recently was relegated
a low priority status. You have a really ugly task ahead.
_______________________________________

A : If your scada system is NT based, you could have it on another domain.
Set up the trust in one direction only. ie Your corporate domain is a trusted
domain of the SCADA Domain. This will allow you to push data out from the scada
system and restrict access.

Passwords need to be secure to do this. Test your passwords with something
like l0phtcrack. Also change them every 30 days. If you need to push data out
then the login used can be of low rights. If you want to check your security,
take a computer hacking course. Some auditing firms offer this.
_______________________________________

A : Building stable and secure systems requires a clearly understood mission
and a well defined set of criteria.

It’s not something you can purchase out of a box.

Cars are built to be crashworthy. They’re built to be safe. Yet everyone realizes
that to be truly safe in a car, you need a competent driver. Likewise, to have
a secure SCADA system with good reliability, you need to have good design policies,
well trained operators, and a solid backup strategy.

No product can sell you that.
__________________________________________

A : For a secured asset, the concensus is defined as something you have, something
you know, and something you are. Biometrics are used with increasing popularity,
and as such, the cost is now a very small item for the piece of mind.

Computer access can be by multiple passive or active methods including: by
network, by radio, by dialup, by login, or by rebooting depending upon what
you allow and need.

The most secure access is NO ACCESS.

This is not always practical, but it works for defense/medical/industrial/financial
industries.

Something you know : passwords, account IDs, Something you have : key, access
card, badge, smart cards, specific hardware, Something you are : finger print,
hand print, retina scan, face recognition

If you only rely on the first item, there will ultimately be someone smarter
than you. There are lots of hardware and software for monitoring. If it is your
network, you should monitor users and warn them and discipline them when unethical
activities are caught.

Regular backups, offline/offsite data storage, seperate fiber networks, equipment
in locked rooms, and workstations with no removable storage are simple security
improvements. Keep in mind that sacrificial systems require little or no security
(but SCADA systems don’t usually fit there) and if MTTR and MTBF and total impact
cost is very low, then security is less important. Also, only installing the
resources and ports you need will help alot.
_________________________________________

A : I think to have physically separate LAN and install a firewall between
two LANs are a very expansive solution. On the LAN , it can use layer 3 switch
to setup VLAN or ELAN. Then, it can be installed with a RAID Authentication
Server for tracing and record all the users who access SCADA system.

========================================

Q : If I use VLAN or ELAN, is that posible for authorized person accessing
the system my SCADA system from other subnet/network segment ?

_________________________________________

A : It is possible for authorized person to access your SCADA system from
other subnet/network segment, If you don’t have security policy or IT manager
to control your owned IT staff(s) to access and configure your network switches
& authentication server. Sometime, you might need your IT staff(s) to trouble
shoot your network via Telnet or Internet from remote sites, then you shall
get someone closely monitor his activeties, once complete the works, you shall
close the Telnet funtions, and check are there any chancing of configuration.

Noted: If you have a remote workgroup or network need to access SCADA via
Internet, you shall implement VPN + DMZ zone + firewell on both side.
___________________________________________

A : Carrying the discussion of security of SCADA systems one step further
– there have been a number of recent posts discussing the issue of separating
the corporate LAN from the SCADA LAN using various methods – the most popular
of which is probably a firewall and possibly additional encryption technology.
What is happening now however is that IP technology is extending out to remote
locations. In the case of electricity distribution networks or water or waste
systems, there may well be standard IT hardware located at remote substations
or pumping stations. With the availability of high speed HDSL modems and fibre
it is now possible to have multi megabit/s comms paths to these remote sites
and it makes sense to run standard IP over these links to ‘mux’ together whatever
functions you wish to provide at the remote site including SCADA access. RTU’s
and IED’s are now freely available with 10BaseT or optical Ethernet ports on
them.

Gone are the hardwired serial links carrying an obscure protocol (from a hacker’s
point of view) such as DNP. If he/she can break in to the remote site with a
laptop and network card they can plug straight into a 10BaseT port and they
are away, straight into the internal SCADA network.

This suggests that some serious security issues need to be addressed on any
remote network terminations where access is not strictly controlled. Current
incarnations of DNP LAN/WAN capable RTU’s have minimal security capabilities
apart from restrictions on the masters they allow connections from. They are
not capable of operating in a secure IP environment using SSL or other encryption
technology. (I know that the DNP User Group is currently working on solutions
to this problem but they are not there yet.)

The only simple solution I can think of at present is an additional firewall
between any remote network and the internal SCADA network which tightly locks
down the allowable connectionsto the internal network and which will probably
be a pain to administer.
_________________________________________

A : With firewall in place, you also can consider to add security defense
system e.g. Axent Defender, if you need more higher level of security on your
SCADA system. I known an oil company is having a larger flat LAN in our place,
which allows all the applications such as SCADA, accounting, etc to connect
with. However, they only use Firewall and Axent defender as the security system.
Of course they are also having the building securiy access control system for
all the server and computer network rooms.
________________________________________

A : I don’t understand why anyone thinks such a thing would be sodifficult
to administer. Admittedly, this limits real-time SCADA status information to
a selectgroup that are allowed access. However, we’ve had reasons to do thisfor
years. We’ve maintained a separate network for this purpose foryears. It’s not
like it is — to use that awful phrase — a "Paradigm Shift."
The fact remains: many people say they need real time data when what they really
need is a timely report They’re not the same.

Now I’m the first to admit that separating the wannabees from thefolks who
really DO need this information is not a politicallydesirable task and it really
takes some stroking to get it to work. But leaving the security doors to the
SCADA system wide open is not asolution either.

We operate two separate in house networks with carefully administered interconnection
points. It’s not easy. But the alternative isn’t much fun either. I mean, does
anyone want to have a Kerberos key server or a Microsoft Domain Controller failure
take down their entire SCADA system? I didn’t think so…
____________________________________

A : It’s probably true regarding the administration of a firewall. However,
what I am suggesting is that you need to create yet another isolated network,
i.e. the one that connects the external plant equipment. This one needs to be
isolated not only from the corporate network but also from the internal SCADA
network. So now you need two firewalls – one between the corporate network and
the SCADA and one between the external SCADA network and the internal SCADA
network. The external SCADA network is extremely vulnerable physically. In our
case someone could kick in a door on a small remote building substation and
just plug their laptop into the local 10BaseT hub. Sure we’d get an alarm to
say someone has opened the door and is inside the substation but it could take
some time to get there to find out what was going on.
____________________________________

A : OK, I’ll play devil’s advocate here: the hacker breaks into your substation
and taps into your SCADA and/oryour corporate LAN. what can they do at this
point? Is the hackerknowledgeable about how your SCADA system and corporate
LAN operates ornot. I’m asking because it will make a really big difference,
whether this is an inside job or not. IMHO, most attacks of this nature will
beinside jobs from disgruntled current or former employee(s). why do youhave
disgruntled employees in the first place? do you have peopleworking in your
SCADA group or operations area that you don’t trust? whywere they hired in the
first place? why are they still employed?

If a "non-knowledgeable" hacker gets into your sub-station and LAN
whatcan they do? If I was a terrorist and I got that far into your station,I
would just run around planting explosive charges all over the placeand then
head to a good viewing site where I could watch the fireworks.if a person happens
to take out an individual station what does that doto your entire system? hopefully,
your design engineers have set thingsup in such a way that any damage &
outages are localized to a very smallpart of your entire system. Sorry to go
off on a bit of a rant here but I’m getting tired of peoplespreading FUD, Fear-Uncertainity-Doubt,
when what the SCADA industryneeds is real hard data and facts about security
threats so we can make intelligent resource allocation decisions and stop making
guesses about what the real threats maybe and where they might come from.for
a interesting article on a somewhat related topic please see thefollow reference
from (contributed by Mark Joseph Edwards, News Editor,mark@ntsecurity.net)
via a Windows & .Net magazine security mailing listI belong to:—–read
CIO Magazine’s February 15, 2002, article "Finally, A Real Returnon Security
Spending" (see the first URL below), which discusses anapproach to calculating
Return on Investment (ROI) for IntrusionDetection Systems (IDSs).
The February 15 article references another article’s sidebar, "Calculating
Return on Security Investment" (see thesecond URL below).
http://www.cio.com/archive/021502/security.html
http://www.cio.com/archive/021502/security_sidebar_content.html
_________________________________________