Re: [OPSEC] charter skeleton rev5

[Merike Kaeo <[e-mail]>]

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?>".

- 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?!?

- 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.

-- 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.......]

-- 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/opsec
>


_______________________________________________
OPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/opsec