1. 18
  1.  

  2. 5

    If you take away nothing else from this article….

    Conclusion: Prioritize well decorated, accessible, centralized and alert-able logs above most other security projects.

    …hint: It will also make debugging a lot easy / faster / more productive…..

    …which incidentally since, most bugs are also security risks….. will also improve security.

    Missing from this article however Schneier’s observation that holding gigabytes of confidential data is like holding millions of gallons of toxic waste…. Sooner or later it’s going to spill out and hurt you.

    Does it’s value really out weigh it’s risks?

    1. 2

      I’m not sure Schneier’s rule applies. It’s just logs. You can pull data out of them that would hurt you. Alternatively, you can use the high-assurance method of offloading them to a dedicated server through a one-way link (data diode). The one-way link allows the logs to be stored by untrusted, Internet-facing nodes but not receive anything back. Append-only storage that requires admin for deletion can help with residual risk of malware just going for a DOS of archive. Cheapest setups for fiber I saw were around $200-300 if you hand-did it. Debuggers or security people could access those boxes directly with serial ports as in A1-class systems as any other link might be hacked. There’s also convenient switches these days to multiplex serial ports like with KVM’s.

      EDIT to add: append-only provision

      1. 4

        I think Schneier’s point is that, yes, things like logs are really usefu and valuable…..

        • but as they age, their value degrades
        • and the privacy risks increase
        • to the point where they are a liability not an asset.

        ie. At some point in time, it is better just to delete them.

        1. 2

          Oh I agree with him. Im just saying it’s one of easiest problems to mitigate for when an organization considers the data worth risk. A lot of people seem unaware that three components collectively under $1,000 mitigates the entire risk on Internet/software side.

    2. [Comment removed by author]

      1. 3

        It seems likely that at least some of the failures in that list were not breaches per se, but rather that the exchanges or services themselves were scams designed to steal from credulous depositors.