La seguridad en el ciclo de desarrollo de aplicaciones ya no es opcional, tiene que ser considerada como un elemento vital y crítico para cualquier tipo de producto ya sea una aplicación web, móvil, cliente, etc. sin ningún tipo de excusa.
Security in application development lifecycle is not optional, it has to be regarded as a vital and critical part of the development process to any kind of product either an application web, mobile, client, etc. without any excuse.
Es frecuente oír en la industria lo difícil y costoso que es aplicar seguridad en el desarrollo y muchas compañías lo utilizan como excusa para producir productos de baja calidad, que lo único que hace es perjudicar a la industria del software y todavía más a sus clientes exponiéndoles a los peligros de Internet.
It is common to hear in the industry how difficult and expensive is to apply security in the development process and many companies use it as an excuse to produce products of low quality, which makes it prejudicial to the software industry, and even more to customers exposing them to online dangers
Por supuesto que requiere un esfuerzo, dedicación, gasta recursos, modifica los paradigmas de desarrollo y además tiene un precio. Pero los verdaderos problemas son otros que parece que muy pocos entienden o quieren ver como son la falta de conocimientos en la materia o foco en el beneficio en vez del cliente.
Of course it requires effort, dedication, spends resources, modifies development paradigms and has a price tag. But the real problems are others that very few understand or want to see as the lack of knowledge in security development or focus on the revenue instead of the customer.
A continuación pongo una serie de puntos a modo de guía de supervivencia que debemos tener en cuenta a la hora de meternos en esta odisea.
- Decisión: Existen 4 marcos principales de seguridad en el desarrollo que las compañías pueden utilizar como son el SDL de Microsoft, CLASP de OWASP, Touchpoints de Cigital y el BSIMM como punto de partida. Debemos escoger el que mejor se adapte a nuestras necesidades y no al revés. No “Copy&Paste” de un marco sino adáptalo a ti.
- Selectivo: No es necesario aplicar el marco entero, solo seleccionar aquellas partes que nos interesen rebajando el tiempo de implantación y su coste. Por ejemplo Microsoft tiene 3 variantes: SDL para productos, SDL-LOB para aplicaciones de negocio y SDL-Agile para programación agile.
- Expertos: Si no tenemos las habilidades en casa debemos buscar ayuda fuera, aunque tenemos que tener cuidado ya que en el fondo muy poca gente tiene experiencia en este campo. Un punto de partida pueden ser las empresas que se han certificado en el SDL de Microsoft. Es conveniente contratar o formar a nuestro personal en este proceso de seguridad para tenerlo en casa.
- Formación: Una buena formación es el camino al éxito. Ofrecer diversos cursos de formación en función de la audiencia y los conocimientos que queremos que nuestros equipos obtengan. Existen diversas certificaciones que nos pueden ayudar como CSSLP del ISC2 y las certificaciones de desarrollo seguro de SANS.
- Paciencia: Microsoft es sin duda el líder en desarrollo seguro como se puede apreciar en estos últimos años (2008-2009), pero tenemos que tener en cuenta que llevan trabajando en este tema desde 2002 y con amplios recursos (humanos y económicos). Seguramente nosotros seremos más modestos que Microsoft, por lo que debemos ser más listos y eficientes.
- Realidad: Nuestro producto ganará en calidad pero en ningún momento debemos pensar que seremos capaces de evitar 100% los fallos de seguridad. El SDL de Microsoft lo define perfectamente: evitar todos los fallos posibles y mitigar aquellos que se escapen mediante otros mecanismos de seguridad (antivirus, cortafuegos, autenticación, criptografía, etc…).
- Unión: Debemos proteger la infraestructura y las aplicaciones (desarrollo) dentro de nuestra estrategia de seguridad. Por lo tanto estas 2 áreas están estrechamente ligadas y deben trabajar juntas sin ningún tipo de excusa. La seguridad es responsabilidad de todos en la organización.
- Sin Escape: Aplicar la seguridad tanto si desarrollamos en casa como si esta externalizado. En caso de externalización deberíamos aplicarles nuestros estándares de calidad. Igualmente si compramos productos de terceros debemos tener ciertas garantías que han seguido un proceso de desarrollo seguro.
- Evolución: Esto es un proceso y en continua evolución. Nuestro marco de seguridad no debe ser estático sino que debe adaptarse a los tiempos: tecnología, procesos y personas.
- Respuesta: Debemos estar preparados para lo peor por lo que es conveniente tener un plan de respuesta en caso de inseguridad en nuestra aplicación que contemple quien debe estar involucrado, como manejar la situación, comunicación, etc.
I have put a series of points as a survival guide that we must take into account to get involved in this odyssey.
- Decision: There are 4 main security development frameworks that companies can use such as the Microsoft SDL, OWASP CLASP, Cigital Touchpoints and BSIMM are good starting point. You should choose the best that fits your needs and not vice versa. Do not “Copy & paste” a framework but adapt it to yourself.
- Selective: No need to apply the entire; select only those parts that interest you to lowering deployment time and cost. For example Microsoft has 3 variants: SDL from products, SDL-LOB for business applications and SDL-agile for agile development.
- Subject Matter Experts: If we don’t have the skills in-house, we must seek help out but we must be careful because there are basically few people who have experience in this field. A starting point may be companies that have been certified in the Microsoft SDL. It is advisable to hire or train folks in-house to educate them in the security process.
- Training: Good training is the way to success. Offer various security courses depending on the audience and teach the knowledge that we want our staff to obtain. There are various certifications that can help us as the ISC2 CSSLP and SANS secure development certifications.
- Patience: Microsoft is undoubtedly the leader in secure development as seen in recent years (2009 – 2010) but we have to take into account that they been working on this subject since 2002 with extensive resources (human and financial). We will certainly be more modest than Microsoft so we must be smart and more efficient.
- Reality: Our product will win in quality but at any time we have to think we will not be able to achieve 100% security. Microsoft SDL defines it perfectly: avoid all possible failures and mitigate those that slip through other security mechanisms (anti-virus, firewall, authentication, cryptography, etc…).
- Union: We must protect the infrastructure and applications (development) within our security strategy. Therefore these 2 areas are closely linked and must work together without any excuse. Security is the responsibility of the entire organization.
- No escape: Apply security in the develop lifecycle in-house, same as if externalized. Our quality standards should apply in the case of outsourcing. Also if we buy third party products we must have certain guarantees that they have followed a secure development process.
- Evolution: This is a process in constant evolution. Our security framework should not be static but it must change with the times: technology, processes and people.
- Response: We must be prepared for the worst so it is convenient to have a response plan in case of a security compromise in our application that includes who should be involved, how to handle the situation, communication, etc.
Este tema es muy amplio pero espero que el post ayude a enfocar la dirección y seas capaz de implantar un proceso adecuado para tu organización.
¿En qué situación se encuentra tu organización (perdidos, inicio, en desarrollo, implantado) y éxito o fracaso?
This topic is very broad, but I hope the post helps focus in the right direction and you’re able to implement an appropriate process for your organization.
What’s the current status in your organization (completely lost, starting, in progress, implanted) and success or failure?
— Simon Roses Femerling
