Notes from May 27 Telecon

[Charles Schmidt]

Hi all,

Below are my notes from today's teleconference. Thank you all for the great discussion. Comments and corrections are welcome.

Charles

-----------------------

Attending: Charles Schmidt, Joe Sain, Masato Terada, Joe Wolfkiel, Stephen Banghart, Jessica Fitzgerald-McKay, David Solin, Bill Munyan, Adam Montville

Monitoring Overlay

• -          The group had not yet had time to review Charles's model. (https://groups.google.com/a/list.nist.gov/forum/#!topic/scap-dev-endpoint/UbPq0DhTT38) They agreed to review it and respond online and/or discuss on the group's next call.

Main Challenge Solved by the SCAP Architecture

• -          This discussion stemmed from an online post from Adam. (https://groups.google.com/a/list.nist.gov/forum/#!topic/scap-dev-endpoint/TmyBHy_xqz8) Adam proposed that the Application send general assertions (e.g., "password policy should require passwords >= 8") rather than checking instructions. The idea was that these general assertions were platform agnostic, and thus could be used to initiate assessments across all enterprise assets rather than having each assessment being platform specific (as is the case with most check instructions). He felt that just having the Application send checking instructions would provide little value.
• -          Charles and Stephen both expressed concern that creating the model for capturing relevant security concepts in a platform agnostic way would be very difficult. Charles noted that such a vision was explored in the earliest days of CCE, but dropped in favor of the current, platform-specific identifiers. No one was opposed to the idea per se, but the concern was about how difficult it would be to realize and the delays it would create in SCAP development. Adam agreed it would be challenging, but felt the challenge was not excessive.
• -          Joe W. noted that CCI is a correlator, but focuses on policy/compliance correlation (e.g., relationship to things like 800-53) rather than a technical correlator (e.g., general system attributes to specific checking instructions). It was noted that the two types of correlators are related but not the same.
• -          David noted that one of the advantages of sending checking instructions is that it is clearer as to what is happening. He noted that the creation of OVAL was due to many parties expressing higher-level assessment requests ("Check for CVE-1234") but tools were coming back with different results.
• -          Charles suggested that, ultimately, "logical instructions" (i.e., those that were expressed in platform agnostic terms) would need to be converted into "technical instructions" (i.e., platform-specific instructions, such as OVAL) in order to be run. Adam agreed that, at some level, there would need to be platform-specific checking instructions so tools would be able to take specific actions.
• -          Given this, Charles suggested that there might be a new Translator component that took logical instructions as an input and delivered technical instructions as output. This conversion would likely take place through some combination of Internet and local database lookups. If so, such a Translator could integrate with the existing SCAP architecture, allowing the current SCAP data collection architecture to focus on routing of technical instructions while any work on developing a framework for logical instructions could be done in parallel. The only tweak to the architecture would be noting that Applications might send logical, rather than technical, instructions, but since the architecture has minimal standardization of Applications, this is not a significant burden.
• -          There was some discussion of where a Translator might reside in the architecture and the role of the Repository, but it was agreed that, since all components represent capabilities rather than distinct devices, it is fine to consider the Translator and any local storage of technical instructions as separate boxes in the diagram for now.
• -          Conclusion:

o   The SCAP data collection architecture is and will remain compatible with the ideas of using Logical Instructions.

o   Support for Logical Instructions would involve addition of new SCAP components in the architecture.

o   Logical Instructions would not replace Technical Instructions, such as OVAL. They are simply a different way an Application might express an assessment request.

o   The current components of the SCAP data collection architecture (Manager, Collector, Repository, PCE, and PCX) can remain focused on Technical Instructions.

o   As such, development of the SCAP data collection architecture can continue to progress independently of any efforts to create a Logical Instruction framework. The latter might be spun up in the SCAP group or elsewhere but does not need to add any delays to the SCAP data collection architecture work.

 

==== ACTION ITEMS =====

Everyone – Review the Monitoring Overlay materials and provide feedback.

Adam – Write up thoughts on what a Logical Instruction framework effort might look like.

Charles – Finish revised write-up of the SCAP data collection architecture.

[Adam Montville]

Charles,

Thanks for sending out the notes. I’ve attached a quick write-up on computing resources as a refresher for the information that was shared at the workshop this past Fall. I was remote for that workshop, but seem to remember that there was some support for the idea.

Kind regards,

Adam

[Charles Schmidt]

Thanks for sharing, Adam. I believe this aligns with part of CIS's presentation on developing Information Models Before Data Models, given by Tim on September 18, 2019. 

Are you thinking that this work might be a first step towards the idea of a "logical request" language, that could express assessment instructions in a platform agnostic manner (later to be translated into platform specific "technical requests", such as OVAL or other languages)?

Thanks,

Charles

[Adam Montville]

Hi Charles, 

Sorry for my delayed response. Yes, I believe this approach has promise. The way I see it, whether we use OVAL, PowerShell, CLI, NETCONF/RESTCONF, Ansible, Chef, whatever, we’re going to end up “talking about” the same things, just in different languages. If we are expected to understand any sort of same-as relationship, we need a model to bridge the worlds.

So, I (as a policy/compliance guy, or even as a threat hunter or incident responder) could say something like “get me the value of Windows registry X on all Windows 10 machines” and not care about the details. Some data may be ultimately collected by OVAL, some data from a vendor tool using a proprietary language. 

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 Adam,

Thanks for the response.

Your example is very interesting to me since it is not platform agnostic. In fact, it describes exactly the situation we are planning to support in the current SCAP data collection architecture: technical instructions (such as OVAL) arrive at a Collector, but the PCE might not speak OVAL so the Collector is responsible for translating the OVAL collection guidance into whatever commands the PCE understands and then the PCE handles the collection using whatever method it wants.

So it seems that there are a couple levels of this "abstraction" idea, some of which are part of the current design of the data collection architecture and some of which are not:

1) The current vision for the data collection architecture is that Collectors serve as the bridge between the official supported technical instruction languages of the data collection architecture and whatever instructions are understood by its associated PCEs. We would want the list of "official supported technical instruction languages" to be relatively small since all Collectors would need to understand them and translate them as necessary, but the set of languages supported by PCEs would be unlimited. In short, it has always been the vision that OVAL (and any other technical instruction languages we chose to make official) would have the task of conveying instructions to the Collectors, but the actual means of collection, as executed by PCEs, would not be limited in any way.

2) There was also discussion on our previous call of supporting platform-independent "logical" instructions. For example, "collect the minimum allowable password length across all platforms". This would allow the Application to express policy in a platform agnostic manner, but would require another level of translation between these logical instructions and the platform-specific technical instructions the Collectors need. We agreed that, while the architecture was compatible with this idea, that this was separable and could be integrated later by adding new components to the architecture to support this logical-to-technical translation at some point.

So as far as your thoughts: are you thinking more about option 1 or option 2. If the former, that has always been part of the architecture vision and is described in the current architecture document. For option 2, I think that would be a separate development effort that, while compatible with the vision for the architecture, does not need to be addressed immediately to make progress.

Charles

On Wednesday, June 3, 2020 at 9:45:51 AM UTC-5, Adam Montville wrote:

Hi Charles, 

Sorry for my delayed response. Yes, I believe this approach has promise. The way I see it, whether we use OVAL, PowerShell, CLI, NETCONF/RESTCONF, Ansible, Chef, whatever, we’re going to end up “talking about” the same things, just in different languages. If we are expected to understand any sort of same-as relationship, we need a model to bridge the worlds.

So, I (as a policy/compliance guy, or even as a threat hunter or incident responder) could say something like “get me the value of Windows registry X on all Windows 10 machines” and not care about the details. Some data may be ultimately collected by OVAL, some data from a vendor tool using a proprietary language. 

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,

It’s not platform agnostic - that example isn’t. It is collection mechanism agnostic. And, I didn’t talk enough about the possibility for another related model of common configuration items (yes, I’m aware that a CCI exists). In reality, before such a common view could be had, we’d need to understand platform specifics. These relate to options 1 and 2 (I think) as you described.

I’d like to see both.

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 Adam,

Thanks for the response. I think we are on the same page - sorry for my earlier confusion.

It sounds like we are all in agreement that the current data collection architecture, with its collection mechanism agnostic design, is the right path forward and we will continue with the current design. In that regard, There shouldn't be any need to develop any frameworks beyond what we already have with current checking languages.

The higher level, "logical" instruction mechanism that we talked about last week, which is platform agnostic, remains of interest. This will require development of a new framework for understanding instructions at this level, but would be a separable and separate effort, although later integration should not be hard.

The bottom line (if I am understanding you) is that we agree the current design is on track with your vision and can serve as a basis to other efforts to built the logical instruction mechanisms that would allow Applications to issue more general, platform agnostic commands.

As always, please let me know if I am misunderstanding.

Thanks,
Charles

On Wednesday, June 3, 2020 at 10:22:04 AM UTC-5, Adam Montville wrote:

Hi Charles,

To unsubscribe from this group, send email to scap-dev-endpoint+unsub...@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-endpoint+unsub...@list.nist.gov.

[David Solin]

I’m sorry I’m late to the party for this particular discussion, but I suppose we can take it up during today’s call.

I am hoping we all agree that #2 can simply be addressed by creating a library of checks in the (existing) lower-level check languages we already have.  That is, you can create a single over-arching password length check in the meta-vocabulary, but it would merely contain platform-specific password-length checks already implemented in a check language like OVAL.  I think that’s achievable.  Then all our data collection architecture work remains relevant.

Adam’s presentation gives me nightmares, though, because discussions of data models built from first principles gives me flashbacks to failed projects in my past experience.  I do not want to call for the creation of a new checking language based on a new universal ontology, that must be created from scratch, then implemented from scratch, and then come up with a data collection architecture for that.

Best regards,

—David Solin

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.