Enhancing
Network Scanning
For
Discovering Vulnerabilities
(ENSDV)
by
Raymond Cordova MEIA
University of Colorado at Colorado Springs, Colorado, 2010
A Thesis
Submitted to the Faculty of the Graduate School
University of Colorado at Colorado Springs
Partial Fulfillment of the Requirements
for the degree of
Master of Engineering in Information Assurance
Department of Computer Science
2010
ii
Thesis for the Master of Engineering Degree in
Information Assurance
by
Raymond Cordova
has been approved for the
Department of Computer Science
by
_______________________________________________________
Advisor: Dr. C. Edward Chow
_______________________________________________________
Dr. Jugal K. Kalita
_______________________________________________________
Dr. Rory Lewis
_____________________
Date
iii
ENSDV
Enhance
Network Scanning for
Discovering Vulnerabilities
Master of Engineering, Information Assurance
Thesis directed by Associate Dean Professor C. Edward Chow
Department of Computer Science
iv
Enhance
Network Scanning for
Discovering Vulnerabilities
(Master of Engineering, Information Assurance)
Thesis directed by Associate Dean Professor C. Edward Chow
Department of Computer Science
Abstract
With the advent of the 911 terrorist attack and the subsequent identification of the
vulnerabilities of our most critical systems that include the power grid, directives from
government entities such as Homeland Security, has coined the term “Smart Grid” to
describe Industrial Control Systems (ICS) as a power grid of the near future; an
intelligent, self-healing, real-time system. The ongoing effort to develop secure
communications products and technologies specifically designed to operate reliably in
harsh environments around the world must be used for mission critical applications..
The methodology and prevention of attacks to ICS networks is by far one of the most
important projects since the creation of the Internet. It should be noted that the
number of vulnerabilities can be exploited and the critical nature of an exploit is much
more than that of Internet and computer based vulnerabilities. With this in mind,
enhanced network scanning for discovering vulnerabilities becomes an important
v
research area. This thesis proposes to show that the Nessus vulnerability and
compliance check scanner can be enhanced to discover network vulnerabilities. Many
vulnerabilities require the development of plug-ins written specifically to address
issues not addressed by the standard set of subscription plug-ins. Developing and
creating new plug-ins can enhance the Nessus scanner to discover vulnerabilities and
check for compliance of policies. Integrating the new plug-ins with the standard set
improves on the standard scanner as shown in reporting results.
vi
Acknowledgements
I would like to take the opportunity to sincerely thank Dr, Edward Chow for the
support, his tireless efforts, the valuable time he spends in consultation, the
encouragement he has provided, and the direction to guide me through the challenging
coursework at UCCS. This is my opportunity to thank Dr. Chow, being that he does
so much for others, generously giving his time and providing help and motivation. I
truly appreciate Dr. Chow for the person that he is.
I would also like to thank Renaud Deraison from Tenable Nessus for providing the
ProfessionalFeed version of the Nessus scanner for the experiments and research.
Without his contribution, this research would not have been possible.
vii
Table of Contents
Abstract
iv
Acknowledgements
vi
Table of Contents
vii
List of Figures
ix
List of Scripts
xi
Tables
xi
Appendices
xi
Chapter1
Industrial Control Systems Recommended Guidelines,
1
Standards and Regulations in Emerging Technology
Chapter 2
5
Emerging Technology
2.1
Wireless Comes of Age
9
2.2
Vulnerabilities
10
Chapter 3
13
Nessus Scanning
3.1
Bandolier Related Work
14
3.2
Compliance Checks
14
3.3
Compliance Checks Versus Vulnerability Scan
15
3.4
Development Approach
16
3.5
Extending Bandolier with Nessus Credentialed Scanning
21
3.6
Nessus Quick Reference Installation and Upgrade Guide
22
3.6.1
Nessus Background
23
3.6.2
OS Support
24
3.6.3
Prerequisites
25
viii
3.6.4
Installation
26
3.7
Upgrading Unix/Linux
39
3.8
Upgrading Windows
52
3.9
Nessus Directory Configuration
53
3.10
Nessus Server Manager and Client Interface
55
3.11
Changing Default Nessus Port
56
3.12
Registering the Nessus Installation
57
3.13
Adding User Accounts
57
3.14
Host-Based Firewalls
61
3.15
Other Operating System Configuration
62
3.16
Policy Compliance Plug-ins
63
3.17
Patch Auditing
64
3.18
Netstat Port Scanner
65
3.19
Reporting
66
3.20
Nessus Scanner Use
69
3.21
Nessus User Configuration Tab
70
3.22
Nessus Policy Configuration Tab
71
3.23
Nessus Scan Tab
72
3.24
Nessus Report Tab
73
3.25
Customize Policies
74
3.26
Nessus Scan Performance Metrics
81
Chapter 4
92
Lessons Learned
4.1
SCADA Access
92
4.2
Meter and Development Kit Procurement
92
4.3
Nessus Scanner
94
4.4
Digital Bond Bandolier Project Compliance
96
Check Plug-ins
ix
4.5
Nessus Attack Scripting Language (NASL)
97
4.6
VMware
98
102
Chapter 5
Future Direction
5.1
Texas Instruments Development Kit
102
5.2
Automatically Patching Failed Compliance Checks
102
5.3
Shared Plug-ins
103
5.4
OS Extensions
103
5.5
System Alert for Detecting Plug-in Removal
103
106
Chapter 6
Conclusion
109
References
List of Figures
Figure 2-1.
ICS Security
7
Figure 2.2
Emerging Technology Physical Challenges
7
Figure 2.3
Smart Metering Scope
8
Figure 2.3
Wired and Wireless Options
8
Figure 3.1
Windows Nessus Download Files
35
Figure 3.2
Windows Nessus Welcome Screen
36
Figure 3.3
Windows Nessus License Agreement
37
Figure 3.4
Windows Nessus Destination Folder
37
Figure 3.5
Windows Nessus Setup Type
38
Figure 3.6
Windows Nessus Install Dialog
38
Figure 3.7
Windows Nessus Completion Dialog
39
Figure 3.8
Windows Server Manager Configuration
56
x
Figure 3.9
Activated Windows Server Manager Dialog
58
Figure 3.10
Nessus User Management Dialog
59
Figure 3.11
Nessus Add/Edit User Dialog
60
Figure 3.12
Nessus Client Login User Dialog
61
Figure 3.13
Configuration Screen for Credentials
63
Figure 3.14
Policy Compliance Plug-ins
64
Figure 3.15.
Example plug-in Selection of Operating System and
65
Application Security Scans
Figure 3.16
Customize Policy Edit
66
Figure 3.17
Report Example of the iepeers_dll_0day.nasl plug-in and
67
Windows Compliance Checks on an un-patched XP virtual
machine
Figure 3.17.1 Report Example of the SSH Remote Root Login Compliance
68
Check on a Fedora Core 12 virtual machine
Figure 3.18
Nessus User Tab
70
Figure 3.19
Nessus Policy Tab
71
Figure 3.20
Nessus Scan Tab
72
Figure 3.21
Nessus Report Tab
73
Figure 3.22
Prototype Layout
82
Figure 3.23
Nessus Scan Performance Times on Prototype
84
Figure 3.24
Nessus Non-credential Scan Performance Times on ISSG
87
Lab
xi
Figure 3.25
Nessus Non-Credentialed Scan on ISSG Lab
88
Figure 3.26
Nessus Credentialed Scan on ISSG Lab
89
Figure 4.1
Successful Nessus Database Rebuild and Re-index
96
Figure B.1
Itron OpenWay® Solution
115
Figure B.2
CC2530 ZDK Development Kit Cost
120
List of Scripts
Script 3.1
XP “iepeers.dll” 0-day Vulnerability Script
74
Script 3.2
XP USB Storage Devices Disabled Compliance Check
78
Audit Script
Script 3.3
XP CDROM Auto-play Disabled Compliance Check Audit
80
Script
Script 3.4
Fedora 12 SSH Remote Root Login Disabled Compliance
81
Check Audit Script
Tables
Table 1. Prototype Nessus Scan Time
83
Table 2. ISSG Nessus Scan
85
Appendices
Appendix A Security Descriptors
112
Appendix B Selected Vendor Smart Meters
113
1
Chapter 1 Introduction
Industrial Control System
Recommended Guidelines,
Standards and Regulations in the
Emerging Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards
and Technology (NIST) promotes the U.S. economy and public welfare and provides
technical leadership for the nation’s measurement and standards infrastructure.
Specific requirements and methodologies for information system categorization are
described in Technology (NIST) FIPS 199.
The requirements for addressing
minimum security controls for a system are described in NIST SP 800-53
(Recommended Security Controls for Federal Information Systems) and NIST FIPS
200 (Minimum Security Requirements for Federal Information and Information
System). ITL responsibilities include the development of technical, physical,
2
administrative, and management standards and guidelines for the cost-effective
security and privacy of sensitive unclassified information in the nation’s computer
systems that have emerged to provide control of industrial control networks.
In the emerging stages of development, inexpensive Internet Protocol (IP) devices
began replacing proprietary isolated systems running proprietary control protocols
using specialized hardware and software. The possibility of cyber security
vulnerabilities and incidents increased as ICS began adopting Internet solutions to
promote corporate business systems connectivity and remote access capabilities [15].
A different approach was needed to address the issues [14]. These new design
implementations using industry standard computers, operating systems (OS) and
network protocols began to resemble Internet systems. These Internet integration
solutions provided the needed capabilities, but it also introduced a multitude of
vulnerabilities, problems, and issues and provided significantly less isolation for ICS
from the outside world creating a greater need to secure these systems.. As mentioned
earlier, the ITL standards set forth in the NIST 800 series documents is a challenging
and daunting task [9]. This task is coupled with securing Internet access to ICS
systems, isolating the ICS, and providing a secure, safe, reliable control system. It is
interesting to note how emerging technologies have lowered the infrastructure costs
and use existing physical entities and infrastructure.
As these AMI/AMR solutions are implemented, there must be a controlled effort to
ensure security is built in so as not to produce results similar to the problems
3
encountered by the staggering growth of the Internet which produced undesirable
circumstances in which services were the most important factor.
Many commercial venders have recognized the demand for specialized products
such as hardened servers, routers and Ethernet switches, Encrypted Receiver
Transmitter (ERT) Meters, and a variety of other devices to complete the
communications backbone solution for the smart grid. The development of a Smart
Grid has focused on Security, being that the new ICS will inherently have all of the
vulnerabilities of Internet and computer based systems. It will be critical for the smart
grids to provide confidentiality, integrity and availability to ensure the critical
infrastructure is not compromised in the event of a catastrophic failure, cyber event or
and unforeseen disaster. Authoritative entities have produced the NIST 800-82 Guide
to Industrial Control Systems Security (ICS) [11 [15] in an effort to provide guidance
to establish secure industrial control systems (ICS). The methodology and prevention
of attacks to ICS networks is by far one of the most important projects since the
creation of the Internet. The wide variety of available hacking tools has the
Information Technology industry in a precarious state of insecurity, whereas efforts to
prevent the unauthorized use of the ICS network is of critical importance and is one
of the most important aspects of protecting smart grid computing systems. This is a
task that will take systems administrator, security administrators and utility
employees into a new realm of Security to defend the ICS network against those
attacks and unforeseen events. It should be noted that the number of vulnerabilities
4
that can be exploited and the critical nature of an exploit is much more than Internet
and computer based vulnerabilities.
Instead, not only does the development of
Supervisory Control and Data Acquisition (SCADA) systems, ICS or Smart Grids
take conventional computer based vulnerabilities into account, but also new and
ambiguous vulnerabilities that are being identified are unique to the critical smart grid
industry. Policies and processes exist with new vulnerabilities being discovered daily
and new tools, code, procedures and processes are generated daily address any
deficiency in the development of the smart grid systems. There can only be strict
adherence to the requirements and ongoing System Development Life Cycle and
Security Development Lifecycle to continually ensure security in the ICS networks.
In this manner, security can be built into the systems that are critical to the safe
operation of critical infrastructure components.
5
Chapter 2 Emerging Technology
There have been many problems associated with the rapid growth of the Internet.
The vulnerabilities associated with the Internet are well known problems that
introduce a critical security problem to ICS. Many of the solutions to prevent these
vulnerabilities have been no more than a band-aid fix that are not at all ideal in their
implementation. Many of the solutions to the problems have only introduced other
problems that introduce other security risks. With all the problems that currently
effect the IP based technology, it becomes imperative to follow the directives set forth
by the NIST 800 series documents. It becomes a monumental task to secure an
already vulnerable IP-based system and to secure emerging technology. Emerging
technology solutions have inherent vulnerabilities in their own implementations. It
seems reasonable to expect emerging technologies will require all the traditional tasks
of security updates, patches, updates and upgrades as will as providing System
Development Life Cycle activity of the emerging technologies implemented to
provide solutions to ICS. As the emerging technologies are implemented, care must
be given to the implementation and infrastructure with a focus on three components;
availability, integrity, and confidentiality of the ICS are critical and must be strictly
adhered to in order to provide a safe and secure system.
The implementation of security in the leaf products of the various AMI/AMR
devices becomes a major task of providing a reliable and safe solution of gathering
6
information from millions of end points. As is the case with any emerging
technology, new solutions have inherent vulnerabilities, and the Advanced Metering
Infrastructure/Advanced Metering Readers (AMI/AMR) is not an exception. These
smart meters must be considered as a device that can be used to gain access to the
larger infrastructure, the SCADA power grid. Therefore, every precaution must be
taken to protect the meters since these smart meters are a potential gateway to the
more critical SCADA power grid infrastructure.
Several problems are associated with the securing smart meters. These meters must
update usage statistics for, which include but are not limited to several resources,
such as gas, water, and electricity. It is critical that every effort to maintain security
for these devices becomes a normal practice in order to provide a safe and secure
system.
The following figures illustrate the infrastructure, physical challenges, scope, and
wired and wireless solutions:
 See Figure 2.1 for an illustration of securing a typical ICS [2].
 Figure 2.2 shows the challenge of physical security [2].
 See Figure 2.3 for the scope of the smart metering system [16].
 Figure 2.4 shows a typical ICS infrastructure with wired and wireless
solutions [16].
7
Securing Control Networks
5/29/2009
Smart Grid Education Workshop / Chow
10
Figure 2.1 ICS Security
Figure 2.2 Emerging Technology Physical Challenges
Graphics use permission granted from Dr. Edward Chow, UCCS, 2010
8
Figure 2.3 Smart Metering Scope [16]
Figure 2.4 Wired and Wireless Options [16]
9
2.1
Wireless Comes of Age
The use of radio technology to provide wireless solutions with such devices as
mobile phones, laptop computers and common consumer equipment make the use of
wireless technologies a feasible option for solutions to provide business capabilities
and remote access to ICS. Many types of wireless communications are usually
distinguished by the frequency band, the standards used, and the primary application.
Many wireless applications such as ZigBee, Bluetooth and ZWave have been
implemented as computing and telecommunications solutions in markets such as home
automation and building control, SCADA systems and even livestock control. Many
other commercial options for low power radio have been specifically developed,
evolved and emerged as viable solutions for utility communications. Emerging
implementations include the M-Bus standards used for smart metering in northern
Europe, the Wavenis solution used for water metering in France and the Trilliant
platform being used by some utilities in Canada. Utilities in America and Australia
offer a specific Smart Energy profile with ZigBee which was developed to provide
smart metering connectivity to home area networks.
The low-power mesh infrastructure design bounces packets of data through a series
of nodes to reach their target. This type of network topology offers the protection of
avoiding potential single points of failure in a network. This is critical in the design of
the solution. This type of mesh network increases the power consumption of every
fully functional node. Each node must be able to receive and transmit data to and from
10
other close proximity nodes whenever data transfers are required. Some mesh based
devices will be configured as non-repeating “end” devices to facilitate lower power
consumption.
2.2
Vulnerabilities
Definition: A Vulnerability Class is a category of weakness which could adversely
impact the operation of the Smart Grid. A “vulnerability” can be leveraged to cause
disruption or influence the Smart Grid [7].
Millions of homes and businesses are using smart meters that are riddled with
security bugs that could bring down the power grid. Of particular concern, these new
smart electricity meters are being implemented despite vulnerabilities that can open
the door to power -grid botnets that have been identified in several vendor smart meter
devices. The smart meters provide two-way communications between electricity users
and collection devices that ultimately connect to the power plants that serve them.
Utilities in Seattle, Houston, Miami, and elsewhere are hurriedly implementing them
as part of a plan to make the power grid more efficient. Funded by billions of dollars
from President Obama's economic stimulus package, utility organizations have
continued to install the smart meters. Other organizations throughout Europe are also
spending heavily on the new technology. The problem becomes evident when meters
needed to make the smart grid work are built on buggy software that's easily hacked.
Mike Davis, a senior security consultant for IOActive has identified several issues
with the smart meter software. These issues are critical to the security of the smart grid
11
with the vast majority of them use no encryption and ask for no authentication before
carrying out sensitive functions. There is no validation or authentication when
performing software updates or severing customers from the power grid. Mike Davis
has said the vulnerabilities are ripe for abuse. The smart meters have the capability to
switch on/off hundreds of thousands of homes at the nearly the same time. This can
introduce problems with the power company being able to gracefully deal with power
demands or surges. The vulnerability in the devices [13] is susceptible to a worm
designed by Mike Davis and the IOActive colleagues to show authoritative agencies
the reality of the problem. The worm self-propagates across a large number of one
manufacturer's smart meter. Once the device becomes infected, the device is under the
control of the malware developers similarly to the way infected PCs are under the
spell of bot herders. It is at this point that the attackers can “own” the devices and send
instructions to turn power on or off and divulge power usage statistics or sensitive
system configuration settings. The worm is able to spread quickly and exploits an
automatic update feature in the meter that runs on peer-to-peer technology. The peerto-peer technology doesn't use code signing or any other measure to ensure the update
is authorized, but instead uses a routine known as interrupt hooking, which adds
additional code to the device's operating system. There has been no public disclosure
of verified models of smart meters that are designed with these vulnerabilities.
Researchers and engineers decline to identify the models or the manufacturers but will
only elaborate to state that most of the models suffer from the same poor design.
Companies manufacturing the smart meter devices for smart grids include GE Energy,
12
The ABB Group, Sensus Metering, Itron and Landis+Gyr. The embedded platforms
are not designed for security. One deficiency that has been identified as common
among many of the meters is the use of well-known insecure programming functions,
such as memcpy() and strcpy(). These are two of the most common sources of
exploitable software bugs. In many cases, the devices use general purpose hardware
and software that aren't designed for highly targeted or mission critical systems. This
is the nightmare of the smart grid security initiative. Envision a malicious hacker that
has the unique identifier that's printed on your meter.
A security company named ControlScan maintains a database listing vulnerabilities
found in the more common problems found in the Internet infrastructure. The database
lists 34,762 total vulnerabilities that have been identified by ControlScan [14]. This
list cannot reflect all the problems in ICS/Internet infrastructure.
Additional vulnerability problems and the potential impact listed in a Vulnerability
Classes website [3] attempts to list many that may not be as obvious as those listed in
the ControlScan database.
By 2015, utilities in more than two-dozen US states expect to have almost 52 million
customers outfitted with the bidirectional smart meters, according to the Edison
Electric Institute, which represents power companies. Some of those deployments are
already completed and many more will be completed in the next few years. Due
consideration must be given to all the issues of ICS/Internet integration. Attention is
now focused to the Tenable Nessus Vulnerability and Compliance scanner solution.
13
Chapter 3 Nessus Scanning
Information on numerous common vulnerabilities has been presented. These are the
well known common problems but some may not be so obvious to newly trained
ICS/Internet personnel. The problems introduced into the AMI/AMR systems from
Internet and networking vulnerabilities pose a daunting task of identifying and
securing the infrastructure. Many problems are readily apparent and there are those
that are not so easily identified. It would be impossible to manually identify and
mitigate the issues. Nessus has provided a tool to assist in identifying problems in
AMI/AMR technology. Nessus is an active scanner featuring high speed discovery,
configuration auditing, asset profiling, sensitive data discovery and vulnerability
analysis. It is a popular vulnerability scanner that offers many features to help assess
the security of control system networks, devices, servers and workstations. Basic
vulnerability scanning has crashed many control system devices and applications but
new features and techniques make it possible to scan control system networks with
minimal impact to critical systems such as SCADA. This “safe” feature makes
Nessus an ideal candidate for use with SCADA systems.
Tenable Nessus and Digital Bond have formed a collaboration to extend the scanner.
Nessus is part of the following Digital Bond Racks:

Control System Security Assessment Rack

Application Security Assessment Rack

Web Application Security Assessment Rack
14
3.1
Bandolier Related Work
Digital Bond is currently involved in a research project known as Bandolier [17]. It
documents the optimal security configurations for control system application
components. Programs are written into audit files that can be used in security tools
such as Nessus. Policy compliance checks allow asset owners to verification that the
system is in the optimal security configuration for both operating systems and
application security settings. Bandolier audit files are used at initial deployment to
determine baseline configuration and compliance with NIST standards. Bandolier is
funded by the Department of Energy (DOE) and is Objective 1 of a larger effort
known as the Cyber Security Audit and Attack Detection Toolkit.
3.2
Compliance Checks
Using guidance from NIST and other industry organizations, Tenable Network
Security has developed best practice compliance checks for many operating systems
and common Internet applications such as databases and web servers. The Bandolier
project is developing files specifically for control system applications that reside on a
variety of Windows, Linux, and Unix platforms. The Bandolier audit files can be used
with Nessus compliance plug-ins to perform security scans and to compare a
deployed control system component to the best practice security settings and then
identify any variances. The Nessus compliance plug-ins are available to Nessus
ProfessionalFeed customers at a cost of $1200 a year with access to new plug-ins,
customer support, and access to the SCADA plug-ins that Digital Bond [6] developed
for Tenable. Compliance plug-ins provides the Nessus Vulnerability Scanner with the
15
ability to audit a system against a secure configuration as described in the policy
compliance file. Bandolier created files can be used with the Nessus Vulnerability
Scanner to audit security configurations of the twenty-plus control systems
applications that are part of the project. Although Nessus is the de-facto standard for
vulnerability scanning, there are other tools available that can perform similar
functions. Digital Bond will also make the compliance checks available in the
XCCDF and OVAL formats used by NIST's Security Content Automation Protocol
(SCAP). To provide maximum benefit and reusability for the community, all SCAP
validated scanners will be able to use the Bandolier audit files.
3.3
Compliance Checks versus
Vulnerability Scans
An important difference exists between compliance checks and traditional
vulnerability scanning in Nessus. Each has its own distinct purpose and value; i.e.,
vulnerability scanning relies on signatures of “known bad things”. The scanning tests
typically send packets to the device under scan that have caused many control system
applications to crash or operate improperly. On the other hand, compliance checks
compare a system against the “known good”, hardened configuration. This process is
facilitated by creating an authenticated administrator connection to the system and
inspecting its configuration.
Different methods are used to determine what services are running on a
workstation or server. Vulnerability scans send a packet to each TCP and UDP port
16
to evaluate the response to determine if the port was open. Unfortunately, simple port
scanning has caused numerous poorly written control system applications to fail. On
the other hand, compliance checks connect to the workstations or servers as an
authenticated administrator to get a list of the services running and return this
information via the administrative connection. It should be noted that an application
that would crash on a port scan would not crash when the same information was
collected by a compliance check.
Compliance checks can read and evaluate files which makes the number and types of
checks available almost limitless to provide the capability of checking many built-in
settings at the operating system level. The following examples do not represent the
full array of checks that are available but are meant to only highlight the capability of
the checks. Note that the examples start with basic service evaluation to very specific
application configuration inspection.
3.4
Development Approach
Step 1: Select the control system applications for project participation.
The development of a methodology to enhance the Nessus Scanning solution is
flexible that enhanced scans can target conventional network systems and ICS control
servers and computers. In this context, control system refers to any server or
workstation whether it is connected to ICS or conventional LANs or WANs. The
focus is to develop a systematic methodology that can be used in currently
implemented systems and future implementations. The following are factors that
17
make a control system application more applicable for a systematic enhanced
scanning methodology to detect and discover vulnerabilities:

Select a control system application running on a relatively current operating
system. Exclude systems running Windows 98 or NT.

Select a control system application or component that can be secured.
Applications that cannot be patched or configured in a highly vulnerable
manner will be of little use. The audit can and will only verify it is an insecure
state.

Select a control system application that is widely deployed. Human Machine
Interfaces (HMI) or operator consoles are ideal candidates because this will
allow a quick and consistent audit of many HMI workstations. Similarly, if the
same Distributed Control System (DCS) is being used at many power plants
the systems than that DCS would be an ideal choice.

Select a critical control system application. A critical control server is a good
candidate for a compliance policy file even if there is only a primary and
backup server. The compliance policy file will identify any changes to the
secure configuration.

Similar control system application components with different configurations
can have their own compliancy policy. Permissions on different systems could
be quite different even though an HMI might run the exact same software as
an engineering workstation.

Inspect logs, research security bulletins, investigate network anomalies for
potential problems that may possible cause disruptions or outages. This step is
18
needed to assess the proper operation of the target system. Several different
processes are performed.
Step 2: Develop secure, hardened configurations for each control system
application component
This step is extremely important. The goal is to create a standard configuration for
each control system application component for each of the components, e.g. HMI,
Historian, Realtime Server, and OPC Server. Deployed control system application
components will be measured against the standard, Scan with existing plug-ins and
patch any discovered vulnerability. The ideal scenario is for the system administrator,
SCADA administrator or DCS vendor to assist in this step. Digital Bond's research
team, system administrators, the vendor and asset owner users would work together to
define the “gold” standard for Bandolier. Consensus guidelines have been used as a
starting point for operating system and common Internet applications, such as web
servers, database applications, and security configuration settings. Modifications are
made as needed for the control system application to function properly, and then the
control system application specific ideal security settings are defined.
Step 3: Perform a baseline scan
After the “gold” standard is defined, perform a baseline scan. Any vulnerability
discovered or non-compliance should be corrected and the scan run again till all
problems are resolved with the direct fee plug-ins supplied by Nessus. After all
problems have been resolved, the scan should be assigned as the original “gold”
standard.
19
Step 4: Develop Plug-ins for Newly Discovered Issues and Checks for
Compliance
Not all Bandolier audit templates are developed to measure the same level of security.
A particular HMI’s gold standard may be much more secure than another HMI’s gold
standard because the vendor may have leveraged operating system security features
and build security features into one and not the other. Bandolier templates attempt to
identify the best possible security setting for each individual control system
application component.
As of May 1, 2010, Tenable Nessus 35.414 plug-ins performs a high level of
comprehensive checks. Nessus is not a tool that can “cover all the bases” but is a tool
designed to “cover” a large portion of problems that are nearly impossible to discover
manually. With this in mind, there are problems that may be unique to the
organization and a need for customized plug-in to enhance the scanning tool to
discover vulnerabilities and check for compliance.
Customized plug-ins created to enhance the scanning capability to address any issue
is a critical step that must be done correctly. The plug-ins can be written to output a
specific message for vulnerability discovery or indicate compliance. Any
vulnerability or compliance check file must be written to comply with the Nessus
general guidelines. See step 4.1 for Nessus plug-in guidelines.
Step 4.1 Methodology to Create Nessus plug-in
Nessus plug-ins are created according to the guidelines in the Nessus Attack Scripting
Language (NASL) [5]. The guidelines are used for the scanner to make use of full
20
functionality and to ensure the enhanced plug-in behaves properly, especially on
critical computers connected to critical systems. There are three guidelines to follow.
•
execute only if necessary
•
use other script results by use of dependencies
•
share by saving to KB, upload report results and
plug-ins
By following this methodology, the Nessus community reaps many benefits.
Discussion forums, support, knowledge base, documentation and users all benefit
from the collaboration.
Step 5: Test New Plug-ins Before Releasing to Production Environment
Skip this step if no new enhanced plug-ins have been developed. Otherwise, the
system administrator will gather information on the system and will create the
vulnerability and compliance policy files on the secured and hardened configuration.
Each test task on each system should be thoroughly tested. Ideally, the plug-ins
should be tested in a similar lab environment or test equipment. A prototype with
virtual machines can be used as a test bed to determine plug-ins are behaving and not
causing problems to the environment. Badly written plug-ins can cause serious
problems.
Step 6: Perform “Post-Gold” Scan
Perform another scan to discover any vulnerabilities and checks for compliance. This
scan should indicate full compliance with the “gold” standard previously defined in
step 2. Any failures indicated in the scan report will need to be resolved and repeat
and begin step 3 and scan till all issues are resolved. At this point in time, the target
system “gold” scan and “post-gold scan can be compared in the Nessus scanner by
21
selecting the option within the Report GUI interface. The “post-gold” scan should be
run at prescribed intervals to discover if any unauthorized changes have occurred
since the last :gold: baseline scan. The ‘gold” standard documentation and processes
may need modification at this step if new plug-ins are written or other standards have
been updated with new configuration. Repeat the development approach for other
target systems that are participating in the project.
3.5
Extending Bandolier with Nessus
Credentialed Scanning
The Bandolier security audit files provide a view of the internal security
configuration. Some desirable audit results are not available directly from the audit
files or compliance checks. Nessus Credentialed Scanning options are a safe, reliable
method to assess control system servers and workstations. Plug-ins are available to
audit missing patches at both the operating system and application levels, including
some often-overlooked client applications. Enhanced plug-ins are created to target
specific vulnerabilities or compliance checks,
Other authenticated scanning options include the "netstat" port scanner that is a safe
way to enumerate open ports without a traditional port scan that has been known to
crash some control system applications. This is an extremely important fact since the
control system of a Smart Grid cannot crash under any circumstance, especially an
administrator invoked scanning task Unix systems use the command netstat -an to
return the results. Windows systems use WMI to return the same information.
22
Nessus offers additional information when credentials are provided to authenticate
to the remote host. The credential checks are useful when used in conjunction with a
full vulnerability scan and is a safer scanning option to use with fragile control system
hosts.
The Nessus scan policy provides user credentials input to connect to a remote server
or workstation. Nessus is allowed to authenticate to a remote host to use the built-in
operating system functionality to run tests that have been defined by the user in the
scan policy. Selected configuration screenshots are included below.
The Nessus scanner uses Server Message Block (SMB) for Windows hosts that
require the ability to communicate with the remote host on TCP port 445. The defined
user account in the scan policy requires administrator privileges.
The Nessus scanner relies on Secure Shell (SSH) TCP port 22 for Unix and Linux
hosts. Root access is facilitated through either the root account or an account capable
of using su or sudo.
3.6
Nessus Quick Reference Installation and
Upgrade Guide
Nessus Installation Guide
This guide provides commands as a general guideline to install and upgrade Nessus
on supported OS platforms. Detailed information, manuals, documentation,
knowledgebase and support is available at http://www.nessus.org/nessus/ website.
23
3.6.1 Nessus Background
Nessus is a powerful, up-to-date and easy to use network security scanner endorsed
by professional information security organizations such as the SANS Institute. Nessus
provides the ability to perform remote and local audits on a specific target machines
for vulnerabilities, compliance specifications, content policy violations and more. A
given network can be scanned remotely or locally to determine if it has been broken
into or misused in some way. Nessus provides:
•
Intelligent Scanning – attempt to validate vulnerability through exploitation
when possible
•
Modular Architecture – The client/server architecture provides flexibility
•
CVE Compatible –links to CVE for administrators to retrieve further
information, references to Bugtraq (BID), OSVDB and vendor security alerts
•
Plugin Architecture – easily add your own tests, select specific plugins or
choose an entire family. Nessus nessusd plugins are available at
http://www.nessus.org/plugins/index.php?view=all.
•
NASL – The Nessus scanner includes NASL (Nessus Attack Scripting
Language). Security checks can also be written in the C programming language.
•
Up-to-date Security Vulnerability Database – focus on development of security
checks for newly disclosed vulnerabilities is updated daily.
•
Tests Multiple Hosts Simultaneously – ability to test a large number of hosts
concurrently. Smart Service Recognition – Nessus will recognize a FTP server
running on a non-standard port (e.g., 31337) or a web server running on port
8080 instead of 80.
24
•
Tests Multiple Hosts Simultaneously – ability to test a large number of hosts
concurrently. Smart Service Recognition – Nessus will recognize a FTP server
running on a non-standard port (e.g., 31337) or a web server running on port
8080 instead of 80.
•
Multiple Services – Nessus will identify and test all web servers running on a
host (e.g., one on port 80 and another on port 8080), of them.
•
Plugin Cooperation – unnecessary checks are not performed
•
Complete Reports – report what security vulnerabilities exist on your network,
the risk level and how to mitigate by offering solutions.
•
Full SSL Support –ability to test services offered over SSL
•
Smart Plugins (optional) –determines which plugins should or should not be
launched against the remote host. This option is called “optimization”.
•
Non-Destructive (optional) –enable the “safe checks” option of Nessus, which
will make Nessus rely on banners rather than exploiting real flaws to determine
if a vulnerability is present.
•
Open Forum –https://discussions.nessus.org/.
3.6.2 OS Support
Nessus is available and supported for a variety of operating systems and platforms:
 Red Hat ES 4 (i386), and ES 5 (i386 and x86-64)
 Fedora Core 10 (i386 and x86-64) [Compatible with Fedora 9]
 Fedora Core 11 (i586 and x86-64)
 Fedora Core 12 (i586 and x86-64)
25
 Debian 5 (i386 and x86-64)
 FreeBSD 7 (i386 and x86-64)
 Ubuntu 8.04 (i386 and x86-64)
 Ubuntu 8.10 (i386 and x86-64)
 Ubuntu 9.10 (i386 and x86-64)
 Mac OS X 10.4 / 10.5 (i386, x86-64, ppc)
 Windows XP, Server 2003, Server 2008, Vista and Windows 7
(i386 and x86-64)
 SuSE 9.3 (i386)
 SuSE 10.0 (i386 and x86-64)
 Solaris 10
3.6.3 Prerequisites
 Minimum of 1 GB RAM
 2-4GB RAM for larger scans of multiple networks
 Pentium 3 processor running at 2 GHz or higher
 Mac OS X dual-core Intel® processor running at 2 GHz or higher
 Nessus can be run under a VMware instance, enumeration and operating
system identification will be negatively affected if Network Address
Translation (NAT) is used
 Nessus Unix requires several libraries that typically do not require separate
installation. It should be noted the following are required:
o OpenSSL (e.g., openssl, libssl, libcrypto)
26
o zlib
o GNU C Library (i.e., libc)
 Nessus Windows performance can be affected by changes to Microsoft
Windows XP SP-2 and should be installed on a server product from the
Windows Server 2003 family or higher for increased performance and scan
reliability
3.6.4 Installation
It may take several minutes the first time Nessus updates and processes the plug-ins.
The web client connection will not be available until plugin processing ha completed.
Download the latest version of Nessus from http://www.nessus.org/download/. All
commands must be performed with system root privileged user. The following
sections provide installation instructions for the Nessus server on all supported
platforms. Special installation instructions are noted following the example. Platform
Installation Instructions follow:
3.6.4.1 Red Hat ES 4 (32 bit), ES 5 (32 and 64 bit)
3.6.4.1.1 Install Command
Use one of the appropriate commands below that corresponds to the
version of Red Hat:
# rpm -ivh Nessus-4.x.x-es4.i386.rpm
# rpm -ivh Nessus-4.x.x-es5.i386.rpm
# rpm -ivh Nessus-4.x.x-es5.x86_64.rpm
3.6.4.1.2 Sample Output
27
# rpm -ivh Nessus-4.2.0-es4.i386.rpm
Preparing...
########################################### [100%]
1:Nessus
########################################### [100%]
nessusd (Nessus) 4.2.0. for Linux
-Please run /opt/nessus//sbin/nessus-adduser to add a user
-Register your Nessus scanner at
http://www.nessus.org/register/ to obtain all the newest plugins
- You can start nessusd by typing
/sbin/service nessusd start
#
3.6.4.2 Fedora Core 10 (32 and 64 bit), 11 (32 and 64 bit) and 12 (32
and 64 bit)
3.6.4.2.1 Install Command
Use one of the appropriate commands below that corresponds to the
version of Fedora Core:
# rpm -ivh Nessus-4.x.x-fc10.i386.rpm
# rpm -ivh Nessus-4.x.x-fc10.x86_64.rpm
# rpm -ivh Nessus-4.x.x-fc11.i386.rpm
# rpm -ivh Nessus-4.x.x-fc11.x86_64.rpm
# rpm -ivh Nessus-4.x.x-fc12.i386.rpm
# rpm -ivh Nessus-4.x.x-fc12.x86_64.rpm
28
3.6.4.2.2 Sample Output
# rpm -ivh Nessus-4.2.0-fc10.i386.rpm
Preparing...
###########################################
[100%]
1:Nessus
###########################################
[100%]
nessusd (Nessus) 4.2.0. for Linux
-Please run /opt/nessus//sbin/nessus-adduser to add a user
-Register your Nessus scanner at
http://www.nessus.org/register/ to obtain all the newest plugins
You can start nessusd by typing
/sbin/service nessusd start
#
3.6.4.3 SuSE 9.3, 10
3.6.4.3.1 Install Command
Use one of the appropriate commands below that corresponds to the
version of SuSE:
# rpm -ivh Nessus-4.x.x-suse9.3.i586.rpm
# rpm -ivh Nessus-4.x.x-suse10.0.i586.rpm
3.6.4.3.2 Sample Output
# rpm -ivh Nessus-4.2.0-suse10.0.i586.rpm
29
Preparing... ################################## [100%]
1:Nessus ##################################
[100%]
Nessusd {Nessus} 4.2.0. for Linux
-Please run /opt/nessus//sbin/nessus-adduser to add a user
- Register your Nessus scanner at
http://www.nessus.org/register/ to obtainall the newest plugins
- You can start nessusd by typing
/etc/rc.d/nessusd start
#
3.6.4.4 Debian 5 (32 and 64 bit)
3.6.4.4.1 Install Command
Use one of the appropriate commands below that corresponds to the
version of Debian:
# dpkg -i Nessus-4.x.x -debian5_i386.deb
# dpkg -i Nessus-4.x.x -debian5_amd64.deb
3.6.4.4.2 Sample Output
# dpkg -i Nessus-4.2.0-debian5_i386.deb
Selecting previously deselected package nessus.
(Reading database ... 36954 files and directories
currently installed.)
Unpacking nessus (from Nessus-4.2.0-debian5_i386.deb) ...
Setting up nessus (4.2.0) ...
30
nessusd (Nessus) 4.2.0. for Linux
- Please run /opt/nessus/sbin/nessus-adduser to add a
user
- Register your Nessus scanner at
http://www.nessus.org/register/ to obtain all the newest plugins
- You can start nessusd by typing
/etc/init.d/nessusd start
#
Note: Nessus comes with an empty plugin set by default. The Nessus
daemon cannot be started until Nessus has been registered and a
plugin download has occurred. If you attempt to start Nessus without
plugins, the following output is returned:
# /etc/init.d/nessusd start
Starting Nessus : .
# Missing plugins. Attempting a plugin update...
Your installation is missing plugins. Please register and
try again.
To register, please visit http://www.nessus.org/register/
3.6.4.5 Ubuntu 8.04, 8.10 and 9.10 (32 and 64 bit)
3.6.4.5.1 Install Command
Use one of the appropriate commands below that corresponds to the
version of Ubuntu:
# dpkg -i Nessus-4.x.x-ubuntu804_i386.deb
31
# dpkg -i Nessus-4.x.x-ubuntu804_amd64.deb
# dpkg -i Nessus-4.x.x-ubuntu810_i386.deb
# dpkg -i Nessus-4.x.x-ubuntu810_amd64.deb
# dpkg -i Nessus-4.x.x-ubuntu910_i386.deb
# dpkg -i Nessus-4.x.x-ubuntu910_amd64.deb
3.6.4.5.2 Sample Output
# dpkg -i Nessus-4.2.0-ubuntu804_amd64.deb
Selecting previously deselected package nessus.
(Reading database ... 32444 files and directories
currently installed.)
Unpacking nessus (from Nessus-4.2.0-ubuntu804_amd64.deb)
...
Setting up nessus (4.2.0) ...
- Please run
/opt/nessus/sbin/nessus-adduser
to add a user
- Register your Nessus scanner at
http://www.nessus.org/register/ to obtain
all the newest plugins
- You can start nessusd by typing
/etc/init.d/nessusd start
#
3.6.4.6 Solaris 10
32
3.6.4.6.1 Install Command
# gunzip Nessus-4.x.x-solaris-sparc.pkg.gz
# pkgadd -d ./Nessus-4.x.x-solaris-sparc.pkg
The following packages are available:
1 TNBLnessus The Nessus Network Vulnerability
Scanner
(sparc) 4.2.1
Select package(s) you wish to process (or 'all' to process
3.6.4.6.2 Sample Output
# gunzip Nessus-4.2.1-solaris-sparc.pkg.gz
# pkgadd -d ./Nessus-4.2.1-solaris-sparc.pkg
The following packages are available:
1 TNBLnessus The Nessus Network Vulnerability
Scanner
(sparc) 4.2.1
Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:1
Processing package instance <TNBLnessus> from
</tmp/Nessus-4.2.1-solaris-sparc.pkg>
The Nessus Network Vulnerability Scanner(sparc) 4.2.1
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
33
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.
This package contains scripts which will be executed with
super-user permission during the process of installing this package.
Do you want to continue with the installation of
<TNBLnessus> [y,n,?]
Installing The Nessus Network Vulnerability Scanner as
<TNBLnessus>
## Installing part 1 of 1.
(output redacted)
## Executing postinstall script.
- Please run
/opt/nessus/sbin/nessus-adduser
to add a user
- Register your Nessus scanner at
http://www.nessus.org/register/
to obtain all the newest plugins
- You can start nessusd by typing
/etc/init.d/nessusd start
Installation of <TNBLnessus> was successful.
# /etc/init.d/nessusd start
#
34
Note: Ensure the latest Solaris Recommended Patch Cluster from Sun
is installed to eliminate any library compatibility errors.
3.6.4.7 FreeBSD 7 (32 and 64 bit)
3.6.4.7.1 Install Command
Use one of the appropriate commands below that corresponds to the
version of FreeBSD:
# pkg_add Nessus-4.2.0-fbsd7.tbz
# pkg_add Nessus-4.2.0-fbsd7.amd64.tbz
3.6.4.7.2 Sample Output
# pkg_add Nessus-4.2.0-fbsd7.tbz
nessusd (Nessus) 4.2.0 for FreeBSD
Processing the Nessus plugins...
[##################################################]
All plugins loaded
- Please run
/usr/local/nessus/sbin/nessus-adduser
to add an admin user
- Register your Nessus scanner at
http://www.nessus.org/register/ to obtain
all the newest plugins
- You can start nessusd by typing
/usr/local/etc/rc.d/nessusd.sh start
#
35
Note: Nessus recommends customization of the provided
configuration file for your environment as described in Appendix B.
3.6.4.8 Windows
3.6.4.8.1 Download Nessus
Nessus 4.2 is available for Windows XP, Server 2003, Server 2008,
Vista and Windows 7. The latest version of Nessus is available at
http://www.nessus.org/download/. Distribution file sizes and names
vary slightly and are approximately 12 MB in size. Select the
appropriate file and save to a temporary file location. Double click the
file to begin the installation process.
Figure 3.1 Windows Nessus Download Files
3.6.4.8.2 Installation
Install Nessus using an administrative account. Any errors related to
permissions, “Access Denied” or errors suggesting an action occurred
due to lack of privileges indicate an account with a lack of
administrative privileges. Use of the command line run cmd.exe utility
36
with “Run as…” can resolve required privilege errors. The default
settings can be used for most installations. See Figure 3.1 through 3.7
for the Windows installation process.
Figure 3.2 Windows Nessus Welcome Screen
37
Figure 3.3 Windows Nessus License Agreement
Figure 3.4 Windows Nessus Destination Folder
38
Figure 3.5 Windows Nessus Setup Type
Figure 3.6 Windows Nessus Install Dialog
39
Figure 3.7 Windows Nessus Completion Dialog
3.7
Upgrading Unix/Linux
This section explains how to upgrade Nessus from a previous Nessus installation.
The following table provides upgrade instructions for the Nessus server on all
previously supported platforms. Previously created configuration settings and users
will remain intact. Special upgrade instructions are provided in a note following the
example. Platform upgrade instructions follow:
3.7.1 Red Hat ES 4 (32 bit), ES 5 (32 and 64 bit)
3.7.1.1 Upgrade Commands
# service nessusd stop
40
Use the appropriate command below that corresponds to
the version of Red Hat:
# rpm -Uvh Nessus-4.x.x-es4.i386.rpm
# rpm -Uvh Nessus-4.x.x-es5.i386.rpm
# rpm -Uvh Nessus-4.x.x-es5.x86_64.rpm
restart the nessusd service
# service nessusd start
3.7.1.2 Sample Output
# service nessusd stop
Shutting down Nessus services: [ OK ]
# rpm -Uvh Nessus-4.2.0-es4.i386.rpm
Preparing...
########################################### [100%]
Shutting down Nessus services:
1:Nessus
########################################### [100%]
nessusd (Nessus) 4.2.0 for Linux
Processing the Nessus plugins...
[##################################################]
All plugins loaded
- Please run
/opt/nessus/sbin/nessus-adduser
to add an admin user
41
- Register your Nessus scanner at
http://www.nessus.org/register/ to
obtain all the newest plugins
- You can start nessusd by typing
/sbin/service nessusd start
# service nessusd start
Starting Nessus services: [ OK ]
#
3.7.2 Fedora Core 10 (32 and 64 bit), 11 (32 and 64 bit)
and 12 (32 and 64 bit)
3.7.2.1 Upgrade Commands
# service nessusd stop
Use the appropriate command below that corresponds to
the version of Fedora Core:
# rpm -Uvh Nessus-4.x.x-fc10.i386.rpm
# rpm -Uvh Nessus-4.x.x-fc10.x86_64.rpm
# rpm -Uvh Nessus-4.x.x-fc11.i386.rpm
# rpm -Uvh Nessus-4.x.x-fc11.x86_64.rpm
# rpm -Uvh Nessus-4.x.x-fc12.i386.rpm
# rpm -Uvh Nessus-4.x.x-fc12.x86_64.rpm
Restart the nessusd service with the following command when
the upgrade is complete:
# service nessusd start
42
#
3.7.2.2 Sample Output
# service nessusd stop
Shutting down Nessus services: [ OK ]
# rpm -Uvh Nessus-4.2.0-fc10.i386.rpm
Preparing...
########################################### [100%]
Shutting down Nessus services:
1:Nessus
########################################### [100%]
nessusd (Nessus) 4.2.0 for Linux
Processing the Nessus plugins...
[##################################################]
All plugins loaded
- Please run
/opt/nessus/sbin/nessus-adduser
to add an admin user
- Register your Nessus scanner at
http://www.nessus.org/register/
to obtain all the newest plugins
- You can start nessusd by typing
/sbin/service nessusd start
# service nessusd start
43
Starting Nessus services: [ OK ]
#
3.7.3 SuSE 9.3, 10
3.7.3.1 Upgrade Commands
# service nessusd stop
Use the appropriate commands below that corresponds to
the version of SuSE:
# rpm -Uvh Nessus-4.x.x-suse9.3.i586.rpm
# rpm -Uvh Nessus-4.x.x-suse10.0.i586.rpm
Restart the nessusd service with the following command the
upgrade is complete:
# service nessusd start
3.7.3.2 Sample Output
# service nessusd stop
Shutting down Nessus services: [ OK ]
# rpm -Uvh Nessus-4.2.0-suse10.0.i586.rpm
Preparing...
########################################### [100%]
Shutting down Nessus services:
1:Nessus
########################################### [100%]
nessusd (Nessus) 4.2.0 for Linux
Processing the Nessus plugins...
44
[##################################################]
All plugins loaded
- Please run
/opt/nessus/sbin/nessus-adduser
to add an admin user
- Register your Nessus scanner at
http://www.nessus.org/register/
to obtain all the newest plugins
- You can start nessusd by typing
/sbin/service nessusd start
# service nessusd start
Starting Nessus services: [ OK ]
#
3.7.4 Debian 5 (32 and 64 bit)
3.7.4.1 Upgrade Commands
# /etc/init.d/nessusd stop
Use the appropriate commands below that corresponds to
the version of Debian:
# dpkg -i Nessus-4.x.x-debian5_i386.deb
# dpkg -i Nessus-4.x.x-debian5_amd64.deb
# /etc/init.d/nessusd start
3.7.4.2 Sample Output
# /etc/init.d/nessusd stop
45
# dpkg -i Nessus-4.2.0-debian5_i386.deb
(Reading database ... 19831 files and directories
currently installed.)
Preparing to replace nessus 4.2.0 (using Nessus-4.2.0debian5_i386.deb) ...
Shutting down Nessus : .
Unpacking replacement nessus ...
Setting up nessus (4.2.0) ...
nessusd (Nessus) 4.2.0. for Linux
Processing the Nessus plugins...
[##################################################]
All plugins loaded
- Please run
/opt/nessus/sbin/nessus-adduser
to add an admin user
- Register your Nessus scanner at
http://www.nessus.org/register/ to
obtain all the newest plugins
- You can start nessusd by typing
/etc/init.d/nessusd start
# /etc/init.d/nessusd start
Starting Nessus : .
#
46
3.7.5 Ubuntu 8.04, 8.10 and 9.10 (32 and 64 bit)
3.7.5.1 Upgrade Commands
# /etc/init.d/nessusd stop
Use the appropriate commands below that corresponds to
the version of Ubuntu:
# dpkg -i Nessus-4.x.x-ubuntu804_i386.deb
# dpkg -i Nessus-4.x.x-ubuntu804_amd64.deb
# dpkg -i Nessus-4.x.x-ubuntu810_i386.deb
# dpkg -i Nessus-4.x.x-ubuntu810_amd64.deb
# dpkg -i Nessus-4.x.x-ubuntu910_i386.deb
# dpkg -i Nessus-4.x.x-ubuntu910_amd64.deb
# /etc/init.d/nessusd start
3.7.5.2 Sample Output
# /etc/init.d/nessusd stop
# dpkg -i Nessus-4.2.0-ubuntu810_i386.deb
(Reading database ... 19831 files and directories
currently installed.)
Preparing to replace nessus 4.2.0 (using Nessus-4.2.0ubuntu810_i386.deb) ...
Shutting down Nessus : .
Unpacking replacement nessus ...
Setting up nessus (4.2.0) ...
47
nessusd (Nessus) 4.2.0. for Linux
Processing the Nessus plugins...
[##################################################]
All plugins loaded
- Please run
/opt/nessus/sbin/nessus-adduser
to add an admin user
- Register your Nessus scanner at
http://www.nessus.org/register/ to
obtain all the newest plugins
- You can start nessusd by typing
/etc/init.d/nessusd start
# /etc/init.d/nessusd start
Starting Nessus : .
#
3.7.6 Solaris 10
3.7.6.1 Upgrade Commands
# /etc/init.d/nessusd stop
# pkginfo | grep nessus
The following is example output for the previous command
showing the Nessus package:
application TNBLnessus The Nessus Network
Vulnerability Scanner
48
To remove the Nessus package on a Solaris system, run the
following command:
# pkgrm <package name>
# gunzip Nessus-4.x.x-solaris-sparc.pkg.gz
# pkgadd -d ./Nessus-4.2.0-solaris-sparc.pkg
The following packages are available:
1 TNBLnessus-4-2-0 TNBLnessus
(sparc) 4.2.0
Select package(s) you wish to process (or 'all' to
process
all packages). (default: all) [?,??,q]: 1
# /etc/init.d/nessusd start
3.7.6.2 Sample Output
# /etc/init.d/nessusd stop
# pkginfo | grep nessus
application TNBLnessus The Nessus Network
Vulnerability Scanner
# pkgrm TNBLnessus
(output redacted)
## Updating system information.
Removal of <TNBLnessus> was successful.
# gunzip Nessus-4.2.1-solaris-sparc.pkg.gz
# pkgadd -d ./Nessus-4.2.1-solaris-sparc.pkg
49
The following packages are available:
1 TNBLnessus The Nessus Network Vulnerability
Scanner
(sparc) 4.2.1
Select package(s) you wish to process (or 'all' to
process
all packages). (default: all) [?,??,q]: 1
Processing package instance <TNBLnessus> from
</export/home/cbf/TENABLE/Nessus-4.2.1-solarissparc
pkg>
The Nessus Network Vulnerability Scanner
(sparc) 4.2.1
## Processing package information.
## Processing system information.
13 package pathnames are already properly installed.
## Verifying disk space requirements.
## Checking for conflicts with packages already
installed.
## Checking for setuid/setgid programs.
This package contains scripts which will be executed
with super-user
permission during the process of installing this
package.
50
Do you want to continue with the installation of
<TNBLnessus> [y,n,?]
Installing The Nessus Network Vulnerability Scanner as
<TNBLnessus>
## Installing part 1 of 1.
(output redacted)
## Executing postinstall script.
- Please run
/opt/nessus/sbin/nessus-adduser
to add a user
- Register your Nessus scanner at
http://www.nessus.org/register/ to obtain
all the newest plugins
- You can start nessusd by typing
/etc/init.d/nessusd start
Installation of <TNBLnessus> was successful.
# /etc/init.d/nessusd start
#
Note: Uninstall the existing version and then install the newest
release to upgrade Nessus on Solaris. This process does not
remove configuration files or files that were not part of the original
installation. Ensure the latest Solaris Recommended Patch Cluster
from Sun encounter library to avoid compatibility errors.
51
3.7.7 FreeBSD 7 (32 and 64 bit)
3.7.7.1 Upgrade Commands
# killall nessusd # pkg_info
This command lists all the packages installed and
their descriptions. The following is example output for the
previous command showing the Nessus package:
Nessus-4.0.2 A powerful security scanner
Remove the Nessus package using the following command:
# pkg_delete <package name>
Use one of the appropriate commands below that corresponds to
the version of FreeBSD:
# pkg_add Nessus-4.2.0-fbsd7.tbz
# pkg_add Nessus-4.2.0-fbsd7.amd64.tbz
# /usr/local/nessus/sbin/nessusd -D
3.7.7.2 Sample Output
# killall nessusd
# pkg_delete Nessus-4.0.2
# pkg_add Nessus-4.2.0-fbsd7.tbz
nessusd (Nessus) 4.2.0. for FreeBSD
Processing the Nessus plugins...
[##################################################]
All plugins loaded
52
- Please run
/usr/local/nessus/sbin/nessus-adduser
To add an admin user
- Register your Nessus scanner at
http://www.nessus.org/register/ to
obtain all the newest plugins
- You can start nessusd by typing
/usr/local/etc/rc.d/nessusd.sh start
# /usr/local/nessus/sbin/nessusd -D
nessusd (Nessus) 4.2.0. for FreeBSD
Processing the Nessus plugins...
[##################################################]
All plugins loaded
#
Note: Uninstall the existing version and then install the newest
release to upgrade Nessus on FreeBSD. This process does not
remove configuration files or files that were not part of the original
installation.
3.8 Upgrading Windows
3.8.1 Upgrade Nessus 4.0 to 4.0.x
This upgrade process will ask if the user wants to delete everything in the
Nessus directory. If you choose “Yes” for this option, an uninstall process
53
will remove previously created users, existing scan policies, scan results and
the scanner will become unregistered.
3.8.2 Upgrade from Nessus 3.0 to 3.0.x
Direct upgrades from Nessus 3.0.x to Nessus 4.x are not supported. An
upgrade to version 3.2 can be used as an interim step to ensure that vital scan
settings and policies are preserved.
If scan settings do not need to be kept, uninstall Nessus 3.x first and then
install a fresh copy of Nessus 4. Consult the Nessus 3.2 Installation Guide for
more information to upgrade to 3.2 as an interim step. The guide can be found
ath
the
Tenable
website
at
http://www.tenablesecurity.com/documentation/nessus_3.2_installation_guide
.pdf
3.8.3 Upgrading from Nessus 3.2 and later
Upgrades from Nessus 3.2 or later are supported. Download the Nessus 4
package and install it without uninstalling the existing version to preserve all
previous vulnerability scan reports and policies and will not be deleted.
3.9 Nessus Directory Configuration
3.9 Nessus Major Directories
3.9.1 Windows

\Program Files\Tenable\Nessus
Windows Nessus Subdirectories
 \conf
- Configuration files
54
 \data
- Stylesheet templates
 \nessus\plugins
- Nessus plugins
 \nessus\users\<username>\kbs
- User knowledgebase on disk

- Nessus log files
\nessus\logs
3.9.2 Unix Distributions (Red Hat, SuSe, Debian, Ubuntu, Solaris)

/opt/nessus
Unix Nessus Subdirectories
 ./etc//nessus/
- Configuration files
 ./var/nessus/users/<username>/kbs/
- User knowledgebase on disk
3.9.3 FreeBSD

/usr/local/nessus
FreeBSD Subdirectory

./lib/nessus/plugins/
- Nessus plugins
3.9.4 Mac OS X

/Library/Nessus/run
Mac OS X Subdirectory

/var/nessus/logs/
-Nessus log files
55
3.10 Nessus Server Manager and Client Interfaces
3.10.1. Nessus Server Manager
Use the Nessus Server Manager to start, stop and configure the Nessus server.
The Client interface provides the connection to the server. The server interface
allows you to:

Register your Nessus Server to nessus.org in order to receive updated
plugins

Perform a plugin update

Configure the startup option whenever Windows starts

Manage Nessus users

Start or Stop the Nessus Server
56
Figure 3.8 Windows Server Manager Configuration
3.11 Changing Default Nessus Port
Edit the nessusd.conf file located in C:\Program Files\Tenable\Nessus\conf\ to
change the default port. These configuration directives can be edited to alter the
Nessus service listener and Web Server preferences:
# Port to listen to (old NTP protocol). Used for pre 4.2 NessusClient
# connections :
listen_port = 1241
# Port for the Nessus Web Server to listen to (new XMLRPC protocol) :
57
xmlrpc_listen_port = 8834
Stop the Nessus service via the Nessus Server Manager and restart it.
3.12 Registering the Nessus Installation
Register Nessus by clicking on “Obtain an activation code”. Two options exist.
The Nessus website will offer a HomeFeed and ProfessionalFeed version. The
website is at http://www.nessus.org/plugins/?view=register-info.. A
ProfessionalFeed is required for commercial use and offers plugin updates,
customer support, configuration audits, virtual appliance and more. A HomeFeed
is required for home users and not licensed for professional or commercial use.
Required information is provided and processed and an email that contains an
Activation Code entitles you to either the ProfessionalFeed or the HomeFeed of
plugins. Enter the Activation Code in the appropriate field and click on the
“Register” button. Note that you will be prompted to enter the administrator
username and password. The Nessus Server Manager authorizes the Feed
Activation Code, and takes several minutes to update the Nessus plugins.
Functioanlity in the Nessus Server Manager is disabled until it is activated.
Note: Nessus Security Center is a centralized application that can be used to
manage Activation Codes for several Nessus installations.
3.13 Adding User Accounts
Click on the “Manage Users”button in the “Nessus Server Manager” dialog.
58
Figure 3.9 Activated Windows Server Manager Dialog
59
Click on the “+” button to enter a new username and password.
Figure 3.10 Nessus User Management Dialog
60
Enter the username, the password, the password again, and select
the “Administrator” checkbox to assign administrator credentials to the user.
Figure 3.11 Nessus Add/Edit User Dialog
Clicking the “Edit…” button will allow password maintenance. Click the “-”
button with a user selected will delete the user after confirmation.
61
Figure 3.12 Nessus Client Login User Dialog
3.14 Host-Based Firewalls
It is required that connections be allowed from the Nessus client’s IP address if the
Nessus Server is configured on a host with a personal firewall such as Zone Alarm,
Sygate, Windows XP firewall or any other firewall software. T he default port 8834 is
used for the Nessus Web Server user interface. On Microsoft XP service pack 2 (SP2)
systems, clicking on the “Security Center” icon available in the “Control Panel”
presents the user with the opportunity to manage the “Windows Firewall” settings. To
open up port 8834 choose the “Exceptions” tab and then add port “8834” to the list.
Consult the documentation for configuration instructions for other personal firewall
software.
62
3.15 Other Operating System Configuration
Configuration of other operating systems requires specific parameters for the desired
results. Configuration is very similar for the different supported operating systems.
The Graphical User Interface (GUI) dialogs can be used for the required
configuration. Refer to the installation guides for the particular operating system and
version for a complete detailed guide. The guides can be found at
http://www.nessus.org.
Note: The configuration tasks can be done via Command Line Interface (CLI)
directives. Configuration files can be edited for the desired configuration.
Refer to the installation guides for the particular operating system and version.
The guides can be found at ttp://www.nessus.org.
63
Figure 3.13 Configuration Screen for Credentials
3.16 Policy Compliance Plug-ins
The Policy Compliance plug-ins are also referred to as compliance checks. These are
the mechanisms implemented by which audit files work. They facilitate the means to
audit a variety of settings from baseline operating system security policy to
customized application configuration checks such as those found in the Bandolier
security audit files. Tenable offers operating system audit files for nearly all major
operating systems. See Figure 3.14.
64
Figure 3.14 Policy Compliance Plug-ins
3.17 Patch Auditing
Nessus credential checks can be used to identify missing security patches. Local
security plug-ins will check for missing operating system and application patches that
are commonly overlooked during the security assessment phase. This task is one of
the most critical tasks that are required for securing operating systems and
applications. See Figure 4.3 for an example screenshot.
65
Figure 3.15. Example plug-in Selection of Operating System and Application
Security Scans
3.18 Netstat Port Scanner
Nessus also has the ability to use the authenticated connection to do a "netstat" port
scan. This is a safe way to enumerate open ports without a traditional port scan that
has been known to crash some control system applications. As the name implies, on
Unix systems the command netstat -an is invoked to return the results. For Windows,
WMI is used to return the same information.
66
3.16 Customize Policy Edit
3.19 Reporting
Using a combination of the Nessus credential scanning features can produce a useful
NERC CIP compliance report that often gives more insight into the security posture
of the machine or system. Combining the Bandolier security audit files, netstat port
scanner, and patch auditing can produce a report for inspection by the asset owners.
Here is the report of the custom iepeers.dll 0-day vulnerability [10] [11] plug-in run
against a Windows XP un-patched computer. See Figure 3.17.
67
Figure 3.17. Report Example of the iepeers_dll_0day.nasl plug-in and Windows
Compliance Checks on an un-patched XP virtual machine
68
Figure 3.17.1 Report Example of the SSH Remote Root Login Compliance Check on
a Fedora Core 12 virtual machine
69
3.20 Nessus Scanner Use
Nessus users have a wide range of powerful options whose functionality is critical to
a successful vulnerability scan. Scans can be configured and tailored for specific needs
in each unique environment. As with any function in the Technology industry, there is
the balancing act that must be observed. For instance, “Thorough Tests” can be
selected in the Global Settings menu. This will cause the scanner to behave differently
when executing but can also have a risk of adversely affecting fragile hosts or
services. This will cause the scanner to behave differently with over 900 of the more
than 34,000 plug-ins available with Nessus. The idea is to use the “Thorough Tests”
option only if needed. A system administrator would not select this option if all he
wanted to perform is port enumeration. Or the system administrator could select
“Thorough Tests” and “Enable CGI scanning” options for scanning specific web
applications. These configuration examples show that the options are features in the
scanner that add to its flexibility and robustness.
70
3.21 Nessus User Configuration Tab
The Nessus configuration tab is used to add users and assign permissions. The users
are then restricted to the permissions of their account.
Figure 3.18 Nessus User Tab
71
3.22 Nessus Policy Configuration Tab
Nessus policy configuration tab is used to customize the policy for a scan. Policies
can be configured in a variety of configurations. Plug-ns can be added or removed,
credentials can be supplied, preferences defined and the policy can be named and
described. The entire configuration for a policy customization is done in this tab.
Figure 3.19 Nessus Policy Tab
72
3.23 Nessus Scan Tab
The Nessus Scan Tab is used to select the policy for the scan. The scan is named and
the target or targets are specified. The “Launch Scan” button is then highlighted.
Figure 3.20 Nessus Scan Tab
73
3.24 Nessus Report Tab
The Nessus Report Tab is used to select the report for the scan. The report is selected
and the download button is used to fetch the report from the server. The format is
selected form the dropdown menu. The HTML format is a convenient format for
quickly displaying the results.
Figure 3.21 Nessus Report Tab
74
3.25 Customize Policies
Several factors that make the Nessus Scanner an ideal tool for system administrators
is the ability to customize plug-ins for very specific needs. This fine granularity
enables each plug-in to be used a building block to address the multitude of
vulnerabilities that can be exploited in SCADA systems. Since the integration of the
Internet into ICS, it is difficult to discover all the vulnerabilities that have surfaced in
the system. Nessus includes a list of over 34,000 plug-ins used for discovering
vulnerabilities. However, the case may exist where no plug-in has been written for a
particular case.
At fist glance, it appears like a comprehensive list of plug-ins is available for Nessus
scanning. Research shows that there has not been a plug-in written to address CVE2010-0806 “Peer Objects” component involving access to an invalid pointer upon the
deletion of an object. Otherwise known as an “Uninitialized Memory Corruption
Vulnerability”, exploits have surfaced in the wild in March 2010 [10] [11]. The
following NASL code [5] was written to address this vulnerability.
#
# iepeers.dll 0-day vulnerability script
# (free-after-use
# aka Uninitialized Memory Corruption Vulnerability )
# CVE Reference: CVE-2010-0806
# Written by Raymond Cordova
# Test Script to detect 0-day vulnerability in Internet
Explorer
75
#
include("compat.inc");
if (description)
{
script_id(50003);
script_version("$Revision: 1.0 $");
script_name(english:"iepeers.dll 0-day vulnerability
in Internet Explorer versions 6 or 7");
script_summary(english:"Checks Internet Explorer
version for 0-day free-after-use vulnerability.");
script_set_attribute(attribute:"synopsis", value:
"A older version of Internet Explorer (6 or 7) is
installed on the remote host.");
script_set_attribute(attribute:"description", value:
"A version of Internet Explorer (6 or 7)
is installed
on
the remote host.
Data Execution Protection (DEP)is
enabled by default in IE 8.0 which helps mitigate
attacks against it.
Microsoft recommends that users upgrade to version 8
for better security. Note that there are unconfirmed
reports from Secunia program and computer online
76
scanners report that version 8 is also vulnerable to
the iepeers.dll vulnerability using ActiveX.");
script_set_attribute(attribute:"see_also", value:"
http://blogs.technet.com/msrc/archive/2010/01/14/secur
ity-advisory-979352.aspx
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE2010-0806
http://www.vul.kr/microsoft-internet-explorer-iepeersdll-use-after-free-exploit-meta
http://www.microsoft.com/technet/security/advisory/981
374.mspx
http://secunia.com/advisories/38860/");
script_set_attribute(attribute:"solution",
value:"Upgrade to Internet Explorer 8." );
script_set_attribute(attribute:"risk_factor", value:
"Medium");
script_set_attribute(attribute:"plugin_date",
value:"2010/03/28");
script_end_attributes();
script_category(ACT_GATHER_INFO);
script_family(english:"Windows");
script_copyright(english:"This script is a test script
written by Raymond Cordova.");
77
script_dependencies("smb_hotfixes.nasl");
script_require_keys("SMB/IE/Version");
script_require_ports(139, 445);
exit(0);
}
include("global_settings.inc");
include("smb_func.inc");
port = kb_smb_transport();
version = get_kb_item("SMB/IE/Version");
v = split(version, sep:".", keep:FALSE);
if ( int(v[0]) > 5 && int(v[0]) < 8 )
{
if (report_verbosity > 0)
{
report = '\n' +
"Internet Explorer version " + version + " is
installed on the remote host. The iepeers.dll
is vulnerable to exploits. This vulnerability
exploits the “free-after-use invalid object
pointer after object deletion" + '\n';
security_warning(port:port, extra:report);
}
else security_warning(port);
78
exit(0);
}
else exit(0, "Internet Explorer version " + version + "
is installed on the remote host. The iepeers.dll is
vulnerable to exploits.");
Script 3.1 XP “iepeers.dll” 0-day Vulnerability Script
Script 3.1 will scan, detect, report and suggest a solution to the vulnerability, if
found. The methodology used includes the use of previously written code by the use
of a dependency statement in the code. e.g., script_dependencies(). Also, local
Knowledge Base items stored on the local server are accessed for use with
script_require_keys() statement. Utilizing these functions allows for enhancing the
performance and overall effectiveness of the scan.
# Windows Compliance Check for XP computers
# Checks for disabled USB Storage Devices
# Version 2 Windows Compliance Plugin
# Written By Raymond Cordova
<check_type: "Windows" version: "2">
<group_policy: "Audits Windows 2003 Systems for disabled
USB Storage devices.">
<custom_item>
type: REGISTRY_SETTING
79
description: "USB Storage Devices
Are disabled"
value_type: POLICY_DWORD
value_data: 4
reg_key: "HKLM\SYSTEM\CurrentControlSet\
Services\UsbStor"
reg_item: "start"
reg_type: REG_DWORD
</item>
</group_policy>
</check_type>
Script 3.2 XP USB Storage Devices Disabled Compliance Check Audit
Script
80
# Windows Compliance Check for XP computers
# Checks for disabled CDROM autorun
# Version 2 Windows Compliance Plugin
# Written By Raymond Cordova
<check_type: "Windows" version: "2">
<group_policy: "Audits Windows Systems for CD AutoRun
disabled">
<custom_item>
type: REGISTRY_SETTING
description: "CD AutoRun Disabled"
value_type: POLICY_DWORD
value_data: 0
reg_key:"HKLM\SYSTEM\
CurrentControlSet\Services\Cdrom"
reg_item: "AutoRun"
reg_type: REG_DWORD
</item>
</group_policy>
</check_type>
Script 3.3 XP CDROM Auto-play Disabled Compliance Check Audit
Script
81
<check_type:"Unix">
<custom_item>
type:FILE_CONTENT_CHECK
description:"Check if PermitRootLogin is set to no
and not commented for the server."
file:"/etc/ssh/sshd_config"
regex:"^ *[^#]*PermitRootLogin *"
expect:"PermitRootLogin no"
</custom_item>
</check_type>
Script 3.4 Fedora 12 SSH Remote Root Login Disabled Compliance
Check Audit Script
Following the Nessus best practices presented in the NASL Reference Guide [5],
the code was written to address only one vulnerability in each plug-in. In this way,
the plug-in can be used with future or existing plug-ins as a building block that
becomes a building block of a complex collection of plug-ins.
3.26 Nessus Scan Performance Metrics
Nessus scans were performed on the prototype and ISSG lab computers. The
prototype layout is shown in Figure 3.22.
82
Prototype Layout
5/10/2010
ENSDV / Cordova
12
Figure 3.22 Prototype Layout
The Nessus scanner used was version 4.2.1 build 9119 with the
ProfessionalFeed subscription services with updated plug-ins. Full scans were
performed with CGI, Web application tests and thorough testing enabled. Safe
checks were also enabled. Administrator credentials were provided in the Nessus
policy.
83
Prototype Target Machines
Seconds
3Com SSS HP Procurve VXWorks
723
HP Jet Direct Printer
253
Windows 7 Home - physical
565
Windows Server 2003 VM
242
Windows XP Pro un-patched VM
279
Linux Kernel 2.6 VM
Windows XP Pro patched - physical
Table 1. Prototype Nessus Scan Time
874
1153
84
Figure 3.23 Nessus Scan Performance Times on Prototype
Nessus scans were performed on the ISSG lab computers on subnets 128.198.60.0
and 128.198.62.0. The scan discovered 34 machines active on the network. Full scans
were performed with CGI, Web application tests and thorough testing enabled. Safe
checks were enabled. Credentials were not provided in the policy.
85
Target Machines
Seconds
128.198.60.1
128.198.60.127
128.198.60.129
128.198.60.18
128.198.60.181
128.198.60.63
128.198.60.65
128.198.62.1
128.198.62.120
128.198.62.131
128.198.62.184
128.198.62.185
128.198.62.186
128.198.62.2
128.198.62.25
128.198.62.26
128.198.62.3
128.198.62.90
128.198.62.91
128.198.62.92
128.198.62.93
a-212-01.csnet.uccs.edu
a-212-02.csnet.uccs.edu
a-212-03.csnet.uccs.edu
a-212-04.csnet.uccs.edu
ace.csnet.uccs.edu
b2b.csnet.uccs.edu
bilbo.csnet.uccs.edu
gandalf.csnet.uccs.edu
se-a210-05.csnet.uccs.edu
sis.csnet.uccs.edu
viva.csnet.uccs.edu
walden.csnet.uccs.edu
walrus.csnet.uccs.edu
blanca.uccs.edu
Table 2. ISSG Nessus Scan
409
413
412
5830
368
417
402
455
530
1372
429
464
460
461
4864
565
456
586
675
767
701
320
324
385
362
1117
373
466
4233
354
372
5272
781
4587
5666
86
Several factors affect the scan time on the target machines. It appears that the scan
takes longer on machines that have web services installed. The Viva server took
5,272 seconds to complete. The scan appears to have found several web server’s
instances of virtual Apache installations. Older machines such as the physical XP
patched machine on the prototype did not perform well. Several applications and
services installed on this machine have it in an “overloaded” condition. The machine
has a 1GHz PIII with 512 RAM and is very slow when working on a modern
application. Many other factors affecting scan time performance include:
•
Hardware
•
Operating System
•
Applications
•
Services
•
Network Infrastructure
•
Nessus server Host
•
Firewall
•
Passive or Active IDS/IDP
Note: For additional assessment of Nessus scan performance, please refer to
http://www.nessus.org/documentation/index.php?doc=nessus published by Tenable
Nessus [19].
87
Figure 3.24 Nessus Non-credential Scan Performance Times on ISSG Lab
88
Figure 3.25 Nessus Non-Credentialed Scan on ISSG Lab
89
Figure 3.26 Nessus Credentialed Scan on ISSG Lab
90
Results of the two different scans indicate how different configuration can affect
the scan performance. Four machines were targeted:

Athena.csnet.uccs.edu

Blanca.uccs.edu

Gandalf.csnet.uccs.edu

Viva.csnet.uccs.edu
The policy configuration was identical except for the credential configuration in which
credentials were provided for one scan and not the other. It should be noted that
credentialed scanning invokes additional plug-ins for a more comprehensive scan
result. Additionally, scans will only run plug-ins that are pertinent in a cascading
fashion, e.g., if the web application test is enabled and a web application is found on
the target machine, more scan tests will be launched against the target. If no web
application is found, the web tests will terminate and scan time is reduced. .
Figure 3.25 scan result with no credential configuration indicates a shorter period of
time for the scan to complete. Figure 3.26 indicates longer periods of time before the
scan completed. Credentialed scanning took slightly over 36% longer than noncredentialed scanning.
91
92
Chapter 4 Lessons Learned
4.1 SCADA Access
As plans unfolded for research in ICS and Internet integration emerging technology
and security of the systems, several unforeseen issues began to surface. The first
realization of difficulty focused on the problems with procuring a prototype that could
simulate a SCADA infrastructure. When asked about test access to a SCADA test bed,
a quote from an email from Renaud Deraison of Nessus simply states, “That's the
biggest problem with SCADA”, indicating no test scans can be tested on the SCADA
system unless special permission is granted through contract agreement. Ultimately,
no access to any test bed or system could be established because of the stringent
security of the ICS.
4.2 Meter and Development Kit Procurement
While attempting to procure smart meters and collection points for lab testing,
several vendors were hesitant to provide any information about their product for fear
of divulging trade secrets and discovering unknown vulnerabilities. This procurement
proved difficult to implement because of vendors at Byram Labs offered meters at a
cost of nearly $3000 to provide a few meters of different models but the collection
points would cost $900 for an online monitoring service in 6 month time periods.
Other vendors provided meters only for authorized buyers. And others would allow
93
purchase of a smart meter but provided no support for interface support, code
enhancement, development or hardware. It became apparent meters purchased directly
from a vendor would not fulfill thesis research requirements to enhance network
scanning for discovering vulnerabilities.
Several development kits could simulate a “Smart Meter” but cost, interface
hardware, software, and the ambiguity of what is specifically needed made the
decision difficult. Extensive research showed the TI CC2530ZDK MSP2530 ZigBee
and ZigBee Pro development kit to be a good candidate for conducting meaningful
research. The development kit costs $649 and has a “Sample before Buy” program
that allows for users to order different hardware samples for testing in the kit. This kit
allows for testing of several different low-power RF processors and protocol stacks
currently used in TI’s solution for Smart Meters. Also considered was the CC430 that
integrates the latest MSP430F5xx to develop an entire wireless project. However,
more functionality and flexibility is integrated in the MSP2530 development kit with
the more secure Smart Meters using this hardware.
Another candidate development kit is the CC2430 System-on-Chip solution for 2.4
GHz IEEE 802.15.4 / ZigBee. The ZStack library version 2.2.2-1.30 used in the
CC2430 and CC2530 microcontrollers uses an insufficient random Psuedo-RandomNumber-Generator (PRNG) for cryptographic signatures and session keys. PRNG data
repeat every 32,767 samples, and there are at most 16 bits of entropy in any key.
Searching the entire key space is possible without investing a lot of time. The random
numbers must not be used to generate random keys used for security purposes. The
94
flaw is that the PRNG is not cryptographically secure and is that it is seeded from a
random source that has very little entropy. The weakness ought to serve as a
cautionary tale for the untold number of companies working on parts with stimulus
monies that will make up the emerging smart grid. So it became a time consuming
research task to determine if the Zigbee stack shipped with the development kits
CC430 and CC2530 shipped with the latest version 2.3.0 which relies on the fact that
the Zigbee stack in these kits is not flawed.
4.3 Nessus Scanner
The Nessus demo version was selected for the functionality, flexibility,
customizable, powerful, automated, safe scanning tool that it is advertised as. Nessus
boasts it is a centralized invaluable tool for ICS/Internet administrators to simplify the
daunting task of securing the ICS/Internet infrastructure. The decision was made to
test the tool with credentialed scanning and customize plug-ins for enhancing the tool
to add meaningful value. The focus was to identify and focus on a methodology to be
used as a foundation to be used to meet the security requirements of the various
enterprise organizations. The Nessus HomeFeed version was downloaded and it was
soon discovered that the tool functionality is limited to basic scanning. It became
evident the HomeFeed version would not meet the requirements to fulfill research,
methodology and enhancement goals.
Renaud Deraison at Nessus was contacted through email with a request for the
ProFeed version. Project information was provided and Renaud provided a fully
95
functional version of Nessus ProFeed. The ProFeed version provided additional
functionality:

Report comparison

Resolved inconsistencies in the creation of custom plug-ins

Re-index DB inconsistencies

Display issues with plug-ins
The Nessus ProFeed exhibited odd behavior with custom plug-ins.

Re-index DB inconsistencies unless the DB is purged and rebuilt

Display issues with plug-ins

Re-named plug-in is run twice if ID is not updated

Re-named plug-in is displayed twice in plug-in dialog window
The solution to rebuild and re-index the database was attempted to resolve the
problems encountered with custom plug-ins. The command “:>"c:\Program
Files\Tenable\Nessus\nessusd.exe" -R 3 was entered in a command prompt. The “–R”
and the number “3” switch options rebuild the database with a complete flush, rebuild
and re-index. The procedure to logout of the client, stop the Nessus server and execute
the command failed. The command prompt immediately returned and the server would
not restart. The installation was repaired through the Control Panel Programs applet
and the server restarted successfully. However, the duplicate plug-ins were still listed
and the scan report indicated two instances of the same plug-in although the plug-ins
were named differently. The underlying cause was the plug-in ID number was
identical in that the ID number was not changed during the renaming procedure. This
96
effectively caused a collision of the plug-ins in the database and the cached plug-in
mechanism. Two mistakes were made. Renaming a plug-in requires the ID to be
changed immediately before the server is restarted or plug-ins are updated through
server manager. The re-index command failed because the server manager window
was still open even though the server was stopped. The server manager window must
be closed prior to rebuilding the DB.
When starting the Nessus Server Manager, the user must wait about a 10-30 seconds
before starting the client. Although the server indicates the service is started, there is
obviously some background process that is still starting that the client depends on to
successfully connect to the server.
Figure 4.1 Successful Nessus Database Rebuild and Re-index
4.4 Digital Bond Bandolier Project Compliance Check
Plug-ins
Preliminary research direction focused on the Bandolier files delivered to Nessus for
SCADA compliance checking. The idea was to investigate the files for a better
97
understanding of scanner use with compliance check audit files. This tool is further
supported by the Digital Bond Bandolier project [6]. Nessus has been approved by
North American Reliability Corp. (NERC) Critical Infrastructure Protection (CIP) as a
tool for scanning SCADA. Plug-ins are custom written to scan SCADA network
systems and require subscription services for full functionality and update service. The
Bandolier project has provided forty 40 new plug-ins specifically written for SCADA
as of May 2010 The plug-ins are pre-compiled Nessus binary (.nbin file extension)
files that could not be analyzed unless they are reverse engineered with an application
similar to IDA Pro. This made it difficult to analyze and research these scripts. Deeper
research revealed many of the “nbin” files are run only as compliance checks for
SCADA vendor specific applications and focus was shifted away from analyzing these
files. Two audit files were disassembled and analyzed. It became evident that it would
not be advantageous to continue in this direction.
4.5 Nessus Attack Scripting Language (NASL)
The Nessus Attack Scripting Language (NASL) [5] is a new language to learn
before any scripting or customizing can be done. The reference manual was studied
and test scripts were written to tune skills for the methodology to write custom scripts.
The NASL interpreter proved to be very unforgiving. A space in the script would
render the script un-executable and could only be discovered by brute force trial and
error until running the mis-behaved script resulted in script errors in the report. Of
particular concern are the Windows Compliance check ID 51126 and Unix
Compliance Check ID 51127 scripts. During the creation of an enhanced script for
98
detecting SSH remote root login, the report indicated a conflict in version 1 and 2 of
the compliance scripts. The windows script worked but the Unix Compliance Check
ID 51127 would report “check_type” not set in the created custom script. Research of
Nessus documentation and discussion boards indicated that “v2” be appended to the
filename and the opening <“check_type : “Unix” version: “2”> and closing
</check_item> tags are required for the version 2 plugin. The Nessus database is reindexed with a nessus –t command to accept changes to any plug-ins. The nessus –D
is used to re-build the database. The Nessus service is restarted and errors persisted.
The script was re-written from scratch with a backward compatible version 1 format
and received a parse error indicating “ “ in line 3. The space was removed and the
script successfully completed. A version 2 script was re-created and fails with the
same indications. The limited resources of discussion boards, limited support,
documentation all indicate the <check_type> tags should be included in version 2 but
clearly do not work for Unix compliance checks. Issues appear to be an unforgiving
syntax error in which a “space” before or after the script statements cause an error at
run time and the version 2 syntax not recognized correctly in Unix Compliance Check
ID 51127. Renaud Deraison of Nessus has confirmed that the version 2 syntax is not
functional in the Unix compliance checks and only works with Windows.
4.6 VMware
The VMware server console was selected as the Virtual Machine solution for
simulation of a computer systems connected to SCADA systems. The VM server
software would not install on the un-supported laptop hardware and had to use VM
99
Workstation or Player trial versions. Four machines were configured as W2K3
unpatched, XP unpatched, Ubuntu 10 beta and Fedora 12 with telnet enabled. The
virtual machines were then scanned and the XP un-patched machine was scanned
successfully with administrator credentials. The W2K3 machine returned with limited
results. It could not fully be scanned with credentials since no domain was defined.
The Ubuntu 10 machine was scanned resulting in no critical vulnerabilities found
since no plug-ins have not been written for the Beta version of Ubuntu 10. Although
there are Ubuntu plug-ins for earlier versions and the scan runs against Ubuntu 10,
earlier version plug-ins are not executed. Fedora 12 was configured with telnet
services and SSH remote root login enabled. Scans produced a report indicating both
risk configurations on Fedora 12.
Difficulties surfaced with the virtual machines. The XP un-patched machine became
corrupt and had to be re-installed. It should be noted no scans were run on the XP
machine prior to the corruption and had been powered down ever since it was created.
It is not known why this occurred.
The Fedora 12 and W2k3 machines lost network connectivity when testing at UCCS.
The Windows 7 laptop performed very well with all 4 virtual machines active.
However, attempting to run a Nessus scan on the virtual machines while connected to
the UCCS wireless campus resulted in no scan run on any virtual machine. Re-testing
on the home prototype wireless LAN successfully completed. Connections on the
“bridged” network adapter needed to be configured as “host only” for successful
100
network connectivity between the host machine and the virtual machines. The
scans were successfully completed at home and UCCS and re-testing proved
successful.
101
102
Chapter 5 Future Direction
5.1 Texas Instruments Development Kits
Research can be continued in a lab setup of Texas Instrument’s MPS2530 microcontrollers. This development kit can be used to assess Texas Instrument’s smart
meters that are currently being used in the United States. The micro-controllers are
advertised as NIST CIP compliant; however, there are vulnerabilities in the MPS2430
series meters. Research and development is needed for the creation of enhanced plugins to check the ZigBee stack version for the Pseudo Random Number Generator
(PRNG) vulnerability. ZigBee stack versions greater than version 2.3 do not exhibit
the (PRNG) vulnerability.
5.2 Automatically Patching Failed Compliance
Checks
In a related area of work, Digital Bond and the Bandolier project have provided 40
specifically targeted compliance plug-ins for SCADA. The plug-ins are Nessus binary
pre-compiled files with a “.nbin” file extension. A possible research project can be
performed to research the compiler for the possibility to integrate the audit file
language with C+ for automatic patching of specific security vulnerabilities. The
compliance check file, registry key, web banner, configuration file, etc. is already
known to the plug-in and it would be matter of changing a value from “yes” to “no”,
103
as such in the case of “PermitRootLogin Yes” for Fedora Core 12. The C+
language is recognized by the Nessus interpreter.
5.3 Shared Plug-ins
As of May, 2010, Tenable Nessus provides 35,414 plug-ins to the scanner that are
updated daily. There are vulnerabilities that have not been addressed by the direct feed
plug-in subscriptions from Tenable. A possible research project can focus on the
methodology presented in this thesis to contribute to the creation of plug-ins to share
among the Nessus community. Many of the plug-ins in the subscription direct feed
services were written by Nessus community users. This can become a great
contribution if an ongoing comprehensive effort is undertaken.
5.4 OS Extensions
The Windows vulnerability and audit files can be tailored for different Operating
Systems (OS). The registry keys being inspected are unique to different OS’s and can
be quickly and easily modified for different versions of Windows. This process entails
determining the correct registry keys and configuration files for inspection for each
OS.
5.5 System Alert for Detecting Plug-in Removal
Lastly, I can envision a project for future work to alert the administrator that a
customized plug-in has been removed form the plug-in directory. However, if the
custom plug-in is uploaded to Nessus direct feed subscription services, the update
104
would download the plug- if non-existent in local directories. This is the Nessus
community idea of sharing.
If it is simply a local custom plug-in not being shared and not uploaded to Nessus,
the code alert project would be interesting to implement. Perhaps some code to
determine if the plug-in directory size decreases could be used as a trigger for the
alert. The directory should only grow. The plug-in cache will already contain a copy
and would still run even if the custom plug-in is removed.
105
106
Chapter 6 Conclusion
As the utility power grid catches up to technology, several inherent problems
surface that are apparently not as visible as most would think. The problems arise from
the cyber net infrastructure that introduces common vulnerabilities that have evolved
from the Internet communication system and computer/network operating systems..
The Committee of Homeland Security and several other regulatory agencies have
heard recommendations [15] [18] from security consultants that have researched the
problems and the devised solutions for the security vulnerabilities in wireless and
cyber infrastructures.
I have surveyed the smart grid technology and related security issues. Research
performed has proved that the available smart meters are insufficient in security
mechanisms to protect the smart grid from what are common Internet and Operating
System vulnerabilities.
It is interesting to note that emerging technology for ICS has finally reached a point
of maturity that security has dictated the need for confidentiality, integrity and
availability in a scope where no compromise can be tolerated. To this end I have
designed and developed Nessus plug-ins to enhance network scanning to discover
vulnerabilities and perform compliance checks. A test-bed prototype consisted of
virtual machines to ensure the enhanced plug-ins “behaved”.
107
I have developed a systematic methodology that can be followed as a foundation
to create new custom plug-ins to tailor the scans for specific ICS/IP or network
environment. The methodology involves writing a plug-in for only one vulnerability,
using Nessus built-in functions to determine if the scan should be run, call other plugins as dependencies to use those results in the current scan, and share the custom plugin with the Nessus community. The Nessus Attack Scripting Language (NASL) very
elegantly accommodates this methodology coding of the attack test script.
The iepeers.dll vulnerability plug-in was written to check for a 0-day vulnerability
discovered in the wild in March 2010.
Discovering 0-day exploits can be a
challenging task or relatively simple. The development approach methodology I
present requires the system administrator be pro-actively checking bulletins,
subscribing to security advisories and staying on top of the issues that arise in the
course of his duties. Or a new vulnerability might be discovered by meticulously
searching logs. The development approach methodology presented in this thesis can
be flexed to encompass unique situations.
Audit file compliance checks were written to enhance the scanner for detecting
compliance for three important issues. The audit file compliance check files and there
fuction are described below:

ssh_remote_root_login.audit detects sshd_config does not allow remote ssh
logins on Fedora Core 12 OS

CD_autorun_disabled_v2.audit detects CDROM autoplay is disabled ion
Windows XP machines
108

USB_storage_disabled_v2.audit detects USB storage devices are disabled
on Windows XP machines
The plug-ins contribute to enhancing the Nessus scanner by detecting special cases
that may otherwise be overlooked. Sharing the results and newly created plug-ins
benefits the family of Nessus users. It is recommended that those responsible for
securing their network follow the methodology presented in this thesis to lay a
foundation for a systematic approach to securing their networks. The methodology
expects the system administrator to perform the most important step to analyze
complicated data to determine the best set of operations by examining granularities in
work processes, programs, network systems and projects to implement network
standards, policies and procedures.. Once a standard is accepted, scanning is begun
and vulnerabilities must be patched. Enhance the scanner with new plug-ins and test in
a prototype. Release into production if the plug-in behaves and scan at scheduled
intervals.
.
109
References
[1] ANSI C12.22: A Smart Grid Standard, Itron Smart Meters.
http://news.itron.com/Pages/ami1_1108.aspx
[2] Chow, Edward Dr., Graphic use granted by permission of Dr. Edward Chow
at UCCS website http://cs.uccs.edu/~cs691/
[3] Common Vulnerabilities and Exposures (CVE)
http://www-arc.com/sara/cve/cve.html
[4] Contactless Radio Frequency Technology Transforming Smart Meters with
Secure Pre-Payment,
http://www.ti.com/rfid/shtml/apps-smartmetering.shtml
[5] Deraison, Renaud, Reference Manual for Nessus Attack Scripting Language,
Version 1.4.0, Manual at website at
http://www.virtualblueness.net/nasl.html
[6] Digital Bond research project.
http://www.digitalbond.com/wiki/index.php/Bandolier#Compliance_Chec
k_Examples
[7] Definition and list of vulnerabilities.
http://www.owasp.org/index.php/Category:Vulnerability
[8] First OMS compliant Wireless M-Bus RF module for smart meters launched
http://www.metering.com/node/16162
110
[9] Guide to Industrial Control Systems (ICS) Security, Supervisory Control
and Data Acquisition (SCADA) systems, Distributed Control Systems
(DCS), and other control system configurations such as Programmable
Logic Controllers (PLC) http://csrc.nist.gov/publications/drafts/80082/draft_sp800-82-fpd.pdf
[10] Information on 0-day vulnerability discovered in the wild March 2010.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0806
[11] Information on 0-day vulnerability discovered in the wild March 2010.
http://secunia.com/advisories/cve_reference/CVE-2010-0806/
[12] Itron Releases OpenWay® Collection Engine with Enhanced Security
Features, February 2009
http://www.itron.com/pages/news_press_individual.asp?id=itr_016976.xm
l
[13] Journal of Energy Security, Making a Secure Smart Grid a Reality, Subparagraph, Weaknesses in the Smart Grid, p. 3-7, October 2009.
http://www.ensec.org/index.php?option= com_content&view=article&id=
218:making-a-secure-smart-grid-areality&catid=100:issuecontent&Itemid=352
[14] SCADA and Control Systems Cyber Security.
http://loftyperch.com/index/use_lang/EN/page/408.html
111
[15] Stouffer,Keith and Falco, Joe and Scarfone, Karen Final Public Draft,
Special Publication 800-82, Recommendations of the National Institute of
Standards and Technology, Guide to Industrial Control Systems (ICS)
Security http://csrc.nist.gov/publications/drafts/800-82/draft_sp800-82fpd.pdf
[16] Smart Metering Scope graphic. http://www.energyretail.org.uk/documents/BERRWANCommunicationsOptionsDefinition.p
df
[17] Related work for network scanning. Digital Bond Bandolier project, Website
at http://www.digitalbond.com/wiki/index.php/Bandolier
[18] Weiss, Joseph, “Current Status of Cyber Security of Control Systems”,
Testimony of Joseph M. Weiss Control Systems Cyber Security Expert
before the Committee on Commerce, Science, and Transportation U.S.
Senate March 19, 2009.
[19] Windows and Unix published performance characteristics of Nessus version
4. http://www.nessus.org/documentation/index.php?doc=nessus4
112
Appendix A
A.1 Subject Descriptors
ICS - Industrial Control Systems
ICS - Incident Command System
NIST - National Institute of Standards and Technology
SCADA - Supervisory Control and Data Acquisition
SDL - Secure Development Lifecycle
ANSI - American National Standards Institute
NERC - North American Electric Reliability Corporation
FERC - Federal Energy Regulatory Commission
OMS – Open Metering System
HMI – Human Machine Interface
AMI – Advanced Meter Infrastructure
AMR – Advanced Meter Reading
CIP – Critical Infrastructure Protection
TGB - Tower Gateway Base-Station
ALA - Active Line Access
113
Appendix B
B.1 Selected Vendor Smart Meters
Several vendors have recently released enhanced versions of their smart meter
products. These vendors have been developing Smart Meters in compliance with the
Security Development Lifecycle and several guidelines adopted by the regulatory and
management agencies involved with the process of safely securing the Power Grid.
B.1.1 Itron OpenWay®
Itron has recently released its OpenWay® Collection Engine with Enhanced Security
Features [12]. Itron released the new Smart Meter February 11, 2009 and is leading
the industry with enhanced Smart Meter security. Two key characteristics of
OpenWay® by Itron make this possible: the economies of scale of the OpenWay
radio-frequency based local area network communications module (RFLAN), and the
American National Standards Institute (ANSI) C12.22 open standard protocol [1].
The release and initial shipments of an enhanced security Smart Meters enables strong
authentication and enhanced security for use in Advanced Metering Infrastructure
(AMI) deployments. The current version of OpenWay software is fully compliant with
security and encryption to meet industry and American National Standards Institute
(ANSI) C12.22 standards. The optional enhanced security version exceeds these
114
requirements by providing security consistent with the North American Electric
Reliability Corporation (NERC) Critical Cyber Asset requirements. Based on elliptic
curve cryptography (ECC), Itron is shipping Certicom's AMI 7000® series meters
with communication encryption and key management appliances in OpenWay to
secure end-to-end network messages. The AMI infrastructure receives and passes
information from the OpenWay Collection Engine down to the OpenWay
CENTRON® meter. The OpenWay security architecture, combined with enhanced
signing and encryption capabilities, is designed to meet the two-way command and
control requirements for AMI and Smart Grid network platforms. Itron boasts that
their solution provides strong integrity of control, non-repudiation, availability and
confidentiality. Also, Itron states that they now offer unparalleled network and
metering system security with the release of their optional enhanced security version,
enhancing the energy management and measurement technologies as efforts progress
toward the development of the Smart Grid. Interestingly, the meter provides strong
authentication to support enhanced security, a critical option required for secure
communication. See Figure B.1.
115
Figure B.1 Itron OpenWay® Solution
B.1.2 Texas Instruments Smart Meters with Secure Pre-Payment
Smart electricity, water and gas meters are undergoing extensive development
upgrades to ensure security. Additionally, a new revolution has surfaced for payment.
A contactless radio frequency (RF) chip Transponder IC, the Secure Multi-Purpose
Contactless IC/Module RF-HCT-WRC5-KP22 [4], has been incorporated into the
smart meter with a new capability for a consumer payment card or token. This idea is
transforming smart meters into secure [12] AMI/AMR and pre-payment devices. The
meters are built on high-speed, low-power, secure smart IC platform with industrystandard secure encryption. Several desirable features are included with the meters
listed as follows.
116

Triple DES, SHA-1 crypto-algorithms,

Mutual authentication – authorized tag
ANSI X9.63 session key
and reader complete
transaction

Flexible and configurable memory

Supports up to five applications on one card or token

ISO/IEC 14443 with ISO/IEC 7816 command set support
Radio Frequency enabled pre-paid smart meters give utilities access to a broader
customer base. RF enabled meters with Pre-Payment reduces the risk of non-payment
and offers consumers a new, fast and convenient way to control and pay for services.
Reduction in billing administration costs can be realized with this revolutionary new
idea. Two models of the reader are available, the TRF7960 and TRF7961 TI-RFid™
HF Reader IC. Both offer the following features.

High level of integration and performance

Low-power and small size

Configurable and flexible architecture

Eases hardware and software system design

Low total Bill of Materials (BOM)

ISO/IEC 14443, ISO/IEC 15693 and Tag-it
Several advantages of Contactless RF Pre-Payment can be realized for
consumers. Consumers can now control utility usage and not have utilities
117
turned off unexpectedly. It is expected that consumers will embrace the
convenience of “ 24/7 wave and pay as you go” . Major credit card
companies and banks worldwide are deploying secure contactless technology.
It is a fast and convenient “ tap-and-go”
credit, debit and stored-value
payment application at the retail point of sale. The technology securely stores
and transmits data over short ranges, typically less than 2 inches. Consumers
need only purchase contactless cards from a kiosk or the utility company. The
cards contain a secure contactless RF chip loaded with a pre-paid amount.
The consumer waves the card in front of the meter to activate it and the
amount is loaded into the smart meter and debited from the card. Texas
Instruments offers a complete contactless RF pre-payment solution for Smart
Meters, including tag and reader integrated circuits and microcontrollers. It is
an easy and efficient solution to RF-enable the latest generation of smart utility
meters.
118
B.1.3 Texas Instruments Smart Meters
The Texas Instruments (TI) product line of MSP430 microcontrollers and Low-Power
RF devices provide a solution for low-power wireless networks, including standardbased IEEE 802.15.4 low-cost, low-speed communication devices, ZigBee or other
proprietary networks. The MSP430 product line offers ultra-low power consumption,
power-saving mechanisms, a high-performance 16-bit CPU and integrated analog. The
MSP430 micros-controllers and TI’s Low-Power RF devices provide designers the
ability to achieve low power consumption, long range and reliable performance are
provided at a competitive price. The CC430 family of sub 1 GHz system-on-chip
monolithic devices integrates with the MSP4305xx microcontroller with a flexible
Low-Power RF transceiver.-Based Netwok
B.1.4. System-on-Chip Solutions
Industry’s highest performance, single-chip, low-power RF solution is the CC430. The
CC430 is based on the new 5xx generation of ultra-low-power MSP430
microcontrollers. Designed with a high level of peripheral integration, outstanding
analog performance and ease of use, the 5xx core is paired with the flexible CC1101
sub-1GHz transceiver to deliver the sensitivity and blocking performance required for
a robust communication link in RF environments. The CC430 devices enable the user
to minimize RF power, size, and cost requirements while still maintaining superior
119
application performance. There is also the 8051-based System-on-Chip solution.
TI recommends the CC2430/2431 for IEEE 802.15.4 and ZigBee networks use; the
CC2510/2511 is recommended for 2.4 GHz; and the CC1110/1111 for sub-1 GHz use.
The MSP2530 development kit provides a flexible platform to encompass the majority
of controllers, protocols and devices.
B.1.5 Standard-Based Networks
The IEEE 802.15.4 wireless radio frequency standard for low-power and short-range
applications is ideal for point-to-point or point-to-multipoint networks. The 802.15.4based proprietary network can be upgraded to evolve to a ZigBee-compliant system.
The ZigBee is a low-power wireless network standard that offers mesh networking
and interoperability between different products. ZigBee is a network layer on top of
the IEEE 802.15.4 standard physical and mac layers. Smart metering and home
automation services in Advanced Metering Infrastructure (AMI) profiles and the
Home Automation (HA) profiles are ideal targets for Zigbee.
B.1.6 Proprietary Networks
Texas Instruments (TI) accommodates free software code for building a network. The
SimpliciTI Network Protocol is implemented with a battery operated TI Low-Power
RF System-on-Chip or the MSP430 and an RF transceiver. The SimpliciTI network
protocol is a simple and versatile solution, combining MSP430+CC1101/2500,
CC1110/2510 and DSSS parts to provide solutions for applications such as alarm
systems, smoke detectors and active RF-ID applications.
B.1.7 Development Platforms
120
Texas Instruments (TI) offers several development kits that are available by
donation awards or purchase. Partial kits are available for evaluation via free
download but still require purchase of licenses, software, etc. for full functionality.
Texas Instruments offers the “Sample and Buy” program where developers can order
samples and test as needed. In this way, developers can evaluate the product. The cost
of the development kit can cost from less than a thousand dollars to several thousand
dollars. The TI CC2530ZDK development kit is a good starter candidate for lab use.
The MSP2530 micro-controller is currently used in the TI advertised compliant Smart
Meters.
CC2530ZDK
Name
CC2530 ZigBee Development Kit
Status
ACTIVE
Price (US$) $649.00
Order Options
Order Online
Figure B.2 CC2530 ZDK Development Kit Cost
121
A CC2530ZDK includes:

TI's ZigBee stack, Z-Stack (www.ti.com/z-stack)

2 SmartRF05EB Evaluation Boards

5 SmartRF05 Battery Boards

7 CC2530EM Evaluation Modules

USB Dongle Antennas and batteries IAR EW8051 C-compiler with C-SPY
debugger (30+30 day evaluation license.)
B.1.8 MBUS3 Firmware
On September 28, 2009 in Oslo, Norway, a new firmware feature set was
introduced as MBUS3 [8] to comply with the Open Metering System (OMS)
specification for advanced metering applications. It has been launched by the compact
RF module provider Radiocrafts AS. The new firmware runs on the Wireless M-Bus
module (RC1180-MBUS) for use in AMI/AMR applications. It is the first completely
embedded module solution compliant with the new OMS specification available in the
market in addition to the well established NTA 8130 compliant feature set
(MBUS2).The OMS primary communication interface is based on the Wireless M-Bus
standard (EN 13757-4:2005). It specifies the communication between a multi-utility
communications (MUC) controller or gateway and electricity, gas, water and heat
meters. The specification is becoming widely accepted in Europe. The new MBUS3
122
module can be configured for use as a master (in the MUC), a slave (in the meter
or an actuator), or as a repeater. Several desired features are capable in the MBU3 set.

supports S1, S2, T1 and T2 modes

handles encryption (AES-128) all time critical communication between
the MUC
and the meter

power saving features gives battery lifetimes in excess of 14 years

master module can support up to 64 slaves, all with unique encryption
keys

unique auto-message generation feature

message mailboxes supporting individual communication with several
slaves in parallel

repeater functionality makes up a complete and autonomous repeater
that will store and retransmit slave messages in order to increase the
coverage area of one master (MUC)
The new RC1180-MBUS3 [8] is a surface-mounted high performance transceiver
module measuring only 12.7 x 25.4 x 3.3 mm, and can easily be integrated into any
123
meter. Serial communication is facilitated by a UART interface that is used for
configuration. An antenna connects directly to the RF pin. When used with quarterwave antennas a line-of-sight range of 800 m can be achieved. The new module
supports two-way communication and is capable of valve control and data
acknowledgement. The RC1180-MBUS module has been certified for operation under
the European radio regulations for license-free use in the rapidly growing smart
metering market. This solution provides a complete Wireless M-Bus solution
compliant with the OMS specification in a small compact module form factor that is
easy to integrate into meters and gateways. The Wireless M-Bus stack makes it easy to
add a fully compliant OMS solution to space limited and battery operated meters. It
significantly reduces time-to-market, development, and compliance testing cost.