Communications of the ACM
Go Static or Go Home
Credit: Michael Glenwood
Most current and historic problems in computer and network security boil down to a single observation: letting other people control our devices is bad for us. At another time, I will explain what I mean by "other people" and "bad." For the purpose of this article, I will focus entirely on what I mean by control. One way we lose control of our devices is to external distributed denial-of-service (DDoS) attacks, which fill a network with unwanted traffic, leaving no room for real ("wanted") traffic. Other forms of DDoS are similar—an attack by the Low Orbit Ion Cannon (LOIC), for example, might not totally fill up a network, but it can keep a Web server so busy answering useless attack requests the server cannot answer any useful customer requests. Either way, DDoS means outsiders are controlling our devices, and that is bad for us.
Surveillance, exfiltration, and other forms of privacy loss often take the form of malicious software or hardware (so, "malware") that somehow gets into your devices, adding features like reading your address book or monitoring your keystrokes and reporting that information to outsiders. Malware providers often know more about our devices than we as users (or makers) do, especially if they have poisoned our supply chain. This means we sometimes use devices we do not consider to be programmable, but which actually are programmable by an outsider who knows of some vulnerability or secret handshake. Surveillance and exfiltration are merely examples of a device doing things its owner does not know about, would not like, and cannot control.
Comments
Conrad Muller
In my experience, more projects fail because they are the wrong design and don't meet the users' needs than fail due to bad code. I write mid-sized business applications, and going into most projects neither my clients nor I know what will be needed to meet the business goals. Sometimes the business only knows they have a bottleneck, but have no idea what kind of application could solve the problem.
At this point, the only solution I have found is a round of analysis followed by prototyping. After that it is time to create a tentative design, keeping in mind that no project completes without someone seeing a better way to solve a problem once they have seen your first try. Properly managed change can be the sign of a healthy project.
There are probably projects where everything is know up front, but that doesn't describe my practice.
Displaying 1 comment