eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Following on some interesting vulnerability research in the area by vendors who shall go unnamed for the purpose of avoiding conflicts of interest (ahem…) SCADA security experts Uniloc have published a top 10 list of tips for keeping the systems safe from attacks.
This is encouraging stuff, seeing as how not too long ago the systems (that are used to control and monitor operations of massive plants and factories, if you are unfamiliar) seemed relatively overlooked in the security department, aside from the product efforts of vendors including Uniloc and Industrial Defender, among a select few others.
The reason why vulnerabilities in SCADA networks are so important to address is because the potential for fallout if they get taken offline or messed about with is absolutely disastrous, with some people already claiming that the massive U.S. power outage of 2003 resulted from such an assault.
You get the picture…rather than merely stealing some data or interrupting transactions the idea is that if someone could harm a major SCADA operation they might be able to knock out critical infrastructure services to a large geography or somehow make a big power plant go boom.
The real risk around SCADA, one that vendors in the arena have tried to downplay as they say their systems were not designed to be used as such, is when companies link the technologies to public networks and open the potential for remote attacks. As we know, even when people are advised that doing something like this is a horrible idea, eventually somehow it happens, either by sheer negligence in decision making, or via accidental oversight.
“Many customers asked us to send them basic information about how best to secure their SCADA networks,” said Jim White, vice president of biz dev for Uniloc, in the company’s advisory. “After receiving significant feedback from the industry, it is in the best interest of our nation that those managing its critical infrastructure have the most advanced technology and methodologies available for securing these networks.”
So, without further ado, here are Uniloc’s recommendations on the steps that SCADA system operators should take to avoid potential security issues:
1. Do serious risk analysis. Determine what your exposure is to identified threats, their consequences, cost of mitigation and risk tolerance. Create a risk profile of critical assets, using it as a basis to develop policies and procedures prior to deploying technologies.
2. Implement policies and procedures. Before implementing any technical solution, create a comprehensive set of policies and procedures that serve as guidance to operators, security personnel, vendors and anybody who could have access to or contact with SCADA systems.
3. Ignore training at your peril. Often overlooked, staff training is one of the most important components of a good security plan. Having the right technical policies, procedures and infrastructure is useless without people knowing how to properly use them. Training should encompass all aspects of your security plan.
4. Make security policies as important as safety policies. You should have zero tolerance within the organization for security breaches across any aspect of your SCADA environment. Such breaches can lead to loss of life, bodily injury or other consequences such as a detrimental impact on the environment or local community.
5. Integrate physical and cyber security. Physical access controls and surveillance technologies need to be integrated into an overall cyber security infrastructure. Just as SCADA has migrated to the use of IP protocols and COTs technologies, access and surveillance functions have moved in parallel. Integrating these functions creates a coordinated approach to protecting critical systems.
6. Create a “trust” zone. Isolate cyber assets from all personnel except those specifically authorized. Focus on methodologies and technologies that authenticate and authorize only those who are trusted and prohibits all others by default.
7. Establish authentication for users and devices/systems. Device/system “fingerprinting” provides the first layer in creating a “cyber fortress” architecture. Such architecture creates a trust perimeter for both SCADA systems and access clients based on the actual physical fingerprint authentication of systems and devices.
8. Strictly enforce privileges. Ensure that only authenticated systems and clients are allowed to communicate across an encrypted communications channel. All applications should use RBAC (Role Based Access Control) at both the application and device level. Device fingerprinting technology allows RBAC to be implemented at a level that has not been available before — the device itself.
9. Use dynamic password methodologies. Periodically changing passwords is a best-practice policy worth following. However, in some cases the policy can be restrictive and unenforceable. Using a dynamic challenge and response mechanism between hardware devices creates a hardware password that is enforced dynamically and only known between trusted devices.
10. Adopt physical device recognition. Many companies seek to mitigate the risk of problems caused by humans (traditionally the “weak link” in security systems) by using multi-factor authentication, notably human biometrics such as retina scanning, smart cards and fingerprinting. While all of these serve to identify an authorized user, most are not practical in an industrial environment. The best solution is to include a user’s computer as part of an identity and access control solution, validating identity through multi-factor identification.
Matt Hines has been following the IT industry for over a decade as a reporter and blogger, and has been specifically focused on the security space since 2003, including a previous stint writing for eWeek and contributing to the Security Watch blog. Hines is currently employed as marketing communications manager at Core Security Technologies, a Boston-based maker of security testing software. The views expressed herein do not necessarily represent the views of Core Security, and neither the company, nor its products and services will be actively discussed in the blog. Please send news, research or tips to SecurityWatchBlog@gmail.com.