[clug] Dangerous Dave's talk

[Bob Edwards]

On 06/03/15 07:54, Scott Ferguson wrote:
> Please don't top post
>
>
> On 05/03/15 23:21, Dodgy Dave wrote:
>> I think a more engineering approach is to assess the risks (write them
>> down), and then attempt to mitigate/cover those risks one by one,
>> assessing them for strengths and weaknesses. Pretty boring, but quite
>> likely to give the best outcomes in the end.
>>
>> For each 'solution' element, what are the risks that it covers, and how
>> well? Are there better ways to do the same thing? Are the risks real, or
>> just 'tin foil' material? Are they practical? At what 'cost' or level of
>> difficulty, etc
>
> I think Hal has clearly indicated the problems with the VM approach, as
> have I with the LiveCD and using an OS on a removable device.
>
> If you have specific points you disagree with please indicate which ones
> and I'm happy to demonstrate my reasoning.
>
> I'm not sure why you prefer an "engineering" approach (or what you mean
> by it from a "software" engineering point of view).
>
> IMO the proper approach is from a risk management and security
> engineering one. From a risk management point of view it's important to
> consider not just the "chance" of something going wrong - but the impact
> "if" something goes wrong otherwise you run the risk of dismissing
> possible risks as "tin foil" (ignorance based risk assessment) simply
> because while "it might be possible" "it hasn't happened yet"*1.
>  From a security engineering approach - minimise exposure, which has
> already been done if only using the "device" (be it VM/chroot/removable
> device) for banking, and, *change control* - don't do it if you can't
> make a compelling argument in favor of the change that has been
> thoroughly thought through (do you really need to do online banking?
> which scripts are necessary to run on the bank site? would a debit card
> be better than a credit card, etc).

I sometimes wonder why the (disproportionate?) interest in online
banking vs. other online activities where rich metadata is being
freely given to foreign-controlled entities? Is guarding online
banking a privacy issue or a theft issue?

If the latter, can anyone point to an instance where an Australian
bank has not ended up re-imbursing the loss(es)? Certainly, there
are convenience issues at play, and the story probably differs for
a business banking breach vs. a personal banking breach, but does
anyone know of cases where the eventual outcome was a loss to the
customer, where the customer had taken "reasonable" steps to protect
their online activities?

Or is "online banking" simply a metaphor for a whole range of online
activities that are desired to be kept private?

cheers,

Bob Edwards.

>
> i.e. Q. Can a VM be secured against host-based exploits? A. No.
> Q. Is a Live CD secure against exploits? A. No (to be as secure as
> possible it must be as updated as possible).
>
>
> *1 As the bloke who jumped off the tenth floor said as he passed the
> fifth - "so far so good".
>
>
> Rather than re-invent the wheel I'd just suggest the people read Brian
> Krebs advice.
>
> HTH
>
> Kind regards (in security solidarity).
>
>>
>> DD
>>
>> On 05/03/15 07:37, Hal Ashburner wrote:> On 4 March 2015 at 21:43, Scott
>> Ferguson <scott.ferguson.clug at gmail.com> wrote:
>>>
>>>> A live CD is better - *if* kept updated. An OS installed to a USB Key is
>>>> (possibly?) not quite as secure as a Live CD, but is easier to keep
>> updated.
>>>>
>>>
>>> What about an SD card that you enable as writable only to do updates
>>> with that big hardware switch on the side of it?
>>>
>>
>>
>>
>> On 05/03/15 07:37, Hal Ashburner wrote:> On 4 March 2015 at 21:43, Scott
>> Ferguson <scott.ferguson.clug at gmail.com> wrote:
>>>
>>>> A live CD is better - *if* kept updated. An OS installed to a USB Key is
>>>> (possibly?) not quite as secure as a Live CD, but is easier to keep
>> updated.
>>>>
>>>
>>> What about an SD card that you enable as writable only to do updates
>>> with that big hardware switch on the side of it?
>>>
>>
>>
>
>
> ---
>
> "The pure and simple truth is never pure and rarely simple" ~ some dead
> person
>