Re: PG in cash till machines - Mailing list pgsql-general

Hi John,

On 5/10/2013 2:55 PM, John R Pierce wrote:
> On 5/10/2013 2:11 PM, Bexley Hall wrote:
>> Having designed (regulated) gaming and "grey area" devices (each
>> handling hard currency), I can tell you that you have to have already
>> performed a pretty exhaustive threat analysis (e.g., red team, blue\
>> team) *before* you start the product's design. If you can't imagine
>> *all* of the ways you can be targeted, then you can't determine
>> how/if you will be "secure" in each of those scenarios (e.g.,
>> I've incorporated features into the hardware designs to counter
>> certain types of physical attacks).
>
> indeed, and there's always threat models that no one could foresee,
> witness the recent story of coordinated ATM withdrawals of $45,000,000
> enabled by some back door hacking of the bank databases.

All (?) software and security flaws can be traced to "improper
assumptions".  Someone, somewhere, involved in the design of the
"system" (which includes more than just hardware and software)
made some BASIC assumption that was flawed.

I.e., assumed "/* CAN'T HAPPEN */" actually *couldn't* happen!

The trick to designing robust software (and robust systems) is
to identify those assumptions and then seriously question whether
they *really* are valid -- or, just valid in your particular
outlook on Life, The Universe and Everything.

- This instruction got executed so the next one will, as well.
- The only way for this instruction to be executed is if the
   preceeding one is, also.
- There can't be two credit cards with the same account number.
- People can't be in geographically different locations at the
   same time (so they can't possibly make withdrawals on the
   same account from those different locations, concurrently)
- Social security numbers can't begin with '0'.
- System power won't fail (or be intentionally interrupted)
   before I get a chance to do X... (e.g., flush buffers to
   permanent storage)
- All first names are less than BUFLEN characters.
- When turning *right*, I can't hit anything on the *left*.
- No one will unplug (or cut!) this cable.
- Users will choose "good" passwords.
- malloc() will never FAIL.
- This contact will close each time a coin is dispensed.
- Coins can't pass this sensor faster than once every N seconds.
etc.

Conversely, the way to find faults in those systems/software is
to "do the unexpected".  Developers tend to be *so* focused on
"just trying to get it to work" that they often don't attend to
"getting it to work *well*".

Carlos has to figure out which of these assumptions he's made
that aren't *guaranteed* (by some agency/mechanism) to be true
and figure out how to *make* them true (or, detect when they
are not).

--don