Incubator Status

Link to Jira: 

OFJ-1590

Functional Specification

Overview

Agencies are required by OMB to track Plans of Actions & Milestones (POA&Ms) and OpenFISMA does not explicitly support the POA&M concept.

The lack of POA&Ms affects agencies' ability to comply with OMB regulations and/or guidance. It may create extra work because agencies may need to separately prepare a POA&M report for certain compliance purposes.

This is not a huge roadblock for existing OpenFISMA instances (since, presumably, those users have learned to adjust to the OpenFISMA model), but it is a big obstacle for government agencies to deploy a new instance of OpenFISMA.

Related Requirements (Regulations, Guidelines, etc.)

OMB released memorandum 02-01 explaining the content and structure of an information system security POA&M.

Models

A poam is a list of milestones (or tasks). Each task has the following properties:

• Description
• Point Of Contact (optional)
• Due Date
• Cost (in $, nullable)
• Status: Complete or Not Complete

Each task is related to exactly one finding. Each finding has 0-n tasks associated with it. Notice that Finding and POAM are very similar. Literally speaking, a Finding is what the auditor submits to the agency to document a material weakness, while a POAM is the agency's plan to resolve a Finding. For now, we are not going to change the Finding terminology used throughout OpenFISMA, but the possibility of renaming it to "POAM" is possible.

In addition to defining this new Milestone model, we also plan to modify the existing Finding model, dropping the following attributes:

• Expected Completion Date (supplanted by Tasks's Due Date)
• Mitigation Strategy (supplanted by Task's Description)
• Resources Required (supplanted by Task's Cost)

Behavior

When a Finding is in NEW or DRAFT status, the task list can be modified by adding, removing, or editing milestones. In any other status, milestones cannot be added, removed, or edited.

In any state, each milestone has a "Complete" button. This button can only be clicked by the Milestone's POC or the Finding's POC. 

The finding still has a logical property called "Expected Completion Date". This field is calculated as the maximum of the subtask due dates.

The finding also has a logical property called "Next Action Due Date". When in EN status, the next action due is the minimum of the subtask due dates.

When searching, there is a new column called "Tasks" that is simply a concatenation of all of the task descriptions.

A finding cannot be submitted for "POA&M Approval" until it has at least 1 milestone.

Migration

Each legacy finding will be converted into a finding with a single milestone, mapped as follows:

• Milestone Description = Finding's Mitigation Strategy
• Milestone Assignee = Finding's POC
• Milestone Due Date = Finding's ECD
• Milestone Cost = NULL

Presentation

We are making a few changes to the presentation layer, as well as adding the milestones UI.

Remove "Mitigation Strategy" tab. The UI components here will be relocated or removed altogether.

New layout for the finding's first tab.

1. Remove the Finding ID field. (It's displayed in the tab already.)
2. Move the current "details" box to float right and put the "Description" back to left justification (not floated) so that the the description and recommendation text will flow around the details box.
3. Split the details box into three boxes:
   1. Details
      1. Keep existing fields here unless they belong in one of the other two boxes.
   2. People
      1. Put all the people fields from the details box into "People"
   3. Dates
      1. Put all of the date fields from the details box into "Dates"
4. Underneath the recommendation, put the Milestones UI.

Here is a mockup of the layout for finding tab.

Gliffy Zoom

By default, the milestones are displayed in a table that is sortable but NOT editable. If the user clicks the "Edit" pencil, the milestones area becomes editable, as shown in the following screen:

Gliffy Zoom

Privileges

We will create three new privileges: finding.edit_milestones (this one allows create/edit/delete of milestones) and finding.complete_milestones (this one allows clicking the complete button only).

A POC for the finding will automatically have the ability to complete all milestones. The POC for any particular milestone will also have the ability to complete that particular milestone.

Notifications

We will add 2 new notification events: finding milestones being modified (added/edited/deleted are all part of 1 event) and finding milestones being completed).

We also send an instant email notifications (which users can't unsubscribe from) to POC's and assignees once a finding or milestone is assigned to them.

Miscellaneous

James has requested the sample data for findings should not generate such long paragraphs. Paragraphs should be about 1/3 of the current size. This is logically irrelevant, but as long as it does not interfere with the rest of the feature, it can be slipped in here.

Technical Specification

Data Models

The data models for POAM are quite straightforward. There will be a new Milestone table that is associated with Finding. I don't think this is complicated enough to deserve a deep technical exposition.

Editable YUI Table

The usability of this feature is going to depend heavily on an efficient user interface for modifying milestones.

To accomplish this, I am going to use a YUI table with editable fields. In "view" mode, these editable fields will not be displayed. But in "edit" mode (i.e. after clicking the edit pencil), these fields will become editable.

Changes to milestones made in this user interface will be stored in memory; these changes will not be persisted until the user clicks the save button.

It seems that YUI makes this style of inline editing relatively simple to accomplish: http://developer.yahoo.com/yui/examples/datatable/dt_cellediting.html. The example they show may not be exactly what we want to do, but it's a very close starting point.

Access Control

Access control is definitely the biggest doozy in this improvement. One of the unstated assumptions in the functional specification is that a POC should be able to view a finding simply because he/she is the POC. Our legacy model of access control (based on the role and privilege tables, and optionally on organization ids) conflicts with this assumption. As addressed and explained in OFJ-1642 Enable POCs to see their own findings, the handling for this problem is complicated and would take a lot of effort (i.e. time and money).

However, to get this feature introduced as early as possible, there must be a compromise. The current ACL will be tweaked to allow POC's and assignees to view and complete the findings and milestones they're assigned to. However, these findings may not appear in their search results, dash board, and everywhere else. The only guaranteed way to access these findings is via a direct link (which should be emailed to them as long as a finding or milestone is assigned to them).