Segurança através da obscuridade é subestimada

Em segurança da informação, desenvolvemos uma série de axiomas que não são aceitos para argumentar:



  • Nunca implemente sua própria criptografia.

  • Sempre use TLS.

  • A segurança pela obscuridade é ruim.


Etc. A maioria deles está geralmente correta. No entanto, parece-me que as pessoas estão seguindo cegamente esses axiomas como um culto à carga. E muitos realmente não pensam sobre as exceções à regra. Neste artigo, levantarei minhas objeções à ideia de que a segurança através da obscuridade é ruim.



Risco, defesa em camadas e queijo suíço



Uma das principais tarefas da segurança da informação é reduzir os riscos. De acordo com a metodologia OWASP, o risco de um problema é calculado usando a fórmula:



Risco = Probabilidade * Impacto


Por essa fórmula, o problema de execução remota de código (RCE) apresenta um risco maior do que o problema de script entre sites, porque o RCE tem um impacto maior. Tudo é simples aqui. Mas e quanto à métrica de probabilidade? De acordo com o OWASP, a probabilidade é definida da seguinte forma:



No nível mais alto, é uma estimativa aproximada das chances de uma vulnerabilidade específica ser divulgada e explorada por um invasor.


Portanto, se reduzirmos a probabilidade, reduziremos o risco geral. É bom. Na verdade, é muito semelhante ao conhecido conceito de "defesa em profundidade". É também denominado "modelo de queijo suíço".







De acordo com este modelo, você precisa construir mecanismos de defesa em um modelo em camadas de forma que mesmo se um invasor passar o primeiro nível, ele será interrompido em outros.



Segurança através da obscuridade



Então, vamos falar sobre segurança na obscuridade. É uma má ideia usá-lo como sua única camada de proteção. Se o invasor passar por ele, nada mais o protegerá. Mas, na verdade, não é ruim como um nível "adicional". Porque tem baixo custo de implantação e geralmente funciona bem.



Vamos considerar vários cenários:



  • No meu servidor, o SSH é executado na porta padrão 22 e nas credenciais root:123456. Qual é a probabilidade de compromisso?


A probabilidade é quase 100%, uma vez que hackers em toda a Internet são serviços de força bruta com credenciais padrão.



  • SSH é executado na porta 22 e nas credenciais utku:123456. Qual é a probabilidade de compromisso?


Bem, eliminamos o perigo da força bruta com credenciais padrão. A probabilidade e o risco são reduzidos. No entanto, ainda enfrentamos uma tonelada de ataques direcionados. Alguém pode adivinhar o nome de usuário utku, já que esse é meu nome verdadeiro.



  • SSH é executado na porta 64323 e credenciais utku:123456. Qual é a probabilidade de compromisso?


Mudamos o número da porta padrão. Isso vai ajudar? Primeiro, eliminamos o perigo da força bruta padrão mais uma vez, uma vez que ela verifica apenas as portas comuns. E quanto ao resto? Fiz uma pequena enquete no meu twitter para descobrir o comportamento das pessoas ao escanear portas.





Como você pode ver, muitos tendem a verificar apenas as portas padrão e mais populares. Portanto, se você alterar a porta de 22 para 64323, eliminará alguns dos ataques em potencial. Você reduzirá a probabilidade e o risco.



O mesmo é verdadeiro para vulnerabilidades de software. Se uma vulnerabilidade for encontrada no Microsoft Remote Desktop Protocol, toda a Internet começará a verificar a porta 3389. Você pode reduzir os riscos simplesmente alterando a porta padrão.



Outras aplicações



Claro, além de alterar os valores padrão, você pode usar a mesma metodologia em outras áreas. Em alguns casos (nem sempre), as seguintes idéias podem ser aplicadas.



  • Ofuscação de código : claro, isso é de conhecimento comum. Hackers também são pessoas. Se você ofuscar bem o seu código, eles terão que gastar mais tempo procurando problemas. Eventualmente, eles podem desistir.

  • Nomes de variáveis ​​aleatórias para um aplicativo da web : você pode usar caracteres aleatórios em vez de nomes de variáveis ​​amigáveis. Pode ajudar da mesma forma que a ofuscação de código.

  • : encryption_algorithm(data, key). , — decryption_algorithm(data, key). , , , . - - , (, SQL-), .




A segurança através da obscuridade é amplamente usada na segurança física / real. Por exemplo, o presidente está dirigindo do ponto A ao ponto B com uma carreata de 30 carros. Mas ele não se senta em seu carro presidencial, para não se tornar um alvo fácil. Ele pode estar em qualquer máquina da tupla, e isso reduz o risco de um ataque.







Os animais também exploram a segurança na obscuridade - é a camuflagem. Stealth reduz a probabilidade de ser morto. Portanto, no processo de evolução, eles adquiriram essa habilidade.







Resultado



A segurança apenas na obscuridade não é suficiente. As melhores práticas sempre devem ser aplicadas. Mas se você pode reduzir seu risco a custo zero, você deve. A obscuridade é uma boa camada no sistema de segurança geral.



All Articles