[j-nsp] Supporting Audit Requirements in JUNOS

[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 <jmadrid2 at gmail.com> 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 <sfouant at gmail.com> 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
> > <christian at broknrobot.com> 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 <sfouant at gmail.com>
> 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 at 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 at 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?
>