Seminar Secure Software Engineering

News

  • Kickoff slides available
  • The list of topic is now final (with one minor exception)
  • Process for application: write an e-mail to Prof. Jan Jürjens with a short application in written form, your course credits so far and a prioritized list of desired topics.
    Deadline: 1.3.2017 15.03.2017
  • The kickoff meeting will take place 18.04.2017 16:15 in room B015.
  • Attending this seminar is possible in English as well as in German
  • The seminar will be held as a block seminar in the form of two/three whole day sessions at the end of the summer term 2017

Deadlines

    • 24.05.17 (24:00) Abgabe Gliederung
    • 18.06.17 (24:00) Abgabe Vorversion Ausarbeitung*
    • 02.07.17 (24:00) Abgabe Reviews
    • 30.07.17 (24:00) Abgabe Ausarbeitung*
    • 27.08.17 (24:00) Abgabe Folien
    • ∼14./15./29.9. VorträgeTerminänderung: Vorträge am 5.10.
    • *: Wird das Seminar in Kombination mit der Veranstaltung "Softwaretechnik für sichere Systeme" belegt, ist die Anfertigung einer Ausarbeitung freiwillig. In diesem Fall ist statt der Ausarbeitung dann der vorläufige bzw. ausgearbeitete Foliensatz abzugeben. Statt einer Ausarbeitung wird in diesem Fall der Foliensatz in den Reviewprozess einbezogen.

     

    Abstract

    The participants will get to understand the requirements on security-critical systems and its types of threats. They will get an overview of the existing techniques to avoid security risks and to repel threats. They will get to know of the special features of the management of security-related software projects, the benefit of security expenses and the relevant standards and regulations. Finally, they will have concentrated on model-based techniques for developing security-critical systems as well as analyzing and re-engineering of existing software, being able to evaluate gained practical experience and to get an overview of existing tools and its performance.

    Guiding themes

    The development and maintenance of trustworthy and security-critical systems are big challenges. There are many software-intense systems designed, implemented and in use that have serious security issues. We know from experience as well as from headlines about spectacular malfunction of systems or about successful attacks on them. The reasons are manyfold. Sometimes the developers' required security awareness is missing, often the required knowledge for development processes, methods, techniques and tools is missing or they are not used as one supposes not to be able to afford a high time and cost expenditure with the current competitive pressure. In relation to the engineering or re-engineering of security-critical software systems the following questions need to be answered:

     

    • Which methods do exist for a comprehensive risk management with which experts are able to perform a complete analysis of the security risks of business processes and workflows and to derive proposals for appropriate treatments?
    • Which methods do exist for the engineering or re-engineering of security-critical software systems for the selection of suitable development processes and suitable tools as well as quality assurance?
    • Which tools do exist to automatically analyze e.g. business processes, UML specifications, source code and configuration files towards security?
    • Is it possible to intuitively specify security requirements with UML or CASE tools for example, such as AutoFocus? Do tools exist for simulation, consistency checking, code generation, verification and testing of security aspects?
    • Are the created models usable as documentation for certification against relevant standards?

    List of seminar topics

    1. Addressing privacy requirements in system design

    A major challenge in the field of software engineering is to make users trust the software that they use in their every day activities for professional or recreational reasons. Trusting software depends on various elements, one of which is the protection of user privacy. Protecting privacy is about complying with user’s desires when it comes to handling personal information.

    Introductory literature:

    2. Privacy aware access control models

    As the amount of data being collected by service providers increases, privacy concerns increase for the data owners that must provide private data to get services. Legislative acts require enterprises protect the privacy of their customers and privacy policy frameworks. Unfortunately, defining these standards does not guarantee that the privacy policies are actually enforced since privacy is not central to conventional access control models.
    Introductory literature:

    3. Integration management of security requirements approaches

    Different approaches have been proposed in the literature to handle security requirements.  However, each approach can support security requirements at one or specific stages of system development life cycle. Due to the absence of the integration management between different security requirements approaches, one cannot guarantee the alignment of security requirements at different stages of system developments process. Therefore, tracing and integrating security needs throughout the whole software development process is one of the main challenges in software and requirements engineering research.

    Introductory literature:

    • http://link.springer.com/chapter/10.1007/11767138_5
    • http://link.springer.com/article/10.1007/s00766-009-0093-9

    4. Privacy Threats Identification

    Most of today’s software systems are part of Socio-Technical Systems (STSs) that involve a organizational (humans and organizations) and technical (software and hardware) components to accomplish shared objectives. Since most of the data in these systems are digitalized, many research papers have been published on the importance of taking the privacy during the early stages of system development to prevent the disclosure of sensitive personal information. To enable correct enforcement for the privacy issues, a threat model should be identified. For example, preserving Alice’s identity from being disclosed to unauthorized users means many things depending on who is unauthorized to access what? and where such threat could occur (e.g., data communication or database level)?. However, a few research have been done on the identification of privacy threats models and their consequences.

     

      5. Security-Monitoring and code injection

      Given a model of a secure system design, the system has to be implemented. There are different mechanisms to ensure and/or monitor, that certain security requirements are satisfied during the run-time of a system. Two possibilities are monitoring the code purely externally by watching access / transaction / ... logs or instrumenting the source code to connect it to assessing tools.

      Introductory literature:

      6. Security adaptation through aspect oriented programming

      Software systems connected via network / internet face attacks continuously. There is a vast number of applications that depend on a working backend available via the internet to work - this especially applies to mobile shopping apps for example.

      Systems can then be adapted during run-time, but integrating this can bloat the code and lower its maintainability.

      Aspect oriented programming is a method of providing code and logic to realize crosscutting concerns seperated from the core business logic.

      Introductory literature:


      7. Privacy-protection mechanisms for the Android ecosystem

      Since a few years, mobile devices have bypassed desktop computers in sales, and the number of mobile application developers bypasses the number of desktop developers worldwide. To better understand the mobile ecosystem with its unique implications on the privacy of its users, it is interesting to learn fundamentals and specifics of privacy-preserving mobile application development and find out how it differs from the development of desktop applications.


      8. Empirical investigations about the use of security mechanisms

      Despite considerable advances in the fields of security engineering in general and cryptography in particular, an alarming number of software applications is shipped with vulnerabilities that could have been prevented if state-of-the-art security mechanisms would have been in place. Why is there such a gap between security engineering knowledge and its application in practice? Since software development is an inherently human activity, it interesting to address this question from the empirical perspective and identify challenges and opportunities for new and improved security mechanisms.

       

      9. Reflection-aware Static Security Analysis of Java Programs

      Implementations of large projects with many dependencies are prone for errors and especially for security related errors like writing critical data into public accessible fields.
      Static security analysis is a approach to detect some kinds of these errors by analyzing the source code. Static analysis of source code is hardened by programming language features like dynamic typing or Java Reflection, which make static decisions about types or calls at run time undecidable in many cases. However, there are approaches to resolve concepts like Java Reflection for some cases.


      10. Inheritance of Security Properties  in Object-oriented Contexts

      In Information Security specific security properties like secrecy are required for assets. In our working group we are using the UMLsec approach to model and verify security requirements on UML models. In this approach assets for security properties like e.g. secrecy can be members of classes whose information shouldn't be read by unauthorized entities for the secrecy case. In many approaches inheritance between objects is neglected in such approaches but recent research goes into the direction of deriving security properties from super objects or to validate if a child objects fulfills the security properties if the parent of this object fulfills the security properties. However, this questions aren't new and many general research in this direction has been done for object-oriented databases.

      11. Security Design Patterns

      The Security Patterns are a solution for recurring security design problems. They are expected to be general, time-tested solutions and should be able to solve recurring real world problems.The most prevelant advantage of using the security design patterns is the possibility of designing secure systems hence containing fewer security design flaws. The purpose would of study would be to understand the state of the art in this field of research.

      12. Security integration in Domain Specific Languages

      Domain Specific Languages (DSL)are used to perform tasks in certain domains. The langauge in software systems is targetted at desiging systems from a specific viewpoint. DSL for many domains have been formulated and utilized. However, the security integration and addressing the critical security aspects in many of these domains is not well addressed or there exist different methods for integrating security. The purpose would be to study the security integration in many of these DSL in various domains.

      13. Domain knowledge support for RE

      Knowledge about the application domain - captured in ontologies - can support requirements engineering to enable enhanced checks e.g. for completeness and consistency. To start the development process with requirements of high quality can reduce errors and security or safety issues.

      Introductory literature:

      14. Requirements Quality Metrics

      Many security issues are already introduced to the project during requirements elicitation. Requirement metrics are used to identify risks of a project by locating errors in the requirements document. These metrics validate the gathered requirements by evaluating whether the requirements are complete and correct or not. Several metrics are used to measure the requirements e.g., volatility metrics check changes in the requirements, traceability evaluates links among the requirements within a document and requirements completeness metrics verifies whether the specified requirements are complete or not. Therefore multiple metrics are necessary, as one metric is not sufficient to evaluate the health of a project.

      How to participate

      As soon as the final list of topics is announced, send an e-mail to Prof. Dr. Jan Jürjens explaining why you want do participate in the seminar an to what extent you are a good choice for the topics. (See above).

      Blockseminar

      This seminar will take place as a two- or three-day block seminar at the end of the term.

      Leistungsnachweis

      The grade will be put together from the following parts:

      • a written manuscript of about 15 pages length referring to the main part
      • a presentation of about 35 minutes plus discussion (limits: 30-40 minutes)
      • active participation during the presentation of other participants
      • compliance with formal guidelines (in particular the timely and complete submission)
      • you will obtain further information during the first meeting

      The grade you receive will built as follows:

      • presentation (40%)
      • written composition (40%)
      • reviews (10%)
      • discussion after the presentations (10%)

      Furthermore, compliance to the formal guidelines is vital (degradation of marks in case of non-compliance). Failing one part automatically leads to failing the whole seminar, and plagiarism in one part immediately leads to failing the seminar and will be reported to the audit committee.

      Feedback

      We are really interested in accompanying feedback to directly respond to change requests. Please express your comments subsequent to a lecture via e-mail or the anonymous contact form of our research group (in the latter case please mention the lecure the comment refers to). Many thanks!