Tandem Security SIG Minutes


March 21, 1997 - Canadian Imperial Bank of Commerce

Attendees:

John Wildfong ACCI
Caroline Woo Bank of Nova Scotia
Mark Bramley Bank of Nova Scotia
Victor Doreen Bank of Nova Scotia
Tom Chung Bank of Nova Scotia
Anne Osso Bell Sygma
Kevin Bloska Canadian Imperial Bank of Commerce
Kien Truong Intria (formerly CIBC)
Clement Lee Royal Bank of Canada
John Fong Royal Bank of Canada
Grant Lowe Royal Bank of Canada
Marcello Cosentino Royal Bank of Canada
John Leeson SNS Shared Network Services
Mark Wilson SNS Shared Network Services
Cathie Searle Tandem
Gary Burke Tandem
Richard Cheng Toronto Stock Exchange


1) Introduction /Clement Lee Royal Bank of Canada

- Rebroadcast the purposes and values of SIG.

2) Kien Truong (Host)

Welcomed members to the second SIG meeting, and informed audience that CIBC's Operations department has reorganized into a separate company named "Intria".

3) Jay McLaughlin / Unlimited Software & Associates (USA)

Security Products: Boss & Cyberboss (Developed by Cross-El Solutions)

(Note: See attached text files. These are "text" extracts from Jay's PowerPoint presentation. The original PowerPoint files are also available. Please contact Jay McLaughlin or John Leeson).

Many new Security issues (e.g., firewalls)

1990 survey breaches of Security: 87% caused by people.

1997 survey breaches of Security: still 87% caused by people.

People are real security risk.

80-90% of Security breaches are by persons authorized to use the System.

BOSS: Controlled Access and Management.

CYBERBOSS: (internet)

(Note: the following questions were raised in the meeting. Jay supplied the following answers later by email):

Boss Questions & Answers:

Q: When Full Auditing is implemented in BOSS what is the CPU usage?

A: Minimal -- the files written are Entry-Sequenced Enscribe files. To put it another way -- you would certainly want to track "who did what" within a security system no matter what it costs. But the cost is minimal, <2%.

Q: What is the typical install?

A: The most logical way to install the system is to first install it on a development system only and test it there. When implementing on production systems, most corporations bring up the BOSS system either by "Department" by "System" or by "User Group" (usually based on business needs). If you want one group of users that are currently using

TACLs who don't really require that functionality -- I would look at using BOSS on their application first. BOSS is not a difficult product to install or use. The manual is quite specific and telephone support is always available during Installation Phase.

Q: How does it eliminate Shared-IDs?

A: In comparison to Safeguard, if you as SUPER.SUPER want to give an operator SUPER.SUPER to run one task -- it requires that you create "Aliases" which are in effect, other logons. In Boss, you simply give that user SUPER.SUPER capability for that one function and when that function is completed he/she is back to their original logon. Also,

in networks, you can jump from approved network to approved network without having to re-Logon.

Q: Why have a SUPER.SUPER?

A: Our point exactly! But let's go one better -- why have any Guardian Users running TACLs without having them come into a front end that will "Log" everything they do?

Q: Can it Enable/Disable logging of certain commands? e.g., "PASSWORD"?

A: Yes, through the products "Advance Auditing" functionality. It allows a security person to view all of the "FUP PURGES" on a system without looking at the plethora of other FUP commands that would be uninteresting to security.

Q: Who manages BOSS? E.g., security or technical people?

A: Good question! The Tandem Technical staff usually manages BOSS with blessing by the Security and Audit people. After the system is "up and running" for some time -- there is little reason for anyone to "Manage" the system -- it pretty much takes care of itself - when implemented properly.

Q: What tools are available to "scrape access definitions" of specific user from existing audit logs to assist in designing boss menu for user?

A: I believe you mean, is there a utility to bulk load users? The answer is No. But when you study the BOSS hierarchy and how users relate to applications, functions within applications, domains and scopes -- you will see that manually loading the databases should probably have some thought behind it and not have Bulk Load capabilities.

Q: How do you handle transitioning people off of SUPER.SUPER?

A: SUPER.SUPER has far too much flexibility for most shops. The only reason most people have it is that they have been accustomed to having it since day one. I would explain the "Business" and Security reasons for taking SUPER.SUPER from them. Remember, everything that they could currently accomplish within SUPER.SUPER can STILL be accomplished (based on BOSS Manager). It will just be more secure and totally logged.

4) Action Items from last meeting / Cathie Searle Tandem

a) CA Unicenter demo.

Awaiting next release 2.0 approx. April 18, will be running about end of April. TNG ("The Next Generation") approx July or Aug.

Q: Who has installed? Problems?

A: only Canadian installations in Montreal.

b) DISKFILE Access rules. Answered by Bill Simpson in previous minutes.

c) Status of SEEP:

Password Quality program distributed by Mark. SEEP no longer available as standalone product. Now bundled with Safeguard and CA 125 & 325.

d) Netbatch TPR (John Wildfong's question) group sharing not supported?

Issue still needs to be clarified.

5) Open discussion / Questions & Issues.

Anne Osso / Bell Sygma:

Shared Userids & SUPER.SUPER: Who does what? What is SUPER.SUPER needed for?

Tandem published article around 1991-92, available on Infoway defining just when it's needed. Should only be needed for: 1. ADDUSER *,255; 2. License & Revoke; 3. Install functions (license)... can PROGID Install

Note: Article referred to is Support Note S910320 "The Use and Abuse of SUPER.SUPER" by Timothy Chou, Randall Schwartz and Lyle Settle.

Some comments:

"Bank A": Only 1 person has SUPER.SUPER access (password available in vault). Also SUPER.SUPER ID is "owned" by SUPER.SUPER (not security admin).

Company B: Super is "shared", but users are forced to logon initially through individual alias, thus can trace who did what.

Anne Osso:

How to handle the transition of people ("downgrading") from very privileged ID's to more restricted id's. How do people do this?

Some comments: Sell it as way to "protect" people, i.e., limit negative effect of mistake made while logged on as SUPER.SUPER; Also, define what is needed for a user to actually do his/her job.

Caroline Woo/BNS:

Raised issue of cleaning up Safeguard rules after a userid is deleted.

Possibilities:

CSP in last meeting introduced "Wizards" in future release or products that could help "clean up" deleted users.

TACL or other routine to find SG rules for user & create SAFECOM /in file/ to run... slow & lots of resources. Especially if there are lots of nodes & rules. (e.g. "ALTER DISKFILE *.*.* -GROUP.USER"). All ACL modification times are changed by this command so you can't determine the last time an ACL was modified.

Action item for Cathie to follow-up.

Caroline Woo:

Spooler question: is it possible to audit or protect individual spooler jobs. Safeguard can protect access to spooler, but how can we audit jobs (i.e., find out who & when a job was deleted).

No answers. Some people put more sensitive or critical jobs into separate spoolers.

Action item for Cathie to follow-up.

Andi Coleman / Nations Bank (John Leeson brought this on her behalf):

How many people SYSGEN safeguard?

Answer: No-one at meeting does this.

If not, how accessible is SUPER.SUPER to tech support people? Specifically, how easy is it for non-Security people to shutdown safeguard (e.g., during a problem).

"Bank A" has only person with this access.

"Company B" Tech/Security have SUPER.SUPER and is same group.

"Bank C": Tech support maintains super password. Keep record of super logons & Audit SUPER.SUPER. Maintain record of every "stop safeguard" command, and compare to scheduled activity.

"Company D": Has limited use of SUPER.SUPER. When someone does logon to super a highlighted EMS message is sent to Viewpoint until logged off.

SYSGEN'ing safeguard means that if safeguard had a severe problem whole system would have to shutdown. Unlike (e.g.) MVS systems, this might not be acceptable for Tandem shops... availability is key. (In IBM shops, if ACF2, RACF or TOP Secret are not running, then nothing gets done).

Tom Chung / BNS:

Restore issue: how to audit / prevent an Operator, who has access to restore, from altering a critical batch job (e.g. TACL or program), then restore it over production environment & run it.

Comments: Encrypt data. (but can't encrypt every file).

John Fong /RBC:

What utility is available for non Tandem/Safeguard literate people to use to manage ACL's or user administration.

Comment - invest some money in courses to educate staff.

Cathie's comment - CAUnicenter is an option for IBM host mainframe literate people to manage Tandem systems.

John Fong:

Why will Netbatch Plus not support the use of aliases, what are the options available to promote user accountability?

Comments - configure NB jobs to allow for multi user submits.

Cathie to investigate other options.

John Wildfong/ ACCI:

Who is running ODBC Release 2?

Nobody

Kien Truong/CIBC:

Question on alias for operators. How to manage this in a "common" environment... shared terminals, shift changes.

SNS: So far, only it's only "controlled" by the fact of secure rooms, scheduled shifts. i.e., we know who was working at that time.

Recommendation from group: institute a strong policy statement with regard to terminal logoff at shift end.

6) TCP/IP , Network Security: Gary Burke, Tandem.

Gave overall presentation of TCP/IP components, logon requirements.

Various methods: resilient services

Some notes:

Password in clear over LAN (not encrypted).

Configuration Settings:

FTP very general discussion.

There was a question on configuring FTP servers with an idle timeout. John Leeson: you can put entry in "PORTCFM" file: e.g.: $system.ztcpip.ftpserv /highpin on/ timer 600. Server will timeout after 10 minutes of inactivity.

7) Wrap-up/ Mark Wilson SNS

a) from GreenHouse Software & Consulting

- PASSYNC Version 30x

- Enhanced FTPSERV Program Short Documentation

- Products & Consulting Tools

b) Other:

- SNS ALIAS Program Abstract

- Toronto and ITUG Tandem Security SIG Members (SIGNAMES.XLS)

c) Diskette containing:

- SNS - ALIAS program (to identify alias ID of a process).

- GHS.EXE:

GreenHouse Software self-extracting Word Documents,

particularly Secure FTPSERV-E

- PQUALITY.TXT Dos text password quality example (GHS)

- CARLWEB.TXT Email authorizing PASYNC.DOC distribution

- AUMIN1.DOC Australia Security SIG Minutes (OZTUG)

- SIG0321.DOC Agenda for March 21st

- SIGMIN.DOC Minutes from Nov 15th 1996 SIG meeting

- SIGMINV.DOC Vendor supplied info from Nov. 15 meeting (CSP & Tandem/CA)

- SIGNAMES.XLS Security SIG Contact names

Next meeting:

Date: Fri. Jun. 13, 1:00 pm

Location: Bell Sygma Offices, 483 Bay Street

Host: Anne Osso

In order to arrange this and future meetings, we are looking for:

Contact: Mark Wilson or John Leeson @SNS, John Fong @Royal Bank, or Anne Osso @Bell Sygma (next host).

Addendum:

For those who do not yet know, Bill Simpson has left CSP. He was expected at this meeting, but didn't arrive. Apparently, he resigned from (and left) CSP that same day. I have heard he is still working in the security area, but not on Tandem.

Bill was one of the people who helped set up this SIG, and had always been extremely helpful and knowledgeable to all of us. He will be missed in the Tandem Security area.