Integrating IT Security into the System Development Life Cycle (SDLC)

1
Integrating Security into the Systems
Development Life Cycle (SDLC) May 22, 2003
Center for Information Technology Office of
the Deputy Chief Information Officer Mike
Friedman, CISSP mf28c_at_nih.gov 2-4458 Larry
Wlosinski, CDP, CISSP, GSEC wlosinsl_at_mail.nih.go
v 2-4443
2
AGENDA (1st Half)

• Introduction/Background/Course Objectives
• What is Security?
• How Things Changed
• What we Found during Y2K
• Certification and Accreditation
• What is the SDLC?
• Security and the 5 Phases of the SDLC
• Performance Measures

3
AGENDA (2nd Half)

• Risks Associated with Bad Programming Practices
• Top 10 Application Security Vulnerabilities
• Common Programming Errors
• Protection Against Parameter Tampering
• Programming Concerns and Safeguards
• Responsibilities
• Questions

4
Course Objectives

• Provide an introduction to application security
• Provide a basic framework for system
  certification and accreditation
• Inform you about application related security
  services, functions, and responsibilities
• Provide useful information about programming
  concerns
• Provide pointers to security guidance (i.e. Best
  Practices) for programmers

5
Protecting Information

• No Power
• No Users
• No Network Connection

6
The Only Truly Secure Computer
7
How Do We Give Away our Private Information?

• People Steal It
• We Give it away Unintentionally
• We Give it away Intentionally

8
Annual Number of Computer Viruses
9

Annual Number of Web Page Defacements

10
(No Transcript)
11
What is Security?

• Confidentiality - Ensuring that there is no
  deliberate or accidental improper disclosure of
  sensitive automated information.
• Integrity - Protecting against deliberate or
  accidental corruption of automated information.
• Availability - Protecting against deliberate or
  accidental actions that cause automated
  information resources to be unavailable to users
  when needed.

HHS Automated Information Systems Security
Program Handbook - http//irm.cit.nih.gov/policy/a
issp.html
12
How Things Have ChangedHardware
13
How Things Have ChangedSoftware and Data
14
How Things Have ChangedSystem Development Life
Cycle
15
How Things Have ChangedIT Security
16
How Things Have ChangedIT Security (Cont.)
17
Documentation Concerns(What we learned from Y2K)

• Required Documentation Findings
• Software Program Rarely
• Operational Poor
• User Non existent
• LAN Administrator None
• System Administrator Poor
• Database Administrator Little
• Disaster Recover Only Data Center
• Contingency Planning Little
• Security Plan Mission Critical
• Certification / Accreditation None
• Security Test Plan Whats that?
• Authorization to Process (MOU) None

18
Documentation Concerns

• User access privileges
• Deregistration - Implement procedures to control
  access when staff leave
• Operations, system, user, and programming -
  documentation is to be kept current
• Continuity of Operations

19
Security Certification

• A comprehensive analysis of the technical and
  non-technical aspects of an IT system in its
  operational environment to determine compliance
  to stated security requirements and controls.
• Employs a set of structured verification
  techniques and verification procedures during the
  system life cycle
• Demonstrates the security controls for an IT
  system are implemented correctly and are
  effective
• Identifies risks to confidentiality, integrity,
  and availability of information and resources
• Ultimate Goal Authorization to Process

20
System Accreditation

• A management decision by a senior agency
  official to authorize operation of an IT system
  based on the results of a certification process
  and other relevant considerations
• Assigns responsibility for the safe and secure
  operation of an IT system to a designated
  authority
• Balances mission requirements and the residual
  risks to an IT system after the employment of
  appropriate protection measures (security
  controls)

21
Key Documents in Accreditation and Certification

• System Design Reviews (SDRs)
• Risk Assessments (RAs)
• System Security Plans (SSPs)
• Interconnection Agreements
• Security Test and Evaluation (STE) Reports
• Continuity Of Operation Plans (COOPs)
• Corrective Action Plans (CAPs)
• Disaster Recovery Plan (DRP)
• Certifiers Statement and the Accreditation
  Letter

22
Applicable IT Security Legislation and Regulations

• Computer Security Act of 1987
• OMB A-130 (Appendix III)
• Federal Information Security Management Act
  (FISMA)
• Health Insurance and Portability and
  Accountability Act (HIPAA)
• Information Technology Management Reform Act
  (ITMRA)

23
What is the SDLC?

• NIST SP 800-34 defines the SDLC as the scope of
  activities associated with a system, encompassing
  the systems initiation, development and
  acquisition, implementation, operation and
  maintenance, and ultimately its disposal that
  instigates another system initiation.

24
Phases of the SDLC
25
Phase 1 Initiation

• Data Sensitivity Assessment
• Preliminary Risk Assessment (RA)
• Review Solicitations (e.g. Request for Proposals
  - RFPs)

26
Phase 2 Development/Acquisition

• Functional and Technical Features/Requirements
• Staff background Checks
• Operational Practices
• Test Plans, Scripts, and Scenarios
• Security Controls in Specifications

27
Phase 2 Development/Acquisition (2)

• In-House Concerns
• Security features
• Development process
• Changing requirements
• Threats
• Vulnerabilities
• Malicious insiders

28
Phase 2 Development/Acquisition (3)

• COTS Applications
• Operational Practices
• System Security Plan (SSP)
• Contingency Plan (CP)
• Awareness
• Training
• Documentation

29
Phase 3 Implementation

• Testing and Accreditation
• Test Data
• Test unit, subsystem, and entire system
• Technical evaluation
• Security Management - administrative controls and
  safeguards

30
Phase 3 Implementation (2)

• Physical facilities
• Personnel, responsibilities, job functions, and
  interfaces
• Procedures (e.g. backup, labeling)
• Use of commercial or in-house services
• Contingency Plans

31
Phase 3 Implementation (3)

• Disaster Recovery Plan (DRP)
• COTS products (security patches?)
• Remove installation programs
• Machine content/intent
• File and program overlay settings and privileges

32
Phase 3 Implementation (4)

• Backup, restore, and restart instructions and
  procedures
• Implementation backups (could server as
  benchmark)
• Ensure implementation of only approved/accredited
  systems

33
Phase 4 Operations/Maintenance

• Backup and restoration parameters
• Performing backups
• Support training classes
• Cryptography keys
• User administration and access privileges
• Audit logs

34
Phase 4 Operations/Maintenance (2)

• Log file analysis
• Security software
• Physical protection
• Off-site storage
• Output distribution
• Software hardware warrantees
• Registration/Deregistration

35
Phase 4 Operations/Maintenance (3)

• Operational Assurance Activities
• Review runtime operation
• Review technical controls
• Verify documentation of access permissions
• Review system interdependencies
• Verify that documentation is current
• Verify proper use of deregistration
• Verify that documentation is accurate

36
Phase 5 Disposal

• Storage of cryptographic keys
• Legal requirements of records retention
• Archiving federal information
• Sanitize media

37
Performance Measures - Why

• Quantify Benefit/Cost Analyses
• Budget Monitoring
• Quality Control/Improvement
• Regulatory Reporting

38
Performance Measures

• Meeting the privacy, integrity, confidentiality,
  availability of the system as defined in the
  statement of work or statement of need
• Labor hours spent on IT Security
• Dollars associated with IT Security

39
Tracking Security Costs

• Background checks of employees
• Developing security requirements for the project
• Developing RFAs
• Reviewing RFPs
• Developing contingency program
• Back-up processing

40
Tracking Security Costs (2)

• Off-site storage of back-up media
• Developing security test program
• Exercising security test plans
• Training Managers, Users, Operational Staff, LAN
  Administrators, Local Support Staff, Security
  Staff, etc.

41
BREAK
42
Risks

• Financial Fraud
• Theft of Proprietary or Sensitive Info.
• Internal Attacks into Sensitive Applications
  (E.g. Human Resources, Patient Info., Grants,
  Financial Info.)
• Content Manipulation
• Loss of Customer Trust
• Unstable Application due to DoS attacks

43
Web Application Security Vulnerabilities

• Un-validated parameters
• Broken Access Controls
• Broken Account and Session Management
• Cross-Site Scripting Flaws
• Buffer Overflows

44
Web Application Security Vulnerabilities (Cont.)

• Command Injection Flaws
• Error Handling Problems
• Insecure Use of Cryptography
• Remote Administration Flaws
• Web and Application Server Mis-configurations

45
Common Programming Errors

• Failure to Adhere to the Design
• Improper Error Detection and Handling
• Buffer Overflows
• Improper Input Validation
• Un-initialized Variables
• Format String Attacks
• Erroneous Locking Routines
• Code Reviews only after Implementation

46
Protection Against Parameter Tampering

• Data type restrictions (I.e. string, integer,
  real, etc.)
• Permit only the allowed character set
• Maximum and minimum length checking
• Check whether Null is allowed

47
Protection Against Parameter Tampering (Cont.)

• Check whether parameter is required or not
• Check whether duplicates are allowed
• Numeric range checking
• Allow only specific legal values
• Allow only specific patterns

48
Programming Concerns and Safeguards

• Access Controls
• System and Data Integrity
• Unauthorized Access
• Privacy and Confidentiality
• Production Implementation
• Documentation

49
Access Controls

• Require a User ID and password
• SQL command concerns
• Allow on valid accounts
• Encrypt passwords
• Use strong passwords
• Beware of disks/CDs in reader
• Do not program as administrator
• Single Sign-On

50
System and Data Integrity

• Check contractor disks
• Software upgrades and patches
• Program for versatility
• Allow only acceptable parameters
• Restrict use of configuration files
• Do not store parameters in system registers
• Edit data for size and value

51
System and Data Integrity (2)

• Avoid using pathnames
• Allow only acceptable error codes
• Dont retrieve data from public files
• Dont use undocumented, seldom used, or unusual
  functions or commands
• Control quantity and size of files
• Limit number of processes running at one time
• Web update cookies via on-line access
• Encrypt sensitive or critical data

52
Unauthorized Access

• Avoid commands that hackers can find in log files
• Avoid using hidden fields
• Do not store sensitive data on web control pages
• Avoid using cookies
• Use compiled code in production

53
Unauthorized Access (2)

• Check boundaries of test and data areas
• Verify completion of transmitted files
• Application should not require root access
• Determine what transactions should appear in log
  file

54
Unauthorized Access (3)

• Program controls so only applicable records exist
  and ensure they havent been altered
• When practical, use third party testers
• Write protect installation disks
• Separate reporting of financial transactions
  involving receipts and payments

55
Privacy and Confidentiality

• Print Sensitive Information on appropriate
  reports
• Do not store personal information in cookies
• Do not use persistent cookies

56
Production Implementation

• Ensure that all COTS software has latest security
  patches
• Remove installation programs from system
• Remove non-essential programs
• Verify operating system and relevant COTS
  products have latest upgrades and patches

57
Production Implementation (2)

• Check runtime privileges
• Review backup and restore procedures including
  checkpoint restart
• Backup immediately after installation
• Only implement systems that have had IVV and
  have been certified and accredited

58
GAO Findings

• For security program management, we identified
  weaknesses for all 24 agencies in 2002.
• Establishing a strong security management
  program requires that agencies take a
  comprehensive approach that involves both (1)
  senior agency program managers who understand
  which aspects of their missions are the most
  critical and sensitive and (2) technical experts
  who know the agencies systems and can suggest
  appropriate technical security control
  techniques.

GAO-03-303T (11/19/02) Computer Security
Progress Made, But Critical Federal Operations
and Assets Remain at Risk
59
Responsibilities

• Manager/Director
• Contract Officer
• Project Officer/Manager
• Budget Specialist
• Security Officer
• Application Developer/Programmer

• Database Manager
• LAN/System Administrators
• Application Trainers/Instructors
• IVV/Test Team
• IT Security Section Staff

60
Responsibilities

• Manager/Director
• Contract Officer
• Project Officer/Manager
• Budget Specialist
• Security Officer
• Application Developer/Programmer

• Database Manager
• LAN/System Administrators
• Application Trainers/Instructors
• IVV/Test Team
• IT Security Section Staff

61
Responsibilities

• Manager/Director
• Contract Officer
• Project Officer/Manager
• Budget Specialist
• Security Officer
• Application Developer/Programmer

• Database Manager
• LAN/System Administrators
• Application Trainers/Instructors
• IVV/Test Team
• IT Security Section Staff

62
Responsibilities

• Manager/Director
• Contract Officer
• Project Officer/Manager
• Budget Specialist
• Security Officer
• Application Developer/Programmer

• Database Manager
• LAN/System Administrators
• Application Trainers/Instructors
• IVV/Test Team
• IT Security Section Staff

63
NIST References

• URL for NIST Special Publications
  http//csrc.nist.gov/publications/nistpubs/index.h
  tml.
• 7 SP 800-34, Contingency Planning for Information
  Technology Systems, June 2002
• SP 800-28, Guidelines on Active Content and
  Mobile Code, October 2001.SP 800-27, Engineering
  Principles for Information Technology Security (A
  Baseline for Achieving Security), June 2001.
• SP 800-26, Security Self-Assessment Guide for
  Information Technology Systems, November 2001.
• SP 800-18, Guide for Developing Security Plans
  for Information Technology Systems, December
  1998.
• SP 800-14, Generally Accepted Principles and
  Practices for Securing Information Technology
  Systems, September 1996
• SP 500-153, Guide to Auditing for Controls and
  Security A System Development Life Cycle
  Approach, April 1988

64
Other References

• NIH IT Security Web Site URL http//www.cit.nih.g
  ov/security.html
• Office of Management and Budget (OMB) Circular
  No. A-130, "Management of Federal Information
  Resources".
• URL http//www.whitehouse.gov/omb/circulars/a130/
  a130trans4.html.
• Federal Information Processing Standards
  Publication 73 (FIPS PUB 73) Guidelines for
  Security of Computer Applications, Washington, DC
  GPO, June 1980. URL http//csrc.nist.gov/publicat
  ions/fips/index.html.
• U.S Customs Service, System Development Life
  Cycle (SDLC) Handbook, HB 5500-07, October 1998.
  URL http//www.customs.ustreas.gov/contract/mode
  rn/sdlcpdfs/. This handbook contains detail
  information about the System Development Life
  Cycle.
• HHS Automated Information Systems Security
  Program (AISSP) Handbook
• URL http//irm.cit.nih.gov/policy/aissp.html
• Carnegie Mellon Software Engineering Institute
  (SEI) Capability Maturity Model 2002. URL
  http//www.sei.cmu.edu/cmm/

65
Programming Advice

• Best Practices for Secure Web Development
• URL http//www.securitymap.net/sdm/docs/secure-pr
  ogramming/Secure-Web-Development.pdf
• W3C, The World Wide Web Security FAQ, 4
  February 2002.
• URL http//www.w3.org/Security/faq/www-security-f
  aq.html
• Carnegie Mellon Software Engineering Institute
  CERT Coordination Center, Understanding
  Malicious Content Mitigation for Web Developers,
  2 February 2000.
• URL http//www.cert.org/tech_tips/malicious_code_
  mitigation.html
• Netscape Communications Corporation, JavaScript
  Security, 27 May 1999.
• URL http//developer.netscape.com/docs/manuals/js
  /client/jsguide/sec.htm
• Sun Microsystems, Java Web Server Security
  Problems, 15 February 2000.
• URL http//www.sun.com/software/jwebserver/faq/jws
  ca-2000-02.html
• Apache Software Foundation, Apache Cross Site
  Scripting Info, 2 February 2000.
• URL http//www.apache.org/info/css-security

66
Microsoft Advice

• Microsoft Corporation, HOWTO Prevent Cross-Site
  Scripting Security Issues, 1 February 2000.
• URL http//support.microsoft.com/default.aspx?sci
  dkben-usQ252985
• Microsoft Corporation, Q253119 HOWTO Review ASP
  Code for CSSI Vulnerability, 2 February 2002.
• URL http//support.microsoft.com/support/kb/artic
  les/Q253/1/19.ASP
• Microsoft Corporation, Q253120 HOWTO Review
  Visual InterDev Generated Code for CSSI
  Vulnerability, 2 February 2002.
• URL http//support.microsoft.com/support/kb/artic
  les/Q253/1/20.ASP
• Microsoft Corporation, Q253121 HOWTO Review
  MTS/ASP Code for CSSI Vulnerability, 2 February
  2002.
• URL http//support.microsoft.com/support/kb/artic
  les/Q253/1/21.ASP

67
Articles

• Frank, Diane, Agencies Seek Security Metrics.
  Federal Computer Week, 19 June 2000. URL
  http//www.fcw.com/fcw/articles/2000/0619/pol-metr
  ics-06-19-00.asp
• Sirhal, Maureen, OMB orders agencies to report
  on computer security, 11 July 2002. URL
  http//www.govexec.com/dailyfed/0702/071102td2.htm
  
• Burris, Peter, and Chris King. A Few Good
  Security Metrics. METAGroup, Inc. 11 October
  2000. URL http//www.metagroup.com/metaview/mv03
  14/mv0314.html

68
Questions?