Risk-Management and Risk-Analysis-Based Decision Tools for Attacks on Electric Power

Jeffrey S. Simonoff 1 , Carlos E. Restrepo 2 , and Rae Zimmerman 2*
1 Leonard N. Stern School of Business, New York University, New York, NY, USA. 2 Robert F. Wagner Graduate School of Public Service, New York University, New York, NY, USA.
*Address correspondence to Rae Zimmerman, Robert F. Wagner Graduate School of Public Service, New York University, 295 Lafayette St. – 2nd Fl., New York, NY 10012; tel: 212-998-7432; Fax: 212-995-4162; Rae.zimmerman@nyu.edu.
Copyright 2007 Society for Risk Analysis
KEYWORDS
Electric power outages • logistic regression • negative binomial regression • prediction interval • weighted least squares
ABSTRACT
Incident data about disruptions to the electric power grid provide useful information that can be used as inputs into risk management policies in the energy sector for disruptions from a variety of origins, including terrorist attacks. This article uses data from the Disturbance Analysis Working Group (DAWG) database, which is maintained by the North American Electric Reliability Council (NERC), to look at incidents over time in the United States and Canada for the period 1990–2004. Negative binomial regression, logistic regression, and weighted least squares regression are used to gain a better understanding of how these disturbances varied over time and by season during this period, and to analyze how characteristics such as number of customers lost and outage duration are related to different characteristics of the outages. The results of the models can be used as inputs to construct various scenarios to estimate potential outcomes of electric power outages, encompassing the risks, consequences, and costs of such outages.
DIGITAL OBJECT IDENTIFIER (DOI)10.1111/j.1539-6924.2007.00905.x About DOI

Related Articles
Find other articles like this in Wiley InterScience
Find articles in Wiley InterScience written by any of the authors
Request Reprint
Wiley InterScience is a member of CrossRef.

more

POWER GRID in North Korea obsolete


SCADA POWER NETWORKS CYBER ATTACKS


In-the-wild attacks against electrical utilities coupled with extortion demands: implications for response to criminal and terrorist action
- Gordon Housworth [ 1/20/2008 - 23:43 ] #
CIA announced what appears to be the first, documented in-the-wild successful SCADA (Supervisory Control and Data Acquisition) attack against utilities infrastructure. Surely more to follow but with the agency making the announcement, it appears to be a concrete example unlike the staged attack against a captive diesel powered generator (video, text, more text):
US Central Intelligence Agency senior analyst Tom Donahue told a gathering of 300 US, UK, Swedish, and Dutch government officials and engineers and security managers from electric, water, oil & gas and other critical industry asset owners from all across North America, that "We have information, from multiple regions outside the United States, of cyber intrusions into utilities, followed by extortion demands. We suspect, but cannot confirm, that some of these attackers had the benefit of inside knowledge. We have information that cyber attacks have been used to disrupt power equipment in several regions outside the United States. In at least one case, the disruption caused a power outage affecting multiple cities. We do not know who executed these attacks or why, but all involved intrusions through the Internet."
Said to be "virulently allergic to hyperbole," Donahue would not have made a public announcement, nor would the agency have granted permission, "if he didn't think the threat was very large and that companies needed to fix things right now."
The UK is reporting that the specific case is Central/South America, lasting short duration:
The CIA has refused to provide further details but intelligence sources say that the cities where the hackers have caused outages were in Central and South American countries including Mexico. The sources said that in no case was a ransom paid and that the outages lasted for only a few minutes. It is not known if the hackers have made any further threats.
Seeing Mexico among the targeted Central and South American states, and being aware of the drug cartels' counterattack against the Calderon government, I think it wise to raise the potential of tunable Just-in-time Disruption in conjunction to extortion revenues within Mexico. This kind of activity is well within the cartels ability to fund.
This could well be as much proof of function, shot-across-the-bow of recalcitrant victims, or both. If one can gain detailed knowledge of the PEMEX pipeline distribution system, they can get similar data on a Latin American electrical grid. A magnificent model, intentional or accidental, for more tunable just in time disruption.
Targeting the power industry is a recent extension of a long-standing extortion practice:
In the past two years, hackers have in fact successfully penetrated and extorted multiple utility companies that use SCADA systems, says Alan Paller, director of the SANS Institute, an organization that hosts a crisis center for hacked companies. "Hundreds of millions of dollars have been extorted, and possibly more. It's difficult to know, because they pay to keep it a secret," Paller says. "This kind of extortion is the biggest untold story of the cybercrime industry."
Paller told Forbes.com in June that he expected those incidents to increase, and warned that a botched extortion attempt could lead to accidental damage. "There's been very active and sophisticated chatter in the hacker community, trading exploits on how to break through capabilities on these systems," he said. "That kind of chatter usually precedes bad things happening."
Cyber-extortion and its collateral damage aren't new, says Bruce Schneier... He says that offshore-hosted Web sites, most often offering pornography and gambling, are frequent victims of hacker extortion. Targeting power companies, however, is a new wrinkle, he says.
The ease of penetrating a mixed supervisory control network
I believe that my September 2004 article, Black hat meets white hat in the Idaho desert, describes the effort that produced the Aurora test. (See also Domestic Digital Pearl Harbor driven by offshore criminal and terrorist agents and Pandemic flaws at the architectural and base component level.) But unlike the special conditions permitted in the INL attack that was able to damage the diesel powerplant, but not the electrical generator, attacks against Supervisory Control and Data Acquisition (SCADA) can have pervasive, systemic effects.
Lay readers will not be happy after listening to Ganesh Devarajan merrily describe how easy it is assault SCADA devices, change apparent sensor values, take control of the system, what schematics he has seen terrorist members take an intense interest, et al. See his video at LayerOne 2007 and his slides on PDF.
A former NSA pen tester (penetration tester), Ira Winkler, describes how his team attacks SCADA networks:
There are two primary ways to break into a computer: (1) take advantage of bugs in the software, and (2) take advantage of the way a user or administrator configures or uses the computer...
Some bugs create elevated privileges, provide unauthorized access, or cause information leakage. These are security vulnerabilities. If you can connect to a computer that has not corrected such a vulnerability, you can take it over. It is that simple.
The vulnerability can exist in the operating system, SCADA applications software, Web browser, or any other software on the computer. In the case of SCADA and its supporting systems, power companies are very slow to mitigate the vulnerabilities, and may never do so, because they are afraid that any change can create problems. This is why power grid systems are likely to be more vulnerable to cyber attacks than most other computers.
With regard to taking advantage of configuration problems, even perfectly secure software can be set up insecurely. For example, I have seen many computers where the password on the Administrator account is "administrator." Passwords can otherwise be insecure. Low-level users can be given high-level access. There are also more technical ways to insecurely configure a computer. Again, if you can access a poorly configured computer, you can take it over.
Looking forward
We should expect to see parallel or overlapping attacks by criminal and terrorist groups, each of which could involve swarm attacks against multiple targets or tiers with a utility's network. Now that successful proof-of function interruptions are public knowledge, expect accelerated copycat events, although in the short-term, perpetrators may wait to observe what countermeasures, if any, are taken against them.
Given the interconnected nature of power grids, your network may become collateral damage to an attack on a seemingly distant network. Depending on the nature of an attack, it may be hard to determine if the perpetrator is criminal or terrorist (as terrorists also need funding).
Expect state countermeasures to draw counter-countermeasures from the attacker whomever they might be. Attack patterns will be watched closely as will the attacker watch and respond to the net countermeasures enacted against them. What will they be?
Targets will have to review their temporary power arrangements (many units will actually not start or will not run as long as expected) so as to not adversely impact business continuity. Supply chains will have to be reexamined for weak links due to any interruption of power at any tier on a global basis. (Think Hurricane Katrina and the lessons learned from it.)
How the merger of proprietary control systems and public internet occurred
An Ars Technica forum discussion on US approves standards to keep electric grid hacker-free contained this fine summary of how the power grid control merged with the internet:
Before the rapid adoption of the Internet we know today, these systems were operated in an isolated fashion. PLCs [Programmable Logic Controller] and RTUs [Remote Telemetry Unit or Remote Terminal Unit] in the field (devices monitoring, measuring, and responding to key points throughout the system) communicated using private networks to the control centers. Control centers communicated with the regional operators via private links, etc. The systems used to control the control centers were isolated from outside networks. They were expensive, highly-customized, and were very difficult to replace.
Along comes Unix (later Windows) systems. Control system manufacturers could just leverage common OSes and write their apps to run on those OSes--saving money. These systems were communicating with custom protocols over private networks. The protocols have no authentication/authorization, etc. See, when collecting data monitoring a grid, you need measurements multiple times per second in some cases. Adding 20% overhead for authenticating a packet on your private network was not needed.
Then comes the Internet as we know it. The corporate side of the business is using commodity OSes to operate, and wants to implement, say, a commercial billing system to run on the corporate network and print invoices, etc. That data is in the control center network. The invoice printing operations is in the corporate network. That's when the pressure (cost reductions) comes in to link the two.
There's also the pressure to encapsulate the custom protocols to run inside IP. That way, the systems can use the common network infrastructure (WAN links over ATM, leased lines, and the like) and reduce cost. Keep in mind that the underlying protocols haven't been rewritten to support authentication or encryption.
See, it's a delicate combination of two very different operating paradigms. Control systems folks focus on uptime and speed while corporate IT folks focus on security and control (by giving up uptime for patching, etc). The two networks are run very differently. There exists a division of knowledge about how to operate computer networks. This leads to shoddy divisions of the networks with weak or non-existent firewall policies so that the "grid" isn't affected by the IT staff. Also, understand that the control centers now communicate over the Internet using protocols encapsulated in IP. That's how they keep each other up to date. That's how the delicate balance of generation and demand is kept.
Recently, there has been an increase in awareness (a good thing!) of the brittle nature of the electric infrastructure. I say brittle because a common threat in the corporate environment (a Slammer/Blaster worm) now can have a devastating effect on the availability of the networks, applications, and systems supporting the monitoring of the control system if the two networks aren't properly segmented and controlled.
If a knowledgeable, malicious attacker was to gain direct access to a control system network, they would have the ability to tamper with the data presented to the operators and the software. They could feasibly cause a significant outage. How? Do things like tell the generators that they need to generate more power while at the same time opening some key switches over high voltage lines. Also, be sure to "hide" the real data from the operators and their displays, and they'll never know what's happening. They won't even respond, because their systems say everything is fine. These kinds of attacks are made possible due to the protocols not incorporating encryption or authentication. The data is often sent over IP, so many scanning and packet injection tools can perform this kind of packet injection trickery...
Basically, the cyber security controls and operating procedures of many control systems is 10-15 years behind what corporate IT is today. Putting the two together can often create risk... FERC [Federal Energy Regulatory Commission] [is] trying to establish a very modest baseline of security controls and procedures across the companies out there running their systems in 2008 using 1980's security methodologies...
Ultimately, this problem won't go away anytime soon. We can take steps to minimize the risk of cyber attack and minimize the damage caused by the loss of lines/substations. Our heavy reliance on the grid will always make it a credible target for attack...
Electrical power lags behind petroleum refining in security
Electrical power assets appear to lagging the refining industry in implementing realistic security. Here is one rationale, and given my work in the petroleum sector I can vouch for the attention paid to fire or explosion, but I find it too Pollyannaish in its timetable for bringing electricity current. I continue to wonder if we are talking about something akin to Y2K in the effort to find, fix, replace and (re)integrate the grid's firmware and software. (You only have to kill a few sites to start a cascade among many.):
[Refinery owners] have the resources, knowledge, and sophistication to implement comprehensive security programs. In the mid-tier and smaller refineries, this effort is moving at a slower pace; however, they still have progressed further in security than the power industry. There tends to be a heightened awareness for security in refining because loss of view and control in this industry can lead to greater loss of life and property...
While controls technology in refining is similar to that in the power industry, there are some important differences that may explain the variation in security preparedness:
In a refinery, there is more sophistication and discipline with respect to security and network architecture, and more effort put into system hardening.
In the power industry, you are more likely to find controls environments in unsecured areas, easily available to anyone who has access to the plant.
You may find more technicians working on controls systems in the power industry, while you tend to find more engineers working on controls systems in refining.
All of these differences can be reconciled once the power industry moves to proactive security.
I found it interesting that the World Economic Forum's Global Risks 2007 did not include power continuity among its 23 "core" global risks even though those chosen, e.g., "Oil price shock/energy supply interruptions," were said to of "systemic nature: their impacts challenge the integrity of the system. Their consequences are harder to predict, frequently disproportionate, difficult to contain and present challenges to us all." I put this up to the fact that power has not reached the public consciousness of petroleum.
An arduously slow road to 'not enough'
Note the consistent threat verbiage without concerted action:
1998: Jeffrey A. Hunker, then Director of the Critical Infrastructure Assurance Office (CIAO)
"The full support of the private sector" is vital in protecting U.S. critical infrastructures against cyber attack... "The threat that we are facing is a threat that's growing over time... And so we need to respond with a sense of urgency and produce real results very quickly to combat it.... I think that one major measure of success is going to be the extent to which the private sector -- the owners and operators of the electric power grid, and our transportation and our banking and finance sectors -- comes together and, with the government, develops an action plan. We'll be able to measure how that partnership has been formed within the next six months to a year."
2000: Richard Clarke on the assertion that cyberwar is a threat that US government cannot defend solely by federal means:
The owners and operators of electric power grids, banks and railroads; they're the ones who have to defend our infrastructure. The government doesn't own it, the government doesn't operate it , the government can't defend it. This is the first time where we have a potential foreign threat to the United States where the military can't save us.
2003: Interview with Richard Clarke regarding cyber tools by al Qaeda and other entities:
For an organization [that] is looking to leverage its investment, to have the biggest possible damage for the least possible investment, cyberspace is a good bet, because it doesn't cost a lot of money to develop these skills. You could have an effect in a number of places simultaneously, without being in those locations, and you can achieve a certain degree of anonymity and a certain degree of invulnerability to arrest [or] apprehension....
Mountain View [shows] the ease with which people can do virtual reconnaissance from overseas on our physical infrastructure and on our cyber infrastructure, and the difficulty that we have in knowing what is being done...
[Our] electric power companies, both the generating companies and the distribution companies, have paid very little attention to security in cyberspace. It took them a long time to even admit that they were connected to the Internet. Now they know that they are. Now they also know that they're running a control software, SCADA, that is available to our enemies, because it's software that's sold around the world. They are beginning to understand that they need to have security. And the Federal Electric Regulatory Commission is beginning to understand that it needs to regulate that, in order to create an even playing field...
I'd suggest the Federal Electric Regulatory Commission create an even standard for all power-generating companies and all power distribution companies, and a high standard that's achieved in several steps over the course of the next several year...
SCADA systems need to be encrypted. People who have access to them need to do authentication... But we also need to make sure that our control signals -- the signals that we send out over the electric power grid -- are not sent and clear, they're not broadcast on radio, but they're on fiber optic cables that are not connected to the Internet...
Unless power companies are required to do [this] by the federal government, they will never do it, because they're now in competition with each other. They're all willing to do it if they're all forced to do it... no one has competitive disadvantage by proving security...
We, as a country, have put all of our eggs in one basket... It could be that, in the future, people will look back on the American empire, the economic empire and the military empire, and say, "They didn't realize that they were building their whole empire on a fragile base. They had changed that base from brick and mortar to bits and bytes, and they never fortified it."
2005: cyber-security a distant second to physical security:
"People downplay the importance of cyber-security, claiming that no one will ever die in a cyber-attack, but they're wrong," says Richard Clarke... "This is a serious threat."... "An attack on the scale of the Bhopal disaster in India is not impossible"... Despite such a nightmare scenario, federal officials are more immediately focused on the threat of a dual attack... a physical attack and a simultaneous cyber-attack on critical infrastructure"...
Many experts say that DHS is still relatively unprepared to protect America's critical infrastructure against a cyber-attack. "In government, when it came to senior level focus after Sept. 11, 99.9 percent was skewed towards physical protection, and cyber-security took a back seat."...
The industry has a lot to address, Clarke says. "Every time the government has tested the security of the electric power industry, we've been able to hack our way in - sometimes through an obscure route like the billing system."... "Computer-security officers at a number of chemical plants have indicated privately that they are very concerned about the openness of their networks and how easily they might be penetrated."
2007: This author on Cyber Storm:
[It] does not give this author comfort that the first federal cyber war exercise, Cyber Storm, carried out in February 2006 had such a relatively positive outcome. (It is moments like this when I remember the counsel of a skilled practitioner who noted that any exercise presided over by political elites must be designed not to fail lest their stewardship be called into doubt.) Cyber Storm was to provide a "controlled environment to exercise State, Federal, International, and Private Sector response to a cyber related incident of national significance"...
Having spun scenarios without limit, Cyber Storm's "Overarching Lessons Learned" offer painful parallels to each of the TOPOFF series simulating large-scale terrorist attacks involving biologic, chemical and radiological WMDs ("diseases are fearsome, hospitals and first responders are overwhelmed, interagency and intra-agency coordination is pummeled while communications in the form of multiple control centers, numerous liaisons, and increasing numbers of response teams merely complicate the emergency response effort")... Who could be surprised by these lessons learned? They could describe any large bureaucracy under stress, perhaps even their daily environment...
2007: An insufficiently strong standard emerges:
"NERC reliability standards [are] less stringent guidelines than [those offered in the] NIST guidance," said Greg Wilshusen, director of information security issues at the Government Accountability Office. "They do not provide the level of standard, mandatory protection required."
Specifically, NERC standards focus on the bulk power system as a whole, but don't properly address the threat of regional outages or the security of the IT components that support the electric grid, Langevin said. By contrast, the System Protection Profile for Industrial Control Systems developed by NIST in collaboration with private sector organizations presents a cross-industry, baseline set of security requirements for new industrial control systems that vendors and system integrators can use. Government has not yet enforced the adoption of these requirements.
"Why [NERC] would have standards below NIST is beyond me," Langevin said. "This is something we're going to [pay] close attention to; perhaps legislation will be required."
2008: The problem will get worse before it gets better. From a 2005-2007 study of electric utilities' energy management systems, SCADA and distribution management systems:
Linkage to other utility enterprise systems continued to be on the increase on a global scale; despite cyber security concerns. For many sites, the key to remaining secure seemed to be either: (a) the restricted provision of non-real-time access via periodic downloads to authorized requestors or (b) indirect access to and from the control system via historian files. Newton-Evans anticipates some changes in priorities this year, with a likelihood that many U.S. utilities will be implementing a NERC compliance reporting system over the 2008-2010 period.
Examples of flaws and entry points
Rather than asking how safe are the current SCADA and related architectures, better to ask how can such an environment not offer multiple opportunities for mischief? For examples of mischief, Schneier's weblog entry, Staged Attack Causes Generator to Self-Destruct, contained reader comments which I've categorized under two topics: systemic fault opportunities and attack vectors. (While the commentary of many forums is dross, Schneier's readers did a creditable job.)
Systemic fault opportunities
Still designing for efficiency, not security, and allowing connection of systems designed for closed proprietary systems onto the web:
1, The [SCADA] systems are designed by engineers with only one [aspect] in mind to control complex systems (oil platforms etc)... The problem with 1 is that security was never ever a consideration in the design. And like Unix most SCADA systems will do as they are told irespective of the consiquences.
2, [Management] no longer want to pay to have people on site any longer just on call from home or some other office in the world... The problem with 2 is that the Internet is the cheapest solution...
The result is systems that have no built in safe guards appearing on the internet with minimal security...
[More] and more of the old electrical mechanical relay logic controls [in electrical utilities] have been replaced by PLCs, RTUs and bay level controllers, combined with SCADA. Yes, the majority of SCADA systems used run on commodity hardware and Windows OS...
In most cases, the new Ethernet based control protocols are secret... (the exception being Modbus/TCP). The companies which own them provide binary drivers in a format known as "OPC". OPC runs only on Windows, so a customer pretty much has to use Windows to run their SCADA system whether they want to or not.
The field devices which are controlled by these protocols are not very sophisticated and will accept commands from anywhere without requiring any sort of authentication. The assumption is that if you are on the network, you are not going to do anything malicious...
Cost reduction:
SCADA vendors want to cut their costs and only support one platform. We initially were told by our SCADA vendor that we would have to go all Windows, HMI [Human-Machine Interface] workstations & servers, if we wanted to upgrade to the latest version of their system...
Every penny saved is another penny in the vendor's pocket... It doesn't matter how good your design is because the customers will demand arbitrary price cuts. This is standard purchasing department tactics during the negotiation of any purchase...
[US] utilities used to pay into EPRI [Electric Power Research Institute] to get research done for the common good. EPRI would have been the logical party to deal with these problems. After deregulation [many] of these companies are not willing to pay for research anymore...
Cost-benefit analysis driving out dedicated networks:
[These] systems were networked, usually over a fairly slow wire, so it is all in allowing the control systems to do more than monitor and control devices over the specialized SCADA network, since the remote devices [may] be speaking IP... but, in Power/Gas/etc networks, there's a lot of equipment that would be considered obsolescent (Anyone remember Visicode switches? PDMs?) but, if they work, won't be scrapped.
Employ new application/use case without redesign:
A system used in a way or in an environment for which it was not designed is a potential problem... SCADA systems were largely designed to not be connected to the Internet. Simply connecting them without significant redesign is a recipe for serious problems.
Aging, unpatched equipment. See the incongruity in this polar pair:
- SCADA systems are built using off the shelf components (on the human interface side), MS Windows is common.- The systems are seldom patched, in some cases, the software vendor will not support systems that have 'unapproved' patches.- The systems are built with life expectancies measured in decades...
The only thing which has kept this from being a major problem so far is that most plant equipment is old so equipment with this capability is in the minority. The only practical solution is to put the plant on an isolated network with some sort of intermediary security box between the plant and the office which only allows limited information to pass each way. Trying to secure every individual valve and other plant device is unrealistic...
20-year old technology? That is sometimes the newer equipment in the generation plants and substations. Dial-up accessible? Absolutely. Modems left enabled? More often than you would think. And, yes, the newer hardware is IP accessible, not always securely installed and configured...
Human error in procedure and programming:
In one incident a contracter anxious to complete his installation connected 2 completely [separate] parts of our banking network together totally compromising our security. We only discovered it days later when we could contact servers we should not have been able to. Another was 100 servers rolled out with their C: drives open to anonymous and undetectable attacks because of one configuration error. Again this was in a sector that you would expect to be secure however it was not. On yet another occasion I went to a shared PC to fix it and written in pencil around the edges of the monitor where all the usernames and passwords of all the people that used this particular PC to access the banks systems.
Complexity of equipment and their controllers:
Newer GE gas turbine control systems use PCs with Windows for the MMI [Man Machine Interface]. They have discontinued their own MMI system, and currently sell a re-branded product from someone else... MMI is what you use to control the equipment. If you control the MMI, you control the equipment. The equipment control system itself has protective relays and other over rides, but the MMI system still has a lot of factors and parameters that are set at commissioning which can damage the equipment if set incorrectly. You can also of course, simply shut down the system by issuing a shutdown command...
GE is a mixed bag with regards to their offerings... last I had heard they had 13+ different SCADA systems depending on the division you were working with. But I can say authoritatively that their Energy Management System offerings are UNIX, same with Siemens. I do seem to remember that they had a smaller Distribution Mgmt. System that was windows based, but those systems typically don't have [a] generation control, merely routing at the street level.
[For] the bigger electric systems like , Southern California, NYC, Southern NJ, etc... cost of computing hardware was not a concern... Some smaller rural utilities may see that cost reduction from running Windows make a significant change to the overall price of an a new control system...
Embedded systems face problems akin to SCADA:
[M]ore and more critical control functions in things like electrical generation, chemical production, and so on are handed over to embedded systems, because they can be, and because it makes things like maintenance and troubleshooting easier. And again, in service of convenience for management and maintenance, it's all getting networked, with everything from 9600 baud modems over POTS (who said wardialing was dead?) to the latest fiberoptics and even short-range wireless in some cases.
The fundamental problem is that your average embedded guy doesn't know much of anything about network security, and isn't hooked into social or professional networks that might tell him. OTOH, he's got an advantage over your average programmer, because embedded systems have to be much more tightly built in the first place, i.e. unhandled cases are unacceptable in general, and critical bugs tend to get fixed quickly, because the consequences are potentially catastrophic in a way that crashing your computer simply isn't. The software is also immensely simpler and more rigid than your average network application. The first step is to convince embedded programmers and their managers that malicious attack is as real and urgent a potential failure as any of the others that the software must handle.
Attack vectors
Insider attack:
A malicious or inattentive operator at the plant in the middle of the night could do the same thing. Nothing "cyber" is necessary for this attack.
Insiders, often foreign, hired without proper checks:
It's very hard to background check an engineer when you have so very few of them, and the pool of replacements is mostly from overseas. In the old days, you didn't have to -- the engineering schools knew that they were putting lives in these men's hands, so verifying the diploma was good enough.
The most disturbing trend I have seen in background checks is to preferentially hire recent immigrants from overseas (with background check waivers are in effect) as opposed to U.S. citizens with no criminal record but spotty credit or other risk factors. Sometimes this is a H1B issue.
More often, it's a product of laziness in not conducting real backgrounds on people born outside the USA. Unless DHS is doing really, really good checks prior to allowing these people into the USA (which takes a lot of money), this is a serious vulnerability with respect to international terrorism.
Access network assets indirectly:
[Power system component] systems are not typically "connected to the internet". They are, however, interfaced to most companies business networks, through some type of firewall, in order for operational data to make it to "the business", and for maintenance staff to access diagnostic information. This connectivity, however, can safely be managed following fairly standard methods of defense in depth, and implementing reasonable security practices.
War dialing remains a valid attack:
Modems are still a relevant attack vector... Everything from PBXs, manufacturing gear, even an accounting system.
Look for an overlooked access point:
[Hack] into control of the transmission / distribution system - look around some pole tops, there are radio controlled switches everywhere.
Affect a cascading overload:
[A] "cascading overload" is one where a local problem caused by any local event propergates out of the local area into other areas that are not at fault... In previous times suppliers put sufficient and well thought out safegaurds into their networks and introduced changes in a managable fashion... Unfortunatly the modern drive to maximise efficiency and return makes the likleyhood of such propergating faults all the more common.
Insert common worms and viruses:
Older SCADA systems used to run on proprietary hardware or on UNIX workstations. Newer ones are using PCs with Windows for display, monitoring, alarm display and data logging. On the more sophisticated systems control though is often still through proprietary hardware, but on the cheaper ones control is done on the same PC as display. The industry has gone this way to take advantage of cheaper PC hardware. There are a few vendors basing their systems on Linux instead of Windows, but these ones specialise in the more sophisticated end of the market. Wonderware, Citec, WinCC, Rockwell, etc. however all use Windows.
[A] worm or virus could DDOS or send undesirable commands to pretty much any newer control system if it can get access to the network. The SCADA networks are getting connected to the business networks because the business side wants real time reporting and production scheduling. This means that if viruses and worms are a realistic threat to office PCs, they are a realistic threat to the plant as well.
Issue simple, directed on/off commands:
[The] potential for "script kiddie" or "wrench-in-the-works" type attacks [in which] Simple 'If-it's-on-turn-it-off, if-it's-off-turn-it-on' type of "button pushing" could really raise havoc on a wide scale... All this takes is system level access and rudimentary programming skills.
Insert bad data:
[All] command and control information is passed between sensors..., control units..., and actuators... Over a bus. Airplane manufactures went digital for many reasons: to save money [and] to make the equipment more reliable... [S]ystems will eventually distribute sensory, control and actuator functionality over a network. That means that the sensory data upon which the control function operates will be vulnerable to attack as well as the commands to actuators, engines, valves, &etc. Can every electronic device in every system have its own security front-end to protect its data communications? If not, could one bring down, say, a power network by simply faking data values from a remote transformer farm saying "Hey! I'm overloaded!" and let the control function (over-) react?
This is probably the way that any attack would be carried out. Operators that use remote system implicitly trust the reading on their instruments. One of the most efficient ways to disable a system is to supply bogus readings and watch the operators crash their own systems. Do it at 3:00am when peoples decision making is at its worst and it could be serious.
Try the default passwords:
Of course Iran (and China, Pakistan, N. Korea, etc.) know the passwords. It is amazing how many times the default password is not changed. [There are not] that many vendors out there to choose from and the manuals are available on the 'net.
Affect phase mismatch via manipulation of the power grid configuration and/or load balancing equipment (LBE):
If a key point on the power grid could be closed, then two legs of the grid would become connected. If these two legs are of different [wave] length, then there would be a phase difference between them. A difference in length of the two legs of just a few miles would cause a slight phase difference that would cause serious trouble on a megavolt power line.
While the power grid is designed to provide dynamic control of this phase difference, as well as phase compensators (switchable capacitive and inductive loads to compensate for the phase difference), if one could rapidly switch in and out several legs in the power grid, the dynamics of such a rapid change in power load and phase would be very difficult to compensate for. Weak spots in the grid would overload or burn out as they dissipated the heat developed by the current from the phase mismatch.
Pick an easy entry point to remove a node:
[Many local substations can] be unmanned, secluded, and guarded only by a chain-link fence and some barbed wire. Most of the gear and lines appears uninsulated... you could raise a whole lot of havoc with a good arm and a roll of heavy-duty aluminum foil.
This is not far off the mark. The US first used the BLU-114/B special-purpose munition, containing reels of "chemically treated carbon graphite filaments, to attack to attack the Serbian power grid in 1999, virtually terminating Serbian power generation and distribution by shorting out the system. (This link also has an informative 'Electrical Distribution System Overview' written from the viewpoint of disruption.)
Time to affect repair is often sufficient damage or a causal condition for another default:
it's not how much damage an insider could do (enormous!) but how long it would take to fix. Some of the equipment used in the power distribution system is manufactured only a few places in the world; spare parts inventory does not exist; lead time for replacement is measured in months not weeks; and transportation of these larger than 8'x8'x40' components is a real hassle under 'ordinary' conditions.
Is your data center prewired to be able to use rental generators for weeks or months if necessary? Do you have ironclad contracts with multiple sources of said generators? Did you think to strike the 'act of God' clause regarding nonperformance in the event of natural or man-made disaster?
If not, you're kidding yourself about maintaining uptime in a disaster. The fastest way to find out that your on-site generators haven't been properly maintained is to run them for a week and watch them fail . . . In a real disaster, your emergency generators are a temporary bridge to some other power source. Unless you thoughtfully lay hands on a generator technician you employ, a large spare parts inventory, and ridiculous amount of diesel fuel storage well in advance.
CIA: Hackers Shook Up Power Grids (Updated)By Noah ShachtmanDanger RoomJanuary 19, 2008 2:58:00 PM
CIA launches hunt for international computer hackers threatening to hold cities ransom by shutting off powerBy WILLIAM LOWTHERDaily MailLast updated at 23:33pm on 18th January 2008
Hackers Cut Cities' PowerAndy GreenbergForbes01.18.08, 7:00 PM ET
Title is error as text states outside the US:CIA official: North American power company systems hackedBy Jill R. Aitoro jaitoro@govexec.comGovExecJanuary 18, 2008
SANS Flash: CIA Confirms Cyber Attack Caused Multi-City Power OutageThe SANS InstituteSANS NewsBites Vol. 10 Num. 5Fri Jan 18 14:59:14 2008
US approves standards to keep electric grid hacker-freeBy Nate AndersonArs Technica