lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20031021212728.GF20506@surreal.seattlefenix.net>
From: benjamin at seattlefenix.net (Benjamin Krueger)
Subject: No Subject (re: openssh exploit code?)

* Montana Tenor (montanatenor@...oo.com) [031021 13:59]:
> I agree with Mitch.  Lets say you get an advisory that
> a severe thunderstorm may be coming your way.  Do you
> wait until the wind and rain are blowing inside your
> house to close the windows and doors.  Do you allow
> the kids to keep playing outside?  You do the prudent
> thing.  Instead of trying to brute-force Mitch into
> this, think about why doing the right thing to protect
> the long term interests of your business is the RIGHT
> thing to do.

I don't think anyone is brute-forcing Mitch. Criticizing,
yes. Forcing? No.
 
> The problem is solved by a refusing to allow a
> superior, most likely one ignorant to security
> concerns, to make the ultimate decision about security
> issues.  Come on, thats why he/she hired you in the
> first place.  To come to the decision that there
> is/may be a problem and to fix or mitigate it, unless
> your an MCSE, than your job is simply being a patch
> drone.  ( sorry couldnt refuse that jab :) ).

The problem is not an unwillingness due to lack of
executive support. The problem is an unwillingness by
many reasonable professionals to kowtow to vague problem
reports and advisories. The problem is that you're willing
to point out a problem, but not elaborate, thus removing
any ability for us to evaluate the severity of a problem
on our systems and networks.

The problem you're going to find is that people are not
going to jump just because a security firm says they 
should without evidence.
 
> Doing the prudent thing is almost always the best
> approach.  If you see a CERT advisory, I would say its
> prudent to patch.  Even if the language is vague and
> you see no proof.  

Will you assume responsiblity for your advice when a
hurried patch from a harried software firm that I install
in a flurry of panic as advised by a vague notification
causes my corporation irreparable harm? Will you recover
the wasted staff time, wasted money, and wasted planning
that went in to deploying this new patch when it turns
out that the patch was not even effective or opens new
holes?

You are not playing in a world of theory now. This is
the real world, with real costs, real time constraints,
real businesses, and real reputations at stake.

> Do you have to be lifted up into the tornado before
> seeking shelter? If, in the corporate world, your
> downtime to patch means lost income, then perhaps you
> need to allow for such loses in your business
> model/plan.  Its part of doing business, and thats not
> my opinion, its fact.  Either you put the money in(via
> lost revenue in downtime) now, or you lose more money
> later when you get sucked into the tornado.  I am
> sorry, but when a customer calls me today because I
> have taken his box offline to apply a patch, I explain
> to the customer that doing so is the prudent thing to
> do, and the atmosphere turns from a bitching customer
> to one that respects the fact that I am so proactive
> in securing their machine and thier interests.  Its a
> trade off, pay me now..or pay me more later, its never
> that you dont pay, unless its fraud, and its better to
> apply a patch that may not be doing more than
> printf'ing "hello world" than to not and be owned.  

Perhaps unexpected should be "built in" to systems. This
too has unexpected costs, and sometimes those
costs are too great and the returns too little to
justify the resources needed to implement them.

Maybe you have time to waste testing useless helloworld
patches on the off chance that they may be important. 
I'll wager that most professionals do not.

> People seem to forget that corporations need to think
> in terms of what is best for their long term futures. 
> If you find your losses are increasing beyond what
> your company can absorb, perhaps you should look at
> switching to a more stable environment.  Or realise
> that doing business in the sector means incurring some
> losses, and if your revenue cannot match the losses,
> perhaps your business plan needs to be altered. 

"Yes, my way may cause you great pain, but if it does
and you don't like it, you should go somewhere else."

Keep your toyland philosophy away from my systems please.
 
> Anyone that disagrees with me can do a simple test. 
> Next time the CEO says it is not acceptable, ask the
> CEO how important to you is our largest customer,
> because they will be the first to leave us when things
> go horribly wrong.  You see, big corporations know
> that software has bugs, people make mistakes, it is
> the manner that you deal with those issues and with
> your customers that determines how well you will do in
> this arena.  

You're just as likely, if not more so, to lose your
largest customer because you're sitting on a panic button
for security issues. You jump, take down systems, and cry
out every time a notification goes out. Maybe that's
acceptable for whatever business you work in. Some of us
cannot afford to diddle around with vague warnings and
security patches we cannot even verify, much less a constant
stream of downtimes which may or may not be necessary.

-- 
Benjamin Krueger

Confidence is the mother of success. Cockyness is a mother of a time bomb.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ