Ten Steps to transaction security v0r3 by G7TLu5x

VIEWS: 5 PAGES: 16

									Ten steps to transaction security




       Ten steps to transaction security in the
              European energy sector


 Guidelines for market participants using external PKI-
                   service providers




                                    Status:            Request for comments
                                    Version/release:   0.3
                                    Revision:          none
                                    Date:              July 14, 2012




ebIX                                                                    May 16, 2006
Ten steps to transaction security                                                                                                                    2


                                                              CONTENTS

0      MANAGEMENT SUMMARY .................................................................................................... 3
    0.1       BACKGROUND ......................................................................................................................... 3
    0.2       KEY RECOMMENDATIONS ........................................................................................................ 3
1      INTRODUCTION ......................................................................................................................... 4
    1.1       ABOUT THIS DOCUMENT .......................................................................................................... 4
    1.2       SCOPE OF PROJECT ................................................................................................................... 4
    1.3       PARTICIPANTS IN THE PROJECT ............................................................................................... 4
    1.4       REFERENCES ............................................................................................................................ 5
    1.5       CHANGE LOG ........................................................................................................................... 5
2      SECURE ELECTRONIC BUSINESS TRANSACTIONS ........................................................ 6
    2.1       THE GOALS OF SECURITY ......................................................................................................... 6
    2.2       AIM OF THIS DOCUMENT .......................................................................................................... 6
3      TEN STEPS TOWARDS SECURED TRANSACTIONS ......................................................... 7
    3.1   DEVELOP AN UNDERSTANDING FOR SECURITY ....................................................................... 7
    3.2   DEFINE THE CERTIFICATION AUTHORITY ............................................................................... 8
    3.3   SET UP OR SELECT A REGISTRATION AUTHORITY ................................................................... 8
    3.4   SET UP A DIRECTORY SERVICE................................................................................................. 8
    3.5   MAINTAIN DATA QUALITY....................................................................................................... 9
    3.6   DEFINE OPERATING PROCESS IN A PKI .................................................................................. 10
    3.7   SET UP CERTIFICATION PRACTICE STATEMENT AND CERTIFICATE POLICY IN ACCORDANCE
    WITH EBIX-CP ................................................................................................................................... 10
    3.8   ARCHIVING ............................................................................................................................ 11
    3.9   SECURITY IN ELECTRONIC DATA INTERCHANGE ................................................................... 11
    3.10 OTHER FIELDS OF APPLICATION AND USERS.......................................................................... 13
APPENDIX A                   SAMPLE PROCESSES ...................................................................................... 14
    A.1       ISSUING A NEW CERTIFICATE ................................................................................................. 15
    A.2       REPLACING A DEFECTIVE CERTIFICATE ................................................................................. 16




ebIX                                                                                                                            May 16, 2006
Ten steps to transaction security                                                                       3


0 MANAGEMENT SUMMARY
This document is the fourth in a series of publications from the ebIX project “DigSig” regarding the
use of encryption and digital signatures within the European energy sector. Being defined in a general
manner, the organizational parts aim at ensuring a uniform organizational security level with regard to
electronic signature and encryption of transactions between market participants across company
boundaries.

The technical parts of the documents, defined as well in a general manner, are to ensure interoper-
ability at a technical level even where different products or services are utilized. The political,
organizational and technical statements represent recommendations which are to enable a reliable
trustworthy infrastructure to be set up among market participants along the lines of solidarity.

These measures shall serve as a guide for implementation within companies and for subsequent
application at market interfaces. However, procedures other than proposed in the recommendations
need to be justifiable and must not impair the general level of security.

For economic reasons, market participants should be interested in making sure that the infrastructure
of confidence is not undermined. This is the only way to guarantee secure handling of electronic
business in the medium term, and to ensure that further automation steps can be managed in the light
of future developments.

0.1     Background

This document has been produced in response to requests for a quick-route description of the first
steps that are to be undertaken, when implementing the organizational and technical infrastructure
required for securing electronic business transaction – “secure” in terms of confidentiality and
liability.

0.2     Key recommendations

The key recommendations in this document define the first requirements in these ten broad areas,
which are elaborated in the main text of this document:

     Develop an understanding for security within the organisation or sector
     Define the certification authority
     Set up or select a registration authority
     Set up a directory service to
     Maintain data quality
     Define operating process within a PKI
     Set up certification practice statement and certificate policy in accordance with ebIX-CP
     Define recommendations and procedures for archiving, especially to cover legal requirements
     Define legal framework for security in electronic data interchange
     Consider other fields of application and users




ebIX                                                                                    May 16, 2006
Ten steps to transaction security                                                                          4


1 INTRODUCTION
1.1    About this document

Within the European energy sector, electronic data interchange (EDI) using a variety of methods has
become a core business enabler over the last few years. It is no longer possible to imagine how
liberalised energy markets would function without EDI; rapid and automatic interchange and
processing of business transactions, as far as possible without human intervention, is organisationally
and economically necessary for all participants at all levels. Whether the transactions contain metering
data, invoices, customer switching information or schedules: automation brings benefits through
process optimisation. Nevertheless, there are further, fundamental considerations – political,
organisational and technical – to bear in mind, which influence implementation.

Core processes with a high-volume character require supporting processes within the organisation.
Securing EDI transactions is one such supporting process, especially in connection with transparency
and integrity of the data involved. Just as a signature gives a piece of paper legal character – e. g. from
an offer to a contract – EDI requires the same legal status for security and non-repudiation. To this
end, it is essential that a secure business partner network be established, within which electronic
business transactions for all participants are made possible. Therefore we need to promote an
infrastructure which can be trusted both by larger corporations (with their own certification
authorities) and smaller companies (who buy-in from service providers).

This can only be guaranteed by verification and confidentiality mechanisms directly associated with
the information exchanged. These mechanisms need to cover the whole range of the logical
transactions consistently. This is necessary to be able to carry out transactions in the new deregulated
market between market participants in a legally correct and clear-cut manner in terms of liability law,
and not least in an inexpensive way under technical and organisational aspects.

1.2    Scope of project

In the light of these requirements, a small project (“DigSig”) was established within the ebIX structure
to generate appropriate documentation which can then be used as a basis for implementation scenarios
on a national and/or international level. The intention is to describe the overall harmonisation
requirements for the use of encryption and digital signatures for electronic transactions within the
European energy sector; also being compatible with the following overall ebIX objectives:

1) Make recommendations of common procedures that facilitate the common open European energy
   market
2) Make common standards for secure data interchange that can automate the process to reduce the
   costs for the parties involved.

1.3    Participants in the project

The project is based on documents produced within the German national group (under the able
tutoring of Dr. Willi Kafitz, Siemens AG, Frankfurt) and has been coordinated for ebIX by Carl W.
Major. The following participants provided intellectual and/or financial support to the project:




ebIX                                                                                       May 16, 2006
Ten steps to transaction security                                                            5



Country         Name                                       Company
DE              Carl W. Major                              E.ON Netz
DE              Dr. Konstantin Staschus                    VDN
DK              Erik Hartwell                              Energinet.dk
BE              Hugo Dekeyser                              Eandis
SE              Joachim Abrahmsén                          Steria
NL              Lodewijk ter Haar                          Tennet
FI              Matti Vasara                               Fingrid
NO              Per M. Breistein                           Statkraft
NO              Ole Jacob Høyland                          Statnett
SE              Oscar Ludwigs                              Svenska Kraftnät
SE              Robert Lundin                              Steria
CH              Rudolf Baumann                             ETRANS

1.4     References

[1] Original project proposal, see http://www.ebix.org/

1.5     Change log

 Ver.    Rel.   Rev.   Date               Changes
 0       1      none   2005-12-07         Document generated
 0       1      A      2006-01-13         Textual corrections
 0       1      B      2006-01-16         Diagrams added
 0       2      none   2006-02-28         Comments incorporated
 0       3      none   2006-05-16         Publication as ebIX RFC




ebIX                                                                          May 16, 2006
Ten steps to transaction security                                                                         6


2 SECURE ELECTRONIC BUSINESS TRANSACTIONS
2.1    The goals of security

In view of the trend towards transmitting master data, metered data, invoices and advice notes over the
Internet, there is a real need for action with regard to information security. In recent years, the quality
of service provided by the Internet has increased to such an extent that it now meets the requirements
of the electricity industry. Transmissions simply need to be secure.

We cannot accept the argument that little damage has been caused to date. Isolated breakdowns or
incidents of misuse can be overcome. However, if cross-company electronic data interchange
continues to become more automated so as to assume the character of sector-wide e-business, security
measures will need to ensure that further digitization of business processes does not cause additional
problems for companies involved in data exchange. Since manual checks are becoming increasingly
rare, this is the only way to ensure that further rationalization can be kept manageable.

These recommendations do not insist on a corporate PKI, but merely that the relevant organizational
and technical measures are in place in cases where electronic data is exchanged between market
participants.

Rules are already in place, e.g. in electronic invoicing or formal contracts. We wish to recommend
cost-effective technical solutions for providing organizational security in areas where there are no
legal guidelines. Before data can be exchanged via Electronic Data Interchange (EDI), a bilateral EDI
contract should be signed. A specimen is provided with EU recommendation 94/820/EG. In the
contract annexes, market participants simply need to make reference to the association’s
recommendations. With regard to interoperability these include, for example, the market interfaces in
UN/EDIFACT format; and for security, these recommendations apply.

The technical reference is the ISIS-MTT standard with a few intentional simplifications to facilitate
the broadest possible user base. The simplifications (e.g. dispensation with umlauts, UTF-7 coding,
etc.) can be removed if a standard procedure and standard products are the general rule on the market.

2.2    Aim of this document

The setting up, introduction and day-to-day operation of a Public Key Infrastructure (PKI) within a
company has often turned out to be a troublesome undertaking. Although many welcome IT security
measures in principle, they are discouraged by PKI terminology and technology. PKI is an
infrastructural measure, just like the telephone or e-mail. One application is usually not enough to
achieve a positive business case. Only multiple applications are worthwhile. A company must
therefore make PKI a strategic necessity and budget for the medium-term, i.e. over three years. This
will result in both security and economic benefits.

The present document aims to make clear to market participants of all sizes that it is of economic
importance, legally advantageous and technically/organizationally unproblematic for them to accept
and practice the PKI security measures offered by communications partners as recommended by the
DigSig project. Many topics have already been addressed in the papers that have already been
published. This document is intended as a set of guidelines to outline the steps towards “Secured
transactions”.




ebIX                                                                                       May 16, 2006
Ten steps to transaction security                                                                              7



3 TEN STEPS TOWARDS SECURED TRANSACTIONS
3.1     Develop an understanding for security

As business continues to evolve, an understanding of how business and its actual transaction can be
protected also needs to evolve. This applies to all fields of business and business transactions –
regardless of whether they are in finance, workflow management or infrastructure.

In all the areas mentioned above, external events have to be increasingly responded to in real time:
reorganization, process adjustments, the operation of risk management and the adapting of
infrastructure to business requirements are all becoming faster as technology advances.

Risk management considerations now extend beyond the confines of financing and the raising of
capital. As part of the so-called “Basel II” guidelines, which are currently being drawn up at an
international level, enhanced risk management measures are being discussed in terms of company
appraisal. With regard to the minimum capital requirements that banks expect from companies, these
are reflected in the three pillars: credit risk, market risk and operational risk, and are therefore clearly
more flexible than was previously the case. Using the coined expression “operational risks” the risk
term is for the first time being applied in contexts that also include infrastructure.

With regard to operational risks in particular, consideration is being given to the fact that IT
infrastructures are increasingly being categorized as business-critical.

Disruptions caused by events relating to IT security also lead to considerable damage.

The growing level of automation can also result shortcomings taking longer to be detected. It might
well be possible to get over isolated incidents, but the sum of all incidents or the duration of an
individual fault can be business-critical.

Companies and authorities are increasingly addressing such problems with organizational measures.
These include:

     Appropriate guidelines and monitoring (governance)
     Anchoring of information security in the organizational structure
     Internal or external services, such as virus competency, protection against infiltration into the
      computer network
     Prevention and inventory measures in rapidly changing networks

There is also the fact that all employees and managers, even those who are nothing more than users of
the IT infrastructure, should understand the risks and be responsible for their prevention (awareness).

With regard to electronic data interchange, i.e. external communication usually over public networks,
both users and those responsible for IT should develop a basic understanding that business data
fundamentally needs to be protected. Encryption takes care of confidentiality; digital signatures
safeguard authenticity of origin and integrity of content. The VDEW project “VEDIS” aims to
introduce encryption and electronic signatures such as those described in the ISIS-MTT standard, as
cryptographic, certificate-based security mechanisms.

An understanding of these protection measures cannot, however, be decreed “from above”. Despite the
existence of necessary disciplinary guidelines, the successful implementation of IT security goals will
for the foreseeable future also depend on the cooperation of employees. Moreover, IT security will
always contain strict organizational aspects and never be achieved by technology alone. This applies
in particular to the PKI and its operation processes.


ebIX                                                                                         May 16, 2006
Ten steps to transaction security                                                                           8



Purely technical approaches can therefore be highly problematic and be counter-productive in
achieving the original goals.

A combination of appropriate security awareness, sensible organization and technical facilities are the
main prerequisites for the successful introduction of a PKI.

3.2    Define the Certification Authority

Encryption and digital signatures, as intended by the DigSig project, use asymmetric cryptology
procedures. Asymmetric cryptology is based on key pairs, a public key and a private key.

A certificate in this context verifies that the public key belongs to the key owner. It is issued by a
certification authority (electronically signed), which the communication partners must recognize and
accept as a trusted third-party. A certificate must be published – at least in the closed user group that
wishes to use it for achieving secure communication connections. Although not an absolute technical
requirement, we recommend separate key pairs for encryption, authentication and digital signatures.
This ensures that the encryption key can be kept within the company to enable encrypted information
to be accessed if necessary (key backup). Authentication can also take place without entering a PIN, as
the digital signature represents a personal declaration of intent and the person signing should be the
only one authorized to dispose of the key. This is reason why the signature key should at least not be
used for encryption purposes.

In order to give digital signatures the same status as hand-written signatures under civil law and
administrative law, the German Signatures Act for example makes high demands of this overall
process. The result is that many documents can now be legally valid in electronic form. One of the
conditions of use is a so-called qualified certificate and a secure signature creation device.

We do not explicitly recommend qualified signatures if they are not prescribed by law, but naturally
does permit them as a high-level security standard.

3.3    Set up or select a Registration Authority

Registration is understood to mean the positive identification of the key owner before the completion
of the certification process. It is also primarily an organizational element aimed at excluding any
attempts at misuse.

If only a small number of certificates are required, the standard procedures of the CSP can be applied.

In the case of large companies that need to register many employees, it makes sense to set up one or
more local registration authorities (LRA). The department responsible for issuing IDs is usually used
for this. In this case, good practice requires that this procedure involves positive identification, without
stipulating whether or not a personal appearance for the ID process or the issuing of a PIN is
necessary. The company should be allowed a high degree of flexibility without compromising the
security level through mistakes arising from double issues or deliberate opportunities for misuse.

The certificate service providers have responded with appropriate offers and standard procedures
aimed at making this organizationally important security step flexible and in line with customer
requirements.

3.4    Set up a directory service

If the services of a public CSP are enlisted, it will issue the certificates with the public key in “its”
directory. Here it can be queried publicly.



ebIX                                                                                         May 16, 2006
Ten steps to transaction security                                                                        9


Three procedures have been established for doing this:

a) HTTP request:
The Hypertext Transfer Protocol has produced a system of rules for accessing documents over the
Internet. HTTP is therefore the protocol that is used for transmitting HTML pages. In this case the
certificate is requested in HTTP mode, i.e. not automated.
This can make sense if, out of security considerations, only Port 80 can be opened in the firewall.
Although the HTTP request is not universally used, it represents a practical first step towards
managing external certificates, e.g. for an encryption procedure. However, standard client applications
now only make LDAP requests. Automation via HTTP is therefore not possible.

b) LDAP request:
The Lightweight Directory Access Protocol (directory service) is a TCP/IP-based directory access
protocol. Today it is considered to be the standard solution for directory services in Internet-based
networks. LDAP offers a uniform format in which all names can be represented; it provides different
layouts and a clear assignment of names to their internal representation. It is specified in RFC 1777,
1778, 1779 and 1781. The protocol was standardized in 1999 by the IETF (Internet Engineering
Taskforce, www.ietf.org).

LDAP requests can be made for both individual certificates and certificate revocation lists (CRL).

The LDAP is mainly used for the regular, decentralized updating of CRLs.

c) OCSP request:
Online requests using the Online Certificate Status Protocol are still quite rare, but are gaining in
importance. During the validation process, not only is the CRL accessed but the status is also queried
via an OCSP responder. The reply received via the protocol is signed, usually having either the valid,
invalid or indeterminate status.

A company wishing to commence implementation should make its valid certificates and certificate
revocation list, which is probably still quite small, available in an external directory. The LDAP access
protocol via Port 389 is available for doing this. This database resides in the demilitarized zone
(DMZ). It is usually a subset from the corporate directory, e.g. an active directory or DIR.X (X.500),
where the original data is managed. This external subset can be generated and updated from the
corporate directory using language tools like shadowing or chaining, without the database having to be
managed at various locations.

External access should be fully-qualified and via a complete, correct e-mail address, so as to prevent
spanning.

3.5    Maintain data quality

The setting up or partial setting up of a Public Key Infrastructure to be used for external business
relations requires a high degree of data quality for the most important employee data. “Important data”
in this context means data that should be logically and technically unambiguous over long periods of
time. This includes names, e-mail addresses and unique identification options, such as a unique
personnel number. Many companies have also introduced an 8-digit global identifier (GID).

In the GID, 8 alphanumeric characters guarantee a character set of 836 places (26 uppercase letters and
10 numbers) and therefore long-term uniqueness.




ebIX                                                                                     May 16, 2006
Ten steps to transaction security                                                                     10


Ideally, the e-mail address should lie within the company domain and be issued as a lifetime e-mail
address; and in the case of common names, not immediately reissued to a different person if an
employee leaves the company.

The best data quality is usually to be found in systems managed by Human Resources. This data
should be used according to the “one-way principle” and only be managed in the HR system by the
HR department. This data should thus form the nucleus of the registration process and be augmented
by additional data sources. This data record should also be contained in the directory service or
external directory.

3.6     Define operating process in a PKI

Organizational rules need to be implemented for certain case studies, regardless of whether make or
buy-decisions need to be made by market participants.

Taking the most common case as an example, namely the combination of PKIs for multifunctional
employee IDs, some of the cases to be deal with are:

     Issuing new certificates or
     Defective permits

Examples of these processes are given in the diagrams in Annex 4.1.

Other standard processes can be defined in the same way:

     New employee
     Departure of an employee from the company
     Name change
     Transfer of a single employee within the group
     Forgotten ID
     Lost ID
     Transfer of a single employee
     Ban on entering the premises
     Trainees
     External employees

Roll-out

To avoid having to rely on processes designed for individual employees, separate processes can be
defined for situations involving specific company policy. Examples are first issues or subsequent
issues to many people at the same time.
If a company has also decided to set up local registration authorities (LRA) or central PKI
components, additional operating processes will need to be defined. This includes, for example,
strictly controlled access modalities to a key archive (for encryption key), transfer of HR data to
electronic applications or a card management system, etc.

3.7     Set up Certification Practice Statement and Certificate Policy in accordance with ebIX-CP

The ebIX Certificate Policy (ebIX-CP) defines industry recommendations in terms of urgently
required minimum guidelines for achieving security. Using this document as a basis, market
participants define their own CP and publish it as a self-declaration for external communications
partners and for implementation in internal divisions, majority holdings or regional companies. The
actual implementation in each company or company division is described in the Certificate Practice
Statement (CPS). This document is not usually published.


ebIX                                                                                   May 16, 2006
Ten steps to transaction security                                                                    11



These recommendations attach great importance to organizational security as it allows more cost-
effective solutions to be used for the technical security components.

This is why further documents, e.g. “PKI Policy” and “Handling Key Material”, contain numerous
organizational references.

The document “Certification Practice Statement”, in particular, represents in a structured form based
on RFC 3647 an urgent association recommendation regarding the setting up and main contents of
these statements.

Market participants should base their own documents on this.

These company-specific documents should serve as detailed, internal versions of the CPS for
describing the company’s individual processes in accordance with auditing regulations. At the same
time, a general subset of the company’s internal rules should also be published in the form of a
Certificate Policy (CP). This CP serves as a confidence-building measure between the
communications partners, indicating how the agreed security measures should be correctly
implemented.

Since 2004-01-01 the conclusion of EDI contracts containing contractual rules on IT security has also
been mandatory for the exchange of invoices via Electronic Data Interchange (EDI). This legal
requirement regarding “authenticity or origin” and “integrity of content” can be met by the CP at no
additional expense by including it as a contract element for electronic invoicing using the respective
EDI message types.

3.8    Archiving

The introduction of PKI mechanisms, in particular digital signatures, has brought about a change in
paradigm. The probative value of data and documents becomes marketable with regard to electronic
communication and so needs to be documented and safeguarded over the long-term by means of an
appropriate archival system.

The archiving system must comply with auditing requirements, allow external disputes to be resolved
and fulfill legal requirements regarding tax inspection. Example statements can be found in the
“Principles of data access and verifiability of documents” in Germany and subsequent to the Change
in Tax Legislation Act 2003, which came into force on 2004-01-01, relating to electronic invoicing.

These regulations have made things significantly easier for companies, since documents containing
results and procedures can now be adapted to the latest technical invocations. However, the above
code has adopted an “equal terms" approach for the examining financial authorities and the regulations
are aimed at preventing opportunities of misuse, in particular regarding the deduction of income tax.

Data integrity and signature authorization must be checked and the results documented. The signature
verification key also needs to be kept in a safe place. The signed data, validation results and
certificates need to be archived in such a way that the information can be immediately put together in
the event of a tax inspection.

Other requirements, such as the storing of unconverted and converted EDI data and protocols are not
affected.

3.9    Security in electronic data interchange

a) Contractual basis.



ebIX                                                                                   May 16, 2006
Ten steps to transaction security                                                                        12


If not already done, an EDI contract should be concluded between the communications partners. This
contract, drawn up in accordance with Article 2 of the Recommendation 94/820/EG of the European
Commission dated 19 October 1994, is available on the European Union website and can be
completed by adding company details such as name, address, etc. The basis for this urgent
recommendation is the legal fact that such a contract is required for invoice-related data exchange in
accordance with Sales Tax Law. Since in today’s liberalized energy market, metered data (MSCONS)
and changes in master data (UTILMD) are considered just as important business transactions as grid
usage invoices (INVOIC) and payment advice notes (REMADV), a correct contractual basis should
also be in place for these too.

Annex 1 of this contract is a reference to market interfaces and, where applicable, their
implementation (e.g. syntax version).

Annex 2 is a reference to the ebIX recommendations or their individual implementation, as
documented in the company’s CP.

This enables the legal requirement of a contractual basis with agreements on guarantees of
“authenticity of origin” and “integrity of content” to be met without great expense.

b) E-mail security
The DisSig project was initiated because of the increasing use of electronic data interchange over the
Internet, in particular via e-mail (SMTP). The “e-mail body” is only of secondary importance. The
decisive information is usually transported as a file attachment. The e-mail level can therefore be
looked on as the transport level and the file as the information level.

The e-mail transport level can be initialized and tested in accordance with the European Bridge CA
procedure (EB-CA).

c) User data security
The first priority is to improve the security of electronic data interchange at the e-mail level with the
aid of certificate-based PKI mechanisms. If a PKI is only used at this level it should be encrypted and
signed.

This depends on whether or not an e-mail gateway solution (often termed a “virtual post office”) has
been set up. The recommendations generally apply to “site-to-site security”, “end-to-end security” or
mixed forms. It is a practical solution that can be applied by all market participants with minimum
expenditure.

In addition to encryption and digital signatures at the e-mail level, the file signature method should
also be supported. The S/MIME standard may have a few restrictions, but it is fast, practical and
inexpensive to implement, and also guarantees an adequate level of security. Users should
nevertheless be aware of the restrictions:

   With S/MIME the signer is the same as the sender.
   Consequently, S/MIME does not support multiple signatures, as required, for example, in business
    letters or in other areas of application involving multiple responsibilities. This also makes it
    difficult to map out data transmitted without acceptance of responsibility without explicit
    explanations.
   With S/MIME, the text and attachments are packed in a "sealed" container. This makes archiving,
    retrieval and full text searches problematic.

For these reasons and the associated economic consequences, signatures at file level should also be
used.



ebIX                                                                                        May 16, 2006
Ten steps to transaction security                                                                            13



If this level is achieved, it will also be sufficient to encrypt at e-mail level (S/MIME) and sign at file
level.

3.10 Other fields of application and users

Until now, only mail encryption/signatures and document/file signatures have been mentioned as
fields of application for certificate-based security measures. These applications are primarily used for
data interchange between market participants in the liberalized electricity market. In principle,
maintaining information security is a corporate goal aimed at preventing loss, falsification, misuse and
unintentional use of company resources, and to safeguard the secure and trustworthy administration of
business.

The digital processing of information and process data has become a vital and indispensable
infrastructure in the core business of energy provision. Information, communication and automation
systems are now an integral part of the business-critical infrastructure. This is why information
security is not only desirable but also absolutely necessary.

But information security to protect critical infrastructures is only one side of the story (prevent misuse,
disabler aspect). Information security only enables the necessary renovation/reconstruction of the
business process over the complete value-added chain (enabler aspect).

External companies employed as general contractors or for rectifying faults in the energy network and
who require access to in-house applications and data are on the increase. Nowadays, of course,
Internet technologies (TCP/IP networks) are used to provide networked automation. In Germany,
simple notification systems are already run directly over the Internet.

The use of IT-supported workforce systems is either at the test or planning stage at many large
companies. This inevitably involves numerous internal interfaces to the control systems, to public
communications networks and to commercial data processing systems. There is now a general reliance
on IT tools and databases. Technical documentation and planning matrixes are only available on CD
or online.

The pressure to use the communication features of modern technology in order to achieve faster fault
diagnosis, better quality assurance and improved use of economic resources has resulted in network
structures that are anything but comprehensible with all manner of complicated firewall
configurations, router tables and network management structures that need to be monitored.
Nevertheless, the controlled reactivation of a failed function in a control component at an important
substation or power station is now an unsolvable problem or unheard of security risk, or both, for a
back office technician located in England and connected via the Internet.

The implementation of these recommendations also makes problems like these manageable and is
therefore part the trend towards corporate strategy. The economic feasibility of something like this has
been demonstrated by the SELMA project in the field of metering technology. Thanks to the
implemented security technology, a SELMA meter is not only capable of supplying un-falsifiable
billing information; it can also be upgraded securely with new software calibrated by Germany’s
national metrology institute (PTB) via the Internet or another communication network.

Many other applications involving secure communication with business customers, authorities,
suppliers and service providers are also in use.




ebIX                                                                                        May 16, 2006
Ten steps to transaction security                                              14



Appendix A SAMPLE PROCESSES

The following examples show processes within the PKI environment:

   Issuing a new certificate
   Replacing a defective certificate




ebIX                                                                May 16, 2006
Ten steps to transaction security            15



A.1 Issuing a new certificate




ebIX                                May 16, 2006
Ten steps to transaction security                16



A.2 Replacing a defective certificate




ebIX                                    May 16, 2006

								
To top