QUAL O VALOR DA CERTIFICAÇÃO PROFISSIONAL NO BRASIL..??

Total de visualizações de página

CERTIFICADO ISO 27002 - SEGURANÇA DA INFORMAÇÃO - EXIN - 2013 - CERTIFICADO ITIL 2011 FOUNDATION

CERTIFICADO ISO 27002 - SEGURANÇA DA INFORMAÇÃO - EXIN - 2013 - CERTIFICADO ITIL 2011 FOUNDATION

COBIT 5

COBIT 5
Powered By Blogger

CONTATOS REFERENTES A TRABALHOS DE AUDITORIA E CONSULTORIA

CERTIFICAÇÕES PROFISSIONAIS:
ISO 27002 - Segurança da Informação - 2013;
ITIL 2011 Foundation - 2014;
Formação COBIT4.1 - Redes Sociais -

Serviços Prestados:
Auditoria na Área de Informática - Auditoria do ambiente de tecnologia da informação

Consultorias de Apoio a Criação de Políticas e Procedimentos Referentes ao Uso das Redes Sociais ;

Consultoria em Gestão de Relacionamentos para TI ;

Consultoria de Apoio a Formação de Comitês de Gestão da TI;

Alinhamento estratégico TI x Rumos do Negócio ;

Contatos:
51- 92022717
51- 33429388

crmaia7@gmail.com - Email





Postagens mais lidas no BLOG

Pesquisar este blog

logo da Consultoria - MAIA - TI

logo da Consultoria - MAIA - TI
copie e cole para ver no tamanho ideal

quarta-feira, 21 de setembro de 2011

Segurança da Informação ISO 27000

É essencial que os gestores da sua empresa estejam conscientes da necessidade de haver uma harmonização entre os fatores: Gestão de Risco, Gestão do Tratamento do Risco, Gestão da Continuidade do Negócio e Gestão de um sistema completo de Segurança da Informação, antes da decisão de compra de serviços de consultoria ou mesmo de software de implementação de segurança da informação ou continuidade do negócio.

Partindo-se do princípio de que Gestão de Risco é o primeiro passo para a compreensão dos elementos de risco envolvidos no seu negócio específico e conseqüente habilidade de determinar as prioridades de forma sistemática, qual não é a nossa surpresa ao perceber que existem empresas comprando proteção para um pequeno pedaço do processo, sem antes analisar o todo, e ter em conta suas mudanças constantes, no dia a dia.
Gestão do Sistema de Segurança da Informação (conforme as melhores práticas da Norma ISO 27001:2005) é uma gestão completa de todos os fatores envolvidos na proteção da informação determinada pela empresa. Não é prudente implementar um sistema de Plano de Continuidade do Negócio, por exemplo, sem que tenha sido feita uma análise de riscos, onde cada ativo da informação foi analisado em termos da sua importância, consideradas a Confidencialidade, Integridade e Disponibilidade desejadas pelos gestores. A análise dos riscos inerentes aos processos que se deseja proteger é o passo número 1. Não existe coerência em “adivinhar” hoje o que tem que ser protegido, e em seguida notar, amanhã, que aquilo que estamos gastando tempo e dinheiro protegendo tornou-se informação pública há um ano atrás.
A Gestão de Riscos é viva dentro da Gestão de Problemas, Gestão de Incidentes e Gestão de Mudanças, que trabalham juntas para inserir, de forma consistente com a Análise de Risco, ações corretivas, preventivas, ou simplesmente mudanças de configuração em qualquer das áreas afetadas por uma variação de qualquer tipo, incluindo fatores de recursos humanos, de terceirizados (outsourcing), ou outros fatores administrativos que mudam os aspectos de risco, mesmo vindo de fora da área de TI (Tecnologia da Informação).
Sem o primeiro passo – Gestão de Risco, com objetivos e metas para cada controle - não se tem visibilidade se o risco está aumentando ou diminuindo de tamanho com o uso do controle. Deve-se, por exemplo, estabelecer objetivos e metas de segurança - por exemplo - metas no número de incidentes por mês, ou por ano. Se não houver meta para isso, como saberemos se estamos melhorando em nível de gestão de incidentes?
Existe hoje software que faz esta gestão para o usuário, com gráficos e relatórios de gestão de objetivos para controles de tratamento de risco.
Não existe fórmula mágica nem atalho para a criação de um Plano de Continuidade de Negócios. Nem existe tal coisa para a Gestão de Incidentes ou de Mudanças. O primeiro passo é: O que queremos proteger? Quanto vale? Como pretendemos proteger? Qual a metodologia? Qual o custo? Tendo estas perguntas sido respondidas, deveríamos então passar a gerir este processo para medir se o que nos propusemos a fazer é de fato o que está acontecendo – e ter assim visibilidade sobre os controles, podendo mudá-los rapidamente, sempre que o retorno demonstrar que o risco residual está sendo excedido, ou mesmo que o custo está muito alto para o risco residual efetivo.
Toda longa jornada começa com um primeiro passo. Gestão de Segurança da Informação começa com a Análise de Riscos, bem feita, e sua Gestão constante em direção à melhoria contínua.
RESOLUÇÃO 3.380
Dispõe sobre a implementação de estrutura de gerenciamento do risco operacional.
O BANCO CENTRAL DO BRASIL, na forma do art. 9º da Lei 4.595, de 31 de dezembro de 1964, torna público que o CONSELHO MONETÁRIO NACIONAL, em sessão realizada em 29 de junho de 2006, com base nos arts. 4º, inciso VIII, da referida lei, 2º, inciso VI, 8º e 9º da Lei 4.728, de 14 de julho de 1965, e 20 da Lei 4.864, de 29 de novembro de 1965, na Lei 6.099, de 12 de setembro de 1974, com as alterações introduzidas pela Lei 7.132, de 26 de outubro de 1983, na Lei 10.194, de 14 de fevereiro de 2001, com as alterações introduzidas pela Lei 11.110, de 25 de abril de 2005, e no art. 6o do Decreto-lei 759, de 12 de agosto de 1969,
RESOLVEU:
Art. 1º Determinar às instituições financeiras e demais instituições autorizadas a funcionar pelo Banco Central do Brasil a implementação de estrutura de gerenciamento do risco operacional.
Parágrafo único. A estrutura de que trata o caput deve ser compatível com a natureza e a complexidade dos produtos, serviços, atividades, processos e sistemas da instituição.
Art. 2º Para os efeitos desta resolução, define-se como risco operacional a possibilidade de ocorrência de perdas resultantes de falha, deficiência ou inadequação de processos internos, pessoas e sistemas, ou de eventos externos.
§ 1º A definição de que trata o caput inclui o risco legal associado à inadequação ou deficiência em contratos firmados pela instituição, bem como a sanções em razão de descumprimento de dispositivos legais e a indenizações por danos a terceiros decorrentes das atividades desenvolvidas pela instituição.

§ 2º Entre os eventos de risco operacional, incluem-se:

I - fraudes internas;
II - fraudes externas;
III - demandas trabalhistas e segurança deficiente do local de trabalho;
IV - práticas inadequadas relativas a clientes, produtos e serviços;
V - danos a ativos físicos próprios ou em uso pela instituição;
VI - aqueles que acarretem a interrupção das atividades da instituição;
VII - falhas em sistemas de tecnologia da informação;
VIII - falhas na execução, cumprimento de prazos e gerenciamento das atividades na instituição.
Art. 3º A estrutura de gerenciamento do risco operacional deve prever: I - identificação, avaliação, monitoramento, controle e mitigação do risco operacional; II - documentação e armazenamento de informações referentes às perdas associadas ao risco operacional; III - elaboração, com periodicidade mínima anual, de relatórios que permitam a identificação e correção tempestiva das deficiências de controle e de gerenciamento do risco operacional; IV - realização, com periodicidade mínima anual, de testes de avaliação dos sistemas de controle de riscos operacionais implementados; V - elaboração e disseminação da política de gerenciamento de risco operacional ao pessoal da instituição, em seus diversos níveis, estabelecendo papéis e responsabilidades, bem como as dos prestadores de serviços terceirizados; VI - existência de plano de contingência contendo as estratégias a serem adotadas para assegurar condições de continuidade das atividades e para limitar graves perdas decorrentes de risco operacional; VII - implementação, manutenção e divulgação de processo estruturado de comunicação e informação. § 1º A política de gerenciamento do risco operacional deve ser aprovada e revisada, no mínimo anualmente, pela diretoria das instituições de que trata o art. 1º e pelo conselho de administração, se houver. § 2º Os relatórios mencionados no inciso III devem ser submetidos à diretoria das instituições de que trata o art. 1º e ao conselho de administração, se houver, que devem manifestar-se expressamente acerca das ações a serem implementadas para correção tempestiva das deficiências apontadas. § 3º Eventuais deficiências devem compor os relatórios de avaliação da qualidade e adequação do sistema de controles internos, inclusive sistemas de processamento eletrônico de dados e de gerenciamento de riscos e de descumprimento de dispositivos legais e regulamentares, que tenham, ou possam vir a ter impactos relevantes nas demonstrações contábeis ou nas operações da entidade auditada, elaborados pela auditoria independente, conforme disposto na regulamentação vigente. Art. 4o A descrição da estrutura de gerenciamento do risco operacional deve ser evidenciada em relatório de acesso público, com periodicidade mínima anual. § 1º O conselho de administração ou, na sua inexistência, a diretoria da instituição deve fazer constar do relatório descrito no caput sua responsabilidade pelas informações divulgadas. § 2º As instituições mencionadas no art. 1º devem publicar, em conjunto com as demonstrações contábeis semestrais, resumo da descrição de sua estrutura de gerenciamento do risco operacional, indicando a localização do relatório citado no caput. Art. 5º A estrutura de gerenciamento do risco operacional deve estar capacitada a identificar, avaliar, monitorar, controlar e mitigar os riscos associados a cada instituição individualmente, ao conglomerado financeiro, conforme o Plano Contábil das Instituições do Sistema Financeiro Nacional - Cosif, bem como a identificar e acompanhar os riscos associados às demais empresas integrantes do consolidado econômico-financeiro, definido na Resolução 2.723, de 31 de maio de 2000. Parágrafo único. A estrutura, prevista no caput, deve tam- bém estar capacitada a identificar e monitorar o risco operacional decorrente de serviços terceirizados relevantes para o funcionamento regular da instituição, prevendo os respectivos planos de contingên- cias, conforme art. 3º, inciso VI. Art. 6º A atividade de gerenciamento do risco operacional deve ser executada por unidade específica nas instituições mencionadas no art. 1º. Parágrafo único. A unidade a que se refere o caput deve ser segregada da unidade executora da atividade de auditoria interna, de que trata o art. 2º da Resolução 2.554, de 24 de setembro de 1998, com a redação dada pela Resolução 3.056, de 19 de dezembro de 2002. Art. 7º Com relação à estrutura de gerenciamento de risco, admite-se a constituição de uma única unidade responsável: I - pelo gerenciamento de risco operacional do conglomerado financeiro e das respectivas instituições integrantes; II - pela atividade de identificação e acompanhamento do risco operacional das empresas não financeiras integrantes do consolidado econômico-financeiro. Art. 8º As instituições mencionadas no art. 1º devem indicar diretor responsável pelo gerenciamento do risco operacional. Parágrafo único. Para fins da responsabilidade de que trata o caput, admite-se que o diretor indicado desempenhe outras funções na instituição, exceto a relativa à administração de recursos de terceiros. Art. 9º A estrutura de gerenciamento do risco operacional deverá ser implementada até 31 de dezembro de 2007, com a observância do seguinte cronograma: I - até 31 de dezembro de 2006: indicação do diretor responsável e definição da estrutura organizacional que tornará efetiva sua implementação; II - até 30 de junho de 2007: definição da política institucional, dos processos, dos procedimentos e dos sistemas necessários à sua efetiva implementação; III - até 31 de dezembro de 2007: efetiva implementação da estrutura de gerenciamento de risco operacional, incluindo os itens previstos no art. 3º, incisos III a VII. Parágrafo único. As definições mencionadas nos incisos I e II deverão ser aprovadas pela diretoria das instituições de que trata o art. 1º e pelo conselho de administração, se houver, dentro dos prazos estipulados. Art. 10. O Banco Central do Brasil poderá: I - determinar a adoção de controles adicionais, nos casos de inadequação ou insuficiência dos controles do risco operacional implementados pelas instituições mencionadas no art. 1º; II - imputar limites operacionais mais restritivos à instituição que deixar de observar, no prazo estabelecido, a determinação de que trata o inciso I. Art. 11.
Esta resolu~ção está em vigor desde 2006.

segunda-feira, 12 de setembro de 2011

Gestor de TI brasileiro resiste à nuvem pública

Uma pesquisa encomendada pela Unisys à IDC sobre o fenômeno da “Consumerização de TI” no Brasil - uso de dispositivos móveis pessoais no ambiente corporativo – aponta a percepção das organizações com relação à adoção de cloud computing. O estudo ouviu 101 executivos de TI de diversas empresas localizadas nas principais cidades do Brasil.

Quando perguntadas sobre o uso da nuvem para suprir a chegada dos dispositivos móveis ao ambiente corporativo, cerca de 2/3 das companhias entrevistadas no Brasil afirmaram considerar este ambiente, em linha com as respostas obtidas em todos os países pesquisados. O Brasil se destaca pela pouca adesão às nuvens públicas, com apenas 8% contra 17% nos demais países.

A pesquisa ainda mostra que as organizações já prepararam ou estão preparando seus data centers para atender as novas demandas. No Brasil, cerca de 70% das companhias consultadas disseram que estão investindo em virtualização, consolidação e/ou estandardização de seus data centers, relativamente em linha com a média dos demais países pesquisados. Em contrapartida, o estudo aponta uma redução na preocupação com a modernização das aplicações: apenas 46% das empresas brasileiras consultadas afirmaram ter alguma iniciativa neste sentido.

Questionadas sobre a escolha do local em que são mantidas as aplicações utilizadas pelos dispositivos móveis – se permanecem no próprio dispositivo ou em ambiente centralizado (On-line / Cloud Computing) – as empresas brasileiras entrevistadas afirmam que consideram mais confiáveis as nuvens: 53% classificaram essa alternativa como importante ou criticamente importante, enquanto a média considerando os outros países pesquisados é de apenas 34%.

“A sensibilidade em relação à vulnerabilidade das aplicações residentes nos dispositivos remotos, a predisposição à serviços de computação em nuvem e o pouco avanço feito na modernização de aplicações mostram um caminho interessante a ser seguido pelos executivos brasileiros”, afirma Paulo Roberto Carvalho, diretor de negócios de outsourcing da Unisys Brasil. “Aspectos como a virtualização de desktops e serviços semelhantes devem entrar rapidamente na agenda destes profissionais”, completa.

terça-feira, 6 de setembro de 2011

Cinco remédios para os males que afligem o departamento de TI

Seu departamento de TI pode ter os funcionários mais brilhantes e ambiciosos. Os melhores. Mas isso não garante que o grupo será eficiente.
Como na maioria dos departamentos, há muitas causas para a ineficiência. E sintomáticas. O grupo de TI deve estar preparado para ajustar forças que, por vezes, estão fora do seu controle. As mudanças no modelo de negócios aumentaram a pressão sobre os CIOs, que já não podem mais errar na seleção de fornecedores ou terem dificuldades de entender o significado de ROI.
"A cada falha, é fácil detectar uma infinidade de causas potenciais", diz John Baschab, VP sênior de serviços de gestão da Technisource.
As quatro principais razões para a ineficiência da TI, diz Baschab, são: (1) turbulências na área de negócios da empresa, como a necessidade de rápido crescimento da receita ou uma fusão forçando uma maior demanda por TI; (2) seleção equivocada e uma fraca gestão dos fornecedores; (3) inexperiência de gestão ou uma gestão que afaste a equipe de TI das áreas de negócio; (4) e orçamento reduzido ou um gestor financeiro que não compreenda perfeitamente a relação custo/benefício da área.
Mas há bons remédios para cada uma delas. Baschab aponta cinco deles.
Melhorar a Gestão de TI
Um passo na melhoria da gestão de TI é formar um comitê diretivo de TI que atue como ponte entre os mundos de TI e as áreas de negócios. Este comitê seria composto normalmente por executivos internos com interesse em TI que também tenham influência dentro da empresa para promover mudanças necessárias.
"Na maioria das vezes o comitê é composto pelo presidente e seus subordinados diretos", diz Baschab, "mas também pode incluir outros líderes influentes dentro da empresa."
O comitê diretivo de TI deve servir como um CIO virtual" assessorando o CIO e resolvendo rapidamente os problemas entre as áreas de negócio e a TI. O comitê deve também ser responsável pela contratação do pessoal de gestão de TI, certificando-se de que os gerente sejam realmente gestores responsáveis por sua áreas não apenas um programador sênior, diz Baschab.
"Promover uma limpeza no organograma de TI é a melhor forma para começar", acrescenta. "Não deve haver caixas flutuantes e linhas pouco definidas de responsabilidade."
Ter disciplina no gerenciamento de projetos
CIOs precisam listar todos os projetos futuros, determinar claramente o ROI de cada projeto e em seguida priorizar todos os projetos por seu benefício para as áreas de negócios, diz Baschab.
É responsabilidade dos líderes de TI conhecer a real capacidade do departamento de TI e limitar o número de projetos abertos. "Não espere que a quantidade de projetos seja menor do que você quer, diz Baschab, mas "tenha certeza de que os projetos necessários serão realmente executados no tempo e dentro do orçamento previstos."
Gerenciar melhor os fornecedores
A receita para manter seus fornecedores na linha, diz Baschab, é insistir em contratos favoráveis e gerir agressivamente as relações após a compra feita.
Mais especificamente, você deve "determinar que os fornecedores entreguem o combinado e não minem os orçamentos de TI com taxas e prazos improdutivos e inflados", diz Baschab, que acrescenta que os gerentes de TI e CIOs não devem hesitar em abrir mão de fornecedores ruins, trocando-os por fornecedores melhores.
Ao negociar com um fornecedor, a TI deve exigir o melhor preço ou ameaçar abrir uma nova RFP (Request For Proposal). Também devem procurar se certificarem de como os fornecedores medem a satisfação do cliente.
"Experimente exigir um relatório de cada fornecedor, a cada trimestre, e mantê-los dentro de um padrão de entrega pré-definido", diz Baschab.
Melhorar a Gestão Fiscal e Orçamento
Cada líder de TI precisa ser capaz de explicar à diretoria qualquer irregularidade no orçamento, e ter uma compreensão clara da relação custos versus receitas.
"Os CIOs devem reconhecer que a maioria das empresas deve gerar 10 Reais em receita para cobrir cada Real gasto em TI", diz Baschab. E se esforçarem para serem vistos como executivos que zelam pela saúde financeira da empresa.
"Os CIOs devem se tornar um parceiro da equipe de gerência sênior, sugerindo formas de redução de custo global da empresa através do uso de TI", diz Baschab.
Promover a paz entre usuários de negócios e de TI
Um CIO deve fazer o possível para reduzir acusações entre os departamentos, diz Baschab. Membros do departamento de TI precisam caminhar lado a lado com os usuários de negócios e colaborar com eles regularmente. Se você não se envolver com os usuários de negócios, você não deve ser promovido, diz Baschab.
"A qualidade do relacionamento com os usuários de negócios deve ser parte do processo de avaliação e promoção para todos os membros da equipe de TI", diz ele.
By CIO Digital - setembro de 2011

terça-feira, 30 de agosto de 2011

Como aumentar a colaboração no departamento de TI

O conceito DevOps (desenvolvimento + operações) pode ser o caminho para que as duas áreas trabalhem juntas, de forma eficiente e harmônica.
Já faz algum tempo que o gerentes de TI lamentam a tensão entre as equipes encarregadas de mudar o negócio (desenvolvimento) e aquelas responsáveis por mantê-lo funcionando (operações). Na verdade, a maioria das organizações sofre essa maldição, e os estereótipos que refletem essa animosidade não são poucos.
Equipes operacionais, por exemplo, enxergam os integrantes da equipe de desenvolvimento como pessoas sentadas em suas torres de marfim produzindo código de todos os dias, criando aplicativos sem considerar as restrições do mundo real. Por outro lado, desenvolvedores veem o pessoal de operação como mantenedores da infraestrutura, responsáveis por mantê-la sempre disponível, sempre a postos para impedir que ela seja afetada por código mal escrito.
Esses estereótipos existem porque os comportamentos organizacionais, com uma área sempre pronta a culpar a outra pelas falhas, acirrar conflitos. As duas partes devem agir rapidamente para mudar.
O conceito de DevOps (desenvolvimento + operações) tem sido apontado por muitos como a maneira das duas áreas passarem a trabalhar juntas, de forma eficiente e harmônica, para beneficiar o negócio. Mais especificamente, a Forrester define DevOps como um conjunto de processos, métodos e sistemas de comunicação, integração e colaboração entre as funções de TI responsáveis pelo desenvolvimento das aplicações, infraestrutura e operações. Faz parte do trabalho de devs e ops estarem alinhados e colaborarem um com o outro.
Líderes de TI podem começar a construir uma relação mais próxima entre aqueles que criam o software e os que mantêm tudo funcionando, em produção, considerando as seguintes ações:
1. Alterar a gestão de mudança
A reputação do pessoal de operação é a de resistir às mudanças, porque todo mundo – pessoal operacional, desenvolvedores, e os próprios clientes - passou a acreditar que a mudança é ruim. Falhas de serviço são frequentemente atribuídas a mudanças, por isso, se poucas são executadas, menos falhas ocorrerão. Esta associação ridícula apenas nos diz que o nosso processo de gestão de mudança é falho, muitas vezes profundamente.
Da mesma forma que conseguimos conciliar objetivos aparentemente contraditórios, como disciplina e velocidade, os profissionais de desenvolvimento deverão olhar os de operações como parceiros, não como um obstáculo irritante. O pessoal operacional da área de gestão de mudanças permite garantir que o processo está sendo executado de forma consistente. Todas as alterações realizadas fora do processo devem ser identificadas e corrigidas imediatamente.
2. Aumentar a comunicação entre as áreas, para que o grupo de desenvolvimento conheça melhor a área de operações
Para melhorar a compreensão, reduzir o preconceito e melhorar a percepção, as equipes de TI precisam melhorar a comunicação. O objetivo é adaptar as práticas de trabalho para garantir uma maior colaboração entre as áreas em novas iniciativas de TI. Essa colaboração não só ajuda a maximizar ganhos, como também a melhorar a qualidade das soluções de TI.
3. Educar os desenvolvedores de aplicações sobre a evolução de I&O orientada a serviço
Líderes de TI devem estender a ITIL ao gerenciamento de serviços. Com a introdução da ITILv3, em 2007, o quadro já não é mais centrado na operação. Ela explica todas as fases do ciclo de vida de serviços, incluindo aqueles relacionados com a área de desenvolvimento. É preciso educar os profissionais de desenvolvimento e operações a identificarem como ferramentas de automação de serviços podem colaborar para a implantação dos processos de TI e usá-las. A abordagem certa dele levar o pessoal de desenvolvimento a desejar ter um papel em ITIL e não se sentirem forçados a isso.
4. Considere o desenvolvimento de aplicações como serviço
A declaração pode soar chocante e provavelmente ofensiva para alguns desenvolvedores, mas o desenvolvimento de aplicações é, em última análise, um subcomponente do serviço geral de TI. O líder de TI deve trabalhar para reposicionar o até então isolado grupo de desenvolvedores dando a eles um papel mais central, de parceiros do pessoal de infraestrutura e operações na prestação de serviços relevantes para clientes comuns.
5. Compreender e gerir a diversidade de opiniões sobre a entrega de serviços
Existem razões pelas quais alguns de nós gostam de trabalhar em desenvolvimento e por que os outros odeiam programação. No entanto, essa não é uma desculpa para não trabalhar juntos para o bem do negócio. A liderança de TI precisa assegurar que haja um melhor mix de habilidades e tipos de personalidade nos grupos funcionais de TI. A revisão dos processos de gestão de pessoas deve ser feita em conjunto com o RH. Isto irá identificar problemas e lacunas nos conhecimentos e habilidades do pessoal de TI.
6. Integrar TI às áreas de negócio
Pare de repetir o mantra de alinhamento das áreas de TI e negócios e trabalhar para tornar-se de fato um facilitador de um parceiro de valor estratégico. A TI não deve estar alinhada ao negócio, simplesmente porque a TI é o negócio! As equipes de TI precisam entender como o seu trabalho está em sintonia com os objetivos mais amplos do negócio. Ter uma equipe eficaz, que compreenda isso, é essencial para posicionar a área de TI como um grupo que pode aumentar a vantagem competitiva da empresa por meio da tecnologia e da inovação.
By Computerworld

sexta-feira, 26 de agosto de 2011

Governo define que computação em nuvem e uso de redes sociais terão normas de Segurança da Informação

Formalmente instalado na semana passada, o Comitê Gestor de Segurança da Informação vai começar um trabalho de revisão e elaboração de novas normas a serem adotadas em toda a administração pública federal. Há sete temas prioritários, entre eles computação em nuvem, uso de redes sociais e mobilidade.

Na prática, é uma continuação do trabalho que já vem sendo desenvolvido pelo Departamento de Segurança da Informação e Comunicações (DSIC), ligado ao Gabinete de Segurança Institucional da Presidência da República. O comitê gestor, no entanto, é mais amplo, formado por 16 órgãos da administração federal.

Esses órgãos devem, agora, indicar representantes que vão participar dos grupos específicos para a discussão dos sete temas elencados como mais importantes, com o objetivo de que novas normas de segurança sejam elaboradas até o fim do ano.

Além dos já mencionados – computação em nuvem, redes sociais e mobilidade –, os pontos se referem ao tratamento das informações, gestão de mudanças, verificação de conformidade, controle de ativos de informação e revisão das normas existentes.

Em alguns casos, devem ser adotadas medidas para generalizar para todos os órgãos, inclusive estatais, medidas que já são de alguma forma aplicadas na administração direta – como as normas da Secretaria de Logística e TI sobre continuidade e, consequentemente, o controle da gestão das políticas de tecnologia da informação.

Outros pontos, como a computação em nuvem, devem ganhar maior discussão. Afinal, nesse caso há um projeto em andamento de elaboração de uma política pública para a nuvem – que passa inclusive pela implementação de uma nuvem privativa da administração pública.

Até aqui, no entanto, ainda não avançou a discussão da proposta de criação de uma rede nacional de excelência de segurança da informação e criptografia, que pretende integrar pesquisas em universidades, institutos e centros de pesquisa, órgãos governamentais e empresas.
By Convergência Digital Agosto 2011

segunda-feira, 22 de agosto de 2011

Como aumentar a colaboração no departamento de TI

O conceito DevOps (desenvolvimento + operações) pode ser o caminho para que as duas áreas trabalhem juntas, de forma eficiente e harmônica.
Já faz algum tempo que o gerentes de TI lamentam a tensão entre as equipes encarregadas de mudar o negócio (desenvolvimento) e aquelas responsáveis por mantê-lo funcionando (operações). Na verdade, a maioria das organizações sofre essa maldição, e os estereótipos que refletem essa animosidade não são poucos.
Equipes operacionais, por exemplo, enxergam os integrantes da equipe de desenvolvimento como pessoas sentadas em suas torres de marfim produzindo código de todos os dias, criando aplicativos sem considerar as restrições do mundo real. Por outro lado, desenvolvedores veem o pessoal de operação como mantenedores da infraestrutura, responsáveis por mantê-la sempre disponível, sempre a postos para impedir que ela seja afetada por código mal escrito.
Esses estereótipos existem porque os comportamentos organizacionais, com uma área sempre pronta a culpar a outra pelas falhas, acirrar conflitos. As duas partes devem agir rapidamente para mudar.
O conceito de DevOps (desenvolvimento + operações) tem sido apontado por muitos como a maneira das duas áreas passarem a trabalhar juntas, de forma eficiente e harmônica, para beneficiar o negócio. Mais especificamente, a Forrester define DevOps como um conjunto de processos, métodos e sistemas de comunicação, integração e colaboração entre as funções de TI responsáveis pelo desenvolvimento das aplicações, infraestrutura e operações. Faz parte do trabalho de devs e ops estarem alinhados e colaborarem um com o outro.
Líderes de TI podem começar a construir uma relação mais próxima entre aqueles que criam o software e os que mantêm tudo funcionando, em produção, considerando as seguintes ações:
1. Alterar a gestão de mudança
A reputação do pessoal de operação é a de resistir às mudanças, porque todo mundo – pessoal operacional, desenvolvedores, e os próprios clientes - passou a acreditar que a mudança é ruim. Falhas de serviço são frequentemente atribuídas a mudanças, por isso, se poucas são executadas, menos falhas ocorrerão. Esta associação ridícula apenas nos diz que o nosso processo de gestão de mudança é falho, muitas vezes profundamente.
Da mesma forma que conseguimos conciliar objetivos aparentemente contraditórios, como disciplina e velocidade, os profissionais de desenvolvimento deverão olhar os de operações como parceiros, não como um obstáculo irritante. O pessoal operacional da área de gestão de mudanças permite garantir que o processo está sendo executado de forma consistente. Todas as alterações realizadas fora do processo devem ser identificadas e corrigidas imediatamente.
2. Aumentar a comunicação entre as áreas, para que o grupo de desenvolvimento conheça melhor a área de operações
Para melhorar a compreensão, reduzir o preconceito e melhorar a percepção, as equipes de TI precisam melhorar a comunicação. O objetivo é adaptar as práticas de trabalho para garantir uma maior colaboração entre as áreas em novas iniciativas de TI. Essa colaboração não só ajuda a maximizar ganhos, como também a melhorar a qualidade das soluções de TI.
3. Educar os desenvolvedores de aplicações sobre a evolução de I&O orientada a serviço
Líderes de TI devem estender a ITIL ao gerenciamento de serviços. Com a introdução da ITILv3, em 2007, o quadro já não é mais centrado na operação. Ela explica todas as fases do ciclo de vida de serviços, incluindo aqueles relacionados com a área de desenvolvimento. É preciso educar os profissionais de desenvolvimento e operações a identificarem como ferramentas de automação de serviços podem colaborar para a implantação dos processos de TI e usá-las. A abordagem certa dele levar o pessoal de desenvolvimento a desejar ter um papel em ITIL e não se sentirem forçados a isso.
4. Considere o desenvolvimento de aplicações como serviço
A declaração pode soar chocante e provavelmente ofensiva para alguns desenvolvedores, mas o desenvolvimento de aplicações é, em última análise, um subcomponente do serviço geral de TI. O líder de TI deve trabalhar para reposicionar o até então isolado grupo de desenvolvedores dando a eles um papel mais central, de parceiros do pessoal de infraestrutura e operações na prestação de serviços relevantes para clientes comuns.
5. Compreender e gerir a diversidade de opiniões sobre a entrega de serviços
Existem razões pelas quais alguns de nós gostamos de trabalhar em desenvolvimento e por que os outros odeiam programação. No entanto, essa não é uma desculpa para não trabalhar juntos para o bem do negócio. A liderança de TI precisa assegurar que haja um melhor mix de habilidades e tipos de personalidade nos grupos funcionais de TI. A revisão dos processos de gestão de pessoas deve ser feita em conjunto com o RH. Isto irá identificar problemas e lacunas nos conhecimentos e habilidades do pessoal de TI.
6. Integrar TI às áreas de negócio
Pare de repetir o mantra de alinhamento das áreas de TI e negócios e trabalhar para tornar-se de fato um facilitador de um parceiro de valor estratégico. A TI não deve estar alinhada ao negócio, simplesmente porque a TI é o negócio! As equipes de TI precisam entender como o seu trabalho está em sintonia com os objetivos mais amplos do negócio. Ter uma equipe eficaz, que compreenda isso, é essencial para posicionar a área de TI como um grupo que pode aumentar a vantagem competitiva da empresa por meio da tecnologia e da inovação.
by CIO Digital

quinta-feira, 18 de agosto de 2011