In linguistics, there are two opposed philosophies of language: prescriptive and descriptive:
- Prescriptivists like to see a language as a collection of rules, the breach of which is improper at best. While they acknowledge that language changes, that change is seen as a slow shift in accepted rules.
- Descriptivists, on the other hand, see language as a living organism. While it follows rules, those rules constantly evolve and change. Linguists can only map and catalog these changes- without any hope of “catching up” to the current state.
Practical instruction in proper use of language requires a little of both philosophies. Lists of rules are not extremely useful to a writer, however some basic rules are essential in order to establish a formal tone or write for a broad audience. At the same time, a good writer must also have an understanding of language as it is, or risk being inauthentic. I see application security much in the same light. Most Security Professionals are planted pretty firmly in the Prescriptivist camp. There is a pervasive belief that what is needed to get developers to write secure code is a clear and complete set of requirements- in other words, a list of "do this, and don't do that". I am certainly not one to discount the need for good security requirements, but I do think the application security field could use a healthy dose of Descriptivism. Both business needs and security issues are, like language, a mix of “old and stable” with “new and fluid”. Prescriptive security requirements let us encapsulate the old and stable, making it as easy as possible to deal with. Descriptive security requirements allow us to acknowledge and respond to the new and fluid. Combining these approaches gives developers the ability to focus on the business problems that form the core of their job, but still inserts continuous security assurance into the development process. Of course, adding Descriptivism into application security requires education for all parties:
- Developers must have some level of security knowledge (akin to what's needed for other aspects of quality, like performance or usability)
- Architects must learn how to design for security
- Managers and project managers must know how to plan for and prioritize security assurance activities.
When these educational goals are met, organizations are capable of producing software with robust security – as their customers, stockholders, and regulators demand – while still being an agile competitor.
