Segurança de SO

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Inspire-se (Vídeo) - Contingência ->
Apresentador: Marcos Alexandre (Gerente de Desenvolvimento de Produtos)
Comentários do apresentador e algumas pesquisas relacionadas em cima do tema abordado na entrevista:
O que é um plano de contingência?
Um plano de contingência, também chamado de planejamento de riscos, plano de continuidade de negócios ou plano de recuperação de desastres, tem o objetivo de descrever as medidas a serem tomadas por uma empresa, incluindo a ativação de processos manuais, para fazer com que seus processos vitais voltem a funcionar plenamente, ou num estado minimamente aceitável, o mais rápido possível, evitando assim uma paralisação prolongada que possa gerar maiores prejuízos a corporação, como:
> a fuga de acionistas,
> grandes perdas de receita;
> sanções governamentais; 
> problemas jurídicos para os dirigentes;
> abordagens maliciosas da imprensa;
> fuga de funcionários para os concorrentes e
> em casos extremos, o fechamento da empresa.
Como é um plano de contingência?
As normas para um plano de contingência são muito importantes por que, você já imaginou aqui a gente ta falando de servidores, sobre bastante coisa que no dia a dia a gente tem muita informação e essas informações mesmo elas estando em locais seguros, tem que tomar cuidado com isso por que você pode perder informações, e esse plano de contingência ele faz com que você tenha que identificar todos os processos que são feitos pela empresa avaliar impacto no negócio, por que tudo isso faz com que o que você fez no dia a dia ele tenha maior segurança, você tem que ter uma lista de opções aonde você consegue elencar o que é melhor para aquilo e ter um plano de contingência pronto, facilita muito uma política de segurança, critérios para o plano, práticas e medidas quando definir a equipe o responsável por cuidar daquela equipe (que vai cuidar da equipe e dos problemas que possam vir a surgir quando realizar tal contingência), ou seja, se algo acontecer quem vai se responsabilizar por resolver tais problemáticas, ter as informações na mão, ter normas, fazer com que esse plano tenha uma política bem organizada e tem que comunicar a direção da empresa. Basicamente então o plano de contingência é um plano que vai "salvar" tudo caso algo muito errado ocorra, como se fosse a última esperança por isso deve ser se não a primeira uma das primeiras coisas a ser elaborada. 
Como deve ser elaborado um plano de administração de crise?
Um plano de administração de crise passa por uma criação de um time para isso, uma equipe, tem que ter uma equipe por que quando você passa uma crise, e ela pode ser baixa, médio ou alto risco, quando é baixo risco é mais simples mas quando é alto risco são informações super importantes, a gente já viu problemas de empresas que quebraram simplesmente por que perderam essas informações por isso elas são muito importantes, como por exemplo na China aonde conseguem monitorar as pessoas através de sua face, consegue saber tudo sobre alguém simplesmente por ter a sua face em um banco de dados, desde o que a pessoa gosta, no que trabalha, nomes de parentes, o que come e o que não, etc.. Por que ele já mapeou com esse monitoramento toda a sua vida, então não são apenas informações simples que se é possível saber; e quando você tem uma equipe dentro da empresa que trabalha com essa crise ela faz com que as informações elas fiquem de certa forma "redondas" que elas tenham esse casamento e você não tenha problema de perder informações. Agora, caso você tenha essa perda de informação, essa equipe tratará sobre isso mas são pessoas especialistas que estavam na empresa ali prontas pra isso pra poder recuperar essas informações e trazê-las de volta.
Como deve ser elaborado um plano de continuidade operacional?
Para esse plano de continuidade, basta você ter a equipe organizada, você saber fazer a analise do impacto dessa paralização, por que quando você tem um problema na empresa/servidores não da pra parar todos os funcionários, é a mesma coisa quando tem um problema em uma crise, aonde você pode perder os dados dali, você tem que fazer o que? paralizar, ver qual é o impacto de paralizar aquilo, será que vai causar um grande impacto na empresa se eu parar todo mundo? Por isso que às vezes é importante você saber trabalhar com as duas partes, tanto tendo uma produção um pouco menor mas que tenha um impacto/diferencial naquilo e você trabalhar com sistemas redundantes fazer a distribuição desse sistema, muitas vezes tem um sistema funcionando aqui e tem um igual ao lado, mas quando um dos dois cai, o outro é capaz de sustentar por um tempo sozinho; ele sinaliza pra equipe de crise que parou x sistema mas o y está operando, então quando eu tenho dois eu faço com que eu tenha possibilidade de fazer algo desse tipo. E sempre contar com pessoas especializadas, por isso que é importante a qualificação da pessoa, que tenha um diferencial e que realmente tenha estudado para isso.
Como deve ser elaborado um plano de recuperação de desastres?
Ter noção dos riscos que englobam a minha empresa que podem me atrapalhar? É você já estar preparado pra isso, ter estratégias de recuperação, nós só temos que precaver antes do desastre mesmo que não aconteca o desastre por que assim você já consegue de fato se precaver de um futuro desastre, a partir do momento em que você não sabe como resolver, ai fica difícil, por exemplo, hoje a gente sabe que de vez em quando acontece isso quando para uma ferramenta por ex de comunicação mundial (WhatsApp), a gente fica sem comunicação e não consegue se comunicar por que você está tão focado naquilo em utilizar aquilo que você acaba por não conseguir por se desligar daquilo. E quando uma empresa de grande porte passar por algum tipo de desastre é preciso ter uma estratégia de recuperação e continuidade de negócio, testes e planos, tem que ter planos para recuperação; isso tem que se executado mesmo que não precise, por exemplo, não aconteceu de perder as informações mas vamos testar recuperar pra ver se de fato na hora H não vai acabar perdendo nada.
-----------------------------------------------------------x------------------------------
Tópico 1 ->
Introdução:
Olá! Nesta unidade, vamos discutir sobre Contingência, Disaster Recovery, Auditoria e Monitoramento de Controles e Virtualização.
Ao longo da discussão veremos que a virtualização surgiu como uma chave da tecnologia para resolver alguns problemas gerenciais. Essa dinâmica apresenta diversos benefícios como o suporte à consolidação do servidor, isolando os aplicativos de enquanto compartilham a mesma máquina, melhoram a segurança do sistema, isolando aplicativos vulneráveis de outros aplicativos de missão crítica em execução na mesma máquina, dentre outras questões.
Será uma excelente oportunidade discutir sobre todas essas temáticas para aprimorar os seus conhecimentos.
-----------------------------------------------------------x------------------------------
Tópico 2 ->
Contingência:
Este tópico lhe ajudará com o desenvolvimento de planos de contingência viáveis para facilitar uma resposta oportuna a qualquer interrupção estendida aos sistemas de informação. A contingência do sistema de informação se encaixam em um ambiente de preparação para emergências muito mais amplo, que inclui a continuidade de processos organizacionais e de negócios e planejamento de recuperação.
Ao longo do tópico iremos apresentar o processo de planejamento que deve estar focado em minimizar a duração de uma perturbação grave, facilitando a coordenação eficaz das tarefas de recuperação e redução da complexidade do esforço de restauração.
Planejamento de Contingência e Processo de Gerenciamento de Riscos:
As atividades de gerenciamento de riscos da perspectiva do planejamento de contingência têm duas principais funções. Primeiro, o gerenciamento de riscos deve identificar as ameaças e vulnerabilidades apropriadas aos controles que podem ser implementados para impedir a
ocorrência de incidentes ou para limitar os efeitos de um incidente. Esses controles de segurança protegem um sistema de informações contra três categorias de ameaças:
1. Natural - furacões, tornados, inundações ou incêndios
2. Humano - erro do operador, sabotagem, implante de código malicioso e ataques terroristas
3. Ambiental - falha do equipamento, erro de software, interrupção da rede de telecomunicações, e falhas de energia elétrica.
O gerenciamento de riscos deve identificar os riscos para os quais os planos de contingência devem ser colocados em prática. O plano de contingência, portanto, está intimamente ligado aos resultados da avaliação de riscos e seu processo de mitigação. Determinar efetivamente os riscos específicos para um sistema de informação (ou sistema operacional) durante a interrupção do serviço, é fundamental pois é a partir de uma avaliação de risco do ambiente do sistema de informações que será possível implementar a correção (solução do problema).
Como os riscos podem variar ao longo do tempo e novos riscos podem substituir os antigos à medida que o sistema evolui, o risco e o processo de gerenciamento deve ser contínuo e dinâmico. O ISO - Information System Owner (numa tradução literal, seria: Proprietário do sistema de informação), deve estar ciente dos riscos do sistema e determinar se o atual plano de contingência trata os riscos de maneira completa e eficaz.
As categorias de segurança são usadas em conjunto com informações de vulnerabilidade e ameaça na avaliação a partir dos riscos para uma organização.
Planejamento de Contingência e Ciclo de Vida de Desenvolvimento do Sistema:
O Ciclo de Vida de Desenvolvimento do Sistema (SDLC - System Development Life Cycle) refere-se ao escopo completo das atividades conduzidas pelas ISOs associados a um sistema durante sua vida útil. O ciclo de vida começa com o projeto em sua fase de iniciação e termina com a fase de descarte do sistema. As medidas de contingência devem ser identificadas e integradas em todas as fases do ciclo de vida - uma abordagem que reduz os custos de planejamento de contingência, aprimora as capacidades de contingência e reduz os impactos das operações do sistema se o plano de contingência for implementado.
As considerações durante as fases do SDLC são as seguintes:
Fase de iniciação: Os requisitos de planejamento de contingência devem ser considerados quando um novo sistema de informação está sendo concebido. Na fase de iniciação, os requisitos do sistema são identificados e compatíveis com seus processos operacionais. Requisitos de contingência inicial pode se tornar aparente. Durante esta fase, o novo sistema de informação será avaliado contra todos os outros sistemas de informação existentes e planejados para determinar sua prioridade de recuperação.
Fase de desenvolvimento / aquisição: À medida que os conceitos iniciais evoluem para os designs do sistema, soluções de contingência específicas podem ser incorporadas. Medidas de contingência devem continuar a refletir os requisitos operacionais e do sistema. O design deve incorporar a redundância e robustez diretamente na arquitetura do sistema para otimizar a confiabilidade, manutenibilidade e disponibilidade durante a fase de operações / manutenção. A cópia de segurança e os procedimentos e prazos também são definidos nesta fase. Ao incluí-los no projeto inicial, os custos, bem como problemas associados à adaptação ou modificação do sistema durante as fases posteriores, são reduzidos.
Fase de implementação: Enquanto o sistema está passando por testes iniciais, contingência estratégias devem ser testadas para garantir que os recursos técnicos e os procedimentos de recuperação são precisos e eficazes.
Fase de operação / manutenção: Quando o sistema está em pleno funcionamento (em produção), usuários, administradores, e os gerentes devem manter um programa de treinamento e conscientização que cubra procedimentos do plano de contingência. Exercícios e testes devem ser realizados para garantir que os procedimentos continuam eficazes. Os backups regulares devem ser realizados e armazenados externamente.
O plano deve ser atualizado para refletir as alterações nos procedimentos com base nas lições aprendidas. Quando o sistema de informações (ou sistema operacional) passa por atualizações ou outras modificações (por exemplo, alterações nas interfaces externas), essas modificações devem refletir no plano de contingência.
Fase de descarte: Considerações de contingência não devem ser negligenciadas no processo de substituição de sistemas. Quando os sistemas legados são substituídos, eles podem fornecer uma valiosa capacidade de backup se eventualmente ocorrer uma perda ou falha do novo sistema. Em alguns casos, as peças de equipamento (por exemplo, discos rígidos, fontes de alimentação, chips de memória ou placas de rede) de hardware que foram substituídos por novos sistemas podem ser usadas como peças de reposição para equipamentos operacionais novos. Além disso, sistemas legados podem ser usados como sistemas de teste para novas aplicações. Durante a fase de descarte, os requisitos regulamentares para disponibilidade de dados devem ser considerados. Embora um sistema tenha sido substituído, pode ser necessário manter o dados, o software ou um mecanismo para recuperar os dados se os históricos não forem incorporado no sistema de substituição.
-----------------------------------------------------------x------------------------------
Tópico 3 ->
Disaster Recovery (Recuperação de Desastres):
Para minimizar a perda de serviços virtuais devido a desastres naturais ou causados pelo homem é necessário ter um planejamento para aplicar a recuperação desses desastres. No entanto, o gerenciamento de alterações do sistema de recuperação de desastres contra a alteração do ambiente computadorizado não é executado de forma tranquila (sem problemas). Para compensar esta situação, existe um interesse crescente na construção de um sistema de recuperação de desastres no ambiente de nuvem e o número de casos de sistema de recuperação de desastres no ambiente de nuvem tem aumentado gradualmente.
Contudo, há uma limitação na construção de um sistema de recuperação de desastre para o ambiente em nuvem (Cloud Computing). Este tópico está organizado da seguinte forma: A princípio será apresentado a técnica de recuperação de desastre relacionada à nuvem e os fornecedores serão analisados. Em seguida, serão apresentadas as métricas de classificação e a adaptação do sistema em nuvem as propostas de operações do sistema de recuperação de desastres na nuvem.
Em termos de hardware do sistema de recuperação de desastres, os principais componentes são divididos em servidor, armazenamento e rede. Os servidores e redes são ambientes de nuvem que podem ser configurados para fornecer um ambiente virtual, mantendo o estado de failover (termo utilizado para denominar um servidor que assume um determinado serviço se outro servidor tem problemas). No entanto, no caso de armazenamento, uma vez que os dados são gerados e alterados continuamente através do servidor que fornece o serviço principal, a replicação remota de dados deve ser realizada por meio da função de replicação de dados fornecida pelo serviço em nuvem.
O sistema de recuperação de desastres ativa recursos para replicar dados críticos, os recursos do servidor são alocados e mantidos com o mínimo de recurso. Em caso de desastre, o sistema em nuvem no centro de recuperação de desastre aloca recursos para o servidor usando a função de provisionamento de recursos e operando com o sistema de recuperação de desastres para fornecer os serviços de negócios contínuos para o cliente.
Estratégia de Recuperação de Desastres e Plano de Manutenção:
Com a crescente dependência da tecnologia da informação (TI) e do processo de negócios para apoiar o crescimento dos negócios e as mudanças associadas às suas complexidades, combinadas com as mudanças tecnológicas. Uma retomada eficiente e eficaz
dos negócios vitais a partir das funções no caso de uma interrupção não programada é muito importante. O gerenciamento de uma recuperação de desastre é um sistema usado para definir um processo contínuo de planejamento, desenvolvimento, teste e implementar procedimentos e processos de gerenciamento de recuperação de desastres.
Reflita:
Um plano de teste deve abranger as seguintes áreas: cronograma, introdução, equipes de teste, planejamento de pré-teste, cronograma de teste, pontos de verificação de teste críticos e log de problemas de teste.
A partir da definição de Martin, de que forma é possível aplicar o plano de teste abrangendo todas as áreas que foram citadas?
Quais são os cuidados e as implicações da equipe responsável pela elaboração de teste para atender todos os elementos relacionados?
A estratégia de recuperação de desastre foi projetada para garantir a continuação dos processos comerciais vitais no evento que ocorre um desastre. Ele fornece uma solução eficaz que pode ser usada para recuperar todos os negócios vitais e processos dentro do prazo necessário, usando registros vitais armazenados externamente.
O último passo envolve o desenho dos critérios para o teste e a manutenção do plano. O planejamento sem teste pode ser catastrófico. Um plano de recuperação de desastre deve ser cuidadosamente testado e ajustado conforme necessário. Uma organização pode desenvolver novos produtos que exijam processos novos ou aprimorados. É necessário incluir o efeito dessas alterações no seu plano de recuperação de desastres (DR - Disaster Recovery) para garantir que esteja atualizado e pronto para a sua implementação quando ocorrer a próxima interrupção dos negócios.
Planejamento da Manutenção:
Uma das partes mais difíceis da recuperação de desastres é a manutenção contínua do plano, pois as mudanças no plano ocorrem e impulsionam as alterações dos procedimentos de gestão para atender aos relatórios de teste e auditoria.
O objetivo desta manutenção é a definição da atividade necessária para manter o Plano de DR (Disaster Recovery ) para a gestão dos ambientes de mainframe e mid-range. A manutenção do plano de recuperação de desastres é muito importante para garantir o status atualizado dos procedimentos que regem a recuperação.
Isso significa manter o plano de teste e o plano de implementação atual, sincronizado com as mudanças nos negócios. Todas as mudanças nos negócios e nos ambientes mainframe e mid-range devem ser considerados para inclusão e atualização do Plano de recuperação de desastres.
Teste de Recuperação de Desastre:
De acordo com Toigo (2002), “não existe falha nos testes, pois são usados para obter o conhecimento, para não depreciar o plano”. O objetivo do plano de teste é especificamente identificar e documentar o plano de tarefas e procedimentos a serem implementados em um ambiente de teste. Esta dinâmica inclui parâmetros de teste, objetivos, critérios de medição, metodologia de teste, gráficos de plano de tarefas e tempo nas linhas para validar a eficácia do atual plano de recuperação de desastres.
O Plano de teste é um componente importante da atividade de manutenção planejada, uma vez que os testes podem ser comparados como sendo a “espinha dorsal” em que a validade do plano é demonstrada. O plano de recuperação de desastres será testado para garantir se a empresa tem a capacidade de continuar com os processos críticos de negócios em caso de desastre. Isto é muito importante para que os procedimentos de recuperação sejam executáveis e precisos.
Há muitas razões para testar o plano, incluindo os seguintes itens: a ferramenta de auditoria, benchmarking, enquanto o benefício de testar o plano é treinar as equipes responsáveis por cumprir o plano de recuperação de desastres.
Os tipos comuns de testes são: simulação de testes - um cenário de desastre é 'declarado' e o pessoal afetado simula o que eles fariam naquela situação particular. É frequentemente usado para a execução de testes não técnicos e Testes paralelos - sistemas críticos são restaurados no local externo e os testes individuais do sistema e do aplicativo são executados. Isto é geralmente realizado durante um fim de semana.
Teste de Estratégias e Procedimentos Planejados:
Deve haver eventos planejados para revisar a integridade dos planos de teste, como uma lista de verificação dos testes (ou testes passo a passo). Os testes periódicos são necessários devido à contínua mudanças que podem levar a melhorias.
Segundo Martin, a questão importante não é que o teste tenha sido bem-sucedido sem problemas, mas que os resultados e os problemas encontrados são revisados e usados para atualizar ou revisar a atual recuperação de falhas (planejamento de procedimentos).
O teste pode ser realizado executando o plano de implementação de desastre ou pode ser desejável executar um subconjunto do plano. Ao executar um teste de recuperação de falhas, é muito importante usar apenas as informações recuperadas do local de armazenamento externo.
O plano de teste abrange as seguintes áreas: cronograma, introdução, equipes de teste, planejamento de pré-teste, teste de linha do tempo, pontos críticos de verificação de teste e registro de problemas de teste.
Requisitos Básicos para um Teste Eficaz:
É fundamental estabelecer um cenário antecipadamente. Uma estratégia de teste deve identificar o escopo do desastre (cenário); além de indicar quaisquer suposições que estão sendo feitas, como a duração prevista da interrupção, a disponibilidade do pessoal-chave de recuperação ou a oportunidade de executar um backup de última hora de dados críticos.
É importante definir objetivos de teste. Um teste deve ser realizado somente após a definição dos objetivos formais que deve indicar claramente qual é o exercício a ser testado. Por exemplo, o teste pode ser determinar, sob determinadas condições, com que rapidez o software do sistema e aplicativos podem ser ativados no hardware do hotsite. O teste também pode procurar medir o desempenho de um concentrador usado em conjunto com as estações de trabalho de usuários com perfis de baixa atividade. Os objetivos devem ser claramente indicado antes do exercício dos testes para ajudar na interpretação dos resultados do teste no final do exercício. Em geral, quanto menores os objetivos, mais valiosas serão as informações derivadas do teste.
Outra questão fundamental é o processo de definição das regras. Os procedimentos ou regras em uma operação de recuperação de teste devem ser executados e é necessário exigir e seguir rigorosamente, quando houver um desvio, o plano é necessário para realizar a tarefa. Isso revela algo sobre a adequação dos procedimentos do plano, e os participantes podem ser solicitados a fazer algumas anotações cuidadosas de quais etapas não documentadas devem ser tomadas para alcançar o objetivo. Em casos excepcionais, as regras para o teste podem ser flexíveis. Geralmente, esse tipo de regra de teste é usado para avaliar quão bem um
o participante da equipe pode improvisar ou desenvolver procedimentos onde não existia anteriormente.
A identificação dos participantes e observadores é um ponto crucial. Uma lista da equipe e dos observadores deve ser fornecida (geralmente auditoria interna), para o gerenciamento de TI e outras pessoas que participarão do teste.
Todos os membros devem estar plenamente conscientes de seu papel antes que o teste ocorra e os observadores devem saber exatamente o que procurar (buscar) e o que fazer. Os membros da equipe devem ser informados das regras e receber as devidas instruções que os ajudarão a coletar informações valiosas durante o teste.
É primordial documentar os resultados do teste, dependendo dos objetivos do teste, a saída pode ser impressa na forma de medições de desempenho do sistema, logs de transações ou outros relatórios contendo dados buscados no teste. Esses dados serão analisados e os documentos originais e as conclusões tiradas deles mantiveram o plano. As conclusões
do teste e a documentação de origem são uma parte importante da documentação que um auditor exigirá ao auditar a recuperação de desastres.
-----------------------------------------------------------x------------------------------
Tópico 4 ->
Auditoria e Monitoramento de Controles:
Um dos fatores mais importantes a considerar quando vamos discutir sobre a auditoria e monitoramento de controles é que o termo “auditoria” pode significar muitas coisas diferentes para diferentes pessoas. O que pode ser considerado como auditoria e monitoramento de controles em uma organização e em grande parte o domínio do auditor de computador especialista, pode ser realizado por auditores de negócios em outra organização. Por exemplo, a auditoria do computador pode ser restrita a software de sistemas de auditoria em uma organização, enquanto as áreas como sistemas de auditoria em desenvolvimento pode ser de responsabilidade do auditor comercial. Da mesma forma, em algumas organizações, não é incomum que o papel da auditoria de computadores seja estendido para incluir a revisão dos procedimentos administrativos e as produção de trabalho de auditoria baseado em conformidade aos programas para auditores de campo, fornecendo os serviço de auditoria de sistemas mais amplos.
Não há regras rígidas e rápidas sobre o que constitui auditoria de computador. Frequentemente, de acordo com o tamanho das organizações que operam no mesmo setor podem ter abordagens diferentes para auditoria de computadores. Mesmo quando parece haver comunalidade no escopo de áreas de auditoria, pode haver variações significativas em relação a profundidade da auditoria realizada.
Uma auditoria de um sistema operacional em uma organização pode exigir entre 5 e 10 homens-dia, enquanto em outro, o mesmo sistema operacional pode estar sujeito a um processo de diversos profissionais com duração de vários meses.
Saiba mais:
Na palestra intitulada de “Como melhorar o processo de Auditoria Interna”, ministrada no Lean Kanban Brazil 2018 é apresentado os desafios e os resultados da implementação do Kanban no processo de Auditoria Interna de uma das maiores instituições financeiras do país, que teve como foco a redução do lead time dos projetos e o aumento da colaboração entre os times.
Origens da Auditoria de Computadores:
A ausência de uma definição comum de auditoria de computadores pode, em parte, ser devida à relativa novidade deste processo. A história da auditoria tradicional ou inspeção pode ser rastreada por centenas de anos. Por outro lado, a auditoria de computadores é relativamente recente. Foi somente no final dos anos 1970 que a maioria das grandes organizações no Reino Unido estabeleceram um recurso de auditoria de computador pela primeira vez.
Uma característica fundamental de muitas organizações hoje é a mudança. Embora não seja necessariamente o motor da mudança, a TI é invariavelmente um componente intrínseco e grande parte da mudança não seria possível sem a TI.
A TI apresentou um grande impacto social, econômico e político em todo o mundo. Não só levou a criação de novas profissões, mas também revolucionou outros, como trabalho de escritório ou, quando combinado com robótica, indústrias de transformação. A auditoria por computador opera em um clima de constante e mudança rápida. Como a fraude e abuso de computador podem ter um efeito prejudicial sobre uma organização, é importante, portanto, que existam altos padrões de segurança e controle para minimizar o impacto potencial sobre a organização.
Pesquisas periódicas realizadas por organizações como a NATIONAL SUPERCOMPUTING CENTRE - NSCC, indicam os seguintes casos comuns de fraude e abuso de computador (NSCC, 2020):
1. divulgação não autorizada de informações confidenciais
2. indisponibilidade dos principais sistemas de TI
3. modificação / destruição não autorizada de software
4. modificação / destruição não autorizada de dados
5. roubo de hardware e software de TI
6. uso de instalações de TI para negócios pessoais
A maneira pela qual esses objetivos são alcançados, no entanto, muda fundamentalmente. Especificamente, é necessário maior controle na prevenção em vez de confiar nos mecanismos de controle corretivos que geralmente podem ser encontrado em sistemas manuais.
É importante ao considerar a auditoria do computador como parte integrante da auditoria geral. Geralmente é separado para permitir algumas questões de segurança e controle a serem tratadas efetivamente e fazer melhor uso da equipe especializada. A auditoria de computadores, portanto, é um meio para atingir um fim ao invés de um fim em si. Sempre existe uma tentação ao lidar com a TI para se tornar absorvido nas complexidades técnicas de um sistema operacional ou aplicativo e ignorar as realidades de negócios da organização.
Ao longo dos anos, o papel do auditor de computadores mudou gradativamente para ser mais consultivo, seu papel continua a amadurecer e desenvolver. Isso é essencial pois uma das principais atribuições é o fornecimento de um serviço de valor agregado à negócios em face cada vez mais sofisticado. Um dos principais desafios para os auditores de computador é manter-se atualizado com os constantes e rápidos desenvolvimentos; devendo buscar por treinamento contínuos.
Sem isso, os auditores de computador terão a sua capacidade limitada de auditar efetivamente e de fornecer um serviço valioso para a organização. Note-se também que o papel do auditor pode, em algumas áreas, sobrepor-se às funções de segurança do computador e isso pode causar uma grande confusão. É essencial definir claramente as respectivas responsabilidades para que a duplicação desnecessária seja evitada.
O papel do auditor de computador é fornecer à gerência sênior uma equipe independente e garantia objetiva quanto ao nível de segurança que será aplicada no ambiente de TI. Como parte integral do processo de auditoria, os auditores de computador também devem aconselhar e é nesta área que a duplicação e sobreposição pode surgir (e ser gerenciada de forma coerente).
Automação de Auditoria:
Em muitas organizações, as origens da auditoria de computadores residem na necessidade de auditores de negócios obterem os dados de forma independentes do sistema e, posteriormente, obter uma garantia sobre o funcionamento interno do sistema de TI. Embora a automação de auditoria ainda representa uma atividade principal de muitos auditores de computador, cada vez mais, essa atividade está sendo transferida para os auditores de negócios.
Essa transição foi facilitada pela disponibilidade de aplicativos mais amigáveis. O papel do auditor de computador neste ambiente é fornecer conhecimentos especializados aos auditores de negócios, em vez de realizar a atividade.
A automação de auditoria é geralmente considerada sob dois títulos principais:
1. como ferramenta de auditoria
2. como ferramenta de administração
Ferramentas de Auditoria:
A automação de auditoria, nesse contexto, envolve o uso de técnicas de auditoria assistida por computador (CAATS - Computer Aided Audit Tools) como uma parte integrante de uma revisão de auditoria para aumentar sua eficiência e eficácia. CAATS são geralmente categorizadas naqueles que revisam dados e os controles.
Os CAATS que revisam dados geralmente envolvem a extração, exame e manipulação de dados a partir de programas. Tais técnicas podem permitir ao auditor obter uma garantia quanto à precisão e integridade dos dados que estão sendo revisados e, implicitamente, a força ou fraqueza de controle.
Cada vez mais, existe uma grande variedade de produtos de software de terceiros disponíveis para o desenvolvimento do CAATS. Alguns dos mais conhecidos incluem:
A. IDEA (extração e análise interativa de dados)
B. ACL (linguagem de comando do auditor)
C. SQL (Structured Query Language - usado com bancos de dados relacionais)
D. SAS (software de análise estatística)
Há também uma grande variedade de outros software terceiros que podem auxiliar
em uma revisão de auditoria, como o CA-Examine para uma revisão do funcionamento do sistema IBM MVS, ou o Enterprise Security Manager da Axent para uma revisão do UNIX. Normalmente, os produtos serão usados para áreas como: planejamento, avaliação de riscos, registro de tempos, eletrônica, gestão dos documentos de trabalho e apresentações.
-----------------------------------------------------------x------------------------------
Tópico 5 ->
Virtualização:
Os computadores tornaram-se onipresentes em organizações acadêmicas, corporativas e governamentais. Ao mesmo tempo, o amplo uso de computadores deu origem a uma enorme complexidade de gerenciamento e diversos riscos de segurança. A virtualização surgiu como uma chave da tecnologia para resolver alguns desses problemas. A virtualização introduz essencialmente um nível de indireção a um sistema para dissociar aplicativos do subjacente sistema host.
Esse desacoplamento pode ser aproveitado para fornecer propriedades importantes, como isolamento e mobilidade, oferecendo uma infinidade de benefícios úteis. Esses benefícios incluem o suporte à consolidação do servidor, isolando os aplicativos de enquanto compartilham a mesma máquina, melhoram a segurança do sistema, isolando aplicativos vulneráveis de outros aplicativos de missão crítica em execução na mesma máquina, e a resiliência a falhas ao migrar aplicativos de hosts defeituosos, balanceamento de carga, migrando aplicativos para hosts carregados e disponibilidade e administração de serviços aprimoradas migrando aplicativos antes da manutenção do host para que eles possam continuar a funcionar com tempo de inatividade mínima.
Segundo Barham et. al., embora a virtualização possa ser realizada em diferentes níveis de abstração, as duas principais abordagens para fornecer a virtualização transparente de aplicativo são virtualização de hardware e virtualização do sistema operacional (SO). A virtualização de Hardware é o processo em que a arquitetura de hardware subjacente é utilizada a partir de uma máquina virtual para ser possível a realização do processo de desacoplação do sistema operacional do hardware para que um sistema operacional inteiro possam ser executados em um ambiente virtualizado.
As técnicas de virtualização de SO, são representadas pela virtualização do sistema operacional para desacoplar aplicativos do sistema operacional, para que os aplicativos individuais possam ser executados em ambientes virtualizados. As técnicas de virtualização de hardware e sistema operacional oferecem seus próprios benefícios e podem fornecer funcionalidades complementares. A virtualização de SO fornece uma granularidade fina de controle no nível de processos ou aplicativos individuais, sendo mais benéfico do que a abstração de virtualização de hardware que funciona com instâncias inteiras do sistema operacional.
Essa migração de granularidade mais fina fornece maior flexibilidade e resulta em menor sobrecarga. Além disso, se o sistema operacional requer manutenção, a virtualização do SO pode ser usado para migrar os aplicativos críticos para outra instância do sistema operacional em execução. Ao desacoplar os aplicativos da instância do SO, a virtualização do SO permite que o sistema operacional subjacente a ser corrigido e atualizado em tempo hábil, com impacto mínimo na disponibilidade do aplicativo (ou serviços).
A virtualização de hardware sozinha não pode fornecer essa funcionalidade, pois vincula aplicativos a uma instância do SO, e os sistemas operacionais de commodities inevitavelmente incorrem em tempo de inatividade devido às atualizações necessárias de manutenção e segurança. Dados os benefícios da virtualização de sistemas operacionais, os sistemas operacionais contemporâneos estão cada vez mais interessados em fornecer suporte para ele.
Alguns sistemas operacionais estão incorporando gradualmente o suporte à virtualização, fazendo alterações generalizadas no Kernel do SO. A virtualização do sistema operacional pode ser incorporada aos sistemas operacionais básicos com mudanças mínimas.
Conceitos de Virtualização:
A virtualização do SO isola processos dentro de um ambiente de execução virtual, monitorando sua interação com a instância do SO subjacente. De acordo com Popek et. all., semelhante à virtualização de hardware, os aplicativos executados no ambiente virtual devem exibir um efeito idêntico ao demonstrado como se tivessem sido executados no sistema não virtualizado. Além disso, um subconjunto estatisticamente dominante dos aplicativos com a interação dos recursos do sistema deve ser direta para minimizar a sobrecarga.
As abordagens de virtualização do SO pode ser relacionado em duas dimensões: independência do host e integridade. A dependência do host em relação com a virtualização apenas isola os processos enquanto é independente do host e a virtualização também os separa. A distinção é que a virtualização dependente de host simplesmente bloqueia ou filtra o espaço para o nome entre processos, enquanto a virtualização independente do host fornece um espaço de nome virtual privado para os recursos de SO referenciados dos aplicativos.
A virtualização independente de host encapsula processos em um namespace privado que traduz identificadores de recursos de qualquer host para os identificadores privados esperados pela migração (inscrição). De acordo com Laadan, em termos de integridade, a virtualização parcial, virtualiza apenas um subconjunto de recursos do SO. O exemplo mais comum disso é a memória virtual, que fornece a cada processo seu próprio espaço para o nome de memória privada, mas não virtualiza quaisquer outros recursos do sistema operacional.
Embora a virtualização parcial tenha sido usada para suportar modelos mais rígidos de segurança, limitando o escopo de processos defeituosos ou maliciosos, ele pode ser inseguro se houver caminhos diretos ou indiretos para os processos dentro do ambiente para acessar recursos externos ou mesmo romper com o meio ambiente. A virtualização completa virtualiza todos os recursos do sistema operacional. Enquanto os sistemas operacionais básicos fornecem a virtualização para alguns recursos, a virtualização completa requer a virtualização para muitos recursos que ainda não estão virtualizados, incluindo processos identificadores (PIDs - process identifiers ) e endereços de rede.
Dentro dessa taxonomia das abordagens de virtualização, a virtualização completa e independente do host fornece a mais ampla gama de funcionalidades, que inclui o suporte necessário ao isolamento e à migração de aplicativos.
Arquitetura de Interposição:
Para dar suporte a namespaces virtuais privados, os mecanismos devem ser fornecidos para traduzir entre os identificadores de recursos do pod e os identificadores de recursos do sistema operacional. Para cada recurso acessado por um processo em um pod é atrelado a virtualização (ou seja a camada associa um nome virtual a um nome físico do SO apropriado).
Quando um recurso do SO é criado para um processo em um pod, o nome físico retornado pelo sistema é capturado e um nome virtual privado correspondente é criado e retornado ao processo. Da mesma forma, sempre que um processo passa um nome virtual para o sistema operacional, a virtualização captura e substitui-o pelo nome físico correspondente.
A interposição é o principal mecanismo que pode fornecer o redirecionamento necessário para virtualização de namespaces. Em nosso contexto, a interposição captura eventos na interface entre aplicativos e o SO e executa alguns processamentos desses eventos antes de transmiti-los ao SO ou até aos aplicativos. A interposição que precisa ser feita para implementar a virtualização do SO requer que algum pré-processamento deve ser feito antes que a funcionalidade nativa do kernel seja executada e outro pós-processamento após a funcionalidade nativa do kernel é executada.
A interposição de chamadas do sistema pode ser implementada em diferentes camadas do sistema. Um módulo do
kernel pode fornecer virtualização transparente para aplicativos sem alterações básicas do kernel e sem sacrificar a escalabilidade e o desempenho. Além do que, operando em modo privilegiado, a virtualização pode fornecer a segurança necessária para garantir o isolamento correto. Trabalhando no nível dos módulos do kernel, o módulo de virtualização pode utilizar o conjunto de sub-rotinas do kernel exportadas, que é uma interface bem definida.
O uso da API do kernel também indica um certo nível de portabilidade e estabilidade na implementação, pois as mudanças na API do kernel são raras. Em outras palavras, a portabilidade da virtualização é protegida por uma grande extensão das alterações do kernel de maneira semelhante à proteção de aplicativos herdados.
Existem outras abordagens para implementar as chamadas de sistema. Uma abordagem é implementar a interposição como uma biblioteca no nível do usuário, de modo que o código de interposição é executado no contexto do processo que executa a chamada do sistema. Isso é relativamente fácil de implementar, pois potencialmente observamos a geração do código de uma maneira mais portátil e utiliza o limite claro entre o nível do usuário e o kernel.
Outra abordagem é usar um recurso de rastreamento de processo do kernel, como o ptrace, que permite um processo no nível do usuário para monitorar outro processo. Usando a funcionalidade do kernel disponível, essa abordagem de rastreamento de processos pode impor uma abstração de virtualização de SO com mais eficiência do que estritamente as abordagens no nível do usuário. No entanto, o ptrace tem muitas limitações em termos de desempenho e segurança, e a semântica do ptrace é altamente específica do sistema, o que resulta em um método não portátil.
Uma terceira abordagem é modificar o kernel diretamente para implementar a interposição. Isso oferece flexibilidade máxima, com a menor sobrecarga de interposição. No entanto, escrever o código diretamente no kernel é mais complicado do que no nível do usuário, mais difícil de depurar, e o resultado é provavelmente não-portátil. Além disso, impor um processo de correção, recompilação e reinicialização do kernel é uma barreira prática séria para a implantação e facilidade de uso.
-----------------------------------------------------------x------------------------------
Tópico 6 ->
Conclusão:
O gerenciamento de riscos deve identificar os riscos para os quais os planos de contingência devem ser colocados em prática, já o plano de contingência, está intimamente ligado aos resultados da avaliação de riscos e seu processo de mitigação.
Ao longo dessa unidade foi possível aprender sobre o plano de teste. Vimos que sua estrutura abrange as seguintes áreas: cronograma, introdução, equipes de teste, planejamento de pré-teste, cronograma de teste, pontos de verificação de teste críticos e log de problemas de teste. Quaisquer que sejam os objetivos, eles devem ser claramente declarados antes do exercício de teste para ajudar na interpretação dos resultados do teste.
Finalizamos a unidade discutindo sobre os conceitos de virtualização do Sistema Operacional. Verificamos a necessidade de interposição de chamadas do sistema para implementar a virtualização do SO e comparamos algumas abordagens para fornecer essa funcionalidade. Discutimos algumas condições de corrida que podem surgir na implementação da virtualização de SO e como essas condições de corrida podem ser endereçadas.
-----------------------------------------------------------x------------------------------