Sign In

Communications of the ACM

Practice

Go Static or Go Home


Go Static or Go Home, illustration

back to top 

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

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.
  

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.