[j-nsp] Supporting Audit Requirements in JUNOS

Jose Madrid jmadrid2 at gmail.com
Wed Jul 23 09:32:28 EDT 2008


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?


More information about the juniper-nsp mailing list