In an ideal world, everyone would build applications with a software development lifecycle (SDLC) that considers security at every step.
The security and regulatory space of the application would be understood. The application’s design and requirements would be vetted for threats and vulnerabilities. Secure code reviews would be conducted on critical parts of the codebase. Deployment pipelines would dynamically and statically test code while also running security checks on the dependency chain.
Finally, rigorous manual testing, using a standard like OWASP’s Testing Guide, would help ensure the application was as secure as possible before going to a controlled release where detailed documentation outlines how to properly secure and use the application. In this world, “Secure by Design” and “Security is in our DNA” would not be marketing terms but would be reality.
Unfortunately, the world we live in makes this a difficult reality to achieve. In our world, security competes with “time to market” and “killer features."
So while there are resources from ISO, NIST, and others that give us guidance and guardrails on getting to our security goal, they also offer a steep learning curve and considerable time to implement. Therefore rather than rolling out security, most development teams put it off until the next release.
Needless to say, delaying adopting a secure SDLC comes at a price. According to one report, 77.5 days was the average time required to close a security vulnerability in a web application.¹ That is a steep price to pay for not catching an issue before it leaves development. So while the wholesale adoption of a security framework may be out of your reach, it does not mean you can afford to put off security.
The trick is finding small, practical wins that you can act on immediately. Fortunately, there are beneficial practices that are achievable even on the tightest of timelines and the slimmest of budgets.
Now I would like to introduce Security the Elephant. Security is a special elephant that, luckily for us, does not have to be eaten in one bite.²
Over the next few short posts, my goal is to outline a few simple security practices that can be easily implemented at little cost of time or money. While no single change will be monumental in and of itself, taken as a whole, the changes will add up to make your application and development process more secure.
Misuse Stories aka Abuse Stories
First up, I would like to discuss Misuse Stories — also known as Abuse Stories.
By now everyone is familiar with User Stories. At their simplest User Stories document the requirements of an application by stating in plain language how a user of a certain type will interact with the application.
Examples might be “Users will provide username and password to log into the application” or “Authenticated Administrators can grant any user admin privileges”. These are the stories that represent the happy path in the application. Misuse Stories are the evil twins of User Stories.
They are the Danny Devito to User Stories’ Arnold Schwarzenegger.
Like normal User Stories, they tell how a certain type of user might interact with the application. However, unlike normal User Stories, the types of users that make up Misuse Stories are either not nice or not very careful.
Misuse Stories typically center on the actions of “Curious Users,” “Malicious Hackers,” “Disgruntled Employees,” or “Interns." These users carry out all types of untoward acts upon the application or its environment. They might “stuff credentials,” “brute force,” “steal API keys,” or “leave S3 buckets open to the world.”
Misuse Stories are written by the development team and not stakeholders. Therefore, Misuse Stories should be created during the iteration when a User Story is pulled from the board.
If you want to get started immediately with Misuse Stories, during your next iteration, when you pull a story, brainstorm and record as many Misuse Stories as you can that surround it.
Taking “Users will provide username and password to log into the application” as an example, a brainstorming session might come up with the following Misuse Stories:
- A Malicious Hacker attempts to brute force the password of known usernames
- A Curious User attempts to use leaked credentials from a published compromise of another website to attempt login
- A Malicious Hacker steals credentials from the network
Even if those were the only stories that the team came up with, there is still a wealth of data there if they are used properly. Again, keeping it simple, suppose that when work began on the story the developer and the tester discussed how to mitigate the threats the Misuse Stories presented. Such a discussion might yield the following requirements:
- Require complex passwords
- Disallow the use of the last 10 passwords
- Lock account after 3 retries
- Ensure that vulnerable versions of TLS are disabled on the web server
- Use generic error messages on login failure that do not reveal the username
Now the developer can begin coding with these requirements in mind. Furthermore, automated tests can be written to capture the requirement ensuring compliance in future releases.
Hopefully, you agree that a practice like this will not add too much extra time to your development cycle and that what time is spent would be worthwhile. Even a simple example like this yielded good results. Imagine what a real brainstorming session with team members intimate with the application and environment would come up with. The best part is that exercises like this get easier the more you do them.
First, the team will get better the more they practice. Second, you will find that you can build a catalogue of Misuse Stories to draw from as many different applications share similar features.
Eventually you may find this practice is too simplistic and want to move on to formal Threat Modeling. If so, that is great. There are many great Threat Modeling frameworks to choose from when you are ready.
Until that time comes though, do not be afraid to take a bite of the elephant and to start simple with Misuse Stories.
¹ https://www.edgescan.com/wp-content/uploads/2019/02/edgescan-Vulnerability-Stats-Report-2019.pdf
² Vegan readers are invited to imagine Security as a Tofelephant
