Uma Definição Operacional Sucinta e Prática para "Segurança"

Além de filosófico, o artigo de hoje é um tanto ambicioso: tentarei propor uma definição genérica para "segurança" que seja sucinta mas abrangente, didática mas rigorosa, e que encaixe bem tanto com as noções intuitivas que todo mundo tem, tanto com seu uso em segurança de sistemas de informação e outras áreas correlatas. Tento, com isso, preencher uma lacuna esquisita: dentre as dezenas de livros de "segurança" e artigos técnicos-científicos que li ao longo dos anos, não me lembro de nenhum que tenha oferecido uma definição que eu tenha achado satisfatória do que seja essa tal de "segurança".

Tenciono conseguir essa aparente façanha apelando para um artifício conhecido como "definição operacional". Resumidamente, consiste em definir uma coisa em termos do que se precisa fazer para obtê-la – algo vagamente semelhante a definir "peso" como "o número que aparece na balança". Não é tão filosoficamente bonito quanto definir "peso" como "a força que surge em um corpo imerso em um campo gravitacional", mas é bem mais prático de usar. O mesmo acontecerá com nossa definição operacional de segurança: ela não vai ser "perfeita" e talvez nem mesmo filosoficamente elegante, mas tentarei mostrar através de alguns exemplos que ela se sai muito bem na prática.

A Forma Restrita

Indo direto ao assunto, segue abaixo a minha versão favorita da "Definição Operacional de Segurança", no que chamamos de "forma negativa restrita":

"Segurança consiste em ter salvaguardas racionais de que certos eventos indesejados específicos não vão acontecer."

Como vai ficar claro ao longo da discussão, essa definição funciona igualmente bem na chamada "forma positiva": "segurança consiste em ter garantias de que certos eventos desejados específicos vão acontecer".

Há uma certa flexibilidade para variações na escolha exata de certas palavras. Por exemplo, alguns amigos preferem "evitar que certos eventos aconteçam"; pessoalmente, eu evito a palavra "evitar" porque observei que ela gera rejeição entre os praticantes de segurança reativa. Outra variação comum é usar a palavra "garantias" ao invés de "salvaguardas". Eu tenho preferido "salvaguardas" porque "garantias" passa uma idéia de "garantia absoluta" que muita pouca coisa tem, ao passo que "salvaguardas" soa mais brando – as pessoas parecem ter mais facilidade em admitir que uma "salvaguarda" não é "perfeita" nem "absoluta". Por outro lado, um amigo meu prefere "contramedidas" ao invés de "salvaguardas". Portanto, pense nessa definição mais como um "modelo" (no sentido de "template") que você pode adaptar como achar melhor. Todavia, vou tentar ilustrar por que essa é minha versão predileta.

Interpretação Preliminar

A palavra "racionais" na expressão "salvaguardas racionais" tem um significado profundo. Há quem defenda que ela poderia ser retirada e deixada implícita, mas eu faço questão de colocá-la. Com ela, estamos querendo dizer que daremos preferência a uma abordagem desapaixonada, analítica, metódica e sistemática; e lançaremos mão de várias ciências – matemática, estatística, psicologia e várias outras – para nos auxiliar.

Por outro lado, essa ênfase na racionalidade significa despojar-nos de preconceitos, crendices, "achismos", modismos e, acima de tudo, ter a coragem de sair da nossa "zona de conforto". Para criaturas eminentemente emocionais como nós, seres humanos humanos, e para uma área mais ditada por moda do que a própria indústria de moda, como é a informática, essa racionalidade que a nossa definição demanda é uma exigência dura, mas absolutamente imprescindível para separarmos as ilusões da realidade.

O cerne da nossa definição obviamente está em listarmos quais são esses tais "eventos específicos" que queremos ou não queremos (dependendo se estamos usando a forma positiva ou negativa) que aconteçam. Aqui a palavra "específicos" nos dá a dica que devemos adotar uma abordagem "de baixo pra cima" ("bottom-up"): devemos começar com coisas pequenas, as mais simples, exatas e específicas possíveis, para então podermos partir para generalizações cada vez mais abrangentes.

Um Exemplo Elementar

Vamos trabalhar um exemplo simples: como posso ter segurança contra indisponibilidades do meu computador causada por faltas de luz de até dez minutos? Bem, se for um computador de mesa, podemos ligá-lo em um UPS (conhecido aqui no Brasil como "No-Break")1. E se for um notebook, eles já vêm com bateria embutida. A maioria delas tem autonomia superior a 10 minutos; então, nesse caso, temos, sim, um certo tipo de "segurança" contra esse "evento indesejado específico" que é "falta de luz por até 10 minutos".

Mas, se quiséssemos segurança contra faltas de energia de até 20 horas, as baterias que tipicamente vêm nos "no-breaks" ou notebooks normalmente não aguentam tanto – ou seja, não teríamos "segurança" contra a indesejada falta de energia. Aí seria o caso de dimensionar o banco de baterias para dar a autonomia desejada. Isso nos levaria à discussão de que ficaria caro, ou sobre outras questões operacionais, como durabilidade e ciclo de manutenção (as baterias envelhecem e precisam ser substituídas após alguns meses).

Note bem o que fizemos: definimos um requisito razoavelmente preciso ("segurança contra falta de luz de até X horas") e começamos a discutir as limitações e implicações deles, usando o que se sabe sobre a ciência, técnica e histórico dos "no-breaks" conhecidos. É claro que poderíamos ser muito mais precisos do que isso: por exemplo, poderiamos amparar essas afirmações com o consumo dos computadores "protegidos" medidos em watts ou volt-ampères e contrastá-los com a capacidade das baterias em ampères-hora versus a eficiência da conversão do modelo específico do "no-break" que pretendemos usar versus fator de potência das fontes dos computadores – questões estudadas pela engenharia elétrica, uma ciência muitíssimo bem estabelecida. Mas não vou entrar nesses detalhes aqui; para meus propósitos hoje, basta que o leitor vislumbre que esse tipo aprofundamento poderia ser desejável em um caso real.

Repare como a especificidade ajuda: se eu tivesse dito "quero segurança contra falta de luz", sem qualificar por quanto tempo, propor o "no-break" como "salvaguarda" não chegaria a ser de todo inútil, mas ficaria bem mais vago. Se disséssemos, "quero que o sistema não pare", ficaria ainda mais vago: falta de luz seria apenas uma dentre muitas coisas que poderiam fazer o sistema parar. E se pedirmos "segurança" ou que algo seja "seguro", sem qualificação, a coisa fica tão vaga que cai no vazio.

A lição aqui é: quando formos pedir "segurança", é imperativo que tentemos especificar "contra o que", "por quanto tempo", "em que circunstâncias" e "sob que condições" da maneira mais precisa que nos for possível.

Múltiplos Eventos Indesejados

Vamos retornar ao exemplo acima da segurança contra falta de luz, mas agora adicionando os fatores "custo" e "esforço": quero não apenas segurança contra falta de luz por vinte horas, mas quero também segurança de que o custo de aquisição da operação não exceda R$ 100,00: temos agora duas coisas que não queremos que aconteça, em um caso clássico de conflito de requisitos: pois mais autonomia significa mais custo. Pior ainda, é um conflito do pior tipo: o sem solução – não conheço nenhuma solução que custe menos de R$ 100,00 que mantenha um computador tipo "notebook" ou "desktop" típico funcionando sem energia elétrica da tomada por 20 horas.

A jogada aqui foi formularmos questões como "custo", "esforço" e "prazo" em termos de "segurança contra ficar caro demais", ou "segurança contra levar tempo demais pra implementar". Nossa definição operacional de segurança é abrangente o bastante para englobar esse tipo de coisa sem "forçadas de barra".

Quando entramos em uma situação dessas em que o conflito não tem solução, teremos de relaxar algum dos requisitos e vem a hora de priorizar. Existem meios de obtermos 20 horas de autonomia, mas, pra isso, vamos ter de relaxar as restrições de custo. Também existem meios de se obter um custo total de até R$ 100,00, mas aí teremos de aceitar uma autonomia menor.

Ou talvez pudéssemos jogar com outra variável: o consumo de energia – tablets consomem muito menos energia que notebooks, que por sua vez consomem bem menos que computadores "de mesa" ("desktops") convencionais. Se na nossa aplicação pudermos usar tablets, poderíamos chegar bem mais perto do R$ 100 para 20 horas de autonomia do que com computadores. Mas, naturalmente, isso só funcionaria já tivéssemos o tablet, pois senão teríamos que considerar o custo de aquisição dele e estouraria os R$ 100 de orçamento do mesmo jeito.

Há ainda outra variável com a qual podemos jogar: o tempo. Talvez não haja solução para nosso conflito hoje, o que pode fazer com que a melhor linha de atuação seja adiar a solução até que a evolução da tecnologia ou recursos talvez nos traga uma solução aceitável. Ou talvez ainda a ausência de solução simplesmente nos impeça de fazer o que queremos porque não apenas há solução agora, mas porque nenhuma se apresenta no horizonte.

A lição aqui é que especificidade permite tratarmos os requisitos com muito mais embasamento e propriedade. Mesmo dentro de limitações técnicas, econômicias, etc., costuma haver espaço para "jogarmos" com as variáveis e pensarmos em soluções, desde as mais convencionais (desktop com alguns segundos de autonomia a R$ 100,00), até as mais criativas (tablet ao invés de desktop para termos mais autonomia pelos mesmos R$ 100,00).

Alguns Outros Exemplos Intuitivos

Ouço muita gente aqui em Recife dizer que "falta segurança" na cidade. O que eles querem dizer com isso? Da nossa discussão acima, vimos que, formulada dessa maneira vaga, só podemos dar palpites: eu diria que é mais provável que eles queiram dizer "segurança contra assaltos" ou "segurança contra violência urbana" do que "segurança contra acidentes de trânsito", embora esta última me parece uma resposta igualmente válida. Veja o que fiz: tentei preencher a falta de especificidade com o que conheço sobre as ansiedades dos meus concidadãos. Todavia, se eu estivesse entre os esquimós do ártico, talvez eles achassem que a "segurança" que "falta" fosse "contra morrer de frio".

A flexibilidade na formulação da lista de eventos indesejados permite tratarmos igualmente bem aspectos preventivos versus reativos. Por exemplo, não dá para prevenirmos batidas de carro absolutamente, pois não depende só da gente – estamos sujeitos a fatores fora do nosso controle, tal como os erros dos outros motoristas. Mas, se reformularmos a coisa como "segurança contra a perda financeira" advinda de uma batida, caímos exatamente no que fazem as empresas seguradoras: elas nos "ressarcem" caso aconteça algum "sinistro" (que é o termo que elas usam para os "eventos indesejados", tais como batidas, roubos, etc.)

Aliás, esse é um exemplo interessante porque também ilustra como diferentes atores desejam "segurança" sob diferentes aspectos: nenhuma seguradora paga integral nem incondicionalmente o valor do carro; se ela o fizesse, toda vez que você quisesse trocar de carro, bastaria jogá-lo de um precipício ou tocar fogo nele e a seguradora te pagaria outro. Ou seja, a seguradora também precisa ter "segurança contra o próprio segurado" – que, novamente, ilustra o caso dos quesitos conflitantes e a necessidade de se atingir um meio-termo confortável entre eles.

Indo além, o segurado também precisa ter "segurança que a seguradora honre a apólice" (note o uso da forma positiva). Por exemplo, o que fazer se a seguradora falir? Daí advém toda a indústria de resseguros.

A Forma Geral

A arte da aplicação desta definição está na lista de eventos indesejados e nas salvaguardas que vamos adotar para cada um deles. Dá pra intuir que, em casos reais, essa lista tende a ser longa, que a priorização dos conflitos gera dilemas espinhosos e que a discussão sobre quais salvaguardas adotar, seus méritos e eficácias relativas, etc., gera quebra-cabeças formidáveis que requerem muita pesquisa, testes e experimentação. De fato, há toda uma indústria de consultorias e serviços agregados para fazer esse tipo de trabalho.

Uma consequência disso é aquele célebre clichê de que "nada é 100% seguro": você consegue realmente ter certeza que sua lista de eventos indesejados é exaustiva? Ou seja, você consegue mesmo garantir que não deixou de considerar nenhuma possibilidade? Não existe absolutamente nenhum jeito de as coisas darem errado além dos que você previu? Suas contramedidas tratam absolutamente todos os casos e funcionam inconcidionalmente e por tempo ilimitado?

Isso me dá a chance de concluir o artigo apresentando a "forma geral" da nossa definição operacional, que difere na forma restrita em apenas algumas poucas palavrinhas, abaixo destacadas em negrito:

"Segurança consiste em ter um conjunto abrangente e balanceado de salvaguardas racionais de que certos eventos indesejados específicos não vão acontecer."

Aqui adotei novamente na forma negativa, mas também funcionaria perfeitamente bem na "forma geral positiva". Acho que, em vista de tudo que discutimos acima, o significado e a importância da expressão "conjunto abrangente e balanceado de salvaguardas" ficam claras: quanto mais abrangentes forem nossas salvaguardas, menos chance de sermos surpreendidos por um imprevisto; e se não tivermos um balanceamento – ou seja, se formos muito bem defendidos sob um certo ponto de vista mas muito despreparados sob algum outro critério – então, não teremos atingido a "verdadeira segurança", pois há pelo menos uma faceta pela qual estamos desguarnecidos e vulneráveis.

Apesar de eu achar que a arte de se atingir a "verdadeira segurança" e a nobreza do trabalho de um engenheiro de segurança está justamente na obtenção e manutenção desse "balanceamento abrangente de contramedidas", eu costumo evitar apresentar a forma geral para "novatos". Há duas razões pra isso: uma prática, e outra psicológica. A prática é que, na minha experiência, tratar a questão com uma abordagem "de cima pra baixo" ("top-down") tende a gerar formulações vagas e imprecisas, que vão contra o princípio da especificidade que defendi aqui.

A segunda razão, de natureza psicológica, é que a aplicação da definição na sua forma geral tende a "assustar" as pessoas: ao se depararem com uma lista gigante de coisas aparentemente díspares, muitas delas territórios desconhecidos para elas, faz com que tenham a impressão de ser trabalho demais, uma guerra invencível. Muita gente ainda tem expectativas irreais de que "faça esse 'dever de casa' ou instale esse programa/sistema e estará seguro"; desafiar essa noção frontamente choca e gera rejeição. Já usando a definição restrita, focando em aspectos específicos estrategicamente bem escolhidos, tenho observado que dá pra ganhar algumas batalhas antes que o exército se dê conta da imensidão da guerra, o que faz bem para o moral da tropa.

Pontes com Outras Áreas e/ou Abordagens

Se você trabalha com arquitetura de software e ficou com a impressão de que esse meu papo sobre "listas de eventos indesejados e contramedidas" se parece vagamente com o que se faz em engenharia de requisitos, eu estaria disposto a dizer que há muitas semelhanças entre as duas atividades.

Se você é da área de segurança de sistemas de informação e achou tudo isso parecido com o que se conhece por "modelagem de ameaças", eu também diria que é mais ou menos por aí, a despeito de eu ter sérios senões quanto à maioria das metodologias específicas que eu já vi. Mas eu estaria disposto a tolerar a simplificação meio forçada de que essa nossa definição de segurança é mais ou menos equivalente a dizer "você tem segurança se fez seu dever de casa em bolar um modelo de ameaças e contramedidas adequadas para cada uma delas".

Os mais eruditos poderão até notar que esse estilo "de baixo pra cima" ("bottom-up") de começar por coisas específicas e ir agrupando e priorizando para se chegar a uma visão mais abrangente se parece muito com a metodologia de "Attack Trees" proposta pelo Bruce Schneier. Eu estaria disposto a dizer que a essência da idéia é basicamente a mesma, muito embora eu ache que a organização da coisa está mais para um grafo do que uma árvore, e que eu acho que os conectivos são muito mais variados do que apenas ANDs e ORs.

Os leitores argutos também notarão uma característica útil da nossa definição: ela dispensa termos de definir logo de saída coisas como risco, dano, vulnerabilidade, ataque, ameaça, etc; podemos incorporar essas coisas dentro da nossa lista de eventos indesejados, da forma que nos for mais conveniente para cada contexto. Minimizar a complexidade (ou melhor, adiá-la) é um resultado comum da "trapaça" de se utilizar definições operacionais.

Conclusões e Leituras Adicionais

Para não tornar este artigo excessivamente longo, tive de me limitar a alguns poucos exemplos curtos e relativamente triviais. Se o leitor quiser ter um gostinho de como se parece uma lista de eventos indesejados para um caso real um pouco maior (mas nem tão grande assim), sugiro ler o primeiro artigo da série do NASDEC: nele, eu discuto o que quero e encerro com uma lista razoavelmente curtinha (ainda que meio vaga) de eventos indesejados dos quais quero me proteger ao criar um armazém de dados duradouro. Caso queira ver as contramedidas específicas e como elas foram implementadas, leia a série inteira – ficará claro o quão fundo se precisa ir para se conseguir a tal "segurança".

Para ver um exemplo decentemente bem trabalhado de uma "lista de eventos indesejados" em uma aplicação real publicamente disponível na Internet, veja o "modelo de ameaças" do I2P (uma rede de anonimização ao mesmo tempo parecida, ao mesmo tempo diferente, do seu "primo" mais famoso, o Tor). Note como eles tentam vislumbrar a quantidade mais abrangente possível de ataques e discutir as contramedidas que adotam, os fatores mitigantes, etc.

Em artigos futuros, terei oportunidade de discutir exemplos mais complexos da aplicação dessa nossa definição operacional e como ela se encaixa na obra de vários pensadores, estudiosos e praticantes de vários tipos de "segurança". Por hoje, fico satisfeito se tiver conseguido convencer o leitor a tentar aplicar essa definição à sua realidade e me contar como ela se sai.



1 O nome correto é UPS, sigla de "uninterruptible power supply" ou "fonte de alimentação ininterrupta", mas aqui no Brasil há um hábito de chamá-los de "No-Breaks" [ voltar ]

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
enildo | 2012-01-25 17:56:43 | permalink | topo

Mestre Kiko, demorei para ver o artigo, mais gostei do que li.

Marco Carnut | 2011-12-09 11:27:08 | permalink | topo

Ricardo,

Acho que entendi o que você quis dizer: a forma restrita é de aplicabilidade tão geral quanto a forma geral, pelo menos do ponto de vista filosófico :)

Talvez a nomenclatura "forma restrita" e "forma geral" não tenha ficado muito boa – aceito sugestões de como mudá-la para refletir isso. Eu as empreguei do ponto de vista de "especificidade": a forma restrita tenta forcar em aspectos específicos com escopos restritos. A forma geral tenta se aproximar assintoticamente da "verdadeira segurança", abrandgente e universal, daí o termo "geral". Mas, sem dúvidas, as duas são gerais em termos de aplicabilidade filosófica.

Mas no que tante à aplicabilidade prática, eu estaria disposto a afirmar que a forma restrita é mais aplicável do que a forma geral, porque a especificidade promove resultados rápidos e bem delineados, ao passo que a forma geral, com sua característica "assintótica" de eternamente se aproximar mas nunca chegar à "verdadeira segurança", acaba sendo menos prática na prática, se me perdoa o trocadilho. :)

É por isso que eu não me canso de discutir esse assunto – toda vez que eu acho que já o examinei sob todos os ângulos, vem alguém como você e me mostra um ângulo que eu nunca tinha pensado antes.

-K.

Ricardo Ulisses | 2011-12-08 19:23:27 | permalink | topo

Kiko,

Eu já havia sido apresentado a sua definição operacional restrita de segurança e quero registrar que sempre que a leio ela própria me soa "abrangente e balanceada", tal qual a definição geral :)

Confesso que ao ler o texto fiquei curioso em entender o porquê da qualificação da primeira versão como "restrita". Ao comparar ambas as definições e as explicações que as cercam, fico com a sensação de que a versão geral é mais restrita (ou específica) que a própria versão restrita.

Ainda assim, entendo que a classificação como restrita e geral estão mais relacionadas ao seu uso irrestrito (isto é, sem ressalvas e explicações adicionais ao leitor delas), não ao fato de qual tem escopo mais delineado que a outra.

Enfim, o que fica é que segurança é algo a ser discutido com limites bem definidos, do contrário, como você escreveu com propriedade, a coisa fica tão vaga que cai no vazio.