The execution of Application Security roadmap should be carried out in five basic steps:
1. Build a plan: Recognize the potential dependencies between various initiatives, and integrated projects to produce a plan that is tailored for your application process, development tools, programming language, platform, and technology. The plan should focus on developing the building blocks of change, identify the knowhow of current IT application development process, and determine the best way to gradually adjust your application development process to fold in security best practices.
2. Roll out individual best practices initiatives carefully: Establish a champion to drive and take ownership of each integrated project. There is a need to run a successful pilot in part of our IT before the attempt to spread best practices far and wide.
3. Train People: Developers and Architects remain blithely unaware of security and the critical role that they play in it. Training and mentorship is a necessity.
4. Establish a metrics: Apply a business-driven metrics scorecard to monitor progress and assess success. Metrics and measures (even relative metrics based on risk over time or business metrics such as maintenance budget) are critical to making progress in a large organization.
5. Establish and sustain a continuous improvement capability: Create a situation in which continuous improvement can be sustained by measuring results and periodically refocusing attention on the weakest aspects of the security of your application.
Bayan Alhaddad
March 17th 2005
Thursday, March 17, 2005
Tuesday, November 2, 2004
Static code analysis tools characteristics
All Information Technology projects produce at least one artifact – code. This fact moves code review to the number one touch-point “best practice” to be of focus. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. Today, a handful of first-tier options are available in the static code analysis tools space. Each of the tools offers a comprehensive and growing rule set varying in both size and area of focus. As we investigate and evaluate which tool is most appropriate for our needs and environment, the coverage of the accompanying rule set should be one of our primary factors of comparison. In addition, to be useful and cost effective, a source code analysis tool must have these key characteristics:
Be designed for security: Exploiting software is not an exercise in standard-issue QA. An application defect uncovered during functionality testing might be addressed in such a way that the functional issue is resolved, but security defects may still remain and be reachable via surprising execution paths that are not even considered during functionality testing. The knowledge base built into a tool is an essential decision factor.
Supporting multiple-tiers: Our applications are rarely written in a single programming language or targeted to a single platform. Our most business-critical applications are highly distributed, with multiple tiers each written in a different programming language and executed in a different platform. Automated security analysis software must support each of these languages and platforms. A tool that can analyze only one or two languages can’t meet the needs of our modern applications.
Be extensible: Good tools need a modular architecture that supports multiple kinds of analysis techniques. That way, as new attack and defense techniques are developed, the tool can be expanded to encompass them. Likewise, users must be able to add their own security rules. Every department within IT has its own set of security needs, meaning that one size fits all approach to security is doomed to fail.
Be useful for security analysts and developers: Even the best analysis tools cannot automatically fix security problems. The best automated tools make it possible for analysts to focus their attention directly to the most important issues.
Supporting existing development process: Seamless integration with build processes and IDEs Plug-In is an essential characteristic of any software tool. For a source analysis tool to become accepted as part of an application development team’s toolset, the tool must properly inter-operate with existing compilers used on the various platforms and support current development tools. Good tools both integrate into existing development process and also coexist with and support analysis in familiar development tools.
Static analysis tool must avoid these characteristics:
Too many of False-Positives: One common problem with early approaches to static analysis was their excessive false positive rates. Application Security practitioners seem to feel that tools that provide a false positive rate under 40 % are okay. Modern approaches that include data flow analysis capability dramatically reduce false positives, making source code analysis much more effective.
Spotty integration with IDEs: Developers already have an IDE they like, and they should not have to switch to do a security analysis.
Bayan Alhaddad
October 2nd, 2004
Be designed for security: Exploiting software is not an exercise in standard-issue QA. An application defect uncovered during functionality testing might be addressed in such a way that the functional issue is resolved, but security defects may still remain and be reachable via surprising execution paths that are not even considered during functionality testing. The knowledge base built into a tool is an essential decision factor.
Supporting multiple-tiers: Our applications are rarely written in a single programming language or targeted to a single platform. Our most business-critical applications are highly distributed, with multiple tiers each written in a different programming language and executed in a different platform. Automated security analysis software must support each of these languages and platforms. A tool that can analyze only one or two languages can’t meet the needs of our modern applications.
Be extensible: Good tools need a modular architecture that supports multiple kinds of analysis techniques. That way, as new attack and defense techniques are developed, the tool can be expanded to encompass them. Likewise, users must be able to add their own security rules. Every department within IT has its own set of security needs, meaning that one size fits all approach to security is doomed to fail.
Be useful for security analysts and developers: Even the best analysis tools cannot automatically fix security problems. The best automated tools make it possible for analysts to focus their attention directly to the most important issues.
Supporting existing development process: Seamless integration with build processes and IDEs Plug-In is an essential characteristic of any software tool. For a source analysis tool to become accepted as part of an application development team’s toolset, the tool must properly inter-operate with existing compilers used on the various platforms and support current development tools. Good tools both integrate into existing development process and also coexist with and support analysis in familiar development tools.
Static analysis tool must avoid these characteristics:
Too many of False-Positives: One common problem with early approaches to static analysis was their excessive false positive rates. Application Security practitioners seem to feel that tools that provide a false positive rate under 40 % are okay. Modern approaches that include data flow analysis capability dramatically reduce false positives, making source code analysis much more effective.
Spotty integration with IDEs: Developers already have an IDE they like, and they should not have to switch to do a security analysis.
Bayan Alhaddad
October 2nd, 2004
Sunday, July 11, 2004
The Three Core Areas Of Application Security
Applied Risk Management
To make risk management coherent, it is useful to draw a distinction between the application of risk analysis and the architectural level (sometimes called threat modeling or security design analysis) and the notion of tracking and mitigating risk as a full lifecycle activity. Architectural risk analysis is a best practice and is one of the central touch-points in application security. However, security risks crop up throughout the Software Development Lifecycle (SDLC); thus, Risk Management Framework (RMF) is heart of application security activities. Successful risk management, however, is a business-level decision-support tool to gather the requisite data to make good judgment call, based on knowledge of vulnerabilities, threats, impacts, and probabilities. The RMF should consist of these fundamental activity stages:
· Understand the business context
· Identify the business and technical risks
· Synthesize and prioritize the risks, producing a ranked set
· Define the risk mitigation strategy
· Carry out required fixes and validate that they are correct
Application Security Touch-points (best practices)
Adding features such as SSL to our application (to cryptographically protect communications) or through authorization does not present a complete solution to secure our applications. Application security must be part of a full lifecycle approach with its touch-points (Best Practices):
1. Code review (Static Analysis Tools)
Example of risk found: Buffer Overflow on a specific line of code.
All Information Technology projects produce at least one artifact – code. This fact moves code review to the number one touch-point “Best Practice”. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. Code review is necessary but not sufficient practice for achieving secure application and therefore environment. A comprehensive approach to application security involves holistically combining both code review and architectural analysis.
2. Architectural risk analysis
Examples of risk found: Poor compartmentalization and protection of critical data; failure of a Web Service to authenticate calling code and its user and to make access control decisions based on proper context. At the design and architecture level, a system must be coherent and present a unified security front. Designers, architects, and analysts should clearly document assumptions and identify possible attacks. At both the specifications-based architecture stage and at the class-hierarchy design stage, architectural risk analysis is a necessity. At this point, security analysts uncover and rank architectural flaws so that mitigation can begin. Disregarding risk analysis at this level will lead to costly problems down the road. Risks crop up during all stages of the application lifecycle, so a constant risk management thread, with recurring risk-tracking and monitoring activities, is highly recommended for application security.
3. Penetration testing
Example of risks found: Poor handling of program state in Web interface.
Penetration testing is extremely useful, especially if an architectural risk analysis informs the tests. The advantage of penetration testing is that it gives a good understanding of fielded software / application in its real environment. However, any such testing that does not take the software architecture into account probably won’t uncover anything interesting about software risk. One pitfall with penetration testing involves who does it. The Application Security functions acknowledge that network penetration tests are not the same as application or software-faced penetration tests.
4. Risk-based security tests
Example of risks found: Extent of data leakage possible by leveraging data protection risk.
Security testing will encompass two strategies: testing of security functionality with standard functional testing techniques and risk-based security testing based on attack patterns, risk analysis results, and abuse cases. Guiding security testing with knowledge of software architecture, common attacks, and the attacker’s mindset is thus extremely important.
5. Abuse cases
Example of risks found: Susceptibility to well-known tampering attack.
Building abuse cases is a great way to get into the mind of the attacker. Similar to use cases, abuse cases describe the system’s behavior under attack; building abuse cases requires explicit coverage of what should be protected, from whom, and for how long.
6. Security requirements
Example of risks found: No explicit description of data protection needs.
Security must be explicitly worked into the requirements level. Good security requirements cover both overt functional securities and emergent characteristics (captured by abuse cases and attack patterns.
These touch-Points “best practices” can be applied regardless of the base application process being followed, Control Objectives for Information and related Technology (COBIT), Capability Maturity Model integration (CMMi), and any number of other processes will involve the creation of a common set of application artifacts (the most common artifact being code). A Secure Development Lifecycle (SDL) will be created by adapting our existing Information Technology Software Development Lifecycle (SDLC) to include these touch-points.
The artifacts of this Application Security will focus on include requirements and use cases, architecture, design documents, test plans, code, maintenance, test results, measurements and feedback from the end-users.
Knowledge
One of the critical challenges facing the security of Information Technology is the dearth of experienced practitioners. As application security evolves, and best practices are established. Knowledge management and training play a central role in encapsulating and spreading the emerging discipline more efficiently. This core area involves gathering, encapsulating, and sharing security knowledge that can be used to provide a solid foundation for application Security practices.
Information and knowledge isn’t the same thing, and it is important to understand the difference. Knowledge is information in context – information put to work using processes and procedures. A checklist of potential security bugs in ABAP, Java or J2EE is information; the same information built into a static analysis (code review) tool is knowledge.
The application security knowledge is categorized into seven (Principles, Guidelines, Rules, Vulnerabilities, Exploits, Attack patterns, Historical risks) knowledge catalogs that are in turn grouped into three (Prescriptive knowledge, Diagnostic knowledge, Historical) knowledge categories. The degree of this knowledge will be deployed based on job function within IT, based on technology, programming language (ABAP, Java, .NET) used, attack patterns, and historical risks.
This application security knowledge will be applied (where and when applicable) at various stages throughout the entire Secure Development Lifecycle (SDL) and through the use of the touch-points “Best Practices”. For example, rules are extremely useful for static analysis and code
Bayan Alhaddad,
July 11th, 2004
To make risk management coherent, it is useful to draw a distinction between the application of risk analysis and the architectural level (sometimes called threat modeling or security design analysis) and the notion of tracking and mitigating risk as a full lifecycle activity. Architectural risk analysis is a best practice and is one of the central touch-points in application security. However, security risks crop up throughout the Software Development Lifecycle (SDLC); thus, Risk Management Framework (RMF) is heart of application security activities. Successful risk management, however, is a business-level decision-support tool to gather the requisite data to make good judgment call, based on knowledge of vulnerabilities, threats, impacts, and probabilities. The RMF should consist of these fundamental activity stages:
· Understand the business context
· Identify the business and technical risks
· Synthesize and prioritize the risks, producing a ranked set
· Define the risk mitigation strategy
· Carry out required fixes and validate that they are correct
Application Security Touch-points (best practices)
Adding features such as SSL to our application (to cryptographically protect communications) or through authorization does not present a complete solution to secure our applications. Application security must be part of a full lifecycle approach with its touch-points (Best Practices):
1. Code review (Static Analysis Tools)
Example of risk found: Buffer Overflow on a specific line of code.
All Information Technology projects produce at least one artifact – code. This fact moves code review to the number one touch-point “Best Practice”. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. Code review is necessary but not sufficient practice for achieving secure application and therefore environment. A comprehensive approach to application security involves holistically combining both code review and architectural analysis.
2. Architectural risk analysis
Examples of risk found: Poor compartmentalization and protection of critical data; failure of a Web Service to authenticate calling code and its user and to make access control decisions based on proper context. At the design and architecture level, a system must be coherent and present a unified security front. Designers, architects, and analysts should clearly document assumptions and identify possible attacks. At both the specifications-based architecture stage and at the class-hierarchy design stage, architectural risk analysis is a necessity. At this point, security analysts uncover and rank architectural flaws so that mitigation can begin. Disregarding risk analysis at this level will lead to costly problems down the road. Risks crop up during all stages of the application lifecycle, so a constant risk management thread, with recurring risk-tracking and monitoring activities, is highly recommended for application security.
3. Penetration testing
Example of risks found: Poor handling of program state in Web interface.
Penetration testing is extremely useful, especially if an architectural risk analysis informs the tests. The advantage of penetration testing is that it gives a good understanding of fielded software / application in its real environment. However, any such testing that does not take the software architecture into account probably won’t uncover anything interesting about software risk. One pitfall with penetration testing involves who does it. The Application Security functions acknowledge that network penetration tests are not the same as application or software-faced penetration tests.
4. Risk-based security tests
Example of risks found: Extent of data leakage possible by leveraging data protection risk.
Security testing will encompass two strategies: testing of security functionality with standard functional testing techniques and risk-based security testing based on attack patterns, risk analysis results, and abuse cases. Guiding security testing with knowledge of software architecture, common attacks, and the attacker’s mindset is thus extremely important.
5. Abuse cases
Example of risks found: Susceptibility to well-known tampering attack.
Building abuse cases is a great way to get into the mind of the attacker. Similar to use cases, abuse cases describe the system’s behavior under attack; building abuse cases requires explicit coverage of what should be protected, from whom, and for how long.
6. Security requirements
Example of risks found: No explicit description of data protection needs.
Security must be explicitly worked into the requirements level. Good security requirements cover both overt functional securities and emergent characteristics (captured by abuse cases and attack patterns.
These touch-Points “best practices” can be applied regardless of the base application process being followed, Control Objectives for Information and related Technology (COBIT), Capability Maturity Model integration (CMMi), and any number of other processes will involve the creation of a common set of application artifacts (the most common artifact being code). A Secure Development Lifecycle (SDL) will be created by adapting our existing Information Technology Software Development Lifecycle (SDLC) to include these touch-points.
The artifacts of this Application Security will focus on include requirements and use cases, architecture, design documents, test plans, code, maintenance, test results, measurements and feedback from the end-users.
Knowledge
One of the critical challenges facing the security of Information Technology is the dearth of experienced practitioners. As application security evolves, and best practices are established. Knowledge management and training play a central role in encapsulating and spreading the emerging discipline more efficiently. This core area involves gathering, encapsulating, and sharing security knowledge that can be used to provide a solid foundation for application Security practices.
Information and knowledge isn’t the same thing, and it is important to understand the difference. Knowledge is information in context – information put to work using processes and procedures. A checklist of potential security bugs in ABAP, Java or J2EE is information; the same information built into a static analysis (code review) tool is knowledge.
The application security knowledge is categorized into seven (Principles, Guidelines, Rules, Vulnerabilities, Exploits, Attack patterns, Historical risks) knowledge catalogs that are in turn grouped into three (Prescriptive knowledge, Diagnostic knowledge, Historical) knowledge categories. The degree of this knowledge will be deployed based on job function within IT, based on technology, programming language (ABAP, Java, .NET) used, attack patterns, and historical risks.
This application security knowledge will be applied (where and when applicable) at various stages throughout the entire Secure Development Lifecycle (SDL) and through the use of the touch-points “Best Practices”. For example, rules are extremely useful for static analysis and code
Bayan Alhaddad,
July 11th, 2004
Saturday, June 19, 2004
The Trinity of Trouble
There are three trends – together makes up the trinity of trouble and that is why application security is needed now than in the past.
Connectivity
The growing connectivity of our backend systems through intranet and extranet increases the probability of both the number of attack vectors and the ease with which an attack can be made. This could put your landscape and therefore business operation at greater risk. More and more computers, ranging from PCs / servers to systems that control critical infrastructure, such as your SAP mega solution, the Supervisory Control and Data Acquisition (SCADA) systems "generally refers to an industrial control system: a computer system monitoring and controlling a process" that run the power grid, are being connected to your networks and to the Internet. Furthermore, your employees, businesses are increasingly dependent on network-enabled communication such as e-mail or Web pages. Unfortunately, as these systems are connected to the Internet, they become vulnerable to software-based attacks from distant source. In the past software security problems did shut down world-wide businesses (banking services and airlines as shown by the SQL Slammer worm of January 2003).
Extensibility
The second trend negatively affecting software security is the degree to which systems have become extensible. An extensible system accepts updates or extensions, sometimes referred to as mobile code so that the functionality of the system can be evolved in an incremental fashion. For example, the plug-in architecture of web browser makes it easy to install viewer extensions for new document types as needed.
Today’s operating systems support extensibility through dynamic ally loadable device driver and models and today’s applications, such as word processors, email clients, spreadsheets, and Web browser, support extensibility through scripting, controls, components, and applets. The advent of Web Services and Service Oriented Architecture (SOA), which are built entirely from extensible systems such as J2EE and .NET, brings explicit extensibility to the frontend. From economic standpoint, extensible systems are attractive because they provide flexible interfaces that can be adapted through new components. Unfortunately, the very nature of extensible systems makes it hard to prevent software vulnerabilities from slipping in as unwanted extensions.
Complexity
A third trend impacting software security is the growth in size and complexity of our modern information systems especially software systems and therefore the number of line code. Security faults are a subset of quality faults which will tend to be a function of code complexity. Simply, more code, more bugs, more security problems.
Bayan Alhaddad,
June 19, 2004
Connectivity
The growing connectivity of our backend systems through intranet and extranet increases the probability of both the number of attack vectors and the ease with which an attack can be made. This could put your landscape and therefore business operation at greater risk. More and more computers, ranging from PCs / servers to systems that control critical infrastructure, such as your SAP mega solution, the Supervisory Control and Data Acquisition (SCADA) systems "generally refers to an industrial control system: a computer system monitoring and controlling a process" that run the power grid, are being connected to your networks and to the Internet. Furthermore, your employees, businesses are increasingly dependent on network-enabled communication such as e-mail or Web pages. Unfortunately, as these systems are connected to the Internet, they become vulnerable to software-based attacks from distant source. In the past software security problems did shut down world-wide businesses (banking services and airlines as shown by the SQL Slammer worm of January 2003).
Extensibility
The second trend negatively affecting software security is the degree to which systems have become extensible. An extensible system accepts updates or extensions, sometimes referred to as mobile code so that the functionality of the system can be evolved in an incremental fashion. For example, the plug-in architecture of web browser makes it easy to install viewer extensions for new document types as needed.
Today’s operating systems support extensibility through dynamic ally loadable device driver and models and today’s applications, such as word processors, email clients, spreadsheets, and Web browser, support extensibility through scripting, controls, components, and applets. The advent of Web Services and Service Oriented Architecture (SOA), which are built entirely from extensible systems such as J2EE and .NET, brings explicit extensibility to the frontend. From economic standpoint, extensible systems are attractive because they provide flexible interfaces that can be adapted through new components. Unfortunately, the very nature of extensible systems makes it hard to prevent software vulnerabilities from slipping in as unwanted extensions.
Complexity
A third trend impacting software security is the growth in size and complexity of our modern information systems especially software systems and therefore the number of line code. Security faults are a subset of quality faults which will tend to be a function of code complexity. Simply, more code, more bugs, more security problems.
Bayan Alhaddad,
June 19, 2004
Subscribe to:
Posts (Atom)