slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Integrating Security into the Systems Development Life Cycle (SDLC) May 22, 2003 Center for Information Technology PowerPoint Presentation
Download Presentation
Integrating Security into the Systems Development Life Cycle (SDLC) May 22, 2003 Center for Information Technology

Loading in 2 Seconds...

play fullscreen
1 / 68

Integrating Security into the Systems Development Life Cycle (SDLC) May 22, 2003 Center for Information Technology - PowerPoint PPT Presentation


  • 438 Views
  • Uploaded on

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@nih.gov 2-4458 Larry Wlosinski, CDP, CISSP, GSEC wlosinsl@mail.nih.gov 2-4443

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Integrating Security into the Systems Development Life Cycle (SDLC) May 22, 2003 Center for Information Technology' - ryanadan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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, CISSPmf28c@nih.gov 2-4458

Larry Wlosinski, CDP, CISSP, GSECwlosinsl@mail.nih.gov 2-4443

agenda 1 st half
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
agenda 2 nd half
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
course objectives
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
protecting information
Protecting Information
  • No Power
  • No Users
  • No Network Connection
how do we give away our private information
How Do We Give Away our Private Information?
  • People Steal It
  • We Give it away Unintentionally
  • We Give it away Intentionally
slide9

Annual Number of

Web Page Defacements

what is security
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/aissp.html

how things have changed hardware

Component

1970s

Now

User Interface

Mainframe terminals

Desktops, Laptops, PDAs, Cell Phones

Connection

Direct Connection

Direct connection, LANs, WAN, wireless, ISDN, DSL

Monitors

Monochrome character display using vacuum tubes

Full color pixel-based matrix display, PDAs

Unit of storage capacity

Kilobytes and megabytes

Gigabytes and terabytes

Processor Speed

Kilobytes per second

Gigabits per second

Processor

Sequential processing

Multitasking/multiprocessing

Storage interface

80-column hole-punch cards

Desktops, workstations, terminals, laptops, wireless devices

Storage Media

Magnetic Tapes

Floppy disks, Hard drives, CDs, CDRs, CDRW, DVDR, Zip drives, Dongle

How Things Have ChangedHardware
how things have changed software and data

Area of Concern

1970s

Now

Operating System

Mainframe Specific: IBM, Unisys, Honeywell, HP, etc.

Microsoft (2000/XP), UNIX (e.g. Solaris, SGI, AIX), Linux, MAC OS X

Type of Data

Characters/Text

Text, graphics, audio, video, IM, IRC, etc.

Word Processor

N/A – Manual typewriter

Word, WordPerfect, AmiPro

Calculations

N/A - Paper, Calculators

Spreadsheet (e.g. Excel, Lotus 1-2-3)

Scheduling

N/A – Paper calendar

Outlook, GroupWise

Presentations

N/A - Special order clear slides

PowerPoint

Music

N/A - Radio

MP3 files

Architecture design

N/A - Paper blueprints used

CAD software

Video

N/A – TV

Stored and real-time AVI, WAV files; cameras on desktop, doorways, etc.

Pictures

N/A – Camera

Digital files

Programming Language

COBOL

Visual Basic, Java, HTML, etc.

How Things Have ChangedSoftware and Data
how things have changed system development life cycle

Phase

1970s

Now

Initiation

Management initiative

Business Case Studies, Cost/Benefit Analysis

Development/Acquisition

Programmers

Managers, programmers, web masters, users

Implementation

Programmers work with computer operations

Many people: managers, programmers, web master, LAN administrators, system administrators, end user, security staff.

Operations/Maintenance

Computer center

LAN and system administrators, users, automatic jobs/bots

Disposal

Simply throw away [It was difficult to access data on tape]

Proper media disposal mandatory

How Things Have ChangedSystem Development Life Cycle
how things have changed it security

Subject/Topic

1970s

Now

Users

Limited to those with direct connect terminals

Anyone on the Internet

System architecture

Single mainframe (terminals in star configuration)

Many interconnected networks of various configurations

System Access

Only required a terminal with direct wiring

Network access with User ID, password, authentication, single sign-on

Data Connection

Clear text

Clear and encrypted

Data Availability

By request

Available on the Internet

Access Concerns

Internal access via terminal at desk

Internal access, anyone on LAN, Internet users

Data security

Tape library

Data on disks, CDs, hard drive, laptops, PDAs, and other media

Data storage

Clear text

Compressed, encrypted, large volume

Communications protocols

Vendor specific for terminal access

Many: HTTP, FTP, SSL, Telnet, SSH, IMAP, IDENT, UDP, TCP, etc.

Environment protection

Building, rooms, lock boxes, fire suppressors

Same plus firewalls (network and personal), IDS, routers, anti-virus software

How Things Have ChangedIT Security
how things have changed it security cont

Subject/Topic

1970s

Now

System software

Mainframe specific

Various operating systems, utilities, software packages

Software problem resolution

Mainframe vendors

Anyone who supplies software [upgrades, patches, help desk]

Access methods

Power up terminal

Direct connection to network, dial-in, hacker attacks via Internet, DSL, VPNs

Awareness

Primarily limited to computer center staff

Everyone must be diligent

Security software

Mainframe utilities

Operating system configuration, anti-virus, vulnerability scanners, IDS, communications monitoring

Security audit activities

Audit computer center

Audit network, computer center, applications, communication servers, Internet activity, penetration testing, etc.

Threat Source

Anyone who has access to the computer center

Anyone who has access to the computer center, desktop, and the Internet.

How Things Have ChangedIT Security (Cont.)
documentation concerns what we learned from y2k
Documentation Concerns(What we learned from Y2K)

Required DocumentationFindings

  • 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 What’s that?
  • Authorization to Process (MOU) None
documentation concerns
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
security certification
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

system accreditation
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)
key documents in accreditation and certification
Key Documents in Accreditation and Certification
  • System Design Reviews (SDRs)
  • Risk Assessments (RAs)
  • System Security Plans (SSPs)
  • Interconnection Agreements
  • Security Test and Evaluation (ST&E) Reports
  • Continuity Of Operation Plans (COOPs)
  • Corrective Action Plans (CAPs)
  • Disaster Recovery Plan (DRP)
  • Certifier’s Statement and the Accreditation Letter
applicable it security legislation and regulations
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)
what is the sdlc
What is the SDLC?

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

phases of the sdlc

NIST 800-30

HHS SLC Requirements Guide

ISO/IEC 12207

1. Initiation

System Concept Development

Investment Analysis

Planning

Acquisition

Requirements

Requirements Analysis

Design

Design and Engineering

2. Development or Acquisition

Development

Development

3. Implementation

Integration and Test

Testing

Implementation

Implementation

4. Operations or Maintenance

Operations and Maintenance

Operations and Maintenance

5. Disposition

Disposition

Retirement

Phases of the SDLC
phase 1 initiation
Phase 1: Initiation
  • Data Sensitivity Assessment
  • Preliminary Risk Assessment (RA)
  • Review Solicitations (e.g. Request for Proposals - RFPs)
phase 2 development acquisition
Phase 2: Development/Acquisition
  • Functional and Technical Features/Requirements
  • Staff background Checks
  • Operational Practices
  • Test Plans, Scripts, and Scenarios
  • Security Controls in Specifications
phase 2 development acquisition 2
Phase 2: Development/Acquisition (2)

In-House Concerns:

  • Security features
  • Development process
  • Changing requirements
  • Threats
  • Vulnerabilities
  • Malicious insiders
phase 2 development acquisition 3
Phase 2: Development/Acquisition (3)
  • COTS Applications
  • Operational Practices
    • System Security Plan (SSP)
    • Contingency Plan (CP)
    • Awareness
    • Training
    • Documentation
phase 3 implementation
Phase 3: Implementation
  • Testing and Accreditation
    • Test Data
    • Test unit, subsystem, and entire system
    • Technical evaluation
  • Security Management - administrative controls and safeguards
phase 3 implementation 2
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
phase 3 implementation 3
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
phase 3 implementation 4
Phase 3: Implementation (4)
  • Backup, restore, and restart instructions and procedures
  • Implementation backups (could server as benchmark)
  • Ensure implementation of only approved/accredited systems
phase 4 operations maintenance
Phase 4: Operations/Maintenance
  • Backup and restoration parameters
  • Performing backups
  • Support training classes
  • Cryptography keys
  • User administration and access privileges
  • Audit logs
phase 4 operations maintenance 2
Phase 4: Operations/Maintenance (2)
  • Log file analysis
  • Security software
  • Physical protection
  • Off-site storage
  • Output distribution
  • Software & hardware warrantees
  • Registration/Deregistration
phase 4 operations maintenance 3
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
phase 5 disposal
Phase 5: Disposal
  • Storage of cryptographic keys
  • Legal requirements of records retention
  • Archiving federal information
  • Sanitize media
performance measures why
Performance Measures - Why
  • Quantify Benefit/Cost Analyses
  • Budget Monitoring
  • Quality Control/Improvement
  • Regulatory Reporting
performance measures
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
tracking security costs
Tracking Security Costs
  • Background checks of employees
  • Developing security requirements for the project
  • Developing RFA’s
  • Reviewing RFP’s
  • Developing contingency program
  • Back-up processing
tracking security costs 2
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.
risks
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
web application security vulnerabilities
Web Application Security Vulnerabilities
  • Un-validated parameters
  • Broken Access Controls
  • Broken Account and Session Management
  • Cross-Site Scripting Flaws
  • Buffer Overflows
web application security vulnerabilities cont
Web Application Security Vulnerabilities (Cont.)
  • Command Injection Flaws
  • Error Handling Problems
  • Insecure Use of Cryptography
  • Remote Administration Flaws
  • Web and Application Server Mis-configurations
common programming errors
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
protection against parameter tampering
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
protection against parameter tampering cont
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
programming concerns and safeguards
Programming Concerns and Safeguards
  • Access Controls
  • System and Data Integrity
  • Unauthorized Access
  • Privacy and Confidentiality
  • Production Implementation
  • Documentation
access controls
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
system and data integrity
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
system and data integrity 2
System and Data Integrity (2)
  • Avoid using pathnames
  • Allow only acceptable error codes
  • Don’t retrieve data from public files
  • Don’t 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
unauthorized access
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
unauthorized access 2
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
unauthorized access 3
Unauthorized Access (3)
  • Program controls so only applicable records exist and ensure they haven’t been altered
  • When practical, use third party testers
  • Write protect installation disks
  • Separate reporting of financial transactions involving receipts and payments
privacy and confidentiality
Privacy and Confidentiality
  • Print ‘Sensitive Information’ on appropriate reports
  • Do not store personal information in cookies
  • Do not use persistent cookies
production implementation
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
production implementation 2
Production Implementation (2)
  • Check runtime privileges
  • Review backup and restore procedures including checkpoint restart
  • Backup immediately after installation
  • Only implement systems that have had IV&V and have been certified and accredited
gao findings
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”

responsibilities
Manager/Director

Contract Officer

Project Officer/Manager

Budget Specialist

Security Officer

Application Developer/Programmer

Database Manager

LAN/System Administrators

Application Trainers/Instructors

IV&V/Test Team

IT Security Section Staff

Responsibilities
responsibilities60
Manager/Director

Contract Officer

Project Officer/Manager

Budget Specialist

Security Officer

Application Developer/Programmer

Database Manager

LAN/System Administrators

Application Trainers/Instructors

IV&V/Test Team

IT Security Section Staff

Responsibilities
responsibilities61
Manager/Director

Contract Officer

Project Officer/Manager

Budget Specialist

Security Officer

Application Developer/Programmer

Database Manager

LAN/System Administrators

Application Trainers/Instructors

IV&V/Test Team

IT Security Section Staff

Responsibilities
responsibilities62
Manager/Director

Contract Officer

Project Officer/Manager

Budget Specialist

Security Officer

Application Developer/Programmer

Database Manager

LAN/System Administrators

Application Trainers/Instructors

IV&V/Test Team

IT Security Section Staff

Responsibilities
nist references
NIST References
  • URL for NIST Special Publications: http://csrc.nist.gov/publications/nistpubs/index.html.
    • 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
other references
Other References
  • NIH IT Security Web Site URL: http://www.cit.nih.gov/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/publications/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/modern/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/
programming advice
Programming Advice
  • “Best Practices for Secure Web Development”
    • URL: http://www.securitymap.net/sdm/docs/secure-programming/Secure-Web-Development.pdf
  • W3C, “The World Wide Web Security FAQ”, 4 February 2002.
    • URL: http://www.w3.org/Security/faq/www-security-faq.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/jwsca-2000-02.html
  • Apache Software Foundation, “Apache Cross Site Scripting Info”, 2 February 2000.
    • URL: http://www.apache.org/info/css-security
microsoft advice
Microsoft Advice
  • Microsoft Corporation, “HOWTO: Prevent Cross-Site Scripting Security Issues”, 1 February 2000.
    • URL: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q252985
  • Microsoft Corporation, “Q253119 HOWTO: Review ASP Code for CSSI Vulnerability”, 2 February 2002.
    • URL: http://support.microsoft.com/support/kb/articles/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/articles/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/articles/Q253/1/21.ASP
articles
Articles
  • Frank, Diane, “Agencies Seek Security Metrics.” Federal Computer Week, 19 June 2000. URL: http://www.fcw.com/fcw/articles/2000/0619/pol-metrics-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/mv0314/mv0314.html