PráticasTítulo

Inserir de Desenvolvimento
Aqui
Inserir Título
Seguro em Sistemas
Aqui
Práticas de Desenvolvimento Seguro em Sistemas

Responsável pelo Conteúdo:

Prof. Esp. Allan Piter Pressi

Revisão Textual:
Prof. Ms. Claudio Pereira do Nascimento
 Práticas de Desenvolvimento
Seguro em Sistemas

Fonte: iStock/Getty Images

Nesta unidade, trabalharemos os seguintes tópicos:
• Aprovação e Garantia de Software Seguro
• Instalação e Implantação de Software Seguro
• Aquisição de Software
• Conclusão

Objetivos
• Compreender os critérios de aceitação/acreditação de software seguro bem como
modelos de gestão de software de próprios e de terceiros.

Caro Aluno(a)!

Normalmente com a correria do dia a dia, não nos organizamos e deixamos para o
último momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Contextualização
Uma vez que o software esteja pronto ou que seja adquirido, existem questões ini-
ciais sobre como disponibilizar o software em produção, como saber se nosso software
atendeu aos requisitos do desenvolvimento e as premissas definidas.

O processo de implantação de um software é composto por diferentes diretrizes des-

de a avaliação, testes de stress, plano de suporte, plano de operação, etc.

Softwares adquiridos de terceiros, por vezes já possuem determinados processos

definidos para a sua implantação em produção, porém, mesmo que o software seja
adquirido de terceiros as avaliações e testes são fundamentais para determinar a qualidade
e segurança do produto.

6
Aprovação e Garantia de Software Seguro
A aprovação de um software é uma parte do ciclo de vida do desenvolvimento onde
deve ser verificado se o produto entregue ou disponibilizado cumpre os requisitos de
segurança, os testes e os critérios utilizados ajudam e apoiam a determinar se ele está
apto para uso em produção.

Introdução a Acreditação do Software

O propósito da fase de validação do software determina se o software adquirido ou
desenvolvido atende aos critérios determinados em contrato entre as partes envolvidas
(contratada e contratante).

O julgamento sobre a qualidade do produto entregue deve ser avaliado segundo cri-
térios de testes adequados aos segmentos ao qual esse software está sendo utilizado.

O julgamento sobre a segurança do produto deve ser avaliado segundo critérios

técnicos e testes específicos de segurança com o objetivo de garantir que os produtos
atendam aos princípios de segurança da informação.

Planejamento do Teste
O plano de teste visa garantir que o software atenda aos critérios determinados
e espelha o escopo dos requisitos solicitados, as regras de negócios definidos como
também aos critérios legais e compliance da operação onde o software será utilizado.
Dentre os pontos e os critérios que devem ser considerados no planejamento citamos
os seguintes:
• Os requisitos e características para testes;
• Requisitos de limites de testes;
• Tipo de teste de stress;
• Testes de segurança;
• Requisitos de nível de performance;
• Interfaces que serão testadas;

Para a execução de um teste pode-se utilizar de diferentes formas e estratégias, como

também pode envolver times distintos de testes em etapas e processos que podem ser
utilizados dentre os quais citamos os seguintes:
• Casos de Testes;
• Testes do tipo Caixa Preta;
• Testes do tipo Caixa Branca;
• Testes de Carregamento;

7
7
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

• Testes de Stress;
• Testes de Performance;
• Testes de Usabilidade;
• Testes de Segurança.

Esses testes podem ser executados também por ferramentas especificas assim como
outras atividades conforme itens abaixo.
• Análise de código fonte de acordo com a complexidade e aderência aos padrões de
códigos e boas práticas;
• Análise de cobertura em que podem ser testados partes do código em que podem
ser realizados teste com base em determinadas condições e cenários; (***)
• Análise de memória, avaliando a performance física do software e do hardware;
• Carga e perfomance do software;
• Testes de vulnerabilidade de aplicações que validam diversos elementos tais como:
links válidos, uso correto entre o cliente e o servidor, teste de falhas, entre outros
testes específicos.

Critérios de Testes Completos

A norma ISO 9126, é uma norma que define um conjunto de critérios que podem ser
aplicados em testes de softwares e que auxiliam na garantia de entrega de um produto
de software, entre os critérios que compõem essa norma estão:
• Funcionalidade;
• Confiabilidade;
• Usabilidade;
• Eficiência;
• Manutenção;
• Portabilidade.

Aceitação dos Riscos de Software

Devido aos números de ameaças no cyberspace e a complexidade dos produtos de
softwares, podem apresentar diferentes riscos, que devem ser gerenciados de maneira
apropriada, de forma a mitigar esses riscos e a exposição da empresa.

8
 Os critérios de aceitação de risco que devem ser observados são de responsabilidade
das empresas, e quando falamos sobre o desenvolvimento de software eles devem ser
bem criteriosos para não comprometer a organização. Os critérios que devem compor
essa avaliação são os seguintes:
• Requisitos de segurança internos e externos: Validações de Dados, acesso, geren-
ciamento de memórias, exceções, etc.;
• Grau de complexidade do produto: Sistema de Cadastro simples, comércio eletrô-
nico, solução fiscal, financeiro, etc.;
• Fatores de performance: Gerenciar muitas transações por segundo;
• Fatores de Confiabilidade: Funcionamento 24x7, gestão de transações.

Se o software desenvolvido tem como finalidade atender à uma operação de

missão crítica como por exemplo uma aplicação hospitalar, os critérios dos testes
muitas vezes são mais específicos e apropriados dado a importância desse produto
para seu utilizador.

Em qualquer cenário a empresa deve avaliar seu apetite ao risco em produtos de

software e possuir planos de contingência e continuidade de negócios.

Convém lembrar que um software sempre estará associado e inter-relacionado com

ativos e que cada ativo pode atender a um determinado processo de negócio específico
e que em caso de uma parada inesperada ou perda deste produto, ele pode causar um
impacto a corporação.

Os critérios de aceitação de software seguro devem ser rigoroso e estar em

conformidade com os requisitos de conformidade esperados.

Atividades Pós-Revisão
O objetivo das atividades de pós-revisão visam verificar se as correções e/ou ajustes
necessários apontados durante os testes foram corrigidos.

O plano de pós-revisão deve abranger os seguintes pontos a saber:

• Auditoria de configuração;
• Geração de um baseline de avaliação;
• Relatórios de operação e manutenção;
• Revisão do plano de gerenciamento com base no baseline;
• Avaliação de anomalias, relatórios e resoluções;
• Gestão de mudanças;
• Administração das configurações;
• Políticas e procedimentos como guia de seleção de padrões e convenções.

9
9
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Testes Independentes
Testes de softwares também podem ser realizados por fornecedores especializados
desde que sejam respeitados os devidos acordos de confidencialidade na execução dos
serviços como que os critérios de testes e recursos utilizados seja compatível com o
serviço realizado.

Dentre as atividades que podem ser realizadas por empresas especializadas em testes
de software, as mesmas também devem seguir critérios claros nos testes e cobrir os
seguintes pontos:
• Plano de testes;
• Contratos de confidencialidade;
• Documentação de falhas de produto;
• Relatórios e outras documentações;
• Código-fonte dos testes aplicados;
• Entregáveis ao longo do projeto.

Após a realização de todos os testes necessários e o relatório entregue após o proces-

so deve conter os seguintes elementos:
• Conclusões preliminares;
• Problemas encontrados;
• Recomendações para mitigação dos mesmos;

Os diversos mecanismos de testes têm por objetivo comum identificar bugs, erros
ou falhas que possam comprometer o funcionamento e características do produto, mas
também servem para identificar falhas de segurança que possam comprometer os pilares
da segurança da informação.

O principal objetivo de qualquer processo de teste não deve ser o de caça as bruxas, ou
iniciar um processo de demissão da equipe de desenvolvimento, mas deve sim, funcionar
como um processo de aprendizado pela equipe de desenvolvimento de software e de
forma lúdica melhorar a compreensão sobre a definição e uso do produto de software.

Os resultados de um software que não foi devidamente testado ou validado podem

ser cruciais se for disponibilizado por uso sem a devida validação.

10
 Figura 1 – BUG
Fonte: iStock/Getty Images

A imagem acima foi propositadamente colocada de forma invertida para caracterizar

o que um bug em software pode ocasionar à empresa, o risco a imagem de uma empre-
sa, seus clientes, fornecedores e colaboradores.

Instalação e Implantação
de Software Seguro
O objetivo geral da fase de instalação e implantação do software é assegurar que o
sistema está aprovado e que ele possa ser incorporado aos sistemas existentes e que o
planejamento estratégico necessário foi realizado para garantir se ele está operacional e
se pode ser utilizado livremente.

Após o software ser instalado, algumas atividades devem ser realizadas para garantir
que o produto tenha a aderência ao ambiente corporativo, todo o processo de instalação
de um software deve ser iniciado com um plano de trabalho.

Todas as verificações inerentes após a instalação devem ser realizadas, como a de

verificar continuamente sobre a existência de ameaças presentes nas listas de segurança
existentes (CVE, SANS, Microsoft, etc.)

11
11
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Planejando para o uso do Software em Produção

Antes do software ser disponibilizado para uso em produção devem ser implementa-
das políticas de uso e treinamento adequado as corporações e seus colaboradores sobre
o uso da ferramenta e/ou produto.

Primeiramente, devemos monitorar o uso do produto de maneira que ao ser dispo-

nibilizado para uso em produção ele seja gerenciado e seus componentes monitorados
durante a operação.

Além disso podem compor este processo o uso de normas de diversos tipos e fina-
lidade, por exemplo: acesso ao sistema, requisitos mínimos, política de troca de senha,
etc., e evoluindo de acordo com a necessidade da organização.

Suporte ao Usuário
Após a instalação o software deve ter o suporte operacional aos usuários, de forma
a resolver conflitos ou problemas que possam vir a surgir a qualquer ponto ou dúvidas
sobre funcionalidades ou recursos.

Neste ponto também é visto se o produto está aderente as boas práticas e prover dia
a dia o suporte necessário a operação.

As requisições de suporte e/ou ajustes no software devem ser monitoradas e acom-

panhadas até que seja resolvida dentro de um processo de segurança contínuo no de-
senvolvimento de produto.

Convém dentro deste cenário que a operação preveja canais de atendimento ao

público utilizado do software.

Bootstraping
Processos de Bootstraping podem ser definidos como um auto processo de
carregamento, e que podem ser compostom por outros processos de auto verificação,
assim que os mesmos são iniciados, podendo passar por um auto teste de configurações,
componentes, regras e políticas de forma automática.

Inicialização Segura
Em processos de inicialização de aplicações podem ser utilizados para uma melhor
segurança dispositivos do tipo HardLock (Chave de Hardware), TPM (Trusted Plataform
Module), ambos utilizam critérios criptográficos para garantir a segurança do produto.

Eles podem funcionar como uma forma de garantir que em sua ausência a aplicação
ou software não irá funcionar.

12
Gerência de Configuração
Um conjunto de práticas que descrevem como uma organização controla seus ativos
de software e componentes é conhecido por gerência de configuração.

A gestão da configuração de qualquer produto de software permite que a empresa

ou seus usuários possam realizar ajustes em parâmetros de acordo com sua demanda ou
processo, isso dá ao software a flexibilidade técnica e de negócios caso a empresa neces-
site sem que seja necessário o uso da equipe de desenvolvimento para ajustes no código.

Esta característica de que o software tenha ferramentas de configuração e ajustes

devida flexibilidade e garante que o produto atenda plenamente as especificações
referentes a ajustes de configuração.

Porém todo e qualquer processo de gerência de configuração deve possuir meca-

nismos de segurança para alterações não intencionais ou intencionais que possam vir
a comprometer a operação do ambiente, por exemplo, vamos supor que exista uma
tabela em que sejam disponibilizados valores referente ao cálculo dos impostos; um
determinado imposto, essa alteração sem que houvesse um controle porém caso hou-
vesse uma alteração intencional ou não no valor percentual de devidamente monitorado
poderia causar a empresa prejuízos, risco a imagem, a empresa poderia estar sujeita
inclusive a multas referentes as questões fiscais e comerciais.

Finalmente qualquer processo de gestão de configuração deve ser acompanhado

de um processo de validação da garantia de qualidade e em qualquer circunstância o
software deve ter a possibilidade de retornar aos parâmetros iniciais ou originais.

Esse processo pode ser organizado através de elementos como:

• Regras de gerenciamento de configuração: esse processo permite que a empresa
possa também segregar funções de configuração e parametrização;
• Baseline de Gerenciamento: o baseline é uma forma de controle a partir de um
ponto de partida e que qualquer ajuste em que se possa fazer com que o software
possa perder funcionalidades e performance entre outras coisas e que se necessário
possa se retornar as informações iniciais.
• Gestão de Mudanças: qualquer mudança deve vir acompanhada de algum processo
de workflow de gerência ou validação das alterações realizadas.

Manutenção e Operação de Software Seguro

A manutenção e operação do software seguro incluem o ambiente onde o produto está
instalado. Os custos de operação de um software também deve compor o orçamento anual
de uma empresa, que deve prever o crescimento tanto do produto como da organização.

13
13
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Outro aspecto é o registro das diversas atividades envolvendo a operação de software,

tais como: monitoração, gestão de mudanças, alterações, backup, etc.

Gestão de Incidentes
Um bom processo de gerenciamento da operação de tecnologia deve dentro do seu
programa de gestão conter um processo de gestão de incidentes.

A gestão de incidentes é um processo que pode vir acompanhado de uma série de

ações inerentes a questão.

Um incidente pode ser ocasionado por uma parada inesperada no ambiente de

negócio, pode ser intencional ou não intencional, pode ou não estar associado a processos
de tecnologia, porém o tratamento dado ao incidente deve ser realizado segundo o mais
rigoroso critério de resolução de problemas para evitar que volte a ocorrer novamente.

Todo e qualquer incidente deve ser acompanhado da seguinte operação:

• Monitorar e Notificar o Incidente

Alguns países são rigorosos em relação a incidentes que afrontem a segurança da

informação em relação aos dados pessoais. O processo de notificação é recomendá-
vel para deixar claro a seriedade da empresa em relação ao tratamento do incidente.
• Gerenciamento do Incidente

O gerenciamento do incidente deve ocorrer através da documentação detalhando a

ocorrência e em que circunstâncias a mesma ocorreu, e assim permitir a empresa
que ela possa determinar uma equipe específica para tratar a questão e gestão do
incidente de maneira a acompanhar os desdobramentos do problema.
• Antecipar Potenciais Incidentes

Na prática a gestão de incidente deve ser proativa. Incidentes tende a se potencializar

de acordo com a evolução do tempo e o impacto que ele causa.

A resposta a qualquer incidente é o de tratá-lo e possuir plano de recuperação de

desastres e continuidade de negócios das operações corporativas.

Incidentes em softwares por vezes não surgem aleatoriamente eles podem ser
oriundos de um processo não gerenciado de desenvolvimento ou a ausência de
validação e investigação das ocorrências dia após dia.

14
Gestão de Problemas
A gestão de problemas visa simplificar o processo de atendimento a não conformidade
e/ou questões de suporte que podem ser gerenciadas através de níveis de atendimento
de acordo com o problema relatado.

Dentro desse processo existe um fluxo de comunicação dentro da equipe em que se

possa existir diversos indicadores de qualidade e atendimento referente ao software.

Gestão de Mudanças
A gestão de mudanças é o controle de qualquer mudança que venha a ocorrer nos
processos de software e/ou outros ativos e ele deve ser um procedimento sistêmico,
gerenciado e deve ser autorizado pela direção da empresa para que qualquer mudança
cause o menor impacto a operação.

Um bom gerenciamento de mudanças pode ser realizado através da criação de um

documento/relatório documentando a alteração, o procedimento a ser realizado, o
impacto desta alteração, o plano de comunicação e processo de volta em caso de falha.

Um bom programa de gestão de mudança deve vir acompanhando de um processo

de controle de atualizações nos softwares.

Cópia de Segurança, Recuperação e Guarda

Os processos de cópia de segurança devem compor os requisitos de segurança, este pro-
cesso deve ser claramente documentado e detalhando os dados que estão sendo gravados.

O processo de recuperação de uma cópia de segurança deve ser um processo com-

posto por todas as etapas necessárias para que o processo seja executado por qualquer
profissional com competência adequada a execução do procedimento.

As cópias de segurança devem ser adequadamente armazenadas em locais adequa-

dos, hoje com as novas tecnologias de cópia e recuperação de dados se torna dinâmico
esse processo.

Descarte de Software
Os softwares podem naturalmente possuir um ciclo de vida de acordo com a evolução
da tecnologia/empresa e em determinado momento do tempo pode haver a necessidade
de descarte do produto por aquisição de novos produtos, evolução do produto e/ou a
mudança de escopo entre outras coisas.

Porém em um processo de descarte, especificamente no caso de software, devem

ser observados critérios sobre o descarte adequado, ele deve ser composto por um
documento formal aprovado pelos responsáveis da organização.

15
15
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

O plano de descarte deve conter os detalhes acerca da preservação dos dados exis-
tentes, o tempo de guarda do backup, a maneira de exclusão dos dados ou destruição
da máquina se for aplicável.

Convém na medida do possível o uso de ferramentas de limpeza de discos que

promovem um processo de exclusão segura do software de forma que o produto não
possa ser recuperado por qualquer técnica.

Os documentos entre outras informações/base de conhecimento do produto também

podem ser levados em consideração, caso existam informações documentadas por
escrito, as mesmas devem ser destruídas de forma adequada, com uso de trituradores de
papel ou incineração.

Convém que backups antigos do software também sejam destruídos e não é

recomendável a reutilização.

Muitos procedimentos consideram essas informações em inicio de projeto de software

e devem fazer parte do plano de segurança do software.

Caso o software seja alugado o processo e devolução dos dados deve devidamente
documentado para evitar que esses mesmos dados sejam expostos desnecessariamente
ou que os mesmos fiquem sequestrados.

Aquisição de Software
Em algum momento e muitas vezes as empresas preferem adquirir softwares de
terceiros ao invés de construí-los, não obstante, as mesmas preocupações com segurança
devem ser observadas em relação a isto também.

Ao adquirir um software de terceiro, muitas pontos devem ser avaliados para que a
escolha seja a melhor possível. Porém, em sua maioria, apesar dos diferentes motivos,
as empresas levam em conta como critério baseados em custo e funcionalidades.

Quando o único critério é o preço, tende-se por vezes escolher produtos de menor
qualidade e em um primeiro momento atende a empresa e com o passar do tempo
acaba causando maiores problemas a corporação.

Esses problemas podem ser relacionados a atualizações, suporte, novos desenvolvi-

mentos, personalização, etc. Objetos muito difíceis de gerenciar e cuidar.

Avaliação de Risco de Fornecedores

O propósito da avaliação de risco de terceiros visa identificar e manter uma abordagem
adequada em relação ao provedor de software e a empresa, ameaças implicam em risco
ao ambiente de negócio e devem ser avaliados de forma criteriosa.

16
 Dentre os pontos e itens que devem ser observados em contratos de software devem
conter os seguintes itens:
• Instalação de software ou hardware malicioso;
• Instalação de software ou hardware pirata;
• Falha ou disfunção em ambiente de produção afetando de forma crítica a operação
da companhia;
• Suporte ao ambiente;
• Instalação não intencional de vulnerabilidades em hardware ou software.

A disciplina de segurança da informação nos ensina que a prevenção é melhor méto-

do de se implantar uma segurança ativa. O princípio sempre será o de mitigar riscos e
garantir um nível aceitável de segurança.

Lembrando que a segurança em qualquer estado deve ser proativa e não reativa.

Por que é Importante Realizar a Avaliação

de Risco de Fornecedores?
De forma geral, a avaliação de risco é parte constante da gestão da segurança da
informação, o monitoramento continuo de ativos de software visa identificar processos
e a evolução de ameaças, determinando o potencial que as elas possam causar ao
ambiente e tomar as medidas necessárias para evitar que se materializem.

A habilidade de tomada de decisão é muito importante em relação aos fornecedores

e requer um processo sistémico e contínuo em relação a segurança.

A padronização e organização do processo de avaliação deve ser realizado a partir de

um padrão de critérios pré-definidos e envolvimento dos patrocinadores dentro da empresa.

Avaliação de Risco para Reuso de Código

O reuso de código tem sido uma prática da indústria de software ao longo dos anos
de maneira a acelerar os processos de desenvolvimento de software. De fato o reuso
tem se demonstrado ser uma boa prática, a maioria das linguagens e times de desenvol-
vimento estão preparadas para o uso dessas e outras técnicas.

Sabemos que em uma boa parte dos softwares que utilizamos existe essa estrutura
dentro desses produtos e diante disto devemos nos atentar que uma falha identificada
em algum ponto do software pode estar presente em outro ponto do mesmo produto.

Diante desse cenário deve ser criado um plano de trabalho que permita avaliar esses
itens em diversos pontos do produto, muitas empresas e/ou países as vezes exigem
acesso ao código fonte para realização de auditoria de segurança.

17
17
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Essas auditorias visam buscar diversas informações que possam vir a colocar em risco
a empresa, isso incluem pontos sobre:
• Propriedade Intelectual

Existe uma série de questões associadas a propriedade intelectual aos quais não
vamos entrar no mérito, mas se estivermos falando de empresas concorrentes esses
processos podem envolver milhões de dólares em multas e sanções.

Outra questão se refere aquela em que se envolvem coisas que vão além do código
fonte como fórmulas, entre outros conceitos implementados de maneira a gerar
dúvida dentro de determinados produtos.

Não podemos nos esquecer nas diversas licenças existentes em software que po-
dem afetar o uso e distribuição de produtos e que devem ser observadas para evitar
maiores problemas.
• Compliance

Dependendo da área de atuação da empresa a mesma está sujeita a regulação por

parte de governo e instituições de classe, auferir se o software instalado atende essa
regulação é de suma importância.
• Qualificação de Fornecedores

Hoje temos uma nova forma de contratação de produtos através de soluções que fun-
cionam pela internet e funcionam através de pagamentos mensais com base no uso.

Deve-se ater ao ambiente onde essas ferramentas estão instaladas, planos de

segurança e normas aos quais essas empresas estão associadas. Isso nos leva a
questões de qualificação de fornecedores de softwares.

Isso influência a decisão de compra de produtos de tecnologia, para os critérios de

avaliação de terceiros pode-se seguir os critérios com base na norma ISO 15408.

Controle de Integridade
Contratos são instrumentos legais que permitem as empresas se relacionar com seus
fornecedores, clientes, etc. com regras claras sobre as atividades e responsabilidades de
cada lado.

Esse instrumento dentro da tratativa de um software deve conter regras em relação a

integridade da informação como também em relação a integridade dos controles existentes.

Muitas vezes podem ser exigidos dos fornecedores de produtos atestados de

qualificação técnica e atestados de avaliação de segurança sobre os produtos contratados.

A observância desses controles visa garantir que a empresa provedora é capacitada a

realizar as atividades pelo qual elas estão sendo contratadas.

18
Manutenção, Operação e Distribuição de Software
A entrega e operação de um software é a última parte de um processo de software,
durante essa entrega o produto deve ser monitorado durante o período de operação.

As operações de manutenção são as atividades seguidas a distribuição e normalmente

acompanhada com o termo sustentabilidade do produto.

O pós-desenvolvimento sustenta atividades e geralmente é definido no plano de operação.

Cadeia de Custódia
O termo cadeia de custódia tem por objetivo determinar um baseline em que toda a
equipe tem conhecimento de todos os entregáveis do produto de software.

Neste ponto também pode-se definir os times responsáveis por áreas e/ou módulos
do produto e por consequência a gestão dos mesmos.

Publicação e Disseminação de Controles

A publicação de produto é o ato de colocar o produto em produção, deve ser asso-

ciado a questão de licenciamento do produto, garantido que o produto possuí as
garantias legais para serem colocados em produção.

A publicação de produto é o inicio da produção e deve ser associado a questão de

licenciamento que possui todas as garantias legais para serem colocados em produção.

A disseminação de controles de uso sobre o produto caracteriza uma das boas práticas
do modelo de desenvolvimento seguro, estes controles podem ser auto assináveis através
de certificados digitais de uso, validação da integridade dos controles, evitando ameaças
internas e externas ao ambiente.

Integração entre Sistemas

Um software atualmente pode integrar-se a outras soluções através de interfaces
programáveis que acessam um conjunto de dados, o controle no acesso ou distribui-
ção de dados deve ser claro e a forma de acesso deve ser prevista nos termos de uso
das aplicações.

Autenticidade e Integridade de Software

O software utilizado deve ser garantido através de mecanismos que possam garantir
a integridade do código que está sendo executado e evitando que códigos maliciosos
possam vir a prejudicar o funcionamento da aplicação.

19
19
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Instalação e Operação em Ambiente de Produção

O uso de um software de terceiro deve contemplar modelos de uso instalação e
operação em ambiente de produção de maneira controlada e monitorada.

Convém pensar em controles de tecnologia, assistência e uso de ferramentas específi-

cas que possam promover esse recurso, entre os recursos disponíveis podemos citar ferra-
mentas de controle de versão e colocando em produção ferramentas de monitoramento.

A figura abaixo ilustra as diversas ferramentas que podem ser utilizadas em diversas
fases do desenvolvimento do produto.

Lista de Ferramentas: https://goo.gl/tyNGEh

Gestão de Incidente e Vulnerabilidades

Um incidente ou a exploração de uma vulnerabilidade pode evoluir de um simples
incidente para uma crise quando não tratado adequadamente.

Continuamente lemos notícias na mídia impressa ou especializada sobre determinada

companhia que teve seus dados vazados, muitas vezes o acesso a esses dados se dá por
diferentes técnicas de invasão e os dados são roubados.

Muitas vezes os invasores aguardam muito tempo até que todos os rastros estejam
apagados para usar os dados sequestrados para realizar extorsão financeira junto as
empresas, com a ameaça de vazamento desses dados.

As companhias ignoram esses elementos e não tomam as atitudes adequadas e os

vazamentos acabam ocorrendo prejudicando as empresas e seus clientes.

Independente do quão seguro seja o software outros mecanismos de controle devem

ser implementados para garantir a operação adequada do software, esses outros
mecanismos podem ser: firewall, soluções de antivírus, mecanismos de gestão de
identidade, etc.

Conclusão
Manter um produto de software ou de terceiros, requer o que chamamos de controle
e gestão, e que em todas as fases de vida de um produto, os pontos de atenção e geren-
ciamento de dados fazem parte de um conceito de segurança pró-ativa dos produtos.

20
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

  Sites
Teste de Software
https://goo.gl/XXVIOj
Testes de Software Exploratórios
https://goo.gl/xPdHES

 Vídeos
Testes de Software
https://youtu.be/DBw_GctgPqU
Transforme testes Manuais em Testes Automatizados
https://youtu.be/yXSdu1t-g-Y

21
21
UNIDADE
Práticas de Desenvolvimento Seguro em Sistemas

Referências
HOGLUND, Greg; McGraw, Gary. Como Quebrar Códigos: a arte de explorar (e
proteger) software. Pearson 448 ISBN 9788534615464. (Livro Eletrônico).

STALLINGS, William. Criptografia e Segurança de Redes: princípios e práticas - 4ª

edição. Pearson 512 ISBN 9788576051190.(Livro Eletrônico).

SHEMA, Mike. Hack notes: segurança na web referência rápida/2003 - (Livro)

referência rápida. São Paulo: Campus, 2003. 182 p. ISBN 8535213503.

22