This series, and my blog, have moved! Check it out!
In the previous article in this series we discussed security requirements. When making any product, requirements are a must, and ensuring you have security built into your requirements from the beginning is the first step to ensure your final product will be of high quality. In this article we will discuss the next phase of the system development life cycle: Design.
As you recall, the system development life cycle generally looks like the image below:
System Development Life Cycle (SDLC)
When designing software applications, software architects not only need to worry about what the customer has asked for (business requirements), functional requirements (user requirements, scheduling, system requirements), but also non-functional requirements that are often taken for granted, such as usability, quality, and of course, security.
Top comments (1)
Thanks for the great list of secure design patterns and principles, @shehackspurple .
but, you've unfortunately played into a typical misconception: security is both functional and non-functional. You can hardly call a requirement for authentication and/or authorization non-functional, yes? these are most certainly functions that must be included, either by calling a service or building.
Remember: security is the cross-domain domain. security gets build North to South, East to West, front to back at many different levels and in overlapping ways. there are few 1:1 relations between defenses and attacks. we build the features that stakeholders require, along with defense that will stop, slow down, or at least identify attack attempts.