Software Application Control and SDLC

Transcription

1 Software Application Control and SDLC Albert J. Marcella, Jr., Ph.D., CISA, CISM 1 The most effective way to achieve secure software is for its development life cycle processes to rigorously conform to secure development, deployment, and sustainment principles and practices. Organizations that have adopted a secure software development life cycle (SDLC) process have found almost immediately upon doing so that they have begun finding many more vulnerabilities and weaknesses in their software early enough in the SDLC that they are able to eradicate those problems at an acceptable cost. Moreover, as such secure practices become second nature over time, these same developers start to notice that they seldom introduce such vulnerabilities and weaknesses into their software in the first place. Albert J. Marcella, Jr., Ph.D., CISA, CISM 2 1

2 A proactive quality management strategy is to have multiple defect removal points in the software development life cycle. The more defect removal points there are, the more likely one is to find problems right after they are introduced, enabling problems to be more easily fixed and the root cause to be more easily determined and addressed. Albert J. Marcella, Jr., Ph.D., CISA, CISM 3 Each defect removal activity can be thought of as a filter that removes some percentage of defects that can lead to vulnerabilities from the software product. The more defect removal filters there are in the software development life cycle, the fewer defects that can lead to vulnerabilities will remain in the software product when it is released. More importantly, early measurement of defects enables the organization to take corrective action early in the software development life cycle. Albert J. Marcella, Jr., Ph.D., CISA, CISM 4 2

3 Albert J. Marcella, Jr., Ph.D., CISA, CISM 5 Each time defects are removed, they are measured. Every defect removal point becomes a measurement point. Defect measurement leads to something even more important than defect removal and prevention: it tells teams where they stand against their goals, helps them decide whether to move to the next step or to stop and take corrective action, and indicates where to fix their process to meet their goals Albert J. Marcella, Jr., Ph.D., CISA, CISM 6 3

4 The development team should consider the following questions when managing defects: 1. What type of defects lead to security vulnerabilities? 2. Where in the software development life cycle should defects be measured? 3. What work products should be examined for defects? 4. What tools and methods should be used to measure the defects? 5. How many defects can be removed at each step? 6. How many estimated defects remain after each removal step? Albert J. Marcella, Jr., Ph.D., CISA, CISM 7 Coding Standards End users, designers and developers are expected to maintain standards for the development of the application/software source code. Their purpose is to increase application/software quality, by proper commenting, limiting module complexity, systematic naming conventions, and other techniques. Such standards are often dependent on the choice of programming language. Albert J. Marcella, Jr., Ph.D., CISA, CISM 8 4

5 Coding Standards are NOTmerely a way of enforcing naming conventions on your code. Coding Standards enforcement ISstatic analysis of source code for: 1. Certain rules and patterns to detect problems automatically. 2. Based on the knowledge collected over many years by industry experts. 3. Virtual code review or peer review by industry respected language experts. Albert J. Marcella, Jr., Ph.D., CISA, CISM 9 System Development Tools What is Gantt Chart? Popular tool used to plan and schedule time relationships among project activities. Albert J. Marcella, Jr., Ph.D., CISA, CISM 10 5

6 Albert J. Marcella, Jr., Ph.D., CISA, CISM 11 PERT The Program Evaluation and Review Technique (PERT) is a network model that allows for randomness in activity completion times. An activity is a task that must be performed and an event is a milestone marking the completion of one or more activities. Before an activity can begin, all of its predecessor activities must be completed. Albert J. Marcella, Jr., Ph.D., CISA, CISM 12 6

7 PERT Diagram Albert J. Marcella, Jr., Ph.D., CISA, CISM 13 Software Metrics Metrics are only useful if you know what to do with the answers you get. Albert J. Marcella, Jr., Ph.D., CISA, CISM 14 7

8 A software metric is like a thermometer. The fact that you measure something at 98.6 F doesn't mean anything until you know what the normal temperature is. A temperature of 98.6 is good for body temperature but really bad for ice cream. 13 Albert J. Marcella, Jr., Ph.D., CISA, CISM 15 Examples of Application Security Metrics 2 Process Metrics Is a SDL Process used? Are security gates enforced? Secure application development standards and testing criteria? Security status of a new application at delivery (e.g., % compliance with organizational security standards and application system requirements). Existence of developer support website (FAQ's, Code Fixes, lessons learned, etc.)? % of developers trained, using organizational security best practice technology, architecture and processes Management Metrics % of applications rated business-critical that have been tested. % of applications which business partners, clients, regulators require be certified. Average time to correct vulnerabilities (trending). % of flaws by lifecycle phase. % of applications using centralized security services. Business impact of critical security incidents. Albert J. Marcella, Jr., Ph.D., CISA, CISM 16 8

9 Examples of Application Security Metrics 2 Vulnerability Metrics Number and criticality of vulnerabilities found. Most commonly found vulnerabilities. Reported defect rates based on security testing (per developer/team, per application) Root cause of Vulnerability Recidivism. % of code that is re-used from other products/projects % of code that is third party (e.g., libraries) Results of source code analysis: Vulnerability severity by project, by organization Vulnerabilities by category by project, by organization Vulnerability +/- over time by project % of flaws by lifecycle phase (based on when testing occurs) Albert J. Marcella, Jr., Ph.D., CISA, CISM 17 Software Assurance Maturity Model Albert J. Marcella, Jr., Ph.D., CISA, CISM 18 9

10 Software Assurance Maturity Model (SAMM) This model was developed to aid organizations in formulating and implementing a strategy for software security. It is maintained through the OpenSAMMProject as part of the Open Web Application Security Project (OWASP). This model is designed to be tailored to the specific risk environment each organization faces. Albert J. Marcella, Jr., Ph.D., CISA, CISM 19 The model focuses on four core business functions that are involved in software development: 1. Governance: processes and activities related to the way in which an organization manages its software development. 2. Construction: processes and activities related to the way an organization defines the goals for and the creation of software within development projects. 3. Verification: processes and activities related to the way an organization validates and tests artifacts created throughout software development. 4. Deployment: processes and activities related to the way an organization manages the operational release of software it creates to a runtime environment. Albert J. Marcella, Jr., Ph.D., CISA, CISM 20 10

11 Software Assurance Maturity Model (SAMM) Albert J. Marcella, Jr., Ph.D., CISA, CISM 21 Software Security Framework (SSF) Albert J. Marcella, Jr., Ph.D., CISA, CISM 22 11

12 Software Security Framework (SSF) 1. Governance: practices that help organize, manage, and measure a software security initiative 2. Intelligence: practices for collecting corporate knowledge used in carrying out software security activities throughout the organization 3. SDL Touchpoints: practices associated with analysis and assurance of particular software development artifacts and processes 4. Deployment: practices linked to network security and software maintenance organizations Albert J. Marcella, Jr., Ph.D., CISA, CISM 23 Integrating Security into the Software Life Cycle Albert J. Marcella, Jr., Ph.D., CISA, CISM 24 12

13 Systems Development Life Cycle Project Initiation Classify the data that the system will process Determine if sensitive data absolutely must be collected and/or stored Perform risk analysis based on known requirements & classification of data Develop an initial IT System Security Plan Project Definition Identify, document & incorporate security control requirements into IT System design specifications Develop evaluation procedures to validate that security controls Update the IT System Security Plan to include controls Implementation Execute the evaluation procedures Conduct a risk assessment to evaluate overall system risk Update the IT System Security Plan to include controls Disposition Require that data retention schedules are adhered to Require that electronic media is sanitized prior to disposal Albert J. Marcella, Jr., Ph.D., CISA, CISM New Development Push security involvement to the front end of development: Security Design (for sensitive systems) Encrypted communication channels Sensitive information shall not be stored in hidden fields Application Development Application-based authentication shall be performed for access to data that is not considered publicly accessible Support inactivity timeouts on user sessions Data storage must be separated from the application interface Validate all input irrespective of source, focus on server-side Implement a default deny policy for access control Use the least set of privileges required for processing Internal testing must include one of: penetration testing, fuzz testing or source code auditing Clear cached and temporary data upon exit Production and Maintenance Scan internet-facing sensitive applications periodically for vulnerabilities Albert J. Marcella, Jr., Ph.D., CISA, CISM 13

14 Applications Procurement Work to incorporate language into contracts that includes: General Personnel, Security Training, Background Checks Vulnerabilities, Risks and Threats Application Development Development Environment Secure coding, Configuration management, Distribution, Disclosure, Evaluation Testing General, Source Code, Vulnerability and Penetration Test Patches and Updates Tracking Security Issues Delivery Of The Secure Application Self Certification No Malicious Code Security Acceptance And Maintenance Acceptance Investigating Security Issues Albert J. Marcella, Jr., Ph.D., CISA, CISM Source: Legacy Applications Periodic application vulnerability scanning Strong configuration management If vulnerabilities are identified: Each application may have specific challenges Case by case analysis may reveal options: Easy fix Virtualization Host based intrusion prevention Application firewall technology Third party integration Other technology Albert J. Marcella, Jr., Ph.D., CISA, CISM 14

15 Security enhancement of the SDLC process mainly involves the adaptation or augmentation of existing SDLC activities, practices, and checkpoints, and in a few instances, it may also entail the addition of new activities, practices, or checkpoints. Albert J. Marcella, Jr., Ph.D., CISA, CISM 29 The key elements of a secure software life cycle process are: 1. Security criteria in all software life cycle checkpoints (both at the entry of a life cycle phase and at its exit) 2. Adherence to secure software principles and practices 3. Adequate requirements, architecture, and design 4. Secure coding practices 5. Secure software integration/assembly practices 6. Security testing practices that focus on verifying the dependability, trustworthiness, and sustainability of the software being tested 7. Secure distribution and deployment practices and mechanisms 8. Secure sustainment practices 9. Supportive tools 10. Secure software configuration management systems and processes 11. Security-knowledgeable software professionals 12. Security-aware project management 13. Upper management commitment to production of secure software 6 Albert J. Marcella, Jr., Ph.D., CISA, CISM 30 15

16 General Principles (Control Considerations) for Secure Software Development The following principles should guide the development of secure software, including all decisions made in producing the deliverables at every phase of the software life cycle. Albert J. Marcella, Jr., Ph.D., CISA, CISM Minimize the number of high-consequence targets The software should contain as few high-consequence targets (critical and trusted components) as possible. High-consequence targets are those that represent the greatest potential loss if the software is compromised and therefore require the most protection from attack. Critical and trusted components are high-consequence because of the magnitude of impact if they are compromised. This principle contributes to trustworthiness and, by its implied contribution to smallness and simplicity, also to dependability. Albert J. Marcella, Jr., Ph.D., CISA, CISM 32 16

17 2. Don t expose vulnerable and high-consequence components The critical and trusted components the software contains should not be exposed to attack. In addition, known vulnerable components should also be protected from exposure because they can be compromised with little attacker expertise or expenditure of effort and resources. This principle contributes to trustworthiness. Albert J. Marcella, Jr., Ph.D., CISA, CISM Deny attackers the means to compromise The software should not provide the attacker with the means by which to compromise it. Such means include exploitable weaknesses and vulnerabilities, dormant code, backdoors, etc. Also, provide the ability to minimize damage, recover, and reconstitute the software as quickly as possible following a compromising (or potentially compromising) event to prevent greater compromise. Albert J. Marcella, Jr., Ph.D., CISA, CISM 34 17

18 3. Deny attackers the means to compromise In practical terms, this will require building in the means to monitor, record, and react to how the software behaves and what inputs it receives. This principle contributes to dependability, trustworthiness, and resilience. Albert J. Marcella, Jr., Ph.D., CISA, CISM Always assume the impossible will happen Events that seem to be impossible rarely are. They are often based on an expectation that something in a particular environment is highly unlikely to exist or to happen. If the environment changes or the software is installed in a new environment, those events may become quite likely. The software should be designed to guard against both likely and unlikely events. Albert J. Marcella, Jr., Ph.D., CISA, CISM 36 18

19 5. Never make blind assumptions Validate every assumption made by the software or about the software before acting on that assumption. 6. Security software is not the same as secure software Just because software performs information securityrelated functions does not mean the software itself is secure. Software that performs security functions is just as likely to contain flaws and bugs as other software. Albert J. Marcella, Jr., Ph.D., CISA, CISM 37 Software Assurance Albert J. Marcella, Jr., Ph.D., CISA, CISM 38 19

20 The main objective of software assurance is to ensure that the processes, procedures, and products used to produce and sustain the software conform to all requirements and standards specified to govern those processes, procedures, and products. Software security and secure software are often discussed in the context of software assurance. Software assurance in its broader sense refers to the assurance of any required property of software. Albert J. Marcella, Jr., Ph.D., CISA, CISM 39 An increasingly agreed-upon approach for assuring the security of software is the software security assurance case, which is intended to provide justifiable confidence that the software under consideration: 1. Is free of vulnerabilities; 2. Functions in the intended manner, and this intended manner does not compromise the security or any other required properties of the software, its environment, or the information it handles; and 3. Can be trusted to continue operating dependably under all anticipated circumstances, including anomalous and hostile environmental and utilization circumstances which means that those who build the software need to anticipate such circumstances and design and implement the software to be able to handle them gracefully. Albert J. Marcella, Jr., Ph.D., CISA, CISM 40 20