WIXLIB

09-11-2010First OWASP DAYThe OWASP FoundationChile 2010http://www.owasp.orgSeguridad en elCiclo de DesarrolloAlejandro Johannes M.Business AdvisorVice president Capítulo Chileno OWASPajohannesm@gmail.com (569)8 662 4049Temario OWASP Guide Evolución TI en las Organizaciones Capítulo: Principios de CodificaciónSegura en SDLC Contexto y referencias OWASP Modelo de Protección de la Información Principios para Aplicaciones Segurasdesde el Diseño Flujo Modelo Amenazas Ejemplos21

09-11-2010OWASP Guide Guía para construir aplicaciones y servicios WEBseguros Varios editores, autores, directores de proyecto (40aproximadamente.) Publicación gratuita y abierta a interesados enmejorar la seguridad de aplicaciones Conjunto de definiciones, alertas, vulnerabilidades ybuenas prácticas. No impone, pero sugiere Copyright 2002-2005. The Open Web Application SecurityProject (OWASP). Todos los derechos reservados. Se concedepermiso para copiar, distribuir y / o modificar este documentosiempre que se incluya este aviso de derechos de autor y semantenga la atribución a OWASP.Evolución de las TI en las OrganizacionesSERVICELEVELMANAGEMENTQUALITY &PQMVENDORS &OUTS.MGNTAPPLICATION HIT.MGNTClaramente una aplicación se encuentra en un entornoque corresponde a la realidad y nivel de madurez que tieneLa Empresa en sus procesos de negocio y NUITYPLANNINGPROBLEM RITY Nivel de MadurezEtapaInicialDefinirDondequieroEstar ?EtapaContagioEtapaDe MadurezEtapaDe IntegracionEtapaDe ControlCrecer en los Niveles deMadurez requieremayores niveles deinversión de lasorganizaciones en TI yaceptar que éstarepresenta un área desoporte estratégico alNegocioTiempo / VolúmenesRef.: Extacto de Richard Nolan, Profesor de la escuela de negocios de Harvard2

09-11-2010Capítulo: Principios de CodificaciónSegura en SDLC La elección de una metodología de desarrollo no es tan importante como el simplehecho de poseer una. El desarrollo Ad hoc no es lo suficiente estructurado para producir aplicacionesseguras. Elegir la metodología adecuada. Considerar: Complejidad: puede sobreburocratizar identificando demasiados roles diferentes Fuerte aceptación de diseño, testeo y documentación Espacios donde se puedan insertar controles de seguridad (tales como análisis de riesgo deamenazas, revisiones por parte de pares, revisiones de código, etc.) Que funcione para el tamaño y nivel de madurez de la organización Tenga potencial de reducir tasa actual de errores y de mejorar la productividad de losdesarrolladores.Contexto y Referencias OWASP Los principios de seguridad tales como confidencialidad, integridad, ydisponibilidad – aunque son importantes, amplios y vagos – no cambian OWASP propicia: Adoptar un Modelo de Riesgo de Amenazas: Microsoft / Trike / CVSS /AS4360 / y Octave Mejores prácticas de mercado: CobIT / ISO 27001 / ISO 17799 / PCI / SOX Una gestión organizacional que abogue por la seguridad Políticas de seguridad documentadas y apropiadamente basadas enestándares nacionales-internacionales Una metodología de desarrollo con adecuados puntos de control yactividades de seguridad Gestión segura de versiones y configuración Lograr un “SDL”: Security Development Lifecycle3

09-11-2010ROLES Y ACIÓNCIÓNSYSVALINDEPEN-BIBLIO-DIENTETECASDDMY MONITOREOUSERSACCESOSCLIENTACCESS SQLCONTROLUSUARIOS TROL DERECURSOS YVULNERABI-MONITOREOLIDADESPrincipios para AplicacionesSeguras desde el Diseño Análisis de Riesgos Identificación de amenazas, revisión de pares, revisiones de código, Fuerteaceptación de diseño, testeo, Ethical Hacking, documentación, etc Clasificación de Activos: La selección de controles sólo es posible después declasificar los datos a proteger tales como Datos, Código SW, Configuración FW Orientación arquitectura (p.ej. “la capa Web no debe llamar a la base de datosdirectamente”, Aislar Producción de Desarrollo con Firewall) Niveles mínimos de documentación requerida Requerimientos de testeo mandatorios (inspecciones, Ethical Hacking, comprobaren el tiempo Niveles mínimos de comentarios entre código y estilo de comentarios preferidos Manejo de excepciones Control de integridad del código fuente4

09-11-2010Principios para AplicacionesSeguras desde el Diseño La arquitectura de seguridad empieza el día en que se modelan los requisitos delnegocio, y no termina nunca hasta que la última copia de su aplicación es retirada Seguridad por defecto (p.ej. estructura passwords, valores sistemas, continuidadoperativa,.) Principio del mínimo privilegio Fallos de manera segura Los sistemas externos son inseguros: la confianza implícita de ejecutar sistemasexternos, no está garantizada Segregación de Funciones: Identificar funciones sensibles No confiar la seguridad en la oscuridad, sino hacer lo contrario Incorporar bitácoras: Logs, Journals, prender los Audit journals, y disponer de unmecanismo de su revisión. Principio de NO-RepudiaciónFlujo Modelo AmenazasEj.: Identificación yAutenticación / Reputación /Financiero / Privacidad /Garantías, SLA /Estándares / ContinuidadOperativa / MinimizarFraudes / etcIdentificarObjetivos ilidadesEj.: Disponibilidadoperativa / Hackers /Error digitación /Extracción Datos /Robo / Legales /Pérdida confidencialidEj.: Servidor /Lenguaje, MotorBdD, s.o. / Router,redes / Backups,Retención,Recuperación /Autenticación /RepairsDescomponerAplicaciónIdentificar yDocumentarAmenazas5

09-11-2010PLANIFICAR SEGÚN MODELO DE LOS PROCESOS DE SEGURIDADAdministración deProblemas eIncidentesSeguridadAdministraciónAcceso Red,Mail, InternetControlVulnerabilidadesy Alertas deMercadoControl deCambiosInforInformaciónRevisiónIndependiente raciónAcceso Físico yControlAmbientalUso dadOperativaVULNERABILIDADES Propietario no definido Clasificación ids por funciones Administración usuariosUSUARIOS(password default, grupos,accesos directos, expiración, idsprivilegiados) Programas con escalamientode privilegios Etc CONTROLES DE PROTECCIÓNEjemplo, Análisis de Protección : UsuariosACTIVOSDEINFORMACIÓN6

09-11-2010Ejemplo, Análisis de Protección : Accesos Procedimientos y metodología(nomenclatura, clasificación,control de cambios, privilegiousuarios, revisión journals) Datos de Producción noencriptados usados en Areas de ACCESOSDesarrollo, Testing u otros Cxs remotas, filtros, ftp, Userids privilegiados sin control,configuración Routers Tareas programadasdesprotegidas. Etc CONTROLES DE PROTECCIÓNVULNERABILIDADESACTIVOSDEINFORMACIÓNSe inicia y logra con el compromiso yresponsabilidad del Top Management7

09-11-20108

09-11-2010 3 Capítulo: Principios de Codificación Segura en SDLC La elección de una metodología de desarrollo no es tan importante como el simple hecho de poseer una. El desarrollo Ad hoc no es lo suficiente estructurado para producir aplicaciones seguras. Elegir la metodología adecuada. Considerar: Complejidad: puede sobreburocratizar identificando demasiados roles diferentes