East to West Data Center Security? #netsec

I always recommend layered security. And East-to-West Data Center Security is no different!  However, security for the sake of security isn’t ever a good thing. So let’s take a look at East-to-West DC security.

I’d also wholeheartily agree with intrusion prevention (IPS) and possibly application layer security on east-to-west data center traffic.  Hackers are breaching East-to-West systems through zero days, injections, and brute force, something user identification wouldn’t really help with.

In regards to user-id, there shouldn’t ever be user identifiable traffic in that direction.  When there is, it is the same user over and over again.

Example:
From DMZ web services to backend DB servers there should only be the DB API ports open. Nothing else.  DB users shouldn’t be the same as the underlying system’s users and are *rarely* AD/Radius users anyway.

Because of the system/user differences, I tend to think of east to west security as more of a “IT Security Posture” than a specific technology implementation.

Other than intrusion prevention and application identification (is this DB call really a DB call), I’d recommend rolling password changes for the DB API call users, lockouts after 1 failed attempt, and never “select *” privileges let alone root.  If your application coders don’t know what they want, they’re slowing the application performance anyway.

You could say “what about administrators of the east-to-west systems?” But even that traffic is north to south at some point before it gets to them.  I’d do user identification there.

Just my 2cents.  Leave a comment and tell me your east-to-west security approaches!


Leave a Reply

There aren't any comments at the moment, be the first to start the discussion!