I have to agree an abuse of trust from one trusted services to others would be a control point that I would look at within the system. (I am not sure is this is based on Service Orientated Architecture type of system or something more simplistic).
The 2 factor is definitely a good start up front, but also need to all at the control in place throughout the system to ascertain if there is any weak points in the design that could be abused. Z Edward E. Ziots, CISSP, CISA, CRISC, Security +, Network + Security Engineer Lifespan Organization [email protected]<mailto:[email protected]> Work:401-255-2497 This electronic message and any attachments may be privileged and confidential and protected from disclosure. If you are reading this message, but are not the intended recipient, nor an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you are strictly prohibited from copying, printing, forwarding or otherwise disseminating this communication. If you have received this communication in error, please immediately notify the sender by replying to the message. Then, delete the message from your computer. Thank you. [cid:[email protected]] From: [email protected] [mailto:[email protected]] On Behalf Of Andrew S. Baker Sent: Wednesday, April 16, 2014 9:45 AM To: ntsysadm Subject: Re: [NTSysADM] Secure Communications for Server Orchestration The boxes in question are all housed in a top-tier hosted data center with biometric scanner and audited access. The biggest concern is logical security. The goal is to prevent someone who gets access to the master box, and thus has automatic authenticated access to several other key systems hosting a mission critical application. Regards, ASB http://XeeMe.com/AndrewBaker<http://xeeme.com/AndrewBaker> Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market... On Tue, Apr 15, 2014 at 10:04 AM, Kurt Buff <[email protected]<mailto:[email protected]>> wrote: Depending on circumstances, I'd work on physical security for the master (perhaps putting the master in a separate locked cabinet), and then login security for it as well - implement 2FA, such as a proximity card or other assurance. Any idea what the threat model is? Kurt On Tue, Apr 15, 2014 at 4:11 AM, Andrew S. Baker <[email protected]<mailto:[email protected]>> wrote: Correct... In addition to using certificate-based logons, rather than password-based logons. ASB http://XeeMe.com/AndrewBaker<http://xeeme.com/AndrewBaker> Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market... On Mon, Apr 14, 2014 at 6:31 PM, Kurt Buff <[email protected]<mailto:[email protected]>> wrote: Aside from using public keys vs. passwords? Kurt On Mon, Apr 14, 2014 at 9:14 AM, Andrew S. Baker <[email protected]<mailto:[email protected]>> wrote: Good afternoon: I have an interesting question about secure configuration between puppet orchestration master servers and their minions. (for those who don't use puppet, you can look at it here: http://puppetlabs.com/puppet/puppet-enterprise ) The question pertains to using SSH to secure the communication between the master server and its slave servers. What other mechanisms would you consider to ensure that this SSH connection does not get abused? (As it would essentially be always active) Regards, ASB http://XeeMe.com/AndrewBaker<http://xeeme.com/AndrewBaker> Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market...
<<inline: image001.png>>
