Re: [OPSEC] charter skeleton rev5

Merike Kaeo wrote:
> I just re-read all discussion from charter skeleton 3 onwards and here
> is some input from me:
> 
> - regarding work with other wg's.   Can we have a paragraph in the
> charter that says something like (and I take some wording from Dan
> Roascanu's comment as well as IPPM wg (where I remember this came up
> when I was co-chair there):
> 
> " The principal input of the Working Group are operational experience
> and needs.  The intended output of the wg is to provide guidance to the
> operators community as well as to Working Groups that develop protocols
> or the community of protocol developers at large to promote consistent
> approaches for supporting existing operational security practices and to
> promote new approaches where operationally desired.  Within the IETF
> process, OPsec security practice documents will be subject to as
> rigorous a scrutiny for usefulness, clarity, and accuracy as other
> protocol standards. The OPsec WG will interact with other areas of IETF
> activity whose scope intersect with the requirement of these specific
> practices. These include working groups such as BMWG, v6ops, and <insert
> others?>".

I like the tenor of this, but I am also in favor of compactness, and  I
think rev 5 is quite attractive in the extent to which it is pared back
to a minimalist core.

would you consider it incomplete without this sentiment?

> - in v6ops there's discussion on
> draft-ietf-v6ops-rfc3330-for-ipv6-04.txt .......specific to which
> prefixes should get filtered.......we probably want to support/comment
> on that work?!?

One of the concerns I have with enterprise networks in general but also
with forwarding and control plane protection is the congruence of policy
between ipv4 and ipv6 configuration. So I would agree and if possible
amplify that sentiment.

> - Some work items I see as relevant:
> 
>  -- IPv6 specific operational security concerns (despite common 'it's no
> different than v4' comments) I think there's things like RA
> advertisement suppression and some similar things that may need some
> consideration.

Indeed... Operationally it's easy enough to respond to and mitigate
sources of rogue's RA's but can you suppress them a priori without
features that may/probably do not exist in your switch platform?
Practice wise there's something be said for not relying on RA's when
your devices are going to be statically configured.

> -- logging document...definitely needs to be included somehow....is Tina
> signed up for the work?  [I totally am in sync with George's comment a
> few weeks ago that getting operator input was tough.......especially as
> doc editors.........it is important to get people signed up for the
> writing part....and no, I'm not volunteering right now.......]

Tina has expressed interest I know she's busy so I have avoided
hasseling her.

> -- AAA related things...how devices get authenticated to and how
> activities get logged/audited
> 
> One thing that I see in practice is that things that are a 'duh - of
> course you would do that'  is not something that's second nature to all
> operators, especially the ones with less experience.  And make that
> ditto for new equipment vendors.  I have a story where I had to explain
> a year ago why NTP was important for timestamping of logs :)   
> Anyhow.....just some thoughts.....sorry for late contribution........
> 
> - merike
> 
> On Jan 9, 2008, at 3:47 PM, Joel Jaeggli wrote:
> 
>> This version incorporates comments from:
>>
>> Ron Bonica
>> Danny McPherson
>> Dan Romascanu
>> George Jones
>>
>>
>> ----
>>
>> Goals:
>>
>> The OPSEC WG will document best current practices with regard to network
>> security. In particular an effort will be made to clarify the rational
>> supporting current operational practice, address gaps in currently
>> understood best practices for forwarding, control plane, and management
>> plane security and make clear the liabilities inherent in security
>> practices where they exist.
>>
>> Scope:
>>
>> The scope of the OPSEC WG is intended to include the protection and
>> secure operation of the forwarding, control and management planes.
>>
>> Documentation of best common practices, revision of existing operational
>> security practices documents and proposals for new approaches to
>> operational challenges are in scope.
>>
>> Method:
>>
>> It is expected that the work product of the working group will
>> fall into the category of best current practices documents. Taxonomy or
>> problem statement documents may provide a basis for best current
>> practices documents.
>>
>> Best Current Practices Document
>>
>> For each topic addressed, a document will be produced that attempts to
>> capture current practices related to secure operation. This will be
>> primarily based on operational experience. Each entry will list:
>>
>> * threats addressed,
>>
>> * current practices for addressing the threat,
>>
>> * protocols, tools and technologies extant at the time of    
>> writing that are used to address the threat,
>>
>> * the possibility that a solution does not exist within existing tools
>> or technologies.
>>
>> Taxonomy and Problem Statement Documents
>>
>> A document which attempts to describe the scope of particular
>> operational security challenge or problem space without necessarily
>> coming to a conclusion or proposing a solution. Such a document might be
>> a precursor to a  best common practices document.
>>
>> While the principal input of the Working Group are operational
>> experience and needs, the output should be directed both to provide
>> guidance to the operators community as well as to Working Groups that
>> develop protocols or the community of protocol developers at large, as
>> well as to the implementers of these protocols.
>>
>> Non-Goals:
>>
>> The Operations security working group is not the place to do new
>> protocols or requirements documents.
>>
>> New protocol development or requirements work should be addressed in a
>> working group chartered in the appropriate area or as individual
>> submissions. The OPSEC WG may take on documents related to
>> the practices of using such work.
>>
>>
>>
>>
>>
>> _______________________________________________
>> OPSEC mailing list
>> OPSEC@ietf.org
>> https://www1.ietf.org/mailman/listinfo/opsec
>>
> 
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/opsec
> 

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/opsec