First test for the SharePoint component schema

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

First test for the SharePoint component schema

Morrison, Linda E.

Hello;

 

Last fiscal year we produced a SharePoint Sever 2007 Security Guide for our sponsor.  This guide was produced and delivered to our sponsor in the NIST XCCDF standard.  This year we are producing compliance checks for all of our checkable recommendations in the security guide. 

 

After several discussions with Microsoft we confirmed that we should develop our  SharePoint component schema based on the SharePoint Object Model (Windows SharePoint Services 3.0). 

 

I have attached the SharePoint component schema files containing our first test (spwebappliation_test).  The spwebapplication_test is used to check the properties or permission settings of a SharePoint web application.  We are continuing to develop tests for other SharePoint security items.  If anyone has any feedback on the attached SharePoint component schema, please let me know. 

 

Thanks,

 

Linda Morrison

The MITRE Corporation

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

sharepoint-system-characteristics-schema.xsd (72K) Download Attachment
sharepoint-definitions-schema.xsd (80K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: First test for the SharePoint component schema

mmcavoy

Did you look into directly querying the Windows Internal database used by SharePoint instead of creating a new schema?  (info: http://www.davidpokluda.com/Blog/post/Connecting-to-SharePoint-embedded-database.aspx)  I’m just wondering what kind of precedent we’re setting by creating application specific schemas.  Do you think the scenario with SharePoint is unique?  What kind of impact will lots of application specific schemas have on OVAL interpreters/ tool developers?  Is there some way we can make the schema more generic or apply to more than just SharePoint- some sort of schema that any application using a database can use, etc.? 

 

Thanks,

Melissa Albanese

 


From: Morrison, Linda E. [mailto:[hidden email]]
Sent: Tuesday, April 14, 2009 9:21 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Hello;

 

Last fiscal year we produced a SharePoint Sever 2007 Security Guide for our sponsor.  This guide was produced and delivered to our sponsor in the NIST XCCDF standard.  This year we are producing compliance checks for all of our checkable recommendations in the security guide. 

 

After several discussions with Microsoft we confirmed that we should develop our  SharePoint component schema based on the SharePoint Object Model (Windows SharePoint Services 3.0). 

 

I have attached the SharePoint component schema files containing our first test (spwebappliation_test).  The spwebapplication_test is used to check the properties or permission settings of a SharePoint web application.  We are continuing to develop tests for other SharePoint security items.  If anyone has any feedback on the attached SharePoint component schema, please let me know. 

 

Thanks,

 

Linda Morrison

The MITRE Corporation

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email]. To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: First test for the SharePoint component schema

Morrison, Linda E.

Melissa,

 

Initially we tried to identify the location of the data on the system for our recommendations, for some recommendations we found the data was stored in XML files and we suspected that it was also being written to the SharePoint database.  We were able to look at the many tables in the SharePoint databases, however we did not locate the data for our recommendations.   We had several meetings with Microsoft to explain our task and explain OVAL.  Microsoft suggested that we do not use the XML files because the configuration information stored in them may not always be up to date.  Microsoft convinced us that the XML files and querying the database was not the right place to check the configuration state of SharePoint.  They felt that the SharePoint object model would be the best way for us to retrieve the configuration data that we need.  Also, many of the products that help manage SharePoint use the SharePoint object model.  Let me know if you have any other questions.

 

Thanks,

 

Linda

 

 

From: Melissa McAvoy [mailto:[hidden email]]
Sent: Tuesday, April 14, 2009 11:49 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Did you look into directly querying the Windows Internal database used by SharePoint instead of creating a new schema?  (info: http://www.davidpokluda.com/Blog/post/Connecting-to-SharePoint-embedded-database.aspx)  I’m just wondering what kind of precedent we’re setting by creating application specific schemas.  Do you think the scenario with SharePoint is unique?  What kind of impact will lots of application specific schemas have on OVAL interpreters/ tool developers?  Is there some way we can make the schema more generic or apply to more than just SharePoint- some sort of schema that any application using a database can use, etc.? 

 

Thanks,

Melissa Albanese

 


From: Morrison, Linda E. [mailto:[hidden email]]
Sent: Tuesday, April 14, 2009 9:21 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Hello;

 

Last fiscal year we produced a SharePoint Sever 2007 Security Guide for our sponsor.  This guide was produced and delivered to our sponsor in the NIST XCCDF standard.  This year we are producing compliance checks for all of our checkable recommendations in the security guide. 

 

After several discussions with Microsoft we confirmed that we should develop our  SharePoint component schema based on the SharePoint Object Model (Windows SharePoint Services 3.0). 

 

I have attached the SharePoint component schema files containing our first test (spwebappliation_test).  The spwebapplication_test is used to check the properties or permission settings of a SharePoint web application.  We are continuing to develop tests for other SharePoint security items.  If anyone has any feedback on the attached SharePoint component schema, please let me know. 

 

Thanks,

 

Linda Morrison

The MITRE Corporation

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email]. To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: First test for the SharePoint component schema

Andrew Buttner
Administrator
In reply to this post by Morrison, Linda E.
Instead of creating a test for each class of interest in the object model, would it be better to create a test based off of the FullTextSqlQuery class?  This would end up being similar to the current WMI and SQL tests, but would be focused on the SharePoint Object model.

Thoughts?

Thanks
Drew

>-----Original Message-----
>From: Morrison, Linda E. [mailto:[hidden email]]
>Sent: Tuesday, April 14, 2009 9:21 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component
>schema
>
>Hello;
>
>
>
>Last fiscal year we produced a SharePoint Sever 2007 Security Guide for
>our sponsor.  This guide was produced and delivered to our sponsor in
>the NIST XCCDF standard.  This year we are producing compliance checks
>for all of our checkable recommendations in the security guide.
>
>
>
>After several discussions with Microsoft we confirmed that we should
>develop our  SharePoint component schema based on the SharePoint Object
>Model (Windows SharePoint Services 3.0).
>
>
>
>I have attached the SharePoint component schema files containing our
>first test (spwebappliation_test).  The spwebapplication_test is used to
>check the properties or permission settings of a SharePoint web
>application.  We are continuing to develop tests for other SharePoint
>security items.  If anyone has any feedback on the attached SharePoint
>component schema, please let me know.
>
>
>
>Thanks,
>
>
>
>Linda Morrison
>
>The MITRE Corporation
>
>
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: First test for the SharePoint component schema

Morrison, Linda E.
Drew,

I have done a lot of searching and it seems that this class is used to search a site or across sites for documents matching a search query.  I have found a lot of examples to do this:

http://social.technet.microsoft.com/Forums/en-US/sharepointdevelopment/thread/df90b1f5-67a3-407c-9dff-8dcf814c24d3/
The Microsoft.SharePoint.Search.Query only supports the built-in metadata columns for search by design. The column names used in the FullTextSqlQuery should be valid managed proprieties. Some of the important managed properties are mentioned in the document attached with this blog named properties.txt. The query elements which are supported only with SQL search syntax using the FullTextSqlQuery class are:
* FREETEXT() - Searches for the search term everywhere, even in the content of the documents if specified like this FREETEXT(*, '" + searchString + "')) where * denotes search in all managed proprieties. Instead of "*" you can mention the managed property name in which you want to search. The FREETEXT() is better suited to finding documents containing combinations of the search words spread throughout the column.
* CONTAINS() - Is better suited to search for the exact search term mentioned. You can also use  the wildcard character at the end of the word or phrase, e.g., CONTAINS(Title, 'comp*) where "Title" is the column you need to search. If the column name is not specified, the Contents Column, which is the body of the document is specified.
* LIKE - Like can be used to search if the term exits at the beginning, end or even in between, e.g., Filename like '%" + searchString + "%'
* ORDER BY - Is used to place the search results in some particular order, e.g., ORDER By RANK DESC will order the search results based on RANK.


I don't see how this class will  help us find the configuration properties that we need to check.    

Thoughts?

Linda

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Wednesday, May 06, 2009 1:02 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

Instead of creating a test for each class of interest in the object model, would it be better to create a test based off of the FullTextSqlQuery class?  This would end up being similar to the current WMI and SQL tests, but would be focused on the SharePoint Object model.

Thoughts?

Thanks
Drew

>-----Original Message-----
>From: Morrison, Linda E. [mailto:[hidden email]]
>Sent: Tuesday, April 14, 2009 9:21 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component
>schema
>
>Hello;
>
>
>
>Last fiscal year we produced a SharePoint Sever 2007 Security Guide for
>our sponsor.  This guide was produced and delivered to our sponsor in
>the NIST XCCDF standard.  This year we are producing compliance checks
>for all of our checkable recommendations in the security guide.
>
>
>
>After several discussions with Microsoft we confirmed that we should
>develop our  SharePoint component schema based on the SharePoint Object
>Model (Windows SharePoint Services 3.0).
>
>
>
>I have attached the SharePoint component schema files containing our
>first test (spwebappliation_test).  The spwebapplication_test is used to
>check the properties or permission settings of a SharePoint web
>application.  We are continuing to develop tests for other SharePoint
>security items.  If anyone has any feedback on the attached SharePoint
>component schema, please let me know.
>
>
>
>Thanks,
>
>
>
>Linda Morrison
>
>The MITRE Corporation
>
>
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: First test for the SharePoint component schema

Andrew Buttner
Administrator
Ok, I see what you mean by this class not being a search of the config data, but rather the information stored on a SharePoint site.

I looked into Melissa's point about the Windows Internal Database, and I think this would be ideal for OVAL.  This is the low level location of the data we are after.  But it seems impossible to really look at this.  The data is always abstracted up through something like Windows SharePoint Services (WSS).

I liked figure 2 in http://msdn.microsoft.com/en-us/library/bb530302.aspx

But I feel a little uneasy about adding a test for a single class in WSS.  This just leads us down the road of a new test for every WSS class.  Ideally I am looking for some type of query mechanism that will allow one (or at least just a few) OVAL Tests that will allow us to look into this data.  (WMI??)

Granted I have no solution for this problem right now.  I am starting to think that the best current solution is to go down the Class = OVAL Test path.  Thoughts?

Thanks
Drew



>-----Original Message-----
>From: Morrison, Linda E. [mailto:[hidden email]]
>Sent: Thursday, May 07, 2009 3:29 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] First test for the SharePoint
>component schema
>
>Drew,
>
>I have done a lot of searching and it seems that this class is used to
>search a site or across sites for documents matching a search query.  I
>have found a lot of examples to do this:
>
>http://social.technet.microsoft.com/Forums/en-
>US/sharepointdevelopment/thread/df90b1f5-67a3-407c-9dff-8dcf814c24d3/
>The Microsoft.SharePoint.Search.Query only supports the built-in
>metadata columns for search by design. The column names used in the
>FullTextSqlQuery should be valid managed proprieties. Some of the
>important managed properties are mentioned in the document attached with
>this blog named properties.txt. The query elements which are supported
>only with SQL search syntax using the FullTextSqlQuery class are:
>* FREETEXT() - Searches for the search term everywhere, even in the
>content of the documents if specified like this FREETEXT(*, '" +
>searchString + "')) where * denotes search in all managed proprieties.
>Instead of "*" you can mention the managed property name in which you
>want to search. The FREETEXT() is better suited to finding documents
>containing combinations of the search words spread throughout the
>column.
>* CONTAINS() - Is better suited to search for the exact search term
>mentioned. You can also use  the wildcard character at the end of the
>word or phrase, e.g., CONTAINS(Title, 'comp*) where "Title" is the
>column you need to search. If the column name is not specified, the
>Contents Column, which is the body of the document is specified.
>* LIKE - Like can be used to search if the term exits at the
>beginning, end or even in between, e.g., Filename like '%" +
>searchString + "%'
>* ORDER BY - Is used to place the search results in some particular
>order, e.g., ORDER By RANK DESC will order the search results based on
>RANK.
>
>
>I don't see how this class will  help us find the configuration
>properties that we need to check.
>
>Thoughts?
>
>Linda
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Wednesday, May 06, 2009 1:02 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] First test for the SharePoint
>component schema
>
>Instead of creating a test for each class of interest in the object
>model, would it be better to create a test based off of the
>FullTextSqlQuery class?  This would end up being similar to the current
>WMI and SQL tests, but would be focused on the SharePoint Object model.
>
>Thoughts?
>
>Thanks
>Drew
>
>>-----Original Message-----
>>From: Morrison, Linda E. [mailto:[hidden email]]
>>Sent: Tuesday, April 14, 2009 9:21 AM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component
>>schema
>>
>>Hello;
>>
>>
>>
>>Last fiscal year we produced a SharePoint Sever 2007 Security Guide for
>>our sponsor.  This guide was produced and delivered to our sponsor in
>>the NIST XCCDF standard.  This year we are producing compliance checks
>>for all of our checkable recommendations in the security guide.
>>
>>
>>
>>After several discussions with Microsoft we confirmed that we should
>>develop our  SharePoint component schema based on the SharePoint Object
>>Model (Windows SharePoint Services 3.0).
>>
>>
>>
>>I have attached the SharePoint component schema files containing our
>>first test (spwebappliation_test).  The spwebapplication_test is used
>to
>>check the properties or permission settings of a SharePoint web
>>application.  We are continuing to develop tests for other SharePoint
>>security items.  If anyone has any feedback on the attached SharePoint
>>component schema, please let me know.
>>
>>
>>
>>Thanks,
>>
>>
>>
>>Linda Morrison
>>
>>The MITRE Corporation
>>
>>
>>
>>To unsubscribe, send an email message to [hidden email] with
>>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>difficulties, write to [hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: First test for the SharePoint component schema

Laura Curston
I HAVE ALREADY UNSUBCRIBED TO THIS.................NOW STOP SENDING ME THESE EMAIL PLEASE!!!!!!!!!!!

> Date: Thu, 14 May 2009 09:05:39 -0400
> From: [hidden email]
> Subject: Re: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema
> To: [hidden email]
>
> Ok, I see what you mean by this class not being a search of the config data, but rather the information stored on a SharePoint site.
>
> I looked into Melissa's point about the Windows Internal Database, and I think this would be ideal for OVAL. This is the low level location of the data we are after. But it seems impossible to really look at this. The data is always abstracted up through something like Windows SharePoint Services (WSS).
>
> I liked figure 2 in http://msdn.microsoft.com/en-us/library/bb530302.aspx
>
> But I feel a little uneasy about adding a test for a single class in WSS. This just leads us down the road of a new test for every WSS class. Ideally I am looking for some type of query mechanism that will allow one (or at least just a few) OVAL Tests that will allow us to look into this data. (WMI??)
>
> Granted I have no solution for this problem right now. I am starting to think that the best current solution is to go down the Class = OVAL Test path. Thoughts?
>
> Thanks
> Drew
>
>
>
> >-----Original Message-----
> >From: Morrison, Linda E. [mailto:[hidden email]]
> >Sent: Thursday, May 07, 2009 3:29 PM
> >To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >Subject: Re: [OVAL-DEVELOPER-LIST] First test for the SharePoint
> >component schema
> >
> >Drew,
> >
> >I have done a lot of searching and it seems that this class is used to
> >search a site or across sites for documents matching a search query. I
> >have found a lot of examples to do this:
> >
> >http://social.technet.microsoft.com/Forums/en-
> >US/sharepointdevelopment/thread/df90b1f5-67a3-407c-9dff-8dcf814c24d3/
> >The Microsoft.SharePoint.Search.Query only supports the built-in
> >metadata columns for search by design. The column names used in the
> >FullTextSqlQuery should be valid managed proprieties. Some of the
> >important managed properties are mentioned in the document attached with
> >this blog named properties.txt. The query elements which are supported
> >only with SQL search syntax using the FullTextSqlQuery class are:
> >* FREETEXT() - Searches for the search term everywhere, even in the
> >content of the documents if specified like this FREETEXT(*, '" +
> >searchString + "')) where * denotes search in all managed proprieties.
> >Instead of "*" you can mention the managed property name in which you
> >want to search. The FREETEXT() is better suited to finding documents
> >containing combinations of the search words spread throughout the
> >column.
> >* CONTAINS() - Is better suited to search for the exact search term
> >mentioned. You can also use the wildcard character at the end of the
> >word or phrase, e.g., CONTAINS(Title, 'comp*) where "Title" is the
> >column you need to search. If the column name is not specified, the
> >Contents Column, which is the body of the document is specified.
> >* LIKE - Like can be used to search if the term exits at the
> >beginning, end or even in between, e.g., Filename like '%" +
> >searchString + "%'
> >* ORDER BY - Is used to place the search results in some particular
> >order, e.g., ORDER By RANK DESC will order the search results based on
> >RANK.
> >
> >
> >I don't see how this class will help us find the configuration
> >properties that we need to check.
> >
> >Thoughts?
> >
> >Linda
> >
> >-----Original Message-----
> >From: Buttner, Drew [mailto:[hidden email]]
> >Sent: Wednesday, May 06, 2009 1:02 PM
> >To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >Subject: Re: [OVAL-DEVELOPER-LIST] First test for the SharePoint
> >component schema
> >
> >Instead of creating a test for each class of interest in the object
> >model, would it be better to create a test based off of the
> >FullTextSqlQuery class? This would end up being similar to the current
> >WMI and SQL tests, but would be focused on the SharePoint Object model.
> >
> >Thoughts?
> >
> >Thanks
> >Drew
> >
> >>-----Original Message-----
> >>From: Morrison, Linda E. [mailto:[hidden email]]
> >>Sent: Tuesday, April 14, 2009 9:21 AM
> >>To: oval-developer-list OVAL Developer List/Closed Public Discussion
> >>Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component
> >>schema
> >>
> >>Hello;
> >>
> >>
> >>
> >>Last fiscal year we produced a SharePoint Sever 2007 Security Guide for
> >>our sponsor. This guide was produced and delivered to our sponsor in
> >>the NIST XCCDF standard. This year we are producing compliance checks
> >>for all of our checkable recommendations in the security guide.
> >>
> >>
> >>
> >>After several discussions with Microsoft we confirmed that we should
> >>develop our SharePoint component schema based on the SharePoint Object
> >>Model (Windows SharePoint Services 3.0).
> >>
> >>
> >>
> >>I have attached the SharePoint component schema files containing our
> >>first test (spwebappliation_test). The spwebapplication_test is used
> >to
> >>check the properties or permission settings of a SharePoint web
> >>application. We are continuing to develop tests for other SharePoint
> >>security items. If anyone has any feedback on the attached SharePoint
> >>component schema, please let me know.
> >>
> >>
> >>
> >>Thanks,
> >>
> >>
> >>
> >>Linda Morrison
> >>
> >>The MITRE Corporation
> >>
> >>
> >>
> >>To unsubscribe, send an email message to [hidden email] with
> >>SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
> >>difficulties, write to [hidden email].
> >
> >To unsubscribe, send an email message to [hidden email] with
> >SIGNOFF OVAL-DEVELOPER-LIST
> >in the BODY of the message. If you have difficulties, write to OVAL-
> >[hidden email].
> >
> >To unsubscribe, send an email message to [hidden email] with
> >SIGNOFF OVAL-DEVELOPER-LIST
> >in the BODY of the message. If you have difficulties, write to OVAL-
> >[hidden email].
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST
> in the BODY of the message. If you have difficulties, write to [hidden email].


" Upgrade to Internet Explorer 8 Optimised for MSN. " Download Now To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

SharePoint component schema

mmcavoy
In reply to this post by Morrison, Linda E.

The “spiissettings” are all IIS specific settings, not SharePoint.  I believe many, if not all, can be checked directly through the registry.  If they can’t be checked through the registry or using some other existing test, then they should be in an IIS component schema as they would be used by any application using IIS, not just SharePoint. 

 

I’m not familiar with SharePoint, so I don’t know what other settings might also be found in the registry.  You (or anyone on the list who knows SharePoint internals) may want to revisit all of the suggested tests in the schema and look for overlap with existing OVAL tests. 

 

I think the only settings that should be in the SharePoint schema are the ones that are specific to SharePoint and not stored in a common storage repository.  Anything that’s stored in the registry, files, Windows Internal database, etc. should be tested via the most generic method available.  This encourages reuse of tests and makes it easier on tool developers. 

 

There may be a more fundamental discussion regarding the best way to organize tests within schemas. Should SharePoint related registry keys be listed in the SharePoint schema as new tests that extend the registry test or omitted from the SharePoint schema since they are already covered by other tests?   

 

Thanks,

Melissa Albanese

 


From: Melissa McAvoy
Sent: Tuesday, April 14, 2009 11:49 AM
To: 'OVAL Developer List (Closed Public Discussion)'
Subject: RE: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Did you look into directly querying the Windows Internal database used by SharePoint instead of creating a new schema?  (info: http://www.davidpokluda.com/Blog/post/Connecting-to-SharePoint-embedded-database.aspx)  I’m just wondering what kind of precedent we’re setting by creating application specific schemas.  Do you think the scenario with SharePoint is unique?  What kind of impact will lots of application specific schemas have on OVAL interpreters/ tool developers?  Is there some way we can make the schema more generic or apply to more than just SharePoint- some sort of schema that any application using a database can use, etc.? 

 

Thanks,

Melissa Albanese

 


From: Morrison, Linda E. [mailto:[hidden email]]
Sent: Tuesday, April 14, 2009 9:21 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Hello;

 

Last fiscal year we produced a SharePoint Sever 2007 Security Guide for our sponsor.  This guide was produced and delivered to our sponsor in the NIST XCCDF standard.  This year we are producing compliance checks for all of our checkable recommendations in the security guide. 

 

After several discussions with Microsoft we confirmed that we should develop our  SharePoint component schema based on the SharePoint Object Model (Windows SharePoint Services 3.0). 

 

I have attached the SharePoint component schema files containing our first test (spwebappliation_test).  The spwebapplication_test is used to check the properties or permission settings of a SharePoint web application.  We are continuing to develop tests for other SharePoint security items.  If anyone has any feedback on the attached SharePoint component schema, please let me know. 

 

Thanks,

 

Linda Morrison

The MITRE Corporation

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email]. To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: SharePoint component schema

Morrison, Linda E.

Melissa,

 

Thanks for the great input.  We were actually investigating if the IIS settings that we need to check were available through other means such as the registry, WMI, or metabase.  We have found that in IIS 6 most of the IIS settings are now stored in the Metabase and  not the registry.  There is a metabase.xml file that stores these settings.  OVAL has a metabase test that we have been investigating for our SharePoint SSL recommendations.  Since we have found that we can obtain the IIS information from the metabase.xml file and OVAL has a test available, we have removed the spiissettings test from our SharePoint schema. 

 

All other tests contained within the SharePoint schema should be SharePoint specific and we have not found these to be stored in any common storage repositories.

 

Let me know if you have any other questions or concerns.

 

Thanks

 

Linda

 

From: Melissa McAvoy [mailto:[hidden email]]
Sent: Monday, July 13, 2009 3:01 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] SharePoint component schema

 

The “spiissettings” are all IIS specific settings, not SharePoint.  I believe many, if not all, can be checked directly through the registry.  If they can’t be checked through the registry or using some other existing test, then they should be in an IIS component schema as they would be used by any application using IIS, not just SharePoint. 

 

I’m not familiar with SharePoint, so I don’t know what other settings might also be found in the registry.  You (or anyone on the list who knows SharePoint internals) may want to revisit all of the suggested tests in the schema and look for overlap with existing OVAL tests. 

 

I think the only settings that should be in the SharePoint schema are the ones that are specific to SharePoint and not stored in a common storage repository.  Anything that’s stored in the registry, files, Windows Internal database, etc. should be tested via the most generic method available.  This encourages reuse of tests and makes it easier on tool developers. 

 

There may be a more fundamental discussion regarding the best way to organize tests within schemas. Should SharePoint related registry keys be listed in the SharePoint schema as new tests that extend the registry test or omitted from the SharePoint schema since they are already covered by other tests?   

 

Thanks,

Melissa Albanese

 


From: Melissa McAvoy
Sent: Tuesday, April 14, 2009 11:49 AM
To: 'OVAL Developer List (Closed Public Discussion)'
Subject: RE: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Did you look into directly querying the Windows Internal database used by SharePoint instead of creating a new schema?  (info: http://www.davidpokluda.com/Blog/post/Connecting-to-SharePoint-embedded-database.aspx)  I’m just wondering what kind of precedent we’re setting by creating application specific schemas.  Do you think the scenario with SharePoint is unique?  What kind of impact will lots of application specific schemas have on OVAL interpreters/ tool developers?  Is there some way we can make the schema more generic or apply to more than just SharePoint- some sort of schema that any application using a database can use, etc.? 

 

Thanks,

Melissa Albanese

 


From: Morrison, Linda E. [mailto:[hidden email]]
Sent: Tuesday, April 14, 2009 9:21 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Hello;

 

Last fiscal year we produced a SharePoint Sever 2007 Security Guide for our sponsor.  This guide was produced and delivered to our sponsor in the NIST XCCDF standard.  This year we are producing compliance checks for all of our checkable recommendations in the security guide. 

 

After several discussions with Microsoft we confirmed that we should develop our  SharePoint component schema based on the SharePoint Object Model (Windows SharePoint Services 3.0). 

 

I have attached the SharePoint component schema files containing our first test (spwebappliation_test).  The spwebapplication_test is used to check the properties or permission settings of a SharePoint web application.  We are continuing to develop tests for other SharePoint security items.  If anyone has any feedback on the attached SharePoint component schema, please let me know. 

 

Thanks,

 

Linda Morrison

The MITRE Corporation

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email]. To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: SharePoint component schema

Blake Frantz

It’s my understanding that IIS 7 does not leverage an IIS 6 compatible metabase unless metabase compatibility support is installed (it’s not there by default). This will be significant while creating the MOSS 2007 tests as MOSS 2007 will install on top of IIS 6 and IIS 7.

 

http://learn.iis.net/page.aspx/125/metabase-compatibility-with-iis-7/

 

[snip]

The IIS 7.0 configuration system is compatible with legacy configuration interfaces at the API level. It supports the Admin Base Objects (ABO) interface, also known as IMSAdminBase, as well as the ADSI and WMI providers that were built on top of ABO in IIS 6.0. Existing applications and scripts can still call into those programmatic interfaces on IIS 7.0 and continue to work, as long as the Metabase Compatibility component of IIS 7.0 is installed.

Note: By default, this component is not installed.

[/snip]

 

Blake

 

From: Morrison, Linda E. [mailto:[hidden email]]
Sent: Wednesday, July 15, 2009 9:55 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] SharePoint component schema

 

Melissa,

 

Thanks for the great input.  We were actually investigating if the IIS settings that we need to check were available through other means such as the registry, WMI, or metabase.  We have found that in IIS 6 most of the IIS settings are now stored in the Metabase and  not the registry.  There is a metabase.xml file that stores these settings.  OVAL has a metabase test that we have been investigating for our SharePoint SSL recommendations.  Since we have found that we can obtain the IIS information from the metabase.xml file and OVAL has a test available, we have removed the spiissettings test from our SharePoint schema. 

 

All other tests contained within the SharePoint schema should be SharePoint specific and we have not found these to be stored in any common storage repositories.

 

Let me know if you have any other questions or concerns.

 

Thanks

 

Linda

 

From: Melissa McAvoy [mailto:[hidden email]]
Sent: Monday, July 13, 2009 3:01 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] SharePoint component schema

 

The “spiissettings” are all IIS specific settings, not SharePoint.  I believe many, if not all, can be checked directly through the registry.  If they can’t be checked through the registry or using some other existing test, then they should be in an IIS component schema as they would be used by any application using IIS, not just SharePoint. 

 

I’m not familiar with SharePoint, so I don’t know what other settings might also be found in the registry.  You (or anyone on the list who knows SharePoint internals) may want to revisit all of the suggested tests in the schema and look for overlap with existing OVAL tests. 

 

I think the only settings that should be in the SharePoint schema are the ones that are specific to SharePoint and not stored in a common storage repository.  Anything that’s stored in the registry, files, Windows Internal database, etc. should be tested via the most generic method available.  This encourages reuse of tests and makes it easier on tool developers. 

 

There may be a more fundamental discussion regarding the best way to organize tests within schemas. Should SharePoint related registry keys be listed in the SharePoint schema as new tests that extend the registry test or omitted from the SharePoint schema since they are already covered by other tests?   

 

Thanks,

Melissa Albanese

 


From: Melissa McAvoy
Sent: Tuesday, April 14, 2009 11:49 AM
To: 'OVAL Developer List (Closed Public Discussion)'
Subject: RE: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Did you look into directly querying the Windows Internal database used by SharePoint instead of creating a new schema?  (info: http://www.davidpokluda.com/Blog/post/Connecting-to-SharePoint-embedded-database.aspx)  I’m just wondering what kind of precedent we’re setting by creating application specific schemas.  Do you think the scenario with SharePoint is unique?  What kind of impact will lots of application specific schemas have on OVAL interpreters/ tool developers?  Is there some way we can make the schema more generic or apply to more than just SharePoint- some sort of schema that any application using a database can use, etc.? 

 

Thanks,

Melissa Albanese

 


From: Morrison, Linda E. [mailto:[hidden email]]
Sent: Tuesday, April 14, 2009 9:21 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Hello;

 

Last fiscal year we produced a SharePoint Sever 2007 Security Guide for our sponsor.  This guide was produced and delivered to our sponsor in the NIST XCCDF standard.  This year we are producing compliance checks for all of our checkable recommendations in the security guide. 

 

After several discussions with Microsoft we confirmed that we should develop our  SharePoint component schema based on the SharePoint Object Model (Windows SharePoint Services 3.0). 

 

I have attached the SharePoint component schema files containing our first test (spwebappliation_test).  The spwebapplication_test is used to check the properties or permission settings of a SharePoint web application.  We are continuing to develop tests for other SharePoint security items.  If anyone has any feedback on the attached SharePoint component schema, please let me know. 

 

Thanks,

 

Linda Morrison

The MITRE Corporation

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email]. To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: SharePoint component schema

Morrison, Linda E.

Blake,

 

Thank you for the input.  We are developing our OVAL tests based on SharePoint Server 2007 running on a Windows Server 2003 platform, the version of IIS for this platform is IIS 6.0. 

 

Linda

 

From: Blake Frantz [mailto:[hidden email]]
Sent: Wednesday, July 15, 2009 2:17 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] SharePoint component schema

 

It’s my understanding that IIS 7 does not leverage an IIS 6 compatible metabase unless metabase compatibility support is installed (it’s not there by default). This will be significant while creating the MOSS 2007 tests as MOSS 2007 will install on top of IIS 6 and IIS 7.

 

http://learn.iis.net/page.aspx/125/metabase-compatibility-with-iis-7/

 

[snip]

The IIS 7.0 configuration system is compatible with legacy configuration interfaces at the API level. It supports the Admin Base Objects (ABO) interface, also known as IMSAdminBase, as well as the ADSI and WMI providers that were built on top of ABO in IIS 6.0. Existing applications and scripts can still call into those programmatic interfaces on IIS 7.0 and continue to work, as long as the Metabase Compatibility component of IIS 7.0 is installed.

Note: By default, this component is not installed.

[/snip]

 

Blake

 

From: Morrison, Linda E. [mailto:[hidden email]]
Sent: Wednesday, July 15, 2009 9:55 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] SharePoint component schema

 

Melissa,

 

Thanks for the great input.  We were actually investigating if the IIS settings that we need to check were available through other means such as the registry, WMI, or metabase.  We have found that in IIS 6 most of the IIS settings are now stored in the Metabase and  not the registry.  There is a metabase.xml file that stores these settings.  OVAL has a metabase test that we have been investigating for our SharePoint SSL recommendations.  Since we have found that we can obtain the IIS information from the metabase.xml file and OVAL has a test available, we have removed the spiissettings test from our SharePoint schema. 

 

All other tests contained within the SharePoint schema should be SharePoint specific and we have not found these to be stored in any common storage repositories.

 

Let me know if you have any other questions or concerns.

 

Thanks

 

Linda

 

From: Melissa McAvoy [mailto:[hidden email]]
Sent: Monday, July 13, 2009 3:01 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] SharePoint component schema

 

The “spiissettings” are all IIS specific settings, not SharePoint.  I believe many, if not all, can be checked directly through the registry.  If they can’t be checked through the registry or using some other existing test, then they should be in an IIS component schema as they would be used by any application using IIS, not just SharePoint. 

 

I’m not familiar with SharePoint, so I don’t know what other settings might also be found in the registry.  You (or anyone on the list who knows SharePoint internals) may want to revisit all of the suggested tests in the schema and look for overlap with existing OVAL tests. 

 

I think the only settings that should be in the SharePoint schema are the ones that are specific to SharePoint and not stored in a common storage repository.  Anything that’s stored in the registry, files, Windows Internal database, etc. should be tested via the most generic method available.  This encourages reuse of tests and makes it easier on tool developers. 

 

There may be a more fundamental discussion regarding the best way to organize tests within schemas. Should SharePoint related registry keys be listed in the SharePoint schema as new tests that extend the registry test or omitted from the SharePoint schema since they are already covered by other tests?   

 

Thanks,

Melissa Albanese

 


From: Melissa McAvoy
Sent: Tuesday, April 14, 2009 11:49 AM
To: 'OVAL Developer List (Closed Public Discussion)'
Subject: RE: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Did you look into directly querying the Windows Internal database used by SharePoint instead of creating a new schema?  (info: http://www.davidpokluda.com/Blog/post/Connecting-to-SharePoint-embedded-database.aspx)  I’m just wondering what kind of precedent we’re setting by creating application specific schemas.  Do you think the scenario with SharePoint is unique?  What kind of impact will lots of application specific schemas have on OVAL interpreters/ tool developers?  Is there some way we can make the schema more generic or apply to more than just SharePoint- some sort of schema that any application using a database can use, etc.? 

 

Thanks,

Melissa Albanese

 


From: Morrison, Linda E. [mailto:[hidden email]]
Sent: Tuesday, April 14, 2009 9:21 AM
To: [hidden email]
Subject: [OVAL-DEVELOPER-LIST] First test for the SharePoint component schema

 

Hello;

 

Last fiscal year we produced a SharePoint Sever 2007 Security Guide for our sponsor.  This guide was produced and delivered to our sponsor in the NIST XCCDF standard.  This year we are producing compliance checks for all of our checkable recommendations in the security guide. 

 

After several discussions with Microsoft we confirmed that we should develop our  SharePoint component schema based on the SharePoint Object Model (Windows SharePoint Services 3.0). 

 

I have attached the SharePoint component schema files containing our first test (spwebappliation_test).  The spwebapplication_test is used to check the properties or permission settings of a SharePoint web application.  We are continuing to develop tests for other SharePoint security items.  If anyone has any feedback on the attached SharePoint component schema, please let me know. 

 

Thanks,

 

Linda Morrison

The MITRE Corporation

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email]. To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].