Embed Size (px)
Citation preview
May 2003
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 [email protected] 2-4458Larry Wlosinski, CDP, CISSP, GSEC [email protected] 2-4443
May 2003
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
May 2003
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
May 2003
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
May 2003
Protecting Information
No Power No Users No Network
Connection
May 2003
The Only Truly Secure Computer
May 2003
How Do We Give Away our Private Information?
People Steal It
We Give it away Unintentionally
We Give it away Intentionally
May 2003
Annual Number of Computer Viruses
1,798,872
7,638,012
184,2579,184-
1,000,000
2,000,000
3,000,000
4,000,000
5,000,000
6,000,000
7,000,000
8,000,000
9,000,000
1999 2000 2001 2002
An
nu
al N
um
be
r o
f V
iru
se
s
May 2003
Annual Number of Web Page Defacements
7,629
4,195
30,388
0
5000
10000
15000
20000
25000
30000
35000
1999 2000 2001
Year
Nu
mb
er
of
We
b P
ag
es
De
fac
ed
p
er
Ye
ar
May 2003
May 2003
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
May 2003
How Things Have ChangedHardware
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
May 2003
How Things Have ChangedSoftware 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.
May 2003
How Things Have ChangedSystem 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
May 2003
How Things Have ChangedIT Security
Subject/Topic 1970s NowUsers Limited to those with direct connect
terminalsAnyone 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
May 2003
How Things Have ChangedIT 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.
May 2003
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 What’s that? Authorization to Process (MOU) None
May 2003
Documentation Concerns1. User access privileges2. Deregistration - Implement
procedures to control access when staff leave
3. Operations, system, user, and programming - documentation is to be kept current
4. Continuity of Operations
May 2003
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
May 2003
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)
May 2003
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
May 2003
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)
May 2003
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.”
May 2003
Phases of the SDLCNIST 800-30 HHS SLC Requirements
GuideISO/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
May 2003
Phase 1: Initiation Data Sensitivity Assessment Preliminary Risk Assessment
(RA) Review Solicitations (e.g.
Request for Proposals - RFPs)
May 2003
Phase 2: Development/Acquisition
Functional and Technical Features/Requirements
Staff background Checks Operational Practices Test Plans, Scripts, and Scenarios Security Controls in Specifications
May 2003
Phase 2: Development/Acquisition (2)
In-House Concerns: Security features Development process Changing requirements Threats Vulnerabilities Malicious insiders
May 2003
Phase 2: Development/Acquisition (3)
COTS Applications Operational Practices
System Security Plan (SSP) Contingency Plan (CP) Awareness Training Documentation
May 2003
Phase 3: Implementation Testing and Accreditation
Test Data Test unit, subsystem, and entire
system Technical evaluation
Security Management - administrative controls and safeguards
May 2003
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
May 2003
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
May 2003
Phase 3: Implementation (4)
Backup, restore, and restart instructions and procedures
Implementation backups (could server as benchmark)
Ensure implementation of only approved/accredited systems
May 2003
Phase 4: Operations/Maintenance
Backup and restoration parameters Performing backups Support training classes Cryptography keys User administration and access
privileges Audit logs
May 2003
Phase 4: Operations/Maintenance (2)
Log file analysis Security software Physical protection Off-site storage Output distribution Software & hardware warrantees Registration/Deregistration
May 2003
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
May 2003
Phase 5: Disposal Storage of cryptographic keys Legal requirements of records
retention Archiving federal information Sanitize media
May 2003
Performance Measures - Why
Quantify Benefit/Cost Analyses Budget Monitoring Quality Control/Improvement Regulatory Reporting
May 2003
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
May 2003
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
May 2003
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.
May 2003
BREAK
May 2003
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
May 2003
Web Application Security Vulnerabilities
1. Un-validated parameters2. Broken Access Controls3. Broken Account and Session
Management4. Cross-Site Scripting Flaws5. Buffer Overflows
May 2003
Web Application Security Vulnerabilities (Cont.)
1. Command Injection Flaws2. Error Handling Problems3. Insecure Use of Cryptography4. Remote Administration Flaws5. Web and Application Server
Mis-configurations
May 2003
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
May 2003
Protection Against Parameter Tampering
1. Data type restrictions (I.e. string, integer, real, etc.)
2. Permit only the allowed character set
3. Maximum and minimum length checking
4. Check whether Null is allowed
May 2003
Protection Against Parameter Tampering (Cont.)
1. Check whether parameter is required or not
2. Check whether duplicates are allowed
3. Numeric range checking4. Allow only specific legal values5. Allow only specific patterns
May 2003
Programming Concerns and Safeguards
Access Controls System and Data Integrity Unauthorized Access Privacy and Confidentiality Production Implementation Documentation
May 2003
Access Controls1. Require a User ID and password2. SQL command concerns3. Allow on valid accounts4. Encrypt passwords5. Use strong passwords6. Beware of disks/CDs in reader7. Do not program as administrator8. Single Sign-On
May 2003
System and Data Integrity1. Check contractor disks2. Software upgrades and patches3. Program for versatility4. Allow only acceptable parameters5. Restrict use of configuration files6. Do not store parameters in system
registers7. Edit data for size and value
May 2003
System and Data Integrity (2)1. Avoid using pathnames2. Allow only acceptable error codes3. Don’t retrieve data from public files4. Don’t use undocumented, seldom used, or
unusual functions or commands5. Control quantity and size of files6. Limit number of processes running at one time7. Web – update cookies via on-line access8. Encrypt sensitive or critical data
May 2003
Unauthorized Access1. Avoid commands that hackers can
find in log files2. Avoid using hidden fields3. Do not store sensitive data on web
control pages4. Avoid using cookies5. Use compiled code in production
May 2003
Unauthorized Access (2)
1. Check boundaries of test and data areas
2. Verify completion of transmitted files
3. Application should not require root access
4. Determine what transactions should appear in log file
May 2003
Unauthorized Access (3)1. Program controls so only applicable
records exist and ensure they haven’t been altered
2. When practical, use third party testers
3. Write protect installation disks4. Separate reporting of financial
transactions involving receipts and payments
May 2003
Privacy and Confidentiality
1. Print ‘Sensitive Information’ on appropriate reports
2. Do not store personal information in cookies
3. Do not use persistent cookies
May 2003
Production Implementation1. Ensure that all COTS software has
latest security patches2. Remove installation programs from
system3. Remove non-essential programs4. Verify operating system and
relevant COTS products have latest upgrades and patches
May 2003
Production Implementation (2)
1. Check runtime privileges2. Review backup and restore
procedures including checkpoint restart
3. Backup immediately after installation4. Only implement systems that have
had IV&V and have been certified and accredited
May 2003
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”
May 2003
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
May 2003
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
May 2003
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
May 2003
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
May 2003
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
May 2003
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/
May 2003
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
May 2003
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
May 2003
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
May 2003
Questions?
