WG 15 Protocol Security

1
WG 15 Protocol Security

• Herb Falk Convener
• Frances Cleveland

2
Original Security Concerns (Top 10)
3
Types of Security Vulnerabilities for
Operational Systems

• Protocol Security Scope of WG15 Protocol
  security vulnerabilities can generally be
  countered with encryption
• End-to-End Security
• Media The threats to utility telecommunications
  media are most likely to come from industrial
  espionage, where experts in utility RTU protocols
  could be hired to eavesdrop on data or even
  disrupt operations.
• Databases Databases are vulnerable not only to
  malicious attacks, but more likely to
  carelessness, indiscretions, poor validation and
  testing, and inadequate design of data exchanges.
• Applications Inadequate design and testing of
  applications could lead to false reliance on
  their results and cause power system reliability
  problems or invalid financial gains or losses.
• Should not rely on Security by Obscurity!!
  Physical separation is not adequate security.

4
What is in scope?
Interface to EMS Application
Typically Not Standardized
Interface To/From ICCP
ICCP Service Interface and Parameters
ICCP Protocol
OSI Upper Layer Protocols
Possible Solution Areas
OSI Transport
RFC-1006
OSI Network
TCP/IP
Provided By OS
5
Recommendation to WG15 Members for TASE.2
Protocol Security

• The public key infrastructure (PKI) encryption
  mechanism of SSL/TLS should be inserted at the
  transport layer for use during the association
  process, while secret key encryption would be
  used during normal traffic.
• Currently, this method is probably practical only
  for control center systems or high-performance
  field devices, where the performance and resource
  impact of SSL/TLS would not be cost-prohibitive.
• However, as embedded chips with security built
  into the protocols become more prevalent and more
  cost-effective, this technology could be used on
  media-constrained and/or compute-constrained
  field devices as well.
• Secret key encryption adds about 10 to the data
  load

6
Status

• Developed Security Requirements for IEC 60870-6
  TASE.2
• WG 15 Vote
• 16 members only 6 voted
• Yes 3 active members
• No 2 active members
• Abstain 1 corresponding member
• Vote Failed

7
Comments and Issues

• Comments
• Needs increase in scope to cover end-to-end
  security rather than just protocol security
• Not enough TASE.2 experience in WG 15
• Needs more discussion
• USA EPRI sponsored end-to-end security report

8
Security Concerns

Security Concerns

Priority
Non
-
Secure TASE.2 Profile
Entire Set of Secure TASE.2 Profile


Recommendations are Implemented


1

Bypassing Controls

Bypassing Controls

2

Integrity Violation

Indiscretion

3

Authorization Violation

Illegitimate Use

4

Indiscretion

Information Leakage

5

Intercept/Alter

Availability (e.g. Prevention of Denia
l of Service)

6

Illegitimate Use

Data Validity

7

Information Leakage

Performance

8

Spoof

Local Security Administration and Procedures

9

Masquerade

Remote Security Procedures

10

Availability (e.g. Prevention of Denial of
Service)

Certificate and Authent
ication Management

1
1

Eavesdropping (e.g. Data Confidentiality)

Certificate Authority Privacy and Security
Procedures


9
Suggested End-to-End Security for ICCP/IEC TASE.2

• TASE.2/ICCP should use
• SSL/TLS encryption for associations, and secret
  key encryption for normal data exchanges, as per
  IEC TC57 WG15 recommendations

• Bilateral Tables to limit access to data
• SNMP for management of communication networks
• Firewalls to limit access to the communication
  channels
• Virtual Private Networks (VPNs) as added security
• Backup of data, multiple sources of data,
  validity checking
• Intrusion detection countermeasures as backup
  security
• Control center security policies, with multiple
  levels of security that sag rather than break,
  should be strongly enforced. No technological
  measure can ensure security policies must be
  included.
• All security measures will break at some point.
  Assume that every safeguard will be compromised
  at some point or another, and establish secondary
  and even tertiary safeguards that may not totally
  prevent an attack but will at least give notice
  of an intrusion.

10
Suggested Security for UCA/IEC 61850

• Initial suggestions IEC 61850/UCA should use
• VPNs could be the primary security defense if
  encryption is too demanding of compute-constrained
  devices
• SSL/TLS and/or secret key encryption (eventually
  as per IEC TC57 WG15) for devices which can
  support the additional compute requirements

• Object models can constrain the access rights of
  different users, and can report attempted
  unauthorized access
• SNMP for management of communication networks
• Backup of data
• Intrusion detection countermeasures as backup
  security
• Control center security policies, with multiple
  levels of security that sag rather than break,
  should be strongly enforced.

11
Suggested Security for DNP (IEC 60870-5??)

• Initial suggestions DNP should use
• VPNs could be the primary security defense if
  encryption is too demanding of compute-constrained
  devices
• SSL/TLS and/or secret key encryption for devices
  which can support the additional compute
  requirements
• SNMP for management of communication networks
• Backup of data

• Intrusion detection countermeasures as backup
  security
• Control center security policies, with multiple
  levels of security that sag rather than break,
  should be strongly enforced.

12
Security and the IEC?

• How should end-to-end security be handled?
• What should the scope of WG 15 be?
• Ignore end-to-end issues and remain protocol
  security only?
• Expanded to cover end-to-end security?
• Other?