Segurança: Uma Linha Fina Entre a Vida e o Caos

Um episódio da história da aeronáutica – e da guerra – ilustra de uma maneira muito gráfica a curtíssima distância entre o yin e o yang.

Boeng B-17 – Imagem: Wikimedia Commons

Na Segunda Guerra Mundial, o Boeing B-17 Flying Fortress foi o bombardeiro padrão dos EUA. Como seria de esperar, muitos deles foram perdidos durante o combate, mas muitos também foram perdidos depois de completada a missão, ao pousar de volta à base. Culpa dos pilotos, clamavam uns. Culpa da formação, clamavam outros. Culpa da manutenção, diziam outros mais. Até a qualidade das pistas recebeu seu quinhão de culpa. Mas nenhuma hipótese era suportada por qualquer tipo de evidência.

Depois da guerra, finalmente tiveram tempo de fazer uma nova investigação para tentar entender o que realmente tinha acontecido.

A linha fina

Imagine que você esteve a participar de um bombardeio estressante por doze horas. Você está cansado. Está escuro. Está chovendo e você está na aproximação final da sua base. Você estende a mão para acionar o interruptor que engata o trem de pouso e, de repente, com uma guinada brusca, sua aeronave estola e bate no chão, matando todos a bordo. Esta imagem do painel de instrumentos do cockpit do B-17 mostra o que o piloto estaria vendo nesse momento:

Painel de instrumentos do B-17

Não há quantidade de treinamento no mundo que possa compensar essa falha de design. Não há nada para impedir que o erro mais banal se transforme em uma catástrofe. O interruptor ‘pouso tranquilo’ (opera o trem de pouso) e o interruptor ‘morte horrível’ (opera os flaps) são muito próximos um do outro, e idênticos.

“Culpar os usuários por não serem capazes de operar com segurança um projeto terrivelmente mal desenhado.” Já ouvimos isso antes.

Essa investigação levou a algo chamado “codificação de forma” que persiste até hoje como uma linguagem de design. A maioria das aeronaves modernas acionam o trem de pouso através de uma alavanca com um pequeno ressalto em forma de roda na extremidade; quando você toca na alavanca, você sabe o que está segurando. O controle dos flaps é hoje um grande tarugo quadrado e – adivinhe – eles não estão próximos um do outro. O mundo aeronáutico aprende com seus erros.

Alavancas para trem de pouso e flaps, depois de revisadas.

Aplicar o exemplo na cultura digital

Na segurança cibernética, criamos soluções sofisticadas para problemas incrivelmente difíceis, gerenciamos riscos capazes de dar nó no estômago de um camelo e levamos os computadores a fazer coisas que ninguém pensava ser possível (ou mesmo desejável). Mas também continuamos a fazer exigências ridículas aos usuários: faça isso, não faça aquilo, não clique em links, repeite a política de senhas…

Fornecemos aos usuários alavancas mal projetadas. Esperamos que implementações de tecnologia arbitrariamente complexas sejam perfeitas e livres de vulnerabilidades a longo prazo. Ao mesmo assumimos uma postura crítica quando o software que recebemos sem custo da comunidade open-source falha ao sofrer um ataque organizado por um estado-nação como a Rússia.

Aqui há uma dissonância cognitiva interessante, mas não encontrei uma maneira de identificar quais são nossas falsas expectativas tecnológicas; quando estamos a exigir da tecnologia coisas idiotas. O mais próximo que eu chego disso é tentar determinar onde está o ônus da segurança e se é razoável pedir à parte interessada que o assuma.

É razoável pedir a uma empresa de dez pessoas que se defenda dos russos?

Não.

É razoável pedir a uma empresa de infraestrutura crítica que não conecte seus sistemas sensíveis à Internet com a senha ‘Senh@01-08-2002‘?

Com mil demồnios, claro que é!

É preciso trazer para a o design de UI (interfaces gráficas), uma área particularmente sensível ás questões de segurança, conceitos equivalentes à citada codificação de forma – como a usada nas outras engenharias – no desenvolvimento de sistemas digitais seguros. O caminho crítico para tornar a segurança cibernética escalável a longo prazo é colocar as várias responsabilidades de segurança nos lugares certos e incentivar adequadamente as pessoas que precisam gerenciar essas responsabilidades. Às vezes, a pessoa óbvia para gerenciar o ônus da segurança não será a pessoa ideal para o cargo. É preciso então mudar as coisas para que elas sejam melhor dimensionadas e se adaptem ao ambiente.

Sendo uma atividade humana, o campo da segurança cibernética também sofre muito com o pensamento de manada, apego ao passado e argumentos de autoridade. Então, deixo aqui uma ideia – ou apelo. A comunidade de segurança cibernética deve:

  • conversar com pessoas não-técnicas e realmente ouvi-las
  • construir coisas que funcionem para a maioria das pessoas, na maioria das vezes
  • se colocar no lugar dos usuários
  • perguntar se realmente estamos sendo sensatos em nossas expectativas quanto ao comportamento do usuário

Ainda não chegamos a isso.

Multiplique sua Estimativa por Pi

A estimativa de projetos é uma arte hermética, em nenhum lugar isso é mais verdadeiro do que no desenvolvimento de sistemas computacionais. Certa vez, ouvi falar de uma misteriosa confraria de numerólogos, que multiplicavam suas estimativas de tempo por π. A prática supostamente dava a eles uma margem de segurança suficiente para definir novos requisitos, testes, iteração e outras mudanças aleatórias no escopo do projeto.

Imagem: Pexels

Isso me pareceu curioso e arbitrário, mas fiquei intrigado. Depois de refletir um tanto, pude colocar a conjectura da estimativa circular (CEC) em bases matemáticas sólidas.

Alguém – um designer, seu líder, o produtor executivo, um amigo, sua mãe – pede que você faça algo. Você pensa um pouco, faz algumas anotações, considera o que é necessário e apresenta um projeto e uma estimativa de tempo para a conclusão.

Mas as coisas mudam. Acontece que havia algumas coisas que seu designer/ líder/produtor/ amigo/mãe esqueceu de mencionar e, à medida que você fazia o trabalho, sugiram algumas ideias para estender o projeto um pouco mais. Seu escopo cresceu.

E é claro que nem tudo correu bem. Sua primeira tentativa foi um fracasso [instrutivo]. Então você focou na segunda tentativa e acabou criando uma serie de problemas que demoraram um tanto mais para serem ajustados. Você gastou dois dias extras para encontrar uma solução alternativa. Em suma, você seguiu um caminho positivamente tortuoso até seu objetivo.

Quanto tempo demorou a sua jornada em comparação com o plano original? Parece que os numerólogos estavam certos…

E aí está – não importa o que você pense quando começa um projeto. Depois de passar pela pesquisa, design, discussões, protótipos, falhas, testes, rotatividade de requisitos e todos os outros caprichos do processo criativo, você certamente terá gasto π vezes o tempo que você planejou originalmente.

Alguns podem questionar meu rigor matemático e até mesmo contestar o que acredito ser a conclusão incontestável. Alguém poderá alegar que o multiplicador correto não é de fato π – mas 2, ou √2, ou e, ou a razão áurea φ. No entanto, não conheço ninguém que chegue a alegar que o multiplicador seja < 1.

Independentemente de quaisquer inclinações numerológicas, o argumento é que você se permita admitir que no início de um projeto você a) não tem o panorama completo, b) você não sabe como as coisas vão se encaminhar, e c) há trabalho pela frente sobre coisas que você ainda não tem ideia.

Nenhuma quantidade de planejamento e análise de tarefas pode mudar isso, então não tente. Em vez disso, dê a si mesmo uma reserva de tempo plausível e então mergulhe no trabalho.

Ah, e aquela lista de tarefas que você fez no fim de semana passado? Não é por acaso que você conseguiu concluir apenas cerca de um terço dos itens da lista. 😉