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.

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:

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.

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.