Project topics and materials
Get Complete Project Material File(s) Now! »
Software Engineering
The software engineering discipline is vast and promotes concepts to properly manage software development from its early existence. The field has developed over time several techniques and methodologies to produce software with a focus on delivery time and quality. It gives guidelines to manage specifications, to gather and elicit requirements, to define an architecture with design of components and interfaces, to provide procedure for testing, to maintain software, to manage configuration, to review processes around management, to define security and safety, etc..
The primarily goal is to translate real-world concerns to software, letting customers expressing needs that are then translated to applications that runs on computers. The whole process is complex and involving heterogeneous actors. It is also still evolving, with new methods to better manage systems. The definition of software is made in terms of a set of requirements, that represent the business goal of the application. The translation of these business needs in software is realized using a programming language. A set of concepts also govern programming engineering.
At the beginning, the programs were defined as structured instructions executed sequentially.
The Figure 2.1 shows an evolution of programming paradigms these past decades, that diverged in two main dimensions. The first dimension represents an advanced conceptualization of components through the programming language. For instance, programming languages started to conceptually define separation of concerns to virtually manage piece of software independently.
Aspect-Oriented Software Development
Aspect-Oriented Software Development (AOSD) is a whole discipline around the concept of aspect. It describes approaches to software modularization and composition, and gather techniques and methodologies to incorporate the aspect concepts. The set of software development techniques include requirement engineering, analysis and design, architecture, testing, and programming.
The last point is the core of AOSD, but requires support of the aforementioned techniques with either tools, or methodologies. The preliminary steps elicit requirements that represent cross-cutting concerns. In software, there are several concerns that can be either functional or non-functional. It means that some concerns are business related, while other are related to the correct execution of the program and are generally implied by some technical choices: environment, programming language, framework, platform, etc. These concerns are sometimes translated in programming pieces that are scattered and tangled over the code. Such concerns are good candidate to be implemented with aspects.
There are several use cases that are discussed. For instance, the benefit of adopting Aspect- Oriented Software Development in Business Application Engineering [PCG+08] for large companies
lies in overcoming several challenges in the context of specific products. AOSD is not bound to a particular language, and needs several tools and methods for the particular environment of the company: debugging tools, processes that respect existing business process, extension to languages, flexible mechanisms, etc. Also, AOSD does not necessarely fits all projects, and needs to be introduced slowly. For instance, Robinson and al. [LSM05] present the relation between AOSD and security in the area of application security management, in which the application handle security policy and needs to enforce specific behavior. they differentiate the business logic from the security management logic, the security enforcement logic and the communication logic. They show that AOSD fits the use case by using an interaction specification language describing behavioral dependencies between components, and runtime adaptation in the interaction scheme.
AOSD refers to the general concept of aspect that is implemented in a particular language.
We are discussing the aspect paradigm through the presentation of Aspect-Oriented Programming.
The term Aspect-Oriented-Programming [KLM+97] (AOP) has been coined around 1995 by a group led by Gregor Kiczales, with the goal to bring proper separation of concerns for crosscutting functionalities. Roots for foundations can be traced back to adaptive programming, or composition filters [Lop05]. O. Selfridge introduced a notion that can be related to AOP as « demons that record events as they occur, recognize patterns in those events, and can trigger subsequent events according to patterns that they care about » [Sel58]. But the approach has then derived to become a discipline apart.
Security Implication in the Software Development Life Cycle
The secure software development lifecycle gather techniques and methodology to follow in addition to the software development lifecycle to produce high quality solutions, respecting compliance and quality level to avoid flaws and vulnerability when developing applications. At the early age of software development, the complexity and time to write a single piece of software was too high to let someone abuse of a system. With the rapid and growing usage of application for any kind of problems, people started to exploit software logic to bypass some internal limitations.
Then, when systems became ubiquitous and inter-connected, a new category of people have been given access to mass systems. Software are complex pieces designed and developed by individuals and automated tasks. Sometimes, without the possibility to control entirely the process, some errors are introduced in the application. It goes from architecture flaws, where specifications represent a subset of the real-environment, letting some unknown behavior at the mercy the luck. It can also be software weaknesses, that when exposed to some attackants can introduce security vulnerabilities. These vulnerabilities can be detected and exploited by a large range of attackers. The rapid growing of systems and complexity to manage several teamstogether to timely deliver softwares combined to the structuration of governments, groups of security experts, talented system hackers and a whole range of malicious users lead to the emergence of a new discipline in computer science. The aim is to not only produce softwares, but produce high quality softwares compliant with regulations in place, internal company policies, etc. Furthermore, the lifecycle involves several actors from the early gathering of specifications to the final stage of testing, deployment, and detection. In this section, we detail the different steps that are traditionally accepted as being part of the so-called SDLC (Security Development Lifecycle).
Table of contents :
Résumé
1 Introduction
1.1 Background
1.2 Overview
1.3 Problem Statement
1.4 Contributions
1.5 Organization of the thesis
2 Modularization of cross-cutting concerns
2.1 Software Engineering
2.2 Aspect-Oriented Software Development
2.3 Security Implication in the Software Development Life Cycle
2.4 Security Requirements
2.5 Security and aspects
2.6 Service Oriented Architecture
I Modularization of defensive security
3 Vulnerability remediation with modular patches
3.1 Introduction
3.2 Agile management of vulnerabilities
3.3 A flexible architecture
3.4 Static analysis process
3.5 Assisted remediation with a security aspect library
3.6 Evaluation
3.7 Related work
3.8 Summary
4 Automation of input validation verification in application
4.1 Introduction
4.2 Aspect-based modularization with enhanced data-types
4.3 Use case
4.4 Validation
4.5 Related work
4.6 Language approach for security modularization
II Modularization of constructive security
5 Service framework modularization for message-based security
5.1 Introduction
5.2 Motivation
5.3 REST Security
5.4 Evaluation of REST security protocol
5.5 Related Work
5.6 Summary
6 Modularization of privacy in cloud platform around persistance layer
6.1 Introduction
6.2 Privacy-Aware Applications in the Cloud
6.3 Privacy Enhanced Application Programming
6.4 Related Work
6.5 Summary
III Conclusion and perspectives
7 Conclusion
8 Perspectives: towards a cross-layer and parametric aspect system
8.1 Motivation
8.2 Requirements
8.3 Aspect System and Language
8.4 Related work
8.5 Conclusion
Bibliography
