Overview of FISMA and FedRAMP process and controls with a focus on Drupal layer controls

2. Presenter
Michael Lemire
Director of Information Security
michael.lemire@acquia.com

3. Agenda
• Review Current US Government Compliance landscape
• How to achieve FISMA Compliance
• International and Developing Compliance Standards
• How Acquia achieved a compliant ready hosting platform.

4. Drupal in the Federal Government
• Governments are expanding use of Drupal
• Drupal is open source
• Cost effective vs proprietary licensed software
• Proven secure
• Drupal facilitates shared development between agencies
• Proven
• www.whitehouse.gov
• www.house.gov
• www.ready.gov
• www.investor.gov
• www.teach.gov
• www.ed.gov
• www.energy.gov

5. Current US Government Compliance Landscape
FISMA, DIACAP and FedRAMP are standardized approaches to security assessment,
authorization, and continuous monitoring for information systems utilized by the
Federal government.
FISMA - Federal Information Security Management Act of 2002. Applicable to non-
DoD agencies.
DIACAP – Department of Defense Information Assurance Certification and
Accreditation Process. Applicable to DoD related agencies.
With both FISMA and DIACAP each information system must be documented, reviewed
by independent third party assessor and authorized by authorizing officials.
Time consuming, expensive

6. Coming Soon - FedRAMP
FedRAMP - Federal Risk and Authorization Management Program
• Establishes an “authorize once, use many times” framework for cloud
computing products and services. FedRAMP is meant to supersede
FISMA and DIACAP for cloud products.
• FedRAMP was established on Dec 8, 2011 via a memorandum produced by
the Federal Chief Information Officer and is due to achieve Initial Operating
Capacity in 2012.
• Based on the same NIST publications as FISMA with added controls pertinent
to the cloud
• FedRAMP Concept of Operations – defines how the FedRAMP process will
work
• http://www.gsa.gov/graphics/staffoffices/FedRAMP_CONOPS.pdf

7. Important NIST Publications and Standards
FIPS 199 – Security categorization of the information system according to
its Confidentiality, Availability and Integrity requirements
• What type of data?
• Importance to national security?
Determine “High water mark” (low, medium, high)
NIST 800-53 rev 3 – Security Controls documented in the SSP
All domains of security are covered and must be documented
Risk Assessment, Personnel, System Acquisition, Physical and
Environmental, Contingency Planning, Configuration Management,
Incident Response, Security Awareness Training, Authentication, Logging
and Audit, Network Security and Encryption
Rev 4 now in draft – adds add’l mobile and cloud controls
NIST 800-30 – Risk Assessments
Defines process for assessing risk and how to apply the process to the
organizational, mission and information system levels.

8. Federal Compliance - High Level Process
1. Categorize the System – FIPS 199
FISMA, DIACAP and FedRAMP Process Confidentiality, Integrity, Availability
2. Select the controls – NIST 800-53
3. Implement the controls and
document them
-System Security Plan
-Privacy Impact Assessment
4. Assess – Contract with Third
Party Assessor
-3PAO reviews SSP and creates STE &
POA&M
5. Authorize – This package of
documents submitted to the
Authorizing Official who reviews,
comments, asks for revisions.
-grants IATC and/or ATO
6.Monitor – Continuous update to
SSP , continuous mitigation of items
identified in STE and POA&M

9. Step 1: Categorize the system –FIPS 199
Establish the “high water mark”- Low/Moderate or High

10. Step 2: Select the controls
NIST 800-53 Revision 3
Annex 1 – Low “high water mark”
Annex 2 – moderate “high water mark”
Annex 3 – high “high water mark”

11. Step 3: Implement and document the controls
The System Security Plan (SSP) -a narrative description of the system
-define the “accreditation boundary” – what is it that is being authorized
-describes the system and the environment where it resides
.. And the controls, divided into control families:
Risk Assessment (RA)
Planning (PL)
System and Service Acquisition (SA) Access Control (AC)
Certification and Authorization (CA) Audit and Accountability (AU)
Personnel Security (PS) System and Communication Protection (SC)
Physical and Environmental Security (PE)
Continuity Planning (CP)
Configuration Management (CM)
Maintenance (MA)
System and Information Integrity (SI)
Media Protection (MP)
Incident Response (IR)
Awareness and Training (AT)
Identification and Authentication (IA)

12. Step 4: Assess The Controls (Audit)
The assessment is a validation by an independent auditor that “you do what
you say you do”. Guided by NIST 800-53a
The third party assessor (3PAO) is tasked with reviewing the SSP and
validating are those control in place.
3PAO creates Security Test & Evaluation Plan (ST&E) and the System
Assessment Report (SAR) which documents the evidencing activities and
results.
-What is non-compliant
Plan of Action Milestone (POA&M) – Lists controls which are not in place and
the plan to implement those controls

13. Step 5: Authorize the System
Finally the FISMA C&A Package is submitted to the Authorizing Official
The package:
• The SSP
• Relevant Policies and Procedures
• The FIPS 199 categorization
• The SAR and ST&E
• The POA&M
Authorizing Official once satisfied issues Authority to Operate (ATO)

14. Step 6: Monitor and Update
• Update the SSP as things change
• Resolve issues and follow plan per POA&M
• Continuous monitoring of risks
• Re-authorize system every 3 years

16. Accomplishing Federal Compliance in the Cloud
Cloud Service Providers may be responsible for the entire set of
controls, or they may be shared in a Shared Responsibility Model
Examples:
SaaS may be built on PaaS Ex: DrupalGardens
PaaS may be built on IaaS Ex: Acquia Managed Cloud
Three primary layers in the shared responsibility model:
•Application Layer (Drupal)
•OS Stack Layer (Linux, Windows, Database, etc)
•Infrastructure Layer (Datacenter, network)
*Each entity must document the controls for which they are
responsible for.*

17. Example: Acquia Managed Cloud
Acquia Managed Cloud is a
PaaS built on
Amazon’s AWS IaaS

18. Example: Acquia Managed Cloud
Example SSP control description:
Control: (from 800-53)
Control Type: Agency/Common/Hybrid
Control Status: Implemented/Planned/Not Applicable
Application Layer:
Responsibility: Customer (Agency)
Implementation Detail: Describe how the control is the responsibility of the agency.
LAMP Stack Layer:
Responsibility: Acquia
Implementation Detail: Describe how the control is implemented
Infrastructure:
Responsibility: Amazon
Implementation Detail: Refer to hosting provider’s SSP
Acquia documents its control responsibilities in its SSP
Amazon documents its control responsibilities in its SSP

19. FISMA Moderate Controls applicable to the
Drupal layer

20. FISMA Moderate Controls applicable to the
Drupal layer

21. FISMA Moderate Controls applicable to the
Drupal layer
How to implement these controls:
-OpenPublic distribution
-Drupal modules:
Password Policy http://drupal.org/project/password_policy