It’s not immediately clear to me how I can connect all of the assigned articles, but I’ll give it a shot! So most of the articles discussed emerging security concerns that probably result from developers simply overlooking security concerns. Security researchers showed that the Tire Pressure Monitoring System now mandated by law allows interlopers to sniff out, decode, and even spoof unsecured signals being sent from the tire pressure sensors to the car’s main computer. The vulnerabilities with the Automated Meter Readers and the myriad internet of things security issues in automated home devices seem to run along a similar vein. Signals sent over wireless networks are vulnerable, because developers didn’t build in any substantial security features.
While it’s useful for governments to hold companies accountable for these vulnerable products that they are producing, as ours is attempting to do with the SPY Car Act of 2015, legislation is a sloooow process. Years go by between the time that a security threat is installed in a car, a home security system, a refrigerator, etc., the time that researchers identify the vulnerability, and the time that governments act to correct the problem. Meanwhile, our lives are being opened up to hackers in shocking and consequential ways.
In come the oddball articles that don’t directly deal with security threats but that I think lie at the heart of the issue. If legislating these security problems is too slow a process, which it is, then developers must do a better job of designing secure products, especially when safety and privacy are at stake. One problem for developers is that there are so many considerations when developing even the simplest systems and so little time and money to thoroughly develop and completely meet all of the system specifications. There are too many issues to try to keep track of, and, given our limited capacity for short-term memory and juggling multiple different items in our heads, it is essential that there is a reliable development process to compensate for our limited short-term memories.
Software engineering principles are critical for achieving a reliable, dependable, and ultimately trustworthy software system, but it’s often hard to apply these high-level principles in daily life as a programmer. It’s doubly hard when a programmer is strapped for time and held to demanding timelines. Test-driven developement (TDD) is a methodology that facilitates thorough system specification and accomplishes much of the low-level testing that needs to happen throughout the design process, especially early on. TDD practioners argue that the methodology scales very well and complements popular agile processes like Agile Model-Driven Development. There are many nuances to TDD that I think will take awhile for me to grasp, but the point is that developers must have a systematic process for creating trustworthy code with all considerations, including security, at the forefront. I can imagine that an excited and intrepid programmer can’t wait to hook an oven up to a mobile app, if that’s his or her sort of thing, so I can also imagine that it takes a disciplined process to force that programmer to consider the more boring but essential issues of safety and security.
As a side note, I was listening to a really interesting interview on the Ezra Klein show with Stewart Butterfield, and toward the end they were discussing the difference between exercising discipline in the moment and building disciplined routines and systems into place for the times that you don’t have the will to be disciplined. I think TDD sounds like a really solid system for ensuring that development discipline is there even when the programmer is trying to jump forward quickly and perhaps recklessly.