# Presentation: 001891

## FISMA 2005: Departmental Best Practice Approaches

**Lisa Schlosser**
**Chief Information Officer**
**US Housing and Urban Development**
**Patrick D. Howard**
**Chief Information Security Officer**
**August 2005**

## Currently with HUD...

- ...But in the process of adopting DOT – DOJ – EPA Best Practices for FISMA Compliance.  Why?

## How DOT and Other Agencies Met with Success

**FY02**

- “F”

- “A-”

- “D+”

**FY03**

**FY04**

_**Focus:**_
- Strategy/Policy
- Executive Support
- IG Coordination

_**Focus:**_
- C&A Execution
- TCIRC Fine-Tuning
- Testing

- 3-Year Strategy
- Secretary Support/PMA Metrics
- C&A/Inventory Methodology
- TCIRC Creation

- PMA Metrics
- Execution of C&A
- Training
- Enterprise Testing
- Collaboration

- Major

- Milestones

- Major

- Milestones

## Two Critical Lessons

*Every Discussion about Security Should Start with the Business...*

*...**Technology is Easy to Change.  People are hard to Change.*

## One Agency Perspective:  U.S. Department of Transportation FY 2002 FISMA IT Security Scorecard:  How it All Began...

**“****F”**

## Reasons for a “Failing Grade”

**Lack of Consistent Systems Inventory**
**Lack of Certified & Accredited Systems**
**Lack of Baseline Configuration Standards**
**Lack of Reporting Standards**
**Lack of Tools to Track Progress/Compliance – and to collaborate on enterprise-wide solutions**

**Notes:**
Analysis revealed several reasons for the failing grade:

Systems inventory – No clear definition of what a system consists of; how to determine system boundaries; what is mission critical; or major versus non-major

Small percentage of C&A’d systems FY02 8% (Just mission critical)
No baseline configuration standards to build to.
No standard reporting guidelines.  Information was not reported correctly to OMB
No consistent method to track progress or compliance.

## Key Corrective Actions Needed

**Develop an accurate comprehensive inventory of *****ALL***** IT Systems**
**Certify and Accredit *****ALL *****IT Systems**
**Develop Standard Baseline Configurations**
**Improve Incident Reporting Process**
**Develop and Implement automated Tools to measure and monitor the IT Security Program – and to provide a collaboration forum**

**Notes:**
Developed System Inventory Guide which defined what a system is; how to determine boundaries; how to determine criticality; sensitivity; what does major and non-major mean (essentially, report all).
Developed baseline configuration standards for commonly used operating systems/applications.
Mandated certification of 50% of mission critical systems by 9/30/03. Exceeded goal by 18%.  Used team of contractors to accomplish goal.  Plan for remaining systems – certify and accredit 90% of all systems by July 1, 2004.
Researched feasibility of designing and developing automated tools to assist in measuring, tracking and reporting progress. 

## Implementation of Key Corrective Actions

**Develop an accurate comprehensive inventory of *****ALL***** DOT IT Systems**
**Established System Inventory Guidelines and Classification Methodology – Based on OMB Guidance**
**Purchased SMS technology and used vulnerability scanning tool for discovery of assets**
**Documented inventory in an integrated enterprise security portal product**
**Developed Matrix for Tracking Inventory Reduction**
**Enforce Through:**
**Engagement of Acquisition Community to enforce standards**
**Robust Enterprise Architecture – Technical Reference Model (TRM)**
**Capital Planning and Investment Control Program**
**Results:  IG verified Inventory in FY03 and FY04**

**Notes:**
Developed System Inventory Guide which defined what a system is; how to determine boundaries; how to determine criticality; sensitivity; what does major and non-major mean (essentially, report all).
Developed baseline configuration standards for commonly used operating systems/applications.
Mandated certification of 50% of mission critical systems by 9/30/03. Exceeded goal by 18%.  Used team of contractors to accomplish goal.  Plan for remaining systems – certify and accredit 90% of all systems by July 1, 2004.
Researched feasibility of designing and developing automated tools to assist in measuring, tracking and reporting progress. 

## Certify and Accredit ALL DOT IT Systems
Secretarial commitment and metrics tracking
Established Inventory
Established DOT standard methodology and templates
Implemented centralized team for Level 1 and 2 Systems
Specialized teams for Level 3 Systems
Established POA&M tracking system
Results:  IG certified that DOT completed 96.5% by June 30, 2004 in a satisfactory manner...but noted that the POA&M process requires significant upkeep

**Secretarial commitment and metrics tracking**
**Established Inventory**
**Established DOT standard methodology and templates**
**Implemented centralized team for Level 1 and 2 Systems**
**Specialized teams for Level 3 Systems**
**Established POA&M tracking system**
**Results:  IG certified that DOT completed 96.5% by June 30, 2004 in a satisfactory manner...but noted that the POA&M process requires significant upkeep**

- Implementation of Key Corrective Actions

**Notes:**
Developed System Inventory Guide which defined what a system is; how to determine boundaries; how to determine criticality; sensitivity; what does major and non-major mean (essentially, report all).
Developed baseline configuration standards for commonly used operating systems/applications.
Mandated certification of 50% of mission critical systems by 9/30/03. Exceeded goal by 18%.  Used team of contractors to accomplish goal.  Plan for remaining systems – certify and accredit 90% of all systems by July 1, 2004.
Researched feasibility of designing and developing automated tools to assist in measuring, tracking and reporting progress. 

## Develop Standard Baseline Configurations
Analyzed Inventory
Established 7 Key Standard Baselines 
Used CSI Where Possible
Established Implementation Guidelines

**Analyzed Inventory**
**Established 7 Key Standard Baselines **
**Used CSI Where Possible**
**Established Implementation Guidelines**

- Implementation of Key Corrective Actions

**Notes:**
Developed System Inventory Guide which defined what a system is; how to determine boundaries; how to determine criticality; sensitivity; what does major and non-major mean (essentially, report all).
Developed baseline configuration standards for commonly used operating systems/applications.
Mandated certification of 50% of mission critical systems by 9/30/03. Exceeded goal by 18%.  Used team of contractors to accomplish goal.  Plan for remaining systems – certify and accredit 90% of all systems by July 1, 2004.
Researched feasibility of designing and developing automated tools to assist in measuring, tracking and reporting progress. 

## Improve Incident Reporting Process
Established 24X7 Transportation Cyber Incident Response Center
Monitor all DOT Networks
Test all External and Internal Sites
Regular vulnerability scanning
Periodic web application scanning
Quarterly privacy compliance testing
Annual system accessibility compliance testing
MOU with OIG for Forensics Support
Participate with DHS in Pilot Programs
Results:  No Incident Reporting Findings in FY04

**Established 24X7 Transportation Cyber Incident Response Center**
**Monitor all DOT Networks**
**Test all External and Internal Sites**
**Regular vulnerability scanning**
**Periodic web application scanning**
**Quarterly privacy compliance testing**
**Annual system accessibility compliance testing**
**MOU with OIG for Forensics Support**
**Participate with DHS in Pilot Programs**
**Results:  No Incident Reporting Findings in FY04**

- Implementation of Key Corrective Actions

**Notes:**
Developed System Inventory Guide which defined what a system is; how to determine boundaries; how to determine criticality; sensitivity; what does major and non-major mean (essentially, report all).
Developed baseline configuration standards for commonly used operating systems/applications.
Mandated certification of 50% of mission critical systems by 9/30/03. Exceeded goal by 18%.  Used team of contractors to accomplish goal.  Plan for remaining systems – certify and accredit 90% of all systems by July 1, 2004.
Researched feasibility of designing and developing automated tools to assist in measuring, tracking and reporting progress. 

## Develop and Implement automated Tools to measure and monitor the IT Security Program
Established Portal
Established Tools
Analyzed Enterprise-wide solutions
Results:  Phase 1 Implemented – Continuing Improvements being made

**Established Portal**
**Established Tools**
**Analyzed Enterprise-wide solutions**
**Results:  Phase 1 Implemented – Continuing Improvements being made**

- Implementation of Key Corrective Actions

**Notes:**
Developed System Inventory Guide which defined what a system is; how to determine boundaries; how to determine criticality; sensitivity; what does major and non-major mean (essentially, report all).
Developed baseline configuration standards for commonly used operating systems/applications.
Mandated certification of 50% of mission critical systems by 9/30/03. Exceeded goal by 18%.  Used team of contractors to accomplish goal.  Plan for remaining systems – certify and accredit 90% of all systems by July 1, 2004.
Researched feasibility of designing and developing automated tools to assist in measuring, tracking and reporting progress. 

## Another Best Practice Tool

- Environmental Protection Agency

## EPA Tools

- ASSERT uses the NIST SP 800-26 as the foundation to automate the
- Annual FISMA Assessment process, allows the addition of agency specific questions, and shows relationships between systems.
- Based on the assessment responses, ASSERT identifies weaknesses, groups the weaknesses, and generates standard Tasks to correct the weakness.  Tasks to correct weaknesses from other sources are manually entered for tracking.
- Allows management to monitor and track progress towards correcting weaknesses using reports and access to systems within their component.
- Generates the FISMA quarterly reports.

- Automated Security Self-Evaluation and Remediation Tracking

## Assessment Questions

**Notes:**
Sample of what you see in ASSERT Assessment.  

Question from NIST 800-26.  Response in LOE (level of effectiveness:  policy - Level 1, procedure - Level 2, implemented - Level 3, tested – Level 4, integrated – Level 5); and EPA specific guidance provided.

Not shown on this slide:

The option to identify as Not Applicable; a Risk Based decision has been made (and appropriated approved & documented); and assign the question to a Secondary Assessor.
 The “Save” button.  Must save each question individually, even if linked to a task and you cannot change.

## System Information

**Notes:**
Fields captured in ASSERT for systems (version 3.1)

In future plan to link System Information to specific questions – for example, the Date of the Latest Authorized Security Plan to appropriate questions for consistency of data in ASSERT.  If you Security Plan date is out of date the related questions will be changed to reflect the lack of a Security Plan so that a task will be generated if one does not already exist.  If the date not current, you should correct to avoid unnecessary problems.

## ASSERT Reports

## Compliance Monitoring

- Commercial tool employed by EPA allows the agency to test network compliance with Agency approved configurations for standard technologies used.

## DOT Best Practice:Enterprise Security Portal

**Notes:**
Once DOT recognized that the information that is collected through the FISMA process is extremely valuable to overall IT security program management, we realized we had no way of collecting, analyzing, correlating, and storing all of this data.  Also, we needed a mechanism to facilitate and encourage our Operating Administrations to provide/update this data in and easy to use method. DOT began developing an automated tool to assist with measuring, tracking and reporting the program of its IT Security Program in May of 2003. We began with the POA&M module to reduce the stress of gathering data for reporting deadline in June.  

From that, the DOT Enterprise Security Portal was born.  The ESP is a management tool that is designed to assist our information security officers with managing their program, identifying budgetary, training, technology and policy needs. The next few slides provide an overview of the portal.

## Enterprise Security Portal:Policies, Guidelines, Standards

**Begin with policies, guidelines & standards**

**Notes:**
Policy Module
DOT began with all policies and developed guidelines and standards to implement policies
Based on Federal policies, statutes, laws
Guidelines and standards based on NIST and best practices

## Enterprise Security Portal:FISMA Reporting

**Web Enabling**
**FISMA Reporting Creates Efficiencies**

**Notes:**
FISMA Module
FISMA data is input into the ESP
Metrics (systems assessed for risks, systems w/up to date security plans, systems accredited)
POA&Ms
Push a button and out pops the FISMA quarterly and year end reports!

## Enterprise Security Portal:Baseline Configuration Standards

**Baselines**
**Required by**
**FISMA in 04**

**Notes:**
Baseline Configurations Sub-Module

Systems are built to baseline configuration standards
Configuration standards were developed using a risked based approach.  The higher the risk, the more stringent the controls
Existing systems are measured against baseline standards when going through the C&A process

## Enterprise Security PortalThreat/Vulnerability Information

**Threat/vulnerability data is applied to systems**

**Notes:**
Threat Management Module
Alerts are mapped to technologies which are mapped to inventory
Allows analysts to be proactive by identifying which systems may be vulnerable before being exploited

## Critical Success Factors:Senior Leadership Support

- Challenges: Business Leaders and System Owners must Buy-In to Security
- Promising practices:
- Use of President’s Management Agenda
- Metrics Collection and Reporting by Business Unit
- Results at Department of Transportation
- C&A Improved to 100%
- Vulnerabilities corrected within one week

## Critical Success Factors:Cost-Effective C&A

- Challenges: High cost of C&A and “snap shot’ security audits
- Promising practices:
- Continuous vulnerability management
- C&A in large batches of systems
- Results at Dept. of Transportation
- C&A costs reduced by 75 – 80% without loss of effectiveness
- Continuous view of DOT systems security status
- Substantially fewer vulnerabilities

## Critical Success Factors:Security Baked-In

- Challenge: Meeting FISMA demand for “minimally acceptable system configuration requirements” at reasonable cost
- Promising practice: Security baked in by the vendors - through procurement language
- Results:
- At an R&D Institute: All Solaris systems secure on delivery so scientists don’t have to secure every system
- At one Federal Department: savings in excess of $100 million projected for reduced patching costs, and measurably improved security, because common secure configurations can be patched in 24-48 hours.

## Proposed Language

**Securely configuring commercial software**
- (a)  In the performance of this contract, any commercial off the shelf (COTS) software delivered by [contractor] shall be configured in conformance with applicable system configuration requirements established by [agency] pursuant to 44 USC 3544 (b) (2) (D) (iii) as enumerated in Exhibit [X].
- (b)   [Contractor] shall maintain such COTS software so as to assure that it conforms to the most current version of all applicable [agency] system configuration requirements throughout its operational life cycle.
- (c)  For both custom and COTS software, with initial delivery and each subsequent release, [contractor] shall provide written assurance** **that the software operates satisfactorily on systems configured in accordance with section (a) above.
- (d) Prior to initial acceptance of the software by [agency] and for each subsequent software release [contractor] shall deliver a complete vulnerability test report of both system and application vulnerability of the application running on the operating system and platform proposed to be used in production.
- (e)  Any exceptions to conformance with the [agency’s] system configuration requirements must be approved in advance and in writing.

## Critical Success Factors: Integrating Testing for Cost Effective Compliance

- Annual
- FISMA
- Compliance
- Plan – 25%
- A Quarter

- POA&M

## Critical Success Factor:Integration with Budget

- Challenge: Meeting FISMA requirements at reasonable cost
- Promising practice: security incorporated into Exhibits 300
- Results:
- At DOT, 100% Business Cases included security funding
- Funding was included in Budget

## U.S. Department of Transportation FY 2003 IT Security Scorecard:

**“****D+”**

## U.S. Department of Transportation FY 2004 IT Security Scorecard:

**“****A-”**

## Summary:  Lessons Learned in FISMA Implementation

- Make it Real
- Its all about the business
- People, process, and technology must be combined to fix the problems
- Technology is easy to change; people are difficult to change
- Must absolutely have executive support to solve the real problems
- CIO-IG coordination essential throughout FISMA process
- Recognize that it is bigger than just security or the CIO
- Procurement officials
- Budget officials
- Business leaders
- Metrics are essential

**Notes:**
Implemented use of systems inventory guide and identified 630 IT systems, 222 are mission critical.
Major project between May and September to certify and accredit mission critical by 9/30/03.
Developed a web-based tool to track and measure progress on the POA&Ms identified through the certification process and report to OMB.
Began developing the required baseline configurations to be used when building new systems as well as performing compliance review of existing systems.