Proposal: Add new appcmd and appcmdlistconfig tests for checking IIS servers on Windows, and fix backward compatibility typo on EntityItemFileTypeType

[vanderpol]

Fixing typo documented in ticket #31

[solind]

This enumeration element should be re-added for backwards-compatibility, but also, it should be deprecated, as it's now part of EntityItemFileAttributeType, which is where it belongs.

[vanderpol]

@solind, as this is my first attempt at github PR's, I think I may have made a mistake, and not sure how to fix. I was planning to make 2 Pull Requests from my same branch, one for the old typo FILE_ATTRIBUTE_DIRECTORY stuff, and one pull request for the new appcmd and appcmd list config, but it appears they are all on this PR now? Should I rename this PR to reflect the appcmd additions?

[solind]

@vanderpol I think each PR is tied to a branch. Since these are both for the same branch of the same fork, they get merged into a single PR. You'd need a different fork to have two separate PRs at the same time.

Anyone should feel free to correct me if I'm wrong.

[vanderpol]

@solind it appears you are correct, which I just learned the hard way. As the FILE_ATTRIBUTE_DIRECTORY typo was just something I noticed when diffing files, I'll just make it a sub-point on the appcmd and appcmdlistconfig PR.

[solind]

I think that would be fine. They're both Windows-related anyway.

[solind]

Hey @vanderpol, I'm having trouble implementing collection the new appcmdlistconfig_object. In general, appcmd commands take the form (using the entity names from these appcmd_objects):

appcmd list <identifier_type> <identifier> <parameter>

I therefore don't understand what the "section" is supposed to signify. And also, while I am familiar with "site", "vdir" and "apppool" types, I'm unfamiliar with the "webserver" construct. It is not understood as an <identifier_type> by appcmd.exe, at least, not on the ancient machine I'm playing with. Is there a particular version of IIS that's needed to make sense of this?

[vanderpol]

Sorry for the delay @solind, I'll have the developer who created the proposal, @bryanlwilson research and comment.

[bryanlwilson]

@solind

For the appcmdlistconfig test your format is slightly off ... you said:
appcmd list identifier_type identifier parameter

that is the format for the appcmd test... for the appcmdlistconfig content will build this:

appcmd list config identifier /section:system.webServer/security/authentication/anonymousAuthentication /text:logonMethod

(I left example section and parameter to show how it looks. logonMethod is the parameter and system.webServer/security/authentication/anonymousAuthentication is the section. The identifier must be site, vdir or webserver).

So for appcmdlistconfig the identifier_type can either be site, vdir or webserver. How it works is the word site, vdir and webserver will not be added to appcmd list config even though it must be defined in content. Instead the tool knows how to handle it. If the identifier_type is vdir or a site the tool knows to populate identifier with the site name or the vdir name given as the identifier. If the identifier_type is webserver then it is not a setting related to a site or vdir, it's a configuration setting for the webserver. For this no identifier is given. In fact if you set indentfier_type to webserver, the identifier should be set to nil in content. So you are correct the word webserver will never show up in the actual appcmd test created by the scanning tool. But content must define it so the scanning tool can create appropriate appcmd using list config to gather information properly.

I have attached my disa examples content which shows examples of each identifier type test. I had to change extension from .xml to .txt to get it to upload. This content file contains commented appcmd format (helping you understand "translation") for each appcmdlistconfig obect.

win-def_appcmdlistconfig_test_disaexamples.txt

[solind]

Hi @bryanlwilson, I was looking for the samples in my email history but couldn't find what I was looking for... are they inside the old Sandbox project?

[solind]

Nevermind, I found the samples here: #76 (comment)

Very helpful!

[solind]

OK, this is good. Now if I modify the appcmd_state/result@datatype="int" in the test content, the "greater than" comparison works properly.

Just a few final notes...

I think, based on the DISA content samples, that the identifier operations are all implied to be case-insensitive -- including "pattern match" and "equals". If that's the case, we should document this.

[bryanlwilson]

OK, this is good. Now if I modify the appcmd_state/result@datatype="int" in the test content, the "greater than" comparison works properly.

Just a few final notes...

I think, based on the DISA content samples, that the identifier operations are all implied to be case-insensitive -- including "pattern match" and "equals". If that's the case, we should document this.

@solind
I concur with documentation update. Are there schema examples that have case-insensitive documented? If so should that be the template for the update?

[solind]

Hi @bryanlwilson , looking at the OVAL schema documentation, it looks like the standard verbiage for this behavior in the object entity is:

In Windows, [case-insensitive-thing] are case-insensitive. As a result, it is recommended that the case-insensitive operations are used for this entity.

I think this generally implies that an interpreter should treat the entity as case-insensitive, but it doesn't absolutely necessitate that.

Since patterns cannot easily be specified as case-insensitive (OVAL Regex doesn't permit modifiers like '(?i)' -- you have to use [Tt][Hh][Ii][Ss] kind of construct instead), I think it may make sense to spell out that "pattern match" operations should be treated as case-insensitive for that entity.

[solind]

Sorry I missed the meeting this morning; I see I've been asked to review this pull request.

How/why are there suddenly 62 files that are part of this PR? It seems a ton of schema formatting and documentation changes have become lumped in with what should be a relatively simple proposal. Did you all discuss this in the meeting today?

[wmunyan]

@solind it was because we noticed that the PR was using master as the base, and we needed to change it to develop. I think @vanderpol (and/or his team) will be doing some Git work to rebase.

[vanderpol]

Per the oval team lead meeting today I changed the branch from master to develop, and then per direction from the team, rebased the appcmd branch against the develop branch, in hopes of just having the history and commits that I performed (4 commits to appcmd), but so far it does not seem to have improved it.

[solind]

@vanderpol worst-case, you can close this PR, check out the develop branch, make your additions in there, and then submit another PR referencing this one.

[vanderpol]

Oh how I love github... if anyone else wants to be the Windows OVAL area supervisor, please let me know... It's open for the taking.

[solind]

If it's any help, @vanderpol, I have broken out the changes for your IIS tests here:
https://github.com/joval/jOVAL/blob/master/scap/schemas/oval/unofficial/windows-iis-def-schema.xsd

and here:
https://github.com/joval/jOVAL/blob/master/scap/schemas/oval/unofficial/windows-iis-sc-schema.xsd

[vanderpol]

I have created a new PR #122 , which is based on the develop branch and supersedes this PR, I'm closing this one.