1. Perspectivas em segurança da informação
1.1. Conceitos-chave
1.1.1. A segurança da informação lida com…
1.1.1.1. a definição, implementação, manutenção, conformidade e avaliação.
1.1.1.2. um conjunto coerente de controles (medidas).
1.1.1.3. salvaguardar a disponibilidade, integridade e confidencialidade.
1.1.1.4. o fornecimento de informações (manual e automatizado).
1.1.2. CID
1.1.2.1. Confidencialidade
1.1.2.1.1. Depende de proteger informações confidenciais contra divulgação não autorizada ou interceptação de informações.
1.1.2.2. Integridade
1.1.2.2.1. Depende da salvaguarda da precisão, integridade das informações.
1.1.2.3. Disponibilidade
1.1.2.3.1. Depende de garantir que informações e serviços vitais de TI estejam disponíveis quando necessários.
1.2. GSI como um ciclo PDCA
1.2.1. Plan
1.2.1.1. Planos e políticas são definidos
1.2.1.2. Controles/medidas são planejados
1.2.2. Do
1.2.2.1. Controles são implementados
1.2.3. Check
1.2.3.1. Verifica se o que foi executado está em conformidade com o planejado
1.2.3.2. Requer auditoria regular
1.2.4. Act
1.2.4.1. Analisa relatórios para identificar melhorias
1.2.4.2. Avaliações de riscos precisam ser atualizadas periodicamente
1.2.5. Controle
1.2.5.1. É um função que os profissionais de segurança acrescentam a esse modelo PDCA
1.3. Perspectiva do negócio
1.3.1. Nem todas as informações e serviços de informação são igualmente importantes para uma organização.
1.3.1.1. Uma Analise de Impacto no Negócio (BIA) pode ajudar a esclarecer isso
1.3.2. A proteção dos ativos de informação exigirá que controles (medidas) sejam implementadas em um nível apropriado de acordo com o valor da informação ou ativo sob a perspectiva do negócio.
1.4. Perspectiva do cliente
1.4.1. Os clientes exigem a continuidade 24/7 das operações de TI nos negócios.
1.4.2. As preocupações com a privacidade ainda são muito fortes, embora o uso das mídias sociais mostre que essa é uma faca de dois gumes.
1.4.3. Os clientes confiam nas organizações que são transparentes devido a maneira como lidam com os seus riscos.
1.5. Perspectiva dos fornecedores
1.5.1. Os fornecedores precisam mostrar o devido cuidado com segurança da informação.
1.5.2. Gerenciamento de incidentes, mudanças e continuidade são processos chave.
1.5.3. O monitoramento ativo e o gerenciamento de vulnerabilidades precisam de mais atenção.
2. Gerenciamento de riscos
2.1. Fazemos uma avaliação de riscos para saber...
2.1.1. Quais ativos de informação precisamos proteger?
2.1.2. Por que precisamos proteger esses ativos?
2.1.3. Quais são os riscos?
2.1.4. Quais são as prioridades ao lidar com esses riscos?
2.1.5. Quais são as opções para lidar com esses riscos?
2.2. Componentes de um risco
2.2.1. Ativos
2.2.2. Ameaças
2.2.3. Vulnerabilidades
2.2.4. Probabilidade de ocorrência
2.2.5. Impacto
2.3. Estratégias para lidar com riscos
2.3.1. Evitar
2.3.2. Mitigar
2.3.3. Compartilhar
2.3.4. Aceitar
2.4. Etapas de avaliação e tratamento de riscos
2.4.1. 1. Determine os ativos no escopo da avaliação.
2.4.2. 2. Determine quem são os donos desses ativos.
2.4.3. 3. Discuta com esses donos sobre as ameaças a esses ativos.
2.4.4. 4. Decida quem são os agentes (origens) de ameaça
2.4.5. 5. Obtenha opiniões de especialistas sobre vulnerabilidades desses ativos.
2.4.6. 6. Obtenha opiniões de especialistas sobre as probabilidades de ocorrência das ameaças (gerar incidentes).
2.4.7. 7. Obtenha opiniões de especialistas sobre impactos quando as ameaças ocorrerem.
2.4.8. 8. Faça um brainstorming com os representantes das partes interessadas.
2.4.8.1. forma mais rápida para identificar a maioria das ameaças para a organização?
2.4.9. 9. Defina algum tipo de fórmula para calcular o nível do risco
2.4.10. 10. Defina o apetite ao risco do(s) donos(s).
2.4.11. 11. Encontre opções para mitigar riscos inaceitáveis.
2.4.11.1. Esse passo é importante antes de iniciar o tratamento dos riscos
2.4.12. 12. Implemente os controles de segurança
2.4.13. 13. Compreenda e mitigue os novos riscos a partir dos controles implementados.
2.4.14. 14. Aceite quaisquer riscos residuais e repita todas as opções acima.
2.5. Fluxo do gerenciamento de riscos
2.5.1. Fluxo
2.5.1.1. Observar que o tratamento dos riscos somente acontece depois que passar pelos critérios de aceite
2.6. Pontos de atenção na avaliação der riscos
2.6.1. Faça antes uma Análise de Impacto no Negócio (BIA) primeiro para determinar onde é necessária uma avaliação de riscos.
2.6.2. Implemente uma linha de base sobre os riscos. Os controles da ISO/IEC 27001/2 podem servir como linha de base.
2.6.3. No entanto, os controles de mitigação de risco devem ser implementados somente quando necessário.
2.6.4. A análise de riscos pode ser facilitada por um especialista, mas requer uma abordagem multidisciplinar com membros de todas as áreas do negócio.
2.6.5. Existem muitas ferramentas disponíveis, mas as ferramentas podem apenas ajudar o processo; não realizá lo!
2.6.6. A avaliação de riscos fornecerá a direção na qual os controles devem ser implementados para lidar com os riscos enfrentados pela organização. Isso é essencial ao projetar um programa de segurança da informação em toda a empresa.
2.6.7. A melhor maneira de alcançar um bom nível de eficácia na governança de segurança é executando uma avaliação periódica dos riscos como parte de um programa de gerenciamento de riscos.
2.6.8. A organização não levará os riscos a um nível 0.
2.6.9. Importante que ao final as partes interessadas sejam informadas sobre os riscos residuais e aceitá lo de acordo com o apetite de risco da organização (a quantidade de risco que as organizações estão dispostas a aceitar ao avaliar as compensações entre segurança e acesso ilimitado à informação).
2.7. Análise de Impacto no Negócio (AIN/BIA)
2.7.1. É feita antes da avaliação de riscos
2.7.2. Serve para identificar onde uma avaliação de riscos é necessária
2.7.3. Lida apenas com o impacto de um evento de perda, dano ou divulgação de informações.
2.7.4. Permite que uma organização identifique os processos em que a segurança é importante.
2.7.5. Deve ser realizada junto com o(s) donos(s) de negócio.
2.7.6. Não analisa ativos, ameaças, vulnerabilidades, probabilidades, etc.; apenas o impacto dos eventos.
2.8. Princípio da linha de base (baseline)
2.8.1. Implemente um conjunto limitado de controles para os ativos que fazem parte do escopo.
2.8.2. Faça uma avaliação de riscos em todos os outros ativos e implemente controles extras apenas quando necessário.
2.8.3. A ISO/IEC 27001/2 podem servir como linha de base para a maioria das organizações
2.9. Declaração de Aplicabilidade (SoA)
2.9.1. Pode ser atualizada com o resultado da avaliação de riscos.
2.9.2. Lista os controles que serão implementados da ISO/IEC 27001
2.9.3. É um documento obrigatório para o processo de certificação de empresas na ISO/IEC 27001
3. Controles
3.1. Estratégias
3.1.1. A Segurança da Informação só ser melhorada através da implementação de controles.
3.1.2. É importante dar um peso maior ao “Plan” do PDCA onde são planejados os controles.
3.2. Controles procedimentais (Organizacionais)
3.2.1. Diretrizes gerais
3.2.1.1. Desenvolva procedimentos documentados apenas onde houver um benefício real
3.2.1.2. Os procedimentos devem ser curtos e relevantes e conter representações visuais das atividades sempre que possível.
3.2.1.3. Se as atividades são realizadas por funcionários com conhecimento, elas não devem ser descritas em detalhes.
3.2.1.4. Um guia deve descrever como os procedimentos são elaborados e como o processo de aprovação, auditoria e manutenção de deles funciona, etc.
3.2.2. Controles procedimentais mais importantes
3.2.2.1. Procedimentos de gerenciamento de incidentes
3.2.2.1.1. Eles descrevem como os incidentes são gerenciados, ou seja, caminhos de escalação, quem é responsável, como os incidentes são resolvidos, quem deve ser informado e como a organização aprende com os incidentes.
3.2.2.2. Procedimentos de gerenciamento de mudanças
3.2.2.2.1. Eles descrevem como as mudanças (TIC) são definidas, como os riscos são mitigados, quem aprova e como as mudanças são controladas.
3.2.2.3. Procedimentos de gerenciamento de continuidade
3.2.2.3.1. Eles descrevem as ações, responsabilidades e caminhos de escalada de grandes incidentes (que podem levar a uma situação de crise) necessários para impedir que a organização falhe em circunstâncias incomuns nos negócios.
3.2.2.4. Procedimentos gerais para retenção de registros
3.2.2.4.1. Convém que o sistema de armazenamento e manuseio assegure a clara identificação dos registros e dos seus períodos de retenção, conforme definido pela legislação nacional ou regional ou por regulamentações, se aplicável.
3.2.2.4.2. A organização pode emitir diretrizes gerais para retenção, armazenamento, tratamento e disposição de registros e informações.
3.3. Controles físicos
3.3.1. Diretrizes gerais
3.3.1.1. Verifique a legislação quando instalar câmeras de vigilância e outros equipamentos sensíveis à privacidade.
3.3.1.2. O zoneamento ajuda a decidir quais partes da organização precisam de controles rígidos de entrada física.
3.3.1.2.1. Áreas da empresa com mesmo nível de segurança podem ser combinadas. Exemplo: Saguão e restaurante
3.3.2. Recomendações da ISO/IEC 27002
3.3.2.1. convém que seja implantada uma área de recepção, ou um outro meio para controlar o acesso físico ao local ou ao edifício; o acesso aos locais ou edifícios deve ficar restrito somente ao pessoal autorizado;
3.3.2.2. convém que as instalações de processamento da informação gerenciadas pela organização fiquem fisicamente separadas daquelas que são gerenciadas por partes externas.
3.3.2.3. convém que a data e hora da entrada e saída de visitantes sejam registradas, e todos os visitantes sejam supervisionados, a não ser que o seu acesso tenha sido previamente aprovado;
3.3.2.4. convém que o acesso às áreas em que são processadas ou armazenadas informações sensíveis seja restrito apenas ao pessoal autorizado pela implementação de controles de acesso apropriados, por exemplo, mecanismos de autenticação de dois fatores, como, cartões de controle de acesso e PIN (personal identification number);
3.3.2.5. convém que uma trilha de auditoria eletrônica ou um livro de registro físico de todos os acessos seja mantida e monitorada de forma segura;
3.3.2.6. convém que as instalações-chave sejam localizadas de maneira a evitar o acesso do público;
3.3.3. Controles de acesso
3.3.3.1. Etapas
3.3.3.1.1. Identificação (quem é você)
3.3.3.1.2. Autenticação (confirma quem é você)
3.3.3.1.3. Autorização (quais direitos você tem)
3.4. Controles relacionados a recursos humanos
3.4.1. Diretrizes gerais
3.4.1.1. Toda a comunicação deve ser focada no grupo alvo.
3.4.1.2. O nível de conscientização do grupo alvo deve ser medido.
3.4.1.3. Deve se haver um cuidado especial com os papéis em que ocorrem altos riscos, especialmente quando são concedidos privilégios de acesso. Onde for necessário, a separação de funções é requerida.
3.4.2. Engenharia social
3.4.2.1. Os funcionários devem ser treinados para identificar a engenharia social e saber como reconhecer quem pode ter acesso a quais ativos.
3.5. Controles relacionados à continuidade de negócios
3.5.1. RTO
3.5.1.1. Objetivo de Tempo de Recuperação (RTO)
3.5.1.2. Especifica a duração e o nível de serviço dentro dos quais um serviço de TI deve ser restaurado após um desastre ou interrupção.
3.5.2. RPO
3.5.2.1. Objetivo de Ponto de Recuperação (RPO)
3.5.2.2. É o período máximo tolerável em que os dados podem ser perdidos de um serviço de TI devido a um incidente grave.
3.5.2.3. Se quer reduzir a perda de dados, então tem que reduzir o RPO
3.5.3. PCN
3.5.3.1. Um plano para continuar as operações do negócio.
3.5.4. PRD
3.5.4.1. Um plano para acessar a tecnologia e a infraestrutura necessárias após um desastre.
3.6. Controles técnicos
3.6.1. Criptografia
3.6.1.1. Criptografia é fundamental para garantia a confidencialidade.
3.6.1.2. Criptografia simétrica
3.6.1.2.1. Duas partes compartilham a mesma chave.
3.6.1.3. Criptografia assimétrica
3.6.1.3.1. Cada parte usa uma chave diferente (pública e privada)
3.6.1.3.2. Nas assinaturas digitais, a chave privada é usada para assinar o documento e a chave pública para verificar quem foi o autor do documento
3.6.1.3.3. Pode fazer uso PKI e há o risco da Autoridade de Certificação (CA) ser hackeada.
3.7. Controles de rede
3.7.1. Componentes de infraestrutura
3.7.1.1. Roteador
3.7.1.1.1. Divide a rede com base no endereço, redirecionando ou bloqueando o tráfego. Ele pode fazer isso muito rápido.
3.7.1.2. Firewall
3.7.1.2.1. Analisa os pacotes de dados e decide, com base em um conjunto de regras, se permite estes pacotes na rede ou não.
3.7.1.2.2. Serve também para separar áreas com requisitos de confidencialidade diferentes
3.7.1.3. Porta de entrada
3.7.1.3.1. Permite os usuários na rede só após a identificação e autorização, por exemplo.
3.7.1.4. Servidores
3.7.1.4.1. Têm uma função principal em redes públicas, por exemplo, receber e-mail ou atuar como servidor web, devem estar situados na chamada zona desmilitarizada (DMZ).
3.7.1.5. DMZ
3.7.1.5.1. Servidores podem ser separados das redes internas (por um firewall) para que, quando comprometidos externamente, ainda haja uma barreira entre a zona comprometida e as informações da organização.
3.7.1.6. Sistemas de detecção de intrusões (IDS)
3.7.1.6.1. Analisa o tráfego e, por exemplo, com base em assinaturas ou anomalias estatísticas, pode rejeitá-lo.
3.7.1.7. IDPS
3.7.1.7.1. Sistema de Detecção e Prevenção de Intrusão (Intrusion Detection and Prevention System - IDPS)
3.7.1.7.2. É um sistema híbrido, surgido a partir da junção dos sistemas IDS e IPS
3.7.1.7.3. IDPS Baseado em Host
3.7.1.7.4. IDPS Baseado em Rede
3.7.1.8. Filtro de conteúdo
3.7.1.8.1. É muito útil para proteger a rede da organização contra sites maliciosos e e-mails, no entanto, será necessária uma extensa configuração e atualizações por operações, uma vez que vários novos sites estão aparecendo continuamente.
3.7.2. Divisão de produção do ambiente de testes
3.7.2.1. Os ambientes de teste devem ser controlados por meio de controles de autorização, a fim de proteger a integridade do ambiente de produção.
3.7.2.2. Uma autorização deve ser feita sempre que os dados estão sendo movidos da produção para o teste e do teste para o ambiente.
3.7.3. Arquitetura Orientada a Serviços (SOA)
3.7.3.1. É uma abordagem arquitetônica na qual os aplicativos utilizam os serviços disponíveis na rede. Nesta arquitetura, vários serviços se comunicam entre si, de uma de duas maneiras: passando dados ou através de dois ou mais serviços coordenando uma atividade.
3.7.3.2. A definição de quais serviços de segurança serão fornecidos e em qual arquitetura deve ser definida para melhor alinhar os requisitos de segurança da informação e o serviço para os clientes.
3.7.4. Arquitetura de design aberto
3.7.4.1. Geralmente, o uso da arquitetura de design aberto aumentaria a extensão dos testes, melhorando a segurança dos serviços.