Centralized Standard Name Distribution (UNCLASSIFIED)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Centralized Standard Name Distribution (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification: UNCLASSIFIED
Caveats: NONE

I'm running into problems in my automated data sharing implementations based on needing to have standardized names for organizations, locations, systems, etc.  In response, we're looking at building out a centralized name maintenance capability for our cyber reporting functionality.

We've started system design and built out XML schemas to support distribution and maintenance of standardized names across the enterprise.

I've talked with several vendors about the concept and there seems to be a common need for this type of capability across the board.

Since DoD vendors will have to build interfaces to consume, use, and tag exported data with standardized names using some standardized schema, I'm thinking this effort may be worth trying to standardize across the SCAP community (maybe even larger communities?).

I've attached a short white paper describing the effort, definitions, requirements, etc.  If I get responses back, I can share XML schemas and business logic we're coordinating.

Also, I can present this at our next SCAP Developer Days (assuming we have one).

Let me know if you believe this capability merits a community effort.  I'll assume silence indicates a lack of interest.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]



Classification: UNCLASSIFIED
Caveats: NONE



Generalized Enterprise Name Maintenance 2012-02-03.docx (57K) Download Attachment
smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Centralized Standard Name Distribution (UNCLASSIFIED)

Waltermire, David A.
Thanks. I'll take a look and provide feedback. Have you looked at using Asset identification 1.1 as part of this strategy?  It has records for organizations, locations, persons, systems and other info.  All of these can be used by ARF 1.1 for reporting.

Thanks,
Dave

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Friday, February 03, 2012 5:10 PM
To: SCAP-DEV
Subject: Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I'm running into problems in my automated data sharing implementations based on needing to have standardized names for organizations, locations, systems, etc.  In response, we're looking at building out a centralized name maintenance capability for our cyber reporting functionality.

We've started system design and built out XML schemas to support distribution and maintenance of standardized names across the enterprise.

I've talked with several vendors about the concept and there seems to be a common need for this type of capability across the board.

Since DoD vendors will have to build interfaces to consume, use, and tag exported data with standardized names using some standardized schema, I'm thinking this effort may be worth trying to standardize across the SCAP community (maybe even larger communities?).

I've attached a short white paper describing the effort, definitions, requirements, etc.  If I get responses back, I can share XML schemas and business logic we're coordinating.

Also, I can present this at our next SCAP Developer Days (assuming we have one).

Let me know if you believe this capability merits a community effort.  I'll assume silence indicates a lack of interest.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]



Classification: UNCLASSIFIED
Caveats: NONE
Reply | Threaded
Open this post in threaded view
|

Re: Centralized Standard Name Distribution (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
In reply to this post by WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification: UNCLASSIFIED
Caveats: NONE

This isn't directly about reporting.  It's a name distribution and maintenance solution.  The names distributed are intended to be metadata tags to support using ARF and ASR, but neither ARF or ASR address the problem of ensuring all reporting endpoints and repositories have the same list of names and relationships between names.  This is more of a "content distribution" solution versus a reporting solution.  I envision the name maintenance and distribution subsystem ultimately becoming part of our Digital Policy Management System.

If we ever address risk scoring as a standards problem, there's a similar problem for distributing continuously updated severities for use in calculating risk scores.

Let me know what you think.

- Joe

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]

On Fri, Feb 3, 2012 at 7:48 PM, Waltermire, David A. <[hidden email]> wrote:


        Thanks. I'll take a look and provide feedback. Have you looked at using Asset identification 1.1 as part of this strategy?  It has records for organizations, locations, persons, systems and other info.  All of these can be used by ARF 1.1 for reporting.
       
        Thanks,
        Dave
       
        -----Original Message-----
        From: [hidden email] [mailto:[hidden email]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
        Sent: Friday, February 03, 2012 5:10 PM
        To: SCAP-DEV
        Subject: Centralized Standard Name Distribution (UNCLASSIFIED)
       
        Classification: UNCLASSIFIED
        Caveats: NONE
       
        I'm running into problems in my automated data sharing implementations based on needing to have standardized names for organizations, locations, systems, etc.  In response, we're looking at building out a centralized name maintenance capability for our cyber reporting functionality.
       
        We've started system design and built out XML schemas to support distribution and maintenance of standardized names across the enterprise.
       
        I've talked with several vendors about the concept and there seems to be a common need for this type of capability across the board.
       
        Since DoD vendors will have to build interfaces to consume, use, and tag exported data with standardized names using some standardized schema, I'm thinking this effort may be worth trying to standardize across the SCAP community (maybe even larger communities?).
       
        I've attached a short white paper describing the effort, definitions, requirements, etc.  If I get responses back, I can share XML schemas and business logic we're coordinating.
       
        Also, I can present this at our next SCAP Developer Days (assuming we have one).
       
        Let me know if you believe this capability merits a community effort.  I'll assume silence indicates a lack of interest.
       
        Joseph L. Wolfkiel
        Engineering Group Lead
        DISA PEO MA/IA52
        (301) 225-8820 <tel:%28301%29%20225-8820>
        [hidden email]
       
       
       
        Classification: UNCLASSIFIED
        Caveats: NONE
       




--
Joe Wolfkiel







--
Joe Wolfkiel




Classification: UNCLASSIFIED
Caveats: NONE



smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Centralized Standard Name Distribution (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
In reply to this post by WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification: UNCLASSIFIED
Caveats: NONE

It's even a little more complex than that.  Here's the current version of schema and sample files I'm working with.

I avoided building any functionality in the schema.  The distro architecture assumes there are types of names  (i.e. organization, location, system, etc).  Within name types, there is a default rollup [equivalent to "context"].  E.g. for organizations, default is "owning", but there are other 'functional' rollups like some organizations reporting to others based on "administering" and "defending" roles.

I tried to cover some of the complexities in the sample files.  I.e. our CERT organizations report to US Cyber Command in the defensive role, but may report to the local CIO in the "owning" role.  In the functional role, they may be named differently than in the default role and may have a different hierarchical name.

In the military, it's pretty common to participate in multiple hierarchies based on mission, so a given organization may have several functional hierarchies.

In a later iteration, I'll have to clarify the roles further.  Currently, assumption is that roles are defined with relation to devices and network.  However, there are also defending, administering, and owning roles in relation to people, real-estate, money, etc.

I ran into this some when we designed the DoD PLARR.  Named entities are requested in a object-verb-subject relationship, i.e. Give me a list of all device compliance for STIG X, grouped by organizations with the role of "organization-owns-device"

I don't really see this as an LDAP equivalent.  More like DNS, except more dimensions and less supported functionality.  An IP address would be an ID, the URL would be an hName, and the web site title would be a dName.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Davidson II, Mark S
Sent: Monday, February 06, 2012 8:20 AM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

I'll say that this topic is a huge stumbling block for many security organizations, and probably IT organizations in general. There are a great many sources of information (Employee Databases, LDAP Repositories, Network Scanners, CMDBs, etc), and each one is authoritative about a subset of an Enterprise's information. The ability to fuse these information sets and keep it up to date is difficult to begin with. Having a usable history of that information set is even more difficult. That said, effective management of this information is essential for any mature organization. This is a big piece of 'Know Your Network'.

 

With that thought, I'd like to offer a brainstorm on this subject:

 

1. From the data side, I think a 'context' property might be useful, where 'context' would identify the tree structure that a given hName, dName, and superiorName belong to. For example, MarksPC might have a superiorName of MITRE in the ownership context, and have a superiorName of Massachusetts in the location context. In order to drill up or down, the ability to specify a node,  the context (or tree) that you are in, and a direction (up/down), would likely be sufficient. A query specifying node=root, context=ownership, and direction=down might provide a list of MITRE departments.

 

2. Are you picturing this as a protocol, similar in function to LDAP? The way the requirements are described, it seems like LDAP would be a pretty close (though not exact) model for what you are looking to do (hierarchical structure, search functions, etc).

 

3. As a security minded individual, I'd be interested in a briefing on this topic.

 

4. From the standards side, I think that standards could be a fit for transporting the information between client and server, but this problem is much bigger than just transporting information. SCAP does not (to my knowledge) have a standard method for communicating arbitrary asset information. If you want to assert "MarkPC ownOrg=MITRE" in an SCAP context, I'm not sure how you would do that.

 

-Mark

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, February 04, 2012 3:44 PM
To: Multiple recipients of list
Subject: Re: [CPE-DISCUSSION-LIST] Centralized Standard Name Distribution (UNCLASSIFIED)

 

This isn't directly about reporting.  It's a name distribution and maintenance solution.  The names distributed are intended to be metadata tags to support using ARF and ASR, but neither ARF or ASR address the problem of ensuring all reporting endpoints and repositories have the same list of names and relationships between names.  This is more of a "content distribution" solution versus a reporting solution.  I envision the name maintenance and distribution subsystem ultimately becoming part of our Digital Policy Management System.

If we ever address risk scoring as a standards problem, there's a similar problem for distributing continuously updated severities for use in calculating risk scores.

Let me know what you think.

- Joe

On Fri, Feb 3, 2012 at 7:48 PM, Waltermire, David A. <[hidden email]> wrote:

Thanks. I'll take a look and provide feedback. Have you looked at using Asset identification 1.1 as part of this strategy?  It has records for organizations, locations, persons, systems and other info.  All of these can be used by ARF 1.1 for reporting.

Thanks,
Dave

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Friday, February 03, 2012 5:10 PM
To: SCAP-DEV
Subject: Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I'm running into problems in my automated data sharing implementations based on needing to have standardized names for organizations, locations, systems, etc.  In response, we're looking at building out a centralized name maintenance capability for our cyber reporting functionality.

We've started system design and built out XML schemas to support distribution and maintenance of standardized names across the enterprise.

I've talked with several vendors about the concept and there seems to be a common need for this type of capability across the board.

Since DoD vendors will have to build interfaces to consume, use, and tag exported data with standardized names using some standardized schema, I'm thinking this effort may be worth trying to standardize across the SCAP community (maybe even larger communities?).

I've attached a short white paper describing the effort, definitions, requirements, etc.  If I get responses back, I can share XML schemas and business logic we're coordinating.

Also, I can present this at our next SCAP Developer Days (assuming we have one).

Let me know if you believe this capability merits a community effort.  I'll assume silence indicates a lack of interest.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820 <tel:%28301%29%20225-8820>
[hidden email]



Classification: UNCLASSIFIED
Caveats: NONE




--
Joe Wolfkiel




Classification: UNCLASSIFIED
Caveats: NONE



2012-01-16 Name Distro Schemas and Sample Files.zip (6K) Download Attachment
smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Centralized Standard Name Distribution (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification: UNCLASSIFIED
Caveats: NONE

I agree it's not technically "SCAP", though the name management problem is pretty critical for OCIL targeting and reporting as well as tool interoperability.

If there's a better forum, let's move the discussion there.

As for how much so far, we're writing code against the schemas and requirements I sent with the plan to deploy a system in the next 3 months.

Though the relationships look similar to DNS, it's not the same problem.  From a distribution standpoint, we plan to send out a list of all names and ask the local user to assign them to objects.  DNS assumes you know the name or the ID and want to look up the name from the ID or the ID from the name.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Davidson II, Mark S
Sent: Tuesday, February 07, 2012 10:23 AM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

What have you designed so far? I think this is a great problem to solve,
since just about everyone has it. I have some experience solving this exact
issue, but at a much lower level of maturity. I think that, depending on the
exact requirements, current technologies might be effectively leveraged to
meet your requirements. The benefit of that would be two-fold. If you pick a
well understood, well documented technology (eg, if you could leverage DNS
servers or LDAP or something similar), it will a) make the development
easier and faster (and you might have best-practices to follow), and b)
finding people with domain knowledge to develop and maintain the solution
will be easier.

======

For the benefit of the group, I'll provide a brief synopsis of the solution
I came up with. There's a fair amount of duct tape and bubble gum here. This
was all in the context of providing a single data mart that our security
infrastructure could query in order to populate our security tickets with
relevant information. While it wasn't pretty, it worked.

1. Extract (Data Sources)

I had a number of data sources that were the system of record for a portion
of the enterprise knowledge.
-LDAP Repository
-HR Database
-Network scanners
-CMDB (Component Management Database)
-Spreadsheets from engineering groups (Had information like which subnets
where for what, etc)

I created a database server with a public share. Each data source had its
own directory within that share, and would publish a daily extract of the
data it had. Some products had the ability to export data, and some required
custom code in order to get the data out. The data extracts were scheduled
for daily delivery in the pre-work hours.

2. Data transform
Once the data had been delivered, the data needed to be massaged into
something that could be imported into the database. I had custom code for
this. The workflow was that the extracts from step 1 were loaded into
memory, then output in a format that would work with the database. After
this process, the data extracts would be moved to an archived folder,
providing a history of the data.

3. Load
This was a pretty simple two-part process. Step one was to load the massaged
data into a temporary table, and step two was to insert and age the data
from the temporary table. At this point, the data was loaded and stored in
the data mart, ready for real-time use.

4. Lesson learned
a. Leveraging existing technology can be beneficial. At the beginning, I
wrote most of my own custom ETL code. As you might expect, the code was
useful only in a single use case, and did not handle unexpected inputs
gracefully (nothing like trying to locate a null pointer exception without a
good logging mechanism). Throughout the lifecycle of the data mart, I
transitioned more and more to existing technology. The result was a more
resilient environment that could be managed by somebody other than the
developer (me).

b. Testing is your friend. I was on a tight timeline and budget, so testing
wasn't really a priority. I ended up with a few production issues that could
have been avoided with proper testing. Since the scope of the environment
was small, downtime was minimal. In a larger-scope environment, a more
rigorous development process is necessary.

c. Stick with standards. I did a lot of work to 'force' the source data to
appear how I wanted it, which involved a lot of reverse engineering that was
frequently broken by product updates. Even if it's a 90% solution, and
'forcing' the data results in a 99% solution, that extra 9% might require so
much maintenance that it's not worth it. I think as long as you can hit 80%
or better 100% of the time, you've accomplished something. In fact, there
was one component that took me a month to write that was completely replaced
by a product upgrade a few weeks later. That one was fun.

=====

On another note, I realize this isn't really an SCAP development discussion
anymore. Is there a better venue to have this discussion, or should it stay
on the scap-dev list?

Thank you.
-Mark

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of WOLFKIEL,
JOSEPH L CIV DISA PEO-MA
Sent: Monday, February 06, 2012 1:44 PM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

It's even a little more complex than that.  Here's the current version of
schema and sample files I'm working with.

I avoided building any functionality in the schema.  The distro architecture
assumes there are types of names  (i.e. organization, location, system,
etc).  Within name types, there is a default rollup [equivalent to
"context"].  E.g. for organizations, default is "owning", but there are
other 'functional' rollups like some organizations reporting to others based
on "administering" and "defending" roles.

I tried to cover some of the complexities in the sample files.  I.e. our
CERT organizations report to US Cyber Command in the defensive role, but may
report to the local CIO in the "owning" role.  In the functional role, they
may be named differently than in the default role and may have a different
hierarchical name.

In the military, it's pretty common to participate in multiple hierarchies
based on mission, so a given organization may have several functional
hierarchies.

In a later iteration, I'll have to clarify the roles further.  Currently,
assumption is that roles are defined with relation to devices and network.
However, there are also defending, administering, and owning roles in
relation to people, real-estate, money, etc.

I ran into this some when we designed the DoD PLARR.  Named entities are
requested in a object-verb-subject relationship, i.e. Give me a list of all
device compliance for STIG X, grouped by organizations with the role of
"organization-owns-device"

I don't really see this as an LDAP equivalent.  More like DNS, except more
dimensions and less supported functionality.  An IP address would be an ID,
the URL would be an hName, and the web site title would be a dName.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Davidson II,
Mark S
Sent: Monday, February 06, 2012 8:20 AM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

I'll say that this topic is a huge stumbling block for many security
organizations, and probably IT organizations in general. There are a great
many sources of information (Employee Databases, LDAP Repositories, Network
Scanners, CMDBs, etc), and each one is authoritative about a subset of an
Enterprise's information. The ability to fuse these information sets and
keep it up to date is difficult to begin with. Having a usable history of
that information set is even more difficult. That said, effective management
of this information is essential for any mature organization. This is a big
piece of 'Know Your Network'.

 

With that thought, I'd like to offer a brainstorm on this subject:

 

1. From the data side, I think a 'context' property might be useful, where
'context' would identify the tree structure that a given hName, dName, and
superiorName belong to. For example, MarksPC might have a superiorName of
MITRE in the ownership context, and have a superiorName of Massachusetts in
the location context. In order to drill up or down, the ability to specify a
node,  the context (or tree) that you are in, and a direction (up/down),
would likely be sufficient. A query specifying node=root, context=ownership,
and direction=down might provide a list of MITRE departments.

 

2. Are you picturing this as a protocol, similar in function to LDAP? The
way the requirements are described, it seems like LDAP would be a pretty
close (though not exact) model for what you are looking to do (hierarchical
structure, search functions, etc).

 

3. As a security minded individual, I'd be interested in a briefing on this
topic.

 

4. From the standards side, I think that standards could be a fit for
transporting the information between client and server, but this problem is
much bigger than just transporting information. SCAP does not (to my
knowledge) have a standard method for communicating arbitrary asset
information. If you want to assert "MarkPC ownOrg=MITRE" in an SCAP context,
I'm not sure how you would do that.

 

-Mark

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Saturday, February 04, 2012 3:44 PM
To: Multiple recipients of list
Subject: Re: [CPE-DISCUSSION-LIST] Centralized Standard Name Distribution
(UNCLASSIFIED)

 

This isn't directly about reporting.  It's a name distribution and
maintenance solution.  The names distributed are intended to be metadata
tags to support using ARF and ASR, but neither ARF or ASR address the
problem of ensuring all reporting endpoints and repositories have the same
list of names and relationships between names.  This is more of a "content
distribution" solution versus a reporting solution.  I envision the name
maintenance and distribution subsystem ultimately becoming part of our
Digital Policy Management System.

If we ever address risk scoring as a standards problem, there's a similar
problem for distributing continuously updated severities for use in
calculating risk scores.

Let me know what you think.

- Joe

On Fri, Feb 3, 2012 at 7:48 PM, Waltermire, David A.
<[hidden email]> wrote:

Thanks. I'll take a look and provide feedback. Have you looked at using
Asset identification 1.1 as part of this strategy?  It has records for
organizations, locations, persons, systems and other info.  All of these can
be used by ARF 1.1 for reporting.

Thanks,
Dave

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of WOLFKIEL,
JOSEPH L CIV DISA PEO-MA
Sent: Friday, February 03, 2012 5:10 PM
To: SCAP-DEV
Subject: Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I'm running into problems in my automated data sharing implementations based
on needing to have standardized names for organizations, locations, systems,
etc.  In response, we're looking at building out a centralized name
maintenance capability for our cyber reporting functionality.

We've started system design and built out XML schemas to support
distribution and maintenance of standardized names across the enterprise.

I've talked with several vendors about the concept and there seems to be a
common need for this type of capability across the board.

Since DoD vendors will have to build interfaces to consume, use, and tag
exported data with standardized names using some standardized schema, I'm
thinking this effort may be worth trying to standardize across the SCAP
community (maybe even larger communities?).

I've attached a short white paper describing the effort, definitions,
requirements, etc.  If I get responses back, I can share XML schemas and
business logic we're coordinating.

Also, I can present this at our next SCAP Developer Days (assuming we have
one).

Let me know if you believe this capability merits a community effort.  I'll
assume silence indicates a lack of interest.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820 <tel:%28301%29%20225-8820>
[hidden email]



Classification: UNCLASSIFIED
Caveats: NONE




--
Joe Wolfkiel




Classification: UNCLASSIFIED
Caveats: NONE



Classification: UNCLASSIFIED
Caveats: NONE



smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Centralized Standard Name Distribution (UNCLASSIFIED)

Kent Landfield
Joe is spot on….  This has a direct tie in to OCIL targeting and is a reason OCIL is not advancing in enterprise products.

I am not sure this is the right place though…  Maybe if we moved it to the OCIL list we could solve two issues at once and do it one way…

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: "WOLFKIEL, JOSEPH L CIV DISA PEO-MA" <[hidden email]>
Reply-To: CPE Community Forum <[hidden email]>
Date: Tue, 7 Feb 2012 10:13:10 -0600
To: "[hidden email]" <[hidden email]>
Subject: Re: [CPE-DISCUSSION-LIST] Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I agree it's not technically "SCAP", though the name management problem is pretty critical for OCIL targeting and reporting as well as tool interoperability.

If there's a better forum, let's move the discussion there.

As for how much so far, we're writing code against the schemas and requirements I sent with the plan to deploy a system in the next 3 months.

Though the relationships look similar to DNS, it's not the same problem.  From a distribution standpoint, we plan to send out a list of all names and ask the local user to assign them to objects.  DNS assumes you know the name or the ID and want to look up the name from the ID or the ID from the name.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820


-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Davidson II, Mark S
Sent: Tuesday, February 07, 2012 10:23 AM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

What have you designed so far? I think this is a great problem to solve,
since just about everyone has it. I have some experience solving this exact
issue, but at a much lower level of maturity. I think that, depending on the
exact requirements, current technologies might be effectively leveraged to
meet your requirements. The benefit of that would be two-fold. If you pick a
well understood, well documented technology (eg, if you could leverage DNS
servers or LDAP or something similar), it will a) make the development
easier and faster (and you might have best-practices to follow), and b)
finding people with domain knowledge to develop and maintain the solution
will be easier.

======

For the benefit of the group, I'll provide a brief synopsis of the solution
I came up with. There's a fair amount of duct tape and bubble gum here. This
was all in the context of providing a single data mart that our security
infrastructure could query in order to populate our security tickets with
relevant information. While it wasn't pretty, it worked.

1. Extract (Data Sources)

I had a number of data sources that were the system of record for a portion
of the enterprise knowledge.
-LDAP Repository
-HR Database
-Network scanners
-CMDB (Component Management Database)
-Spreadsheets from engineering groups (Had information like which subnets
where for what, etc)

I created a database server with a public share. Each data source had its
own directory within that share, and would publish a daily extract of the
data it had. Some products had the ability to export data, and some required
custom code in order to get the data out. The data extracts were scheduled
for daily delivery in the pre-work hours.

2. Data transform
Once the data had been delivered, the data needed to be massaged into
something that could be imported into the database. I had custom code for
this. The workflow was that the extracts from step 1 were loaded into
memory, then output in a format that would work with the database. After
this process, the data extracts would be moved to an archived folder,
providing a history of the data.

3. Load
This was a pretty simple two-part process. Step one was to load the massaged
data into a temporary table, and step two was to insert and age the data
from the temporary table. At this point, the data was loaded and stored in
the data mart, ready for real-time use.

4. Lesson learned
a. Leveraging existing technology can be beneficial. At the beginning, I
wrote most of my own custom ETL code. As you might expect, the code was
useful only in a single use case, and did not handle unexpected inputs
gracefully (nothing like trying to locate a null pointer exception without a
good logging mechanism). Throughout the lifecycle of the data mart, I
transitioned more and more to existing technology. The result was a more
resilient environment that could be managed by somebody other than the
developer (me).

b. Testing is your friend. I was on a tight timeline and budget, so testing
wasn't really a priority. I ended up with a few production issues that could
have been avoided with proper testing. Since the scope of the environment
was small, downtime was minimal. In a larger-scope environment, a more
rigorous development process is necessary.

c. Stick with standards. I did a lot of work to 'force' the source data to
appear how I wanted it, which involved a lot of reverse engineering that was
frequently broken by product updates. Even if it's a 90% solution, and
'forcing' the data results in a 99% solution, that extra 9% might require so
much maintenance that it's not worth it. I think as long as you can hit 80%
or better 100% of the time, you've accomplished something. In fact, there
was one component that took me a month to write that was completely replaced
by a product upgrade a few weeks later. That one was fun.

=====

On another note, I realize this isn't really an SCAP development discussion
anymore. Is there a better venue to have this discussion, or should it stay
on the scap-dev list?

Thank you.
-Mark

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of WOLFKIEL,
JOSEPH L CIV DISA PEO-MA
Sent: Monday, February 06, 2012 1:44 PM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

It's even a little more complex than that.  Here's the current version of
schema and sample files I'm working with.

I avoided building any functionality in the schema.  The distro architecture
assumes there are types of names  (i.e. organization, location, system,
etc).  Within name types, there is a default rollup [equivalent to
"context"].  E.g. for organizations, default is "owning", but there are
other 'functional' rollups like some organizations reporting to others based
on "administering" and "defending" roles.

I tried to cover some of the complexities in the sample files.  I.e. our
CERT organizations report to US Cyber Command in the defensive role, but may
report to the local CIO in the "owning" role.  In the functional role, they
may be named differently than in the default role and may have a different
hierarchical name.

In the military, it's pretty common to participate in multiple hierarchies
based on mission, so a given organization may have several functional
hierarchies.

In a later iteration, I'll have to clarify the roles further.  Currently,
assumption is that roles are defined with relation to devices and network.
However, there are also defending, administering, and owning roles in
relation to people, real-estate, money, etc.

I ran into this some when we designed the DoD PLARR.  Named entities are
requested in a object-verb-subject relationship, i.e. Give me a list of all
device compliance for STIG X, grouped by organizations with the role of
"organization-owns-device"

I don't really see this as an LDAP equivalent.  More like DNS, except more
dimensions and less supported functionality.  An IP address would be an ID,
the URL would be an hName, and the web site title would be a dName.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820


-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Davidson II,
Mark S
Sent: Monday, February 06, 2012 8:20 AM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

I'll say that this topic is a huge stumbling block for many security
organizations, and probably IT organizations in general. There are a great
many sources of information (Employee Databases, LDAP Repositories, Network
Scanners, CMDBs, etc), and each one is authoritative about a subset of an
Enterprise's information. The ability to fuse these information sets and
keep it up to date is difficult to begin with. Having a usable history of
that information set is even more difficult. That said, effective management
of this information is essential for any mature organization. This is a big
piece of 'Know Your Network'.


With that thought, I'd like to offer a brainstorm on this subject:


1. From the data side, I think a 'context' property might be useful, where
'context' would identify the tree structure that a given hName, dName, and
superiorName belong to. For example, MarksPC might have a superiorName of
MITRE in the ownership context, and have a superiorName of Massachusetts in
the location context. In order to drill up or down, the ability to specify a
node,  the context (or tree) that you are in, and a direction (up/down),
would likely be sufficient. A query specifying node=root, context=ownership,
and direction=down might provide a list of MITRE departments.


2. Are you picturing this as a protocol, similar in function to LDAP? The
way the requirements are described, it seems like LDAP would be a pretty
close (though not exact) model for what you are looking to do (hierarchical
structure, search functions, etc).


3. As a security minded individual, I'd be interested in a briefing on this
topic.


4. From the standards side, I think that standards could be a fit for
transporting the information between client and server, but this problem is
much bigger than just transporting information. SCAP does not (to my
knowledge) have a standard method for communicating arbitrary asset
information. If you want to assert "MarkPC ownOrg=MITRE" in an SCAP context,
I'm not sure how you would do that.


-Mark


From: [hidden email] [[hidden email]] On Behalf Of
Sent: Saturday, February 04, 2012 3:44 PM
To: Multiple recipients of list
Subject: Re: [CPE-DISCUSSION-LIST] Centralized Standard Name Distribution
(UNCLASSIFIED)


This isn't directly about reporting.  It's a name distribution and
maintenance solution.  The names distributed are intended to be metadata
tags to support using ARF and ASR, but neither ARF or ASR address the
problem of ensuring all reporting endpoints and repositories have the same
list of names and relationships between names.  This is more of a "content
distribution" solution versus a reporting solution.  I envision the name
maintenance and distribution subsystem ultimately becoming part of our
Digital Policy Management System.

If we ever address risk scoring as a standards problem, there's a similar
problem for distributing continuously updated severities for use in
calculating risk scores.

Let me know what you think.

- Joe

On Fri, Feb 3, 2012 at 7:48 PM, Waltermire, David A.

Thanks. I'll take a look and provide feedback. Have you looked at using
Asset identification 1.1 as part of this strategy?  It has records for
organizations, locations, persons, systems and other info.  All of these can
be used by ARF 1.1 for reporting.

Thanks,
Dave

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of WOLFKIEL,
JOSEPH L CIV DISA PEO-MA
Sent: Friday, February 03, 2012 5:10 PM
To: SCAP-DEV
Subject: Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I'm running into problems in my automated data sharing implementations based
on needing to have standardized names for organizations, locations, systems,
etc.  In response, we're looking at building out a centralized name
maintenance capability for our cyber reporting functionality.

We've started system design and built out XML schemas to support
distribution and maintenance of standardized names across the enterprise.

I've talked with several vendors about the concept and there seems to be a
common need for this type of capability across the board.

Since DoD vendors will have to build interfaces to consume, use, and tag
exported data with standardized names using some standardized schema, I'm
thinking this effort may be worth trying to standardize across the SCAP
community (maybe even larger communities?).

I've attached a short white paper describing the effort, definitions,
requirements, etc.  If I get responses back, I can share XML schemas and
business logic we're coordinating.

Also, I can present this at our next SCAP Developer Days (assuming we have
one).

Let me know if you believe this capability merits a community effort.  I'll
assume silence indicates a lack of interest.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820 <tel:%28301%29%20225-8820>



Classification: UNCLASSIFIED
Caveats: NONE




--
Joe Wolfkiel




Classification: UNCLASSIFIED
Caveats: NONE



Classification: UNCLASSIFIED
Caveats: NONE



Reply | Threaded
Open this post in threaded view
|

Re: Centralized Standard Name Distribution (UNCLASSIFIED)

Adam Montville
Moving this to the OCIL list seems to be a good start.  I'd like to see how we can leverage Asset Identification for OCIL targeting as well, if we're not already.

Regards,

Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815

TRIPWIRE | Take CONTROL
http://www.tripwire.com

From: kent_landfield <[hidden email]<mailto:[hidden email]>>
Reply-To: CPE Community Forum <[hidden email]<mailto:[hidden email]>>
Date: Tue, 7 Feb 2012 10:19:49 -0600
To: <[hidden email]<mailto:[hidden email]>>
Subject: Re: [CPE-DISCUSSION-LIST] Centralized Standard Name Distribution (UNCLASSIFIED)

Joe is spot on….  This has a direct tie in to OCIL targeting and is a reason OCIL is not advancing in enterprise products.

I am not sure this is the right place though…  Maybe if we moved it to the OCIL list we could solve two issues at once and do it one way…

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: "WOLFKIEL, JOSEPH L CIV DISA PEO-MA" <[hidden email]<mailto:[hidden email]>>
Reply-To: CPE Community Forum <[hidden email]<mailto:[hidden email]>>
Date: Tue, 7 Feb 2012 10:13:10 -0600
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [CPE-DISCUSSION-LIST] Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I agree it's not technically "SCAP", though the name management problem is pretty critical for OCIL targeting and reporting as well as tool interoperability.

If there's a better forum, let's move the discussion there.

As for how much so far, we're writing code against the schemas and requirements I sent with the plan to deploy a system in the next 3 months.

Though the relationships look similar to DNS, it's not the same problem.  From a distribution standpoint, we plan to send out a list of all names and ask the local user to assign them to objects.  DNS assumes you know the name or the ID and want to look up the name from the ID or the ID from the name.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]<mailto:[hidden email]>


-----Original Message-----
From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]] On Behalf Of Davidson II, Mark S
Sent: Tuesday, February 07, 2012 10:23 AM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

What have you designed so far? I think this is a great problem to solve,
since just about everyone has it. I have some experience solving this exact
issue, but at a much lower level of maturity. I think that, depending on the
exact requirements, current technologies might be effectively leveraged to
meet your requirements. The benefit of that would be two-fold. If you pick a
well understood, well documented technology (eg, if you could leverage DNS
servers or LDAP or something similar), it will a) make the development
easier and faster (and you might have best-practices to follow), and b)
finding people with domain knowledge to develop and maintain the solution
will be easier.

======

For the benefit of the group, I'll provide a brief synopsis of the solution
I came up with. There's a fair amount of duct tape and bubble gum here. This
was all in the context of providing a single data mart that our security
infrastructure could query in order to populate our security tickets with
relevant information. While it wasn't pretty, it worked.

1. Extract (Data Sources)

I had a number of data sources that were the system of record for a portion
of the enterprise knowledge.
-LDAP Repository
-HR Database
-Network scanners
-CMDB (Component Management Database)
-Spreadsheets from engineering groups (Had information like which subnets
where for what, etc)

I created a database server with a public share. Each data source had its
own directory within that share, and would publish a daily extract of the
data it had. Some products had the ability to export data, and some required
custom code in order to get the data out. The data extracts were scheduled
for daily delivery in the pre-work hours.

2. Data transform
Once the data had been delivered, the data needed to be massaged into
something that could be imported into the database. I had custom code for
this. The workflow was that the extracts from step 1 were loaded into
memory, then output in a format that would work with the database. After
this process, the data extracts would be moved to an archived folder,
providing a history of the data.

3. Load
This was a pretty simple two-part process. Step one was to load the massaged
data into a temporary table, and step two was to insert and age the data
from the temporary table. At this point, the data was loaded and stored in
the data mart, ready for real-time use.

4. Lesson learned
a. Leveraging existing technology can be beneficial. At the beginning, I
wrote most of my own custom ETL code. As you might expect, the code was
useful only in a single use case, and did not handle unexpected inputs
gracefully (nothing like trying to locate a null pointer exception without a
good logging mechanism). Throughout the lifecycle of the data mart, I
transitioned more and more to existing technology. The result was a more
resilient environment that could be managed by somebody other than the
developer (me).

b. Testing is your friend. I was on a tight timeline and budget, so testing
wasn't really a priority. I ended up with a few production issues that could
have been avoided with proper testing. Since the scope of the environment
was small, downtime was minimal. In a larger-scope environment, a more
rigorous development process is necessary.

c. Stick with standards. I did a lot of work to 'force' the source data to
appear how I wanted it, which involved a lot of reverse engineering that was
frequently broken by product updates. Even if it's a 90% solution, and
'forcing' the data results in a 99% solution, that extra 9% might require so
much maintenance that it's not worth it. I think as long as you can hit 80%
or better 100% of the time, you've accomplished something. In fact, there
was one component that took me a month to write that was completely replaced
by a product upgrade a few weeks later. That one was fun.

=====

On another note, I realize this isn't really an SCAP development discussion
anymore. Is there a better venue to have this discussion, or should it stay
on the scap-dev list?

Thank you.
-Mark

-----Original Message-----
From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]] On Behalf Of WOLFKIEL,
JOSEPH L CIV DISA PEO-MA
Sent: Monday, February 06, 2012 1:44 PM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

It's even a little more complex than that.  Here's the current version of
schema and sample files I'm working with.

I avoided building any functionality in the schema.  The distro architecture
assumes there are types of names  (i.e. organization, location, system,
etc).  Within name types, there is a default rollup [equivalent to
"context"].  E.g. for organizations, default is "owning", but there are
other 'functional' rollups like some organizations reporting to others based
on "administering" and "defending" roles.

I tried to cover some of the complexities in the sample files.  I.e. our
CERT organizations report to US Cyber Command in the defensive role, but may
report to the local CIO in the "owning" role.  In the functional role, they
may be named differently than in the default role and may have a different
hierarchical name.

In the military, it's pretty common to participate in multiple hierarchies
based on mission, so a given organization may have several functional
hierarchies.

In a later iteration, I'll have to clarify the roles further.  Currently,
assumption is that roles are defined with relation to devices and network.
However, there are also defending, administering, and owning roles in
relation to people, real-estate, money, etc.

I ran into this some when we designed the DoD PLARR.  Named entities are
requested in a object-verb-subject relationship, i.e. Give me a list of all
device compliance for STIG X, grouped by organizations with the role of
"organization-owns-device"

I don't really see this as an LDAP equivalent.  More like DNS, except more
dimensions and less supported functionality.  An IP address would be an ID,
the URL would be an hName, and the web site title would be a dName.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[hidden email]<mailto:[hidden email]>


-----Original Message-----
From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]] On Behalf Of Davidson II,
Mark S
Sent: Monday, February 06, 2012 8:20 AM
To: Multiple recipients of list
Subject: RE: Centralized Standard Name Distribution (UNCLASSIFIED)

I'll say that this topic is a huge stumbling block for many security
organizations, and probably IT organizations in general. There are a great
many sources of information (Employee Databases, LDAP Repositories, Network
Scanners, CMDBs, etc), and each one is authoritative about a subset of an
Enterprise's information. The ability to fuse these information sets and
keep it up to date is difficult to begin with. Having a usable history of
that information set is even more difficult. That said, effective management
of this information is essential for any mature organization. This is a big
piece of 'Know Your Network'.


With that thought, I'd like to offer a brainstorm on this subject:


1. From the data side, I think a 'context' property might be useful, where
'context' would identify the tree structure that a given hName, dName, and
superiorName belong to. For example, MarksPC might have a superiorName of
MITRE in the ownership context, and have a superiorName of Massachusetts in
the location context. In order to drill up or down, the ability to specify a
node,  the context (or tree) that you are in, and a direction (up/down),
would likely be sufficient. A query specifying node=root, context=ownership,
and direction=down might provide a list of MITRE departments.


2. Are you picturing this as a protocol, similar in function to LDAP? The
way the requirements are described, it seems like LDAP would be a pretty
close (though not exact) model for what you are looking to do (hierarchical
structure, search functions, etc).


3. As a security minded individual, I'd be interested in a briefing on this
topic.


4. From the standards side, I think that standards could be a fit for
transporting the information between client and server, but this problem is
much bigger than just transporting information. SCAP does not (to my
knowledge) have a standard method for communicating arbitrary asset
information. If you want to assert "MarkPC ownOrg=MITRE" in an SCAP context,
I'm not sure how you would do that.


-Mark


From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]] On Behalf Of
[hidden email]<mailto:[hidden email]>
Sent: Saturday, February 04, 2012 3:44 PM
To: Multiple recipients of list
Subject: Re: [CPE-DISCUSSION-LIST] Centralized Standard Name Distribution
(UNCLASSIFIED)


This isn't directly about reporting.  It's a name distribution and
maintenance solution.  The names distributed are intended to be metadata
tags to support using ARF and ASR, but neither ARF or ASR address the
problem of ensuring all reporting endpoints and repositories have the same
list of names and relationships between names.  This is more of a "content
distribution" solution versus a reporting solution.  I envision the name
maintenance and distribution subsystem ultimately becoming part of our
Digital Policy Management System.

If we ever address risk scoring as a standards problem, there's a similar
problem for distributing continuously updated severities for use in
calculating risk scores.

Let me know what you think.

- Joe

On Fri, Feb 3, 2012 at 7:48 PM, Waltermire, David A.
<[hidden email]<mailto:[hidden email]>> wrote:

Thanks. I'll take a look and provide feedback. Have you looked at using
Asset identification 1.1 as part of this strategy?  It has records for
organizations, locations, persons, systems and other info.  All of these can
be used by ARF 1.1 for reporting.

Thanks,
Dave

-----Original Message-----
From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]] On Behalf Of WOLFKIEL,
JOSEPH L CIV DISA PEO-MA
Sent: Friday, February 03, 2012 5:10 PM
To: SCAP-DEV
Subject: Centralized Standard Name Distribution (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I'm running into problems in my automated data sharing implementations based
on needing to have standardized names for organizations, locations, systems,
etc.  In response, we're looking at building out a centralized name
maintenance capability for our cyber reporting functionality.

We've started system design and built out XML schemas to support
distribution and maintenance of standardized names across the enterprise.

I've talked with several vendors about the concept and there seems to be a
common need for this type of capability across the board.

Since DoD vendors will have to build interfaces to consume, use, and tag
exported data with standardized names using some standardized schema, I'm
thinking this effort may be worth trying to standardize across the SCAP
community (maybe even larger communities?).

I've attached a short white paper describing the effort, definitions,
requirements, etc.  If I get responses back, I can share XML schemas and
business logic we're coordinating.

Also, I can present this at our next SCAP Developer Days (assuming we have
one).

Let me know if you believe this capability merits a community effort.  I'll
assume silence indicates a lack of interest.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820 <tel:%28301%29%20225-8820>
[hidden email]<mailto:[hidden email]>



Classification: UNCLASSIFIED
Caveats: NONE




--
Joe Wolfkiel




Classification: UNCLASSIFIED
Caveats: NONE



Classification: UNCLASSIFIED
Caveats: NONE