Description
The goal of the thesis is to identify and analyze the parts of the code of open-source software where security features are implemented.
Since it is difficult to find all security feature implementations in a software system, we want to use a systematic approach starting from easily identifiable security-critical fields and methods. Based on the documentation and a keyword search, we want to annotate them with basic security properties (Confidentiality/Secrecy and Integrity). For such properties, there is work on how they propagate along dependencies (method invocation or field access), e.g. UMLsec Secure Dependency. The idea is that if a member (method or field) is annotated with a security property, the accessing members must also have an annotation for that member to show that this security property is taken into account by the implementation of the accessing method. If this would not be the case, the method must be changed to be compliant and allow developers to annotate it with the security property or the access must be deleted. To check for missing declarations of compliance, we already have basic tool support that creates error markers in Eclipse for methods that have Java annotations for security property (@Secrecy/@Integrity) that indicate where an annotation (@Secrecy/@Integrity) is missing that declares that the annotated properties are considered. The idea is to manually propagate the security properties along the call hierarchy based on this. Here we assume that it is always a given that the security properties are taken into account and can be annotated as being compliant. Accordingly, there are two cases resulting in being compliant, either the method itself must be annotated with the security property (@Secrecy/@Integrity), as this simply propagates it further, or the code of the method contains the implementation of a security feature that prevents propagation. It must then be decided manually which of the two cases applies. According to the decision, either the method is annotated with the relevant security properties (@Secrecy/@Integrity) or the code of the security feature within the method is annotated (in this case in an ifdef-like notation). In this way, implementations of security features can be systematically found and subsequently analyzed, e.g., with respect to size, type of feature, etc.
Contact
Sven Peldszus (sven.peldszus@rub.de)
Kevin Hermann (kevin.hermann@rub.de)
Extent: B.Sc./ M.Sc.