You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by "HARRIOTT, John" <jo...@baesystems.com> on 2017/04/10 02:50:49 UTC
Logging changes to workflow
Is it possible to log changes to a workflow so they can be captured by a central logging/auditing capability e.g. syslog.
This will allow security auditors to detect changes to a systems configuration e.g. addition/removal/modification of a processor(s).
Thanks
This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:
BAE Systems Australia Limited - Australian Company Number 008 423 005
BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846
BAE Systems Australia Logistics Pty Limited - Australian Company Number 086 228 864
Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
Edinburgh, South Australia, 5111. If the identity of the sending company is
not clear from the content of this email please contact the sender.
This email and any attachments may contain confidential and legally
privileged information. If you are not the intended recipient, do not copy or
disclose its content, but please reply to this email immediately and highlight
the error to the sender and then immediately delete the message.
Re: Logging changes to workflow
Posted by Toivo Adams <to...@gmail.com>.
Hi,
It seems such a reporting task is not yet implemented.
I wonder if you need only output to syslog, can’t this be configured adding
*SyslogAppender* to logback.xml configuration?
And maybe new Logger is also needed in logback.xml?
Which might be Logger name?
Thanks
Toivo
2017-04-11 9:31 GMT+03:00 HARRIOTT, John <jo...@baesystems.com>:
> Hi Joe,
>
> What is meant by the following statement: "From that one can access the
> list of changes from a given offset onward."
> ReportingTask.java is an interface class. That does mean there exists a
> class specifically for reporting configuration changes?
>
> Regards John
>
> -----Original Message-----
> From: Joe Witt [mailto:joe.witt@gmail.com]
> Sent: Tuesday, 11 April 2017 4:02 AM
> To: users@nifi.apache.org
> Subject: Re: Logging changes to workflow
>
> Juan,
>
> They were introduced in https://issues.apache.org/jira/browse/NIFI-986
>
> I don't know if there is a reporting task which leverages this yet but the
> key classes to notice are here:
> ReportingTask [1]
> EventAccess [2]
>
> From that one can access the list of changes from a given offset onward.
>
> [1] https://github.com/apache/nifi/blob/master/nifi-api/src/
> main/java/org/apache/nifi/reporting/ReportingTask.java
> [2] https://github.com/apache/nifi/blob/master/nifi-api/src/
> main/java/org/apache/nifi/reporting/EventAccess.java
>
> Thanks
> Joe
>
> On Mon, Apr 10, 2017 at 2:25 PM, Juan Sequeiros <he...@gmail.com>
> wrote:
> > Hi Joe / all,
> >
> > " we make it available via reporting tasks "
> >
> > What reporting task is that? I've looked at NIFI 1 available reporting
> > tasks and I don't see anything that would let me export "flow
> > configuration history".
> > Coincidentally we are having to meet similar requirement.
> >
> > Our solution was to get that through restAPI but if there is a cleaner
> > way though reporting tasks, would like to experiment with that too.
> >
> > On Mon, Apr 10, 2017 at 9:09 AM Joe Witt <jo...@gmail.com> wrote:
> >>
> >> John
> >>
> >> To build on Andrew's comments there is already a very significant
> >> amount of audit data made available for flow changes. We store this
> >> in an audit database so we can drive some user experiences off it and
> >> we make it available via reporting tasks so one could report this
> >> information to an external system. I believe what you're asking for
> >> is well supported.
> >>
> >> In addition to that sort of configuraiton auditing remember too we
> >> have actual data provenance which shows not just what the
> >> configuration was but the lineage/path that data actually takes.
> >> These too together form an extremely powerful audit basis.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Mon, Apr 10, 2017 at 9:05 AM, Andrew Grande <ap...@gmail.com>
> wrote:
> >> > John, the Flow Configuration History menu item already captures it.
> >> > Does it look like a fit?
> >> >
> >> > Andrew
> >> >
> >> >
> >> > On Sun, Apr 9, 2017, 10:50 PM HARRIOTT, John
> >> > <jo...@baesystems.com>
> >> > wrote:
> >> >>
> >> >> Is it possible to log changes to a workflow so they can be
> >> >> captured by a central logging/auditing capability e.g. syslog.
> >> >>
> >> >> This will allow security auditors to detect changes to a systems
> >> >> configuration e.g. addition/removal/modification of a processor(s).
> >> >>
> >> >>
> >> >>
> >> >> Thanks
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> This email has been sent on behalf of one of the following
> >> >> companies within the BAE Systems Australia group of companies:
> >> >>
> >> >> BAE Systems Australia Limited - Australian Company Number 008
> >> >> 423
> >> >> 005
> >> >> BAE Systems Australia Defence Pty Limited - Australian Company
> >> >> Number
> >> >> 006 870 846
> >> >> BAE Systems Australia Logistics Pty Limited - Australian
> >> >> Company Number 086 228 864
> >> >>
> >> >> Our registered office is Evans Building, Taranaki Road, Edinburgh
> >> >> Parks, Edinburgh, South Australia, 5111. If the identity of the
> >> >> sending company is not clear from the content of this email please
> >> >> contact the sender.
> >> >>
> >> >> This email and any attachments may contain confidential and
> >> >> legally privileged information. If you are not the intended
> >> >> recipient, do not copy or disclose its content, but please reply
> >> >> to this email immediately and highlight the error to the sender
> >> >> and then immediately delete the message.
> This email has been sent on behalf of one of the following companies
> within the BAE Systems Australia group of companies:
>
> BAE Systems Australia Limited - Australian Company Number 008 423 005
> BAE Systems Australia Defence Pty Limited - Australian Company Number
> 006 870 846
> BAE Systems Australia Logistics Pty Limited - Australian Company
> Number 086 228 864
>
> Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
> Edinburgh, South Australia, 5111. If the identity of the sending company is
> not clear from the content of this email please contact the sender.
>
> This email and any attachments may contain confidential and legally
> privileged information. If you are not the intended recipient, do not
> copy or
> disclose its content, but please reply to this email immediately and
> highlight
> the error to the sender and then immediately delete the message.
>
Re: Logging changes to workflow
Posted by Joe Witt <jo...@gmail.com>.
John
The code i referenced in the previous note on this thread points to
the API support for connecting a reporting task to the audit data.
This will give you more stable/reliable information than having a
Logger send the data via syslog/etc.. However, there is no
ReportingTask that I am aware of available in the Apache NiFi codebase
that leverages that function so for now you'd want to write a custom
one with Java or with the scripted reporting task support.
Thanks
Joe
On Tue, Apr 11, 2017 at 2:31 AM, HARRIOTT, John
<jo...@baesystems.com> wrote:
> Hi Joe,
>
> What is meant by the following statement: "From that one can access the list of changes from a given offset onward."
> ReportingTask.java is an interface class. That does mean there exists a class specifically for reporting configuration changes?
>
> Regards John
>
> -----Original Message-----
> From: Joe Witt [mailto:joe.witt@gmail.com]
> Sent: Tuesday, 11 April 2017 4:02 AM
> To: users@nifi.apache.org
> Subject: Re: Logging changes to workflow
>
> Juan,
>
> They were introduced in https://issues.apache.org/jira/browse/NIFI-986
>
> I don't know if there is a reporting task which leverages this yet but the key classes to notice are here:
> ReportingTask [1]
> EventAccess [2]
>
> From that one can access the list of changes from a given offset onward.
>
> [1] https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/reporting/ReportingTask.java
> [2] https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/reporting/EventAccess.java
>
> Thanks
> Joe
>
> On Mon, Apr 10, 2017 at 2:25 PM, Juan Sequeiros <he...@gmail.com> wrote:
>> Hi Joe / all,
>>
>> " we make it available via reporting tasks "
>>
>> What reporting task is that? I've looked at NIFI 1 available reporting
>> tasks and I don't see anything that would let me export "flow
>> configuration history".
>> Coincidentally we are having to meet similar requirement.
>>
>> Our solution was to get that through restAPI but if there is a cleaner
>> way though reporting tasks, would like to experiment with that too.
>>
>> On Mon, Apr 10, 2017 at 9:09 AM Joe Witt <jo...@gmail.com> wrote:
>>>
>>> John
>>>
>>> To build on Andrew's comments there is already a very significant
>>> amount of audit data made available for flow changes. We store this
>>> in an audit database so we can drive some user experiences off it and
>>> we make it available via reporting tasks so one could report this
>>> information to an external system. I believe what you're asking for
>>> is well supported.
>>>
>>> In addition to that sort of configuraiton auditing remember too we
>>> have actual data provenance which shows not just what the
>>> configuration was but the lineage/path that data actually takes.
>>> These too together form an extremely powerful audit basis.
>>>
>>> Thanks
>>> Joe
>>>
>>> On Mon, Apr 10, 2017 at 9:05 AM, Andrew Grande <ap...@gmail.com> wrote:
>>> > John, the Flow Configuration History menu item already captures it.
>>> > Does it look like a fit?
>>> >
>>> > Andrew
>>> >
>>> >
>>> > On Sun, Apr 9, 2017, 10:50 PM HARRIOTT, John
>>> > <jo...@baesystems.com>
>>> > wrote:
>>> >>
>>> >> Is it possible to log changes to a workflow so they can be
>>> >> captured by a central logging/auditing capability e.g. syslog.
>>> >>
>>> >> This will allow security auditors to detect changes to a systems
>>> >> configuration e.g. addition/removal/modification of a processor(s).
>>> >>
>>> >>
>>> >>
>>> >> Thanks
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> This email has been sent on behalf of one of the following
>>> >> companies within the BAE Systems Australia group of companies:
>>> >>
>>> >> BAE Systems Australia Limited - Australian Company Number 008
>>> >> 423
>>> >> 005
>>> >> BAE Systems Australia Defence Pty Limited - Australian Company
>>> >> Number
>>> >> 006 870 846
>>> >> BAE Systems Australia Logistics Pty Limited - Australian
>>> >> Company Number 086 228 864
>>> >>
>>> >> Our registered office is Evans Building, Taranaki Road, Edinburgh
>>> >> Parks, Edinburgh, South Australia, 5111. If the identity of the
>>> >> sending company is not clear from the content of this email please
>>> >> contact the sender.
>>> >>
>>> >> This email and any attachments may contain confidential and
>>> >> legally privileged information. If you are not the intended
>>> >> recipient, do not copy or disclose its content, but please reply
>>> >> to this email immediately and highlight the error to the sender
>>> >> and then immediately delete the message.
> This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:
>
> BAE Systems Australia Limited - Australian Company Number 008 423 005
> BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846
> BAE Systems Australia Logistics Pty Limited - Australian Company Number 086 228 864
>
> Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
> Edinburgh, South Australia, 5111. If the identity of the sending company is
> not clear from the content of this email please contact the sender.
>
> This email and any attachments may contain confidential and legally
> privileged information. If you are not the intended recipient, do not copy or
> disclose its content, but please reply to this email immediately and highlight
> the error to the sender and then immediately delete the message.
RE: Logging changes to workflow
Posted by "HARRIOTT, John" <jo...@baesystems.com>.
Hi Joe,
What is meant by the following statement: "From that one can access the list of changes from a given offset onward."
ReportingTask.java is an interface class. That does mean there exists a class specifically for reporting configuration changes?
Regards John
-----Original Message-----
From: Joe Witt [mailto:joe.witt@gmail.com]
Sent: Tuesday, 11 April 2017 4:02 AM
To: users@nifi.apache.org
Subject: Re: Logging changes to workflow
Juan,
They were introduced in https://issues.apache.org/jira/browse/NIFI-986
I don't know if there is a reporting task which leverages this yet but the key classes to notice are here:
ReportingTask [1]
EventAccess [2]
From that one can access the list of changes from a given offset onward.
[1] https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/reporting/ReportingTask.java
[2] https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/reporting/EventAccess.java
Thanks
Joe
On Mon, Apr 10, 2017 at 2:25 PM, Juan Sequeiros <he...@gmail.com> wrote:
> Hi Joe / all,
>
> " we make it available via reporting tasks "
>
> What reporting task is that? I've looked at NIFI 1 available reporting
> tasks and I don't see anything that would let me export "flow
> configuration history".
> Coincidentally we are having to meet similar requirement.
>
> Our solution was to get that through restAPI but if there is a cleaner
> way though reporting tasks, would like to experiment with that too.
>
> On Mon, Apr 10, 2017 at 9:09 AM Joe Witt <jo...@gmail.com> wrote:
>>
>> John
>>
>> To build on Andrew's comments there is already a very significant
>> amount of audit data made available for flow changes. We store this
>> in an audit database so we can drive some user experiences off it and
>> we make it available via reporting tasks so one could report this
>> information to an external system. I believe what you're asking for
>> is well supported.
>>
>> In addition to that sort of configuraiton auditing remember too we
>> have actual data provenance which shows not just what the
>> configuration was but the lineage/path that data actually takes.
>> These too together form an extremely powerful audit basis.
>>
>> Thanks
>> Joe
>>
>> On Mon, Apr 10, 2017 at 9:05 AM, Andrew Grande <ap...@gmail.com> wrote:
>> > John, the Flow Configuration History menu item already captures it.
>> > Does it look like a fit?
>> >
>> > Andrew
>> >
>> >
>> > On Sun, Apr 9, 2017, 10:50 PM HARRIOTT, John
>> > <jo...@baesystems.com>
>> > wrote:
>> >>
>> >> Is it possible to log changes to a workflow so they can be
>> >> captured by a central logging/auditing capability e.g. syslog.
>> >>
>> >> This will allow security auditors to detect changes to a systems
>> >> configuration e.g. addition/removal/modification of a processor(s).
>> >>
>> >>
>> >>
>> >> Thanks
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> This email has been sent on behalf of one of the following
>> >> companies within the BAE Systems Australia group of companies:
>> >>
>> >> BAE Systems Australia Limited - Australian Company Number 008
>> >> 423
>> >> 005
>> >> BAE Systems Australia Defence Pty Limited - Australian Company
>> >> Number
>> >> 006 870 846
>> >> BAE Systems Australia Logistics Pty Limited - Australian
>> >> Company Number 086 228 864
>> >>
>> >> Our registered office is Evans Building, Taranaki Road, Edinburgh
>> >> Parks, Edinburgh, South Australia, 5111. If the identity of the
>> >> sending company is not clear from the content of this email please
>> >> contact the sender.
>> >>
>> >> This email and any attachments may contain confidential and
>> >> legally privileged information. If you are not the intended
>> >> recipient, do not copy or disclose its content, but please reply
>> >> to this email immediately and highlight the error to the sender
>> >> and then immediately delete the message.
This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:
BAE Systems Australia Limited - Australian Company Number 008 423 005
BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846
BAE Systems Australia Logistics Pty Limited - Australian Company Number 086 228 864
Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
Edinburgh, South Australia, 5111. If the identity of the sending company is
not clear from the content of this email please contact the sender.
This email and any attachments may contain confidential and legally
privileged information. If you are not the intended recipient, do not copy or
disclose its content, but please reply to this email immediately and highlight
the error to the sender and then immediately delete the message.
Re: Logging changes to workflow
Posted by Joe Witt <jo...@gmail.com>.
Juan,
They were introduced in https://issues.apache.org/jira/browse/NIFI-986
I don't know if there is a reporting task which leverages this yet but
the key classes to notice are here:
ReportingTask [1]
EventAccess [2]
From that one can access the list of changes from a given offset onward.
[1] https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/reporting/ReportingTask.java
[2] https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/reporting/EventAccess.java
Thanks
Joe
On Mon, Apr 10, 2017 at 2:25 PM, Juan Sequeiros <he...@gmail.com> wrote:
> Hi Joe / all,
>
> " we make it available via reporting tasks "
>
> What reporting task is that? I've looked at NIFI 1 available reporting tasks
> and I don't see anything that would let me export "flow configuration
> history".
> Coincidentally we are having to meet similar requirement.
>
> Our solution was to get that through restAPI but if there is a cleaner way
> though reporting tasks, would like to experiment with that too.
>
> On Mon, Apr 10, 2017 at 9:09 AM Joe Witt <jo...@gmail.com> wrote:
>>
>> John
>>
>> To build on Andrew's comments there is already a very significant
>> amount of audit data made available for flow changes. We store this
>> in an audit database so we can drive some user experiences off it and
>> we make it available via reporting tasks so one could report this
>> information to an external system. I believe what you're asking for
>> is well supported.
>>
>> In addition to that sort of configuraiton auditing remember too we
>> have actual data provenance which shows not just what the
>> configuration was but the lineage/path that data actually takes.
>> These too together form an extremely powerful audit basis.
>>
>> Thanks
>> Joe
>>
>> On Mon, Apr 10, 2017 at 9:05 AM, Andrew Grande <ap...@gmail.com> wrote:
>> > John, the Flow Configuration History menu item already captures it. Does
>> > it
>> > look like a fit?
>> >
>> > Andrew
>> >
>> >
>> > On Sun, Apr 9, 2017, 10:50 PM HARRIOTT, John
>> > <jo...@baesystems.com>
>> > wrote:
>> >>
>> >> Is it possible to log changes to a workflow so they can be captured by
>> >> a
>> >> central logging/auditing capability e.g. syslog.
>> >>
>> >> This will allow security auditors to detect changes to a systems
>> >> configuration e.g. addition/removal/modification of a processor(s).
>> >>
>> >>
>> >>
>> >> Thanks
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> This email has been sent on behalf of one of the following companies
>> >> within the BAE Systems Australia group of companies:
>> >>
>> >> BAE Systems Australia Limited - Australian Company Number 008 423
>> >> 005
>> >> BAE Systems Australia Defence Pty Limited - Australian Company
>> >> Number
>> >> 006 870 846
>> >> BAE Systems Australia Logistics Pty Limited - Australian Company
>> >> Number 086 228 864
>> >>
>> >> Our registered office is Evans Building, Taranaki Road, Edinburgh
>> >> Parks,
>> >> Edinburgh, South Australia, 5111. If the identity of the sending
>> >> company is
>> >> not clear from the content of this email please contact the sender.
>> >>
>> >> This email and any attachments may contain confidential and legally
>> >> privileged information. If you are not the intended recipient, do not
>> >> copy
>> >> or disclose its content, but please reply to this email immediately and
>> >> highlight the error to the sender and then immediately delete the
>> >> message.
Re: Logging changes to workflow
Posted by Juan Sequeiros <he...@gmail.com>.
Hi Joe / all,
" we make it available via reporting tasks "
What reporting task is that? I've looked at NIFI 1 available reporting
tasks and I don't see anything that would let me export "flow configuration
history".
Coincidentally we are having to meet similar requirement.
Our solution was to get that through restAPI but if there is a cleaner way
though reporting tasks, would like to experiment with that too.
On Mon, Apr 10, 2017 at 9:09 AM Joe Witt <jo...@gmail.com> wrote:
> John
>
> To build on Andrew's comments there is already a very significant
> amount of audit data made available for flow changes. We store this
> in an audit database so we can drive some user experiences off it and
> we make it available via reporting tasks so one could report this
> information to an external system. I believe what you're asking for
> is well supported.
>
> In addition to that sort of configuraiton auditing remember too we
> have actual data provenance which shows not just what the
> configuration was but the lineage/path that data actually takes.
> These too together form an extremely powerful audit basis.
>
> Thanks
> Joe
>
> On Mon, Apr 10, 2017 at 9:05 AM, Andrew Grande <ap...@gmail.com> wrote:
> > John, the Flow Configuration History menu item already captures it. Does
> it
> > look like a fit?
> >
> > Andrew
> >
> >
> > On Sun, Apr 9, 2017, 10:50 PM HARRIOTT, John <
> john.harriott@baesystems.com>
> > wrote:
> >>
> >> Is it possible to log changes to a workflow so they can be captured by a
> >> central logging/auditing capability e.g. syslog.
> >>
> >> This will allow security auditors to detect changes to a systems
> >> configuration e.g. addition/removal/modification of a processor(s).
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> This email has been sent on behalf of one of the following companies
> >> within the BAE Systems Australia group of companies:
> >>
> >> BAE Systems Australia Limited - Australian Company Number 008 423
> 005
> >> BAE Systems Australia Defence Pty Limited - Australian Company
> Number
> >> 006 870 846
> >> BAE Systems Australia Logistics Pty Limited - Australian Company
> >> Number 086 228 864
> >>
> >> Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
> >> Edinburgh, South Australia, 5111. If the identity of the sending
> company is
> >> not clear from the content of this email please contact the sender.
> >>
> >> This email and any attachments may contain confidential and legally
> >> privileged information. If you are not the intended recipient, do not
> copy
> >> or disclose its content, but please reply to this email immediately and
> >> highlight the error to the sender and then immediately delete the
> message.
>
Re: Logging changes to workflow
Posted by Joe Witt <jo...@gmail.com>.
John
To build on Andrew's comments there is already a very significant
amount of audit data made available for flow changes. We store this
in an audit database so we can drive some user experiences off it and
we make it available via reporting tasks so one could report this
information to an external system. I believe what you're asking for
is well supported.
In addition to that sort of configuraiton auditing remember too we
have actual data provenance which shows not just what the
configuration was but the lineage/path that data actually takes.
These too together form an extremely powerful audit basis.
Thanks
Joe
On Mon, Apr 10, 2017 at 9:05 AM, Andrew Grande <ap...@gmail.com> wrote:
> John, the Flow Configuration History menu item already captures it. Does it
> look like a fit?
>
> Andrew
>
>
> On Sun, Apr 9, 2017, 10:50 PM HARRIOTT, John <jo...@baesystems.com>
> wrote:
>>
>> Is it possible to log changes to a workflow so they can be captured by a
>> central logging/auditing capability e.g. syslog.
>>
>> This will allow security auditors to detect changes to a systems
>> configuration e.g. addition/removal/modification of a processor(s).
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>>
>> This email has been sent on behalf of one of the following companies
>> within the BAE Systems Australia group of companies:
>>
>> BAE Systems Australia Limited - Australian Company Number 008 423 005
>> BAE Systems Australia Defence Pty Limited - Australian Company Number
>> 006 870 846
>> BAE Systems Australia Logistics Pty Limited - Australian Company
>> Number 086 228 864
>>
>> Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
>> Edinburgh, South Australia, 5111. If the identity of the sending company is
>> not clear from the content of this email please contact the sender.
>>
>> This email and any attachments may contain confidential and legally
>> privileged information. If you are not the intended recipient, do not copy
>> or disclose its content, but please reply to this email immediately and
>> highlight the error to the sender and then immediately delete the message.
Re: Logging changes to workflow
Posted by Andrew Grande <ap...@gmail.com>.
John, the Flow Configuration History menu item already captures it. Does it
look like a fit?
Andrew
On Sun, Apr 9, 2017, 10:50 PM HARRIOTT, John <jo...@baesystems.com>
wrote:
> Is it possible to log changes to a workflow so they can be captured by a
> central logging/auditing capability e.g. syslog.
>
> This will allow security auditors to detect changes to a systems
> configuration e.g. addition/removal/modification of a processor(s).
>
>
>
> Thanks
>
>
>
>
>
>
>
> This email has been sent on behalf of one of the following companies
> within the BAE Systems Australia group of companies:
>
> BAE Systems Australia Limited - Australian Company Number 008 423 005
> BAE Systems Australia Defence Pty Limited - Australian Company Number
> 006 870 846
> BAE Systems Australia Logistics Pty Limited - Australian Company
> Number 086 228 864
>
> Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
> Edinburgh, South Australia, 5111. If the identity of the sending company is
> not clear from the content of this email please contact the sender.
>
> This email and any attachments may contain confidential and legally
> privileged information. If you are not the intended recipient, do not copy
> or disclose its content, but please reply to this email immediately and
> highlight the error to the sender and then immediately delete the message.
>