ACM Transactions on Information and System Security (TISSEC)
Computability classes for enforcement mechanisms
ACM Transactions on Programming Languages and Systems (TOPLAS)
Certified In-lined Reference Monitoring on .NET
Proceedings of the 2006 workshop on Programming languages and analysis for security
Policy enforcement via program monitoring
Policy enforcement via program monitoring
Proving the Correctness of Multiprocess Programs
IEEE Transactions on Software Engineering
Execution monitoring enforcement under memory-limitation constraints
Information and Computation
Run-Time Enforcement of Nonsafety Policies
ACM Transactions on Information and System Security (TISSEC)
Do You Really Mean What You Actually Enforced?
Formal Aspects in Security and Trust
Infringo ergo sum: when will software engineering support infringements?
Proceedings of the FSE/SDP workshop on Future of software engineering research
Using equivalence relations for corrective enforcement of security policies
MMM-ACNS'10 Proceedings of the 5th international conference on Mathematical methods, models and architectures for computer network security
ESSoS'11 Proceedings of the Third international conference on Engineering secure software and systems
Corrective enforcement of security policies
FAST'10 Proceedings of the 7th International conference on Formal aspects of security and trust
Corrective Enforcement: A New Paradigm of Security Policy Enforcement by Monitors
ACM Transactions on Information and System Security (TISSEC)
Iterative enforcement by suppression: Towards practical enforcement theories
Journal of Computer Security - ARSPA-WITS'10
| Hi-index | 0.00 |
Runtime enforcement is a common mechanism for ensuring that program executions adhere to constraints specified by a security policy. It is based on two simple ideas: the enforcement mechanism should leave good executions without changes and make sure that the bad ones got amended. From the theory side, a number of papers [6,10,12] provide the precise characterization of good executions that can be captured by a security policy and thus enforced by a specific mechanism. Unfortunately, those theories do not distinguish what happens when an execution is actually bad (the practical case). The theory only says that the outcome of enforcement mechanism should be "good" but not how far should the bad execution be changed. If we consider a real-life example of a drug dispensation process in a hospital the notion of security automata or even edit automata would stop all requests by all doctors on all drugs and all dispensation protocols, as soon as a doctor forgot to insert the research protocol number. In this paper we explore a set of policies called iterative properties that revises the notion of good traces in terms of repeated iterations. We start discussing how an enforcement mechanism can actually deal with bad executions (and not just only the good ones).