Segurança, Usabilidade e interação

Transcrição

1 Segurança, Usabilidade e interação Security, Usability and interaction Colusso, Lucas Franco; Bel.; Universidade Federal de Santa Catarina lucascolusso@gmail.com Cybis, Alice T. Pereira; PhD.; Universidade Federal de Santa Catarina acybis@gmail.com Dantas, Mario; PhD.; Universidade Federal de Santa Catarina mario.dantas@ufsc.br Resumo As diferenças entre Interação Humano-Computador e Segurança (IHCSec) e Interação Humano-Computador (IHC) ainda são temáticas novas, e existe um delicado equilíbrio entre melhorar a usabilidade de um sistema e reduzir sua segurança. Técnicas de IHC visam melhorar a eficácia e satisfação dos usuários, mas não levam seriamente em conta ameaças e vulnerabilidades que podem introduzir. Utilizamos o estudo de caso de um software desenvolvido no laboratório LaPeSD da Universidade Federal de Santa Catarina (UFSC) para validar um modelo de abordagem de Interação Humano-Computador e Segurança (IHCSec). Como resultado de aplicação do modelo, apresentamos controles de segurança criados para o projeto de interação do sistema. Palavras Chave: Design de Interação, Segurança, Usabilidade. Abstract The differences between Human-Computer Interaction and Security (HCISec) and Human- Computer Interaction (HCI) are still new themes, and there is a delicate balance between improving the usability of a system and reducing its safety. HCI techniques aim to improve the efficiency and user satisfaction, but do not take seriously into account threats and vulnerabilities that it can produce. We use the case study of a software developed at the LaPeSD lab of the Federal University of Santa Catarina (UFSC) to validate a approach model for Human-Computer Interaction and Security (HCISec). As a result of the applied model, we present security controls built into the design of system interaction. Keywords: Interaction design, Security, Usability.

2 Introdução É frequente a perspectiva de que efetuar melhorias em usabilidade afeta a segurança de modo negativo, e vice-versa. Yee (2004) atribui esse conflito aos desenvolvedores de sistemas que tratam a segurança, ou a usabilidade, como complementos para um produto já acabado. A segunda razão pela qual a segurança e a usabilidade parecem ser opostos é o conflito de interesses que existe entre os proprietários de sistemas e seus usuários. A Interação Humano- Computador e Segurança (IHCSec) surgiu devido à necessidade identificada pelos especialistas em Interação Humano-Computador (IHC) de melhorar a usabilidade de sistemas seguros, pois apesar da área já ter um longo histórico - as primeiras pesquisas datam de 1975 (Balfanz et al., 2004), e o mesmo autor aponta que poucos trabalhos se concentram sobre a usabilidade de sistemas seguros - Flechais (2005) afirma que a Interação Humano- Computador e Segurança (IHCSec) concentra-se quase que exclusivamente em melhorar a interface do usuário dos sistemas, o que por si só não é suficiente. Os estudos existentes seguem metodologias e procedimentos vindos diretamente de Interação Humano-Computador (IHC), destinados a avaliar a usabilidade de sistemas em geral. Entretanto, avaliações de usabilidade de sistemas de software seguros requerem procedimentos que se afastem das técnicas padrão acima mencionadas. Whitten (2004) destaca diferenças entre softwares seguros e demais softwares. A avaliação de usabilidade de software seguro não deve se concentrar em usabilidade a ponto de excluir a segurança: em certos casos é necessário até mesmo incluir comportamentos e tarefas de nível complexo aos usuários para garantir esta. Neste trabalho, apresentamos pontos de Interação Humano-Computador e Segurança (IHCSec) incluídos no projeto de um software desenvolvido para o setor de exploração de petróleo, no Laboratório de Sistemas Distribuídos da Universidade Federal de Santa Catarina (LaPeSd). Detalhamos fatores pertinentes a sistemas seguros, baseando-nos em um modelo de avaliação de segurança e usabilidade de projeto de software. Assim, o trabalho está organizado da seguinte forma: fundamentação teórica sobre Interação Humano-Computador (IHC) e Interação Humano-Computador e Segurança (IHCSec) com observações sobre Design de Interação, seguido da apresentação do modelo de análise híbrido (Kainda et al., 2010) de abordagem de segurança e usabilidade. Em sequência apresentamos medidas práticas de controle de segurança aplicadas ao referido sistema, e por final, concluímos e discutimos trabalhos futuros. Fundamentação Houve uma série de tentativas em definir usabilidade: o International Standard Organization (ISO) 1 define usabilidade como a medida em que um produto pode ser usado por usuários específicos para atingir metas específicas com eficácia, eficiência e satisfação em um contexto específico de utilização. Esta definição enfoca nos objetivos dos usuários (eficácia), a velocidade com que os objetivos são atingidos (eficiência) e a satisfação dos usuários com o sistema dentro de um contexto específico. A definição implica que a 1 ISO

3 usabilidade é contextual. Um sistema com boa usabilidade em um contexto pode não o ser em outro. Outras definições de usabilidade incluem diferentes elementos, tais como capacidade de aprendizado (Shackel, 1991) e de memorização (Nielsen, 1993). De acordo com Preece (et al., 2005), por design de interação, entendemos o seguinte: design de produtos interativos que fornecem suporte às atividades cotidianas das pessoas, seja no lar ou no trabalho. Em outras palavras, design de interação significa criar experiências que buscam aperfeiçoar e estender a maneira como as pessoas trabalham, se comunicam e interagem. O design de interação, além disso, busca maneiras de dar suporte aos usuários, e assim sendo, conecta-se às definições de segurança de um sistema, o que pode divergir dos objetivos da usabilidade, pois giram em torno de ameaças ao sistema, e estas podem ser tanto invasores mal-intencionados quanto usuários normais, atingidos pelas dificuldades geradas por um mau projeto de interface. Por exemplo: (1) o usuário percebe uma ação sendo inofensiva quando não é; (2) o usuário é incentivado a efetuar uma interação perigosa; (3) o usuário é incapaz da interação desejável. É, portanto, oportuno utilizar-se de um modelo de abordagem para avaliar a segurança e a usabilidade de sistemas ao se propor controles de segurança para design de interfaces em sistemas seguros. Modelo de abordagem A Interação Humano-Computador e Segurança (IHCSec) está centrada no usuário, pois este precisa de um sistema que é ao mesmo tempo seguro e de boa usabilidade. Ainda, segundo Preece (et al., 2005), avaliar o que foi construído está no centro do design de interação. Por isso, neste caso, é necessário um modelo de análise híbrido (Kainda et al., 2010), diferente de modelos de segurança padrão e também dos modelos de usabilidade. Os fatores críticos averiguados que necessitam de investigação durante a avaliação de usabilidade e segurança são apresentados abaixo, nas duas primeiras etapas (usabilidade e segurança). Para uma avaliação procedente, também apresentamos as métricas de avaliação, muito embora não sejam considerados parte do modelo de análise proposto. A. Usabilidade Eficácia: um sistema só é útil se seus usuários são capazes de atingir os objetivos pretendidos. Um sistema ineficaz pode ser deixado de lado. A eficácia é medida através da capacidade dos usuários em completar uma tarefa em particular ou não. Esta abordagem é adequada para a maioria dos estudos em que a tarefa consiste de um único passo ou caminho. No entanto, tarefas complexas podem exigir uma definição mais detalhada de sucesso ou fracasso, podendo incluir níveis tais como a falha ou sucesso parcial. Satisfação: enquanto análises objetivas de usabilidade de sistemas são comuns, a avaliação subjetiva dos usuários é fundamental para o sucesso de um sistema. Um

4 sistema é fadado a falhar, mesmo quando tem boa usabilidade, se não for popular entre os usuários. A satisfação do usuário pode ser avaliada através de entrevistas e escalas. Precisão: o fator de precisão foi identificado principalmente em tarefas de autenticação. Em muitos casos, sistemas de autenticação exigem que os usuários digitem a senha com 100% de precisão. Estas exigências podem ser impactadas por outras demandas ambientais, como a memorização de informação ou fatores pessoais. Eficiência: enquanto os usuários utilizam um sistema para atingir um determinado objetivo, atingir este, por si só, não é suficiente. O objetivo deve ser alcançado dentro de níveis de tempo e esforço aceitáveis. O nível aceitável de tempo ou esforço no contexto de um sistema pode não o ser em outro. A eficiência é capturada através da medição de tempo para completar uma tarefa ou o número de cliques/ botões pressionados para atingir as metas exigidas. Memorização: muitos sistemas de autenticação exigem que os usuários memorizem segredos necessários para adentrar ao sistema. O número de segredos que um usuário é obrigado a guardar aumenta com o número de sistemas de autenticação diferentes que ele interage. Isso resulta em problemas de memorização, onde os usuários têm dificuldades para se autenticar em vários sistemas diferentes, muitas vezes requisitando opções de refazer as senhas. Habilidade: Isto é baseado na suposição de que os usuários vão aprender ou realmente tentar aprender e entender o sistema. Este pressuposto é falho particularmente em sistemas seguros. Usuários só se preocupam com as partes que eles acham que são importantes para as operações específicas que necessitam fazer, e em muitos casos as tarefas de segurança não são vistas como importantes. Estudos anteriores também descobriram que treinar os usuários na utilização de sistemas de segurança é ineficaz. Os fatores acima têm um efeito direto sobre a usabilidade de um sistema. Uma avaliação de usabilidade deve determinar quais os fatores que se aplicam a um software ou contexto específico. B. Segurança Atenção: os usuários podem facilmente se distrair e diminuir a atenção dedicada a determinada tarefa. Tarefas de segurança exigem atenção total dos usuários, pois do contrário, podem existir falhas de segurança. Vigilância: sistemas seguros tendem a esperar que os usuários estejam alerta e próativos de forma regular, o que é impossível. Tarefas que representam risco de segurança devem ser analisadas e integradas ao fluxo de trabalho dos usuários. Motivação: os usuários têm diferentes níveis de motivação para realizar as tarefas de segurança. Quando os usuários têm a noção de que os riscos são mais diretos a eles, se motivam para realizar tarefas com cautela.

5 Memorização: sistemas de autenticação muitas vezes exigem que os usuários memorizem senhas que são difíceis para alguém adivinhar ou até mesmo atacar com técnicas de força bruta (cracking). Como o número de segredos que os usuários têm que memorizar é grande (tendo em vista a grande quantidade de sistemas que são utilizados atualmente), pode se tornar difícil lembrar alguma senha em particular, especialmente se o sistema não é usado com frequência. Como medida de precaução, os usuários muitas vezes escrevam estas senhas em algum lugar. Isto por si só afeta a segurança do sistema, pois uma senha escrita pode ser encontrada por terceiros. Assim, corre-se o risco de que utilizem tais informações para fins maliciosos. Habilidade: o conhecimento dos usuários ou nível de habilidade desempenha um papel importante na segurança de um sistema. Muitos usuários digitam informações sensíveis em sites desprotegidos porque não têm o conhecimento necessário para distinguir entre um site seguro e um inseguro. Uma avaliação de um sistema seguro deve fazer perguntas como: Quem são os usuários? O que eles sabem sobre o sistema? O que eles deveriam saber? Contexto Social: os seres humanos são seres sociais. Eles ajudam uns aos outros e compartilham informações. Normalmente o compartilhamento é algo positivo. Porém pode vir a ser ruim para a segurança se os usuários compartilharem senhas ou procedimentos de segurança. Muitas vezes os usuários compartilham senhas quando alguém se oferece para ajudá-los com algum problema. A avaliação de um sistema deve analisar como o contexto social afeta a segurança. Condicionamento: tarefas repetitivas de segurança onde os usuários podem prever um resultado podem se tornar uma ameaça para a segurança de um sistema. Um exemplo comum são os pop-up que perguntam aos usuários se um determinado certificado é confiável ou não. Por vezes, ao interagir com tais pop-ups, os usuários percebem que clicar em um determinado botão fará com que o pop-up desapareça para sempre. A análise de segurança e usabilidade de um sistema deve avaliar se as tarefas de segurança têm potencial para condicionar os usuários. C. Métricas mensuráveis Para uma avaliação bem sucedida os elementos de segurança e usabilidade devem ser mensuráveis. A medição é crucial para a análise comparativa e quantificação básica de usabilidade e critérios de segurança. 1. Métricas de usabilidade: Cada fator de usabilidade pode ser medido e quantificado utilizando uma ou mais métricas que fazem parte desse fator. Podemos medir a eficácia através das taxas de sucesso das tarefas. A satisfação é uma medida subjetiva e pode ser mensurada através de questionários, escalas ou entrevistas. A precisão pode ser medida como a taxa de sucesso em tarefas que requerem certo grau de precisão. A eficiência do sistema é medida através do esforço que os usuários fazem para realizar uma tarefa e pode ser capturada através do tempo que o usuário leva para completar uma tarefa e, também, através do número de cliques ou teclas pressionadas. A

6 memorização pode ser mensurada pelo número de usuários que conseguem lembrar-se de uma senha previamente memorizada. 2. Métricas de segurança: fatores de segurança também devem ser mensuráveis. Podemos medir a atenção monitorando e determinando se uma falha de segurança ocorreu, ou não, devido à falta de atenção para alguma informação ou elemento específico, utilizando-se, por exemplo, do eye-tracking. Também podemos capturar índices de vigilância monitorando se os usuários consistentemente prestam atenção às tarefas de segurança. Esta informação também pode ser capturada através de questionários. Além disso, pode-se capturar o condicionamento analisando os erros dos usuários e determinando se os eventos anteriores tiveram efeito sobre a ocorrência destes. A motivação não pode ser medida diretamente, mas pesquisas mostram que a motivação para envolver-se em uma tarefa de segurança é dirigida pela percepção de suscetibilidade a ataques; os benefícios advindos das ações de segurança; facilidades de interação com os controles de segurança; e a gravidade de cometer-se uma falha de segurança (Ng et al., 2009). A mensuração de tais fatores permite observar a motivação dos usuários em executar tarefas de segurança de forma eficaz. Além disso, podemos capturar a memorização contando o número de ações corretas e perguntando aos usuários se eles têm problemas de memorização ou não, enquanto a habilidade pode ser capturada em forma de sucesso no desempenho de tarefas. Com base nos tópicos acima, para analisar a segurança e usabilidade de um sistema, utilizamos o conceito de cenários de uso (ou simplesmente cenários) e cenários de ameaça (negativa). Em nosso contexto, podemos definir cenários de uso como ações que são desejáveis para o sistema, e cenários de ameaça como ações que não são desejáveis e que, portanto, o sistema não deve permitir que ocorram, ao aplicar os tópicos anteriores. Enquanto cenários de uso e cenários de ameaça são tradicionalmente usados durante o levantamento de requisitos e no projeto de Design, aplicamos estes cenários também para a análise de segurança e usabilidade de um sistema também durante seu desenvolvimento, assim como após a finalização do produto, como análise contínua. Recomendações para o software O software utilizado neste caso é um gestor de submissões e recursos computacionais, que manipula uma grande quantidade de dados homogêneos e/ou heterogêneos distribuídos, para que diferentes unidades de processamento trabalhem cooperativamente para responder as requisições específicas de diferentes aplicações dos usuários do sistema. A natureza distinta dos usuários nas organizações leva à criação de diferentes políticas de utilização de recursos, segurança de acesso e controle dos recursos computacionais. Desta forma, podendo representar um obstáculo intransponível, para que essas configurações efetivamente possam processar cooperativamente com certo grau de desempenho as aplicações de diferentes usuários. Usuários diferentes têm necessidades diferentes e produtos interativos precisam ser projetados de acordo com tais necessidades (Preece et al., 2005). Em

7 especial, este fato é um complicador adicional para aqueles envolvidos no desenvolvimento e testes através de simulações, onde a quantidade de processamento e a capacidade de abstração do usuário são elementos essenciais e diferenciais para um bom resultado no tratamento dos dados para que informações relevantes sejam obtidas. O middleware proposto encarrega-se de conectar com as melhores opções de gerenciamento de recursos (exemplos LSF, TORQUE/PBS e Condor) e fazer com que a aplicação seja alocada no melhor ambiente disponi vel e ocioso. Deve-se entender que o sistema deverá fazer alocac aõ inclusive para ambientes onde não existe um gerenciador de recursos, que é, geralmente, o caso dos PCs rodando Windows e/ou Linux. Desta forma, o software busca facilitar a gestão de submissão, monitoramento e coleta de resultados das aplicac oẽs de reservas e reservatórios, tratando a complexa heterogeneidade dos dados e processamentos como um somatoŕio de partes de ambientes homoge neos. O diferencial da proposta de pesquisa e desenvolvimento do LaPeSD (Laboratório de Pesquisa em Sistemas Distribui dos) da Universidade Federal de Santa Catarina se concentra na elevação da abstração da execução dos aplicativos e simulações para um ni vel em que os recursos devem ser solicitados, mesmo por ma quinas do tipo PC executando Windows e/ou Linux. Por ser um software importante para a organização que o utiliza, envolve fatores críticos para a pesquisa e desenvolvimento de novas ações para exploração de reservas de petróleo. Sendo esses: tomada de decisões, recursos de tempo e energia e etc. O software se caracteriza como um sistema seguro e pode ser abordado por meio do modelo apresentado anteriormente. A fim de determinar quais cenários de uso e ameaças devam ser abordadas em primeiro lugar, estes podem ser elencados usando uma matriz de nível de risco (Stoneburner et al., 2002). Usando tal matriz, cada situação pode ser classificada de acordo com sua probabilidade de impacto sobre o sistema. Assim, utiliza-se o modelo de abordagem aqui apresentado, adaptado ao presente projeto, seguindo a lógica da ISO , sobre as diferenças de contexto e suas implicações. Depois da realização de pré-testes feitos com um protótipo do software, onde pudemos definir os cenários de uso e de ameaça, elencamos tópicos que representavam as maiores problemáticas do sistema e onde nossos esforços se concentrariam: 1. Memorização; 2. Atenção; 3. Responsabilidade. Chegamos então às recomendações finais, tendo como base todas as etapas anteriores. Abaixo a descrição das ações específicas para suprir deficiências do sistema: Manutenção de um controle sobre as senhas dos usuários e de suas atividades no sistema, através da geração de relatórios que os administradores possam acessar. Assim, evitam-se problemas como, por exemplo, criar um acesso por meio de senhas e permitir que os usuários escolham seus próprios códigos, o que poderia facilitar ameaças de invasores usando ferramentas para cracking. Adição de um controle de segurança para ativar o estado de atenção do usuário, através da confirmação da intenção em executar atividades críticas, que exijam muito poder de processamento ou que levem muito tempo para serem executadas.

8 Dificultando, assim, o engajamento em atividades de forma displicente ou nãointencional, o que leva à maior eficiência e eficácia no uso do sistema. Melhorias para a tela de submissão de atividades a serem escalonadas e executadas pelo software, cuidados específicos com as formas de expor as informações, para que sejam quanto mais claras possíveis, evitando erros de interpretação. Além disso, antes de efetivamente executar a ação, o sistema deve pedir ao usuário para revisar todos os parâmetros de processamento incluídos na submissão da tarefa. Criação de um histórico de atividades que traga junto das ações os nomes dos usuários que as executaram. Espera-se assim desenvolver um foco na responsabilidade sobre as atividades desenvolvidas no sistema que poderão ser catalogadas e vistas a qualquer momento, pelos colegas e superiores. Conclusão Utilizamos um modelo de abordagem de Interação Humano-Computador e Segurança (IHCSec) para implementar controles em um software e torná-lo mais seguro e eficaz. Empregamos cenários de uso e cenários de ameaças para compreender e identificar elementos que prejudicam a usabilidade e a segurança, tanto internos ao sistema quanto externos. Após as implementações de correções no sistema, concluímos que é pouco provável eliminar por completo as ameaças, tanto externas quanto internas. Trata-se de uma tarefa infinita de avaliação-correção, e na maioria das vezes, deverão haver compensações entre segurança e usabilidade. O objetivo, portanto, é minimizar tanto quanto for possível os cenários de ameaça e maximizar a acessibilidade dos cenários de uso, levando-os a níveis aceitáveis, que variam de caso para caso e precisam ser avaliados com base no sistema, seu contexto e nas tarefas a serem desempenhadas nestes sistemas. Este é um esforço inicial na implementação e estudo de padrões de segurança no Design de Interação e análise de segurança e de usabilidade em projetos de softwares seguros. Em futuros trabalhos serão adicionadas recomendações mais práticas, como elementos visuais e design de comportamentos em objetos e suas reações às ações dos usuários a sistemas seguros. Referências ALEXANDER, I., NEIL, M. Scenarios, Stories and Use Cases. John Wiley, FLECHAIS, I. Designing secure and usable system. Tese de Ph.D. Universidade de Londres, ISO Ergonomic Requirements for Office Work with Visual Display Terminals. T. I. S. Organisation, 1998.

9 KAINDA, R., FLECHAIS, I., ROSCOE, A. W. Security and Usability: Analysis and Evaluation. In: ARES 2010, Fifth International Conference on Availability, Reliability and Security, p , Polônia, IEEE Computer Society. NG, B-Y.; KANKANHALLI, A.; XU, Y. C. Studying Users Computer Security Behavior: A Health Belief Perspective. In: Decision Support Systems, vol. 46, no. 4, p , Disponível em: < Acesso em: 16 ago NIELSEN, J. Usability Engineering. Londres : Academic Press, PREECE, Jennifer; ROGERS, Yvone; SHARP, Helen. Design de Interação: Além da Interação homem-computador. Editora Bookman, São Paulo: SHACKEL, B. Usability context, framework, definition, design and evaluation. In: Human factors for informatics usability. p , Cambridge University Press New York, Nova Iorque. STONEBURNER, G., GOGUEN, A., FERINGA, N. I. Risk Management Guide for Information Technology Systems. Recomendações do Instituto Nacional de Regulamentos e Tecnologia. Departamento Norte-americano de Comércio, Gaithersburg, YEE, K. P. Aligning Security and Usability. In: IEEE Security & Privacy, vol. 2, no. 5, pp , WHITTEN, A. Making Security Usable. Tese de Ph.D. Carnegie Mellon University, 2004.