Vous êtes sur la page 1sur 28

ABB Power Grids

AFS660
Deployment Guideline
User Manual
AFS660 –
Deployment Guideline

Document History Ed01 May 2016


Ed02 July 2016

Copyright and Confidentiality: Copyright in this document vests in ABB LTD.


Manuals and software are protected by copyright. All rights reserved. The copying, reproduction,
translation, conversion into any electronic medium or machine scannable form is not permitted, either in
whole or in part. The contents of the manual may not be disclosed by the recipient to any third party,
without the prior written agreement of ABB.
An exception is the preparation of a backup copy of the software for your own use. For devices with
embedded software, the end-user license agreement on the enclosed CD applies.
This document may not be used for any purposes except those specifically authorised by contract or
otherwise in writing by ABB.

Disclaimer: ABB has taken reasonable care in compiling this document, however ABB accepts no liability whatsoever
for any error or omission in the information contained herein and gives no other warranty or undertaking
as to its accuracy.
ABB can accept no responsibility for damages, resulting from the use of the network components or the
associated operating software. In addition, we refer to the conditions of use specified in the license
contract.
ABB reserves the right to amend this document at any time without prior notice.

The product / software/ firmware/ or the resulting overall solution are designed for data-processing & data-
transmission and may therefore be connected to communication networks. It is your sole responsibility to
provide and continuously ensure a secure connection between the product / software/ firmware/ or the
resulting overall solution and your network or any other networks (as the case may be). You shall establish
and maintain any appropriate measures (such as but not limited to the installation of firewalls, application
of authentication measures, encryption of data, installation of anti-virus programs, etc.) to protect the
product / software/ firmware/ or the resulting overall solution, the network, its system and all the interfaces
against any kind of security breaches, unauthorized access, interference, intrusion, leakage and/or theft
of data or information. ABB Switzerland Ltd and its affiliates are not liable for damages and/or losses
related to such security breaches, any unauthorized access, interference, intrusion, leakage and/or theft
of data or information.

Although ABB provides functionality testing on the products including related firmware and software that
we release, you should institute your own testing program for any product updates or other major system
updates (to include but not limited to firmware/software changes, configuration file changes, third party
software updates or patches, hardware exchanges, etc.) to ensure that the security measures that you
have implemented have not been compromised and system functionality in your environment is as
expected.

Blank pages: Any blank page present is to accommodate double-sided printing.

Document No.: 1KHD653907-EN

ABB Switzerland Ltd


Power Grids
Bruggerstr. 72
CH-5400 Baden © 07/2016 by ABB Switzerland Ltd
CONTENTS

Contents

1 Introduction 5
1.1 Purpose of this document 5
1.2 Legend 5
1.3 Basic Cyber Security considerations 5
1.4 A formalized security model 5
1.4.1 Security policies and principles 6
1.4.2 Security services 7
1.4.3 Security planes 7
1.4.4 Security layers 8

2 Network design 9
2.1 Zones 9
2.2 External communication (including remote access) 9

3 Product related details 10


3.1 General aspects 10
3.1.1 Physical security 10
3.1.2 Verify authenticity of obtained SW/FW distribution 10
3.1.3 Define the Role - User mapping 10
3.1.4 Configuration for device management 11
3.1.4.1 General 12
3.1.4.2 Access with AFS Finder 12
3.1.4.3 Access with Web Browser (through local LAN port or remotely) 13
3.1.4.4 Access with Command Line Interface through IP connection (local or remote) 14
3.1.4.5 Access with Command Line Interface through serial interface (console port) 14
3.1.4.6 Access with AFS View-CT Craft Terminal 15
3.1.4.7 Access with AFS View Network Management System 15
3.1.4.8 Access with other SNMP Manager software 16
3.1.5 Additional product specific features 16
3.1.5.1 Monitoring security status 16
3.1.5.2 External storage CRA-SD 17
3.1.6 Device hardening 17
3.1.6.1 Disable all unused physical ports 18
3.1.6.2 Disable / close all unused logical ports and disable all unused services and
protocols 18
3.1.6.3 Enable port security 18
3.1.7 Logging 18
3.1.7.1 Local logging 19
3.1.7.2 Remote logging 20
3.1.8 Patches / Updates 20
3.1.9 Backup / Recovery 21
3.1.10 Time synchronization 21

4 AFS View-CT 22
4.1 Purpose and usage 22
4.2 Secure setup and operation of CT 22
4.2.1 Rights 22
4.2.2 User accounts 23
4.2.3 Logging 23

ABB AFS660 Deployment Guideline 3


CONTENTS

4.2.4 Secure communications 23


4.2.5 Firewall and virus-checker 23
4.2.6 Patches / Updates 24

5 Bibliography / Referenced documents 25


5.1 Product manuals 25
5.2 Section references 25

6 Document history 26

4 AFS660 Deployment Guideline ABB


INTRODUCTION
Purpose of this document

1 Introduction

1.1 Purpose of this document


This document forms an important part of the overall user documentation for AFS660, further called 'Product'. It is
applicable for the following equipment variants:
– AFS660-S, AFS665-S
– AFS660-C
– AFS660-B, AFS665-B
The document provides an overview about essential Cyber Security aspects and gives strong recommendations
about hardening the Product in the context of the communication infrastructure it is used for.
Your assets belong typically to the mission critical infrastructure of your country and utmost efforts shall be made
to mitigate possible Cyber Security risks. Compromises in this matter may result in serious consequences for your
country, company and yourself.

1.2 Legend
The designations used in this manual have the following meanings:

 List
 Work step
 Subheading
Link Indicates a cross-reference with a stored link
Note: A note emphasizes an important fact or draws your attention to a dependency.
Courier ASCII representation in user interface

1.3 Basic Cyber Security considerations


The important thing about security is to understand that security is a chain consisting of many components. Which
components to implement in the network depends on both which security threats to address and what is
considered the correct and balanced level of security for the network.
Physical security and upholding processes that support the organization's security policies are perhaps the most
important parts of the network security. Also important is the authorization of users, logging, firewalls, hardening
of unused ports and the use of secure protocols.
Dependence between different security measures needs to be considered to get the most implemented action.
For example, to get the most out of audit logging you are depending on good authorization and the opposite is
also true.
Security in a network also depends on the security of its constituent nodes. Remember that the overall security of
a network equals the security of the weakest node.

1.4 A formalized security model


Security is a process and not a state. It is about applying fit-to-purpose, cost-effective mechanisms at each point
in time throughout the process. A layered defense helps to mitigate the threats.

ABB AFS660 Deployment Guideline 5


INTRODUCTION
1
A formalized security model

To provide adequate security, one must be able to model and understand the communication infrastructure and
analyze threats to these assets. A three-plane architecture derived from ITU-T X.805 standard provides a useful
and simple way of capturing relevant information, see Figure 1. All the information and recommendations given in
this Deployment Guideline address one or several topics and dimensions of the model and aim making the device
hardened in the overall network context.

Figure 1 Security architecture model

The security architecture is separated into three security planes and every plane into three security layers. On
every security layer there are security services applied to mitigate threats. Policies and principles are steering the
architecture all the time. When the system is in operation, operational policies are adapted to the system
architecture. All these activities together are called "security architecture".

1.4.1 Security policies and principles


Security policy is a set of rules and practices that specify or regulate how a system or organization provides
security services to protect sensitive and critical system resources.
Principles are decisions, rules or good practices that are applied when designing systems or networks. ABB
solutions uses certain specific security principles and best practices as a basis for providing network protection.
One important principle is the "defense in depth" which calls for employment of security mechanisms in layers.
The defense in depth strategy is summed up by the term "Belt and Braces", that is, if one mechanism fails there
are other mechanisms remaining to provide adequate protection.
Another fundamental principle is the "least privilege" that states that entities is only given the privileges they need
to perform their tasks and that nodes do not run any unnecessary services.

6 AFS660 Deployment Guideline ABB


INTRODUCTION
A formalized security model

1.4.2 Security services


Security service is a fundamental concept in all security architectures. The service meets the security objectives
identified by the threat-and-risk analysis. Security services are implemented by means of security functions and
mechanisms. A confidentiality security service, for example, might be implemented using SNMPv3 with encryption
as the security function. This, in turn, makes use of encryption mechanisms. The eight most important security
services are the following:

 Accountability: Accountability procedures are used to keep track of who does what and when; it goes hand
in hand with Non-Repudiation providing evidence on who did what. Accountability functions track the usage of
security services and network resources. Accountability logs facilitate recovery and fault discovery.
 Authentication: Authentication is used to confirm the identities of communicating entities (person, device, ser-
vice or application) and ensures that the entities are not masquerading or attempting unauthorized replay of
previous communication.
 Authorization: Authorization protects against unauthorized use of network resources. Access control ensures
that solely authorized personnel or devices have access to network elements, stored information, information
flows, services and applications. The three security services Accountability, Authentication, and Authorization
are sometimes bundled together and abbreviated AAA.
 Availability: Availability means that authorized entities have access to network elements, stored information,
information flows, services and applications regardless of incidents that affect the network.
 Confidentiality: Confidentiality goes hand in hand with Privacy and entails protecting data from unauthorized
disclosure. Data confidentiality ensures that data content cannot be understood by unauthorized entities. En-
cryption, access control lists, and file permissions are methods frequently used to protect data confidentiality.
 Integrity: Integrity ensures the correctness or accuracy of data. The data is protected against unauthorized
modification, deletion, creation, and replication. Integrity features might also indicate unauthorized activities.

1.4.3 Security planes


Networks can be designed in such a way that events on one security plane are kept isolated from the other security
planes. This makes it possible to differentiate between security concerns and to address each independently.
The security planes are as follows:

 O&M Security Plane: The O&M security plane is concerned with the protection of operation and maintenance
functions of the network elements.
This document focuses specifically to this plane as AFS View is part of ABB’s overall Network Management
Suite.
 Signaling & Control Security Plane: The signaling and control security Plane protects activities that enable
the efficient delivery of information, services and applications across the network.
Examples belonging to this plane are routing or RST protocols.
 End-User Security Plane: End-user in this context can mean a person but also an application generating data-
flows. The end-user security plane manages subscriber access and use of the service across the utility net-
work.
An example belonging to this plane are AAA-related functions provided e.g. by Radius or LDAP.

ABB AFS660 Deployment Guideline 7


INTRODUCTION
1
A formalized security model

1.4.4 Security layers


Each security plane is divided into three different security layers. This layered defense strategy acknowledges that
each layer has different security threats and ensures that security mechanisms can be deployed in each layer.
The security layers are as follows:

 Infrastructure Security Layer: The infrastructure security layer is the fundamental building blocks of networks
services and applications. Examples of components that belong to the infrastructure layer are network ele-
ments and links between network elements and infrastructure they are located at.
 Network Services Security Layer: The network services security layer addresses network services provided
to end-users. These ranges from basic transport and connectivity to the service enablers necessary for provid-
ing network access.
 Applications Security Layer: The applications security layer covers network-based applications accessed by
the end-user, for example, voice applications, multimedia applications, and web-browsing.

8 AFS660 Deployment Guideline ABB


NETWORK DESIGN
Zones

2 Network design

2.1 Zones
The overall network architecture is not topic of this Product specific deployment guide. It has however to be noted
that improper configuration of a single network element may compromise the overall network zoning- and security
approach and may result in serious cyber risks.
Security zones must be protected by firewall, application proxies or in extreme cases by data-diodes. It is essential
that zones are properly documented including all assumptions reg. services, addressing-schemes and data flows
between the zones.
Network segmentation or creating security zones is required to minimize the impact when one zone is
compromised. One should distinguish …
 Geographical zones / physically segregated areas
(e.g. Control-Centers, Substations …)
 Logical zones
(applications / services with similar security requirements across the network)

Network design and maintenance is fully in customer's responsibility unless explicitly agreed otherwise in writing.

2.2 External communication (including remote access)


External1 connections to the operational network are one of the most critical entry points for possible attacks. It is
therefore important to limit the number of external connections to the absolute minimum. Access rights have to be
strictly controlled.
 External connections should go through a firewall or application proxy and if possible terminate at a terminal
service. Wherever external connections exists use a monitoring function, e.g. to log access or attempts of ac-
cess.
 Access from external connections shall be controlled. Users shall be authenticated on an individual basis, e.g.
every user should have its own username and password. Access control systems like SDM2, Radius or LDAP
based systems are recommended.
 If VPNs are used, careful consideration shall be taken to where the VPNs terminate. It is recommended that
VPNs are terminated as centralized service in conjunction with firewalls and application proxy. Contact ABB
for more information regarding the Remote Access Package (RAP) that enables secure internal and external
support services.

1. External shall mean connections to other security zones (e.g. Customer office network or even Internet)
2. DM = System Data Manager; for details about SDM for Communication Systems please contact your ABB
sales representative

ABB AFS660 Deployment Guideline 9


P R O D U C T R E L AT E D D E TA I L S
3
General aspects

3 Product related details

This chapter addresses the steps and measures to be taken to make best use of the security and hardening
functions of the Product by optimized configuration of management interfaces, user ports and services.

3.1 General aspects

3.1.1 Physical security


 Physically protected access to network devices to prevent tampering and replacement / exchange of device-
parts, or attaching further connections in an unauthorized way.
 If possible mount the network equipment in a safe place, e.g. in a lockable cabinet.
 To prevent unauthorized access, see also section 3.1.6 Device hardening.

3.1.2 Verify authenticity of obtained SW/FW distribution


During Product life cycle you may update/upgrade the equipment's SW resp. FW. The distribution means of such
code may vary over time. To verify the authenticity of the obtained code two methods exist, depending on the type
of FW or SW:
 The code is signed with an ABB-certificate that is based on a trusted certificate of a Certification Authority (CA)
such as Cybertrust or Verisign. This method is normally used for AFS View.
 The code is not signed due to technical restrictions but the authenticity can be verified by an associated hash-
value. Before loading a new firmware, the user can generate a SHA-256 hash and cross-check it against the
values published on the ABB-website.

Currently the second option is implemented for AFS660 products.

3.1.3 Define the Role - User mapping


A Role is describing a set of rights to perform certain actions e.g. management tasks on an equipment.
Each individual user who has access to the equipment needs one or several roles for his work. To minimize
operational risks, users should always use the lowest but still working privilege-level even they may have roles
with higher privileges than currently needed.
The following table describes Roles supported by Product:

10 AFS660 Deployment Guideline ABB


P R O D U C T R E L AT E D D E TA I L S
General aspects

Role Rights and Privileges Remark


Administrator The user is authorized to monitor and administer the All activities with read/write access, including the following activities
device reserved for an administrator:
 Add, modify or delete user accounts
 Activate, deactivate or unlock user accounts
 Change all passwords
 Configure password management
 Set or change system time
 Load files to the device, e.g. device configurations, certificates or
software images
 Reset settings and security-related settings to the state on delivery
 Configure the CAM server, RADIUS server and authentication lists
 Apply CLI scripts
 Switch CLI logging and SNMP logging on and off
 External memory activation and deactivation
 System monitor activation and deactivation
 Switch the services for the management access (e.g. SNMP) on
and off.
 Configure access restrictions to the user interfaces or the CLI
based on the IP addresses
Operator The user is authorized to monitor and configure the All activities with read/write access, with the exception of the above-
device - with the exception of security-related named activities, which are reserved for an administrator.
settings
Auditor The user is authorized to monitor the device and to Monitoring activities with read access
save the Audit Trail log file
Guest The user is authorized to monitor the device - with Monitoring activities with read access
the exception of security-related settings
Unauthorized No access to the device As an administrator you assign this access role to temporarily lock a
user account.
 The device assigns this access role to a user account if an error oc-
curs when assigning a different access role.

 For local users, only one role can be assigned to a user.


 When remote user authentication through Central Account Management (CAM), e.g. with SDM600, is used,
several roles can be assigned to one user
Users that log into the AFS660 shall consider the principle of "least privilege", i.e. they shall select the role with
only the necessary rights to perform a planned task.

3.1.4 Configuration for device management


Access to device management must be subject to user authentication and access must be limited according to
the least-privileges principle in order to avoid intentional or unintentional, malicious mal-configurations.
For the configuration of user accounts see [a]1
 Use secure protocols for device management:
 Avoid HTTP; use HTTPS.
 Avoid TELNET because password confidentiality is not given.
Use SSH higher than version 1 instead
 Use version 3 for SNMP with read only access and secure passwords. Change any default passwords.
 Where applicable use central user authentication to facilitate efficient and secure account handling (e.g.
SDM600 based approaches).
 Restrict management sessions
– Restrict management access to a defined number of entitled IP-addresses.
Refer to [b] for configuration details
– Make use of session time-out features if configurable.
Refer to [c] for configuration details.
– Restrict access after a number of invalid login attempts.
Refer to [a] for configuration details.

1.see section 5.2 for references

ABB AFS660 Deployment Guideline 11


P R O D U C T R E L AT E D D E TA I L S
3
General aspects

Note: Password handling & policy is essential for cyber security.


 The default passwords must be replaced with properly complex passwords.
 Possible password policies shall be applied (length, types of characters, expiration…).
 ABB passwords used for FAT/SAT must be changed by end-user organization.
 Default or preset accounts shall be replaced by personalized accounts.
 Anonymous access shall be disabled.

The Product provides following management access methods with possible roles:

3.1.4.1 General

An AFS660 in factory default has no IP address configured. Initial configuration of IP address can be done through
AFS Finder or through serial interface (CLI).
The management agent is assigned to a specific VLAN (i.e. the management VLAN). In factory default settings
this is VLAN 1. It is recommended to use separate VLANs for management traffic and for user traffic if possible
from the network design point of view.
The following users are defined in the factory default state. This is applicable for all the access methods further
explained below.

Login name Password Role


admin abbadmin Administrator
user abbuser Guest

AFS660 allows to enable / disable individual servers for management access (see more information below).

3.1.4.2 Access with AFS Finder

AFS Finder is typically used for initial configuration of AFS660 during commissioning, when the device is still in
factory default configuration. The following parameters can be set with AFS Finder:

 IP address of management agent (incl. netmask)


 IP address of the default gateway
 System Name

No password is required to access the switch with AFS Finder.


It is recommended to disable the AFS Finder protocol on the AFS660, or set to read-only after the initial
configuration. Refer to [d] for configuration details.

12 AFS660 Deployment Guideline ABB


P R O D U C T R E L AT E D D E TA I L S
General aspects

This method needs following open logical ports:

Port Protocol Service Remark


none none

3.1.4.3 Access with Web Browser (through local LAN port or remotely)

Graphical User Interface is available with a web browser interface (e.g. Internet Explorer, Firefox). Two methods
can be used:

 HTTP:
Unsecure connection between browser / management computer and switch. It is recommended to disable the
HTTP server on the AFS660 and thus block the unsecure browser access. Refer to [e] for configuration details.
 HTTPS:
Secure connection between browser / management computer and switch. A digital certificate is required for the
encryption of the HTTP connection. In factory default configuration the switch configuration includes a self-
signed certificate for HTTPS access. The device allows you to create a new certificate yourself (through user
interface) or to load an existing secure certificate onto the device. The latter is the preferred option. Refer to [f]
for configuration details.

This method needs following open logical ports:

Port Protocol Service Remark


80 HTTP unsecure browser access
443 HTTPS secure browser access

ABB AFS660 Deployment Guideline 13


P R O D U C T R E L AT E D D E TA I L S
3
General aspects

3.1.4.4 Access with Command Line Interface through IP connection (local or remote)

Two methods can be used for CLI interface through IP connection:

 TELNET:
Unsecure connection between terminal software (e.g. PUTTY) on management computer and switch. It is rec-
ommended to disable the TELNET server on the AFS660 and thus block the unsecure CLI access. Refer to [g]
for configuration details.
 SSH:
Secure connection between terminal software (e.g. PUTTY) on management computer and switch. AFS660
only supports SSHv2 (less secure version 1 of the protocol is not supported). A digital certificate is required for
the encryption of the SSH connection. In factory default configuration the switch configuration includes a self-
signed certificate for SSH access. The device allows you to create a new certificate yourself (through user in-
terface) or to load an existing secure certificate onto the device. The latter is the preferred option. Refer to [h]
for configuration details.

Port Protocol Service Remark


22 SSH v2 Secure Shell
23 TELNET Telnet

3.1.4.5 Access with Command Line Interface through serial interface (console port)

For this access, physical access to the equipment is required (i.e. physical security measures shall prevent
unauthorized access to the device). A laptop is connected to the console port on the AFS660 and uses RS232
protocol. Access to all monitoring and configuration functions is provided through command line interface.
The communication itself is not protected and cannot be disabled. For user authentication the same mechanisms
are used as for the other access options (protected by user name and password).
After a power-up of the equipment it is possible to enter 'System Monitor 1' through the serial interface which is
the boot menu. The 'System Monitor 1' offers the following possibilities:

 Managing the operating system and verifying the software image


 Updating the operating system
 Starting the operating system
 Deleting configuration profiles, resetting the device to the factory defaults

14 AFS660 Deployment Guideline ABB


P R O D U C T R E L AT E D D E TA I L S
General aspects

 Checking boot code information

System Monitor 1 can be used to recover from any unexpected behavior of firmware or configuration. (e.g.
misconfiguration) by setting back the equipment to factory default or a specific firmware. Refer to [i] for details.

The 'System Monitor 1' can be disabled through the user interface (GUI or CLI) which prevents unauthorized
access to it. However this also eliminates the recovery functionality mentioned above. In worst case a switch may
have to be sent back to factory to perform recovery actions. Refer to [j] for configuration details.

Port Protocol Service Remark


none none

3.1.4.6 Access with AFS View-CT Craft Terminal

AFS View-CT is a standalone software package that offers a controlled Java environment to access the AFS660
products.
For access to the switches, the AFS View-CT does not provide new functionalities, but it will use the functionality
and security measures as described above in sections 3.1.4.3 to 3.1.4.5.

3.1.4.7 Access with AFS View Network Management System

AFS View is a network management software with a graphical overview of a complete AFS network.

AFS View uses SNMP protocol to monitor and access the switches. Per default SNMPv3 with MD5 Authentication
and DES Encryption is used.

 Do NOT to use the following:


 SNMPv1
 SNMPv3 without authentication or encryption protocols
Refer to [a] for details about SNMPv3 configuration on AFS660.

ABB AFS660 Deployment Guideline 15


P R O D U C T R E L AT E D D E TA I L S
3
General aspects

 Disable the SNMPv1 and v2 servers on the AFS660.


Refer to [k] for configuration details.

Port Protocol Service Remark


161 SNMP SNMPv1/2/3 agent

3.1.4.8 Access with other SNMP Manager software

It is possible to access the AFS660 switch with any SNMP based manager software. SNMPv3 shall be used as
described in section 3.1.4.7.
 To prevent the access to the switch through unsecure SNMPv1 or v2, disable the corresponding servers on
the AFS660.
Refer to [k] for configuration details.

Port Protocol Service Remark


161 SNMP SNMPv1/2/3 agent

3.1.5 Additional product specific features

3.1.5.1 Monitoring security status

AFS660 allows to monitor the security status of the device. The following settings can be supervised:

 Password default settings unchanged


 Minimum Password Length < 8y
 Password Policy settings deactivated
 User account password Policy Check deactivated
 Telnet server active
 HTTP server active
 SNMP unencrypted
 Access to System Monitor with V.24 possible
 Saving the Configuration Profile on the External Memory possible
 Link interrupted on enabled device ports
 Write access using AFS Finder possible
 Load unencrypted config from external memory
 IEC61850-MMS active

 Activate the security status monitoring for the parameters which are applicable in your setup.
The device status will show an alarm on the device, in AFS View and can also send traps to any SNMP trap
receiver.

Refer to [l] for configuration details.

16 AFS660 Deployment Guideline ABB


P R O D U C T R E L AT E D D E TA I L S
General aspects

3.1.5.2 External storage CRA-SD

An AFS660 can optionally be equipped with SD based external storage medium, the CRA-SD.

The CRA-SD can be used to:


 Keep persistent log files (System Log) - see also section 3.1.7.1.
 Keep a copy of the equipment configuration.
 If a CRA-SD is permanently mounted, enable the auto-save function (see screenshot below).
 If the configuration is stored on external storage, activate the configuration encryption in AFS660.
Refer to [r] for configuration details.
 Do automatic software updates.
If you want to prevent automatic software updates through external storage, this function can be disabled (see
screen shot below)

3.1.6 Device hardening


The Product offers a wide range of functionalities that are possibly not used/required in all configurations and for
applications. To reach the utmost cyber security level under given operational needs take following hardening
measures:

ABB AFS660 Deployment Guideline 17


P R O D U C T R E L AT E D D E TA I L S
3
General aspects

3.1.6.1 Disable all unused physical ports

 Disable all unused physical ports in such a way, that they can only be enabled by authorized staff (either locally
or remotely).
Refer to [m] for configuration details.

3.1.6.2 Disable / close all unused logical ports and disable all unused services and
protocols

It is possible to disable the management servers (i.e. services) for unused access methods (e.g. Telnet). Refer to
section 3.1.4 for details.

3.1.6.3 Enable port security

 Disable all services and protocols not required for standard operation.

AFS660 offers port security functionality on all ports. The feature can be activated on one, several or all ports of
the switch, depending on project requirements.

On a port, access can be limited to one or several host with predefined settings for VLAN and MAC address.

Refer to [n] for configuration details.

3.1.7 Logging
Complete and accurate logs are crucial to monitor the security of a system. In case of a security incident log files
provide information to better understand details of the incident.

By default network devices might not log all necessary events and badly configured log services do not provide
the information needed.

AFS660 gives you a convenient approach to configuring security-relevant settings.


At least both failed and granted logon attempts shall be logged.

18 AFS660 Deployment Guideline ABB


P R O D U C T R E L AT E D D E TA I L S
General aspects

3.1.7.1 Local logging

The AFS660 creates the following local log-files:


 System Log:
The device logs important device-internal events in the system log file.
Optionally the logging of SNMP GET and/or SET commands and the commands entered on CLI interfaces (e.g.
SSH) can be logged.
The log file is kept until a restart is performed on the device. After the restart the device creates a new empty
file again.
 Audit Trail:
The device logs system event and writing user actions on the device. This gives the option of following WHO
changes WHAT on the device WHEN.
The device logs the following user actions, among others:
– A user logging on via CLI (local or remote)
– A user logging off manually event.
– Automatic logging off of a user in CLI after a specified period of inactivity
– Device restart
– Locking of a user account due to too many failed logon attempts
– Locking of the management access due to failed logon attempts
– Commands executed in CLI, apart from show commands
– Changes to configuration variables
– Changes to the system time
– File transfer operations, including firmware updates
– Configuration changes via AFS Finder
– Firmware updates and automatic configuration of the device via the external memory
– Opening and closing of SNMP via an HTTPS tunnel
The logged entries are write-protected and remain saved in the device after a restart.
 It also possible to output system messages (log information) on the console port. This feature has to be acti-
vated and the minimum severity level for the messages to be defined.

Persistent Logging of System Log:


The device allows you to save log entries permanently in a file on the external memory (CRA-SD). Therefore, even
after the device is restarted you have access to the log entries.
You can limit the size of the log file and specify the minimum severity for the events to be saved.
If the log file attains the specified size, the device archives this file on the CRA-SD and saves the following log
entries in a newly created file.

Refer to [o] for configuration details.

ABB AFS660 Deployment Guideline 19


P R O D U C T R E L AT E D D E TA I L S
3
General aspects

3.1.7.2 Remote logging

If a Syslog server is present in your network, forward AFS660 system events to the Syslog server.
The AFS660 allows to send messages to up to 8 syslog servers. For each server the following can be configured:
 Type of events to be sent: From System Log and/or from Audit Trail
 Minimum severity of events to be sent to syslog server. Examples for severity:
– If it is sufficient to send messages for failed login attempts, the severity can be set to 'warning'.
– If also successful logins or logouts shall be forwarded to syslog server the severity must be set to 'notice'
(preferred option).

Refer to [p] for configuration details.

3.1.8 Patches / Updates


Not properly patched / updated systems may bear security risks.
 Keep the communication- & IT - infrastructure up to date.
 Ask your ABB representative for support in case of doubts.

Even if flawless patching / updating is the normal case for ABB solutions it's recommended to make a backup of
the device configuration for the rare case of issues (see following clause).

20 AFS660 Deployment Guideline ABB


P R O D U C T R E L AT E D D E TA I L S
General aspects

3.1.9 Backup / Recovery


Accurate backups are needed to be able to recover a system after an incident quickly. An incident might e.g. be
a security attack or an unintentional misconfiguration that cannot be undone. They might also be useful to prove
the state of a system upon delivery.
Device configuration should be saved and stored safely. These configuration files must be used to recover in case
of device malfunction and replacement but also in case a device is compromised.

Note:
 Make a backup of the complete device configuration after initial commissioning.
 Make configurations backups based on a scheduled scheme; recommended cycle depends on frequency
and extend of changes in the network
 Make always a backup before you apply patched & updates

On AFS660 a configuration backup can be stored as follows:


 Locally in the non-volatile memory of the switch
 On a remote server or laptop
 On the external storage of the switch (CRA-SD)
If the CRA-SD is equipped permanently to the AFS660, a copy of the configuration will also be stored on the
CRA-SD every time the configuration is saved on the device. See also section 3.1.5.2.

Refer to [r] for configuration details.

3.1.10 Time synchronization


For sequence of events, all systems including network devices must run at the same time, therefore an external
time server is advised.

 Configure devices to accept time events from dedicated time servers only.
 Avoid broadcast based time-info.

For configuration refer to [q].

ABB AFS660 Deployment Guideline 21


AFS VIEW-CT
4
Purpose and usage

4 AFS View-CT

4.1 Purpose and usage


To configure the Product and to verify the setup and proper operation of it, a dedicated software is provided (in
addition of the possibility to use Web-Browser access). It's called AFS View-CT and is further referred as Craft-
tool (CT). Within the various levels of management functionalities for communication networks it is positioned as
'Element Manager' typically connecting to one network device at the time.

The CT runs on any state of the art Windows-based computer / laptop; recommended is to use:

 Windows 7 (32 or 64 bit)

The CT is mostly installed on computers of deployment- and maintenance-personal. It's their IT-departments
responsibility to setup and operate the computer in a secure way.

Selected key aspects (non exhaustive) to be considered are:

 Restrict / control boot options


 User handling / accounts / roles
 Password policy
 Patch management
 Anti-virus
 Firewall
 Hardening (e.g. restricted usage of external media like USB-sticks and Internet access)
 Logging
 Removing unused programs
 Backup and recovery

For more information, please also consult e.g. 'Microsoft Security Guidance' available on the Internet.

4.2 Secure setup and operation of CT


For the basic setup and operation of the CT see [7]. Below clauses address only the most important security
related aspects of CT.

4.2.1 Rights
AFS View-CT does not require any installation. The following is possible:

 Copy all necessary files to the maintenance computer and start the executable.
 In this setup make sure that the executable is only accessible by authorized users on the laptop, do not copy
the files to public folders

AFS View-CT does not require admin rights on the computer.

22 AFS660 Deployment Guideline ABB


AFS VIEW-CT
Secure setup and operation of CT

4.2.2 User accounts


AFS View-CT does not offer any user accounts or user logins. User Authentication and access control shall be
performed on:

 Operating system of the computer where AFS View-CT is installed


 On the network elements which can be reached from AFS View-CT

Systems/applications that provide user authentication and access control should be configured according to the
least-privilege principle. If a user has more roles, separate accounts should be made for each role. This user
should only use elevated roles when needed, not by default.

4.2.3 Logging
AFS View-CT itself does not offer any logging functionality. For monitoring and logging purposes use the
functionality of the network elements (see relevant sections in this document).

4.2.4 Secure communications


AFS View-CT offers the possibility to access the devices by unsecure (HTTP, TELNET) or secure (HTTPS, SSH)
protocols, depending on the capabilities and configuration of the connected devices. As elaborated in other
sections of these deployment guidelines, network elements shall always be configured to only use secure
protocols for management communication. This implies that also on the AFS View-CT the operator shall only use
secure protocols.

For using HTTPS, enter the IP address of a device including the protocol information e.g. "https://192.168.1.1".
For using SSH, enter the IP address of the device and click on the corresponding SSH icon in the GUI.

The AFS View-CT does not offer the possibility to disable unsecure protocols, this shall be done on device level.

4.2.5 Firewall and virus-checker

If your computer is connected to the device through a firewall, enter rules in the firewall that allow the data traffic
through following ports:

 UDP/161 SNMP
 TCP/443 HTTPS (for access with GUI)
 TCP/22 SSH (for access with CLI)

(Ports for unsecure protocols HTTP and Telnet are not listed here.)

No interference with virus checkers is known.

ABB AFS660 Deployment Guideline 23


AFS VIEW-CT
4
Secure setup and operation of CT

4.2.6 Patches / Updates

Always make sure that the operating system is up to date with necessary security patches and updates.

Unpatched applications and services represent one of the biggest security vulnerability.

Make sure that you use the latest available release of AFS View-CT.

24 AFS660 Deployment Guideline ABB


BIBLIOGRAPHY / REFERENCED DOCUMENTS
Product manuals

5 Bibliography / Referenced documents

5.1 Product manuals

Rev. Document
[1] AFS660-S/AFS665-S, Reference Manual, Graphical User Interface
1KHD652009 / Revision May 2014
[2] AFS660-B/AFS665-B, Reference Manual, Graphical User Interface
1KHD653881 / Revision May 2014
[3] AFS660-C, Reference Manual, Graphical User Interface
1KHD653886 / Revision May 2014
[4] AFS660-S/AFS665-S, User Manual, Basic Configuration
1KHD652010 / Revision May 2014
[5] AFS660-B/AFS665-B, User Manual, Basic Configuration
1KHD653882 / Revision May 2014
[6] AFS660-C, User Manual, Basic Configuration
1KHD653887 / Revision May 2014
[7] AFS View-CT GUI Application
1KHD653905 / Revision June 2015

5.2 Section references


For each reference used in the document, the following table indicates in which section of the relevant product
manual the topic is covered (Exact manual reference can be found in section 4.1).

Rev. Manual title Chapter in Chapter in Chapter in


AFS660-S manual AFS660-B manual AFS660-C manual
[a] Graphical User Interface / User Management 3.1 3.1 3.1
[b] Graphical User Interface / IP Access Restriction 3.6 3.6 3.6
[c] Graphical User Interface / Session Timeouts 3.7 & 3.8 3.7 & 3.8 3.7 & 3.8
[d] Graphical User Interface / AFS Finder Protocol 1.2 1.2 1.2
[e] Graphical User Interface / Server - HTTP 3.5.4 3.5.4 3.5.4
[f] Graphical User Interface / Server - HTTPS 3.5.5 3.5.5 3.5.5
[g] Graphical User Interface / Server - TELNET 3.5.3 3.5.3 3.5.3
[h] Graphical User Interface / Server - SSH 3.5.6 3.5.6 3.5.6
[i] Basic Configuration / System Monitor 1.3 1.3 1.3
[j] Graphical User Interface / Self Test (System Monitor) 6.14 6.14 6.14
[k] Graphical User Interface / Server - SNMP 3.5.2 3.5.2 3.5.2
[l] Graphical User Interface / Security Status 6.3 6.3 6.3
[m] Graphical User Interface / Port Settings 1.6 1.6 1.6
[n] Graphical User Interface / Port Security 4.1 4.1 4.1
[o] Graphical User Interface / Reports 6.25 - 6.29 6.25 - 6.29 6.24 - 6.28
[p] Graphical User Interface / Syslog 6.15 6.15 6.15
[q] Graphical User Interface / Time 2 2 2
[r] Graphical User Interface / Load-Save 1.4 1.4 1.4

ABB AFS660 Deployment Guideline 25


D O C U M E N T H I S TO RY
6
Section references

6 Document history

Rev. Chapter Description Date / Dep. / Name


01 All Initial Product Deployment Guideline AFS660 Aug. 2015 / SHZ
02 4 Chapter 4 Craft-tool added July 2016 / SHZ

26 AFS660 Deployment Guideline ABB


Contact us

ABB Switzerland Ltd

1KHD653907 © Copyright 2016 ABB. All rights reserved.


Power Grids
Bruggerstr. 72
CH-5400 Baden, Switzerland
Tel.: +41 58 589 37 35
(Customer Contact Center)
E-Mail: communication.networks@ch.abb.com

www.abb.com/communicationnetworks

Vous aimerez peut-être aussi