PCN/DRP: Desmistificando a Continuidade do Negócio

Gustavo Scotti, consultor estratégico da Axur Information Security.

Quando pensamos em um plano de continuidade de negócio ou em um plano para recuperação de desastres, a primeira idéia que surge em nossa mente é a alta disponibilidade: equipamentos redundantes, sites replicados ou a mais avançada tecnologia para minimizar a parada do negócio. A infra-estrutura de tecnologia da informação surgiu para permitir maior escalabilidade a processos que já eram feitos de forma manual. Sob o lumiar da visão e compreensão dos processos corporativos, este artigo pretende posicioná-lo frente ao desafio da disponibilidade x interesses do negócio, permitindo também a composição de uma gestão da continuidade do negócio em conformidade com a BS7799.

PCN

Partimos da premissa: o plano de continuidade não serve para diagnosticar problemas – o problema já deve ter sido identificado. Para que possamos visualizar a composição do negócio, vamos precisar mapear os processos da empresa, definindo seu macro-fluxo. Não podemos esquecer, é claro, da realização de uma análise de risco, que é de onde vamos retirar os eventos que podem incidir na parada de um processo. É bastante importante e igualmente significativo que nesta etapa seja identificada a importância de cada processo, utilizando para isso de uma abordagem qualitativa ou quantitativa.

Agora o nosso objetivo é detalhar cada um dos processos que sustentam o negócio e definir quais são os componentes que suportam cada processo. Mapeados todos os componentes, iremos perceber que alguns destes componentes estarão sempre presentes em todos os processos. Estes componentes são chamados de pilares da contingência, e devem ter um tratamento especial. Alguns exemplos de pila res são: pessoas, energia elétrica, requisitos legais e estrutura física. O rompimento de alguma dessas estruturas causam um impacto muito grande, quase sempre levando a um desastre.

Para cada componente elencado devemos ter, detalhadamente: condições de ativação (nossos eventos da análise de risco), responsáveis pela ação do plano (titular e substituto), ações de emergência, recuperação e restauração, tempo para execução do plano e histórico de testes. Imagine que você tenha um processo que necessite da fotocópia de determinado contrato. O que fazer, por exemplo, se este equipamento falhar? Quais são as ações emergenciais, recuperativas, e restaurativas? Em quanto tempo consigo restabelecer o componente para que o processo não pare? Você agora já deve estar pensando em ter uma máquina de fotocópia redundante. O gestor pode definir que o próprio cliente traga a cópia do seu contrato, ou que vá até um centro de cópias enquanto a máquina é levada ao conserto.

Para todo plano de continuidade, existe um custo para a ativação do plano emergencial. No nosso exemplo anterior, o gestor achou uma alternativa com custo zero, e o tempo de recuperação do componente tendendo ao imediato. Lembre-se que era necessário do mapeamento da importância de cada processo. O tempo de recuperação para cada processo irá estimar uma possível perda no momento que este processo falhar. Agora o impacto da parada sobre este processo de negócio já está mapeado.

PRD

Os pilares de contingência, alicerces do negócio, são críticos e representam uma espécie de esqueleto organizacional. Em eventos cujo impacto afeta a disponiblidade do negócio, geralmente podemos mensurar as perdas pelo tempo de parada. Entender e desenvolver um plano de recuperação de desastre é levar a sério o futuro em vista das diversas ameaças que nos cercam.

Vamos analisar um exemplo de interrupção do negócio por indisponibilidade da estrutura física principal. Imagine que você chegue para trabalhar, e o prédio onde estava seu escritório já não exista mais (neste exemplo descartamos a um desastre com perdas humanas). Quem faz o quê? Como? Quando? Quais são as prioridades?

O melhor método para definir um plano de recuperação de desastre é iniciar pelo teste de mesa. Debater com os responsáveis por cada processo significa entender como cada área atuaria em um momento de crise. Roompida a barreira do evento, inicia a análise racional das ações, relacionadas a recursos necessários para restaurar em um tempo mínimo os componentes vitais para que a operação da organização possa ser restaurada em níveis satisfatórios para a manutenção do negócio.

Um plano de PRD deve ser calculado para que a perda financeira seja equivalente ao investimento do plano. Entretanto, outros aspectos devem ser considerados, para que o negócio não perca a credibilidade e os clientes, como o fator “abalo a imagem” e “perda da credibilidade”.

O PCN e o PRD não devem ser concebidos de forma ideal, tendendo ao tempo de recuperação zero. Eles devem contemplar as soluções redundantes já existentes na empresa, e seguir um plano de gestão que garanta a sua constante renovação, sempre com ênfase ao negócio da empresa. Isto garante investimentos precisos nas áreas identificadas como críticas ao negócio da organização.

ROSI: Retorno sobre Investimentos em Segurança da Informação

Fabio F. Ramos, CISSP, CISM, CIFI, consultor da Axur Information Security.

Aclamado sobre a sigla ROSI – “Return on Security Investments”, a aversão ao risco de investimentos onerosos vem fazendo com que o Security Officer fique cada vez mais hábil no papel de justificar a implementação dos controles de segurança da informação.
A palavra de ordem na ciranda da proteção é “coerência”; dar espaço a tecnologia ou conceito que atenda adequadamente o controle do risco sem esquecer da nossa velha conhecida relação “custo/benefício”.

As diversas tecnologias de firewall, antivírus, IDS, controle de acesso físico e suas diversas configurações e características tornam árdua a tarefa de sacudí-los em um mesmo cesto e tirar o ticket com a solução que atenda de maneira eficiente pelo menor preço. Não menos complicado é justificar à Alta Administração a necessidade de se investir em uma tecnologia de segurança, porque afinal de contas “Nunca houve vazamento de informações ou paradas significantes no processo de negócio, por que deveríamos investir tanto?”. Só notamos a importância do capacete quando caímos da moto. E nós – profissionais de segurança -, ficamos a procura da fórmula-mágica, capaz de justificar o que parece tão evidente.

Bem, quando falamos em retorno sobre investimento, e o objetivo desta medição é segurança da informação, cabe lembrar que segundo estatísticas do Computer Security Institute e do FBI, no ano de 2002, 90% das empresas indagadas identificaram vulnerabilidades nos seus sistemas de tecnologia da informação. Com o avanço da tecnologia, o ciclo de desenvolvimento fica cada vez mais curto, aumentando a janela de vulnerabilidade dos sistemas. Esta tendência tende a se agravar nos próximos anos.

Uma vez que a gestão do risco está migrando de ser uma responsabilidade da área de tecnologia, passando a ser compartilhada de toda a organização – assumindo caráter estratégico -, faz-se necessária a instituição de métricas claras para que o diretor financeiro possa identificar de maneira tangível qual o verdadeiro retorno sobre o investimento.

Na verdade, a grande confusão gira em torno ao uso de uma regra de identificação do ROI (return on investment) através do valor o investimento menos o custo do incidente que tomaria espaço caso não existisse o controle contratado. A métrica indicada para mensurar o retorno econômico do investimento é a TIR (taxa interna de retorno). Isso pode facilitar bastante a compreensão do processo de investimento em determinado controle ou tecnologia.

A pergunta básica que leva a mensuração do valor médio para investimento na administração do risco é: qual o impacto decorrente à ocorrência de determinado risco? Para isso faz-se necessária uma análise de risco, que deve ser o ponto de partida para a definição da regra de investimento. Quando da escolha de um controle, muito cuidado na coleta de informações financeiras. Recomenda-se sempre observar, entre outros:

- Valor total das licenças;
- Valor da manutenção pelo período pós o vencimento da manutenção de garantia;
- Necessidade de treinamento de usuários ou administradores;
- Necessidade de contratação de consultoria;
- Necessidade de produtos extras para o funcionamento do controle;
- Restrições legais do uso ou restrições por país;
- Valor para renovação do contrato;
- Custo do chamado em horários fora do expediente.
Estas são informações que devemos passar ao analista financeiro para que possamos estar certos do custo real da solução.

A medida em que as organizações forem investindo em um sistema de gestão do risco, a tendência é que seja necessário cada vez menos investimento para manter o risco administrado. Conforme indicado na BS 7799 parte 2, o modelo PDCA (plan, do, check, act) permite a organização investir em controles que reduzam os riscos a níveis aceitáveis pela Alta Administração, significa assumir uma parte do risco – o risco residual, e controlar a outra parte.

É muito importante também que o Security Officer, em conjunto com o CFO (chief financial officer) ou diretor financeiro, ddeterminem qual o período de payback do projeto em vista do custo de capital da sua organização configurando o VPL (valor presente líquido). Isso pode variar muito de uma empresa para outra, e pode colaborar bastante no momento de determinar métricas para medição de resultados esperados e agendamento de fases subseqüentes em projetos de implementação. Permitirá à empresa um planejamento de curto, médio e longo prazo, acompanhando as tendências de evolução no seu cenário. Talvez através desta medição seja possível dizer com firmeza se a segurança é realmente parte de valor na cadeia produtiva do negócio da empresa.

Controle de Acesso: Como adequar seu ambiente aos requisitos da BS7799

Charles Schneider, consultor da Axur Information Security.

Você sabe como implementar um sistema de controle de acesso à informação que funcione de maneira verdadeiramente eficiente e não se torne um estorvo para o usuário final? Geralmente a resposta vem em coro “Coloque um firewall na entrada e tudo bem!”. Frente às técnicas de intrusão e a sofisticação das atuais arquiteturas de rede e sistemas, esta regra nem sempre funciona tão bem isoladamente. Controlar o acesso, na raiz do termo, significa restringir o acesso às informações. Este é um dos primeiros pontos a ser considerado de forma ampla e estratégica pelas organizações quando estiverem desenvolvendo um plano para proteção dos seus sistemas.

Ao longo deste artigo descreverei algumas técnicas que permitirá as organizações que necessitem maior embasamento obter uma estrutura de trabalho baseada nos controles de uma das mais importantes normas internacionais, a BS 7799. Uma mistura entre o melhor do aspecto teórico e do prático.

Como etapa inicial “em busca da rede segura”, é necessário que seja formalizada uma política de controle de acesso. Esta política deve considerar alguns tópicos como: requisitos de segurança de aplicações do negócio, identificação da informação referente às aplicações do negócio, classificação da informação conforme critérios de confidencialidade, legislação aplicável, obrigações contratuais, perfil dos usuários e gerenciamento dos direitos de acesso. Neste mesmo documento devem constar também as regras gerais de controle de acesso, definindo a aplicação do conceito “fecha tudo e só abre quando autorizado” ou “tudo é autorizado, exceto quando expressamente proibido”, sendo que esta segunda política quase nunca é aplicável. É necessário que este documento chegue a todos os usuários dos sistemas de informação.

É conveniente que seja implementado um sistema de gerenciamento de usuários que servirá para manter documentado todos os acessos lógicos e os privilégios que os usuários possuem no sistema. Este documento pode ser utilização para a concessão de acessos e privilégios aos usuários, onde a área de informática ficará de posse destes documentos para manter o controle de acesso devidamente organizado, capacitando ao departamento jurídico acionar legalmente o funcionário em caso de tentativas de acesso não autorizado.

O gestor poderá, periodicamente, conduzir uma análise crítica dos direitos e privilégios dos usuários para garantir que acessos não autorizados sejam registrados nos sistemas. Esta documentação cobrirá todo ciclo de vida de um usuário em um sistema.

O sucesso de um controle de acesso eficaz passa pela cooperação dos usuários que fazem parte da organização. Estes devem ser conscientizados a seguir as boas práticas para com suas senhas, mantendo sua confidencialidade e evitando ao máximo registrá-las de forma que possam ser lidas. Esta é uma parte importantíssima do processo e que requer o envolvimento de todos.

De que forma participa a área de informática? Sua participação é máxima. A área de informática deve proteger os serviços de rede através da implementação de controles, garantindo que usuários com acessos às redes e seu serviços não comprometam a segurança dos mesmos. Nesta etapa do processo, é necessário implantar outra política, que levará em consideração o uso de redes e seus serviços. Esta política deve considerar as redes aos quais o acesso é permitido e também um procedimento de autorização para determinar quem pode ter acesso a que redes e quais serviços.

Após formatada uma política coerente entre as necessidades do negócio e a tecnologia disponível, a área de informática deverá implantar os controles necessários para “defender” a organização. Existem diversos controles de rede disponíveis, mas como saber qual controle se mostra mais eficiente e onde implantá-lo? As implementações desses controles devem ser baseadas em uma análise de risco previamente elaborada.

Alguns controles de rede que devem ser considerados são:

§ rota de rede obrigatória, que serve para controlar o caminho entre o terminnal do usuário e o serviço de rede;

§ a autenticação para conexão de usuário externo.

Muito cuidado ao defender serviços externos, é necessário analisar se este serviço é extremamente necessário para o negócio, pois pode abrir portas de seu sistema para o mundo. Se necessário utilizar este serviço deve-se usar métodos de autenticação forte; a segregação de redes e o controle de conexões de rede podem ser feitos dividindo em domínio interno e externo, utilizando para isso o tão conhecido amigo “firewall” – citado no início do artigo, e que só agora entra em cartaz -, que filtrará o tráfego entre os domínios através de tabelas ou regras predefinidas.

Vamos tratar agora o sistema operacional. A proteção aos sistemas operacionais deve ser efetuada através das funcionalidades pré-existentes nos próprios sistemas, utilizadas para a restrição dos acessos não autorizados. O técnico da área de informática, mais precisamente o administrador de rede, deve configurar os sistemas para que o processo de entrada nos sistemas (logon) seja realizado através de um processo seguro. Um exemplo é limitar número de tentativas sem sucesso, registro das tentativas de acesso inválidas, obrigar o uso de senhas complexas e etc.

Após a obtenção de um sistema operacional bem protegido é necessário tratar às aplicações do negócio. Para isso, o proprietário da aplicação, que no caso pode ser o DBA, juntamente com o administrador de rede deve aplicar restrições aos sistemas para que os usuários mal intencionados não possam utilizar métodos para alterar os dados dos sistemas.

Mas não é somente nos domínios da organização que dados podem ser violados. Deve ser tomado um cuidado especial com a computação móvel e o trabalho remoto. Convém que seja adotada uma política formal levando em conta os riscos de trabalhar com estes recursos. Esta política deve conter os requisitos para proteção física, controles de acesso, criptografia e etc. É necessário que os usuários que se beneficiam deste recurso recebam treinamento específico.

Bem, o trabalho pesado está feito. Agora é necessário verificar o que está acontecendo e, para isso, é necessário que os sistemas sejam monitorados para detectar divergências entre a política de controle de acesso e os registros de eventos monitorados, fornecendo evidências no caso de incidentes de segurança.

Trilhas de auditoria devem ser configuradas nos sistemas para registrar eventos de segurança relevantes e mantidas por um período de tempo para auxiliar em investigações futuras. Alguns exemplos de eventos que devem ser registrados são: identificação do usuário, data e hora de entrada e saída no sistema, tentativas de acesso ao sistema aceitas e rejeitadas, alertas e falhas no sistema e etc. Para garantir a exatidão na auditoria, os relógios dos sistemas necessitam estar corretos, ajustado conforme algum padrão local de tempo.

Pessoal, espero que o artigo tenha sido proveitoso. Fica a pergunta “Depois desta implementação, nenhum usuário não autorizado acessará o sistema?” Bem, prometer ninguém pode, pois à medida que se expõe a informação, tanto internamente quanto externamente, o risco sempre existirá – por menor que seja. O que garantimos é uma administração inteligente do risco.

Desenvolvimento de Sistemas: Segurança nas aplicações de negócio

André Palma, consultor da Axur Information Security.

Os sistemas de informação representam o principal frame por onde transitam as informações de uma instituição. Afinal o objetivo destes sistemas é justamente concentrar o maior fluxo possível de informações permitindo agilidade nos processos de negócio. Entretanto nem sempre as empresas adotam as medidas de segurança necessárias durante o desenvolvimento de sistemas, para a proteção adequada destas informações.

Controles pontuais são perfeitamente válidos, porém não garantem, por si só, a segurança das informações. Um ambiente seguro devem empregar produtos de segurança sem esquecer de inserir a segurança em seus processos. Muitas empresas vêem empregando controles individuais, desconsiderando a necessidade de definição e principalmente de formalização de seus processos.

A área de desenvolvimento das empresas é um exemplo claro de processo que nem sempre recebe as atenções necessárias no que diz respeito à segurança da informação. Garantir a segurança da rede corporativa não significa ter sistemas de informação seguros. A informalidade ainda predomina nas relações entre desenvolvimento e suporte operacional.

O primeiro passo para inserir a segurança da informação na área de desenvolvimento de sistemas é definir formalmente este processo. Uma abordagem adequada é considerar como início do processo as solicitações dos usuários e como final a liberação das novas versões para produção.

Entre estes dois pontos deve existir uma avaliação do Analista de Segurança. Este analista pode ser um dos próprios Analistas de Sistemas, porem capacitados a determinar quais são os controles de segurança necessários para determinada especificação de sistema. Por exemplo, um usuário solicita inserir novos campos em um formulário. O Analista de Segurança deve avaliar esta solicitação e inserir, na especificação, a necessidade de validação de entrada, caso integridade externa seja fundamental para o negócio em questão.

A equipe de desenvolvimento somente deve receber especificações para novos sistemas ou modificações nos sistemas existentes após avaliação dos requisitos de segurança. É indispensável a formalização destes requisitos, juntamente com os requisitos do negócio apontados pelo usuário. O desenvolvimento das soluções deve respeitar integralmente as definições de segurança impostas pelo Analista de Segurança e documentadas junto aos requisitos do sistema.

Após o desenvolvimento da solução, o Analista de Segurança deve realizar uma verificação se os controles realmente são válidos e garantem, no caso do nosso exemplo, a inserção exclusiva de dados representativos. Após passar pela aprovação de segurança é necessário realizar testes formais com os usuários. Estes testes devem ser realizados em ambientes próprios, totalmente isolados do ambiente de produção.

A confirmação dos usuários de que o sistema incorpora as funções solicitadas deve ser visto como requisito mínimo para a distribuição da nova versão no ambiente de produção. Os procedimentos de distribuição também precisam estar definidos formalmente, pois representam uma fase crítica do processo. Quando possível, convém que sejam realizados testes verificando se as novas versões não possuem funções ocultas, ou os famosos covert channels, que já foram responsáveis por diversos incidentes de segurança.

Cada fase do processo deve ser formalizada e devidamente autorizada. Para isso, é importante manter uma lista de níveis de autorização, ou seja, quem pode autorizar cada fase do processo. Deve-se exigir também que os desenvolvedores documentem cada novo sistema ou modificação realizada, destacando as funções de segurança incorporadas.

Entretanto, a segurança da informação não é obtida apenas através da formalização do processo. Algumas medidas devem ser adotadas para garantir, sobretudo que cada informação é divulgada a quem se faz necessário – conceito conhecido como need to know.

Em primeiro lugar e requisito para todo o processo de desenvolvimento, os ambientes de produção e desenvolvimento deveem ser segregados. Além de fisicamente separados, em salas ou locais diferentes, devem estar logicamente separados, de preferência em redes próprias, separadas por firewalls da rede de produção. Máquinas da produção não devem realizar suporte ou qualquer outra atividade, devem ser vistas como ferramentas de desenvolvimento apenas.

Um segundo passo importante é não fornecer dados reais para testes. Muitas empresas copiam sua base de dados de alguns meses anteriores e disponibilizam aos desenvolvedores como teste. Claro que a base de testes deve representar como a máxima fidelidade a realidade do negócio. Porém pode-se obter isso através de procedimentos de descaracterização da base de dados. É importante substituir dados de clientes por dados aleatórios, números de contas por números aleatórios, ou seja, e qualquer outra informação que possa ser refletida na realidade deve ser descaracterizada.

Controles de criptografia devem ser sempre considerados e avaliados. Nem sempre são necessário, principalmente frente ao overhead que podem causar nos servidores de produção. Porém existem soluções interessantes, como autenticação de mensagens e serviços de não repúdio que não acrescentam volume às taxas de processamento.

O controle de acesso ao código fonte deve ser rigidamente definido. É importante que o responsável pelo desenvolvimento atribua a cada desenvolvedor acesso aos fontes e projetos que este está diretamente ligado. Produtos de controle de versão são interessantes neste sentido, entretanto uma organização através de servidores de arquivos com acessos definidos também resolve a questão.

Por último, é importante que o ambiente de teste seja dedicado. Uma estação de trabalho e um pequeno servidor rodando a aplicação com acesso a base de testes são o suficiente para que os usuários possam identificar e testar as novas características desenvolvidas. Esse ambiente não deve ser conectado ao ambiente de produção. Pode estar isolado ou conectado ao ambiente de desenvolvimento.

Estes são alguns mecanismos que quando adotados concorrem para o aumento da segurança nas aplicações de negócio. Não se deve esquecer que o controle e auditoria do processo devem ser realizados pelo Security Officer, ou pessoa que assume este papel na empresa. Vale ressaltar que estas medidas de segurança não só protegem as informações da empresa, mas também organizam o processo de desenvolvimento. Nada mais correto, pois um ambiente seguro é forte candidato a ser um ambiente organizado.

Segurança de Pessoas: Separation of Duties & Job Rotation

Fabio F. Ramos, CISSP, CISM, CIFI, consultor da Axur Information Security.

Um dos principais aspectos da administração de segurança de uma empresa é ter de gerir recursos humanos. Na configuração de um sistema seguro – utilizando o termo sistema em uma perspectiva de negócio -, o elemento humano é o que costumamos chamar “o elo mais fraco” na cadeia de segurança da informação. Duas das principais técnicas utilizadas pelos departamentos de Recursos Humanos, em conjunto com o departamento de Segurança da Informação, é o separation of duties (separação de atividades) e job rotation (rotação de postos).

O objetivo do “separation of duties” é garantir que, em última instância, uma só pessoa – independente dos privilégios de sistema que possua - não consiga realizar atividades danosas à organização. Lembram do esteriótipo do militar durante a guerra fria, onde o general só conseguiria premer o botão de lançamento da bomba nuclear caso fossem acionadas duas chaves distantes entre si? Independente de possuir as duas chaves, o sujeito fica impedido de executar a ação; seria necessário pedir ajuda a um segundo elemento para realizar esta tarefa, classificada pelo impacto.

Recomenda-se que atividades consideradas de alto risco sejam divididas em pequenas partes e distribuídas para diferentes funcionários, preferencialmente – e quando aplicável – pessoas de áreas ou departamentos distintos, e sem vínculo profissional direto. Esta é uma forma de não correr riscos pelo “excesso de confiança”. É saudável para a empresa e também para o funcionário, que fica impossibilitado de gerar ações prejudiciais à informação mesmo que acidentalmente.

Além de previnir ações intencionais, a técnica de “separation of duties” é um eficiente mecanismo de prevenção para a ocorrência de incidentes não intencionais, freqüentes em atividades onde uma única pessoa executa a tarefa do início ao fim. Um resultado prático desta realidade é quando o sistema operacional instalado pelo administrador é homologado pela equipe de segurança; existe aí uma configuração de separação de atividades, seria muito pouco provável que o administrador encontrasse erros na sua própria instalação. É sempre bom contar com uma segunda opinião. Existem teorias bastante avançadas sobre divisão de atividades e definição de papéis, com responsabilidades para o gestor, custodiador e para o usuário da informação.

A técnica de “job rotation” transcende ao simples fato de alguém realizar atividades no lugar de outra pessoa. Significa alternar, periodicamente, pessoas que ocupam cargos operacionais. Esta prática é muito utilizada quando a análise de risco identifica demasiada dependência de um processo de negócio ou sistema a um operador, administrador e etc. Através da técnica de “ job rotation” outra pessoa pode ser preparada para ocupar o lugar do administrador, operador, analista ou quem quer que seja, servindo como redundância para a função, caso o funcionário deixe a empresa repentinamente ou fique indisponível à empresa por um longo período.

O segundo benefício direto do “job rotation”, e não menos importante que o primeiro, é a condição onde a empresa pode facilmente detectar o encaminhamento ou a realização de fraude como “data diddling” ou outras.

Seja na substituição do ocupante oficial do cargo por férias obrigatórias ou na familiarização das atividades executadas pelo elemento substituinte, a empresa poderá identificar a existência de indícios de atividades ilícitas ou ações que não condizem com as atribuições do cargo.

Estas são duas técnicas bastante utilizadas em empresas que trabalham com operações que envolvem finanças, compra ou venda de ativos. Considerando que a informação representa – e cada vez mais representará – o ativo de maior importância para uma organização, e para isso tomemos como referência o grande número de organizações que já estão utilizando sistemas de Business Intelligence e Balanced Scorecard, os custodiadores da informação serão os elementos mais visados dentro das operações de negócio. Com técnicas como as apresentadas, somadas à administração do risco tecnollógico, a implementação e divulgação da Política de Segurança e a uma gestão baseada em indicadores de resultado, o risco operação tende a ser minimizado e controlado.

Security Awareness através do método D3/AET

Fabio F. Ramos, CISSP, CISM, CIFI, consultor da Axur Information Security.

A melhor forma de conquistar o usuário como aliado em um processo de gestão da segurança da informação é tornando-o consciente das suas responsabilidades e dos riscos que enfrentará em seu dia a dia. Devemos agir com sinceridade e apresentar sem rodeios o cenário que se faz presente. Se estivermos em uma empresa que possui uma área de engenharia, o engenheiro deve estar ciente da possibilidade de vazamento ou corrupção da informação; a área comercial da mesma forma, preocupada com a confidencialidade, disponibilidade, integridade e privacidade da informação, e nas conseqüências que este comprometimento pode acarretar.

A conscientização de segurança deve ser vista como auxiliar indispensável aos controles tecnológicos planejados ou já implementados. Igualmente importante se comparada a um firewall, um sistema de detecção de intrusos ou um sistema biométrico, a cultura organizacional pode trazer grandes benefícios para a organização; o principal deles sem dúvida alguma é o comprometimento.

Um usuário comprometido é um grande aliado, tanto na utilização segura da infomação, quanto no mapeamento de riscos ainda não identificados. É uma cadeia de conhecimento importantíssima formada a partir da conscientização e educação. Quanto maior for o conhecimento deste usuário, maior será sua capacidade de julgamento, refletindo em uma postura próativa, madura e coerente (eficiente) frente às suas responsabilidades no processo de segurança.

A prática do treinamento em segurança, ainda tão pouco utilizada no Brasil, realiza na organização o sentimento da existência de uma direção clara frente as práticas consideradas pelos gestores do negócio, como adequadas no trato com a informação. Não há mais espaço para o formalismo burocratizado das Políticas de Segurança criadas para satisfazer a auditoria. A consolidação de uma “cultura de segurança” é de indiscutível relevância quando analisamos ameaças internas (fraude, mau uso da informação, sabotagem, etc).

Nossa realidade tecnológica impõe ao usuário um uso multifacetado da tecnologia. São rotinas, responsabilidades, privilégios dentre outros, que fazem do usuário um dos mais vulneráveis elos da cadeia de segurança. Para vencer o desafio de trazer à naturalidade o controle da informação, deve-se apresentar ao usuário - em um exercício prático -, qual a importância do seu papel na gestão da informação. Ao invés de perceber a segurança como um adicional à sua atividade, o usuário deverá reconhecer a segurança como parte da sua atividade.

O ciclo básico do Security Awareness segue o modelo D3/AET. Este modelo vem sendo utilizado em função da estrutura de framework que disponbiliza, baseado nas melhores práticas para formação de uma cultura organizacional. Todos os funcionários devem ser avaliados, treinados e novamente avaliados.

O modelo D3/AET traz na forma abreviada a união das primeiras letras de Diagnose, Development, Definition/Awareness, Education (e) Training. A modelagem organiza-se da seguinte forma:

1. Diagnose - Diagnóstico do nível de cultura de segurança da organização
2. Definition - Definição da estratégia de implementação da cultura
3. Development - Desenvolvimento do material para implementação da estratégia

Awareness - Conscientização;
Education - Educação;
Training - Treinamento

Diagnóstico do nível de cultura: essencial a um projeto desta natureza, o diagnóstico vai apontar o nível de cultura atual na organização. O resultado desta avaliação deve ser apresentado preferencialmente em indicadores quantitativos. Algo do tipo: “Departamento Comercial alcançou um desempenho de 80% no conhecimento da política de antivírus”. É importante que já exista uma Política implementada; não faz sentido avaliar a cultura de segurança dos usuários se não existirem parâmetros para o certo e errado.

Definição da estratégia de implementação: este é o momento onde definiremos qual é a melhor maneira para alcançarmos os objetivos almejados. Existem diversas estratéggias para implementação. É importante frisar que mesmo em um plano teórico, já é o momento de identificar volume de investimento na campanha de divulgação, no suporte e no reforço a cultura de segurança da informação da organização.
Desenvolvimento do material para implementação da estratégia: o material que será utilizado para a divulgação da cultura deve ser confeccionado preferencialmente por uma equipe de marketing (endomarketing), em colaboração e com assessoria do Security Officer. Oferecer um conteúdo de fácil digestão quando se fala em segurança da informação, pode não ser um desafio tão simples. Uma boa sugestão é a criação de um simpático mascote com a intenção de tornar o processo de divulgação algo agradável aos olhos do usuário. Lembre-se da regra de ouro: não se conquista aliados com coação. Dizer que todos serão monitorados e comportamentos inadequados serão punidos, pode ser uma faca de dois gumes. Ao invés de amedrontar, a prática nos dá provas de que o melhor é encorajá-los a participar como agentes no controle da informação.

Awareness: o usuário só estará comprometido com a segurança da informação quando for capaz de compreender a importância da sua participação efetiva no processo de gestão da segurança. A conscientização deve despertar para uma visão instintiva. Um insight. O que até então nem era percebido, passa a fazer parte quase que natural do pensamento deste usuário. Sabe aquele cuidado que temos ao sair do carro à noite? Checar se os vidros estão fechados mesmo quando guardamos o carro na garagem. É natural, não? Esta é a chave do sucesso.

Educação: O processo de educação torna claro aos funcionários que a organização está preocupada com a informação. Assim há o resguardo da organização quanto ao “dito pelo não dito”, é a caracterização do seu due care. É suficiente apoiar a divulgação em dez objetivos ou metas, tratando pontos que reflitam o pensamento da organização frente aos riscos que mais a preocupam. Alguns exemplos de tópicos que podem ser abordados:

Vírus de Computador e Cavalo de Troia
Uso de e-mail com segurança
Uso de senhas seguras
Uso da internet com segurança
Práticas de Backup

É interessante que estas palestras não passem de 50 minutos e que ao final, o usuário possa ser avaliado sem sentir que com isso será julgado ou punido. Este tipo de teste deve seguir o carater de “orientação”.

Treinamentos: são divididos os grupos para o treinamento. Geralmente são disponibilizadas turmas de maneira que estejam juntos os grupos de interesse como, por exemplo, departamento comercial, engenharia, diretoria e etc. Desta forma pode-se personalizar o discurso e direcionar o conhecimento àquilo que se aplica às atividades de cada setor, departamento ou unidade. Os treinamentos incorporam o cuidado de segurança à rotina do usuário. Criar uma rotina nos poupa energia e automatiza o acerto.

Uma boa didática, sintonizada com a expcetativa da audiência, utilização de um material rico em exemplos e com bons insights podem ser decisivos para se alcançar êxito na aceitação do usuário. No começo pode ser um pouco dificil organizar uma apresentação com a fórmula certeira para conquistar o público, mas com o passar do tempo e com o feedback dos próprios usuários, a empresa acabará formatando seu modus operandi.

- x - x-

Apesar da simplicidade com o qual o assunto Security Awareness foi aqui exposto, espero sinceramente que possa depertar para ações imediatas o pensamento dos gestores de segurança da informação que nos deram seu precioso tempo na leitura deste artigo. Se quisermos garantir a segurança incondicional da informação, devemos aprender que avaliar o risco é lidar com o imprevisto: conscientizar, educar, treinar significa fazer deste risco um ideal compartilhado entre todos os componentes humanos, parte do processo de valor de uma organização. Administrar o risco, mais do que escondê-lo, é trazê-lo em evidência para quem possa interessar.

Auditoria em Windows XP

Fabio F. Ramos, CISSP, CISM, CIFI, consultor da Axur Information Security.

Uma das preocupações da maioria do gestores de Segurança da Informação sempre foi de transformar os controles de segurança em mecanismos transparentes ao usuário final – impacto zero ao ambiente de trabalho. O antívirus: atualizado no gateway; o backup: automatizado no servidor de arquivos; a troca de senhas: solicitada automaticamente pelo sistema. O que seria de nós sem estes artifícios? O usuário muitas vezes não tem culpa por não conhecer os riscos frente à informação, mas em uma coisa temos que concordar: ajudaria muito, caso o usuário soubesse como é importante sua colaboração efetiva na salvaguarda da informação.

Com a intenção de ajudar os Security Officers, resolvemos lançar uma série de artigos que podem ser enviados aos usuários, de forma a colaborar no processo de sensibilização do nosso maior aliado na proteção da informação. Iniciaremos com o tema Auditoria, depois passaremos por Engenharia Social, Backup, Senhas Seguras e etc. Contamos com sua indicação para novos assuntos, afinal de contas, escrevemos para você leitor.

A. Por que auditar?

Somos todos usuários de sistemas que compartilham, modificam, criam e muitas vezes delegam autoridade a outros para o manuseio da informação. Alguns anos atrás essa responsabilidade ficava toda centrada em um mainframe, passamos então para o tempo da “informação distribuída”, e atualmente devemos lidar com uma informação viva e muitas vezes descontrolada. Outro agravante é a facilidade com que qualquer leigo opera um sistema operacional, não podemos mais contar com o fator “obscuridade técnica”.

Já que não podemos confiar na inocência técnica do “novo usuário” – usuário que conhece melhor do que ninguém os meandros das tecnologias presentes na maioria das organizações -, então devemos contar com sua colaboração na proteção da informação. É neste momento que surge a auditoria, grande aliada quando da desconfiança de que alguém pode ter bisbilhotado aquela pasta com informações confidenciais: seja o orçamento do ano, lançamento de um novo produto, movimentações financeiras, lista de clientes, etc. Parece familiar? Como saber que o “intruso” passou pela nossa casa se ele não quebrou o vidro? Cantam alguns jargões da segurança: “Pior do que ter seu computador invadido, é não saber que o computador foi invadido”.

Auditar significa pré-selecionar uma série de eventos de forma que o sistema armazene mensagens para diversos tipos de comportamentos gerados em nosso computador. Por exemplo, posso criar uma política de auditoria onde o sistema armazenará toda a tentativa de acesso a minha máquina utilizando o meu nome de usuário (username) e uma senha inválida. Caso eu ative esta auditoria, poderei futuramente identificar detalhes sobre situações onde algum individuo tenha tentado adivinhar minha senha para obter acesso a minha estação de trabalho. Sabemos que um ataque bem sucedido é sempre precedido de uma série de tentativas inválidas de acesso. A primeira acepção da palavra auditoria, no sentido prático, é a prevenção.

O segundo benefício direto da ativação da auditoria em sua estação de trabalho, é a possibilidade averiguação dos passos de um invasor, uma vez evidenciado o incidente de segurança. É o que chamamos de trilha de auditoria. Analisando o caminho do intruso, seja ele um hacker ou um colega de trabalho, fica mais fácil compreender a motivação de sua ação, e qual era o seu “alvo” – entenda-se informação.

B. Como ativar a auditoria do WindowsXP?

Escolhi o WindowsXP em inglês porque este sistema operacional está sendo amplamente utilizado no mundo todo, além do que ele conta com recursos super práticos para ativação da auditoria, sem que o usuário tenha que recorrer a especialistas ou técnicos.

Bem, agora mãos a obra: não há dificuldade em ativar a auditoria, qualquer usuário com conhecimento mínimo do sistema operacional conseguirá executar. É importante verificar se a Política de Segurança da Informação da sua empresa permite este tipo de alteração no sistema. Caso não exista uma Políttica para usuários, converse com o administrador e solicite que você possa auditar o que acontece em sua estação de trabalho; antes de tudo é importante respeitar as Diretrizes de Segurança da sua organização. De qualquer forma, você pode ativar esta política no seu computador doméstico.

Vá ao (1) Control Panel, (2) Administrative Tools, (3) Local Security Policy. Agora, neste tela você abre o item (i) Local Policies, e clica em (ii) Audit Policy. A seleção deve ficar conforme a tabela abaixo:

Tabela de Nível de Auditoria

Account logon events Success, failureAccount management Success, failureLogon events Success, failureObject access Success, failurePolicy change Success, failurePrivilege user Success, failureSystem Events Success, failure

C. Auditoria em Arquivos

Quando arquivos como ftp.exe, tftp.exe, command.com, cmd.exe, telnet.exe, wscript.exe e cscript.exe não puderem ser desabilitados, é importante deixá-los em constante auditoria. É através destes arquivos que um invasor faz o download de códigos maliciosos para o computador do usuário. Recomenda-se também ativar a auditoria em arquivos executáveis que permitem acesso a aplicações críticas.

Pressione o segundo botão do mouse sobre o arquivo que você deseja auditar. Pode ser uma planilha do XLS, um DOC ou um desenho em CAD. Vá em (1) Properties, selecione (2) Security e depois clique em (3) Advanced. Agora você clica em (i) Auditing e (ii) Add para adicionar o grupo que você pretende auditar. Neste caso vamos inserir Everyone para uma auditoria ampla. Clicando OK você sairá em uma tela onde os objetos de auditoria podem ser selecionados. Recomendo ativar os itens Traverse Folder/Execute File, Write Attributes e Delete. Todos na opção Failed. Simples, não é?

Pronto. Uma vez selecionado, devemos criar uma rotina pessoal de verificação dos eventos gerados, pelo menos uma olhada por semana. Definimos aquilo que é considerado comportamento estranho, e filtramos para podermos visualizar só o que interessa. É muito simples.

Para visualizar as informações geradas, siga os seguintes passos. Vá ao (1) Control Panel, (2) Administrative Tools, (3) Event Viewer. Clique no item (i) Security do menu da esquerda. Pronto, ai estão os eventos gerados, classificados por tipo, data e categoria. Clicando duas vezes sobre o registro você poderá obter mais informações sobre o evento.

Bem, a mensagem desta semana é: usuário, aprenda a se defender. Estamos enfrentando tempos difíceis onde qualquer um pode sem muito esforço obter informações sensíveis ou privilegiadas vasculhando o computador alheio. É bom lembrar que a responsabilidade pelas informações que estão hospedadas em nossa estação de trabalho, é individual e não deve ser compartilhada. Até o próximo artigo.