Re: [j-nsp] Supporting Audit Requirements in JUNOS

2008-07-23 Thread Jose Madrid
Going back to Christian's point, Rancid doesn't know who made the
changes and if there are multiple changes between rancid run-times, it
will pick up various changes and not just the one in particular.  I
currently use a mixture of rancid and logs from devices to see who
logged in at a time nearest when the change was picked up.  This is
less than ideal solution, but all we currently have.

On Tue, Jul 22, 2008 at 5:17 PM, Stefan Fouant [EMAIL PROTECTED] wrote:
 Yes, we have a change management process in place, but my job is to
 enforce it.  Normally, we get the change request submitted, approved,
 then we push the change to the firewall.  However, there is no simple
 way to correlate the committed change to the actual change request.
 My idea was to enforce the use of comments on commits along the lines
 of:

 commit comment This is for Change Request Ticket # 123

 As I alluded and Ben Bird confirmed, it seems that the most reasonable
 way to accomplish this goal is through the use of deny-commands to
 force the use of any commit which does not contain the string
 'comment' in it.  This is easier said than done, and I'll need to
 brush up on my RegEx skills:

 I wanted to do something along the lines of :

 set system login class engineering deny-commands ^commit.*!comment.*$

 but the damn * is being greedy and matching everything... so, I just
 need to play around with it a bit.

 On Tue, Jul 22, 2008 at 5:06 PM, Christian Koch
 [EMAIL PROTECTED] wrote:
 Hello Stefan -

 I have been going through multiple SAS70's for the past year now...

 however, we have a change management process, which changes need to go
 through in order for a change to be allowed. so everything is all
 documented..

 submit change request - review - approve - push change - archive/document

 i realize this may not be feasible for everyone and being in different
 situations, environments, etc.. but its not too much of a hassle, also if
 you are using something like rancid, or some script or
 other network management product to fetch and save configs when changes are
 made, i think you are in the clear.


 on a side note, if the commit script thing works well, i think that's an
 awesome idea


 christian




 On Tue, Jul 22, 2008 at 3:38 PM, Stefan Fouant [EMAIL PROTECTED] wrote:

 Hi folks,

 As part of SAS 70 Audit requirements, I need to ensure that anytime a
 firewall change is made on my routers a description of that change is
 recorded.  I suppose I could force this by using commit scripts and
 forcing the use of annotate on anything in the firewall-filters
 stanza, although this could be rather unwieldy in it's implementation.
  My preference would be to ensure that anytime the configuration is
 committed a 'commit comment comment' is used, but doesn't seem that
 I can use commit-scripts to force that since a commit is not a
 configuration variable.  I wonder if I could use allow-commands or
 deny-commands to accomplish something along these lines...

 Has anyone attempted anything similar?  What have you folks done to
 support SAS 70 Audit requirements?

 Thanks,

 --
 Stefan Fouant
 Principal Network Engineer
 NeuStar, Inc. - http://www.neustar.biz
 GPG Key ID: 0xB5E3803D
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp





 --
 Stefan Fouant
 Principal Network Engineer
 NeuStar, Inc. - http://www.neustar.biz
 GPG Key ID: 0xB5E3803D
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp




-- 
It has to start somewhere, it has to start sometime. What better place
than here? What better time than now?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Supporting Audit Requirements in JUNOS

2008-07-23 Thread Christian Koch
i think a combination of things like this is fine, in most case, auditors
just want to verify you are actually doing what you say you are...how you do
it, whether  ideal, complicated or simple, doesn't really matter to them for
the most part.

like i said if you have some type of change control procedure or policy, you
can associate the changes and the requester of the change with actual proof
of the change (logs/rancid/tftp/etc)






On Wed, Jul 23, 2008 at 9:32 AM, Jose Madrid [EMAIL PROTECTED] wrote:

 Going back to Christian's point, Rancid doesn't know who made the
 changes and if there are multiple changes between rancid run-times, it
 will pick up various changes and not just the one in particular.  I
 currently use a mixture of rancid and logs from devices to see who
 logged in at a time nearest when the change was picked up.  This is
 less than ideal solution, but all we currently have.

 On Tue, Jul 22, 2008 at 5:17 PM, Stefan Fouant [EMAIL PROTECTED] wrote:
  Yes, we have a change management process in place, but my job is to
  enforce it.  Normally, we get the change request submitted, approved,
  then we push the change to the firewall.  However, there is no simple
  way to correlate the committed change to the actual change request.
  My idea was to enforce the use of comments on commits along the lines
  of:
 
  commit comment This is for Change Request Ticket # 123
 
  As I alluded and Ben Bird confirmed, it seems that the most reasonable
  way to accomplish this goal is through the use of deny-commands to
  force the use of any commit which does not contain the string
  'comment' in it.  This is easier said than done, and I'll need to
  brush up on my RegEx skills:
 
  I wanted to do something along the lines of :
 
  set system login class engineering deny-commands ^commit.*!comment.*$
 
  but the damn * is being greedy and matching everything... so, I just
  need to play around with it a bit.
 
  On Tue, Jul 22, 2008 at 5:06 PM, Christian Koch
  [EMAIL PROTECTED] wrote:
  Hello Stefan -
 
  I have been going through multiple SAS70's for the past year now...
 
  however, we have a change management process, which changes need to go
  through in order for a change to be allowed. so everything is all
  documented..
 
  submit change request - review - approve - push change -
 archive/document
 
  i realize this may not be feasible for everyone and being in different
  situations, environments, etc.. but its not too much of a hassle, also
 if
  you are using something like rancid, or some script or
  other network management product to fetch and save configs when changes
 are
  made, i think you are in the clear.
 
 
  on a side note, if the commit script thing works well, i think that's an
  awesome idea
 
 
  christian
 
 
 
 
  On Tue, Jul 22, 2008 at 3:38 PM, Stefan Fouant [EMAIL PROTECTED]
 wrote:
 
  Hi folks,
 
  As part of SAS 70 Audit requirements, I need to ensure that anytime a
  firewall change is made on my routers a description of that change is
  recorded.  I suppose I could force this by using commit scripts and
  forcing the use of annotate on anything in the firewall-filters
  stanza, although this could be rather unwieldy in it's implementation.
   My preference would be to ensure that anytime the configuration is
  committed a 'commit comment comment' is used, but doesn't seem that
  I can use commit-scripts to force that since a commit is not a
  configuration variable.  I wonder if I could use allow-commands or
  deny-commands to accomplish something along these lines...
 
  Has anyone attempted anything similar?  What have you folks done to
  support SAS 70 Audit requirements?
 
  Thanks,
 
  --
  Stefan Fouant
  Principal Network Engineer
  NeuStar, Inc. - http://www.neustar.biz
  GPG Key ID: 0xB5E3803D
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 
 
 
 
  --
  Stefan Fouant
  Principal Network Engineer
  NeuStar, Inc. - http://www.neustar.biz
  GPG Key ID: 0xB5E3803D
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 



 --
 It has to start somewhere, it has to start sometime. What better place
 than here? What better time than now?

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Supporting Audit Requirements in JUNOS

2008-07-23 Thread Eric Van Tol
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:juniper-nsp-
 [EMAIL PROTECTED] On Behalf Of Jose Madrid
 Sent: Wednesday, July 23, 2008 9:32 AM
 To: Stefan Fouant
 Cc: Juniper-Nsp
 Subject: Re: [j-nsp] Supporting Audit Requirements in JUNOS

 Going back to Christian's point, Rancid doesn't know who made the
 changes and if there are multiple changes between rancid run-times,
 it
 will pick up various changes and not just the one in particular.  I
 currently use a mixture of rancid and logs from devices to see who
 logged in at a time nearest when the change was picked up.  This is
 less than ideal solution, but all we currently have.

Using a configuration management application like Solarwinds Cirrus to push the 
changes out might accomplish what you need.  You can make changes to the 
configuration on the server and add comments to the particular job.  In 
addition, if changes are made to a device that supports configuration change 
traps, you can configure Cirrus to listen for the trap and immediately download 
the configuration of the device, thereby picking up on those changes made in 
between scheduled downloads.

If you want to go the open-source route, I am sure that a similar type of 
change notification can be implemented with Rancid and net-snmp through the use 
of some scripting.

That said, if you find a way to force a 'commit comment', please let everyone 
know.  I'd be interested in this as well.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Supporting Audit Requirements in JUNOS

2008-07-23 Thread Stefan Fouant
Yeah, I tried something along very similar lines, but I think you are
right, what I am trying to accomplish may not be possible with JUNOS
regexes - I was hoping the regex engine was a bit more powerful
considering JUNOS' rich UNIX background.  What I wanted to do was to
allow the various commits, such as 'commit synchronize comment',
'commit at time comment', etc. - so really what I am looking for is
a way to ensure any type of commit operation is permitted so long as
it has the 'comment' option, or vice-versa, deny any commit operation
which does not have the 'comment' option.

I thought JUNOS regexes were POSIX-compliant.  Does anyone know if
JUNOS supports Extended Regular Expressions or does it just support
Basic Regular Expressions?

Cheers!

-- 
Stefan Fouant
Principal Network Engineer
NeuStar, Inc. - http://www.neustar.biz
GPG Key ID: 0xB5E3803D

On Wed, Jul 23, 2008 at 6:18 AM, Benny Amorsen [EMAIL PROTECTED] wrote:
 Stefan Fouant [EMAIL PROTECTED] writes:

 set system login class engineering deny-commands ^commit.*!comment.*$

 This is practically impossible to accomplish with one regex. (I think
 you can do it with perl regexes, but I am not sure how fancy JunOS
 regexes are.)

 How about:

 set system login class engineering allow-commands ^commit.*comment
 set system login class engineering deny-commands ^commit

 This assumes that JunOS processes allow before deny, and that it
 implicitly allows everything not matched by either allow-commands or
 deny-commands.

 /Benny
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Supporting Audit Requirements in JUNOS

2008-07-23 Thread Stefan Fouant
U... anyone smell a feature request? :)

-- 
Stefan Fouant
Principal Network Engineer
NeuStar, Inc. - http://www.neustar.biz
GPG Key ID: 0xB5E3803D

On Wed, Jul 23, 2008 at 9:50 AM, Eric Van Tol [EMAIL PROTECTED] wrote:
 That said, if you find a way to force a 'commit comment', please let everyone 
 know.  I'd be interested in this as well.

 -evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



Re: [j-nsp] Supporting Audit Requirements in JUNOS

2008-07-23 Thread Stefan Fouant
We are currently using TACACS+ for authorization, but not
accounting... I suppose we could enable TACACS+ for accounting as
well, but was worried about the induced latency between our TACACS+
servers and some of our nodes which in some cases are separated by
many router hops and thousands of miles of fiber.

On Wed, Jul 23, 2008 at 11:16 AM, Eugeniu Patrascu [EMAIL PROTECTED] wrote:
 Jose Madrid wrote:

 Going back to Christian's point, Rancid doesn't know who made the
 changes and if there are multiple changes between rancid run-times, it
 will pick up various changes and not just the one in particular.  I
 currently use a mixture of rancid and logs from devices to see who
 logged in at a time nearest when the change was picked up.  This is
 less than ideal solution, but all we currently have.


 Wouldn't TACACS+ solve the 'who' and the 'what' and the 'when' ?
 Parsing the log files and summarizing them shouldn't take log for a Perl
 guy.




-- 
Stefan Fouant
Principal Network Engineer
NeuStar, Inc. - http://www.neustar.biz
GPG Key ID: 0xB5E3803D
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[j-nsp] Supporting Audit Requirements in JUNOS

2008-07-22 Thread Stefan Fouant
Hi folks,

As part of SAS 70 Audit requirements, I need to ensure that anytime a
firewall change is made on my routers a description of that change is
recorded.  I suppose I could force this by using commit scripts and
forcing the use of annotate on anything in the firewall-filters
stanza, although this could be rather unwieldy in it's implementation.
 My preference would be to ensure that anytime the configuration is
committed a 'commit comment comment' is used, but doesn't seem that
I can use commit-scripts to force that since a commit is not a
configuration variable.  I wonder if I could use allow-commands or
deny-commands to accomplish something along these lines...

Has anyone attempted anything similar?  What have you folks done to
support SAS 70 Audit requirements?

Thanks,

-- 
Stefan Fouant
Principal Network Engineer
NeuStar, Inc. - http://www.neustar.biz
GPG Key ID: 0xB5E3803D
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Supporting Audit Requirements in JUNOS

2008-07-22 Thread Christian Koch
Hello Stefan -

I have been going through multiple SAS70's for the past year now...

however, we have a change management process, which changes need to go
through in order for a change to be allowed. so everything is all
documented..

submit change request - review - approve - push change - archive/document

i realize this may not be feasible for everyone and being in different
situations, environments, etc.. but its not too much of a hassle, also if
you are using something like rancid, or some script or
other network management product to fetch and save configs when changes are
made, i think you are in the clear.


on a side note, if the commit script thing works well, i think that's an
awesome idea


christian




On Tue, Jul 22, 2008 at 3:38 PM, Stefan Fouant [EMAIL PROTECTED] wrote:

 Hi folks,

 As part of SAS 70 Audit requirements, I need to ensure that anytime a
 firewall change is made on my routers a description of that change is
 recorded.  I suppose I could force this by using commit scripts and
 forcing the use of annotate on anything in the firewall-filters
 stanza, although this could be rather unwieldy in it's implementation.
  My preference would be to ensure that anytime the configuration is
 committed a 'commit comment comment' is used, but doesn't seem that
 I can use commit-scripts to force that since a commit is not a
 configuration variable.  I wonder if I could use allow-commands or
 deny-commands to accomplish something along these lines...

 Has anyone attempted anything similar?  What have you folks done to
 support SAS 70 Audit requirements?

 Thanks,

 --
 Stefan Fouant
 Principal Network Engineer
 NeuStar, Inc. - http://www.neustar.biz
 GPG Key ID: 0xB5E3803D
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp