1. 3
  1. 2

    Working link; https://web.archive.org/web/20220326171212/https://queue.acm.org/detail.cfm?id=3526209

    What was the conclusion or purpose of this article? It filled an odd space where it offered no technical guidance, but wasn’t creatively written enough to enjoy as-is.

    I don’t want to be overly negative. As a sliver of substance, I’d say: when designing a system, start with an asset-centric threat model. Really dig deep. Get it reviewed by people you trust / employ / both.

    If you don’t know what an asset-centric threat model is, let me know I would enjoy writing about it.

    1. 2

      Strange, the link seems to be working for me. (The web server might do some “checks” behind the scenes.)

      What was the conclusion or purpose of this article?

      The article’s author has a column on ACM Queue called “Kode Vicious”, where he answers the emails of readers, but doesn’t necessarily give a concrete answer, instead tries to tackle the more philosophical aspects of the problem. Sometimes he even goes on to rant about the topic. :)

      The point of the current article I think boils down to: just as we have “software engineers” that think about and implement the actual software, there should exist counterparts “data engineers” that should think about and implement the data management part.

      (Too many times, developers don’t think what to do with the data, and they hope that “the cloud” would just solve any issue…)

      1. 1

        (Too many times, developers don’t think what to do with the data, and they hope that “the cloud” would just solve any issue…)

        Data is central to systems. You can make mistakes modeling and storing data. People are used to shooting themselves in the foot with a single VPS instance with a .22 gun. “The cloud” lets you shoot yourself in the foot with a 10 megaton thermonuclear weapon. All problems need thought, foresight, and mechanisms for recovering from mistakes.