Re: SYSADM and Security

[Russell Fulton <r.fulton () AUCKLAND AC NZ>]

We too have separate groups for OS administration PS administration and
DBAs. I believe that all the special PS accounts such as sysadm are set
up so they can not be logged into directly.  All admins and DBAs have
individual logins (soon to be controlled via RSA tokens) and users then
'sudo su' to the special accounts.

We have central log processing and I have lists of the logins for DBAs
and admins and anyone su-ing to to something they should not will raise
a flag in the hourly report.

Eventually I'll do a daily report of all authentication/authorisation
logs for each machine.

here is an excerpt from the log processing config and should give some
idea of what I'm doing:

Note the regular expressions are Ruby REs -- more or less the same as Perl.

> # this section tries to cover all the legit su and sudo activity
>
> $ITSS_UNIX_ADMIN = (?:xxxx|yyyy|zzzz|....)
> $ITSS_DBA = (?:aaa|bbb003|ccc007|...)
> $PS_ADMIN = (?:ggg002|hhh210|zzz028|...)
> $PS_ACC = ps(?:hr|fs|sa|ep|admin)(?:prd|tst|dev)?
>
> [service itssunixadmin] {
>   [periodic] {
>     proc sudo &
> /^$ITSS_UNIX_ADMIN/                                      : drop
>     proc sudo & %r!^$PS_ADMIN .* COMMAND=(?:/usr)?/bin/su -
> $PS_ACC!             : drop
>     proc sudo & %r!^$ITSS_DBA .* COMMAND=(?:/usr)?/bin/su -
> (?:oracle|vdxt)!     : drop
>     proc sudo & %r!nobody .+ COMMAND=/bin/cat
> /proc/megaide/0/status!        : drop
>     proc su & /'su $PS_ACC' succeeded for
> $PS_ADMIN/                         : drop
>     proc su & /'su (?:oracle|hyperion)' succeeded for
> $ITSS_DBA/             : drop
>     proc su & /'su root' succeeded for
> $ITSS_UNIX_ADMIN/                     : drop
>     proc su & /'su \w+' succeeded for
> root/                                  : drop
>     proc su & /^'su $PS_ACC' succeeded for
> $PS_ADMIN/                    : drop
>     proc su & /^'su weblogic' succeeded for
> $PS_ADMIN/                   : drop
>     proc login & %r!^?ROOT LOGIN
> /dev/pts/\d+!                           : drop
>     proc sshd & /^Accepted keyboard-interactive for
> $ITSS_UNIX_ADMIN/    : drop
>     proc sshd & /^Accepted password for
> $ITSS_UNIX_ADMIN/                : drop
>     proc sshd & /^Accepted publickey for $ITSS_UNIX_ADMIN from
> 130\.216\./       : drop
>     proc sshd & /^Accepted publickey for oracle from
> 192.168\.163\.(5|8)/        : drop
>     proc sshd & %r!^'su root' succeeded for root on
> /dev/\?\?\?/            : drop
>   }
> }

Log record that are not dropped are reported hourly.
The root logins are from console logins as part of the VM management and
are (I'm told) unavoidable.

Mark Staples wrote:
> I've been wondering what other institutions are doing about system
> accounts (i.e. sysadm with PeopleSoft) that have full administrative
> access and can be used by any DBA, which then impacts effective
> monitoring and accountability.
>
> I'm being told that there is no way around the regular use of these
> type of accounts and I need to accept the risk and trust our DBAs.
> While I "believe" what I'm being told, I'd like to find out what other
> institutions are doing to address the use of system accounts.
>
> Thanks!
>
> Mark
>
>
> -----
> Mark Staples
> Director of Information Security/Chief Information Security Officer
> IT Research Liaison
> Medical College of Georgia
> Office: 706-721-1577
> FAX: 706-721-7296
> mstaples () mcg edu
>
> --------
>
> All information in the communication, including attachments, is
> strictly confidential and intended solely for delivery to the
> addressee(s) identified above (ie, To/cc/bc), and may contain
> privileged, confidential, proprietary and /or intellectual property
> entitled to protection from disclosure under applicable law.  If you
> are not the intended recipient, please take note that any use,
> distribution or copying of this communication is unauthorized and may
> be unlawful.  If you have received this communication in error, please
> notify the sender, delete this correspondence from your computer, and
> destroy any printed copies of this communication.
> ------------------------------------------------------------------------
>
> BEGIN:VCARD
> VERSION:2.1
> N:Staples;Mark
> FN:Mark Staples
> TITLE:Chief Information Security Officer
> ORG:Medical College of Georgia
> ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;1120 15th Street=0D=0AHS-2125;Augusta;GA;30912;USA
> ADR;HOME:;;P.O. Box 1505;Augusta;Georgia;30903;USA
> URL;WORK:http://www.mcg.edu
> TEL;WORK:706-721-1577
> EMAIL:mstaples () mcg edu
> TEL;CELL:706-799-7409
> TEL;FAX:706-721-7296
> END:VCARD