{"id":8413,"date":"2016-01-20T11:29:06","date_gmt":"2016-01-20T11:29:06","guid":{"rendered":"https:\/\/multiacademstg.wpengine.com\/27001academy\/?p=8413"},"modified":"2022-07-17T15:43:26","modified_gmt":"2022-07-17T15:43:26","slug":"como-usar-teste-de-invasao-para-o-controle-a-12-6-1-da-iso-27001","status":"publish","type":"post","link":"https:\/\/advisera.com\/27001academy\/pt-br\/blog\/2016\/01\/20\/como-usar-teste-de-invasao-para-o-controle-a-12-6-1-da-iso-27001\/","title":{"rendered":"Como usar teste de invas\u00e3o para o controle A.12.6.1 da ISO 27001"},"content":{"rendered":"

Um famoso hacker, Kevin Mitnick, disse uma vez em uma ocasi\u00e3o: \u201cEu sou contratado por companhias para invadir seus sistemas e entrar em suas instala\u00e7\u00f5es f\u00edsicas para encontrar falhas de seguran\u00e7a. Nossa taxa de sucesso \u00e9 de 100%; n\u00f3s sempre encontramos uma falha\u201d.<\/p>\n

Assim, provavelmente a quest\u00e3o agora em sua mente \u00e9 \u2013 isso poderia ser evitado? O Sr. Mitnick diria n\u00e3o, mas ningu\u00e9m deveria desistir por conta disso. Algo poderia ser feito para minimizar (ou eliminar) a possibilidade de invas\u00e3o de um ambiente de TI. Basicamente, se voc\u00ea sabe quais s\u00e3o as suas vulnerabilidades antes que seus atacantes saibam, voc\u00ea estar\u00e1 mais protegido, assim deixe-me explicar isto em mais detalhes.<\/p>\n

An\u00e1lise de vulnerabilidade vs. Teste de invas\u00e3o<\/h2>\n

Basicamente, quando voc\u00ea realiza uma an\u00e1lise de vulnerabilidade em seus sistemas de informa\u00e7\u00e3o, voc\u00ea pode identificar todas as vulnerabilidades t\u00e9cnicas relacionadas a eles (e.g., Inje\u00e7\u00e3o de SQL, XSS, CSRF, senhas fracas, etc.). Mas, para a explora\u00e7\u00e3o destas voc\u00ea precisa realizar um teste de invas\u00e3o.<\/p>\n

Deixe-me explicar o item anterior. Imagine que voc\u00ea tenha um Sistema que \u00e9 vulner\u00e1vel a Inje\u00e7\u00e3o de SQL (m\u00e9todo para realizar opera\u00e7\u00f5es em uma base de dados). A an\u00e1lise de vulnerabilidade identificar\u00e1 esta vulnerabilidade. Ap\u00f3s a an\u00e1lise de vulnerabilidade, o teste de invas\u00e3o pode ser realizado e a vulnerabilidade pode ser explorada. Isto significa que voc\u00ea pode acessar o sistema vulner\u00e1vel e ter acesso, ou at\u00e9 mesmo modificar ou excluir, informa\u00e7\u00e3o confidencial (informa\u00e7\u00e3o na base de dados sobre clientes, provedores, etc.).<\/p>\n

Por outro lado, de acordo com o controle A.12.6.1<\/a>\u00a0do Anexo A da\u00a0ISO 27001:2013<\/a>, voc\u00ea precisa prevenir a explora\u00e7\u00e3o de vulnerabilidades t\u00e9cnicas. Como fazer isso? Com a an\u00e1lise de vulnerabilidade ou com o teste de invas\u00e3o? Ou, voltando ao exemplo anterior: para a preven\u00e7\u00e3o da explora\u00e7\u00e3o da vulnerabilidade relacionada ao sistema, precisamos realizar o teste de invas\u00e3o? A resposta \u00e9 \u2013 n\u00e3o necessariamente, porque ap\u00f3s a an\u00e1lise de vulnerabilidade n\u00f3s sabemos que o Sistema \u00e9 vulner\u00e1vel, e ao repar\u00e1-lo podemos evitar a vulnerabilidade de inje\u00e7\u00e3o de SQL. Assim, a pr\u00f3xima etapa, explor\u00e1-la, n\u00e3o \u00e9 necess\u00e1ria.<\/p>\n

Assim, se voc\u00ea quer estar em conformidade com a ISO 27001:2013 voc\u00ea pode realziar apenas a an\u00e1lise de vulnerabilidade<\/a>, embora o teste de invas\u00e3o seja uma boa pr\u00e1tica, e \u00e9 altamente recomendada se voc\u00ea quer saber qu\u00e3o vulner\u00e1vel seus sistemas s\u00e3o (em nosso exemplo, queremos saber quais informa\u00e7\u00f5es poderiam ser vistas por uma pessoa n\u00e3o autorizada).<\/p>\n

Fases do teste de invas\u00e3o<\/h2>\n

Caso voc\u00ea esteja pensando em realizar um teste de invas\u00e3o para melhorar a implementa\u00e7\u00e3o de sua ISO 27001, existem muitos utilit\u00e1rios e plataformas que voc\u00ea pode usar para automatiz\u00e1-lo, mas minha recomenda\u00e7\u00e3o \u00e9 que voc\u00ea siga estas fases:<\/p>\n