Application Security

1. Application Security Houston, Texas July 26, 2007

2. Application SecurityIntroduction • W. Lee Schexnaider, CISSP • Currently Sr. Engineer at Symantec (formerly Bindview). Analyzing regulatory frameworks and best practices to map to common controls, compliance questions, and technical security checks. • Formerly Sr. Quality Engineer at NetIQ/Pentasafe. Tested security software for web servers, security policy management, Windows and Unix vulnerability management and change control. Business continuity and disaster recovery coordinator (NetIQ) and Lab Team member for R&D in Houston. • Software testing and documentation positions at Nucleus (energy trading), Lockheed-Martin (Air Force launch range scheduling), Argus (property valuation), CompuText (newspaper editorial, advertising, production, pagination) and various consulting positions. • Newspaper journalist at the Killeen Daily Herald (covered city government, police, fire and the Luby’s Cafeteria Massacre) and the Waco Tribune-Herald, (suburban city government, education, religion, features and the Branch Davidian Standoff.)

3. Current masters degree student in the online Information Assurance program at Capitol College in Maryland. • Bachelor of Science in Journalism from Texas A&M. • CISSP 2004 • American Red Cross training in disaster services and shelter management. Shelter manager during Hurricane Alicia (1983) and volunteer in Houston after Hurricane Katrina. • Currently working on a science fiction novel about the great Galveston hurricane of 1900.

4. Application Security This section of the CISSP CBK is composed of several main areas: • Software development and methods • System Development Lifecycle (SDLC) • Software vulnerabilities and malicious code. • Security controls for items such as databases, change control and applications

5. Applications SecurityExpectations From the Official (ISC)2 Guide to the CISSP CBK, 2007 • The principals related to designing secure information software. • Security and controls of the systems development process, application controls, change controls, data warehousing, data mining, knowledge-based systems, program interfaces, and concepts used to ensure data and application integrity, confidentiality and availability.

6. Applications SecurityExpectations • The knowledge, practices and principles for securing systems and applications during the processes known as lifecycle management. • The security and security controls that should be included within systems and application software. • The steps and security controls in the software lifecycle and change control process

7. Application SecurityExpectations • Concepts used to ensure data and software integrity, confidentiality and availability. • Malicious code and software, such as computer viruses • How malicious code can be introduced into the computing environment

8. Application SecuritySecure Software Development Challenges • Security is generally not the top priority in software development. Functionality and time to market are king. • Code may be written by “citizen” or “amateur” who are not schooled in secure coding techniques (Examples include Visual Basic or Visual Basic for Applications for interacting with Microsoft Office). • One-customer projects may prioritize features over security.

9. Application SecuritySecure Software Development Challenges • Lack of programmers with experience in secure coding. • Lack of quality assurance resources • Complexity of applications • Distributed applications • Internet exposure of application interfaces • Lack of implementation of standardized development procedures

10. Applications SecuritySoftware Development Methods Waterfall Method • Developed in the 1970s. • Features distinct phases that must be completed in order • Phases can have entry and exit criteria • Slow. Requires heavy planning and administration. May impede concurrent development activities

11. Application SecuritySoftware Development Methods Waterfall Method Steps • State requirements • Analyze requirements • Design a solution approach • Design a software framework for the solution • Develop code • Test (may include unit, integration and system tests) • Deploy • Post-implementation

12. Applications SecuritySoftware Development Methods Waterfall method • Seldom used in pure form in commercial software. • Mainly for “mission critical” applications where lives may be at stake (NASA, DOD)

13. Applications SecuritySoftware Development Methods Structured Program Development • Requires defined processes • Modular development • Each phase subject to reviews and approvals • Allows for security to be “baked” into the process

14. Applications SecuritySoftware Development Methods Spiral Method • Formalized in 1988. • Nested version of Waterfall method. • Type of iterative development using prototypes. • Helps with inevitable “feature creep”.

15. Application SecuritySoftware Development Methods Spiral Method Steps • Requirements are defined. • Preliminary design is completed. • Prototype is constructed and evaluated • Evaluation used to construct next prototype. • Risk analysis of project (may result in aborting the project). • Current prototype is evaluated. • Process is repeated until the prototype becomes an acceptable final product.

16. Application SecuritySoftware Development Methods Cleanroom • Developed in the 1990s • Based on chip fabrication • Prevent problems, rather than fixing bugs later • Predictive software development process

17. Application SecuritySoftware Development Methods Cleanroom method • More time is spent on design, rather than testing • May be used for critical applications that face a strict certification process • If risk considerations are addressed early, security becomes integrated, rather than tacked on.

18. Application SecuritySoftware Development Methods Joint Analysis Development • Team approach in a workshop-oriented environment. • Designed to enhance development for mainframes. Now used for rapid application and web development. • Direct communication between developers, subject experts, and end users.

19. Application SecuritySoftware Development Methods Rapid Application Development (RAD) • Determine user requirements and develop systems quickly. • Rapid prototyping • Can be so quick that design may be poor • Can use CASE tools • Developed in the 1980s

20. Application SecuritySoftware Development Methods Agile Software Development • Iterative sections or “timeboxes” • Each timebox is a minature software development process and includes design, requirements development and analysis, coding, testing and documentation. • Developed in the 1990s

21. Application SecuritySoftware Development Methods Agile Software Development • Examples include Extreme Programming, Crystal, Scrum, Feature Driven Development, Adaptive Software Development. • Agile is an adaptive software development process

22. Application SecuritySoftware Development Methods Computer-Aided Software Engineering (CASE) • Designed in the 1970s. • Use computers and computer utilities to help with design, development, implementation and maintenance of software. • Code and design reuse. • Code-generation, data modeling, configuration management tools.

23. Application SecuritySystem Development Lifecycle • SDLC: The scope of activities associated with a system, encompassing the system initialization, development and acquisition, implementation, operation and maintenance, and ultimately its disposal, which instigates another system initiation. - Official (ISC)2 Guide to the CISSP CBK, 2007

24. Application SecuritySystem Development Lifecycle • No industry-wide SDLC, companies can use one or a combination of methods. • Maybe required by regulations and implemented by best practices such as Cobit, ISO 17799/27001, NERC and the Capability Maturity Model (CMM). • Composed of phases.

25. Application SecuritySystem Development Lifecycle SDLC Phases: Project Initiation • Generation of documentation with the project objectives, scope, business needs, strategies, technical solutions using planning, analysis, brainstorming, risk analysis and management. This document is what must be approved by management.

26. Application SecuritySystem Development Lifecycle SDLC Phases: Project Initiation Security considerations • Does the information require special protection? • Will applications or systems risk exposure of sensitive information?

27. Application SecuritySystem Development Lifecycle SDLC Phases: Functional Design, Requirements and Planning • Develop requirements based on Project Initiation documentation. • Project Plan and design documents developed. • Phase may be skipped or merged with Project Initiation or System Design Specifications.

28. Application SecuritySystem Development Lifecycle SDLC Phases: Functional Design, Requirements and Planning Security considerations • High-level security considerations discussed. • Not necessarily how, but what. For example whether data in transit should be encrypted, not the encryption method.

29. Application SecuritySystem Development Lifecycle SDLC Phases: System Design Specifications • All activities related to designing the system and software. Architecture, interfaces, data input, data flow, output, and security features. • Also called Feature Specifications. • Tests or test cases defined.

30. Application SecuritySystem Development Lifecycle SDLC Phases: System Design Specifications Security considerations • Security requirements prioritized high enough so as not to be dropped if project is late. • Low-level definition of encryption and access control methods. • Security testing should be included.

31. Application SecuritySystem Development Lifecycle SDLC Phases: Software Development • Coding, testing and documentation are performed and completed. • The three elements may be performed in parallel or as distinct phases depending on the development methodology. • Coding may be performed in phases or development of parallel modules with stubs and drivers for testing.

32. Application SecuritySystem Development Lifecycle SDLC Phases: Software Development • Testing may be formalized in a phase after coding such as unit tests, unit integration tests, system tests and acceptance tests. • Testing may be conducted as soon as code is usable or hardware is installed. • Change control of code, tests and results and documentation is essential.

33. Application SecuritySystem Development Lifecycle SDLC Phases: Software Development Security considerations • Configuration management must ensure that broken or insecure code is not accidentally reused. • Security testing can include fuzzing, pen testing, verification of data encryption, and access control testing.

34. Application SecuritySystem Development Lifecycle SDLC Phases: Acceptance • This phase may be combined with Implementation and Installation. • This phase can include Certification and Accreditation. • This phase is mostly seen in government system development but may also be used in the commercial systems.

35. Application SecuritySystem Development Lifecycle SDLC Phases: Acceptance • Acceptance: An independent group develops test data and tests the code to ensure that it will function within the organization’s environment and that it meets all the functional and security requirements. • Certification and Accreditation: The process of evaluating the security stance of the software or system against a predetermined set of security standards or policies. Certification are the facts, accreditation is a management decision.

36. Application SecuritySystem Development Lifecycle SDLC Phases: Acceptance • A formal signed document with results of acceptance testing or certification criteria may be required to exit this phase. • Accreditation can be partial (changes needed in a certain timeframe) or full. • Management may accredit a system that has passed certification or refuse to accredit a system that has been certified.

37. Application SecuritySystem Development Lifecycle SDLC Phases: Acceptance Security considerations • Failure of this phase may kick system back to previous phases. • May require a formal meeting with stakeholders or customers. • An acceptable level of risk is determined. (You can’t test everything)

38. Application SecuritySystem Development Lifecycle SDLC Phases: Installation/Implementation • Application or system has been installed at customer (internal or external). • Installation may be in a customer test environment. Further customer testing/accreditation/certification may be required before the product is installed in a production environment (Example: Microsoft Patches, new version of Oracle) • Acceptance/Accreditation/Certification may be combined with this phase.

39. Application SecuritySystem Development Lifecycle SDLC Phases: Installation/Implementation Security considerations • New security issues may appear in customer environment. • Environment may have changed since requirements were developed. • Requirements may have been incorrect. • Product may not longer be marketable

40. Application SecuritySystem Lifecycle • System Lifecycle is a superset of SDLC and includes the development of the product, updates to the product (SDLC is rerun), operations, and end-of-life for the product. • Depending on the organization, two additional phases may be a part of the System Lifecycle or part of the SDLC: Operations/Maintenance and Disposal.

41. Application SecuritySystem Lifecycle Operations/Maintenance • System or application is in general use. • Performance is monitored. • System or application may be audited (Sarbanes-Oxley). • Full or partial SDLC may be rerun for patches, updates or changes to the environment.

42. Application SecuritySystem Lifecycle Operations/Maintenance Security considerations • Regulatory (FISMA, SOX,) internal policies or best practices (Cobit 4.0 to 4.1, PCI DSS v1.0 to 1.1) may change. • New vulnerabilities may be found in application or infrastructure (Windows, Unix, routers, switches) or in the product itself. • Funding may be reduced for maintenance/operations and product may not be patched, updated, monitored, and audited correctly or on a timely basis.

43. Application SecuritySystem Lifecycle Disposal/End-of-Life • Application or system may be uninstalled, replaced or retired. • This phase may include a post-mortem review for lessons learned. • Data may need to converted or imported for new applications. • Old data may need to be destroyed.

44. Application SecuritySystem Lifecycle Disposal/End-of-Life Security considerations • Data may need to be destroyed so it is not usable. • New Federal Rules of Civil Procedure that data and the means to access it may need to be kept for substantially longer than in the past. • Hardware (disk drives) may need special procedures to completely erase data or destroy the media.