[Security_sig] 9/15 Conf. call minutes

[Chris Wright]

Attendees:
----------
	Chris Wright (OSDL)
	Mary Edie Meredith (OSDL)
	Emily Ratliff (IBM)
	Dennis Wells (Unisys)

Agenda:
-------

	- Continue through Ed's DCL doc

Actions:
--------


Minutes:
--------

Mary: Quick review of where we are?

Chris: Sure.  Capturing DCL security capabilities required to secure
Linux systems in DCL environments.  Current draft v0.4 has outline
that's reasonably solid.  The document needs work flushing out the
various sections, which is where we are now

Mary: Decided to do that bit-by-bit for sections of document on the mail
list.

Mary: What I hoped to talk about today is the organizational security
policies.

Mary: Should we introduce the nomenclature, e.g. P.AUTH..?

Emily: Yeah, I think this is the first time it's used in the doc.

Mary: <quick run through of policy bits>

Dennis: re: audit susbystem split out from admin, in my experience is not
normaly used.

Emily: do we have justification to make that a requirement?

Chris: recall, these aren't requirements, the document lists
capabilities (functionalties) that are needed for comprehensive security
which should show where there are gaps.  there's no "compliance with the
security spec can't be met because you're missing $foobar requirement."
Ideally, this should be showing areas where there are barriers to
adoption and identifying where resources can be allocated to work on the
barriers.

Dennis: Is there a forum to get feedback from datacenter requirements.

Mary: We do get feedback from end user adivsory council.  For example
they showed audit was a requirement, did they have specific needs to
break out audit admin.

Chris: The take away from that (for me) was that audit was top the list
of missing features.  Once we talked specifics it quickly got to ideal
features over needed features (tamper proof audit logs, etc).  It's
surprisingly difficult to get specific security requirements (and even
when they're given in the form of compliance with some certification,
it's not always clear which parts of the spec are acutally needed).
My concern is that while we're trying to find gaps, projects are quickly
moving forward and solving real problems, writing code, etc.

Emily:  Could up-level or down-level.  Up-level, i.e. what are you (RH,
Novell, IBM, etc...) working towards (strategicaly)?  Taking Linux to
high level certification to get into, for example.

Dennis: We're interested in EAL3/4 CAPP ES7000 mainframe.

Emily: BTW, CAPP/LSPP have sunset plans, dates are unclear.

Chris: Hey, you're done ;-)

Emily: Well, specific to hardware.

Emily:  Can DCL barriers be framed in terms of migration from windows
or solaris...?

Mary: DCL targets solaris short-term, windows long-term

Emily: There are also Linux specific barriers, like MLOSPP has FIPS
requirements that will be a Linux painpoint due to proliferation of
crypto algs..

Chris: I'm concerned that we're spinning wheels and not actively helping
to improve (deliver code) the current state.  For example, the LSPP
effort is identifying gaps and trying to find people to work on them.

Mary: I'd be happy with a list of top five issues, should be start with
list from LSPP folks?

Emily: focus on enterprise vs. small?  e.g. IPSec VPN configuration can
be difficult, esp from smaller enviroments.

Mary: Mostly enterprise.  Haven't resolved this have we?

Emily: Lots of way to approach the problem, so knowing what DCL needs
would help focus.

Mary: We know audit is an issue, being worked on, SELinux usability is
an issue, being worked on.

Emily: Other things...Encrypted filesystems, secure backup, lost backup tapes.

Chris: None of those were specifically cited as lacking by end user
council.