My friend Randy Marchany tweeted a link to an article “Millennials Value Speed Over Security, Says Survey” that started me thinking about the apparent conflict between speed and security. If you google “Agile software development,” you will see a Wikipedia page, which extensively covers the topic.
“Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing,[1] cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.[2] Agile itself has never defined any specific methods to achieve this, but many have grown up as a result and have been recognized as being ‘Agile’.”
The interesting thing is, if you do a search on that entry for the word “security,” you will find that it is mentioned only once, under the section Regulated Domains. The section per the following consists of the areas where “agile development” is not appropriate:
“Agile methods were initially seen as best suitable for non-critical software projects, thereby excluded from use in regulated domains such as medical devices, pharmaceutical, financial, nuclear systems, automotive, and avionics sectors, etc. However, in the last several years, there have been several initiatives for the adaptation of agile methods for these domains.[64][65][66]
There are numerous standards that may apply in regulated domains, including ISO 26262, ISO 9000, ISO 9001, and ISO/IEC 15504. A number of key concerns are of particular importance in regulated domains which may conflict with the use of agile methods:[64]
- Quality Assurance (QA): Systematic and inherent quality management underpinning a controlled professional process and reliability and correctness of product.
- Safety and Security: Formal planning and risk management to mitigate safety risks for users and securely protecting users from unintentional and malicious misuse.
- Traceability: Documentation providing auditable evidence of regulatory compliance and facilitating traceability and investigation of problems.
- Verification and Validation (V&V): Embedded throughout the software development process (e.g. user requirements specification, functional specification, design specification, code review, unit tests, integration tests, system tests).”
I am not interested in becoming the security guy who always says NO, but sometimes you just need to think long and hard about exactly where you are going and what will happen when you get there. The interesting connection between the article and Agile software is the dates – it appears that the same millennials who value speed over security are responsible for Agile development, which is not surprising when you think about it.
As someone who has been in this industry for over 40 years, I can say from experience that it is incredibly easy to make a very small mistake in a program and create a very large security risk. Show me a person who never takes shortcuts when writing a program and I will show you an old guy (in this context, somewhere north of 35), or someone who has been burned before.
What scares me about this is that The Business has latched onto this Agile development as a way of boosting the bottom line – get the apps out there faster and we can make more money. I am afraid that some of them may have missed the section on where Agile is inappropriate.
This brings me to the point of my tale: We need to be the champions of automation of security. It is essential that the culture of security be baked into the SDLC and that we make sure that all of the developers out there understand that while it is great to be fast, the bad guys are faster. If there is a vulnerability in the product, the bad guys will find it.
When we stop doing security, people will get hurt.
It’s not the speed that kills, it’s the sudden stops.