[SCADASEC] – encryption requirements vis a vis privacy regulations

SCADASEC is a publicly-accessible (after you sign up) email list devoted exclusively to IT security issues as they pertain to our industry.

Not specific or necessarily immediately relevant to SCADA, but interesting because it points to possible architecture requirements for future systems that move personal or regulatorily-controlled data. –Lynne


[SCADASEC] Encryption requirements?

Tue, 06 Oct 2009 12:34:39 -0500

Bob Radvanovsky <rsradvan@unixworks.net>

All —

I came across this from another mailing list that deals with legal issues/aspects of IT systems, and their environments.  Although the spin on the series focuses mostly on credit card and electronic transaction processing, I believe that this raises issues about the use of, and the level of encryption for the SCADA/control systems industry.

To me, the main question is: how much is enough?

Alternatively, another question might be: will encryption help secure my environment(s)?

I don’t an easy answer for either question, but wanted to bring this to everyone’s attention.

The URL links are provided for your reading enjoyment.  There are four (4) parts, and are provided in their parted condition:

Part 1:

Part 2:

Part 3:

Part 4:
To unsubscribe from this mailing list, please visit:

To review our usage policy, please visit:


The Return of the King (or is he?)

The following links serve to point out a missing feature in most SCADA systems.  One of our architectural principles is that the network is stupid, but the edges are smart.  We’re half right, because when CygNet was first written, it was next to inconceivable that sensors and RTS were untrustworthy.  There weren’t a lot of them, they were expensive, and they were difficult for crackers/criminals to access and crack.

Today, though, that state of affairs is rapidly going the way of the dodo, but we’re still trusting our senses, though perhaps we need to reconsider that.  CygNet per se is smart, but the *other* edge of the network is only smart in an idiot savant fashion.  Sure, it’s capable of sending data, but we have no way to determine whether the information we’re receiving is trustworthy.  “How can I be certain that this information is from device X, and that it hasn’t been altered?”

An aspect of future CygNet (and all SCADA systems) will be that they have ways to verify and trust the Other Edge of the Network, where the tigers live.


http://news.bbc.co.uk/2/hi/science/nature/8533157.stm – GPS jamming and spoofing

http://www.cnn.com/2010/TECH/02/19/passport.security/index.html – The King returns

London, England (CNN) — In the name of improved security a hacker showed how a biometric passport issued in the name of long-dead rock ‘n’ roll king Elvis Presley could be cleared through an automated passport scanning system being tested at an international airport. …

May you network in interesting times

Part and parcel of learning about IPv6 has been establishing an internal infrastructure capable of running it, and which must be readily reconfigurable in order to test common configurations.  Stephen H and I have spent dozens of hours trying various configurations of modern, common, small-network configurations as part of the research v6 testbed.

In no particular order, here are some things we’ve learned:


China  – For years we used to say to people who claimed to be interested in network security, “Listen, most Internet-based attacks are coming from address blocks allocated to China, and tracerouting would seem to indicate that there are thousands and thousands and millions of break-in attempts every day.” And…they’d look at me as though I’d shown them a mouthful of black beetles whilst wearing an aluminum-lined baseball helmet, so eventually I just quit talking about it. 

Mind you, this started in the early 1990s.  As I’ve been watching network traffic, I noticed it’s only gotten worse, so I’ve blocked basically all APNIC and Russian address blocks, which has significantly cut down on the random attack traffic I’ve seen.

Why should we care?  Because one big feature of v6 is that it [potentially] brings back the end-to-end architecture that is TCP/IP’s original primary design feature.  You won’t need NAT and everything will be hunky-dory, and or peachy keen, whatever those mean.  Unfortunately, one good side effect of NAT is security-through-inaccessibility, as in you can’t attack what you can’t get to.  With e-to-e v6, though, your hosts are potentially once again available for attack.  Because c6 hasn’t been widely tested (by crackers), it’s a good bet that many implementations will have a lot of security problems in their first few years of deployment.

Windows IP Helper Service – IPv6 transitional assistance service (“Provides tunnel connectivity using IPv6 transition technologies (6to4, ISATAP, Port Proxy, and Teredo), and IP-HTTPS. If this service is stopped, the computer will not have the enhanced connectivity benefits that these technologies offer.”)  While debugging some other network issues, I discovered that at least on one machine, having this service running was generating a lot of network activity to weird random IP addresses on the Internet.  It’s off for the moment until I can confirm that this is normal behavior.


DNS – Domain controllers with multiple NICs that are running DNS will not necessarily return the expected IP address.  The default setting is to round-robin-return the various NIC addresses that register themselves with DNS.  Our first thought was, “turn off round robin,” but that didn’t work, and then “don’t allow DNS registration,” and that didn’t work.

Current status:  not solved

Current “solution”: from Microsoft-> don’t run DCs with multiple NICs.  Seriously, this is their advice.