Your SlideShare is downloading. ×
  • Like
Artigo - Segurança no desenvolvimento de sistemas com metodologia ágil SCRUM
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Artigo - Segurança no desenvolvimento de sistemas com metodologia ágil SCRUM

  • 4,496 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Olá parabéns pelo artigo, só tenho uma dúvida, quero referenciar seu artigo ele foi publicado em algum evento?
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
4,496
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
214
Comments
1
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 softwaree, consequentemente, as organizações e usuários em grande risco. (MCGRAW, 2006) O acompanhamento dessa evolução da Internet permitiu-nos desenvolvernovos recursos para controles de segurança e de privacidade. Mesmo com estesdiversos recursos e controles sofisticados na infraestrutura de redes e junto ao usuáriofinal, o software sempre foi e será o principal vetor de ataque. Atualmente, esse cenário se torna cada vez mais complexo, pois apossibilidade de integração e de acoplamento de novos recursos aos softwares,geralmente chamados de extensões, afeta negativamente a sua segurança, aumentandoo 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 dainformaçã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 dasegurança da informação, atividades e melhores práticas de segurança de softwarejunto ao modelo ágil de desenvolvimento de software, o SCRUM. Enfim, O estudo se justifica uma vez que, atualmente, o software é a principalsuperfície de ataque, Como tal, deve ser eficientemente planejado, executado econtrolado 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 edisponibilidade das informações, além de garantir a conformidade com a legislaçãovigente e a continuidade dos negócios. De forma mais ampla, pode-se definir comoprática de gestão de riscos e de incidentes evitar o comprometimento dos trêsprincipais conceitos da segurança, descritos abaixo: Confidencialidade é o conceito que define que toda informação deve serprotegida de forma que o acesso não autorizado não seja permitido. Integridade é o conceito que define que toda a informação deve ser mantidada mesma forma que foi disponibilizada, visando à proteção contra quaisqueralterações. Disponibilidade é o conceito que define que toda informação disponibilizadapor um individuo ou instituição deve estar acessível no momento em que houvernecessidade para qualquer finalidade. Com base nos conceitos apresentdos acima a noção de risco de segurança desoftware tem se tornado de conhecimento comum, mas os programadores, arquitetos ecientistas da computação só agora começaram a estudar sistematicamente como criarum software seguro. (MCGRAW, 2006) Criação de um sistema seguro requer um processo de segurança integrado nociclo de desenvolvimento do software. Este processo de segurança de software devecobrir desde a arquitetura até a implantação do projeto e, principalmente, definir opapel dos profissionais de segurança de software dentro do ciclo de desenvolvimentode software, de modo que o processo seja aplicado de forma eficaz. (SWIDERSKI eSNYDER, 2004)2.1 Desenho de Segurança Entender os princípios de proteção da informação é essencial para construir odesenho da arquitetura de um software de forma segura. De modo que a dificuldadede construir softwares seguros está relacionada com a qualidade negativa dasdefinições, premissas e requisitos de segurança apresentados. (SALTZER eSCHROEDER, 1975) Softwares complexos são, provavelmente, menos seguros do que o softwaremais 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 economiade mecanismos. (SCHWABER, 2006) Todo o texto relacionado a desenho de segurança é referência obtida nodocumento desenvolvido por SALTZER e SCHROEDER, 1975, que descreve osprincí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, permitindoviolações de segurança dificilmente detectadas, pois o sistema é utilizadonormalmente. O princípio da economia de mecanismos é bem conhecido e se aplica aqualquer aspecto de um sistema, onde a recomendação é manter o desenho dosoftware pequeno e simples o quanto. Em casos onde há necessidade de executar a revisão de código fonte, oprincípio da economia de mecanismos facilita muito o trabalho do especialista desegurança de software responsável por essa atividade.2.1.2 Mediação completa Todas as requisições devem ser verificadas, analisadas e autorizadas entreobjetos e dependências do software. O princípio da mediação diz que todo acesso aum 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íveispara avaliação dos clientes. Com isso, os usuários mais exigentes e devidamenteautorizados poderiam analisar, entender e se convencer de que o sistema atenderealmente à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 empotencial, permitindo que todos possam fazer revisões e identificar possíveisproblemas.2.1.4 Separação de privilégios O princípio de separação de privilégios busca definir privilégios para acessoao 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 omínimo de privilégios necessários. O principio de privilégio mínimo busca limitar operigo. Reduzindo os privilégios do software ou usuário a um escopo bem específicopode 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 demecanismos compartilhados para mais de um ou todos os clientes que utilizam osoftware.2.1.7 Usabilidade É essencial que toda a interface seja de fácil manuseio, facilite o aprendizadodos usuários, tornando assim o sistema menos suscetível a erros. O princípio dausabilidade diz que, se a aprendizagem da atividade executada pelos clientes está deacordo com as proteções construídas para o sistema, então os erros serãominimizados.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 modelagemde ameaças e análise de risco. (MCGRAW, 2006) O principal resultado da modelagem de ameaça é um documento oudocumentos que descrevem em alto nível o desenho da aplicação, lista de recursosque requerem proteção, identificação e categorização das ameaças e plano demitigação. (HOWARD e LIPNER, 2006) A modelagem de ameaças pode, também, ajudar a executar atividades derevisão de código e a construção de testes de penetração. Abaixo, apresento asatividades relacionadas à modelagem de ameaças, utilizando como principalreferência os livros HOWARD e LIPNER (2006) e, também, SWIDERSKI eSNYDER (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 casoocorra algum incidente. Na criação dos cenários, é importante verificar se o usuáriodeve 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 umsistema operacional, utiliza servidor web, serviço de banco de dados ou frameworksde aplicação. Devem ser identificadas e listadas todas estas dependências,considerando que o sistema operacional e os serviços estejam com as configuraçõesseguras.2.2.3 Determinar as premissas de segurança Premissas ou requisitos de segurança devem permanecer documentados edisponíveis aos programadores como referentes para a construção de um softwareseguro. Pontualmente, cada projeto possui requisitos mais específicos e nessemomento, devem-se definir quais as premissas de segurança para esse ambienteoperacional, como, por exemplo, segregação de ambientes lógicos e físicos;arquitetura de autenticação, autorização e auditoria; utilização de um frameworkpadrão; arquitetura para armazenamento centralizado de logs e formato específicopara envio.2.2.4 Determinar tipos de ameaças A gigante de software Microsoft utiliza uma taxonomia de ameaças, criada ebatizada por ela, chamada STRIDE (Spoofing, Tampering, Repúdio, Exposição deinformaçõ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 umusuário tentar se passar pelo presidente de uma empresa, uma biblioteca dinâmica quefoi 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 emcódigo fonte.
  • 6. 2.2.4.3 Repúdio Consistem em repúdio, uma ação executada que não pode identificar o realindividuo 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ãopode 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ãodeveriam ter acesso a elas. Imagine um arquivo confidencial sendo lido por umapessoa 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 tornarindisponível. De alguns anos pra cá, os ataques de negação de serviço têm ocorrido apartir de diversas origens, sendo conhecidos como ataque de negação de serviçodistribuí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 entidadesexternas que interagirão com o software, os processos, o fluxo de dados e onde osdados serão armazenados. A principal contribuição deste processo é uma matriz que detalha os tipos deameaças relacionadas às entidades externas e suas interações junto ao software, osprocessos, 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 doataque 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 paraidentificar 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, tentandoreduzir ou eliminar o risco de uma ameaça. Abaixo, a descrição das estratégias demitigação. A estratégia para mitigar o risco é não fazer nada que possa ser uma estratégiavá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 oufuncionalidade, garantindo que o risco identificado seja levado ao menor nível. Estamitigaçã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 dorisco, garantindo que os recursos ou funcionalidades afetadas pelo risco sejammitigados ou permaneçam desligadas. Em outros casos, notificar o usuário pode ser uma alternativa para algumasameaças, lembrando que somente notificar o usuário, informando que a ameaçaexiste, pode não ser a melhor decisão.2.3 OWASP TOP 10 O The Open Web Application Security Project (OWASP) é uma organizaçãomundial sem fins lucrativos, focada na melhoria da segurança do software, oferece,gratuitamente, para toda a sociedade diversos projetos de segurança de software, ondeo documento mais conhecido e que mais contribui para este trabalho é o OWASP Top10.2.3.1 A1 – Injeção Falhas de injeção de códigos são comuns em aplicações web, principalmente ainjeção de código SQL. Estas falhas ocorrem quando dados fornecidos nos campos deentrada são interpretados como parte de comandos ou consultas, permitindo que umatacante acesse a base de dados da aplicação e execute consultas arbitrárias. Paramitigar essa vulnerabilidade é recomendável que todas as informações enviadas àaplicação sejam validadas, tratando possíveis erros e exceções, evitando a exposiçãode 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 dousuário e os envia de volta ao navegador sem realizar validação ou codificação dosdados, permitindo a execução de códigos/scripts arbitrários. Para mitigar estavulnerabilidade é 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íticospara a segurança de aplicações Web. Apesar disso, é comum encontrar falhas nessesmecanismos, que podem colocar em risco as credenciais utilizadas pelos usuários ouidentificador de sessão (session ID). Burlando os mecanismos de autenticação e degerenciamento, é possível roubar a sessão do usuário obtendo acesso privilegiado semautorização, junto à aplicação. Para mitigar esta vulnerabilidade, é recomendável nãoutilizar identificadores de sessão pré-definidos ou reutilizados, eliminar ou invalidar asessão após a utilização, garantir que as funções de logout e timeout foramimplementadas corretamente.2.3.4 A4 - Referência insegura a objetos Ocorre quando um objeto é acessado de forma direta, sem utilizar qualquertipo de proteção. Objeto, neste caso, pode ser entendido como um arquivo de sistemaou banco de dados, diretórios ou chaves, utilizadas em URLs ou como parâmetros deformulário. Para mitigar esta vulnerabilidade, é necessário verificar a integridade dosobjetos, garantir que o acesso ao objeto está autorizado, garantir que os objetos nãoestão expostos.2.3.5 A5 - Cross Site Request Forgery (CSRF) O ataque consiste em forçar a vítima autenticada no sistema a enviarrequisições a uma aplicação vulnerável, realizando operações sem o conhecimento daví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çõesenviadas à aplicação; utilizar tokens randômicos para cada requisição à aplicação comsessão de autenticação estabelecida; não utilizar a URL para realizar requisições comdados 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 deatualizações, ou senhas padrão em ambiente de produção, por exemplo:
  • 9. Aplicação com usuário privilegiado, “admin” e senha “admin”. Banco dedados SQL Server, com usuário privilegiado “sa” e sem senha. Para mitigar esta vulnerabilidade, é recomendável que, durante odesenvolvimento da aplicação, deva-se garantir que todas as mensagens de errossejam tratadas corretamente, criando mensagens genéricas para serem apresentadasquando 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 teracesso, 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 deautorização definindo privilégios no acesso quando este recurso for possível e assimnão permitir o acesso de usuários não autorizado a arquivos controlados, deconfiguração, logs, etc.2.3.8 A8 - Armazenamento inseguro de criptografia Falhas na implementação de mecanismos de criptografia podem colocar emrisco as informações armazenadas. Podem ser consideradas vulnerabilidades: autilização de cifra “fraca”, tamanho de chave criptográfica inadequada ou erros aoutilizar cifra forte. Um atacante pode aproveitar essa vulnerabilidade para tentar obteracesso aos conteúdos e, também, a dados sensíveis da aplicação. Para mitigar esta vulnerabilidade, não utilize algoritmos conhecidamentefracos, como: RC3, RC4 e MD5. Nunca utilize canais inseguros para a transmissãodas chaves de criptografia. O BASE64 não é algoritmo de criptografia ou função dehash. Não construa algoritmos de criptografia próprios em produção e garanta quedados 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 utilizandoSSL/TLS. Caso contrário, serão enviadas em texto plano e podem ser capturadas porpessoas mal-intencionadas. Um atacante pode utilizar um analisador de pacotes e obter acesso ainformações privilegiadas, como cookies ou identificador de sessão, credenciais eoutras informações críticas para a empresa e negócios. Para mitigar esta vulnerabilidade, é recomendado utilizar TLS/SSL paraconexõ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 maneiracorreta.
  • 10. 2.3.10 A10 - Redirecionamento inseguro Possibilita encaminhar usuários a sites não desejados, os quais podem contercódigos maliciosos para roubar informações da sessão do usuário. Funções deredirecionamento sem a validação do destino. Para mitigar esta vulnerabilidade, é recomendado evitar a utilizaçãoredirecionamentos 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 destetrabalho, o livro Software Security: Building In é: “explorar e descrever um conjuntode 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 melhorespráticas de segurança de software ao SCRUM. Estas melhores práticas ou principaisatividades de segurança de software foram baseadas conforme a referência emMCGRAW (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 desegurança sob o código de um software, com o objetivo de buscar por padrões eregras conhecidas de bugs e, possivelmente, por falhas. Existem diversas maneiras de fazer a revisão de código, uma delas é a análisedo código fonte que pode ser feita de forma manual, consumindo muito tempo, etambém, de forma automática, a partir de ferramentas que verificam o código fontesem 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ódigoscompilados 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 dasatividades mais importantes para garantir a segurança de um software. Analisar asentidades que interagem com o sistema, os componentes, o fluxo de dados e onde osdados serão armazenados, sem dúvida, contribuem para mapear os riscos e descobrirmaneiras de mitigá-los. O modelo de modelagem de ameaças apresentadoanteriormente é 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émconhecidos como testes de penetração em aplicação, são úteis, principalmente, paraidentificar problemas no ambiente e de configuração do sistema. Os testes de penetração são executados através de ferramentas e exigem que oresponsável pelos testes tenha habilidades avançadas em relação à segurança desoftware. Atualmente, este é o principal recurso utilizado pelas empresas para avaliaçãodo software a ser instalado no ambiente de produção, não garantindo que o softwarefoi 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á-losantes mesmo de o software estar pronto em um ambiente de produção. A grande diferença é que os testes podem ser executados em partes dosistema, como em componentes ou na integração deles, além de serem feitos usandoduas metodologias, teste de caixa branca e teste de caixa preta. A análise de risco desenvolvida previamente é essencial e deve direcionar aconstrução de casos de abuso. Os testes de segurança baseados em riscos, também, exigem que o responsávelpor 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, detalhandocomo 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 deuso 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 doprojeto 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 rugbypara 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 defuncionalidades bem definidas. Estas funcionalidades são reunidas e documentadasem uma lista de atividades chamada de backlog do produto, que pode ser atualizada epriorizada pelo dono do produto, de acordo com as necessidades e prioridades donegócio. O SCRUM não se concentra apenas em agregar valor ao negócio e sim emagregar o mais prioritário valor ao negócio, conforme definido pelo cliente e dono doproduto. (SCHWABER, 2004) Abaixo, descrevo informações relevantes, referentes a papéis eresponsabilidades, artefatos e cerimônias da metodologia ágil SCRUM.3.1 Papéis e Responsabilidades3.1.1 Dono do Produto O dono do produto é o profissional responsável pelo gerenciamento dobacklog 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 novosrecursos, priorizando as atividades de acordo com as necessidades da empresa e donegócio. (SCHWABER, 2004)3.1.2 Scrum Master O scrum master é o profissional responsável pelo processo do SCRUM, suacorreta implementação e maximização dos seus benefícios. O scrum master tem comoprincipal atividade remover qualquer possível impedimento para a entrega doobjetivo, garantindo que as metas e as atividades definidas e estimadas na reunião deplanejamento da iteração sejam entregues. (SCHWABER, 2004)3.1.3 Equipe No SCRUM, a equipe é autogerida, e cada um tem a responsabilidade por suasatividades e resultados. A equipe é formada por poucas pessoas com diferenteshabilidades, no máximo de 5 a 9 pessoas, necessárias para a execução das tarefas.
  • 13. 3.2 Artefatos3.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 doproduto que é definida pelo dono do produto, scrum master e toda a equipe durante areuniã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 quantidadede horas de trabalho restante ao longo da linha do tempo. (SCHWABER, 2004)2.3 Cerimônias3.3.1 Planejamento da Iteração Reunião entre a equipe o scrum master e o dono do produto para escolher emensurar 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 asua atividade para os outros integrantes, sinalizando qualquer possível impedimentoao scrum master para resolução das atividades. (SCHWABER, 2004) Diariamente, sempre no mesmo horário, a equipe se reúne com o scrummaster com o objetivo de remover rapidamente qualquer impedimento relacionado aodesenvolvimento do produto. Nessa reunião, cada membro da equipe deve respondera 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, ondea equipe apresenta ao dono do produto o que foi feito e entregue durante aquelaiteraçã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 aequipe 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 sejamintegradas ao SCRUM, é preciso, em primeiro lugar, apresentar e conscientizar todosos colaboradores, principalmente, os envolvidos e interessados na construção desoftware seguro, sobre os conceitos de segurança da informação e segurança desoftware, possivelmente, através de pequenos treinamentos a estes colaboradores. Neste capítulo, descrevo a maior contribuição proposta por este trabalho, aintegração dos conceitos de segurança da informação e as melhores práticas desegurança de software, junto ao modelo ágil de desenvolvimento de software, oSCRUM.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 aoscolaboradores de forma a incentivar uma visão crítica relacionada aos riscos dasegurança, gerando de forma proativa a construção de softwares seguros, atuando emprofundidade ou em outras diversas camadas e evitando incidentes oriundos de açõesinternas erradas ou possivelmente maliciosas.
  • 15. 4.2 Processo Quando o assunto é segurança da informação, é imprescindível ter o totalapoio da alta gerência, evitando que possíveis conflitos de interesses possam impedirque 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 eacessível por todos os colaboradores envolvidos e interessados no projeto. Umadocumentação clara, estando disponível, faz com que o profissional de segurançaesteja capacitado a desenvolver as primeiras analises do projeto, antes mesmo doprimeiro encontro com os outros integrantes do projeto. Conforme mencionado anteriormente, a proposta deste trabalho consiste emalinhar as melhores práticas de segurança de software junto ao SCRUM, mas, paraisso é importante levar em consideração que a equipe de segurança de softwaregeralmente e reduzida e o tempo é muito curto para análises e entregas de novasfuncionalizadas em metodologias de desenvolvimento ágil.4.2.1 Artefatos4.2.1.1 Backlog do produto e backlog da iteração Nestas fases, o profissional de segurança de software deve analisar o backlogdo produto em busca de identificar possíveis ameaças, entender como funcionará oproduto desse projeto, criando cenários, definindo o desenho e a arquitetura, reunindoe alinhando as premissas de segurança com todos os envolvidos e interessados peloprojeto. Executar as primeiras análises do desenho e arquitetura, a partir dasinformações encontradas no backlog do produto e backlog da iteração, já podedirecionar a definição de requisitos de segurança, mapeando as entidades,componentes ou dependências do sistema que ainda não foram identificadas durante aapresentação do projeto. Entender quais as funcionalidades do sistema e as entidadesque irão interagir permitindo o especialista em segurança de software criar cenáriosna visão de um usuário mal-intencionado em casos de abuso. É importante ressaltar que as atividades de análise de vulnerabilidade devemser executadas periodicamente, com o objetivo de identificar possíveis bugs ouconfigurações inseguras, que serão incluídos no backlog do produto. A partir do backlog de produtos e backlog de iteração, as atividades desegurança de software a serem executadas são: definição dos requisitos e premissas desegurança para o projeto, análise de risco e modelagem de ameaças, e casos de abuso.
  • 16. 4.2.2 Cerimônias4.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 acompanhamentodo projeto são essenciais e, por isso, o profissional de segurança de software precisaestar presente nesse momento. Nessa primeira reunião, toda a equipe envolvida e interessada no projetoestará presente. Dúvidas em relação ao desenho e arquitetura devem ser sanadas peloprofissional de segurança de software, bem como a linguagem a ser utilizada, oarmazenamento de dados sensíveis, tipos de dados, autenticação, autorização, entreoutros 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 erequisitos de segurança que se encaixam no contexto do projeto. Essas premissas erequisitos de segurança devem permanecer devidamente documentados, juntamenteao projeto, para servir de referência para todos os envolvidos. No momento da primeira iteração ou apresentação do projeto, as atividades desegurança de software a serem executadas são: definição dos requisitos e premissas deseguranç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 entreguesem produção de duas a quatro semanas. Toda a rapidez provida pelo SCRUM exige agrande dedicação de um profissional de segurança de software. Sabendo disso, oprofissional de segurança precisa atuar de forma proativa, fazendo um bom trabalhode documentação das premissas e requisitos de segurança, além de um desenho daarquitetura muito bem definido. Ao final de cada iteração o profissional de segurança de software e ou oanalista de qualidade deverá executar o teste de penetração e de segurança com oobjetivo de identificar problemas no software ainda não identificados, mitigados ouproblemas de configuração no ambiente de produção. Todos os bugs ou falhas identificadas durante a iteração devem ser submetidosa uma análise de risco pelo profissional de segurança de software, com o objetivo deendereçar a resolução do problema de acordo com a criticidade. Em casos onde osbugs 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á, emsituações identificadas onde os bugs ou falhas são considerados críticos, a correçãodeverá ocorrer o mais breve possível, notificando o dono do produto e, se fornecessá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 deseguranç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 erevisão de código necessário e possível. Dependendo da criticidade de cada vulnerabilidade identificada, o profissionaldeverá recomendar uma mudança emergencial no software ou incluir a atividade nobacklog para a mitigação na próxima iteração ou quando priorizadas pelo dono doproduto em cada projeto.4.2.2.3 Revisão e retrospectiva da iteraçãoNa reunião de revisão ou retrospectiva, os bugs ou falhas identificadas devem serapresentadas juntamente com a criticidade identificada, onde profissional deveráincluir a atividade no backlog para a mitigação na próxima iteração, sugerindo apriorização ao dono do produto.4.3 Desafios Com base na pesquisa desenvolvida para este trabalho e na vasta experiênciaque adquiri durante todos estes anos de trabalho como profissional de segurança dainformaçã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 comunidadecientífica, mas, em termos práticos, a prática de segurança de software continua emsua infância.” (MCGRAW, 2006) Ao iniciar o desenvolvimento deste trabalho, percebi a dificuldade deencontrar documentação de qualidade referente à segurança de software junto ametodologias de desenvolvimento ágil de software, sobretudo em português. Por estemotivo as poucas e principais referencias relacionadas a segurança de software dequalidade foram utilizadas como base para o desenvolvimento deste trabalho.4.3.2 Profissionais MCGRAW (2006) explica que existem dois perfis profissionais de segurançade software: o profissional chapéu preto (blackhat), que executa atividadesconsideradas “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 deprofissionais são necessários, pois, enquanto um profissional de segurança desoftware “ataca” em busca de bugs ou falhas, o outro faz análises no código, definerequisitos 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, testesde segurança, dentre outras atividades. Atualmente, encontrar profissionais com conhecimentos e habilidadesrelacionados à segurança de software é um grande desafio. (MCGRAW, 2006) “Profissionais de segurança de redes não conhecem muito sobre software paraser um bom profissional de segurança de software. Eles podem não carregar muitascaracterísticas sobre como a operação de um software funciona (além do quedesenvolvedores e arquitetos sabem), mas não é isso que precisamos para resolver oproblema de segurança de software. Profissionais operadores de segurança quasenunca sabem nada sobre compiladores, frameworks, linguagem, arquitetura desoftware, testes e outras coisas necessárias para ser um sólido profissional desegurança de software.” (MCGRAW, 2006)“O que fazer quando uma habilidade rara é necessária? Você converte essa habilidaderara em um processo, que outros podem seguir, reforçando e disciplinando as pessoase verificando se está funcionando realmente.” (MCGRAW, 2006)5. Conclusão O assunto segurança de software no Brasil ainda é pouco explorado pelaspessoas, 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 quepossua conhecimentos e habilidades em segurança de software, disponível e dedicadopara 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, aintegração das atividades e melhores práticas de segurança de software, junto aoSCRUM, é possível e pouco complexa, permitindo um acompanhamento próximo dosprojetos possibilitando a construção de softwares mais seguros. Conclui-se que, para que esta integração se torne viável, depois de aplicar asmelhores práticas de segurança de software, a equipe de segurança precisa mensuraros benefícios dos controles definidos em tempo de construção. Acompanhar a reduçãodos incidentes de segurança de software já pode contribuir para medir os resultadosdo trabalho executado. Sugere-se como contribuição acadêmica o estudo prático dos efeitos destaintegração, principalmente, a redução das vulnerabilidades identificadas. O estudoperiódico desses resultados possibilitará medir o resultado do trabalho realizado, a suaqualidade e prover sugestão de melhorias e evolução.
  • 19. 6. ReferênciasHOWARD, 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ívelem:<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-WesleyProfessional, 2007.SALTZER, J.H; SCHROEDER, M.D. The Protection of Information in ComputerSystems. 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>. Acessadoem 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