Suporte Executivo
e Segurança de TI (Parte I)
|
 |
 |
|
Introdução
Há seis meses, você finalmente alcançou
o posto de Diretor de Informática de uma grande
empresa. Como um bom diretor, você enfatiza várias
vezes a importância da segurança aos seus
gerentes sêniores. Aliás, você torna
claro e sem margem para dúvidas que é
necessário que a rede se mantenha segura e ponto
final, sem discussões.
Imagine a sua surpresa quando, em uma segunda-feira,
você abre o jornal Mercury News e vê que
a sua empresa se encontra nas manchetes, e o motivo
não são os resultados surpreendentes do
trimestre. A história conta os detalhes do ataque
de um hacker à rede da sua empresa. O hacker
se apropriou de informações confidenciais
e as postou na Internet, para que todo mundo pudesse
vê-las. É notícia de primeira página,
e você se indaga se você vai aparecer na
CNN hoje. Você se pergunta também o impacto
que isso causará no preço das ações
da sua empresa. O que os acionistas irão dizer?
À medida que as semanas passam, sua equipe de
suporte tenta manter tudo sob controle. Infelizmente,
há tantos riscos de segurança na sua rede
que essa tarefa parece ser impossível. O hacker
parece saber disso, e parece estar utilizando a sua
rede para a praticar. O ataque persiste, não
apenas uma ou duas vezes, mas o tempo todo.
Como isso foi acontecer? Você diz aos seus superiores
que a segurança era uma grande preocupação,
e que você esperava que fosse uma prioridade.
Você não foi ouvido? Como puderam permitir
que intrusos eletrônicos se apropriassem de segredos
da empresa? E ainda pior, os contínuos ataques
estão destruindo a reputação da
sua empresa, uma reputação que você
trabalhou tão arduamente para obter. Como Diretor
de Informática, a sua reputação
também não é das melhores no momento.
É a sua rede, portanto, as atenções
estão voltadas para você.
Parece impossível? Pouco provável? Esta
situação foi inventada, mas é uma
situação bastante real e com freqüência
enfrentada por novos Diretores de Informática.
Os aspirantes a funcionários quase nunca possuem
um conhecimento abrangente das configurações
e status da rede. Antes de aceitar a vaga, poucos candidatos
perguntam se a rede foi submetida (e aprovada) a uma
auditoria de segurança. Menos ainda recebem um
resumo de nível executivo, mostrando o nível
de riscos, ou possuem um bom conhecimento sobre a realidade
da segurança nas empresas.
Em grandes empresas, diferentes níveis de gerência
geralmente separam os gerentes dos executivos. Como
resultado, a comunicação é prejudicada.
As informações provenientes da diretoria,
destinadas ao resto da empresa, podem não ser
entregues. Da mesma forma, as informações
de baixo para cima podem ser facilmente mal direcionadas
ou modificadas.
É claro que nenhum executivo, gerente ou supervisor
pensa realmente que a sua própria rede possa
ser a manchete da próxima edição
de 60 Minutes ou Hard Copy. Mas, ao menos que você
saiba o que realmente está acontecendo na empresa,
ela poderá estar correndo risco. Certifique-se
de que os executivos de sua empresa não estejam
ditando regras sem o conhecimento da realidade da empresa.
Manter as linhas de comunicação abertas
até o topo da empresa é a forma mais importante
de garantir a segurança da sua rede. Considere...
O Compromisso dos Executivos
A Sra. Smith, Diretora Executiva e fundadora da Internet
Software Design (ISD), a partir de uma idéia
escrita em um guardanapo, transformou sua empresa em
um sucesso, da noite para o dia. Esta empresa de tecnologia
de ponta no Vale do Silício, que está
na lista de empresas da Fortune 500, entrou em um novo
mercado e eliminou a concorrência, sem grandes
dificuldades. No mercado de design de software, a empresa
tornou a segurança de computadores uma prioridade
básica. A Sra. Smith continuou a enfatizar seu
compromisso com a segurança à sua equipe
de gerência executiva. Ela se tornou muito conhecida
pelo seu estilo direto, e sempre atingiu o que desejava.
Bom, quase sempre.
Como vários Diretores Executivos que dão
ordens e esperam que sejam cumpridas, a Sra. Smith presumiu
que a sua empresa internacional estivesse segura, até
o dia em que um hacker invadiu a rede financeira de
sua empresa. Sem que fosse detectado pelos funcionários
de suporte, o hacker transferiu todos os dados financeiros
da empresa para outro sistema na Internet. Quando a
transferência foi concluída, o hacker enviou
um e-mail contendo o status financeiro da Sra. Smith
(incluindo as previsões de faturamento) para
os investidores do Fishman & McDonald.
Por sorte da Sra. Smith e de sua empresa, um gerente
dessa empresa de segurança relatou imediatamente
o conteúdo do e-mail a Charles Winifred, Diretor
Financeiro da empresa de Smith. Esse relatório
foi a primeira indicação que Charles teve
de que uma violação de segurança
havia ocorrido, e o deixou com várias perguntas
sem respostas. Charles gostaria de saber como
o sistema tinha sido violado. Ele queria saber por
quê seus funcionários de
suporte não detectaram o acesso não autorizado
aos dados. E queria, é claro, saber quem
foi o responsável pelo roubo e divulgação
das informações. Basicamente, ele queria
respostas imediatamente.
Charles presumiu que sua rede financeira estivesse
segura. Afinal de contas, não era para isso que
eles pagavam seus administradores de sistema? Como eles
puderam ser tão negligentes? E como não
perceberam a violação da segurança
antes que os dados fossem divulgados pela Internet?
Porém, Charles não levou em consideração
um importante conceito em responsabilidade administrativa.
O verdadeiro responsável pela confiabilidade
e integridade dos dados armazenados em redes corporativas
é a gerência, e não os administradores
de sistema. Os acionistas e auditores responsabilizarão
principalmente os gerentes executivos. Se a previsão
de faturamento da empresa é publicada na Internet,
os auditores, acionistas e a imprensa procurarão
os executivos das empresas, e não os administradores
de sistemas.
Para ilustrar melhor as funções do gerenciamento
na segurança da computação, vamos
analisar mais de perto os eventos antes e depois da
divulgação das informações
financeiras da ISD.
Dia 1: sistemas inseguros
A pedido de Charles, o especialista de segurança
interna da ISD, Martin Patterson, foi chamado imediatamente
para conduzir uma auditoria de segurança. Martin
era um dos cinco membros da equipe de segurança
da ISD e talvez o melhor guru de segurança da
empresa. Ele sempre levou a sério qualquer nível
de violação de segurança, sempre
priorizando as respostas a incidentes na sua lista de
tarefas. Basicamente, Martin imediatamente parava o
que estivesse fazendo e atacava cada incidente de segurança
com a ferocidade de um pitbull.
Martin começou sua auditoria investigando as
informações dos sistemas financeiros e
testando a rede à procura de vulnerabilidades
de segurança. Ele levou menos de uma hora para
obter os resultados, que na verdade foram bastante chocantes.
Para uma empresa que dizia-se tão comprometida
com a segurança, a realidade era espantosa.
Martin descobriu que os sistemas corporativos foram
instalados diretamente da caixa, sem configurações
de segurança. Sistemas cruciais foram incorretamente
nomeados e mal protegidos, colocando toda a rede em
uma zona de alto risco. De modo geral, a rede apresentava
tantas brechas de segurança, que poderia ter
sido o alvo de enormes ataques. E esses sistemas estavam
mantendo os dados financeiros mais confidenciais da
empresa!
Pelo que Martin pôde perceber, os sistemas estavam
totalmente abertos, sem nenhum mecanismo de auditoria
ou monitoração instalado. O acesso era
bastante fácil, e as chances das tentativas serem
flagradas, quase nenhuma. Qualquer um, com um pouco
de conhecimento de segurança, poderia fazer o
que quiser nesta rede.
Charles pediu também que Martin descobrisse
de onde a mensagem de e-mail contendo a previsão
de faturamento foi originada. Sendo assim, após
testar os sistemas, Martin tentou rastrear a mensagem
de e-mail. Ele percebeu que sua tentativa seria inútil.
E foi mesmo. Ele não conseguiu chegar a lugar
nenhum, em sua tentativa de localizar o hacker.
Apesar dos Diretores Financeiros não acreditarem
que pode não ser possível rastrear uma
mensagem de e-mail, eu me surpreendi com os resultados
de Martin. É muito fácil dissimular o
envio de uma mensagem, e fazer com que um e-mail pareça
ser originado de outro remetente. Até minha irmã
Laura, de 13 anos, consegue executar essa tarefa sem
problemas.
De qualquer forma, mensagens dissimuladas não
têm nenhuma utilidade para o descobrimento de
um hacker. Ao encontrá-las, você poderá
simplesmente classificar a criatividade do hacker na
criação de nomes de domínios, e
seguir adiante, nada mais. E foi isso que Martin fez.
Ele concluiu sua auditoria e resumiu suas descobertas
em um relatório de gerenciamento. E então
se preparou para a tarefa mais árdua: entregar
o relatório à gerência. Felizmente,
estamos um pouco mais avançados do que no tempo
em que os mensageiros eram mortos por entregarem más
notícias. Porém, flechas figurativas continuam
a voar pelos ares. A entrega de um relatório
de segurança de alto risco pode gerar uma fria
reação ou um rebaixamento tão facilmente
quanto uma palavra de encorajamento. Para a sorte de
Martin, Charles era do tipo que encorajava.
Apesar de Charles apreciar o trabalho detalhado de
Martin, ele ficou totalmente chocado com suas descobertas.
Ele acreditava genuinamente que todos os sistemas na
rede estivessem protegidos. Isso era o que todos os
funcionários da gerência executiva presumiam.
Porém, a auditoria mostrou como as informações
podem ser alteradas, roubadas ou destruídas,
sem nenhuma evidência que possa rastrear o agressor.
Charles agradeceu ao Martin por revelar os fatos (desta
vez, Martin foi o herói!) e mandou imediatamente
que o nível de gerência mais alto corrigisse
os problemas.
Um ano depois: o acesso não autorizado
continua a ocorrer
No ano seguinte, houve várias outras violações
com êxito na Intranet da ISD (com êxito
para os hackers!). O único aspecto bom foi que
Charles recebeu a notícia sobre as violações
do gerente de auditoria interna da ISD e não
da CNN.
Manter as violações longe da mídia
é um dos objetivos principais da maioria dos
Diretores Financeiros, e é muito mais difícil
do que parece. Os próprios hackers atualmente
fazem questão de relatar suas violações
às agências de notícias. Eles sabem
que o dano colateral proveniente de uma propaganda negativa
é, com freqüência, pior do que o dano
causado pelo ataque em si. Em outros casos, o constrangimento
ao tornar o ataque público é, na verdade,
o objetivo do ataque. Charles se considerou com sorte,
pois pelo menos seu problema de segurança constrangedor
foi mantido, relativamente, em sigilo.
Com sorte ou não, Charles continuava em uma
má situação. Ele estava irritado
e ainda surpreso que sua rede continuasse vulnerável.
Ele não havia mandado que seus funcionários
resolvessem esse problema no ano passado? Ninguém
havia feito o que ele tinha mandado? A esta altura,
Charles estava procurando por cabeças. E não
quero dizer que ele queria aumentar o número
de cabeças na sua empresa. Charles queria essas
cabeças rolando.
Neste momento, Charles se encontrou com o diretor de
auditoria interna e com o Diretor de Informática
da empresa para discutir os riscos de segurança.
Eles decidiram que era o momento de contratar um auditor
de segurança independente. E foi aí que
eu entrei no processo.
Quando entrei na equipe, eu já tinha informações
suficientes do auditor anterior. Isso foi um bônus!
Normalmente, um auditor gasta muito tempo entrevistando
funcionários, analisando diagramas da rede e
sondando informações para descobrir quais
os sistemas que poderiam estar vulneráveis.
Eu já sabia quais os sistemas que estavam vulneráveis
no ano anterior, e esses me pareceram um bom lugar para
começar os testes por várias razões.
Primeiro, eu utilizei essa abordagem porque me permitia
compilar informações estatísticas
a partir de fatos reais. Executivos adoram estatísticas.
Gosto de qualquer dado que eu possa colocar em um gráfico
ou planilha , pois sei que a transferência de
informações para gerentes executivos neste
formato é sempre bem-vinda.
A maioria dos executivos com os quais eu trabalho são
muito inteligentes. Mas eles
também recebem tantas informações
diariamente, que necessitam e esperam informações
precisas e de fácil compreensão, que atinjam
seus objetivos em uma página ou menos. Para isso,
o relatório de resumo executivo precisa fazer
sentido em uma só olhada. Apesar disso, eu mesma
já recebi relatórios de auditoria que
me confundiram mais do que esclareceram. A apresentação
de um relatório mal escrito ou estruturado a
um executivo de alto nível gerencial é
não só inútil, como também
um desperdício de todo o trabalho gasto na produção
da auditoria. E como a aprovação de fundos
e a abordagem de riscos normalmente andam juntas, é
imprescindível que os executivos de alto nível
entendam os riscos e as possíveis conseqüências.
Por essa razão, os relatórios da gerência
executiva precisam ser curtos (de preferência
uma página e nunca mais do que duas), fáceis
de serem lidos e entendidos.
Seria fácil para mim transferir os resultados
dessa auditoria à gerência. Eu pude visualizar
o gráfico antes mesmo que eu começasse
a auditoria. Eu corresponderia as vulnerabilidades do
ano passado com as porcentagens encontradas este ano.
Isso seria ótimo! Armazenei essas informações
na minha memória e comecei minha auditoria.
Comecei lendo o relatório de auditoria contendo
as descobertas de Martin de um ano atrás. Foi
muito difícil para mim ler o relatório.
Todos os riscos foram relatados, mas de uma maneira
muito técnica e sem fluência lógica.
Se a gerência recebesse um relatório como
esse, certamente não saberia por onde começar.
Eu levei muito mais tempo do que o planejado para conseguir
as verdadeiras informações do relatório.
Após quebrar a cabeça com o relatório
de Martin, eu pude ter uma idéia de onde estavam
os sistemas de alto risco na rede financeira da empresa.
Primeiro eu sondei esses sistemas à busca de
informações.Em seguida, eu utilizei o
mapa de senhas e comecei a executar o Crack nas senhas.
Eu gosto de tentar descobrir as senhas logo no começo
da auditoria para ver quantas eu consigo revelar logo
no início. Esse mapa de senhas era bastante extenso,
520 usuários. Com certeza eu conseguiria adivinhar
ao menos algumas senhas. E foi o que aconteceu. A verificação
do arquivo crack.out me mostrou que 10 senhas foram
reveladas logo no início. Consegui acertar todas
essas. Deixando os resultados adicionais do Crack para
depois, concentrei minha auditoria nos sistemas de alto
risco.
O administrador do sistema me concedeu acesso a todos
os sistemas. Ao executar uma auditoria, prefiro fazer
o login em um sistema para testar a segurança
do que entrar direto na rede. Quando comecei a fazer
auditorias, adorava tentar entrar direto na rede primeiro
(um teste de penetração), pois era excitante
e me ajudava a aprimorar minha habilidade de violação.
À medida que me tornei mais profissional em minhas
auditorias, descobri que podia cobrir mais dados de
uma maneira mais rápida e efetiva, se solicitasse
ao proprietário do sistema que me concedesse
uma conta de login. Assim, eu poderia entrar no sistema
para verificar a presença de vulnerabilidades
de segurança. Sendo assim, algumas vezes nem
executo um teste de penetração. Primeiramente,
sondo o sistema à procura de informações
da Rede (só para ver o volume de informações
que posso obter). Em seguida, faço o teste de
senhas inválidas. Depois disso, faço o
login e testo as vulnerabilidades e erros de configuração.
O teste de auditoria final é um teste de penetração
do exterior (somente quando necessário).
Não acredito que um teste de penetração
seja sempre necessário. Por exemplo, considere
um sistema que possui uma versão antiga do Sendmail.
É um fato conhecido que tal sistema pode ser
violado. Para que desperdiçar tempo provando
que a água é molhada?
Em alguns casos, eu faço um teste de penetração
em sistemas conhecidos como vulneráveis, só
para provar um conceito à gerência. Em
outros casos, não é necessário
provar nenhum conceito. Tudo depende da extensão
da auditoria, das prioridades do cliente e das expectativas
da gerência.
Nesta auditoria, o teste de penetração,
claramente, não era necessário. A gerência
estava ciente de que a rede poderia ser violada (eu
estava presente porque os hackers também sabiam
disso!). O grande problema desta auditoria era saber
porquê a rede ainda
permanecia vulnerável. Sabendo disso, decidi
desistir do teste de penetração e seguir
adiante.
Prossegui verificando o sistema financeiro mais importante.
Ele estava muito aberto e
não tinha nenhum patch de segurança. Comecei
por explorar um velho vírus de segurança.
Foi fácil perceber que esses sistemas eram instalados
diretamente da caixa. Estava claro que nenhuma segurança
adicional havia sido configurada. Testei um segundo
sistema, depois um terceiro e então um quarto.
O mesmo ocorreu. Pelo que pude perceber, nada tinha
sido alterado desde que a última auditoria de
segurança foi executada. Aparentemente, os funcionários
da linha de frente não
haviam corrigido os problemas.
A pergunta de $64.000 dólares era, obviamente,
por que não? É
óbvio que os problemas de segurança na
ISD deveriam ter sido resolvidos. A gerência também
não deu ouvidos à mensagem de Charles
ou decidiu não ouvir.
A resposta parece ser que, quando Charles mandou que
seus funcionários “Corrigissem os problemas
de segurança agora”, ele considerou o problema
resolvido. Ele nunca verificou se sua ordem foi realmente
executada. Por alguma razão, os problemas não
foram corrigidos e Charles não obteve os resultados
que desejava.
E, por falar em resultados, nesse momento percebi que
continuava a executar o Crack. Tentando imaginar quantas
senhas o Crack tinha conseguido revelar, verifiquei
o arquivo crack.out novamente. Incrível! Mais
cem senhas tinham sido reveladas. E o pior era que o
Crack ainda não havia terminado! Ele ainda estava
insistindo em tentar adivinhar senhas. Estava claro
que os usuários nunca foram orientados sobre
como selecionar senhas fortes. Estava igualmente claro
que o administrador do sistema nunca verificou a presença
de senhas não-apropriadas.
É muito frustrante quando os administradores
de sistema não treinam seus usuários.
Com muita freqüência, os sistemas são
instalados e contas atribuídas aos usuários
sem que estes sejam orientados sobre a importância
da seleção e manutenção
das senhas. É bastante comum também que
os administradores de sistemas não testem as
senhas. Às vezes, eles realmente não têm
tempo. Porém, com muita freqüência,
eles simplesmente não sabem como fazê-lo
e não se sentem à vontade para perguntar.
Além disso, senhas não-apropriadas já
tinham sido apontadas como um problema no relatório
de auditoria do ano anterior. E, diferentemente de alguns
dos outros problemas relatados, as senhas não-apropriadas
poderiam ter sido corrigidas com um esforço muito
pequeno. Acredito que ninguém se sentiu responsável
por essa tarefa.
Foi mesmo uma pena que o relatório da auditoria
do ano anterior não especificou quantas senhas
não-apropriadas foram encontradas. Foi difícil
de acreditar que poderia ter sido pior do que o resultado
deste ano. No final da execução do Crack,
190 senhas foram reveladas em um sistema com apenas
520 usuários. Quase a metade dos usuários
estava utilizando uma senha inválida. Desta forma,
a utilização de senhas me parece inútil.
Por que não divulgar as senhas em uma estação
de rádio nacional, como um lembrete a todos os
funcionários que esquecerem seus nomes ou datas
de nascimento?
Como foi revelado posteriormente, as senhas inválidas
foram somente uma gota no oceano do problema de segurança
que a ISD enfrentava. Os problemas principais pareciam
se concentrar em somente uma área: riscos de
segurança induzidos pelo homem. Para chegar à
raiz desses problemas, comecei a entrevistar os funcionários.
Para tentar descobrir as falhas na comunicação,
comecei do nível mais alto da gerência
para baixo. Neste processo, fiz algumas descobertas
interessantes:
- A equipe de gerência executiva nunca
solicitou ou recebeu um relatório sobre o status
de quaisquer alterações feitas para aprimorar
a segurança da rede;
- Os gerentes executivos simplesmente presumiram
que os problemas de segurança seriam corrigidos,
uma vez que eles solicitaram a sua correção;
- O departamento de administração
do sistema tinha menos funcionários do que o
necessário e não tinham tempo para corrigir
os sistemas;
- Os administradores de sistema estavam trabalhando
horas extras só para instalar novos usuários
e manter os sistemas da empresa on-line. Mesmo que eles
desejassem resolver os problemas, eles nunca conseguiram
encontrar o tempo para fazê-lo;
- Os administradores de sistema também
não sabiam como corrigir os problemas de segurança.
Eles pediram ajuda à gerência, mas não
havia fundos disponíveis para esse tipo de treinamento.
Portanto, a solicitação foi adiada para
consideração posterior;
- Os gerentes de linha também solicitaram
a contratação de funcionários adicionais,
para garantir a segurança da rede. É claro
que para isso também não havia fundos.
Novamente, a ação final foi adiada para
consideração posterior.
Um ano depois, a contratação de novos
funcionários ainda não tinha sido aprovada.
Enquanto isso, os gerentes de linha adiaram o conserto
dos problemas de segurança até que as
novas contratações fossem aprovadas. Resultado:
ninguém tomou nenhuma atitude a não ser
esperar.
É incrível o volume de informações
que se pode obter ao entrevistar os funcionários.
A pior parte dessa história é que os gerentes
de linha sabiam que seus sistemas
continuavam inseguros. Porém, os gerentes superiores
permaneciam sem saber de nada. Isso ocorreu porque os
gerentes superiores não pediram que ninguém
relatasse a resolução do problema. Os
gerentes de linha sabiam que a resolução
não aconteceria em breve, porém não
tomaram a iniciativa de relatar o problema. Como resultado,
os gerentes superiores permaneceram sem saber de nada.
Eles realmente pensaram ter resolvido o problema e não
se preocuparam mais com o assunto.
O que ocorreu neste caso não é totalmente
raro. Como várias outras empresas, a ISD estava
sendo reduzida. Portanto, solicitações
de contratações eram recusadas diariamente.
Os gerentes de linha talvez não soubessem ao
certo porquê esse tipo
de contratação era absolutamente necessária.
Ou talvez era apenas uma solicitação no
meio de tantas outras. Como você já deve
saber, quando há rivalidade interna para a obtenção
de posições limitadas, toda solicitação
de contratação se torna extremamente indispensável.
É possível também que os gerentes
de linha que solicitavam tais contratações
tinham suas razões claras, mas essas razões
se tornaram confusas depois de passar pelos quatro níveis
de gerência entre o gerente que as solicitou e
o executivo que autorizou a aprovação
de fundos. Sem dúvidas a solicitação
de fundos teria sido aprovada se o Diretor de Informática
tivesse recebido diretamente uma solicitação
que dissesse algo como “Esta aprovação
é necessária para corrigir vulnerabilidades
de segurança, porque toda a rede da empresa está
correndo riscos. Até que este cargo seja preenchido,
os dados poderão ser roubados, modificados e
destruídos.”
Resumo: seja dinâmico na sua abordagem
Como a rede financeira de uma empresa da Fortune 500
pode ser tão vulnerável a ataques? Gerenciamento
precário, falta de treinamento, comunicação
insatisfatória e uma complicada estrutura de
relatórios (excesso de níveis de gerência).
Apesar dos executivos da Sra. Smith especificarem a
importância da segurança, eles nunca tomaram
nenhuma atitude efetiva para garantir a existência
dessa segurança. Mandar que seus funcionários
“corrijam os problemas” não
é suficiente. Os gerentes devem manter uma atitude
ativa com relação à segurança.
No mínimo, os gerentes devem solicitar uma prova
clara, por escrito, que identifique a correção
dos problemas de segurança. Nesse caso, tal relatório
mostraria à gerência que os problemas de
segurança não foram resolvidos, pois os
fundos necessários não foram aprovados
para a contratação de funcionários
adicionais.
Em vários casos, a segurança depende
da aprovação de fundos. A importância
dos dados que você está tentando proteger
normalmente determina o valor do investimento necessário
para protegê-los. Com freqüência, os
sistemas permanecem em risco por todo o ano, simplesmente
porque ninguém pensa em fazer um orçamento
de segurança, até que uma violação
ocorra.
Neste caso, a Sra. Smith teve muita sorte. Os dados
da empresa poderiam ter sido destruídos e os
sistemas desativados por vários dias. A Sra.
Smith teve sorte também que a violação
não foi divulgada publicamente. Esta não
é o tipo de cobertura da mídia que os
Diretores Executivos desejam receber na CNN. As conseqüências
de uma publicidade negativa podem ofuscar os danos causados
pela violação em si.
Com freqüência recebo convites para falar
a executivos sobre a segurança na Internet e
Intranet. Quando o faço, quase sempre discuto
o caso da ISD. Me pego repetindo sempre: “Sim,
isso aconteceu de verdade. E provavelmente acontecerá
novamente.” Para tentar passar essa mensagem,
eu também reforço: “A ISD era uma
empresa com um faturamento de um bilhão de dólares
anuais. Se aconteceu com essa empresa, por que você
presume que a sua rede está imune? Você
conhece a situação da segurança
na sua rede? Quando foi a última vez que você
recebeu um relatório de segurança de nível
executivo?” A essa altura, a maioria da platéia
começa a suar.
Para a sua própria tranqüilidade, tente
evitar esses tipos de problemas depois do fato. Pelo
contrário, mantenha uma atitude dinâmica
com relação à segurança.
Em Breve, na Parte II
No próximo mês, Linda McCarthy discutirá
como um problema pode se tornar fora de controle, quando
uma empresa cria um falso compromisso com a segurança.
A ISD teve sorte — desta vez. Mas não aposte
o futuro da sua empresa na sorte. Descubra o que a ISD
deveria ter feito para evitar tudo isso.
Sobre a autora
Linda McCarthy é Consultora de Segurança
Executiva, do Escritório da Direção
de Tecnologia para a Symantec. Ela foi anteriormente
vice-presidente da Engenharia de Sistemas na Recourse
Technologies. Ela trabalhou também como vice-presidente
e diretora de conhecimentos da NETSEC, e foi a fundadora
e presidente da Network Defense e Gerente da Security
R&D na Sun Microsystems. Como consultora, ela já
violou milhares de redes corporativas, para demonstrar
a facilidade com que intrusos podem interromper as operações
de uma empresa.
Links Relacionados:
|
