- Introduction
- The Domain of Application-Level Security
- An Experience Report
- Discussion
- Related Work
- Conclusion
- Acknowledgments
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
27.2 The Domain of Application-Level Security
A classical and increasingly popular example of a non-functional concern is security. Security is a broad domain; we focus our research on the engineering of application-level1 security requirements including authentication, auditing, authorization, confidentiality, integrity and non-repudiation. Security is a challenging application domain, particularly since many security experts are uneasy about trying to isolate security-related concerns. The primary reason for this discomfort is that security is a pervasive concern in software systems. Indeed, separating security-related concerns such as access control is difficult to achieve with state-of-the-art software engineering techniques.
A major cause of this pervasiveness is the structural difference between application logic and security logic. For example, the code to write relevant events to an audit log or the code that realizes an access control model is often spread among many classes. Attempts to modularize security concerns have been ongoing for many years. While the community has succeeded in modularizing the implementation of security mechanisms, where and when to call a given security mechanism in an application has not been adequately addressed. Furthermore, the crosscutting nature of security relates not only to the diversity of specific places where security mechanisms are to be called but also to the context of calls: Some security mechanisms require information that is not localized in the application. For instance, consider communication encryption within an application: the keys to be used for this purpose are typically linked to a user or principal that is somehow represented in the application. Key selection often depends on the specific communication channel and hence requires connection or host information. Initialization vectors and other security state information is often contained in the security mechanism itself. Finally, the actual data to protect may be scattered over several locations in the application.
Application-level security is an appealing but also a difficult candidate for validating AOP techniques because of its inherent complexity. In this validation, it is important to assess the flexibility for reuse and maintenance that a proposed mechanism provides. Given the prevailing heterogeneity of application domains and environments, there is a clear need to reuse security solutions. The extra importance of maintenance may require some further explanation. The Common Criteria [6] and their predecessors argue for considering security from the start of the system development process. However, history shows that for systems of moderate to high complexity, the idea of building a secure system from scratch is utopian. Unanticipated threats always arise during the lifetime of the system, both because the initial threat analysis was incomplete and because the environment in which the software operates changes. Some form of patching or updating the system is always necessary. Moreover, building a very secure system from the start makes an application complex and expensive, often beyond the economic resources of the developing organization.