back to article Wanna protect your data center? Take tips from the US Secret Service

Data center managers should take some tips from the US Secret Service when protecting vital servers from hackers, says someone who has been through a White House lockdown. In a presentation at Enigma 2017, Nathaniel Gleicher – a former director for cybersecurity policy at the National Security Council and now head of …

  1. John Smith 19 Gold badge
    Unhappy

    My suspicion.

    It's tough to do fully depending on many different kinds of "stuff" you support, and the results will be eye watering for most that do it.

    Historically "access control" was about card readers and PIN keypads but today that should be part of the software landscape.

    We've all heard of apps (the NHS seems quite notorious for this) that require Administrator privileges to run and it's time more "need to know was applied."

    No doubt SOP for many Reg reading admins but I thinks there's a few who it might still have it on the ToDo list instead of actually doing.

  2. Anonymous Coward
    Big Brother

    Securing the Perimeter

    Design it so that there is no inside network, as in everyone is on the outside of the perimeter, requiring a hardware dongle to provide credentials and end-to-end-encryption. All traffic on the inside is provided by embedded end-to-end encrypted channels. Anyone else who attaches to the network see nothing but random bits.

    1. tom dial Silver badge

      Re: Securing the Perimeter

      Our (USDoD) data center did not allow end to end encryption, as they required (and used) the capability to scan all traffic entering or leaving the premises. This started after a remote user's account was compromised and used to upload malware that, as I understood it, affected a major application quite seriously. Those of us already using SSH to internal hosts were not forced immediately to stop, partly because telnet and ftp were disallowed on principle, but ultimately had to switch to out-of-band access using a VPN that terminated at a premise gateway.

      In an ideal situation, multiple factor authentication and end-to-end encryption may be suitable, but situations usually are less than ideal. DISA centers typically support thousands of external users and systems, not all of them subject to DoD control.

  3. Marc 13

    erm...

    https://www.washingtonpost.com/politics/white-house-fence-jumper-made-it-far-deeper-into-building-than-previously-known/2014/09/29/02efd53e-47ea-11e4-a046-120a8a855cca_story.html?utm_term=.95bd41d6027b

    That is all...

    1. JimboSmith Silver badge

      Yeah the theory is fine but not the execution in that case. There are supposed to be multilayered defences once over the fence that should stop an intruder from getting anywhere near the building. Sadly on that occasion it didn't happen the way it should. Doesn't help if the dog handler is on his cell phone (leaves one radio in his locker) and therefore leaves it too late to release his dog. The dogs I understand are trained to go after a fence jumper and lock on to one target. When the chasers were ahead of the dog position it then wasn't safe to release. The dogs are effective however (not to blame in that case) and have stopped fence jumpers in the past.

  4. AnthonyP69

    SDN are not the answer

    So he is say plan out your networks, know the traffic, block anything that is unknown, restrict access to it lowest level, Roll based access. Anything that doesn't need to be in the Data Centre should stay out of the data centre.

    I guess forcing your application developer or supplier to document every access they require and hold them accountable for anything that isn't recorded in their documentation. I guess don't back down on the rules!

    1. Claptrap314 Silver badge

      Re: SDN are not the answer

      Force developers to document? That's too late. In my experience, SRE has not advanced to the point of really addressing security. But applying the pattern means, "force application engineers to justify why a given access is needed". Not to you, but at all. Devs are not conditioned to think about tradeoffs in the security dimension. This must change.

  5. Version 1.0 Silver badge

    The post-snowden world

    Essentially trust no-one, not even the system administrator, only physical access permitted, no remote logins, all system administration actions must be logged and reviewed by a third-party withing two hours ... ad infinitum.

    Meanwhile, back at the HQ, the accountants are reviewing the costs of IT which have risen recently and recommend that we outsource - they have a competitive bid from a company that says they are compliant.

    1. PdV

      Re: The post-snowden world

      re Post Snowden world..

      That remark about "we found an outsourcer, he is compliant" .. Stick that on the wall.

      Mine is the one with the Fox Mulder logo : TrustNo1

  6. Velv
    Boffin

    As mentioned, implementing on to an existing legacy network is a massive undertaking that will result in outages.

    However it should be done for all new deployments. Start locked down and only open what must be opened.

    One other caveat - make sure everyone involved fully understands the concepts, rationale and technical requirements otherwise you'll end up with a broken network that's a nightmare to maintain.

  7. tom dial Silver badge

    As I understand this correctly, it is not a new idea, even in the government. When I retired about 5 years ago, US DoD data centers had largely implemented a scheme of many VLANs with detailed access control lists and intermediate firewalls such that users of an application (including other applications) were permitted access only to the resources required. As far as I was concerned, as DBA for a number of specific databases, applications that did not connect to those databases might as well not have existed. The data centers also had implemented out-of-band access for their own administration and begun to impose that on customers who did their own administration.

    As Gleicher and various commenter have noted, it is not easy to implement even for new work, quite a lot harder to retrofit, and more than a little painful for various categories of user. It took them for or five years In general, though, it worked well once in place, giving trouble only occasionally when changes had to be made.

    Out-of-band requirement for us external administrators was especially irksome, as it brought a required VPN that shut off all other workstation networking, cutting off email and the IM that we used for internal communication. These were hard to do without for more than a short period because our agency was geographically distributed, by branch, across three widely separated locations; this problem eventually was solved, I believe, by providing those affected with secondary workstations (and additional LAN drops) for their VPN use. This requirement also led my former agency to drop out of the server operation business, as the network upgrade cost, combined with increasingly stringent and costly configuration management and security requirements came to be seen as diverting resources from their primary mission.

    1. cork.dom@gmail.com

      How about VPN Split tunneling?

      Although not ideal in a security context, it would have prevented having to give the users 2 workstation.

  8. MJB7

    people don't test their backups

    When has that not been the case?

    Admittedly, for most history that's been because copying stuff by hand onto vellum meant that it was too difficult to take backups in the first place, and it's really hard to test a backup you haven't made.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon