Secure Software Design and Development
Secure software design at first glace seems pretty simple, the software is either secure or its not. Unfortunately, is not that simple or straightforward as you can see below in the final papers written by myself and a team of students in our CSOL 560 course. Given how quickly software development is evolving, its extremely important to stay vigilante with updated security measures related to each piece of your software. We sought to keep that in mind as we created a System Test Plan for a fictitious companies reporting and alerts engine project we were hired to complete.
CSOL 560 Course Reflections
Having utilized System Test Plan’s in my real-world career they were not a new concept for me. That said, I have never had to write one. Learning how to properly create this test plan for a reporting and alerts engine was an invaluable learning experience. As these plans tend to be very detailed focused and layout the technical requirements to execute said plan made for countless reviews as a group throughout the course. These reviews we had as a group were not unlike ones you may be apart of in the real world as most companies follow some form of review and release cycle of software and documentation. This allowed us to pull knowledge from each other’s past experiences to better articulate the requirements for our test plan. Setting deadlines for group and weekly meetings to review and edit the plan made this course one of the most engaging out of the entire program. Another key component when looking at Secure Software Design and Development are the ethical considerations of what is and isn’t included in the software design life-cycle.
What do I mean by that? Well an often-used analogy would be looking at how car manufactures decide when and where to incorporate safety designs in a vehicle. Just 20 years ago vehicles didn’t have airbags or safety glass. One could say “back in the day” they didn’t have the technology to incorporate those features at the time. But more realistically those features come with an added cost and could cause automakers to lose profit. This is true with software design as well. Adding security features to software can often times increase the cost of development. Much like the automobile manufacturing, software design continues to advance and business goals shift. Sadly, only after higher death tolls in vehicular collisions, or in the case of software, data breaches and exposure of Personally Identifiable Information (PII) did we begin to consider the importance of safety and security over profitability.
Considering the above, the CSOL 560 course taught be that we should know somebody (attacker) is out to get someone at any given time and utilize that mindset in creation of a test plan by thinking outside the box. To be mindful that software developers may have the technical understanding of how someone could abuse their software, but not necessarily other means of exploiting it. Also, when testing to understand even the smallest of vulnerabilities can snowball upon others throughout the system. Lastly, when developing software, do so for posterity and not profitability.
What do I mean by that? Well an often-used analogy would be looking at how car manufactures decide when and where to incorporate safety designs in a vehicle. Just 20 years ago vehicles didn’t have airbags or safety glass. One could say “back in the day” they didn’t have the technology to incorporate those features at the time. But more realistically those features come with an added cost and could cause automakers to lose profit. This is true with software design as well. Adding security features to software can often times increase the cost of development. Much like the automobile manufacturing, software design continues to advance and business goals shift. Sadly, only after higher death tolls in vehicular collisions, or in the case of software, data breaches and exposure of Personally Identifiable Information (PII) did we begin to consider the importance of safety and security over profitability.
Considering the above, the CSOL 560 course taught be that we should know somebody (attacker) is out to get someone at any given time and utilize that mindset in creation of a test plan by thinking outside the box. To be mindful that software developers may have the technical understanding of how someone could abuse their software, but not necessarily other means of exploiting it. Also, when testing to understand even the smallest of vulnerabilities can snowball upon others throughout the system. Lastly, when developing software, do so for posterity and not profitability.