Re: [Lsvr] [OPSEC] security against what?

[Christopher Morrow <[e-mail]>]

On Tue, Sep 4, 2018 at 11:38 AM Randy Bush <[e-mail]> wrote:

> > 'datacenter operators' == "hyperscale web wonkers" ?
>
> i asked in lsvr, which is what i guess you woud call hyperscale.  lsvr
> also tends toward decentralized,
>
>
sorry: 'decentralized' means what here?


> > or 'datacenter operators' == 'colo provider' ('the planet' not 'equinix'
> -
> > and 'the planet' is now 'someone else' but...)
>
> 1x would seem especially inapporpriate here as there is no
> centralisation of authority.
>

So, in a large datacenter where randos are able to walk around and affect
change to my cage's in/outs (and potentially clamp mitm/etc gear without my
knowledge) there's a different 'security concern' than there is in a
building I wholey own and operate behind several layers of physical
security and such.

If all of your "datacenter deployment" is inside a single cage in a
colocation building you MAY be "safe", but if you span cage spaces (who
ever decided on day-one in a building that they only would ever need 640kb
ram/squarefeet/kw/etc?) you are potentially sending your 'routing
protocols' over links outside of your immediate security perimeter.

That seems rather scary... like kinda really scary, actually...
I wonder how often people consider: "security of the data in the datacenter
(at rest or in flight)" but forget about the routing system which is
intrinsic to the operation of that datacenter?


>
> >>> Is recommending 802.1x possible/sufficient (given the description in
> >>> Randy's strawperson comment)?
> >> it's a long way to that radius server
>
> with coffee, i might expand a bit.  during turn up of new links and
> devices, it may not be easy to get to a distant 1x authority.
>
>
I'd point out that if you put business critical dependencies 'far away' you
are a competitor I'd love to have? :)
Ideally once you figure out your deployment scenario and drive down all the
dependency tree branches you figure out who/what needs to be "local" to the
deployment, and how to live in a state where that dependency is unfulfilled
for part of the turnup/repair/turndown workflows.  Right?