Web Standards Compliance

Documentation stemming from the request from web standards team

Access Management – General:

Sent 6/17. Start with access process and logging (JO, MG)

1. Access management process document, including the process for privileged users, if it is different from the process for general users..
2. Evidence of an annual recertification of continued business need completed within the previous 12 months.
3. Approval documentation with dates for the access additions or changes in the current and previous quarter.
4. List of application users (including privileged users with employee serial numbers, date of removal, and authorization notice who have been deleted within the previous and current quarter.

Access by role:

*system account access (os)* - deploy middleware, manage file system and networking configuration, conduct maintenance
*system account access (os)* managed by toronto access manager process. online request form, some number of mgmt approvals depending on what is being requested. employment validation, annual recertification. manages system access and OS level changes managed by toronto access manager process. online request form, some number of mgmt approvals depending on what is being requested. employment validation, annual recertification. manages system access and OS level changes

1. see https://idman.torolab.ibm.com/AM/ (process & docs are not within our control - managed by igs in toronto... we are users of their system)
2. would be managed by toronto processes. not sure how this is done - note to mgrs? question outstanding to Suresh Persaud
3. approvals would be managed by access mgr
4. managed by toronto

projectzero website - admin privileges for comment moderation, etc... in forums, bugzilla, ldap manages web applications and infrastructure, including some filesystem

1. managed with itcs 104 health check process (semi-annual checks)
2. included in health checks. copying one here
3. access of this nature is limited to infrastructure admin team and required development leads/mgrs. Approval process is by assignment from mgmt
4. deletions by employment status change, or mgmt directive. List of admins changed for certain apps - Yakura came on board, removed Don & Jason, etc... normal maintenance of admin authority

projectzero website - svn_editors creates and changes wiki pages and SVN repos that support Development projects

1. process is
   1. request svn_reader (avail to any zero member)
   2. obtain OSPG certification
   3. consent to Zero participation guidelines from Bob Sager
   4. Bob Sager (mgmt) sends me a note requesting access
2. Bob Sager conducts annual revalidation
3. handled in email exchanges with Bob
4. users aren't deleted - just have privileges to the group removed.

projectzero website - Developer creates and changes html files and associated web content

1. source is maintained in SVN
2. any svn_editor can change source, but can only be deployed by a Deployer

projectzero website - Deployer deploys new and changed html files to the live web site

1. currently handled by the system account access role

projectzero website - Authenticated web user

1. web user is registered and known
2. may post to blog, forum

Access Management – Quarterly Employment Verification:

Sent (MG)

1. Evidence that the previous quarterly verification was conducted, including the date of completions and the total number of verifications.

Access by role:

system account access (os) - managed by toronto access manager process. online request form, some number of mgmt approvals depending on what is being requested. employment validation, annual recertification.

1. Toronto Access Managment sends verification email every April for os privileged access

projectzero website - registered users with IBM emails

1. project zero registered users with IBM emails are compared to bluepages daily to verify evidence of employment. Violation is noted in daily email reports until email and description are changed for that userid (manually deleted or demoted to 'community' status, email changed from ibm.com). No periodic tally of successful verifications, though the daily tally shows the group size which is an indication of how many IBMers were validated each day.

Separations of Duties (SOD):

To Send. (JO, MG)

1. Application-related SOD conflict matrix or functional equivalent.
2. Associated lists and tables -- e.g. Task-to-Group and Group-to-User-- which enable one to determine for each business and IT support user which tasks they have access.
3. List of any known SOD conflicts.
4. Documentation demonstrating that the secondary controls for mitigation are being executed and working properly for any known conflicts.

Problem and Change Management:

Sent 6/17 as a combination of our wiki change request and the Bugzilla process (RB)

1. Change management process document and change records for the current and previous quarter.
   • Summary of current change management process for site artifacts of ProjectZero.org web pages
     1. change requests made through bugzilla
     2. source is stored in projectzero.org Subversion code repository for checkout, modification and local testing
     3. site source is checked in using a valid bugzilla bug
     4. only Infrastructure team members with OS access to the servers in torolab can deploy new site artifacts to the server (access validated through AM revalidation)
     5. major design changes provided by the Community/Usability team (possibly using outside experts in web design & implementation)
     • screenshot of change requests overview:
       
   • Summary of prior quarter change management process for site artifacts of ProjectZero.org web pages
     1. change requests made through wiki documents
     2. source is stored in projectzero.org wiki application database for modification and distributed testing
     3. only development team members with correct LDAP security roles to the wiki application software can edit new site artifacts (authorization roles are administered by the Infrastructure team members with OS access to the servers in Torolab providing LDAP software services for ProjectZero.org)
     4. major design changes provided by the Community/Usability team (possibly using outside experts in web design & implementation)
     • screenshot example of enhancement list in wiki:
       
     • screenshot example of open problems and changes list in wiki:
       
     • screenshot example of closed problems and changes list in wiki:
       
2. Problem management process document and problem records for the current and previous quarter.
   • Summary of current problem management process for site artifacts of ProjectZero.org web pages
     1. problem requests made through bugzilla
     2. source is stored in projectzero.org Subversion code repository for checkout, modification and local testing
     3. site source is checked in using a valid bugzilla bug
     4. only Infrastructure team members with OS access to the servers in torolab can deploy new site artifacts to the server (access validated through AM revalidation)
     • screenshot of problem requests overview:
       
     • screenshot of problem request details:
       
     • screenshot of problem request description and comments:
       
   • Summary of prior quarter problem management process for site artifacts of ProjectZero.org web pages
     1. problem request process mixed with change request process
     2. problem requests were made through wiki documents
     3. source is stored in projectzero.org wiki application database for modification and distributed testing
     4. only development team members with correct LDAP security roles to the wiki application software can edit new site artifacts (authorization roles are administered by the Infrastructure team members with OS access to the servers in Torolab providing LDAP software services for ProjectZero.org)
     5. periodically executed accessibility testing to identify breakages (complete testing process detailed in Accessibility section)

Risk Management:

Need to ask for example and repsond after I hear their initial response to these docs. (MG)

1. Open risk evaluations for the application
2. Evidence showing that secondary controls are being executed.

Accessibility:

To send summary 6/19. I can consider this satisfied for the site, with a few exceptions. Doc still has to get done (MG)

1. Completed accessibility checklist.
2. For web applications, WebKing report and Web Accessibility Standards Report. (The latter is only required for applications that do not require a user to log in)
3. Copy of the CMAD exception, if applicable.

Data Privacy:

To send after I hear back from the Geos' Privacy teams. (MG)

1. Personal Information (PI) or Sensitive Personal Information (SPI) collected by, processed by, or stored within the application.
2. Geographies of Personal Information (PI) or Sensitive Personal Information (SPI) collected, processed or stored (Japan, Canada, EMEA, etc.).
3. Completed Data Privacy Plan.
4. Evidence of approval by the Privacy Boards for each geography applicable.

Labeling of IBM Confidential Information:

1 List of all reports and screens that contain IBM confidential information

We've said in the past that we don't have any confidential information on projectzero.org. Shouldn't be any need to label anything confidential.

-- marcg - 17 Jun 2008-- marcg - 17 Jun 2008