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

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

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

12. 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

13. 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

14. 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

15. 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

16. 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.)

17. 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

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 (ST&E) Reports • Continuity Of Operation Plans (COOPs) • Corrective Action Plans (CAPs) • Disaster Recovery Plan (DRP) • Certifier’s 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 system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation.”

24. 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

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 RFA’s • Reviewing RFP’s • 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