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