1. Segurança no desenvolvimento de sistemas com
metodologia ágil SCRUM
Bruno M. Rego, Inês Brosso
Faculdade de Computação e Informática – Universidade Presbiteriana Mackenzie
Caixa Postal 01302 –907 – São Paulo – SP – Brasil
bmr@attom.com.br inesbrosso@mackenzie.com.br
Abstract. This paper presents a proposal for the integration of information
security and software security best practices with SCRUM, beyond the challenges
and how to measure the results of this integration.
Resumo. Este artigo apresenta uma proposta para a integração da segurança da
informação e melhores práticas de segurança de software junto ao SCRUM,
além dos desafios e como mensurar os resultados desta integração.
1. Introdução
O crescimento de computadores conectados à internet vem aumentando e,
consequentemente, oferecendo mais possibilidades de ataques. Isto coloca o software
e, consequentemente, as organizações e usuários em grande risco. (MCGRAW, 2006)
O acompanhamento dessa evolução da Internet permitiu-nos desenvolver
novos recursos para controles de segurança e de privacidade. Mesmo com estes
diversos recursos e controles sofisticados na infraestrutura de redes e junto ao usuário
final, o software sempre foi e será o principal vetor de ataque.
Atualmente, esse cenário se torna cada vez mais complexo, pois a
possibilidade de integração e de acoplamento de novos recursos aos softwares,
geralmente chamados de extensões, afeta negativamente a sua segurança, aumentando
o risco de acordo com o nível de integrações que a ele oferece. (MCGRAW, 2006)
Sabendo da exposição das empresas e dos usuários que utilizam a internet,
este trabalho propõe uma maneira de integrar os conceitos de segurança da
informação, principais atividades e melhores práticas de segurança de software junto
à metodologia ágil SCRUM para a construção de softwares seguros.
O objetivo deste trabalho é propor a integração dos principais conceitos da
segurança da informação, atividades e melhores práticas de segurança de software
junto ao modelo ágil de desenvolvimento de software, o SCRUM.
Enfim, O estudo se justifica uma vez que, atualmente, o software é a principal
superfície de ataque, Como tal, deve ser eficientemente planejado, executado e
controlado para que possa alcançar seus objetivos.

2. 2. Segurança de Software
A segurança de informação visa a garantir a confidencialidade, integridade e
disponibilidade das informações, além de garantir a conformidade com a legislação
vigente e a continuidade dos negócios. De forma mais ampla, pode-se definir como
prática de gestão de riscos e de incidentes evitar o comprometimento dos três
principais conceitos da segurança, descritos abaixo:
Confidencialidade é o conceito que define que toda informação deve ser
protegida de forma que o acesso não autorizado não seja permitido.
Integridade é o conceito que define que toda a informação deve ser mantida
da mesma forma que foi disponibilizada, visando à proteção contra quaisquer
alterações.
Disponibilidade é o conceito que define que toda informação disponibilizada
por um individuo ou instituição deve estar acessível no momento em que houver
necessidade para qualquer finalidade.
Com base nos conceitos apresentdos acima a noção de risco de segurança de
software tem se tornado de conhecimento comum, mas os programadores, arquitetos e
cientistas da computação só agora começaram a estudar sistematicamente como criar
um software seguro. (MCGRAW, 2006)
Criação de um sistema seguro requer um processo de segurança integrado no
ciclo de desenvolvimento do software. Este processo de segurança de software deve
cobrir desde a arquitetura até a implantação do projeto e, principalmente, definir o
papel dos profissionais de segurança de software dentro do ciclo de desenvolvimento
de software, de modo que o processo seja aplicado de forma eficaz. (SWIDERSKI e
SNYDER, 2004)
2.1 Desenho de Segurança
Entender os princípios de proteção da informação é essencial para construir o
desenho da arquitetura de um software de forma segura. De modo que a dificuldade
de construir softwares seguros está relacionada com a qualidade negativa das
definições, premissas e requisitos de segurança apresentados. (SALTZER e
SCHROEDER, 1975)
Softwares complexos são, provavelmente, menos seguros do que o software
mais simples, então, se deve sempre se esforçar para produzir o software simples,
conforme descrito por SALTZER e SCHROEDER, 1975, no princípio da economia
de mecanismos. (SCHWABER, 2006)
Todo o texto relacionado a desenho de segurança é referência obtida no
documento desenvolvido por SALTZER e SCHROEDER, 1975, que descreve os
princípios básicos para a definição do desenho e arquitetura de forma segura,
extremamente críticos para a construção de um software seguro.

3. 2.1.1 Economia de mecanismos
Sistemas e ou softwares complexos, com diversos recursos e dependências,
podem apresentar erros de desenvolvimento, implantação e ou projeto, permitindo
violações de segurança dificilmente detectadas, pois o sistema é utilizado
normalmente. O princípio da economia de mecanismos é bem conhecido e se aplica a
qualquer aspecto de um sistema, onde a recomendação é manter o desenho do
software pequeno e simples o quanto.
Em casos onde há necessidade de executar a revisão de código fonte, o
princípio da economia de mecanismos facilita muito o trabalho do especialista de
segurança de software responsável por essa atividade.
2.1.2 Mediação completa
Todas as requisições devem ser verificadas, analisadas e autorizadas entre
objetos e dependências do software. O princípio da mediação diz que todo acesso a
um objeto deve ser verificado, autenticado e autorizado. Então, quando esse princípio
é aplicado sistematicamente, ele se torna a base principal de proteção do sistema,
forçando a validação de toda e qualquer.
2.1.3 Desenho aberto
A arquitetura, o desenho e o código do software deveriam estar disponíveis
para avaliação dos clientes. Com isso, os usuários mais exigentes e devidamente
autorizados poderiam analisar, entender e se convencer de que o sistema atende
realmente às suas necessidades. O princípio de desenho aberto diz que a arquitetura,
desenho e código de um software não devem depender da ignorância dos atacantes em
potencial, permitindo que todos possam fazer revisões e identificar possíveis
problemas.
2.1.4 Separação de privilégios
O princípio de separação de privilégios busca definir privilégios para acesso
ao software como, por exemplo, autorização de usuários com diferentes perfis.
2.1.5 Privilégio mínimo
Todo software e usuário deveriam realizar suas funções utilizando apenas o
mínimo de privilégios necessários. O principio de privilégio mínimo busca limitar o
perigo. Reduzindo os privilégios do software ou usuário a um escopo bem específico
pode limitar possíveis incidentes.

4. 2.1.6 Mínimo de mecanismos comuns
O principio mínimo de mecanismos comuns busca limitar a utilização de
mecanismos compartilhados para mais de um ou todos os clientes que utilizam o
software.
2.1.7 Usabilidade
É essencial que toda a interface seja de fácil manuseio, facilite o aprendizado
dos usuários, tornando assim o sistema menos suscetível a erros. O princípio da
usabilidade diz que, se a aprendizagem da atividade executada pelos clientes está de
acordo com as proteções construídas para o sistema, então os erros serão
minimizados.
2.2 Análise de Riscos e Modelagem de Ameaças
A ideia da gestão de risco, como um princípio fundamental da segurança, é
apresentada com diferentes nomes em software de segurança, tais como modelagem
de ameaças e análise de risco. (MCGRAW, 2006)
O principal resultado da modelagem de ameaça é um documento ou
documentos que descrevem em alto nível o desenho da aplicação, lista de recursos
que requerem proteção, identificação e categorização das ameaças e plano de
mitigação. (HOWARD e LIPNER, 2006)
A modelagem de ameaças pode, também, ajudar a executar atividades de
revisão de código e a construção de testes de penetração. Abaixo, apresento as
atividades relacionadas à modelagem de ameaças, utilizando como principal
referência os livros HOWARD e LIPNER (2006) e, também, SWIDERSKI e
SNYDER (2004), conforme relacionadas a seguir:
2.2.1 Criar ou verificar cenários
Consiste em verificar as superfícies de ataque do cenário em questão,
imaginando possíveis ações de agentes externos, com foco em gerar evidências caso
ocorra algum incidente. Na criação dos cenários, é importante verificar se o usuário
deve se proteger contra colaboradores internos ou externos, mal-intencionados.

5. 2.2.2 Avaliar a lista de dependências externas
Sabe-se que a aplicação desenvolvida não é autossuficiente, que roda sob um
sistema operacional, utiliza servidor web, serviço de banco de dados ou frameworks
de aplicação. Devem ser identificadas e listadas todas estas dependências,
considerando que o sistema operacional e os serviços estejam com as configurações
seguras.
2.2.3 Determinar as premissas de segurança
Premissas ou requisitos de segurança devem permanecer documentados e
disponíveis aos programadores como referentes para a construção de um software
seguro.
Pontualmente, cada projeto possui requisitos mais específicos e nesse
momento, devem-se definir quais as premissas de segurança para esse ambiente
operacional, como, por exemplo, segregação de ambientes lógicos e físicos;
arquitetura de autenticação, autorização e auditoria; utilização de um framework
padrão; arquitetura para armazenamento centralizado de logs e formato específico
para envio.
2.2.4 Determinar tipos de ameaças
A gigante de software Microsoft utiliza uma taxonomia de ameaças, criada e
batizada por ela, chamada STRIDE (Spoofing, Tampering, Repúdio, Exposição de
informações, Negação de serviço, Elevação de privilégio), descritos abaixo:
2.2.4.1 Spoofing
Permite a um atacante se passar por alguém ou alguma coisa, tal como um
usuário tentar se passar pelo presidente de uma empresa, uma biblioteca dinâmica que
foi substituída, um servidor respondendo como microsoft.com, entre outros.
2.2.4.2 Tampering
Interceptação e alterações nos dados em um canal de transmissão ou em
código fonte.

6. 2.2.4.3 Repúdio
Consistem em repúdio, uma ação executada que não pode identificar o real
individuo responsável. Já o não repúdio é a habilidade de conter a ameaça de repúdio.
Um exemplo interessante é quando um usuário executa uma ação no sistema e não
pode ser identificado, pois não existem evidências daquela ação.
2.2.4.4 Exposição de Informações
Esta ameaça envolve a exposição das informações a indivíduos que não
deveriam ter acesso a elas. Imagine um arquivo confidencial sendo lido por uma
pessoa mal-intencionada que não tem privilégios para acesso.
2.2.4.5 Negação de serviço
Os ataques de negação de serviço têm como objetivo degradar ou tornar
indisponível. De alguns anos pra cá, os ataques de negação de serviço têm ocorrido a
partir de diversas origens, sendo conhecidos como ataque de negação de serviço
distribuídos (DDOS).
2.2.4.6 Elevação de Privilégios
Esta ameaça ocorre quando um usuário consegue aumentar seus privilégios,
executando atividades de usuários com privilégios administrativos, ou superusuários.
2.2.5 Identificando ameaças
O processo de identificação de ameaças, primeiramente, lista as entidades
externas que interagirão com o software, os processos, o fluxo de dados e onde os
dados serão armazenados.
A principal contribuição deste processo é uma matriz que detalha os tipos de
ameaças relacionadas às entidades externas e suas interações junto ao software, os
processos, o fluxo de dados e onde os dados serão armazenados.
2.2.6 Determinando os riscos
A grande dificuldade para determinar o risco é determinar qual é a chance do
ataque ocorrem. De posse dessa informação, a fórmula abaixo pode ser utilizada:
Risco = Chance de o Ataque Ocorrer × Estrago em potencial

7. Historicamente, especialistas de segurança utilizam cálculos numéricos para
identificar os riscos, mesmo sabendo que os números podem ser subjetivos.
2.2.7 Plano de mitigação
A mitigação, geralmente, consiste em uma defesa ou contramedida, tentando
reduzir ou eliminar o risco de uma ameaça. Abaixo, a descrição das estratégias de
mitigação.
A estratégia para mitigar o risco é não fazer nada que possa ser uma estratégia
válida. Caso o risco identificado seja conhecido e considerado baixo, nada a ser feito.
Outra possibilidade para a mitigação do risco é remover o recurso ou
funcionalidade, garantindo que o risco identificado seja levado ao menor nível. Esta
mitigação deve ser usada quando o risco é muito grande, e a mitigação é
insustentável.
Desligar o recurso e funcionalidade também garante a mitigação pontual do
risco, garantindo que os recursos ou funcionalidades afetadas pelo risco sejam
mitigados ou permaneçam desligadas.
Em outros casos, notificar o usuário pode ser uma alternativa para algumas
ameaças, lembrando que somente notificar o usuário, informando que a ameaça
existe, pode não ser a melhor decisão.
2.3 OWASP TOP 10
O The Open Web Application Security Project (OWASP) é uma organização
mundial sem fins lucrativos, focada na melhoria da segurança do software, oferece,
gratuitamente, para toda a sociedade diversos projetos de segurança de software, onde
o documento mais conhecido e que mais contribui para este trabalho é o OWASP Top
10.
2.3.1 A1 – Injeção
Falhas de injeção de códigos são comuns em aplicações web, principalmente a
injeção de código SQL. Estas falhas ocorrem quando dados fornecidos nos campos de
entrada são interpretados como parte de comandos ou consultas, permitindo que um
atacante acesse a base de dados da aplicação e execute consultas arbitrárias. Para
mitigar essa vulnerabilidade é recomendável que todas as informações enviadas à
aplicação sejam validadas, tratando possíveis erros e exceções, evitando a exposição
de informações sensíveis aos clientes.

8. 2.3.2 A2 - Cross Site Scripting (XSS)
Conhecido como XSS, ocorre quando uma aplicação recebe os dados do
usuário e os envia de volta ao navegador sem realizar validação ou codificação dos
dados, permitindo a execução de códigos/scripts arbitrários. Para mitigar esta
vulnerabilidade é necessário encodar e validar as informações enviadas ao sistema.
2.3.3 A3 - Quebra de autenticação ou sessão
Autenticação apropriada e gerenciamento de sessão são mecanismos críticos
para a segurança de aplicações Web. Apesar disso, é comum encontrar falhas nesses
mecanismos, que podem colocar em risco as credenciais utilizadas pelos usuários ou
identificador de sessão (session ID). Burlando os mecanismos de autenticação e de
gerenciamento, é possível roubar a sessão do usuário obtendo acesso privilegiado sem
autorização, junto à aplicação. Para mitigar esta vulnerabilidade, é recomendável não
utilizar identificadores de sessão pré-definidos ou reutilizados, eliminar ou invalidar a
sessão após a utilização, garantir que as funções de logout e timeout foram
implementadas corretamente.
2.3.4 A4 - Referência insegura a objetos
Ocorre quando um objeto é acessado de forma direta, sem utilizar qualquer
tipo de proteção. Objeto, neste caso, pode ser entendido como um arquivo de sistema
ou banco de dados, diretórios ou chaves, utilizadas em URLs ou como parâmetros de
formulário. Para mitigar esta vulnerabilidade, é necessário verificar a integridade dos
objetos, garantir que o acesso ao objeto está autorizado, garantir que os objetos não
estão expostos.
2.3.5 A5 - Cross Site Request Forgery (CSRF)
O ataque consiste em forçar a vítima autenticada no sistema a enviar
requisições a uma aplicação vulnerável, realizando operações sem o conhecimento da
vítima. Ações realizadas com a participação da vítima, porém sem seu conhecimento.
Para mitigar esta vulnerabilidade, são necessários: filtrar todos as informações
enviadas à aplicação; utilizar tokens randômicos para cada requisição à aplicação com
sessão de autenticação estabelecida; não utilizar a URL para realizar requisições com
dados sensíveis.
2.3.6 A6 - Configuração não apropriada de segurança
Essa falha existe por conta de instalações-padrão não seguras, por falta de
atualizações, ou senhas padrão em ambiente de produção, por exemplo:

9. Aplicação com usuário privilegiado, “admin” e senha “admin”. Banco de
dados SQL Server, com usuário privilegiado “sa” e sem senha.
Para mitigar esta vulnerabilidade, é recomendável que, durante o
desenvolvimento da aplicação, deva-se garantir que todas as mensagens de erros
sejam tratadas corretamente, criando mensagens genéricas para serem apresentadas
quando ocorrer um erro na aplicação.
2.3.7 A7 - Falha na restrição de acesso a URLs
O atacante pode obter acesso indiscriminado às funções a que não deveria ter
acesso, como geração de conteúdos, administração de usuários, etc. Ocorre quando há
acesso, com sucesso, a URLs, aparentemente não conhecidas pelo usuário e proibidas.
Para mitigar esta vulnerabilidade é recomendado forçar o aspecto de
autorização definindo privilégios no acesso quando este recurso for possível e assim
não permitir o acesso de usuários não autorizado a arquivos controlados, de
configuração, logs, etc.
2.3.8 A8 - Armazenamento inseguro de criptografia
Falhas na implementação de mecanismos de criptografia podem colocar em
risco as informações armazenadas. Podem ser consideradas vulnerabilidades: a
utilização de cifra “fraca”, tamanho de chave criptográfica inadequada ou erros ao
utilizar cifra forte. Um atacante pode aproveitar essa vulnerabilidade para tentar obter
acesso aos conteúdos e, também, a dados sensíveis da aplicação.
Para mitigar esta vulnerabilidade, não utilize algoritmos conhecidamente
fracos, como: RC3, RC4 e MD5. Nunca utilize canais inseguros para a transmissão
das chaves de criptografia. O BASE64 não é algoritmo de criptografia ou função de
hash. Não construa algoritmos de criptografia próprios em produção e garanta que
dados sensíveis estão sendo cifrados e armazenados em local seguro.
2.3.9 A9 - Comunicação insegura
Informações sensíveis devem ser transmitidas em canais seguros utilizando
SSL/TLS. Caso contrário, serão enviadas em texto plano e podem ser capturadas por
pessoas mal-intencionadas.
Um atacante pode utilizar um analisador de pacotes e obter acesso a
informações privilegiadas, como cookies ou identificador de sessão, credenciais e
outras informações críticas para a empresa e negócios.
Para mitigar esta vulnerabilidade, é recomendado utilizar TLS/SSL para
conexões que oferecem o mecanismo de autenticação ou transmitem dados sensíveis,
além de garantir que a infraestrutura de comunicação está sendo feita de maneira
correta.

10. 2.3.10 A10 - Redirecionamento inseguro
Possibilita encaminhar usuários a sites não desejados, os quais podem conter
códigos maliciosos para roubar informações da sessão do usuário. Funções de
redirecionamento sem a validação do destino.
Para mitigar esta vulnerabilidade, é recomendado evitar a utilização
redirecionamentos ou encaminhamento, validando se o site de destino não é
malicioso, evitando que informações sensíveis sejam enviadas através da URL.
2.4 ATIVIDADES E MELHORES PRÁTICAS
O objetivo da principal referência utilizada para o desenvolvimento deste
trabalho, o livro Software Security: Building In é: “explorar e descrever um conjunto
de melhores práticas de segurança de software que eu chamo de pontos de conto”.
(MCGRAW, 2006)
A principal contribuição deste trabalho é propor a integração das melhores
práticas de segurança de software ao SCRUM. Estas melhores práticas ou principais
atividades de segurança de software foram baseadas conforme a referência em
MCGRAW (2006), e descritas abaixo.
2.4.1 Revisão de código
A revisão de código no contexto de software seguro é uma análise de
segurança sob o código de um software, com o objetivo de buscar por padrões e
regras conhecidas de bugs e, possivelmente, por falhas.
Existem diversas maneiras de fazer a revisão de código, uma delas é a análise
do código fonte que pode ser feita de forma manual, consumindo muito tempo, e
também, de forma automática, a partir de ferramentas que verificam o código fonte
sem tentar executá-lo de forma eficiente e muito mais rápido.
Além dessas, existem outras formas de fazer a revisão de código em códigos
compilados e byte-codes, que são: análise binária, engenharia reversa.
2.4.2 Análise de risco da arquitetura
A análise do desenho e arquitetura de um software é, sem dúvida, uma das
atividades mais importantes para garantir a segurança de um software. Analisar as
entidades que interagem com o sistema, os componentes, o fluxo de dados e onde os
dados serão armazenados, sem dúvida, contribuem para mapear os riscos e descobrir
maneiras de mitigá-los. O modelo de modelagem de ameaças apresentado
anteriormente é a maneira mais conhecida de modelar e mapear os riscos.

11. 2.4.3 Teste de invasão
Atualmente, os testes de penetração de segurança de software, também
conhecidos como testes de penetração em aplicação, são úteis, principalmente, para
identificar problemas no ambiente e de configuração do sistema.
Os testes de penetração são executados através de ferramentas e exigem que o
responsável pelos testes tenha habilidades avançadas em relação à segurança de
software.
Atualmente, este é o principal recurso utilizado pelas empresas para avaliação
do software a ser instalado no ambiente de produção, não garantindo que o software
foi construído com segurança, mas, se utilizado desde a primeira versão do software,
podendo encontrar bugs de segurança ainda não identificados.
2.4.4 Teste de segurança baseando no risco
O objetivo desta fase é fazer um teste mais direcionado ao software,
economizando tempo e tornando os testes mais eficientes, além de poder executá-los
antes mesmo de o software estar pronto em um ambiente de produção.
A grande diferença é que os testes podem ser executados em partes do
sistema, como em componentes ou na integração deles, além de serem feitos usando
duas metodologias, teste de caixa branca e teste de caixa preta.
A análise de risco desenvolvida previamente é essencial e deve direcionar a
construção de casos de abuso.
Os testes de segurança baseados em riscos, também, exigem que o responsável
por essa atividade tenha habilidades avançadas em relação à segurança de software,
para análises estáticas e dinâmicas no código fonte do software.
2.4.5 Casos de abuso
No UML o caso de uso permite modelar e desenhar o software, detalhando
como os recursos devem ser desenvolvidos e o comportamento normal do sistema.
Já, o caso de abuso permite modelar e desenhar o software, como no caso de
uso do UML, mas na visão de um cliente mal-intencionado, mapeando, assim,
possíveis atividades maliciosas que, possivelmente, seriam executadas.
3. SCRUM
O SCRUM é uma metodologia ágil focada nas necessidades de negócio do
projeto no desenvolvimento de produtos ou serviços. (PRIES e QUIGLEY, 2010)

12. A palavra SCRUM não é uma sigla, mas os mecanismos no jogo de rugby
para obter uma saída de bola e colocá-la em jogo. (SCHWABER, 2004)
O processo é bastante simples e se baseia em ciclos de aproximadamente 2 até
4 semanas, chamados de iterações (em inglês, sprints), dedicados à entrega de
funcionalidades bem definidas. Estas funcionalidades são reunidas e documentadas
em uma lista de atividades chamada de backlog do produto, que pode ser atualizada e
priorizada pelo dono do produto, de acordo com as necessidades e prioridades do
negócio.
O SCRUM não se concentra apenas em agregar valor ao negócio e sim em
agregar o mais prioritário valor ao negócio, conforme definido pelo cliente e dono do
produto. (SCHWABER, 2004)
Abaixo, descrevo informações relevantes, referentes a papéis e
responsabilidades, artefatos e cerimônias da metodologia ágil SCRUM.
3.1 Papéis e Responsabilidades
3.1.1 Dono do Produto
O dono do produto é o profissional responsável pelo gerenciamento do
backlog do produto e tem como principal objetivo maximizar o valor do projeto.
Fazem o papel do cliente, mapeando todas as mudanças planejadas e possíveis novos
recursos, priorizando as atividades de acordo com as necessidades da empresa e do
negócio. (SCHWABER, 2004)
3.1.2 Scrum Master
O scrum master é o profissional responsável pelo processo do SCRUM, sua
correta implementação e maximização dos seus benefícios. O scrum master tem como
principal atividade remover qualquer possível impedimento para a entrega do
objetivo, garantindo que as metas e as atividades definidas e estimadas na reunião de
planejamento da iteração sejam entregues. (SCHWABER, 2004)
3.1.3 Equipe
No SCRUM, a equipe é autogerida, e cada um tem a responsabilidade por suas
atividades e resultados. A equipe é formada por poucas pessoas com diferentes
habilidades, no máximo de 5 a 9 pessoas, necessárias para a execução das tarefas.

13. 3.2 Artefatos
3.2.1 Backlog do produto
O backlog do produto é uma lista priorizada com os itens e recursos desejados,
com tempo estimado, que possam ser adicionados e deletadas durante o projeto.
(SCHWABER, 2004)
3.2.2 Backlog da iteração
O backlog da iteração é uma lista de atividades oriundas do backlog do
produto que é definida pelo dono do produto, scrum master e toda a equipe durante a
reunião de planejamento da iteração.
3.2.3 Gráfico de Burndown
O Gráfico de Burndown é uma representação gráfica que mostra a quantidade
de horas de trabalho restante ao longo da linha do tempo. (SCHWABER, 2004)
2.3 Cerimônias
3.3.1 Planejamento da Iteração
Reunião entre a equipe o scrum master e o dono do produto para escolher e
mensurar os pontos ou horas das atividades a serem executadas durante uma iteração;
essa lista é chamada de backlog da iteração.
3.3.2 Daily Scrum
O daily scrum é uma reunião rápida onde cada integrante da equipe informa a
sua atividade para os outros integrantes, sinalizando qualquer possível impedimento
ao scrum master para resolução das atividades. (SCHWABER, 2004)
Diariamente, sempre no mesmo horário, a equipe se reúne com o scrum
master com o objetivo de remover rapidamente qualquer impedimento relacionado ao
desenvolvimento do produto. Nessa reunião, cada membro da equipe deve responder
a três questões, que são:
- O que eu fiz desde a última reunião (daily scrum)?
- O que será feito entre agora e a próxima reunião (daily scrum)?
- Existe algo prejudicando a execução das atividades planejadas?

14. 3.3.3 Revisão da iteração
A revisão da iteração é uma reunião que ocorre ao final de cada iteração, onde
a equipe apresenta ao dono do produto o que foi feito e entregue durante aquela
iteração. (SCHWABER, 2004)
3.3.4 Retrospectiva da iteração
A retrospectiva da iteração é a reunião que ocorre após cada iteração, onde a
equipe se reúne para discutir melhorias no processo e também no produto.
(SCHWABER, 2004)
4. Integração das atividades de segurança de software com o SCRUM
Para que as atividades e melhores práticas de segurança de software sejam
integradas ao SCRUM, é preciso, em primeiro lugar, apresentar e conscientizar todos
os colaboradores, principalmente, os envolvidos e interessados na construção de
software seguro, sobre os conceitos de segurança da informação e segurança de
software, possivelmente, através de pequenos treinamentos a estes colaboradores.
Neste capítulo, descrevo a maior contribuição proposta por este trabalho, a
integração dos conceitos de segurança da informação e as melhores práticas de
segurança de software, junto ao modelo ágil de desenvolvimento de software, o
SCRUM.
4.1 Educação e conscientização
Treinar e conscientizar os profissionais acerca da segurança da informação,
garantindo uma visão crítica sob ações que colocam ou representam riscos a
“imagem” da empresa, é um grande desafio.
“A real preocupação da maioria das escolas, universidades e colégios técnicos
é ensinar recursos de segurança e não como construir um software seguro”.
(HOWARD e LIPNER, 2006)
O processo de educação e conscientização visa a garantir conhecimento aos
colaboradores de forma a incentivar uma visão crítica relacionada aos riscos da
segurança, gerando de forma proativa a construção de softwares seguros, atuando em
profundidade ou em outras diversas camadas e evitando incidentes oriundos de ações
internas erradas ou possivelmente maliciosas.

15. 4.2 Processo
Quando o assunto é segurança da informação, é imprescindível ter o total
apoio da alta gerência, evitando que possíveis conflitos de interesses possam impedir
que controles definidos pela equipe de segurança de software não sejam aplicados.
Um dos requisitos mais importantes para a construção de software seguro é
que a documentação do projeto seja bem feita e mantida em um local disponível e
acessível por todos os colaboradores envolvidos e interessados no projeto. Uma
documentação clara, estando disponível, faz com que o profissional de segurança
esteja capacitado a desenvolver as primeiras analises do projeto, antes mesmo do
primeiro encontro com os outros integrantes do projeto.
Conforme mencionado anteriormente, a proposta deste trabalho consiste em
alinhar as melhores práticas de segurança de software junto ao SCRUM, mas, para
isso é importante levar em consideração que a equipe de segurança de software
geralmente e reduzida e o tempo é muito curto para análises e entregas de novas
funcionalizadas em metodologias de desenvolvimento ágil.
4.2.1 Artefatos
4.2.1.1 Backlog do produto e backlog da iteração
Nestas fases, o profissional de segurança de software deve analisar o backlog
do produto em busca de identificar possíveis ameaças, entender como funcionará o
produto desse projeto, criando cenários, definindo o desenho e a arquitetura, reunindo
e alinhando as premissas de segurança com todos os envolvidos e interessados pelo
projeto.
Executar as primeiras análises do desenho e arquitetura, a partir das
informações encontradas no backlog do produto e backlog da iteração, já pode
direcionar a definição de requisitos de segurança, mapeando as entidades,
componentes ou dependências do sistema que ainda não foram identificadas durante a
apresentação do projeto. Entender quais as funcionalidades do sistema e as entidades
que irão interagir permitindo o especialista em segurança de software criar cenários
na visão de um usuário mal-intencionado em casos de abuso.
É importante ressaltar que as atividades de análise de vulnerabilidade devem
ser executadas periodicamente, com o objetivo de identificar possíveis bugs ou
configurações inseguras, que serão incluídos no backlog do produto.
A partir do backlog de produtos e backlog de iteração, as atividades de
segurança de software a serem executadas são: definição dos requisitos e premissas de
segurança para o projeto, análise de risco e modelagem de ameaças, e casos de abuso.

16. 4.2.2 Cerimônias
4.2.2.1 Primeira iteração ou apresentação do projeto
A primeira participação do profissional de segurança de software no projeto é
na apresentação do projeto ou primeira iteração. O entendimento e acompanhamento
do projeto são essenciais e, por isso, o profissional de segurança de software precisa
estar presente nesse momento.
Nessa primeira reunião, toda a equipe envolvida e interessada no projeto
estará presente. Dúvidas em relação ao desenho e arquitetura devem ser sanadas pelo
profissional de segurança de software, bem como a linguagem a ser utilizada, o
armazenamento de dados sensíveis, tipos de dados, autenticação, autorização, entre
outros recursos.
No primeiro contato com o projeto, o profissional de segurança de software já
deve orientar a todos os envolvidos e interessados, apresentando parte das premissas e
requisitos de segurança que se encaixam no contexto do projeto. Essas premissas e
requisitos de segurança devem permanecer devidamente documentados, juntamente
ao projeto, para servir de referência para todos os envolvidos.
No momento da primeira iteração ou apresentação do projeto, as atividades de
segurança de software a serem executadas são: definição dos requisitos e premissas de
segurança para o projeto, análise de risco e modelagem de ameaças, e casos de abuso.
4.2.2.2 Iteração
A cada iteração, novas funcionalidades e recursos são construídos e entregues
em produção de duas a quatro semanas. Toda a rapidez provida pelo SCRUM exige a
grande dedicação de um profissional de segurança de software. Sabendo disso, o
profissional de segurança precisa atuar de forma proativa, fazendo um bom trabalho
de documentação das premissas e requisitos de segurança, além de um desenho da
arquitetura muito bem definido.
Ao final de cada iteração o profissional de segurança de software e ou o
analista de qualidade deverá executar o teste de penetração e de segurança com o
objetivo de identificar problemas no software ainda não identificados, mitigados ou
problemas de configuração no ambiente de produção.
Todos os bugs ou falhas identificadas durante a iteração devem ser submetidos
a uma análise de risco pelo profissional de segurança de software, com o objetivo de
endereçar a resolução do problema de acordo com a criticidade. Em casos onde os
bugs ou falhas identificadas tenham risco baixo, o profissional de segurança poderá
endereçar as tarefas no backlog, solicitando a priorização ao dono do produto. Já, em
situações identificadas onde os bugs ou falhas são considerados críticos, a correção
deverá ocorrer o mais breve possível, notificando o dono do produto e, se for
necessário, deverá notificar a alta gerência em busca de priorização.
Algumas atividades são extremamente complexas, como a revisão de código,
pois exigem um volume maior de código do que apenas uma iteração geralmente pode

17. oferecer. Além disso, a revisão de código exige total dedicação de um profissional de
segurança de software, por isso, geralmente, é demandada quando o produto é
extremamente crítico para a empresa.
As atividades de segurança de software na iteração a serem executadas são:
testes de segurança baseados no risco, teste de penetração, operação de segurança e
revisão de código necessário e possível.
Dependendo da criticidade de cada vulnerabilidade identificada, o profissional
deverá recomendar uma mudança emergencial no software ou incluir a atividade no
backlog para a mitigação na próxima iteração ou quando priorizadas pelo dono do
produto em cada projeto.
4.2.2.3 Revisão e retrospectiva da iteração
Na reunião de revisão ou retrospectiva, os bugs ou falhas identificadas devem ser
apresentadas juntamente com a criticidade identificada, onde profissional deverá
incluir a atividade no backlog para a mitigação na próxima iteração, sugerindo a
priorização ao dono do produto.
4.3 Desafios
Com base na pesquisa desenvolvida para este trabalho e na vasta experiência
que adquiri durante todos estes anos de trabalho como profissional de segurança da
informação, apresento desafios que devem ser levados em consideração no momento.
4.3.1 Documentação
“A literatura de segurança de software começou a surgir na comunidade
científica, mas, em termos práticos, a prática de segurança de software continua em
sua infância.” (MCGRAW, 2006)
Ao iniciar o desenvolvimento deste trabalho, percebi a dificuldade de
encontrar documentação de qualidade referente à segurança de software junto a
metodologias de desenvolvimento ágil de software, sobretudo em português. Por este
motivo as poucas e principais referencias relacionadas a segurança de software de
qualidade foram utilizadas como base para o desenvolvimento deste trabalho.
4.3.2 Profissionais
MCGRAW (2006) explica que existem dois perfis profissionais de segurança
de software: o profissional chapéu preto (blackhat), que executa atividades
consideradas “destrutivas”, como atacar o software, testes de penetração, exploits,
entre outras; o chapéu branco (whitehat), para atividades consideradas “construtivas”,
atuando na definição de requisitos de segurança, funcionalidades de segurança,

18. arquitetura, análise de risco, revisão de código, entre outras. Os dois perfis de
profissionais são necessários, pois, enquanto um profissional de segurança de
software “ataca” em busca de bugs ou falhas, o outro faz análises no código, define
requisitos e a arquitetura. Existem situações em que os dois perfis atuam juntos,
como, por exemplo, no desenvolvimento de casos de abuso, análise de riscos, testes
de segurança, dentre outras atividades.
Atualmente, encontrar profissionais com conhecimentos e habilidades
relacionados à segurança de software é um grande desafio. (MCGRAW, 2006)
“Profissionais de segurança de redes não conhecem muito sobre software para
ser um bom profissional de segurança de software. Eles podem não carregar muitas
características sobre como a operação de um software funciona (além do que
desenvolvedores e arquitetos sabem), mas não é isso que precisamos para resolver o
problema de segurança de software. Profissionais operadores de segurança quase
nunca sabem nada sobre compiladores, frameworks, linguagem, arquitetura de
software, testes e outras coisas necessárias para ser um sólido profissional de
segurança de software.” (MCGRAW, 2006)
“O que fazer quando uma habilidade rara é necessária? Você converte essa habilidade
rara em um processo, que outros podem seguir, reforçando e disciplinando as pessoas
e verificando se está funcionando realmente.” (MCGRAW, 2006)
5. Conclusão
O assunto segurança de software no Brasil ainda é pouco explorado pelas
pessoas, empresas e mídia.
Com base nas pesquisas e experiência profissional, percebe-se que,
atualmente, existe grande dificuldade de contratar e manter um profissional que
possua conhecimentos e habilidades em segurança de software, disponível e dedicado
para um ou mais projetos de desenvolvimento de software dentro da empresa, devido
à escassez dessas habilidades e, também, o custo do projeto.
Quando a empresa dispõe de profissionais de segurança de software, a
integração das atividades e melhores práticas de segurança de software, junto ao
SCRUM, é possível e pouco complexa, permitindo um acompanhamento próximo dos
projetos possibilitando a construção de softwares mais seguros.
Conclui-se que, para que esta integração se torne viável, depois de aplicar as
melhores práticas de segurança de software, a equipe de segurança precisa mensurar
os benefícios dos controles definidos em tempo de construção. Acompanhar a redução
dos incidentes de segurança de software já pode contribuir para medir os resultados
do trabalho executado.
Sugere-se como contribuição acadêmica o estudo prático dos efeitos desta
integração, principalmente, a redução das vulnerabilidades identificadas. O estudo
periódico desses resultados possibilitará medir o resultado do trabalho realizado, a sua
qualidade e prover sugestão de melhorias e evolução.

19. 6. Referências
HOWARD, M. e LIPNER, S. The Security Development Lifecycle. Microsoft Press,
2006.
Manifesto para Desenvolvimento Ágil de Software. Disponível em:
<http://www.agilemanifesto.org/iso/ptbr/>. Acessado em 15 de maio de 2010.
MCGRAW, Gary. Software Security: Building Security In. Addison-Wesley, 2006.
OWASP Top Ten Most Critical Web Application Security Vulnerabilities. Disponível
em:<http://owasptop10.googlecode.com/files/OWASP Top 10 - 2010.pdf>.
Acessado em 15 de maio de 2010.
PRIES, Kim H. e QUIGLEY, Jon M. Scrum Project Management. CRC Press, 2010.
RICE, David. Geekonomics: The Real Cost of Insecure Software. Addison-Wesley
Professional, 2007.
SALTZER, J.H; SCHROEDER, M.D. The Protection of Information in Computer
Systems. Disponível em: <http://www.cs.virginia.edu/~evans/cs551/saltzer/>.
Acessado em 20 de abril de 2011.
SCHWABER, Ken. Agile Project Management with Scrum. Microsoft Press, 2004.
SEMOLA, Marcos. Gestão da Segurança da Informação. Campus Elsevier, 2002.
SWIDERSKI, Frank e SNYDER, Window. Threath Modeling. Microsoft Press, 2004.
SUTHERLAND, Jeff. Agile Principles and Values.
Disponível em: <http://msdn.microsoft.com/en-us/library/dd997578.aspx>. Acessado
em junho de 2011.
THOMAS, Steve. An Agile Comparison.
Disponível em: <http://www.balagan.org.uk/work/agile_comparison.htm>.
Acessado em 04 de junho de 2011