[dba-SQLServer] Fwd: Windows Secrets: The Sorry Tale of the (un)Secure Sockets Layer

Mark Breen marklbreen at gmail.com
Mon Sep 19 17:37:49 CDT 2011


Hi Gustav,

You have described exactly what I am talking about.

Basically a padlock on the door is enough to deter a casual attacker and if
it is a dedicated attacker, nothing will deter them.

When I see what Stephen (my brother) can do in minutes to most systems, I am
sure that we can never be secure and still exist in modern society.  So I do
what you do, just the basics and I KISS.

Of course, Cisco, checkpoint, McAfee, Norton will not agree with this
approach.

What they are selling is FUD

And MS are no better, the User Access Control (In my very humble opinion)
protects nobody.  The pro's turn it off and the Mom and Pop user struggle
with it for years, yet they have nothing to steal.

It is the same in the airport, millions of people inconvenienced, daily, yet
the people that they are protecting us from now seek alternate places to
wreak havoc, but poor ol' Mom and Pop are still standing inline.

My argument with my brother is not to have no security - of course not, but
to have the minimum required that is reasonably safe.

(yet he can hardly bare to contemplate what I consider minimum)

Mark






On 19 September 2011 13:29, Gustav Brock <gustav at cactus.dk> wrote:

> Hi Mark
>
> Same here. I think some have a paranoid approach to this.
>
> We have two major (standard) protections here: A hardware firewall and
> Microsoft Security Essentials.
> For the last  many years I've come across one (1) incident where
> "something" tried to install something and MSE popped a message if I really
> wanted that. No thanks.
> All machines including servers run with NAT and port forwarding where
> needed.
> That is complemented with timely updates of Windows and Office.
>
> One additional thing is done, however, and I can highly recommend that:
> Advertising filters on browsers. These cost a little yearly fee per client
> but the advantage is huge as banners and adds are removed which is a relief
> (which you have to experience to grasp) for the users and removes the risk
> of clicking some nasty banner add ("Your computer is at risk! Press here"
> and a full-stop sign).
>
> Our VOIP server was hacked once and some Middle East uglies consumed our
> credit calling Arabic numbers. That was a loss of about USD 60. Not much
> work can be done for this, indeed as it seems our admin password had been
> cracked by brute force. Our splendid VOIP supplier changed the account and
> in half an hour we were back on-air with a longer password.
>
> /gustav
>
>
> >>> marklbreen at gmail.com 19-09-2011 12:24 >>>
> Hello All,
>
> there was a very interesting article recently, I cannot recall if it was in
> MSDN magazine, Code magazine or HBR magazine.
>
> Basically they did some financial analysis on the cost in the US of
> implementing security, vs the cost of a loss.
>
> What was not surprising to (to me anyway) was that the cost of implementing
> security (at a macro level) is higher than the potential loss.
>
> I adhere to this philosophy.  In my house I lock my doors at night, but a
> robber can still get in if he really want to.  To make my house totally
> secure would be to make it impractical and unpleasant to live in.  So I
> balance security with practicalities.
>
> With my IT security I try to adopt the same approach.  My brother is an IT
> security professional, and he sometimes disagrees with me, but sometimes he
> also acknowledges what I suggest.
>
> Thanks
> Mark
>
>
>
>
> On 19 September 2011 10:19, Hans-Christian Andersen <ha at phulse.com> wrote:
>
> > Regarding locking down the hosts file on Windows, if I'm not mistaken, by
> > default it should already be set to read-only and require admin
> privileges.
> > But, even if you set it to read-only, if you have mistakenly given a
> > malicious attacker admin privileges (or they have found some other hole
> in
> > which to escalate their privileges), wouldn't it be rather trivial for
> them
> > to add code to remove the read-only lock from the file? In fact, since
> this
> > is the default in Windows, I would imagine attackers probably already
> > factoring RO into their code.
> >
> > Francisco has the right idea in the sense that a very safe environment
> would
> > be to have a virtual machine set up to boot a live CD of your favorite
> > flavour of Linux (or Windows, if possible?) from a virtual drive in your
> VM,
> > so that the environment is completely clean and that you know that
> anything
> > you have done within that instance of the VM is discarded when you shut
> it
> > down. In fact, if you are really paranoid, don't run it through a VM but
> > from the bare metal of a machine. Then, before surfing, install NoScript
> and
> > run a full update of Firefox. It takes a little while to get the
> environment
> > prepared, but it might be all worth it if you are doing online banking.
> It's
> > what I do.
> >
> > But, regarding this specific issue with Komodo, DigiNotar (and more, it
> > appears), it's probably worth looking into managing what certificates you
> > have within your trusted root store and consider removing ones that you
> > don't feel comfortable having your computer trust implicitly. (
> > http://technet.microsoft.com/en-us/library/cc754841.aspx ) There are far
> too
> > many in there, which kind of wrecks havoc with the whole chain of trust,
> in
> > my opinion.
> >
> >
> >
> > Hans-Christian
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>



More information about the dba-SQLServer mailing list