As duas faces dos riscos de software

riscos do software

muitas das vezes quando me perguntam o que faço respondo que “apoio as Organizações a conhecerem, entenderem e gerirem os riscos relacionados com as Tecnologias de Informação ”.

De entre todas estas palavras, “ Risco ” é sem dúvida aquela que mais se destaca levando a que maior parte das vezes a minha função seja associada a um “Arauto da desgraça”.

Ameaças, vulnerabilidades, ataques, bloqueios, ou não-conformidades são algumas das palavras que surgem quando se começa a falar de Riscos de TI, motivo pelo qual tenho sempre de lançar sempre a "palavra-joker" no início de qualquer conversa: oportunidade!

A definição de risco deve sempre ter em consideração um equilíbrio entre as ameaças e as oportunidades para que a gestão de risco possa contribuir de forma equilibrada para a proteção dos ativos e para a criação de valor .

Recentemente a ISACA lançou o guia profissional “ COBIT 5 for Risk ”, tendo identificado alguns exemplos de cenários de riscos relacionados com as tecnologias de informação que poderão ser utilizados por profissionais de todo o mundo nas suas tarefas relacionadas com o sistema de informação .

Uma das principais novidades foi precisamente a identificação de exemplos de cenários risco escritos pela positiva e pela negativa, sendo possível em qualquer dos casos identificar uma probabilidade de ocorrência e um impacto para suportar uma adequada gestão de risco .

Aqui ficam os exemplos de cenários de risco para a categoria de Software:

#	Exemplo de cenário pela negativa	Exemplo de cenário pela positiva
1	Incapacidade do software entregar os resultados desejados (desalinhamento com o modelo de negócio exigido ou mudanças organizacionais ).	O software utilizado estimula o geração de novas ideias.
2	Imaturidade do software (“early adopters”, erros, etc).
3	O software errado é escolhido para implementação ( custo , desempenho, recursos, compatibilidade, etc).	São realizadas análises e desenhados “ business case s ” para garantir a seleção adequada de software.
4	Existem falhas operacionais quando um novo software é operacionalizado .	Existe formação dos usuários e são realizados testes antes da decisão da passagem a produção para garantir uma transição suave do novo software e a continuidade do negócio .
5	Os usuários não conseguem usar e explorar as novas funcionalidades do software.
6	As modificações intencionais no software levam a dados errados ou ações fraudulentas.	O princípio dos “4 olhos” é utilizado em situações concretas de introdução/modificação de dados para assegurar a avaliação pelos pares e diminuir o estímulo para ações fraudulentas ou simplesmente a ocorrência de resultados inesperados.
7	As modificações não-intencionais no software levam a resultados inesperados.
8	Ocorrência de erros relacionados com o gerenciamento de configurações ou alterações.	O gerenciamento de configuração diminui o tempo de resolução de incidentes e o gerenciamento de problemas .
9	Mal funcionamento de software aplicativo crítico.	São realizados testes antes da decisão de “go-live” para garantir a disponibilidade e bom funcionamento do software.
10	Problemas recorrentes em software de sistema.
11	O software aplicativo é obsoleto (ex. tecnologia antiga , má documentação , manutenção dispendiosa , escalabilidade reduzida, pouca interoperabilidade)	As tecnologias de informação são um fator de inovação , garantindo uma interação entre as áreas de negócio e TI.
12	Incapacidade de regressar a versões anteriores em caso de problemas operacionais com as novas versões.	São definidas cópias de segurança e pontos de restauro de acordo com a importância do software para o negócio para garantir procedimentos de reversão.

Num mundo em que a mudança é cada vez mais a palavra de ordem, ter a capacidade de gerir adequadamente os riscos de uma Organizaçã o é um dos principais fatores críticos de sucesso para a criação de valor.

Neste sentido, importa que criar as condições favoráveis para que as funções de risco sejam vistas como parceiras dos negócios, tendo sempre em mente que a cada probabilidade de ocorrência de um evento de perda existe uma probabilidade inversa de evento de ganho.

Espero ter ajudado!

Bruno Horta Soares, CISA®, CGEIT®, CRISC™, PMP®

"The more you know, the less you no!"

Para enviar as suas questões, dúvidas ou comentários para o "Consultório PortalGSTI" deverá utilizar o email: consultorio@portalgsti.com.br

Referências: "COBIT 5 for Risk"

Continue estudando gestão de riscos no Portal GSTI:

• 12 fatores de riscos da cloud computing
• Ebook sobre a ISO 27005 e gestão de riscos de TI
• Os Riscos as-a-Service da cloud computing!
• 08 erros comuns em gerenciamento de riscos