Proactive Lifecycle Security Management Presented by Rick Ensenbach, CISSP-ISSMP, CISA, CISM

1
Proactive Lifecycle Security Management
Presented byRick Ensenbach, CISSP-ISSMP, CISA,
CISM
2
Survey

• Is it acceptable for IT to be the data owner and
  or system owner?
• Who should be responsible for accepting security
  risk on behalf of the organization?
• Who should be responsible for defining security
  controls in an organization?
• Who in the audience has to comply with the
  Federal Information Security Management Act
  (FISMA)?

3
Setting the Stage

• In the last four years, approximately 250 million
  records containing personal identifiable
  information of United States residents stored in
  government and corporate databases was either
  lost or stolen.  Since little attention was given
  to database breaches prior to 2005, it is safe to
  assume that every man, woman and child has had
  their personal information exposed at least once
  statistically. 
• Quote from InsideIDTheft.info
• Data theft and breaches from cybercrime may have
  cost businesses as much as 1 trillion globally
  in lost intellectual property and expenditures
  for repairing the damage last year, according to
  a survey of more than 800 chief information
  officers in the U.S., United Kingdom, Germany,
  Japan, China, India, Brazil, and Dubai. The
  respondents estimated that they lost data worth a
  total of 4.6 billion and spent about 600
  million cleaning up after breaches
• McAfee Report - "Unsecured Economies Protecting
  Vital Information"

4

• According to the Open Security Foundation's
  DATALOSSdb this pie chart represents events
  involving the loss, theft, or exposure of
  personally identifiable information (PII) for
  2008.

5
No Lack of Publicity or Victims
6
Customer loss following data breach
PGP Corporation and the Ponemon Institute annual
report - U.S. Cost of a Data Breach Study
7
Cost of Data Breach
PGP Corporation and the Ponemon Institute annual
report - U.S. Cost of a Data Breach Study
8
Cost of a Security Bug
Courtesy of SecurityCompass presented at 2008
Minnesota Government IT Symposium Non-Technical
Costs breach reporting, regulatory violation
(penalties), legal fees What is the reputational
cost ??????
9
Security Authorization Process Summary

• Security authorization (formerly called
  certification and accreditation) ensures that on
  a near real-time basis, the organizations
  senior leaders understand the security state of
  the information system and explicitly accept the
  resulting risk to organizational operations and
  assets, individuals, and other organizations.
• Specific point in time based on the residual
  risk and mitigating controls associated with the
  system being authorized to operate in a
  production environment.

10
Who is this process targeted at?

• Business owners
• Data owners
• Personnel responsible for
• Development, acquisition and integration
• System security
• Auditors/assessors
• Security implementation and operations

11
Security Authorization History

• Roots go back to 1983 Federal Information
  Processing Standard (FIPS) 102
• Known by many different names
• Certification Accreditation (CA)
• National Information Assurance
• Certification Accreditation Process
  (NIACAP)
• Defense Information Technology Security
  Certification and Accreditation Process (DITSCAP)
• DOD Information Assurance Certification and
  Accreditation Process (DIACAP)
• Director of Central Intelligence Directive (DCID)
  6/3

12
Key Definitions

• Information System A discrete set of
  information resources organized for the
  collection, processing, maintenance, use,
  sharing, dissemination, or disposition of
  information
• Security Authorization The testing and/or
  evaluation of management, operational, and
  technical security controls in an information
  system to determine the extent to which the
  controls are implemented correctly, operating as
  intended and producing the desired outcome with
  respect to meeting security requirements for the
  system
• Security Control Assessment The testing and/or
  evaluation of the management, operational, and
  technical security controls in an information
  system to determine the extent to which the
  controls are implemented correctly, operating as
  intended, and producing the desired outcome with
  respect to meeting the security requirements for
  the system
• Security Authorization Boundary All components
  of an information system to be authorized for
  operation by an authorizing official and excludes
  separately authorized systems, to which the
  information system is connected
• Plan of Action and Milestones A document that
  identifies tasks needing to be accomplished,
  resources required to accomplish the elements of
  the plan, any milestones in meeting the tasks,
  and scheduled completion dates for the
  milestones.
• Security Plan - Formal document that provides an
  overview of the security requirements for the
  information system and describes the security
  controls in place or planned for meeting those
  requirements
• List not all inclusive See NIST SP 800-37,
  Appendix B for more detailed list

13
Key Process Players

• Authorizing Official A senior official or
  executive with the authority to formally assume
  responsibility for operating an information
  system at an acceptable level of risk to
  organizational operations, assets, individuals,
  and other organizations
• Information (data) Owner Official with
  statutory or operational authority for specified
  information and responsibility for establishing
  the controls for its generation, collection,
  processing, dissemination, and disposal
• Information System Owner Official responsible
  for the overall procurement, development,
  integration, modification, operation and
  maintenance of an information system
• Information System Security Officer Individual
  assigned responsibility for maintaining the
  appropriate operational security posture for an
  information system or program
• Security Control Assessor The individual, group
  or organization responsible for conducting a
  security control assessment
• !!! Discussion Point Conflicts of interest !!!

14
Other Roles

• Common Control Provider
• Information System Security Engineer
• Chief/Corporate Security Officer
• Risk Executive Function

15
Regulatory Industry Requirements
16
Standards
17
Benefits to Implementing Security Authorization
Process

• Direct business participation
• Pre-production security authorization avings
• Risk acceptance at the appropriate level of
  management
• Risks are documented, to include mitigation
  strategies
• Business explicitly accept residual risk and
  recommended security controls
• Standardization
• Assessment, documentation and acceptance of
  security risks
• Architecture and configuration documentation
• Documentation (i.e. BCP/DR, policies, asset
  inventory, etc.)
• Unbiased security controls assessment

18
Relationship to System Lifecycle

• Dark gray Acquisition Lifecycle Phases
• Light gray Development Lifecycle Phases

19
Risk Management Framework
Security authorization is just one step within
the risk management process
20
Security Authorization Process
RMF Risk Management Function
21
Preparation Phase

• Categorize Information System
• Define system boundary
• Create security plan and begin system
  documentation
• Register system in organization asset inventory
• Determine security classification
• Organizational/business criticality
• Relationship/impact to other systems
• Classification of data processed by system
• Level of availability required
• Importance of data integrity
• Security Control Selection
• Initial selection security controls
• System specific (implemented), common (inherited)
  and/or hybrid controls
• Management Controls (controls used to manage
  system risk)
• Technical Controls (automated system safeguards
  and countermeasures)
• Operational Controls (policy, standards, and
  procedural measures)
• Security Plan Approval
• Review and approve initial version of security
  plan

22
Authorization Boundary

• Purpose Reduce cost and complexity, and
  facilitate more targeted application of security
  controls
• Must be done before system categorization and
  security plan development
• Separate large and complex systems by
• data, technology and personnel
• should generally be under the same direct
  management control
• function or mission/business objective
• operating characteristics and information
  security needs
• same general operating environment
• different locations with similar operating
  systems
• Avoid performing security authorization on
  individual software applications - include them
  in the authorization boundary of the host system
• Use commonsense

23
System Security Plan

• Prepared and maintained by the information system
  owner
• Living document
• Provides overview of security requirements and
  description of security controls
• Should contain supporting appendices or reference
  appropriate sources
• Risk assessments
• System interconnection diagrams
• Service level agreements
• Data flow diagrams
• Disaster recovery and contingency plans
• Security configurations
• Configuration management plan
• Incident response plan
• Applicable policies and procedures
• Hardware and software inventories
• Should be updated whenever events impact agreed
  upon security controls
• Vulnerability scan
• New threat to system
• Redefinition of business priorities/objectives
• Addition of new hardware, software or firmware

24
Preparation Phase

• Security Controls Implementation
• Implement previously defined security controls
• Document security controls in security plan
• Functional description
• Planned inputs
• Expected behavior and outputs
• Security Controls Assessment (examination,
  interview and test)
• Select an assessor
• Develop the assessment plan
• Gather documentation needed for assessment
• Perform assessment
• Prepare preliminary assessment report and review
  with system owner
• Perform remediation actions and reassess
• Update security assessment report and prepare
  executive summary for authorizing official
• Update security plan
• Prepare Plan of Action Milestones (remediation
  plan)

25
Authorization - Execution Phase

• Authorize Information System
• Assemble authorization package and submit to
  authorizing official for approval
• Determine the risk to the organization
• Formally accept risk based on
• Compensating controls
• Plan of Action and Milestones
• Residual risk
• Task 4 Prepare the security authorization
  decision and document
• Authorization decision (approval or denial to
  operate)
• Terms and conditions for the authorization
• Authorization termination date

26
Authorization Package
Security Plan
Authorization Package
Security Assessment Report
Plan of Action Milestones
27
Continuous Monitoring - Maintenance Phase

• Strategy
• Maintain the authorized state of security during
  the authorization period and adjust as needed
• Objectives
• Continually monitor the security state of the
  system
• Continually monitor security controls for
  effectiveness
• Configuration/Patch management
• Change control
• Assess the impact to security as changes to the
  system occur
• Maintain security plan and plan of action and
  milestones
• Continually report security status to authorizing
  official

28
Continuous Monitoring Continues Until

• Changes to the system have introduced new
  vulnerabilities
• Controls are no longer effective
• Risk accepted by the authorizing official has
  changed or
• The authorization deadline has passed, then
• Reauthorization begins!

29
Reauthorization

• Reauthorization occurs at the discretion of the
  authorizing official in accordance with federal
  or organizational policy
• Time Driven
• Authorization termination date has been reached
• Event
• Authorizing official changes
• Routine environment/system changes
• Significant environment/system changes (per NIST
  800-37)
• Installation of a new or upgraded operating
  system, middleware component or application
• Modifications to system ports, protocols or
  services
• Installation of a new or upgraded hardware
  platform or firmware component
• Modifications to cryptographic modules or
  services
• Changes in laws, directives, policies or
  regulations
• NOTE Event driven reauthorization should be
  avoided in situations where the continuous
  monitoring process provides the necessary and
  sufficient information to the authorizing
  official to manage the potential risk arising
  from significant environment or system changes.

30
Process Implementation

• Crawl before you walk, walk before you run
• If you have to comply with FISMA, you must have a
  security authorization process in place
• Based on NIST SP 800-37
• Flexibility
• Even if you dont implement this process,
  consider the value of this process
• Pre-production assessment
• Security plan
• 3rd party assessment
• Business involvement

31
Where to get more information

• I-Assure Forum
• www.i-assure.com/forums/Default.aspx
• NIST SP 800-37
• http//csrc.nist.gov/publications/drafts/800-37-Re
  v1/SP800-37-rev1-IPD.pdf
• Books
• FISMA Certification Accreditation Handbook
• by Laura Taylor (ISBN-10 1597491160)
• Building and Implementing a Security
  Certification and Accreditation Program
• by Patrick D. Howard (ISBN-10 0849320623)

32
2009 Prediction

• More and more private sector companies and
  universities will have to comply with FISMA. Why?
  Many companies that are government contractors
  are being required to comply with FISMA already
  as a stipulation in their contracts with the
  government. Organizations that accept grants from
  the government are increasingly being required to
  comply with FISMA.
• FISMA 2008 will pass and government CISOs will
  become more empowered.
• Laura Taylor, Founder of Relevant Technologies
  and author of the FISMA Certification
  Accreditation
• Handbook

33
Status of FISMA Related NIST Publications

• SP 800-30, Revision 1 Guide for Conducting Risk
  Assessments - FEBRUARY 2010
• SP 800-37, Revision 1 Guide for the Security
  Authorization of Federal Information Systems A
  Security Life Cycle Approach - JUNE 2009
• SP 800-39 Managing Risk from Information
  Systems An Organizational Perspective - JULY
  2009
• SP 800-53A, Revision 1 Guide for Assessing the
  Security Controls in Federal Information Systems
  DECEMBER 2009
• SP 800-CM Guide for Security Configuration
  Management and Control (Publication number TBD)
  NOVEMBER 2009

34
Points to Remember

• Assess a defined environment (authorization
  boundary) not the world
• Security authorization is an ongoing process
• Security control assessors make recommendations,
  they do not accept risk or approve mitigating
  controls on behalf of the organization
• Risk acceptance is the sole responsibility of the
  authorizing official
• Reuse and share of security control development,
  implementation, and assessment-related
  information to reduce cost and time
• An active continuous monitoring program reduces
  time and effort

35
Problem vs Challenge

• The problem is not technology, nor is it the
  solution! We need to re-educate our senior
  leaders about the purpose and goal of risk
  management. Regardless of whether it is
  financial, security reputational, regulatory or
  other type of risk, the acceptance of risk is
  ultimately their responsibility and not that of
  IT or security.

36
Questions

• Thank You!
• Rick Ensenbach CISSP-ISSMP, CISA, CISM
• Rick.Ensenbach_at_state.mn.us
• 651-201-2790