RE: [Non-DoD Source] Re: Security Wonks ate my hamster.

From: Freeman, Donald G. CTR <donald.freeman.ctr_at_ablcda.navy.mil>
Date: Wed, 23 Mar 2016 18:05:02 +0000
Message-ID: <85D44D05C4C24C40AFDED6C1FC0E1BDFD1A97838_at_SNSLCVWEXCH02.abl.cda.navy.mil>



>>>>>>>>>>>" In this day and age, most servers are dedicated to the Oracle database. As a consequence, it really makes no sense to refuse root access from a reasonably knowledgeable Oracle DBA. ..."

That is a sensible observation.

Donald Freeman

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Andrew Kerber Sent: Wednesday, March 23, 2016 1:23 PM
To: dba_at_michael-brown.org
Cc: fmh; John Piwowar; rajendra.pande_at_ubs.com; howard.latham_at_gmail.com; oracle-l_at_freelists.org Subject: [Non-DoD Source] Re: Security Wonks ate my hamster.

In this day and age, most servers are dedicated to the Oracle database. As a consequence, it really makes no sense to refuse root access from a reasonably knowledgeable Oracle DBA. The data in the database is the only item that is important to security and the financial health of the company, so there is nothing the root user can do that is more important than the oracle user.

On Wed, Mar 23, 2016 at 11:52 AM, Michael Brown <dba_at_michael-brown.org> wrote:

        For years, I have helped setup environments where almost no one had root or oracle.

        The few that had it were also the ones who could connect to our syslog server.

        Everyone else would use sudo based upon group membership. We set up an alias in /etc/bashrc: become=‘sudo /bin/su -‘, and in sudoers, the groups were authorized to run /bin/su - USERNAME (production required passwords for root and oracle, test systems required passwords for root, oracle was group dependent, and dev did not require passwords). vnc passwords were set randomly by a cron job. This meant we could see who logged in and su’ed to a privileged account in the log files. Since they also logged to an external server, a user could not erase the record of doing stuff.

        The only time I have ever needed the root password was for certain activities during boot. The oracle password is required by certain installers, but in that case, we set it to a temporary value for the duration of the install (or have one of the senior people who knows the password run the installer).

        If a person only has access to oracle, they have to have someone who has root access to run root.sh.

                On Mar 23, 2016, at 11:28 AM, fmhabash_at_gmail.com wrote:

                I have also monkey’d around with HashiCorp Vault secret store. https://www.hashicorp.com/blog/vault.html . The issue that confronts me the most is how ready the enterprise is to formally adopt and institutionalize such solutions. There is going to be significant overhead in learning, maintenance, and architecture.                  

		What I normally see are three distinct scenarios ….
		1)      Hierarchy- based mandates: were a directive comes from the top e.g. CIO/director, ‘we must get this done’. This is effective and sends everyone chasing their tail to get it done. 
		2)      Self-organizing / energizing teams: A group of people that internalize such needs and embrace the idea that ‘good is never good enough’. They learn fast, execute, and communicate effectively. It is hard to see such teams & individuals. 
		3)      Who cares. If not broken, do not fix it. These are places who have inserted plain-text passwords everywhere is scripts and config files for the entire life of the organization. Everyone knows about it, everyone knows it needs fixing, but no one is saying/doing anything i.e. no drive (internal or external). 
		 
		 
		 
		----------------------------------------
		Thanks
		 
		From: John Piwowar <mailto:jpiwowar_at_gmail.com> 
		Sent: Wednesday, March 23, 2016 9:59 AM
		To: rajendra.pande_at_ubs.com
		Cc: howard.latham_at_gmail.com; oracle-l_at_freelists.org
		Subject: Re: Security Wonks ate my hamster.
		 
		Yup, that's a fair point, both about the analogy and the situation, thanks! 
		 
		It really comes down to whether the process is more thoroughly defined than, "passwords locked in that box over there." :-) I'm hoping the answer is yes. 
		
		On Wednesday, 23 March 2016, <rajendra.pande_at_ubs.com> wrote:

			Well it depends is right J

			 

			“but I really wonder about about the motivation of taking the keys away from the guy entrusted to drive the bus.”

			With a lot of ongoing issues – staying with your analogy - the effort is NOT to take the keys of the bus – but make it such that the driver gets to have the keys when he needs to drive the bus and not have the keys all the time.
			Standing access vs break glass when you need it 

			 

			The question comes down to is how easy or cumbersome that process is 

			 

			 

			 

		
		
		-- 
		Regards, 

		John P.

		(Typed with thumbs on a mobile device. Lowered expectations appreciated)





-- 

Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'



-- http://www.freelists.org/webpage/oracle-l
  • application/pkcs7-signature attachment: smime.p7s
Received on Wed Mar 23 2016 - 19:05:02 CET

Original text of this message