# Presentation: 598384

## The Assured Improvement Process Model

- S. Brian Suddeth
- AMSD

- 2005 Census Software Engineering
- Process Group Conference
- November 8, 2005

## What is Assured Improvement?

-  	CMMI and related process models provide a framework for reliable and validated development and business practices.  They ensure structured and repeatable processes.  In the Federal environment, we also have to ensure the confidentiality, integrity and availability of our systems.
-    ***Assured Improvement ****is the integration of Federal IT Security and Software Development Life Cycle (SDLC) requirements into the process models.*

## Why is it important? 

- Auditors require specific levels of certainty:
- Is there a policy to be met?
- Is there a procedure that addresses the policy?
- Is the procedure implemented?
- Has the procedure/process been tested?
- Is the process integrated?

**Notes:**
All federal IT programs are being reviewed by GAO, OMB and OIG inspectors and auditors.  They have a checklist that covers what they review, and how they review it.  The easier we can make it to for them to see that we know what we are doing, we know why we are doing it, we know how we are doing it, and we can verify it, the sooner they will be satisfied and move on to someone who can’t.

## How do we prove it?

**Auditors use several methods to assess compliance:**
- Review documentation
- Trace requirements to processes
- Direct observation of the process
- Interview key individuals
- Check review and reauthorization process

**Notes:**
If you ensure that your CMMI processes are designed to include the required documentation and checkpoints, it becomes easy to demonstrate requirements traceability, provide easy validation and show process integrity.

## What does CMMI lack?

- 	The CMMI model does not specifically address most security issues, only the quality of the process.  Auditors require that we know the policies, we follow them, and that we can provide evidence to verify what we have done.  CMMI lacks traceability of processes and authorization to specific mandatory IT Security practices.

**Notes:**
The Federal Information Security Management Act (FISMA) has many requirements every federal IT program is required to follow.  CMMI provides and excellent framework for process modeling, improvement and planning.  It does not address IT security directly though.

## What are we doing wrong? 

- Addressing security controls late in the development process
- Adding security as an "overlay" rather than a baseline
- Redesigning to make a process secure
- Focusing on business functionality without assessing impact or risk
- Making security controls someone else's problem
- Stovepipe or completely custom designs

## What are we doing right? 

**If you can use existing enterprise managed processes and tools, you don’t waste effort!**
- IT Standards
- Enterprise Architecture
- Pre-approved software products
- Certification and Accreditation
- Professional staff and contractors
- Mission Focus

## Do I have to? 

- You are being watched!
- House Government Reform Sub-Committee FISMA scorecards.
- OMB, GAO and IG audits
- President's Management Agenda
- Certification and Accreditation Process
- DOC and BOC IT Security Program Policy

**Notes:**
Commerce gets an E in IT Security!  Red lights!  Government Reform Subcommittee hearings!  Federal Computer Week.  Government Computer News.

## But do I REALLY have to? 

- SECURITY IS TIED TO OUR BUDGET AND APPROVAL TO OPERATE
**Public Law 107-347 (Title III)****	**
**	****(Federal Information Security Management Act of 2002 - FISMA)**
**Public Law 107-305**
**	****(Cyber Security Research and Development Act of 2002)**
** ****Homeland Security Presidential Directive #7**
**	****(Critical Infrastructure Identification, Prioritization, and Protection)**
**OMB Circular A-130 (Appendix III)**
**	****(Security of Federal Automated Information Resources)****  **

## What are the costs of lack of IT Security integration? 

- System redesign issues
- Wasted resources
- Higher stress
- Schedule slippage
- Increased risk to data
- Interruption of service to our customers
_***LOSS OF PUBLIC CONFIDENCE***_

## What should we be doing? 

- Ensure that the security processes support your business case
- Make small changes early for big impact later
- Know the basic security controls
- Follow the Software Development Life Cycle (SDLC)
- Assess Risk Early And Often
- Document your security requirements
- Document and integrate security controls

## How do we integrate it? 

- When we start a project or make a change, ask the basic questions:
- Who (person, as well as policy or law) authorizes it?
- What are the risks associated with it?
- Where in the process should we perform specific security reviews and have documents updated?
- When do we review it to ensure it is still appropriate?
- How sensitive is the kind of data it will process?
- Which minimum security controls are required?

## How do we integrate IT Security into our processes?

- SP 800-64 - Security Considerations in the Information System Development Life Cycle
- 	http://csrc.nist.gov/publications/nistpubs/800-64/NIST-SP800-64.pdf

## How do we integrate IT Security into our processes?

## Simple Q&A for Requirements?

- How do I determine data sensitivity?
- 		**FIPS 199 & SP 800-60**
- What security controls are needed?
- 		**FIPS 200 & SP 800-53**
- How does data transmitted on a public net get encrypted?
- 		**FIPS 140-1 & 140-2**
- How do I document a major system interconnection?
- 		**SP 800-47**
- How do we document risks?
- 		**SP 800-30**

## KEEP IT SIMPLE 

- Ask the questions before you commit to the changes
- Document the policies and SDLC checkpoints as basic design requirements
- Know how the changes affect your security documentation
- Update the documentation as you go, rather than afterward

## Educate Everyone!  

**Everyone has a role in IT security.**
**Document it in your processes!**
- Clear Rules of Behavior and Standard Operating Procedures
- Annual "Role Based Training" for trusted jobs
- Annual review and reauthorization of roles and privileges
- Annual review of security controls / documents
- Requirements Traceability
- Ownership of your piece of the process
- Documented and verified procedures
- Separation of duties for trusted sensitive positions

**Notes:**
Trusted positions and roles with more than “end user” privileges should be done by separate personnel.  They need training to keep their skills fresh.  They need to have others authorize and review their work for validation.  Annual review and reauthorization of privileges ensures they stay correct.

## So what are the payoffs? 

- By integrating IT Security into the standard processes, we get:
- A robust approach to confident information assurance
- Clarified requirements
- The opportunity to address issues early
- Lowered overall lifecycle cost
- Reduced stress of developing and maintaining our IT systems
- Assurance we can meet our mission, conserve resources and support our business

## Keep it Simple Keep it Integrated! 

- 	When security policies and procedures are an understandable part of our regular routine:
- It enhances our ability to meet our mission
- It inspires confidence and pride in our work
_***IT KEEPS OUR PROGRAM COSTS DOWN***_

## Managing Enterprise RiskThe NIST FISMA Framework (Dr. Ron Ross)

***Starting Point***

## SDLC Information Security

## Where can we find the "How To" documents we need? 

***FISMA Implementation Project*****  **
**(http://csrc.nist.gov//sec-cert/)**
***NIST Computer Security Division SDLC***
**	****(http://csrc.nist.gov/SDLCinfosec)**
***NIST FIPS and Special Publications***** (800-x)**
**	****(http://csrc.nist.gov/publications/nistpubs/index.html)**
***Risk Management Framework***** - Pages 31 & 32**
**	****(http://csrc.nist.gov/sec-cert/PPT/fisma-overview-v1.8.pdf)**
***Information Security System Development Life Cycle***
**	****(http://csrc.nist.gov/SDLCinfosec/SDLC_brochure_Aug04.pdf)**

## More links: 

**Computer Security Policies  http://csrc.nist.gov/policies**
**FIPS Publication 199 - Standards for Security Categorization of Federal Information and Information Systems**
**	****	****http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf**
**FIPS Publication 200 - Minimum Security Requirements for Federal Information and Information Systems**
**	****	****http://csrc.nist.gov/publications/drafts/FIPS-200-ipd-07-13-2005.pdf**
**NIST Special Publication 800-53 - Recommended Security Controls for Federal Information Systems**
**	****	****http://csrc.nist.gov/publications/drafts/sp800-53A-ipd.pdf**
***Cryptographic Module Validation Program*****  http://csrc.nist.gov/cryptval/welcome.html**

## Related Presentations: 

**http://iase.disa.mil/ditscap/ditsarticle.pdf**
**http://www.cyberpartnership.org/SDLCFULL.pdf**
**http://www.cyberpartnership.org/Software%20Pro.pdf**
**http://www.dtic.mil/ndia/2004cmmi/CMMIT6Thur/Achieving_System_and_Software_Assurance_through_CMMI_Complia.pdf**

## Questions

- ?

## Contact Information

- S. Brian Suddeth, AMSD DSO
- 301-763-1593
- _[Stephen.B.Suddeth@Census.gov](mailto:Stephen.B.Suddeth@Census.gov)_
***BOC ITSO  301-763-2862***