Describing a potential goal/challenge

[Adam Montville]

Good morning Everyone,

Reference Charles’ summary here: https://groups.google.com/a/list.nist.gov/forum/#!topic/scap-dev-endpoint/CozEcgf1pYU

Maybe what we could use is a target goal - a specific example of what it is we’re trying to achieve, then ask what is the minimum that needs to be done to meet that goal?

For example, consider an Application that needs to discover, for all computing resources within a company’s boundary of responsibility, conformance with a minimum password length of at least 20. 

Consider that this company has employees with laptops (Windows and Mac), a few Chromebooks, iOS and Android devices, and that they use AWS to provide services to their customers. Additionally, they have a website running on a hosted WordPress solution, network devices, and they use Salesforce. We could add to that a variety of IoT devices at their HQ (perhaps part of their HVAC system).

How can we design a decomposed architecture and associated information models with data model serializations to accomplish the above in the simplest way possible? Maybe we start with a subset of those computing resources and build a POC. Then maybe we continue the POC by adding a few more computing resource classes. Then we write down what we’ve learned. What are the interfaces actually necessary? How tough is normalizing information coming from different methods of collecting state values? And so on.

Kind regards,

Adam

[Schmidt, Charles M.]

Hi Adam,

 

Looking at you example:

> For example, consider an Application that needs to discover, for all computing resources within a company’s boundary of responsibility, conformance with a

> minimum password length of at least 20. 

 

As a starting point, I think we need one of two things:

1. The Application needs to have access to instructions to guide collection of the information of interest. This would be equivalent to finding the OVAL check that will check this on Windows, the OVAL check that will check this on Mac, the OVAL check that will check this on Chromebook, etc. Doing this, of course, requires that the Application know all the types of assets in the enterprise that it will need to assess so it can look up content for them.
2. The assessment infrastructure will need to have a built-in, automated way of taking the high level “check minimum password length >= 20” and turning it into the mechanical processes by which the relevant system details are collected and evaluated across all enterprise resources.

 

I think 1 is painful, but I feel that 2 is probably impractical today.  I do think enhancements in how SCAP content repositories are managed in order to make them a bit more standardized (which the SCAP group had been discussing about a year ago) would go a long way towards making 1 less painful, but I don’t think it would significantly help with 2.

 

As such, I think possibly a better example goal might be - given a collection of assessment content (i.e., we’ve already gone through the pain of option 1 above), an Application should be able to kick off a comprehensive assessment of all assets in the enterprise to which the content applies and, when the results are delivered, know which enterprise assets were and were not assessed. It should be able to do this without any a priori knowledge of what assets are in the organization and which of them are applicable.

 

The proposed architecture is designed to support this second goal: starting with an already identified set of content, allow an Application to initiate an enterprise assessment using that content to the broadest valid extent in the enterprise without any additional required knowledge.

 

Charles

--
To unsubscribe from this group, send email to scap-dev-endpo...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-endpoint
---
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-endpo...@list.nist.gov.

[David Solin]

The *simplest* way to do this would be to create a data model centered around the controls you want to implement.  The problem is that such a model would not be flexible.  What if you need to implement a new control that was never previously envisioned?

It is tempting to want to take a blank-sheet-of-paper approach to devising a revolutionary new system, but abandoning the product of generations of iterative development, expertise and lessons-learned comes at the cost of very likely having to reinvent and reproduce virtually all of it.

My preference is to take the next generation's requirements, try to come up with the most flexible architecture to address them that takes the most practical advantage of existing technologies, and then test the feasibility of that architecture by describing how the most important requirements can be implemented with it.

The result will never be the simplest, or the most optimal solution overall.  But it will be the most practically achievable.

Or, looking now at Charles’s response, I may be completely mischaracterizing intent behind your question!

Best regards,

—David

[Charles Schmidt]

Hi all,

Thanks for the discussion.

I'm not sure where we stand on this question – the three of us may have been talking about different things.

 

To go back to Adam's original question (I think), we are trying to come up with example of a baseline goal that we want to accomplish.

 

My personal sense is that, for the first stage of this project, we should be focusing on taking the general tools and capabilities we have and building better links between them to make them work more efficiently and powerfully. While we probably want to go beyond that eventually, I feel that we need a foundation (both for technical reasons and for adoption reasons). I think the use case I pose is a reasonable foundational capability; I worry that the capability Adam described (if I understood it correctly) would require exactly the type of data model that David described, with all the attendant challenges. I think that, at least for SCAP 2.0, we should focus on more foundational capabilities.

Thanks,

Charles

On Friday, April 24, 2020 at 6:09:56 PM UTC-5, David Solin wrote:

The *simplest* way to do this would be to create a data model centered around the controls you want to implement.  The problem is that such a model would not be flexible.  What if you need to implement a new control that was never previously envisioned?

It is tempting to want to take a blank-sheet-of-paper approach to devising a revolutionary new system, but abandoning the product of generations of iterative development, expertise and lessons-learned comes at the cost of very likely having to reinvent and reproduce virtually all of it.

My preference is to take the next generation's requirements, try to come up with the most flexible architecture to address them that takes the most practical advantage of existing technologies, and then test the feasibility of that architecture by describing how the most important requirements can be implemented with it.

The result will never be the simplest, or the most optimal solution overall.  But it will be the most practically achievable.

Or, looking now at Charles’s response, I may be completely mischaracterizing intent behind your question!

Best regards,

—David

On Apr 24, 2020, at 7:43 AM, Adam Montville <adam.mon...@gmail.com> wrote:

Good morning Everyone,

Reference Charles’ summary here: https://groups.google.com/a/list.nist.gov/forum/#!topic/scap-dev-endpoint/CozEcgf1pYU

Maybe what we could use is a target goal - a specific example of what it is we’re trying to achieve, then ask what is the minimum that needs to be done to meet that goal?

For example, consider an Application that needs to discover, for all computing resources within a company’s boundary of responsibility, conformance with a minimum password length of at least 20. 

Consider that this company has employees with laptops (Windows and Mac), a few Chromebooks, iOS and Android devices, and that they use AWS to provide services to their customers. Additionally, they have a website running on a hosted WordPress solution, network devices, and they use Salesforce. We could add to that a variety of IoT devices at their HQ (perhaps part of their HVAC system).

How can we design a decomposed architecture and associated information models with data model serializations to accomplish the above in the simplest way possible? Maybe we start with a subset of those computing resources and build a POC. Then maybe we continue the POC by adding a few more computing resource classes. Then we write down what we’ve learned. What are the interfaces actually necessary? How tough is normalizing information coming from different methods of collecting state values? And so on.

Kind regards,

Adam

--

To unsubscribe from this group, send email to scap-dev...@list.nist.gov

Visit this group at https://list.nist.gov/scap-dev-endpoint
---

To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev...@list.nist.gov.

[Adam Montville]

Hi Charles,

I’m also interested in what others are thinking at this point. I know we don’t want to reimagine everything. I also feel some pressure to accommodate more and to strive for an ultimate goal. We may not achieve that with 2.0, but we can’t ignore the dynamics of the environment we’re faced with either.

How close can we get to the goal today?

How close can we get to the goal with the direction we’re heading with 2.0?

Where are the gaps?

Kind regards,

Adam

To unsubscribe from this group, send email to scap-dev-endpo...@list.nist.gov

Visit this group at https://list.nist.gov/scap-dev-endpoint
--- 

To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-endpo...@list.nist.gov.

[Charles Schmidt]

Hi all,

I think one key question I am left with from this thread is whether the process we are trying to standardize in the data collection architecture starts with the Application saying "I want to know X" or whether it starts with "I have SCAP content that will collect X and I want it applied against the enterprise". My personal opinion is that, within the scope of the endpoint data collection architecture, we should start with the latter.

Back in the beginning of SCAP v2, the NSA/NIST whitepaper proposed a combined architecture that covered data collection, data evaluation, and content gathering. I view our current work as focusing on a subset of this overall vision, and that other pieces will be addressed separately.

I think we need, as a group, to come to agreement on the question of whether the process we are standardizing starts with an Application sending specific content assessment instructions, or whether it sends higher-level questions that the architecture needs to figure out how to answer. I agree with David that the latter will be orders of magnitude harder. I would prefer to tackle the merely-challenging first.

Charles

[Bill Munyan]

Hello All, 

First, I'm OK with, in the context of SCAP endpoint data collection architecture, to focus on SCAP content.  Seems reasonable for the SCAP effort.  Does this imply that the "SCAP Content" will only be referencing OVAL or OCIL (and probably not really OCIL) as the collection/checking systems?  Right now, are OVAL & OCIL the only officially recognized SCAP checking language?  That could narrow the scope of Collector capabilities, right?

Something we can talk about later this morning as well.

Cheers, 

-Bill M.

--

[Charles Schmidt]

Hi Bill,

Good point. In a different thread there was broad agreement that we want to support checking with OVAL and many other checking languages besides. I don't know that any of the other languages will become "official SCAP languages", but that shouldn't preclude their use in this architecture.

In my response above, please replace "SCAP content" with "checking instructions". No exclusivity was intended.

Charles

On Thursday, May 14, 2020 at 7:57:45 AM UTC-5, Bill Munyan wrote:

Hello All, 

First, I'm OK with, in the context of SCAP endpoint data collection architecture, to focus on SCAP content.  Seems reasonable for the SCAP effort.  Does this imply that the "SCAP Content" will only be referencing OVAL or OCIL (and probably not really OCIL) as the collection/checking systems?  Right now, are OVAL & OCIL the only officially recognized SCAP checking language?  That could narrow the scope of Collector capabilities, right?

Something we can talk about later this morning as well.

Cheers, 

-Bill M.

On Fri, May 8, 2020 at 3:34 PM Charles Schmidt <schmidt...@gmail.com> wrote:

Hi all,

I think one key question I am left with from this thread is whether the process we are trying to standardize in the data collection architecture starts with the Application saying "I want to know X" or whether it starts with "I have SCAP content that will collect X and I want it applied against the enterprise". My personal opinion is that, within the scope of the endpoint data collection architecture, we should start with the latter.

Back in the beginning of SCAP v2, the NSA/NIST whitepaper proposed a combined architecture that covered data collection, data evaluation, and content gathering. I view our current work as focusing on a subset of this overall vision, and that other pieces will be addressed separately.

I think we need, as a group, to come to agreement on the question of whether the process we are standardizing starts with an Application sending specific content assessment instructions, or whether it sends higher-level questions that the architecture needs to figure out how to answer. I agree with David that the latter will be orders of magnitude harder. I would prefer to tackle the merely-challenging first.

Charles

--

To unsubscribe from this group, send email to scap-dev...@list.nist.gov

Visit this group at https://list.nist.gov/scap-dev-endpoint
---

To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev...@list.nist.gov.