Biblio

Technical debt is an analogy introduced in 1992 by Cunningham to help explain how intentional decisions not to follow a gold standard or best practice in order to save time or effort during creation of software can later on lead to a product of lower quality in terms of product quality itself, reliability, maintainability or extensibility. Little work has been done so far that applies this analogy to cyber physical (production) systems (CP(P)S). Also there is only little work that uses this analogy for security related issues. This work aims to fill this gap: We want to find out which security related symptoms within the field of cyber physical production systems can be traced back to TD items during all phases, from requirements and design down to maintenance and operation. This work shall support experts from the field by being a first step in exploring the relationship between not following security best practices and concrete increase of costs due to TD as consequence.

The XML-based data format AutomationML enables vendor-independent exchange of design data between discipline-specific design tools. It is based on Computer Aided Engineering Exchange (CAEX) and hence, compatible with the W3C standards XMLEnc (XML encryption) and XMLDsig (XML signatures). However, despite the importance of protecting engineering data, so far no concept has been presented to ensure and control on a fine-grained level the confidentiality, authenticity and accessibility of information stored in AutomationML files. In this paper, we introduce a basic access control scheme for AutomationML that enables to define user read and write access for each component. Furthermore, the scheme supports non-repudiation based on a change history and so-called "signature chains". It is also capable of supporting views and restricted access to components. The scheme is based on cryptographic measures – i.e. cryptographic hashing, symmetric encryption, signatures, and asymmetric encryption – and enforces its access control mechanisms through encryption to protect against unauthorized reading, and through signature chains to protect against unauthorized manipulation and to ensure non-repudiation. This approach has the benefit to be independent of the underlying file and operating system, storage location, etc., and it keeps full CAEX-conformity by extending AutomationML.This concept can serve as basis for software tools that support AutomationML and want to integrate access control features directly into AutomationML.