![[Atom]](http://media1.huoc.org/feed.png){kind=small}
![[Mail]](http://media1.huoc.org/mail.png){kind=small}
![[Twitter]](http://media1.huoc.org/twitter.png){kind=small}
![[Atom]](http://media1.huoc.org/smallfeed.png){kind=small}
J’écris un petit billet pour vous parler d’un article que j’ai lu récemment et qui m’a bien plu. Il s’agit de l’article User Interaction Design for Secure Systems, Ka-Ping Yee, 2002 (PDF, 16 pages).
The security of any computer system that is configured and operated by human beings critically depends on the information conveyed by the user interface, the decisions of the computer users, and the interpretation of their actions. We establish some starting points for reasoning about security from a user-centred point of view, by modelling a system in terms of actors and actions and introducing the concept of the subjective actor-ability state. We identify ten key principles for user interaction design in secure systems and give case studies to illustrate and justify each principle, describing real-world problems and possible solutions. We anticipate that this work will help guide the design and evaluation of secure systems.
[…]
Usability issues are often considered to “trade off” against security. Among many designers, there is the pervasive assumption that improving security necessarily degrades usability, and vice versa; the decision of whether to favour one or the other is typically seen as a regrettable compromise. In the end, these judgement calls are made somewhat arbitrarily because there seems to be no good answer. We believe that usability and security goals rarely need to be at odds with each other. In fact, often it is rather the opposite: a system that’s more secure is more predictable, more reliable, and hence more usable.
Ce n’est pas un article très technique, car il concerne uniquement les questions d’interface utilisateur. Il est donc facile à lire, même s’il est parfois formulé en termes assez abstraits : les exemples aident à bien comprendre l’application des concepts présentés.
Si vous avez besoin d’un peu plus d’information avant d’ouvrir le PDF, voici la liste des dix principes présentés dans l’article. Évidemment, c’est mieux avec les explications et les exemples.
- Path of Least Resistance
To the greatest extent possible, the natural way to do any task should also be the secure way.
- Appropriate Boundaries
The interface should expose, and the system should enforce, distinctions between objects and between actions along boundaries that matter to the user.
- Explicit Authority
A user’s authorities must only be provided to other actors as a result of an explicit action that is understood by the user to imply granting.
- Visibility
The interface should allow the user to easily review any active authority relationships that would affect security-relevant decisions.
- Revocability
The interface should allow the user to easily revoke authorities that the user has granted wherever revocation is possible.
- Expected Ability
The interface must not generate the impression that it is possible to do something that cannot actually be done.
- Trusted Path
The interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user’s behalf.
- Identifiability
The interface should enforce that distinct objects and distinct actions have unspoofably identifiable and distinguishable representations.
- Expressiveness
The interface should provide enough expressive power (a) to describe a safe security policy without undue difficulty; and (b) to allow users to express security policies in terms that fit their goals.
- Clarity
The effect of any security-relevant action must be clearly apparent to the user before the action is taken.
L’intérêt inattendu de la sécurité
Cet article établit une synergie entre la sécurité et une bonne conception de l’interface utilisateur. Je ne suis pas surpris par cette approche, car j’ai déjà constaté des coïncidences entre sécurité et bonne conception dans de nombreux domaines :
Au sein de l’organisation d’un programme, il y a des liens forts entre sécurité et modularité : toutes deux favorisent l’encapsulation, la réduction des dépendances entre composants, etc.
Par ailleurs, le parallélisme et la concurrence sont des sujets à la mode en ce moment ; Mark Miller, qui travaille de la sécurité par capabilities, expose dans sa thèse, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control, un lien entre la conception de programmes sûrs et de programmes distribués.
Au niveau de la conception des langages de programmation, on observe là encore une corrélation forte entre certains principes de conception généraux des langages de programmation, et la conception de langages adaptés à la sécurité. Par exemple les références mutables globales, habituellement considérés comme néfastes à cause des effets de bords qu’elles permettent, sont vues comme des canaux cachés d’un point de vue sécurité.
Les langages de programmation fonctionnels modernes sont ainsi, sans le savoir, propices à une programmation sûre. C’est une des choses que l’on peut retenir par exemple de l’expérience Emily que j’ai déjà mentionnée.
La sécurité est un domaine qui, au départ, ne m’intéressait pas des masses. La plupart des erreurs de sécurité exploitables sur les logiciels grand public sont liés à des défauts technologiques maintenant évidents (buffer overflow, SQL injection…) qui ravivent ma crispation devant l’inertie de certaines couches logicielles arriérées.
Mais cette synergie entre la sécurité et des aspects de conception qui m’intéressent beaucoup me pousse à m’y pencher de plus près. En particulier, les risques liés à la sécurité sont beaucoup plus évidents et perceptibles que les bénéfices de la bonne conception, et ils constituent donc un bon moyen de pression pour pousser les gens à améliorer leurs technologies.
Cette année, j’ai eu l’occasion de m’intéresser à nouveau aux capabilities, ainsi qu’au minimum vital de cryptographie. J’espère que j’aurai l’occasion d’écrire quelques billets à ce sujet.
# Cygal
19.03.11, 23:52.
# gasche
20.03.11, 11:42.
# SpiceGuid
27.06.11, 17:48.
# gasche
28.06.11, 09:33.
J’entends bien. Ici le surcoût est un effort de conception supplémentaire. Tout comme la simplicité de conception est très difficile ( coûteuse) à atteindre, bonne interface et bonne sécurité sont déjà délicats, les deux ensembles c’est difficile.
Par contre, ce surcoût est accompagné par un gain en sécurité. Le gain en sécurité peut diminuer les coûts; coûts de développement, car une bonne conception permet d’éliminer de larges vecteurs d’attaque qu’il faudrait prendre en compte un par un sinon, mais surtout à l’utilisation, car une faille de sécurité dans un système peut coûter cher, qu’il soit exploité ou non (coût de maintenance, de mise à jour, interruption de service…).
Est-ce que le rapport "gain / coût" de telle ou telle technologie est intéressant ? Ça dépend des contextes, et ça peut changer. Aujourd’hui la preuve formelle à laquelle tu fais référence est effectivement trop coûteuse (trop difficile) pour être mise en pratique en dehors des industries critiques à les gains (en assurance de la fiabilité du système) sont très importants. Je pense que la sécurité est plus facile à faire accepter; il est vrai qu’aujourd’hui certains acteurs conçoivent les failles de sécurité plus comme un problème d’image que comme un problème technique (les failles, on en aura toujours, l’important est de tout faire pour que ça ne nuise pas à notre réputation). Mais elle reste importante dans un large nombre de cas, sans doute plus que la certification/preuve aujourd’hui.
Enfin, là où il y a un coût, il y a un défi pour les chercheurs et les ingénieurs : le diminuer. La certification est trop coûteuse aujourd’hui, à nous de développer des méthodes et des outils pour la rendre plus aisée. Respecter des principes d’usabilité et sécurité est trop exotique et difficile, à nous de construire des systèmes dans lequel ces principes sont plus faciles à mettre en pratique, de les présenter de façon simple (c’est ce que cherche à faire l’article cité), et de les diffuser dans la culture générale des concepteurs de logiciel pour que leur mise en application devienne plus naturelle.
# SpiceGuid
28.06.11, 16:59.
# Cygal
29.06.11, 09:42.