Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Evaluating Or Testing Utility SCADA Security?

Soulskill posted more than 3 years ago | from the i-hear-stuxnet-has-a-nice-admin-suite dept.

Security 227

EncryptedBit writes "I am a local elected official involved in bringing new water and waste water treatment plants online in a small town. The new plants will incorporate SCADA, which can be used to change operational aspects at the plants, up to forcing a shutdown or changing operational parameters. Can any Slashdotters recommend ways to make sure it is secure? Any testing recommendations? The operational engineers are oblivious to security and SCADA is a new factor, so this concerns me. Any pointers would be appreciated."

cancel ×


Sorry! There are no comments related to the filter you selected.

Point an internal browser to (0)

Anonymous Coward | more than 3 years ago | (#34148996)

If your reactor starts glowing blue, you may be infected.

Don't put it on the Internet! (5, Insightful)

Anonymous Coward | more than 3 years ago | (#34149006)

Seriously keep it on it's own separate network.

Re:Don't put it on the Internet! (2, Interesting)

mattt79 (1005999) | more than 3 years ago | (#34149040)

++ Absolutely correct!! SCADA should be considered a Level II control system, and subject to the same degree of security as the devices that are actually controlling the valves!

Re:Don't put it on the Internet! (1)

aaarrrgggh (9205) | more than 3 years ago | (#34150224)

That is easier said than done sometimes, and unfortunately it doesn't solve the whole problem. Solid layer-1 through 3 network security is extremely important, and needs to be very thurough.

But resolving the details isn't easy. How do you prevent a technician serving one piece of equipment on the network from accessing other network-connected equipment? How do you counter factory backdoors?

And... how do you do all of this without an IT staff dedicated to it?

Re:Don't put it on the Internet! (1)

Dolphinzilla (199489) | more than 3 years ago | (#34149044)

totally agree - no amount of convenience is worth the security risk !

Re:Don't put it on the Internet! (1)

davester666 (731373) | more than 3 years ago | (#34149138)

Except we all want cheaper stuff. And that means using the lowest bidder.

And that means a cheap Windows-based computer, running a hacked together app, connected directly to the internet.

Re:Don't put it on the Internet! (2, Interesting)

John Hasler (414242) | more than 3 years ago | (#34150114)

> Except we all want cheaper stuff. And that means using the lowest bidder.

It means using the lowest qualified bidder. Do you think you'd get better quality from the highest bidder?

Re:Don't put it on the Internet! (2, Funny)

mail2345 (1201389) | more than 3 years ago | (#34149064)

But I want to be able to blame "hackers" when I mess up.

Re:Don't put it on the Internet! (1)

Lopton (990061) | more than 3 years ago | (#34149066)

totally agree, this is the ONLY safe option!

Re:Don't put it on the Internet! (4, Insightful)

j35ter (895427) | more than 3 years ago | (#34149160)

Just keep away from Simatic and Wonderware! Better yet, keep away from ANY kind of winXP implementation. Oh yeah, don't forget to *physically* lock all USB ports and external media. Of course, you should make sure that there is no network connectivity with the outer world. And I mean none! No multihomed machines, no VLAN's etc. And, of course, if you see all alarms going off at :)

Re:Don't put it on the Internet! (4, Insightful)

Bigjeff5 (1143585) | more than 3 years ago | (#34149198)

Good safe practice for separating a process control network from the internet is something like: internet > corporate network > buffer network > process network. Completely separating it is not advisable, because it can actually make it harder to administer and protect (updates, antivirus, etc). It's an option though if you are diligent with sneakernet updates and whatnot.

The network your SCADA system runs on should never, ever have direct access to your corporate network or the internet, your buffer network should never have direct access to the internet, and your corporate network should never have direct access to your process network. Be stingy about what you allow through the firewalls at each layer.

Basically when you need SCADA data outside the process network, you send it to the buffer network, and from there it is accessed from the corporate network. All controls should only be managed from the SCADA network (i.e. don't set something up so that it can be managed from the corporate network).

Separation is key. As others have said, SCADA networks need a lot of open access to the various systems they control in order to function efficiently, so within the network things have to be practically wide open. The only real option is to protect yourself with layers to make it nearly impossible for anything you don't want to access the system.

Re:Don't put it on the Internet! (1, Insightful)

Mysteray (713473) | more than 3 years ago | (#34149270)

Completely separating it is not advisable, because it can actually make it harder to administer and protect (updates, antivirus, etc).

Yeah, it might make it a little harder to work with sometimes.


Get your lazy ass off out of your chair and maintain the low-level infrastructure like it needs to be. Sometimes the infrastructure needs a guy with a truck, a wrench, and even a firmware update to match.

There's absolutely no reason industrial control processes should be accessible to the same web browser that can play Facebook games. Ever. There's little or no security isolation between the systems, regardless of how many proxies you put in place. The web just was never designed to work that way.

They really should have as few interoperable ports (e.g. USB) as possible.

Don't believe me? Just ask the Iranians right now.

Re:Don't put it on the Internet! (1)

bjwest (14070) | more than 3 years ago | (#34149996)

But but but.... I have the god given, constitution granted inalienable right to play Farmville, have my desktop covered with widgets and surf the web while at work! By god, I'm an 'merican!! What the hell do you expect me to do while I'm at work, WORK?!? I don't get paid to stare at those blinking pixels and dial thingamabobs all damn day.

Re:Don't put it on the Internet! (2, Insightful)

j35ter (895427) | more than 3 years ago | (#34149278)

IMHO the standard multi-layered network security approach does not always satisfy the security needs of a process management system.

you really don't want your windows machines to update themselves: NO NO NO NEVER!!!
Just imagine the operators' dumb face when WinXP goes into a restart during some critical operation, this could seriously ruin a plant managers Tuesday!

One important aspect is the internal security, people are lazy, and if you allow the to use a USB drive somewhere (management demands reports in electronic form!) you can be sure that someday some admin will need an aspirin and a new job!

The best approach is to have a 2 tiered network: PLC's and SCADA ... and basta!

Re:Don't put it on the Internet! (0)

Anonymous Coward | more than 3 years ago | (#34150164)

you really don't want your windows machines to update themselves: NO NO NO NEVER!!!

I'm going to vouch for this. While a user can interrupt the reboot, it often has to be done within a few seconds of the dialog popping up. Yes, this can really ruin your Tuesday. Especially if it's during a mission-critical operation and Windows Update wants to update something that has absolutely nothing to do with what that computer's purpose is (something like Windows Media Player or Windows Genuine Disadvantage). You're best off uninstalling anything that doesn't benefit that computer's primary purpose.

I'm also going to add my voice to above people in saying that any Windows system would be a bad choice as far as security is concerned. We can go off on some tangent about why windows has so many viruses, but the fact is, it DOES have more viruses than any other operating system in existence. Regardless of why it does, let's be practical: the absence of so many viruses makes other operating systems a better choice, simply because there are fewer bullets with your OS's name on them.

I know that there are going to be some people jumping up and yelling "security by obscurity is BAD!!!", but anything you can do to make it hard on a potential attacker is better for security. That is, unless it has an adverse effect on what you want the computer to do. Just don't RELY on security by obscurity. But another line of defense is never a bad thing.

Regardless of what operating system you use, though, I think it's more important that you just bite the bullet and keep it disconnected from the internet. I come from a Unix background, and it's always been a good rule of thumb that if it works, then it shouldn't need to be updated. Updates stand a chance to break compatibility. If there's no benefit it gives you, then all you're doing is taking the chance of breaking something. If it's disconnected from the internet, then all you really need to worry about is physical security: keep the door to the room locked. Also, disconnect all of the USB ports and the NIC. Padlock the case and turn on the chassis intrusion alarm. If you're really paranoid (and you should be when our drinking water is at stake), disconnect all removable media like CDROM drives. The only external media you should have connected is some method of doing backups - and that needs to be secured, too.

And yes, do your backups. If the software doesn't keep any long-term data, it would be a good idea to have a Ghost image of that hard drive stashed somewhere safe so you can do a fast recovery should the hard drive fail.

Remember the security rule of thumb. First, when you make a system more secure, you'll probably sacrifice convenience. Second, if you make a system more convenient, you'll probably sacrifice security. Bite the bullet and take some inconveniences. You'll thank yourself some day.

I do have to commend the OP for asking advice rather than stumbling along, risking people's health for the sake of appearances. I wish more public officials would be this humble. If you were in my city and I knew it, I'd make sure to vote for you again.

Re:Don't put it on the Internet! (1)

LordLimecat (1103839) | more than 3 years ago | (#34149344)

Can you clarify what a buffer network is, and why it would help?

Re:Don't put it on the Internet! (5, Insightful)

Anonymous Coward | more than 3 years ago | (#34149210)

As a security expert who has audited SCADA systems, I must amend the above remark. If you ask them, "I'm here for security, is it connected to the Internet?", they will say "no". If you instead ask them, because you are concerned, "in an emergency, how an administrator can access it remotely", then will tell you the series of systems that will allow you to connect in- firewalls, vpns, and usually a last hop Citrix remote desktop session to the SCADA software itself, which is often Siemens, and is run in a VM. When you tell them to take it off the Internet, they will put your request in change control, and find a way to get rid of you, or if you're a politician, to buy you out. Usually the people running these things have no ability to think adversarially, so they consider something that is several levels removed from the Internet to not be Internet connected, even though it is. They may even tell you that it has its own leased network, run over Frame Relay leased from a telco, which is quite common. This is also internet connected, as the ISP can get pwned, and the frame relay stuff has a management network that is on the ISP's LAN. I've done security for a Fortune 50 ISP as well.

The short answer is, every SCADA system in the Americas is Internet connected, and no one has the balls to tell them to stop. They will only hire people to audit them who will put on kid gloves and play by their rules, and they refuse to take advice from their vendors, who they pay to be compliant. A security consultant lecturing a SCADA client on security measures is like a temp secretary lecturing a CEO on spelling. It's an event that always ends in a raised eyebrow and a prompt firing.

Every nuclear reactor in the united states is internet connected. I've seen them. I'm certain. Being a whitehat pen tester these days is like being a turned out whore- you know you're not helping anyone but it's too late to go back.

Posted anonymously for obvious reasons.

Re:Don't put it on the Internet! (5, Insightful)

Anonymous Coward | more than 3 years ago | (#34149252)

I almost forgot. Don't ask them, "is your network secure", because they will say yes, even though there's no such thing as a secure network. The appropriate question is, "how defensible is your network" and "what is your dwell time", i.e., what do you have in place to stop intrusions and how long do hackers usually last on your network. But the best question to start with is "what's your incident response budget", which they will brag about, i.e. how much money they spend on getting hackers removed when they're owned. Start there, get them to tell stories about the last time they got hacked. Then you don't have to listen when they start telling you about how they're "secure".

Re:Don't put it on the Internet! (2, Insightful)

noidentity (188756) | more than 3 years ago | (#34149398)

Usually the people running these things have no ability to think adversarially, so they consider something that is several levels removed from the Internet to not be Internet connected, even though it is.

Indeed, everything is connected to the Internet. It's always just an Ethernet cable away. Send the right commands over a phone line, and that cable will be connected for you.

Re:Don't put it on the Internet! (1)

EdIII (1114411) | more than 3 years ago | (#34149538)

is like being a turned out whore- you know you're not helping anyone

A very interesting and insightful post. However, I have to strongly disagree with this analogy. A turned out whore is providing a valuable service.

At least you're making teh moniez, eh (0)

Anonymous Coward | more than 3 years ago | (#34149614)

Nice to see my dark expectations of the IT security industry confirmed. Not that it was hard to guess, mind. But still. As for the original question, well, there's these three envelopes that you probably found in your desk drawer....

Anyway, one of the big questions of our time is HOW THE HELL DO WE SECURE ALL THOSE SYSTEMS?

And we won't have an answer for at least another decade. Best get cracking then. I'm getting the feeling the only long term solution is to basically rewrite everything from scratch and this time care about securing and input handling, and take building the rest --networks, use environments, the works-- from there. That, and learning how to secure our policies and procedures and rewrite those from scratch, too.

Another big question of our time is HOW THE HELL DO WE PROTECT OUR PRIVACY?

Which in a certain light is the same as the previous question. Try it. Now consider that some think privacy and security to be diametrically opposed, and taste the delicious irony. Yeah, they're wrong, so wrong they don't know how wrong they are. Franklin, however, was right. But he's dead and we aren't, so it's up to us now.

Re:Don't put it on the Internet! (2, Insightful)

KUHurdler (584689) | more than 3 years ago | (#34149724)

Seriously, the original poster needs to hire someone that is an industry expert in Utility Communications [] . Disclaimer: I work for this division, but we do this stuff every day and it's not the kind of thing you want to try doing on your own. In the worst instances, there are no second chances.

Re:Don't put it on the Internet! (0)

Anonymous Coward | more than 3 years ago | (#34149898)

As parent poster said said. Anyone that suggests 'keep it completely isolated' has obviously not dealt with such systems in real life.

SCADA systems (usually in the form of Windows + proprietary application) need to connect to PLCs. These PLCs are generally controlled by a server, which in turn is connected into your core network. In *most* manufacturing companies, this data originates in some sort of central office.

Added into the mix (again as poster said), is that the vendor support will usually mandate remote access - by VPN, dial-up or other means.

If you care about these devices, then you should segregate them into a different network, but you will most certainly need a firewall to manage access to them.

My advice: Find a competent security architect to give you the requirements needed. Find a competent network engineer to implement to these specifications.

Re:Don't put it on the Internet! (0)

Anonymous Coward | more than 3 years ago | (#34150220)

You're names not Peter Anderson by it? Yes, THAT Peter Anderson...the one with a ponytail and the buddy with the magical laptop that employs unicorn pee or some such thing with which it has the ability to "monitor every packet on the Internet in real-time no matter where connected". sorta sound like him because you started your statement with a dash of self-aggrandizing. Trust did, and I'm a bit of an expert at such things.

Re:Don't put it on the Internet! (5, Interesting)

Anonymous Coward | more than 3 years ago | (#34150256)

I've also done SCADA system security on the water plants of nuclear reactors, and can confirm that all the ones I've seen have been connected to the Internet. One time I saw a Junxion box and a AP just plugged into the core switch for the control network. It wasn't that crazy given that the Junxion box had its power supply in the manager's office and you can't get within miles of the place without having rifles shoved in your face, but it was still pretty surprising to see it.

Another site uses default passwords for everything and they have a dial-up modem which drops you right into a login prompt on one of the control hosts. You have to call them to get them to plug it in first, though, so they haven't had any problems. Unlike in Hackers, they don't plug it in for any schmuck who asks; you have to give a CAC ID and it has to match the schedule maintenance roster, otherwise the FBI gets called.

The really important stuff isn't really under control of a computer though, it's all in some PLC somewhere and there's only one guy who understands the control logic anyway. I'm not too worried about someone breaking into those networks. If anyone tried to do anything bad, it's much more likely that they're just going to break something unintentionally while learning how the system works and trigger an investigation, not create a meltdown.

Re:Don't put it on the Internet! (0)

Anonymous Coward | more than 3 years ago | (#34149718)

The SCADA system I was just put in charge of is internet facing, runs Windows Server 2K3, is on the office LAN, has no anti-virus software, was never backed up, and hasn't had a single patch applied to it ever. Oh, and we're an IE 6 organization. So basically, don't do any of that.

Re:Don't put it on the Internet! (2, Funny)

j35ter (895427) | more than 3 years ago | (#34150204)

Now *that's* what I call bareback :)

Re:Don't put it on the Internet! (1)

Jimbookis (517778) | more than 3 years ago | (#34150172)

Er... yes. I have worked and maintained a SCADA system at a site that had a large process and control network that under no circumstances ever connected to any other network in any way, shape or form. It just seems intrinsically negligent and stupid to do otherwise. It wasn't hard to maintain even if it meant sneakernet had to be used to get things done - but then I had one machine on my desk for regular networking and another machine on the plant network and used USB keys to install vendor patches and virus database updates to the SCADA system. I am appalled at the assertion that US nuclear power plants are somehow connected to the Internet, even in an obfuscated way. Internet connected SCADA networks might be OK if your plant is manufacturing Mars Bars but for anything critical like utilities or other places where a compromised process network could create a public hazard then it's not on.

Re:Don't put it on the Internet! (1)

mjwalshe (1680392) | more than 3 years ago | (#34150306)

and physically disable the usb ports

SEL SCADA Solutions (0)

Anonymous Coward | more than 3 years ago | (#34149008)

I would recommend giving these guys a l.ook They helped us with a complete installation at an electric utility I worked at.

Re:SEL SCADA Solutions (1)

KUHurdler (584689) | more than 3 years ago | (#34149746)

Let me guess, they recommend all SEL equipment?

Re:SEL SCADA Solutions (1)

aaarrrgggh (9205) | more than 3 years ago | (#34150286)

Not as good as they think it is, but a little better than nothing. An appliance can't secure the network, but as a gateway to the SEL network it might make sense.

Check with Ahmadinijad? (1)

tqk (413719) | more than 3 years ago | (#34149012)

Seriously though, heard of "air gap"?

The operational engineers are oblivious to security and SCADA is a new factor, so this concerns me.

You most certainly should be concerned about that. Incompetent/oblivious mgmt? In the 21st Century?!?

Re:Check with Ahmadinijad? (1)

bunratty (545641) | more than 3 years ago | (#34149200)

Yeah, WiFi is what takes care of that pesky air gap for me! Do you recommend 802.11g or 802.11n for SCADA systems?

Re:Check with Ahmadinijad? (1)

tqk (413719) | more than 3 years ago | (#34149976)

Yeah, WiFi is what takes care of that pesky air gap for me! Do you recommend 802.11g or 802.11n for SCADA systems?

I recommend you have a laptop with a modern version of Linux on site with wifi enabled. You'll have no trouble tracking down promiscuous APs. WiFi access should never be let near critical infra (that's NOT "air gap").

Sheesh. I avoid wifi like the plague (& facebook & twitter & 4chan ...). Don't blame that mess on me.

Re:Check with Ahmadinijad? (1)

Bigjeff5 (1143585) | more than 3 years ago | (#34149206)

I'm confused, since when are operational engineers managers?

Re:Check with Ahmadinijad? (1)

tqk (413719) | more than 3 years ago | (#34149882)

The manager *ought* to be demonstating his competence in this area to his boss (OP), which he is apparently not doing. Mgr.'s who can't comunicate are doing it wrong.

I assume OP is attempting to do due diligence (watching the watchers/doers?), so if he doesn't feel up to trusting his subordinates, damned right, he ought to find out what's really going on.

It's his job to stay on top of this, yes?

I'm not accusing the engineers of incompetence, but if one side doesn't trust what the other's doing, it's time to educate each other, at the least.

Re:Check with Ahmadinijad? (2, Insightful)

mystik (38627) | more than 3 years ago | (#34149530)

Remember Suxtnet? Not too long ago?

It spread by usb drives, which Gleefully jump the "air gap".

It's slightly more complicated than simply keeping an air gap, and probably requires the consultation of someone who's had experience securing these types of networks.

Re:Check with Ahmadinijad? (1)

tqk (413719) | more than 3 years ago | (#34150210)

Remember Suxtnet? Not too long ago?

It spread by usb drives, which Gleefully jump the "air gap".

And we've been warning about USB drives/sticks since the existence of G3!

Malware, if allowed, will use any vector it can. Quelle surprise? It walks in off the street if allowed. USB key!

You're going to install critical infra. with *anybody can plug anything they want to into your server* functionality?

At least get your admins to look into locking it down.

If your servers run Win*, you're hosed on bootup.

Start here (0)

Anonymous Coward | more than 3 years ago | (#34149020)

From what I understand (4, Interesting)

Runefox (905204) | more than 3 years ago | (#34149026)

There isn't much to do with SCADA regarding security - The systems themselves are inherently insecure, the extent of it reaching only so far as default passwords that are scarcely ever changed and the requirement to have a compatible console. If you're connecting these devices to the internet in any way, then you're opening yourself up for a world of hurt. The best security is physical security, with no link to the outside world except in closed, site-to-site communications. I'm by no means an expert, but having heard experts speak about the subject and with some limited experience of my own, there really doesn't seem to be any better way the way things are.

Re:From what I understand (1)

galaxy (212802) | more than 3 years ago | (#34149074)

Hear hear.

Any security engineer / technical security auditor worth his salt will a) point that out to you in a meeting b) prove it to you through pentesting if needed.

SCADA systems in general are on the more .. interesting side from a security testing point of view, as one has to be _pretty_ careful about any side-effects caused by the testing. Been there, done that, haven't (yet) caused any major disasters.. ;)

Re:From what I understand (0)

Anonymous Coward | more than 3 years ago | (#34149078)

As Runefox said, make sure the internal network has the best segregation from the internet as possible, and as many as many feasably financially updated security products. (security between the internet and internal layers). So that one day someone does do something, it's accountable and can be mitigated in the future. Of course, theres no stopping 100%, but you can make the best attempt at a flat attack surface. Now until our standards community and the world can catch up.. we're all stuck to manual labor and tedious security checks. - Burton, Jason (MJH Consulting)

Re:From what I understand (3, Informative)

Da_Biz (267075) | more than 3 years ago | (#34149098)

The systems I work on feed data to our SCADA systems. The entire network is completely walled off from the Internet, and even connectivity to our internal (non-operations) network is mediated by extremely secure bastion hosts.

I can understand that there may be a need for some access (e.g., system pages an operator to send a warning or emergency message), especially as this is a small town. Keep these sorts of connections absolutely to a minimum, and wrap several layers of security around it.

Re:From what I understand (2, Insightful)

postbigbang (761081) | more than 3 years ago | (#34149224)

"Bastion hosts" are an oxymoron. Every device on a network needs the best self-protection set at the highest possible standard. Layers of security are only incrementally effective. It takes only one bot to bring you down. Firewalls, although they sound impressive, are ineffective when users plug in infected flash drives, or other media. You have to distrust every device on your network without exception-- even routers and switches can be broken into using fuzzing techniques. Continually hack yourself, ethically, using the latest techniques. Then do it again. Be afraid, be very afraid. If you're not afraid, then I'm deeply afraid.

Re:From what I understand (1)

Jeremi (14640) | more than 3 years ago | (#34150246)

You have to distrust every device on your network without exception-- even routers and switches can be broken into using fuzzing techniques.

I always thought that for the truly paranoid, the trick is to make sure that it is physically possible for information to flow into the "secured" system from the outside world. For example, make it so that the only connection between the secured system and the Internet-facing gateway is a serial cable, and the TX line on the serial cable has been physically severed. That way the secured system can send status data, alerts, etc, to the gateway computer, but no matter how p0wned the gateway computer is, and no matter how insecure the software running on the secured system is, nobody will be able to affect the secured system's behavior (unless they can physically access the serial cable and repair it, of course... but that's what the guards and Rottweilers are for...)


Anonymous Coward | more than 3 years ago | (#34149694)

And don't install antivirus on the secure network(Not a joke!). To have an effective anti-virus you need regular updates. Those updates need connectivity. That connectivity is exactly what everybody says you have to limit (or connectivity should not exists according to others). And don't forget AV somethimes give false positives. You never want your mission critical software affected by AV.

Besides that, dont go for any automated update on your mission critical network. For any updates you might need apply them to a test system first.

Re:From what I understand (1)

sjames (1099) | more than 3 years ago | (#34150090)

Outbound notifications can be handled by a serial connection with the inside hosts Rx line cut so that it can ONLY send outbound communications.

Re:From what I understand (4, Insightful)

NewbieProgrammerMan (558327) | more than 3 years ago | (#34149380)

There isn't much to do with SCADA regarding security - The systems themselves are inherently insecure...

As somebody that worked at a SCADA software company for a few years, and saw (1) the skill level of the core development team and (2) what customers did with our systems, I heartily endorse this viewpoint.

Re:From what I understand (1)

TooMuchToDo (882796) | more than 3 years ago | (#34149818)

You don't necessarily need an airgap. You just need the network so that you can read SCADA status info and alert based on that. []

Be able to read from WAN->SCADA, but never be able to write.

Pointers (2, Funny)

PiAndWhippedCream (1566727) | more than 3 years ago | (#34149028)

0x00000047, 0x000008C4, and 0x00000A08 All hold awful vulnerabilities, make sure no one has access to them.


Anonymous Coward | more than 3 years ago | (#34149032)

Air gap, it should not be connect to the internet in any form or fashion. it should only be networked with other scada computers and nothing else. Physically seperate networks than the rest of your systems. The Department of Homeland security will come out and speak to you about it if you ask them. google SCADA for there guidelines.


j35ter (895427) | more than 3 years ago | (#34150234)

Air gap, it should not be connect to the internet in any form or fashion. it should only be networked with other scada computers and nothing else. Physically seperate networks than the rest of your systems. The Department of Homeland security will come out and interrogate you about it if you ask them. google SCADA for there guidelines.

There, I fixed it for you...

Having done this... (1)

grasshoppa (657393) | more than 3 years ago | (#34149080)

...I will say that training is going to be your biggest hurdle. But I'm sure you know this. Water and waste water technicians are, in my experience, terrified of technology. This manifests as an unwillingness to use technology and a hostility when forced to do so.

Other than that, treat it as you would any other service that could potentially kill people, or more importantly, lose your next election ( I know how politicians think ); Lock down the subnet, do not provide access to this remotely on equipment you do not own ( ie: no home systems connecting up for scada work ). VPN with two factor ( RSA keyfobs are pretty easy to implement against an ASA anymore ), with municipality provided laptops.

But again, it comes back to training. Good luck with that, I never was able to get that worked out ( although my hands were tied by those in charge, so maybe there's a lesson in there for you ).

Seperate computers (0)

Anonymous Coward | more than 3 years ago | (#34149082)

I worked at a glass fabrication plant with SCADA controllers.

Those guys bought an interface card for a PC, plugged it into the SCADA network, and used the same computer for controlling a tempering furnace and surfing porn. Big mistake.

Keep the control systems completely dedicated to controlling stuff, don't install extra software on them. Don't connect them to a network. And you're fine.

add scada securoty as job requirement? (0)

Anonymous Coward | more than 3 years ago | (#34149084)

if your engineers are oblivious, it sounds like you need to fire them.

Do NOT connect to the Internet! (2, Informative)

RedLeg (22564) | more than 3 years ago | (#34149108)

It's simple......

Do NOT, under any circumstances, connect the SCADA systems, including workstations which can control or monitor them, to anything which touches or has access to the Internet. Make SURE that your control and monitor workstations have current AV in place. Do NOT connect them to the net to update the AV, figure out how to do it with sneakernet.

Further, make SURE you use RFC 1918 addressing for the SCADA systems so that they are not readily routable to the 'net.

Map the interfaces, and have a AAA (Authentication, Authorization and Accountability) strategy for each. Log EVERYTHING.

If you use a carrier to link remote sites into a WAN, make them prove to you that their pipes are clean and secure.

Have Fun......


Re:Do NOT connect to the Internet! (0)

Anonymous Coward | more than 3 years ago | (#34149308)

"These pipes, are CLEAN!"

Re:Do NOT connect to the Internet! (2, Interesting)

Jah-Wren Ryel (80510) | more than 3 years ago | (#34149332)

Do NOT, under any circumstances, connect the SCADA systems, including workstations which can control or monitor them, to anything which touches or has access to the Internet.

When that's not possible due to management pressure, there are options that are better than just giving in and connecting systems up to the internet.

The simplest of such options is a "data diode" -- its a device that physically only permits data to flow in one direction. For example, optical network connections have a transmit fibre and a receive fibre. A data diode would physically connect just one fibre.

Implementing a data diode - say to run your monitoring software on an internet connected PC so as to send status updates via SMS to engineers' phones - can take some effort in order to get all the necessary software to work in the one-way environment. But it is a way to get data out of your SCADA system without having to worry about malicious attacks coming in on the same connection. At worst your monitoring system gets fuxxored, but the SCADA stuff continues to run unmolested.

Here's one data diode product with an emphasis on SCADA, it was just the first one that came up in google, there are many such products out there: []

Re:Do NOT connect to the Internet! (1)

starfishsystems (834319) | more than 3 years ago | (#34149938)

With rare exceptions, all network protocols require two-way traffic. So this idea of a "data diode" is not possible to implement in practice. People who claim otherwise are trying to sell you snake oil.

Re:Do NOT connect to the Internet! (1)

Jah-Wren Ryel (80510) | more than 3 years ago | (#34150014)

With rare exceptions, all network protocols require two-way traffic. So this idea of a "data diode" is not possible to implement in practice. People who claim otherwise are trying to sell you snake oil.

I suggest you do some research. Data diodes tend to be application specific and the good ones "know" enough of the protocols involved in order to spoof the necessary handshaking.

It should scare you (0)

Anonymous Coward | more than 3 years ago | (#34149110)

One of the first known attacks against a SCADA system was basically against exactly the same type of systems you are trying to protect


Ask the NSA (1)

jeff4747 (256583) | more than 3 years ago | (#34149122)

This answer assumes you're in the US. If not, replace the relevant government agency with your own government.

Since your engineers are 'oblivious about security', you're going to have to hire somebody to evaluate your system. NSA should be able to point you towards government contractors that do this kind of thing. You could try DHS since they're supposed to help civilian infrastructure such as your operation, but their "cyber" operation isn't really set up yet.

No, it won't be cheap. You'll have to balance the cost vs. the possible repair costs after an attack.

Well... (1)

symes (835608) | more than 3 years ago | (#34149126)

You'll certainly might get some good tips here on slashdot for free, but really, you might want to think about getting local expertise... your next post "our town's waste and water services have been maiciuously hacked, please help, we're up to our ears in ****" might not filter to the front page.

VPN (0)

Anonymous Coward | more than 3 years ago | (#34149132)

The usual way to "secure" a SCADA network without having to become an expert in the specifics of the typically undocumented or proprietary protocols it uses, is to have the plant network be connected to a hardware VPN router; any cheapo Cisco will do. This way, the only thing that can "dial in" is a PC on the other end running the VPN client; hopefully your _real_ IT dept controls this PC, and can make sure it has antivirus, updates, etc. installed ( + a sane security policy).

Re:VPN (1)

LordLimecat (1103839) | more than 3 years ago | (#34149392)

That doesnt really help when the client gets rootkitted, does it....

Data Diode (1)

ChefInnocent (667809) | more than 3 years ago | (#34149146)

Your internal systems need to be on their own network as others have said. Otherwise, you'll be owned. However, if you have a need to share data "publicly", you can create a data diode to a public server. It involves either a very expensive piece of hardware, or soldering a switch so there is no way to communicate to the main plant computer. Then the plant server communicates to the public server via UDP, and you can use OPC (or whatever you like) to retrieve data. If you have some idiot that wants to control stuff from home, follow the Republican Motto: Just say no.

You have to fix this (1)

MichaelSmith (789609) | more than 3 years ago | (#34149148)

The operational engineers are oblivious to security

Its like saying Our bus drivers are oblivious to road safety. If they don't know how to do their jobs then you are screwed.

Put an air gap between your SCADA system and the internet.

At least you are aware of the risks. (1, Informative)

Anonymous Coward | more than 3 years ago | (#34149164)

I personally witnessed Samba root level shares on SCADA boxes at an oil refinery in Brisbane. As far as I could tell the SCADA boxes were on an intependant network but were fully reliant on no internal security.

Posting anon for obvious reasons.

Seriously scarey.

Hackers tap SCADA vuln search engine (1)

DevConcepts (1194347) | more than 3 years ago | (#34149208)

I might be repeating what others have said, but I found this looking to find out what SCADA is. []

A search engine that indexes servers and other internet devices is helping hackers to find industrial control systems that are vulnerable to tampering, the US Computer Emergency Readiness Team has warned.

The year-old site known as Shodan makes it easy to locate internet-facing SCADA, or supervisory control and data acquisition, systems used to control equipment at gasoline refineries, power plants and other industrial facilities. As white-hat hacker and Errata Security CEO Robert Graham explains, the search engine can also be used to identify systems with known vulnerabilities.

According to the Industrial Control Systems division of US CERT, that's exactly what some people are doing to discover poorly configured SCADA gear.

Scared yet? (1)

lga (172042) | more than 3 years ago | (#34149268)

Is anyone else terrified by the fact that this question even had to be asked?

Re:Scared yet? (0)

Anonymous Coward | more than 3 years ago | (#34149298)

Two words... Elected official

Re:Scared yet? (2, Interesting)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34149664)

I find the fact that it is being asked commendable: if TFS is to be trusted, an elected official is attempting to learn more about security to make sure he can oversee a project properly. That sounds just ducky to me, and well above the status quo.

Now, the fact that said official appears to have strong reason to distrust his engineers, and no ready internal supply of expertise, suggests that any script-kiddie with a copy of Telnet and 10 minutes will be able to quite literally put some poor town up shit creek without a paddle once the project goes live; but the fact that an elected official has forseen that possibility and is asking questions down at the geek club to see if there is a way to head it off seems like a good thing...

WaterISAC (1)

IT.luddite (1633703) | more than 3 years ago | (#34149282)

I'd start reaching out to other utilities/organizations in a similar situation for what they're doing. I'm involved in the electric sector (ES-ISAC) as well as the FERC/NERC stuff so I'm heavily involved in the regional and national "user groups".

For more direct advice:

1) discrete network firewalled, ideally air gapped, from the "corporate" or normal network. This is a single function network.

2) strict controls on media usage as well as protocols on how to use

3) strict config management and change control

4) physical protections to "local" and "remote" systems (RTUs, PLCs, and IEDs (note: IED = intelligent electrical device), you really don't want to build a secure control room and then get back hacked from a field device!)

To actually learn more, Idaho National Labs has the National SCADA Test Bed Program ( and they also have control system security workshops/training programs. Their Advanced SCADA Security Training is pretty eye opening, and that's coming from the perspective of an IT security guy. Your normal operators and operational engineers will likely be blown away by it.

Like I mentioned, coming from the electric sector, I know what your facing (technical as well as cultural issues) and feel you pain. Good luck, and know you are not alone out there... just a minority! ;)

Step 1 (0, Redundant)

ceeam (39911) | more than 3 years ago | (#34149288)

Don't connect any important computers/networks to the Internet. Problem 80% solved, duh.

Attacking and Defending the Grid (2, Insightful)

nexar-andy (246769) | more than 3 years ago | (#34149290)

I recently went to a Belgian OWASP meeting where Justin Searle talked about "Attacking and Defending the Grid".
This guy knows what he's talking about. Among other things, he also mentioned SCADA vulnerabilities.

I recommend you contact him or his company for professional advice (I am in no way affiliated with him or his company - just thought you might be interested)

If you google for the subject of this reply in combination with "OWASP", you'll find more info about the talk.

Contact other municipalities using SCADA... (0)

Anonymous Coward | more than 3 years ago | (#34149302)

Contact other municipalities using SCADA. Ask them what they did. Ask them for further advice if they seem knowledgeable.

VPN (2, Informative)

AmericanInKiev (453362) | more than 3 years ago | (#34149320)

I'm working with an international firm on Scada - we use a VPN to provide a secure private network.

Re:VPN (1, Insightful)

jeff4747 (256583) | more than 3 years ago | (#34149364)

we use a VPN to provide the illusion of a secure private network.


Re:VPN (0)

Anonymous Coward | more than 3 years ago | (#34149446)

VPN is only as secure as the hosts that connect. MAC can be used to force hosts to conform to security policies, but cannot be trusted to not be compromised. Therefore VPN is a poor solution to securing a SCADA system.

SCADA and Security are not yet integrated (3, Insightful)

PureFiction (10256) | more than 3 years ago | (#34149346)

SCADA systems are not designed, implemented, or operated with network and application level security concerns in mind.
  (Usually. The exceptions know who they are :)

Your compensating control is physical security to limit access to SCADA elements and programming. It costs more, but you have no sane alternative.

And before you get too cocky about that restricted air gap, consider Stuxnet turning such a strength into a weakness for exploit. At some point SCADA systems will be security conscious; that day is not today...


Anonymous Coward | more than 3 years ago | (#34149348)

That is all.

To test for weaknesses and fix problems (1)

gamecrusader (1684024) | more than 3 years ago | (#34149366)

invite Russian, Asian, and Middle eastern hackers to attempt to bring down the network and system then find all the points they attacked and fix em

Find a consultant (1)

wjf (1935820) | more than 3 years ago | (#34149384)

There are many different types of SCADA implementations and several options for remotely accessing them - RF (VHF or UHF radio telemetry), cellular, network (wired, or wireless bridged), etc. The answer is simple - if a disaster would result from unauthorized access you need to find a consultant that knows enough about the implementation to keep the bad guys out. Spend the money and get it done right. I've often wondered about some of the SCADA implementations over VHF or UHF radio telemetry and what the person was thinking when the system was put into place, that's as insecure as a CB radio and probably controls some critical infrastructure that people depend on. This whole topic is going to keep resurfacing for years to come, and recent events such as Stuxnet proved this is an area to be concerned with.

Hire a competent auditing firm (0)

Anonymous Coward | more than 3 years ago | (#34149394)

Hire a competent auditing and security assessment firm.

For a rate (probably around $8-$10k per week), you can have a skilled team of security assessors come in, do an analysis, penetration test, etc, and provide a report on the likely weaknesses in any existing design.

For a similar rate, you can hire a different team to come in an consult with you on building/fixing the system.

It's expensive, but it's hard to beat the level of expertise that comes with a group like that. Just don't go hire some guy in his basement, be sure it's a reputable firm. Ask about the variety of the consultant's experience and how many other SCADA systems they've worked with, etc.

Good luck!

SCADA best for systems with short lifespan. (0)

Anonymous Coward | more than 3 years ago | (#34149498)

I love that one of the reasons ppl use SCADA is that is so much easier... say that again it thirty years. I have seen offers where ppl "guarantee" that the computers will last that long. Yeah right. Go for a PCL set up and hire some grease moneys that can crawl around and fix stuff. You will be much happier porting PLC code than trying to reconstruct some pre-made "modules" in software you don't have access to the source to. I have seen one module produce 600+ lines of code! Those flatscreens are pretty now but you will probably have to replace the whole system in 10-15 years. (unless something breaks... You did buy spareparts for 30years in the project, right?)

Process Not Project (1)

FrankDrebin (238464) | more than 3 years ago | (#34149522)

make sure it is secure

Here is the most important thing to know: security is a process not a project. No systems ever "achieve" security. Rather, better-protected systems beat the attackers by having well-thought-out-and-executed security processes.

Related: NERC/MILS (1)

Holger Blasum (250938) | more than 3 years ago | (#34149532)

On the regulatory side, for networks the NERC Reliability Standards for the Bulk Electric Systems of North America [] address similar concerns (including cyber security) in electrical grids. For highly integrated systems MILS kernels [] are an engineering solution e.g. to keep actuators and monitoring subsystems apart.

You're asking about this on Slashdot ? (1)

lbalbalba (526209) | more than 3 years ago | (#34149534)

Seriously ? Were all doomed, man ...

Some thoughts (1)

selil (774924) | more than 3 years ago | (#34149544)

There are a variety of good posts here (among the chaff). The post by @bigjeff5 and the anonymous coward post amendment. For standards and an understanding of the risk metrics Sandia labs has a great set of documents for SCADA security [] , never mind all the FUD. You'll have to decide on whether you want a best in class, good enough, or what you can afford and wherever the three vectors meet at a solution. Technically there is no reason for SCADA to be a risk. Experience though tells us there are plenty of reasons to push the SCADA operational component into the risk category. Not being able to afford to keep the utility operational engineers employed because the technical SCADA solution cost three times your budget is the risk I usually see. What you'll need is an experienced person to act as a trusted third party and there are a lot of them out there in the real world. Be wary of people who talk about security, technical issues, operating systems, and other elements in black and white terms. They rarely have the real world experience to understand real world issues in implementation. Since you appear to be talking about water and in the United States (pardon if not) you are likely highly regulated. You will also need to balance the new requirements and regulations for implementing SCADA devices too.

Hire Someone (1)

mighty7sd (1233176) | more than 3 years ago | (#34149602)

I work for a company who designs SCADA networks for water/wastewater clients. We rarely connect the SCADA network to the internet, but when we do, it takes a lot of time and money to do it right. Hire a firm who specializes in SCADA security, you can't do it on your own.

Try a public utility (0)

Anonymous Coward | more than 3 years ago | (#34149656)

As an elected official, you have standing that the average citizen does not. Contact your local power company (if it's a co-op, contact their supplier) and tell them who you are. All major power companies use SCADA and you'd better believe security is a high priority with them. They can point you in the right direction quicker than anyone else.

Fire them (0)

Anonymous Coward | more than 3 years ago | (#34149670)

Can any Slashdotters recommend ways to make sure it is secure?

Don't connect it to the Internet.

The operational engineers are oblivious to security

Fire them and hire someone competent. :P

Recommendations from my SCATA project (0)

Anonymous Coward | more than 3 years ago | (#34149720)

I've recently been through this in a mid-sized town, some recommendations from experience.

1) Put the workstations and primary logic controllers on their own fiber ring. Make sure there are no gateways to other vlans.
2) Disable all optical drives and usb drives through a group policy (a MUST) on the workstations.
3) If remote access is manditory, use a device like the BlueTree cellular modems connected to the network via an IPSec/GRE tunnel which can provide remote access via dedicated mobile devices (again disable all nics, wireless adapaters, optical drives, usb drives and use a cellular modem included in the tunnel).

Hope this info helps.

hire a consultant (1)

hawguy (1600213) | more than 3 years ago | (#34149840)

If you don't understand the issues well enough to do an audit yourself, insist on an outside audit by a company that does, *and* does not sell any security products or services themselves.

Asking Slashdot is just going to get you a whole lot of uninformed suggestions from mostly well-meaning people with the occasional good suggestion buried in the noise. But you don't know enough about the subject to know which ones are the good suggestions and which are not.

Test and secure the people, not the system (0)

Anonymous Coward | more than 3 years ago | (#34150110)

I think treating security as a checklist item with regard to control systems is a bad idea, and it's been my experience that when someone starts crying for it it's really a people problem.

It's been my experience that SCADA system operators are very no-nonsense people who prefer simple and effective measures to more complex ones with better long-term maintainability. There's something about this approach that drives security-minded people who aren't used to the industry right up the wall, me included. I used to believe that was the wrong approach until I started to have to work with the customers directly, then I began to realize that the sort of security usually found in large networks actually reduces overall system reliability in most cases. I've seen some pretty spectacular disasters resulting from simple things like PKI certificates expiring and time synchronization breaking Kerberos.

I've thought a lot about this and over time have realized that sharing anything -- whether it be HMI control or a bank account or even a book -- increases in complexity as trust between the parties decreases. It's a fundamental engineering principle that if you eliminate a need for a system component it can't fail, and there's no reason why that can't be true for a SCADA system as long as you have good perimeter security. If you can't trust your system operators, what you really need is better management tools like auditing, metrics, and training, not a vague "security" requirement. One terrible thing about treating it as a checklist item instead of part of the overall plan is that you often don't get the funding required to train the staff how not to screw up the computers and have spare machines they can screw around on so they don't break production machines.

One of the nice things about the industrial control industry is that there's often very good job security. Many of our customers know who we are personally and it's very unusual to talk to someone at a customer site that you don't know. Sometimes the control operators are a few fries short of happy meal, but quite honestly the only time we've ever had security problems has been when someone misconfigured a firewall and put some operator terminal out on the Internet. The sites where the line staff are managed well and trust each other enough to simply share the admin passwords with each other have never -- NEVER -- had any kind of network security problem in several decades.

Like I said, there's something about that which drives people with traditional network security backgrounds completely bonkers, so I'll leave you with the following point: the technicians who might get that admin password may make a few mistakes early on and it's going to be annoying. You then have a choice. You can either lock them out and deny them the opportunity to learn from the experience, or you can take heart in the fact that they're the ones who are going to have to drive out and fix whatever unnecessary screwup they caused, ensuring they're never going to want to repeat the experience. There aren't very many things you can do with a SCADA system that are actually going to destroy equipment if your control engineers did their job right, so my advice is to just give the technicians administrative access, airgap the network, and spend your testing budget on seeing if the staff does well at complying with procedures to resist social engineering. Throwing more money at security products has always ended badly for us.

Private Network, No USB, No Data IN/OUT (0)

Anonymous Coward | more than 3 years ago | (#34150126)

Control systems need to be on a completely isolated network with extremely strict controls over how data and programs get onto the network.
Do not enable any USB devices, no firewire, no floppy disks and definitely NO EMAIL. There show not be any way for an average user to bring any data in or out of the systems, PERIOD.

Physical security controls are critical too. The systems need to be in controlled access locations - no following.
The physical systems need to be locked shut so someone with a screwdriver can't open them and add another HDD without authorization too.

Oh, and don't run Microsoft operating systems. If you don't run Windows, then almost none of your people will try to violate data security to load the latest "Elf Bowling" game. []

After the first person violates the rules, FIRE HIM/HER. You'll only need to do it once.

Make sure the contracts meet your needs (1)

slincolne (1111555) | more than 3 years ago | (#34150132)

While you can get into the 'nuts and bolts' of the solution the vendor is offering (you have not bought it yet have you ?) you can minimise some of the risks you may face by transferring them to the supplier.

Have someone perform a risk assessment on the system - and focus on the quantitative aspects (ie what the cost to the community will be if it fails). Make sure that the contract has compensatory and insurance options in excess of those amounts, so that it is in the vendors 'hip pocket' best interests to ensure it does not fail. And of course make sure that the contract has provisions for review, should the potential impacts change or the vendor changes company name, is bought out, etc :-) (yes - i've seen that happen)

You could also have someone do a thorough risk analysis of the system (google up the NIST SP800-30 document) as well as have them supply a complete inventory of hardware, software, and services they will be using to deliver the solution. Again, NIST have an online database where you can look up what vulnerabilities are known for some IT products.

Have the vendor perform a detailed risk analysis of the system - see what they think are problems, and what are not. Where you see gaps - ask them and see what color their faces turn.

Have a look around to see what failures or disasters you have seen in SCADA systems, refer those scenarios to the vendor, and ask them what technical measures they have taken to ensure that a similar act could not happen to them

You should also have your own people clarify and document their own roles and responsibilities with the system - don't assume that you have the resources on hand to manage your side of the situation responsibly - again a risk analysis will help out there.

And of course get it all in writing.

First rule: air gap (1)

Todd Knarr (15451) | more than 3 years ago | (#34150150)

First advice: do not connect the network that runs the SCADA systems to the Internet or to any network that connects to the Internet. Leave an air gap between your control systems and the outside world. It's OK to network them, but make it an isolated, stand-alone network. It's much harder to attack a network when getting access to it requires physically going to one of your offices or plants. It may make it less convenient, but remember you're making it less convenient for the bad guys too and the consequences of a successful attack probably outweigh any inconvenience in having to bring in updates via USB drive or the like. And don't let the vendors cow you. It's your system, after all, and you that's going to be responsible if an attacker causes a problem. If they insist their stuff absolutely needs access to the Internet, ask them point-blank if they'll be willing to sign a binding contract taking full, 100% responsibility for any and all costs stemming from a successful attack on the system from the Internet. If they won't, ask yourself whether you want to be their fall-guy.

It's possible to firewall things thoroughly enough to have indirect connection (eg. the SCADA network connects to your office network, which in turn connects to the Internet, with firewalls at both boundaries), but it's dangerous. You'll need an expert network engineering and design team to do it, and the first thing they're going to ask you is why you need that connection. If you don't have a really good answer for them, you probably don't need even that indirect connection.

Stuxnet as a case in point (1)

starfishsystems (834319) | more than 3 years ago | (#34150320)

One useful consequence of the Stuxnet Trojan is to provide a concrete example of how SCADA networks can be exploited. Knowing the details of how Stuxnet works can inform you of how to perform a comparable variety of penetration tests on your own network.

You will then have a measure of how vulnerable your network is to Stuxnet in particular. It's only a circumstantial indicator of how vulnerable your network is generally, which is why I'm not in favor of pen testing except as part of a more comprehensive security initiative. But it can be politically useful at the outset to have some pen testing results to share with management, and politically useful at the conclusion to show that something was measurably improved.

Protective measures directed against Stuxnet alone will not improve your security in general, but if you develop very good general security processes, you should observe that they effectively protect against Stuxnet among others. Security is hard because you can't prove the nonexistence of vulnerabilities. But you can certainly put measures in place, and you can test their effectiveness against known threats.

As an example, you've seen advice here to put some kind of strong isolation between your corporate network and your SCADA network. The extreme example is to have no connection of any kind, whether through firewalls or bastion hosts or whatever, between the networks.

That's good advice. You'd be crazy to ignore it. But you'd also be crazy to believe it sufficient. Stuxnet is a Trojan Horse. Among other strategies for getting onto your SCADA network, it rides on USB sticks. Your network could be completely isolated and yet it would be still vulnerable to attack. A slightly more sophisticated variant of Stuxnet would actively try to build a connection from your SCADA network outward. Since most network design is not geared to protecting against access from within, and since systems on your SCADA network have to be maintained at least occasionally, chances are that the network will be compromised.

So, it's no joke. This is a tough problem, and probably the toughest part is protecting against inside workers from defeating your security measures for the sake of convenience. Get professional help with this, and if I were you I wouldn't trust a single security contractor to get it all right. When you write up your RFP, do it in such a way that it doesn't bind you to selecting one winning bid.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>