bloomberg on supermicro: sky is falling

Wed Oct 10 15:31:07 UTC 2018

     Well,

( I'm sorry but I cannot resist )

     Seriously mate, trolling this list using "deny-all is bad m'kay" is 
not a good idea.

-----
Alain Hebert                                ahebert at pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 10/10/18 11:09, William Herrin wrote:
> On Wed, Oct 10, 2018 at 10:22 AM Naslund, Steve <SNaslund at medline.com> wrote:
>> Allowing an internal server with sensitive data out to "any" is
>> a serious mistake and so basic that I would fire that contractor
>> immediately (or better yet impose huge monetary penalties.
>>   As long as your security policy is defaulted to "deny all" outbound
>> that should not be difficult to accomplish.
> Hi Steve,
>
> I respectfully disagree.
>
> Deny-all-permit-by-exception incurs a substantial manpower cost both
> in terms of increasing the number of people needed to do the job and
> in terms of the reducing quality of the people willing to do the job:
> deny-all is a more painful environment to work in and most of us have
> other options. As with all security choices, that cost has to be
> balanced against the risk-cost of an incident which would otherwise
> have been contained by the deny-all rule.
>
> Indeed, the most commonplace security error is spending more resources
> securing something than the risk-cost of an incident.  By voluntarily
> spending the money you've basically done the attacker's damage for
> them!
>
> Except with the most sensitive of data, an IDS which alerts security
> when an internal server generates unexpected traffic can establish
> risk-costs much lower than the direct and indirect costs of a deny-all
> rule.
>
> Thus rejecting the deny-all approach as part of a balanced and well
> conceived security plan is not inherently an error and does not
> necessarily recommend firing anyone.
>
> Regards,
> Bill Herrin
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181010/e4bb5be8/attachment.html>