Re: [Rats] my comments on the mic line

[Kathleen Moriarty <[e-mail]>]

Greetings!

I'll start here and work backwards as not to address something twice.

I appreciate the feedback and consideration and welcome more after an
update that addresses the relevant comments and incorporates thoughts of
new co-authors.

On Wed, Nov 8, 2023 at 1:56 PM Tom Jones <[e-mail]>
wrote:

> This area seems out of scope for standardization at all. It is internal
> enterprise decision. It could be included in a best practice for a specific
> industry or use case. It would never be possible IMO for general use.
>

The IETF typically works on what is required for interoperability on the
wire (as a former IETF Security area director). The draft is specifically
limited to that goal. This is also why Dave said his draft was architecture
and will be categorized as informational (it won't be passed on the wire
and there may be multiple ways to accomplish what has been put forth in
that draft.)

Let's say a container orchestration system like vSphere or OpenShift
perform an assessment to see if an operating system meets the controls that
are expected by a predefined policy. The result of this will need to be
communicated to a system that gathers that type of result of all the
systems, containers, applications in an administrative domain. The summary
statement needs to be consistent so the container orchestration system can
summarize the result in an attestation that essentially is to say the
policy was met (or not) to that GRC system. The collection system of these
results might be a traditional GRC system, and could also be a Container
Security Posture Management (CSPM) or a CNAPP management system.

The policy might be a vendor specific policy, called either a Benchmark or
a hardening guide. The name of the guide and the level the policy is met or
not needs to be conveyed to create the larger picture for the
administrative domain.



> I would much prefer that someone focus on a policy language to be sure
> that an unambiguous policy is possible. I have worked on one of those and
> found it to be missing any kind of rigor.
>

I'd put a policy language definition out-of-scope for the IETF. It does not
need to be consistent on the wire, but the result that settings and
measurements met (or didn't) expected values needs to be conveyed. Having
been involved in many of these types of projects over the years, they have
value, but take up lots of unnecessary cycles and funding. OVAL was one of
the standards for this purpose on traditional systems, but it is not a good
fit for virtualized or container systems. The path industry has taken in
recent years (and my team has data on this after studying the full product
market and profiling what is used where) is to shift from OVAL to vendor
specific APIs or SSH into systems (e.g. ansible, puppet).

What we all care about is a level of assessment to a specified set of
Benchmarks at a specified level. This draft is not complete on purpose to
get input and to work collaboratively. Its intent is to establish a
registry where you can convey which Benchmark, policy standard, or
hardening guide was used, what level (defined for each) was met, and a way
to convey any issues with meeting configuration settings or measurements.

I hope this bigger picture helps with a better understanding of the goals
and the importance as it was specifically limited to what was needed to be
conveyed on the wire to facilitate interoperability while allowing vendors
an ability to quickly evolve their policy language. Ideally, the Benchmarks
and each level would be available for customer use as a selection to assure
compliance within the container orchestration system. It's not practical to
share evidence on the wire when assessing each value as that would be too
much data, hence the local or "implicit" attestation recommendation for
policy verification to the Benchmark.

Perhaps Benchmark is a new term to some and I can help with that if needed.
Hardening guides and loosening guides are the other names, but Benchmark
conveys better the goal of setting the Benchmark to be met with levels
possible depending on risk tolerance.

Best regards,
Kathleen

>
> thx ..Tom (mobile)
>
> On Wed, Nov 8, 2023, 7:11 AM Kathleen Moriarty <
> [e-mail]> wrote:
>
>> Thank you, Thomas!
>>
>> I also appreciate the introduction you provided and will sync with Marc
>> and the GRC team at Confidential Computing.
>>
>> Monty had also offered to engage. I'd like to sync with Monty and work
>> together to update terms to better align with the terms being used now. We
>> will also work with the GRC group and perhaps pull both Monty (if willing)
>> and Marc in as co-authors to get a good solution in place that will meet
>> industry needs. I'm open to co-authors and very happy to have collaborators.
>>
>> A.J. also offered that he'd like to contribute and that's welcome!
>>
>> My main objective is to get a good format and registry started with the
>> right set of claims to convey when a set of policies and measurements
>> (claim set) has been met (or has not) to convey compliance information to a
>> management system. This is a gap that needs filling or we will wind up with
>> compliance systems that operate in multiple ways with competing products.
>> (I do have that set of possibilities mapped out and it would confuse the
>> discussion here to bring it up. I'm happy to chat offline on those 3
>> areas.) I'd like to see an affordable method to assure OS and applications
>> that are as built-in as possible, hence this proposal that ties to Dave's
>> endorsements draft.
>>
>> Best regards,
>> Kathleen
>>
>> On Wed, Nov 8, 2023 at 7:12 AM Thomas Fossati <[e-mail]>
>> wrote:
>>
>>> Hi Kathleen,
>>>
>>> sorry you didn't feel good, I hope you'll recover soon!
>>>
>>> This is a copy of the comments I made on the mic line, feel free to
>>> address them whenever you feel better.
>>>
>>> First of all, for me, it is important to get a grasp of the system
>>> architecture you have in mind to understand whether this work is in
>>> the scope of RATS.
>>>
>>> IIUC, you have a composite device that produces complex, multi-layered
>>> evidence.  Then a (local) verifier appraises the evidence and produces
>>> an attestation result.  Then a relying party (i.e., some kind of
>>> governance/risk-compliance application) uses its application-specific
>>> appraisal policy to process the attestation result and create an
>>> “attestation” (= NIST definition #2, see [1]) using the claims you
>>> want to define/register.
>>>
>>> If that is the case, it'd seem to me that the claims set is outside of
>>> the RATS picture - they'd be a message coming out of the RP box in the
>>> bottom right-hand corner of the architecture picture.
>>>
>>> If that is not the case - apologies if I misconstrued your design :-)
>>> - and the claims set is part of the attestation result coming out of
>>> the verifier, then it's good to go for me because this would be
>>> semantics encoded in one of the RATS conceptual messages.
>>>
>>> In any case, RATS or not, this is very relevant work.
>>>
>>> cheers, thanks!
>>>
>>> [1] https://csrc.nist.gov/glossary/term/attestation
>>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
>>
>

-- 

Best regards,
Kathleen