Dentro de SharePoint Refuerzo de seguridad de SharePoint

Pav Cherny

Contenido

Dependencias de seguridad en un entorno de SharePoint
Habilitar la protección de acceso a red
Establecer el aislamiento de dominio
Aislamiento de la implementación de servidor (y Workstation)
Conclusión

Refuerzo de seguridad de SharePoint requiere un enfoque de extremo a extremo que resuelve el espectro completo de las dependencias de seguridad y los riesgos dentro y entre conjuntos de servidores. En concreto, recientes innovaciones y tecnologías disponibles de fábrica con Windows Server 2008, protección de acceso a tales como redes (NAP) con el cumplimiento de seguridad de protocolo Internet (IPsec), pueden ayudar a aumentar la seguridad de SharePoint. Aún detalladas recomendaciones de Microsoft para el refuerzo de seguridad de SharePoint en un entorno de Windows Server 2008 son difíciles de encontrar. El Windows Server 2008 Resource Center for SharePoint Products and TechnologiesNo se incluye a una guía de seguridad. Además, guías de refuerzo de seguridad para Windows SharePoint Services (WSS) 3.0y Microsoft Office SharePoint Server (MOSS) 2007todavía se basan en Microsoft patterns and practices se fechan junio de 2003 que se han actualizado parcialmente en enero de 2006, que era todavía más largo antes del lanzamiento de Windows Server 2008 y de Internet Information Services (IIS) 7.0, en cualquier caso.

Claramente, directrices revisadas están muy vencidas y no sólo porque tenemos largo desde mover desde Windows 2000, SQL Server 2000, IIS 5.0 y Microsoft .NET Framework 1.1, sino también porque las antiguas formas de trabajar con protección de seguridad han demostrado suficientes tiempo y vuelva a. Es simplemente no suficiente proteger un conjunto de servidores de SharePoint como una isla de servidor aislada, como si existan granjas de SharePoint en un vacío. La realidad es que no una sola seguridad hardening paso en una conjunto de servidores importa si el bosque de Active Directory es inseguro si el entorno de intranet se infested con spyware y rootkits o si los usuarios accidentalmente o maliciosamente infringen las directivas de seguridad, por ejemplo, descargar e instalar software de uso compartido de archivos de orígenes cuestionables de SharePoint.

Es posible abordar estos problemas mediante la tecnología de Windows Server 2008. Es la clave para lograr un alto nivel de seguridad en un entorno de SharePoint, extremo a extremo, desde los equipos cliente copia hasta los servidores de base de datos.

En este artículo, trataré aspectos de seguridad de SharePoint en un entorno de intranet basado en Windows Server 2008. Esta discusión implica analizar generales las dependencias de seguridad de SharePoint más allá de los límites de un conjunto de servidores individual y a continuación, implementar NAP con el cumplimiento de IPsec con correspondientes reglas de aislamiento y seguridad para mitigar los riesgos. Para los administradores de SharePoint, una ventaja evidente de NAP es que puede dejar de equipos cliente no administrado desde tener acceso a recursos de SharePoint y descargar documentos. Otro, quizás menos obvia, ventaja es que puede dividir la intranet en redes lógicas independientes a través de aislamiento de dominio y servidor. De esta forma, puede proteger la comunicación cliente a servidor y de servidor a servidor entrante y saliente y también limitar el tráfico a servidores que desee. Suponiendo que hasta 30 por ciento de sitios de SharePoint de una organización residen en conjuntos departamentales rogue, inadequately protegidos y fuera de control del departamento de TI, las ventajas de restringir el tráfico de cliente se no se pueden exagerar. Como siempre, el material complementario incluye hojas de cálculo con instrucciones paso a paso por seguir mis explicaciones en un entorno de prueba.

Dependencias de seguridad en un entorno de SharePoint

Teniendo en cuenta la complejidad de soluciones basadas en SharePoint, el enorme volumen de datos almacenados en sitios de SharePoint y la seguridad a menudo contradictorias y requisitos de productividad de una empresa puede ser difícil determinar cómo y dónde empezar con la consolidación de seguridad de SharePoint. Quizás el primer paso es retirar la noción de mantenidos largo que nuestro intranets son entornos descriptivos, suficientemente protegidos mediante firewalls de perímetro y detectores de virus. Escáneres y los servidores de seguridad no se bloquean un usuario malintencionado de adjuntar un keylogger hardware PS2 o USB a un equipo cliente, no hay controladores requeridos. También no mantienen un rootkit de día cero de activar los equipos móviles en zombis mientras están conectados a un entorno inadequately protegido en el hogar, en hoteles o aeropuertos o en sitios de clientes. Puede parecer sea dura, pero clasificar el entorno interno como hostil ayudará en términos de reconocer las dependencias de seguridad críticas dentro y entre conjuntos de servidores de SharePoint.

Veamos qué problemas críticos que se pueden descubrir en un laboratorio de pruebas sencillo, como lo muestra en la figura 1 y descritos en la hoja de cálculo complementario "Implementación de un entorno de prueba con SharePoint varios conjuntos de servidores y un servidor de directivas de red". Este entorno de SharePoint no es seguro. De hecho, mi hoja de cálculo de implementación infringe varias prácticas recomendadas de seguridad y omite las dependencias importantes. Normalmente aparece inmediatamente con él, suponiendo que no estén requisitos de seguridad en los laboratorios de pruebas. Por supuesto, podría tener permisos administrativos de cuentas de peor realizado mediante la instalación de SharePoint en un controlador de dominio o conceder seguridad, pero estos errores de configuración intencionado no son necesarios. Desde una perspectiva de seguridad, mi entorno de prueba ya es suficientemente incorrecto.

Figura 1 un entorno de prueba no seguros con SharePoint varios conjuntos de servidores

Para empezar, uso la cuenta de administrador de dominio para iniciar sesión en todos los servidores y estaciones de trabajo y instalar todos los sistemas mientras estuvieran conectados a Internet. Es arriesgado. Es mejor evitar iniciar sesión en un equipo no segura con una cuenta de administrador de dominio. Asimismo, es una práctica recomendada equipos en un entorno de ensayo separado, seguro prior to implementación de revisiones e instalar. Kit de instalación automatizada de Windows (AIK) y servicios de implementación de Windows (WDS) ofrecen una buena solución, no seguir sacando provecho de estas tecnologías en mi laboratorio de pruebas por motivos de complejidad. Porque tardó accesos directos, ya podría verse comprometida mi entorno de Active Directory y con él Mis granjas de SharePoint. El juego es a través antes de iniciarlo incluso! Un conjunto de servidores de SharePoint nunca puede ser más seguro que su entorno de Active Directory.

Las cuentas de administrador de dominio son muy sensibles cuentas realmente. Está también en un área confidencial cuando tiene acceso a recursos de SharePoint, tales como el sitio de SharePoint 3.0 Central Administration y colecciones de sitios de SharePoint. Acceso a un sitio SharePoint implica ejecutar el código ASP.NET bajo la identidad del usuario actual en el servidor de solicitudes de cliente. Si ese usuario actual resulta ser un administrador de dominio, el código se ejecuta con privilegios administrativos. Debe denegar los administradores de dominio y acceso de los administradores de servidor local a las aplicaciones Web de SharePoint porque es posible aprovechar sus privilegios elevados, tales como que extraer las cuentas de seguridad y las contraseñas, como se explica en la columna de enero de 2009. Si un atacante puede engañar a un administrador de SharePoint en implementar un componente malintencionado o habilitar código ASP.NET en línea, el atacante también podría ser capaz de determinar las contraseñas de cuenta de seguridad y posteriormente tener acceso a todos los sitios en todos los conjuntos de servidores que utilizan esas cuentas.

En mi laboratorio de pruebas, omite estas dependencias de la cuenta de seguridad y administrativos de los riesgos, configura el conjunto WSS y el conjunto de recursos humanos con las mismas cuentas de seguridad y utiliza la cuenta de administrador de dominio para trabajar con SharePoint 3.0 Central Administration en ambos conjuntos. Compartir cuentas de seguridad entre conjuntos de servidores es una mala idea, en especial si tienen distintos requisitos de seguridad. Un conjunto que comparte sus cuentas depende el conjunto de otro para la seguridad y, por lo tanto, nunca puede alcanzar un nivel de seguridad superior que el conjunto de servidores.

Utilizar cuentas de seguridad independiente es una práctica recomendada importante, pero un conjunto comprometido aún puede proporcionar una vía para ataques en otros conjuntos de servidores en el mismo entorno de Active Directory. Por ejemplo, no tardar mucho esfuerzo para activar un servidor de SharePoint en peligro en una plataforma de suplantación de identidad interna. Un atacante podría habilitar la autenticación básica o obtener un componente malintencionado en un conjunto establecido de SharePoint que envía un encabezado "WWW-Authenticate" a los usuarios y intercepta las credenciales devueltas en texto sin formato, como se muestra en la figura 2 . Ya que los usuarios confían en sus sitios de SharePoint internos, es probable que se entran las credenciales sin vacilación solicitadas, y el ataque se realiza correctamente.

Figura 2 un conjunto de servidores en peligro de SharePoint puede habilitar ataques en otros conjuntos de servidores.

Por supuesto, es difícil poner en peligro un servidor de SharePoint mantiene correctamente, pero no eso el punto. El punto impide la propagación a sistemas confidenciales con seguridad de nivel superior de infracciones de seguridad en sistemas que no mantienen correctamente. Por lo tanto, al menos para los recursos más importantes de SharePoint, como un conjunto de recursos humanos con información que le identifique personalmente, debe considerar estas dependencias de acceso, que implican básicamente que un conjunto de servidores de SharePoint puede ser sólo tan segura como los sitios menos seguras que los administradores del conjunto, administradores de colección de sitios y los usuarios del sitio pueden tener acceso con sus cuentas de usuario.

No olvide incluir los equipos cliente en el análisis de dependencias de acceso y uso. De nuevo, mi entorno de prueba establece un mal ejemplo porque cualquier usuario puede utilizar cualquier estación de trabajo para tener acceso a cualquier recurso, y los equipos no están equipados con detectores de virus o las revisiones de seguridad más recientes. Imagine un usuario con los derechos de un administrador de conjunto de servidores o colección de sitios sesión localmente a un equipo cliente infested spyware o a un equipo en una oficina desbloqueada, donde un atacante puede asociar fácilmente un keylogger de hardware. Matrices y colecciones de sitios están en peligro tan pronto como el atacante obtiene acceso a una cuenta de administrador y una contraseña en cualquier equipo en cualquier ubicación. Software de uso compartido de archivos en equipos cliente también plantea riesgos de seguridad, como los equipos cliente tienden a almacenar el contenido de sitios de SharePoint localmente, manual o automáticamente descargando esa información en archivos temporales. Por lo tanto, un conjunto de servidores de SharePoint nunca puede ser más seguro que los equipos cliente que los usuarios utilizan para tener acceso a recursos del conjunto.

Por supuesto, aún más existen puntos débiles en mi entorno de prueba. Invito para estudiar las secciones relevantes de las guías de refuerzo de seguridad de SharePoint y continuar esta revisión en su propio. Debe reconocer al menos un puñado de problemas adicionales, como que los sitios de SharePoint 3.0 Central Administration y funciones de búsqueda se alojan directamente en servidores que el contenido del sitio, que hay de ninguna solución antivirus en los servidores de servicio, que el conjunto WSS y el conjunto de recursos humanos compartan un servidor de base de datos comunes y no protegido, que todos los equipos en el entorno de prueba tienen acceso directo al servidor de base de datos y que la comunicación de red tiene lugar en texto sin formato. Ninguno de esto es conveniente, por lo que vamos a tratar algunos de estos problemas de seguridad.

Habilitar la protección de acceso a red

Hay muchas medidas para aumentar la seguridad en un entorno de SharePoint, como controlar el acceso físico a equipos y listas de la red, configurar vLANs y control de acceso (ACL) en enrutadores y servidores de infraestructura con seguridad (servidores DNS, servidores DHCP, los controladores de dominio etc.) a través de la implementación de Microsoft Forefront Security para SharePoint y Active Directory Rights Management Services (RMS de Active Directory). Acceso físico controles y las configuraciones de red y el enrutador de TCP/IP básicas más allá del alcance de esta columna y AD RMS se ha tratado en columnas anteriores, por lo nos deja con NAP, IPsec, HTTP sobre Secure Sockets Layer (SSL) y Forefront como los siguiente temas lógicos. Esta columna se centra en NAP y IPsec. HTTP sobre SSL y Forefront Security se abordará en futuras columnas.

NAP con IPsec ofrece al menos tres ventajas claves para un entorno interno de SharePoint:

• Puede aplicar directivas de estado del sistema y automáticamente solucionar problemas de cumplimiento en equipos de cliente que ejecutan Windows XP Service Pack 3 y Windows Vista;
• Puede implementar una capa adicional de seguridad de red a través de IPsec y Firewall de Windows en un bosque de Active Directory completo;
• Puede establecer canales de comunicación cifrados a través de la carga de seguridad encapsuladora (ESP) dentro de un conjunto de servidores de SharePoint y entre servidores y equipos cliente.

Una bonificación es la capacidad de administrar la comunicación de red centralmente mediante Directiva de grupo y auditar el acceso a la red. En resumen, NAP con IPsec es un importante Habilitador de una estrategia de seguridad efectiva de extremo a extremo para SharePoint.

En el núcleo, NAP con IPsec se basa en un mecanismo de distribución inteligente para los certificados x.509. En el equipo cliente, los agentes de estado del sistema (SHA) informar el Agente NAP su estado de cumplimiento mediante documentos de instrucción de mantenimiento (SoH), que el Agente NAP se consolida en una instrucción de sistema de mantenimiento (SSoH). Pasa el SSoH el cliente de cumplimiento NAP de IPsec (EC NAP) en el equipo cliente, que a su vez pasa la SSoH al servidor de cumplimiento NAP (NAP ES). Se trata de la autoridad de registro de mantenimiento (HRA) que obtiene certificados de mantenimiento del sistema de una entidad emisora de certificados (CA) para equipos compatibles con. la figura 3 ilustra cómo un cliente NAP Obtiene un certificado de mantenimiento.

Figura 3 comunicación cliente-servidor NAP para intercambiar información de estado y certificados

Para determinar que es compatible con el equipo solicitante, el ES NAP pasa el SSoH en un mensaje RADIUS para el servidor directivas de redes (NPS). El NPS pasa de nuevo el SSoH al servidor de administración de NAP, que extrae el SoHs individuales el SSoH y reenvía los validadores de estado del sistema (SHV) correspondiente a su vez. Los SHV analizan la información de SoH y devuelven una respuesta de instrucción de estado (SoHR), que consolida el NPS en una respuesta de-instrucción-de-estado del sistema (SSoHR) que el sistema NAP, a continuación, pasa a la SHA en el equipo cliente. Mediante el SoH y SoHRs, SHV comunicarse con sus homólogos SHA correspondientes. Por ejemplo, SoHR desde un SHV antivirus puede indicar el correspondiente SHA antivirus para descargar la versión más reciente del archivo de firma desde un servidor de corrección para devolver el equipo cliente de cumplimiento.

En el servidor, NAP también compara SoHRs las directivas de red y el estado configurado y emite un certificado de mantenimiento del sistema si el equipo cliente es compatible con. El cliente de NAP recibe el certificado de la ES de NAP y lo almacena en su almacén de certificados de equipo. El certificado está ahora disponible para negociación de intercambio de claves de Internet (IKE) establecer asociaciones de seguridad IPsec con asociados de comunicaciones de confianza. El cliente de NAP renueva el certificado de mantenimiento del sistema siempre que va a caducar o cuando un SHA indica un cambio de estado de mantenimiento en el Agente NAP. La conclusión es que los equipos compatibles con reciben un certificado de mantenimiento y no de los equipos no compatibles. Para detalles técnicos profundos, recomiendo las notas del producto" Arquitectura de la plataforma de protección de acceso a la red." La hoja de cálculo complementario "Configuración de protección de acceso de redes" describe los pasos para implementar una infraestructura básica de NAP en un laboratorio de pruebas.

Establecer el aislamiento de dominio

Incluso en mi laboratorio de pruebas poco humilde con funciones NPS y HRA en un único servidor, puede inmediatamente observa las ventajas de NAP. Tan pronto como habilita NAP en los equipos cliente a través de la configuración de la directiva de grupo, NAP aconseja encarecidamente para instalar las revisiones de seguridad más recientes y un detector de virus. El cliente de NAP le informa que faltan componentes de seguridad y el estado de la red incluye una notificación informándole de que el acceso a la red puede estar limitado hasta que el equipo cumpla con los requisitos de mantenimiento. En este momento, sin embargo, no compatibles equipos aún tienen acceso a todos los servidores en la red porque se aún no han configurado las directivas IPsec. Sin directivas de IPsec que solicitan o requerir la autenticación para conexiones entrantes y salientes, la infraestructura NAP realmente no es mucho más que un mecanismo de distribución de certificado de mantenimiento. Es necesario implementar el aislamiento de dominio para NAP para que sea eficaz.

Implementación de aislamiento de dominio significa dividir la red interna en segmentos de restringido, límite y redes seguras a través de directivas de cumplimiento de IPsec. El objetivo es impedir que equipos no compatibles tengan acceso a los servidores de la red interna, con la excepción de los servidores que los equipos no compatibles deben poder tener acceso a ser compatible con y obtener un certificado de mantenimiento. En la figura 4 , esto está relacionada con el servidor NAP NPS01. La diferencia entre el segmento de límite y el segmento seguro es que la directiva IPsec para el segmento de límite de solicitudes de autenticación para conexiones entrantes y salientes y, por lo tanto, permite el retroceso a texto sin cifrar la comunicación con equipos no compatibles, mientras que el segmento seguro requiere autenticación para las conexiones entrantes, que prohíbe el retroceso a texto sin formato y bloquea los equipos no compatibles. Puede utilizar la hoja de cálculo complementario "Configurar directivas de estado cumplimiento de IPsec" para implementar esta segmentación.

Figura 4 restringido, límite y redes seguras para NAPNAP

El controlador de dominio en la figura 4 es un caso especial. Puede solicitar o requerir la comunicación protegida por IPsec entre los miembros del dominio y controladores de dominio si los equipos que ejecutan Windows Vista o Windows Server 2008 (consulte la hoja de cálculo complementario "Configurar IPSec para dominio controlador comunicación"), pero esta configuración no es compatible con Windows Server 2003 y Windows XP. Si decide no utilizar IPsec para comunicación del controlador de dominio, DC01 formará parte de la red restringido; solicitar que IPSec mueve el controlador de dominio en el segmento de límite y que requieren que IPSec hace el controlador de dominio un miembro del segmento seguro. La configuración depende de su situación específica y sus necesidades. Si es posible, recomiendo utilizar IPsec.

Aislamiento de la implementación de servidor (y Workstation)

Establecer NAP con aislamiento de cumplimiento y dominio IPsec actúa como el primer hito importante hacia el refuerzo de seguridad. Todos los equipos cliente ahora deben cumplir los requisitos de estado razonable poder puede tener acceso a los recursos de SharePoint internos. A continuación, puede centrarse en el entorno de SharePoint en varios niveles para lograr un nivel fino de control de comunicación de extremo a extremo, incluida la comunicación de equipos cliente de segmentación. la figura 5 muestra una estrategia de segmentación posible según la función de cada equipo individual en la red interna.

Figura 5 un entorno de pruebas mejorada con múltiples conjuntos de servidores de SharePoint

Como podrá observar en la figura 5 , mi entorno de pruebas incluye ahora sistemas adicionales. Entre otras cosas, cambió la configuración de los conjuntos de WSS y HR había especificado cuentas de seguridad independiente, mueven la configuración de recursos humanos y bases de datos de contenido a un servidor independiente de SQL y implementan equipos independientes para la administración central de SharePoint 3.0 y la función búsqueda de SharePoint en ambos conjuntos. Desproteger las hojas distintas en el material complementario, que ilustran cómo realizar estos pasos.

Proteger la comunicación entre los niveles es ahora un proceso sencillo, gracias a nuestro NAP con el trabajo de preparación de IPsec. A través de la directiva de grupo, puede administrar centralmente todas las reglas de Firewall de Windows con seguridad avanzada para bloquear la comunicación entrante y saliente en los clientes y servidores para los niveles más restrictivos. Se recomienda deshabilitar la regla de combinación en directiva de grupo para impedir que los administradores locales apliquen firewall en conflicto y las reglas de seguridad de conexión en cualquier miembro del dominio. Por ejemplo, puede bloquear UDP y TCP puerto 1434 en los servidores de base de datos, abrir un puerto TCP personalizado para la instancia predeterminada de SQL Server, cifrar el tráfico, abrir sólo los puertos TCP que las aplicaciones Web se utilizan en los servidores de solicitudes de cliente y bloquear HR no todos los equipos tengan acceso a cualquier servidor o equipo cliente en el departamento de RRHH.

REFERENCIAS

	Sitio Web de protección de acceso de red go.Microsoft.com/fwlink/?LinkId=69752
	Sitio Web de tecnologías y productos de SharePoint Microsoft.com/SharePoint
	Windows SharePoint Services TechCenter TechNet.Microsoft.com/windowsserver/SharePoint
	Centro de desarrollo de Windows SharePoint Services msdn2.Microsoft.com/SharePoint
	Blog del equipo de tecnologías de productos de Microsoft SharePoint y blogs.msdn.com/SharePoint

Una pregunta interesante es si también debe bloquear equipos importantes obtengan acceso a los equipos no confidenciales, por ejemplo, se deben mantener HR clientes tengan acceso a servidores de RRHH SharePoint del conjunto WSS. Es un ejemplo donde entran en conflicto los requisitos de seguridad y productividad. Por motivos de productividad, Creo que es imposible rechazar a HR personas acceso a sitios de SharePoint de toda la compañía como sitios en mi conjunto de WSS, que implica que el conjunto WSS debe ajustarse a los mismos estándares de seguridad como el conjunto de recursos humanos. Por lo tanto, en ambos conjuntos, tuve que mover los sitios de SharePoint 3.0 Central Administration, buscar funciones para un equipo independiente y aplicar reglas de seguridad de servidor de seguridad y conexión. Por supuesto, también debe designar cuentas dedicados, sin privilegios para administración de SharePoint en ambos conjuntos y aplicar más pasos de refuerzo de seguridad. Joel Oleson ha publicado una gran lista resumida de los pasos de refuerzo de seguridad en su Blog de suelo de SharePoint. Recomiendo encarecidamente consejos de Joel siguiente en una infraestructura habilitada con IPsec que proporciona una base sólida para el refuerzo de seguridad de SharePoint de extremo a extremo.

Conclusión

Conjuntos de servidores de SharePoint no existen en un vacío. Existen en un entorno que incluye los equipos cliente, servidores de infraestructura y equipamiento de red. Esto significa que obligada a estos componentes si desea conseguir una mejor seguridad a través de SharePoint proteger-refuerzo. Es imposible proteger una granja de SharePoint en un entorno de Active Directory no seguro. Es imposible proteger un conjunto de servidores de SharePoint si los equipos cliente son infested con spyware. Es imposible proteger un conjunto de servidores de SharePoint si un atacante puede highjack cuentas de usuario, cuentas de administrador o cuentas de seguridad en cualquier lugar.

Tecnología de Windows Server 2008 proporciona la base para convertir una amplia seguridad neto a través de un bosque de Active Directory a través de protección de acceso de red con el cumplimiento de seguridad de protocolo Internet, Firewall de Windows con seguridad avanzada y administración de directiva de grupo. Sacar provecho de estas tecnologías en un entorno de SharePoint es definitivamente merece la pena el esfuerzo. Puede controlar y proteger la comunicación entre las estaciones de trabajo, servidores y controladores de dominio; puede aplicar los estándares de estado del sistema; puede implementar el aislamiento de dominio; y puede exigir niveles independientes en el entorno interno de SharePoint. Mediante la pertenencia a grupos de seguridad o unidades organizativas, Active Directory determina automáticamente la configuración de directiva que se aplican a cada miembro de dominio, incluidos los equipos cliente, servidores de base de datos, servidores y servidores de nivel medio para la administración y otros propósitos. Puede establecer directivas generales para cada nivel y directivas específicas para cada función de tipo y el servidor de equipo. Puede impedir que los usuarios que aloja SharePoint en los equipos cliente bloqueando todas las conexiones entrantes, y puede impedir que los departamentos de alojamiento de conjuntos de SharePoint no aprobadas y no seguros podrían proporcionar vías para ataques en otros conjuntos de servidores de la red interna.

Pero no ir overboard con restricciones. Tenga en cuenta que muchos procesos de negocio departamentales dependen de las implementaciones de SharePoint fuera de centro de datos. Después de todo, SharePoint es una plataforma de colaboración empresarial importante de la empresa.

Pav Cherny es un experto de TI y autor especializado en tecnologías de Microsoft para la colaboración y comunicaciones unificadas. Sus publicaciones incluyen notas del producto, manuales de producto y libros con un enfoque en las operaciones y administración del sistema. Pav es presidente de Biblioso Corporation, una empresa especializada en servicios de documentación y localización administrados.