Application security: Difference between revisions
Obiwankenobi (talk | contribs) |
|||
Line 79: | Line 79: | ||
[[Veracode]].<ref>http://www.veracode.com/solutions Veracode Security Static Analysis Solutions</ref> |
[[Veracode]].<ref>http://www.veracode.com/solutions Veracode Security Static Analysis Solutions</ref> |
||
Banking and large [[E-Commerce]] corporations have been the very early adopter customer profile for these types of tools. It is commonly held within these firms that both Black Box testing and White Box testing tools are needed in the pursuit of application security. Typically sited, Black Box testing (meaning Penetration Testing tools) are ethical hacking tools used to attack the application surface to expose vulnerabilities suspended within the source code hierarchy. Penetration testing tools are executed on the already deployed application. White Box testing (meaning Source Code Analysis tools) are used by either the application security groups or application development groups. Typically introduced into a company through the application security organization, the White Box tools complement the Black Box testing tools in that they give specific visibility into the specific root vulnerabilities within the source code in advance of the source code being deployed. Vulnerabilities identified with White Box testing and Black Box testing are typically in accordance with the [[OWASP]] taxonomy for software coding errors. White Box testing vendors have recently introduced dynamic versions of their source code analysis methods; which operates on deployed applications. Given that the White Box testing tools have dynamic versions similar to the Black Box testing tools, both tools can be correlated in the same software error detection paradigm ensuring full application protection to the client company. |
Banking and large [[E-Commerce]] corporations have been the very early adopter customer profile for these types of tools. It is commonly held within these firms that both Black Box testing and White Box testing tools are needed in the pursuit of application security. Typically sited, Black Box testing (meaning Penetration Testing tools) are ethical hacking tools used to attack the application surface to expose vulnerabilities suspended within the source code hierarchy. Penetration testing tools are executed on the already deployed [http://www.checkmarx.com/Products.aspx?id=10 application security testing]. White Box testing (meaning Source Code Analysis tools) are used by either the application security groups or application development groups. Typically introduced into a company through the application security organization, the White Box tools complement the Black Box testing tools in that they give specific visibility into the specific root vulnerabilities within the source code in advance of the source code being deployed. Vulnerabilities identified with White Box testing and Black Box testing are typically in accordance with the [[OWASP]] taxonomy for software coding errors. White Box testing vendors have recently introduced dynamic versions of their source code analysis methods; which operates on deployed applications. Given that the White Box testing tools have dynamic versions similar to the Black Box testing tools, both tools can be correlated in the same software error detection paradigm ensuring full application protection to the client company. |
||
The advances in professional [[Malware]] targeted at the Internet customers of online organizations has seen a change in Web application design requirements since 2007. It is generally assumed that a sizable percentage of Internet users will be compromised through [[malware]] and that any data coming from their infected host may be tainted. Therefore application security has begun to manifest more advanced anti-fraud and heuristic detection systems in the back-office, rather than within the client-side or Web server code.<ref>{{cite web|title= Continuing Business with Malware Infected Customers|url=http://www.technicalinfo.net/papers/MalwareInfectedCustomers.html|publisher=Gunter Ollmann|date=October, 2008}}</ref> |
The advances in professional [[Malware]] targeted at the Internet customers of online organizations has seen a change in Web application design requirements since 2007. It is generally assumed that a sizable percentage of Internet users will be compromised through [[malware]] and that any data coming from their infected host may be tainted. Therefore application security has begun to manifest more advanced anti-fraud and heuristic detection systems in the back-office, rather than within the client-side or Web server code.<ref>{{cite web|title= Continuing Business with Malware Infected Customers|url=http://www.technicalinfo.net/papers/MalwareInfectedCustomers.html|publisher=Gunter Ollmann|date=October, 2008}}</ref> |
Revision as of 16:27, 15 May 2012
Application security encompasses measures taken throughout the application's life-cycle to prevent exceptions in the security policy of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrade, or maintenance of the application.
Applications only control the use of resources granted to them, and not which resources are granted to them. They, in turn, determine the use of these resources by users of the application through application security.
Open Web Application Security Project (OWASP) and Web Application Security Consortium (WASC) updates on the latest threats which impair web based applications. This aids developers, security testers and architects to focus on better design and mitigation strategy. OWASP Top 10 has become an industrial norm in assessing Web Applications.
Methodology
According to the patterns & practices Improving Web Application Security book, a principle-based approach for application security includes:[1]
- Knowing your threats.
- Securing the network, host and application.
- Incorporating security into your software development process
Note that this approach is technology / platform independent. It is focused on principles, patterns, and practices.
Threats, Attacks, Vulnerabilities, and Countermeasures
According to the patterns & practices Improving Web Application Security book, the following terms are relevant to application security:[1]
- Asset. A resource of value such as the data in a database or on the file system, or a system resource.
- Threat. A negative effect.
- Vulnerability. A weakness that makes a threat possible.
- Attack (or exploit). An action taken to harm an asset.
- Countermeasure. A safeguard that addresses a threat and mitigates risk.
Application Threats / Attacks
According to the patterns & practices Improving Web Application Security book, the following are classes of common application security threats / attacks:[1]
Category | Threats / Attacks |
---|---|
Input Validation | Buffer overflow; cross-site scripting; SQL injection; canonicalization |
Authentication | Network eavesdropping ; Brute force attack; dictionary attacks; cookie replay; credential theft |
Authorization | Elevation of privilege; disclosure of confidential data; data tampering; luring attacks |
Configuration management | Unauthorized access to administration interfaces; unauthorized access to configuration stores; retrieval of clear text configuration data; lack of individual accountability; over-privileged process and service accounts |
Sensitive information | Access sensitive data in storage; network eavesdropping; data tampering |
Session management | Session hijacking; session replay; man in the middle |
Cryptography | Poor key generation or key management; weak or custom encryption |
Parameter manipulation | Query string manipulation; form field manipulation; cookie manipulation; HTTP header manipulation |
Exception management | Information disclosure; denial of service |
Auditing and logging | User denies performing an operation; attacker exploits an application without trace; attacker covers his or her tracks |
Mobile application security
The proportion of mobile devices providing open platform functionality is expected to continue to increase in future. The openness of these platforms offers significant opportunities to all parts of the mobile eco-system by delivering the ability for flexible program and service delivery options that may be installed, removed or refreshed multiple times in line with the user’s needs and requirements. However, with openness comes responsibility and unrestricted access to mobile resources and APIs by applications of unknown or untrusted origin could result in damage to the user, the device, the network or all of these, if not managed by suitable security architectures and network precautions. Application security is provided in some form on most open OS mobile devices (Symbian OS,[2] Microsoft [citation needed], BREW, etc.). Industry groups have also created recommendations including the GSM Association and Open Mobile Terminal Platform (OMTP).[3]
Security testing for applications
Security testing techniques scour for vulnerabilities or security holes in applications. These vulnerabilities leave applications open to exploitation. Ideally, security testing is implemented throughout the entire software development life cycle (SDLC) so that vulnerabilities may be addressed in a timely and thorough manner. Unfortunately, testing is often conducted as an afterthought at the end of the development cycle.
Vulnerability scanners, and more specifically web application scanners, otherwise known as penetration testing tools (i.e. ethical hacking tools) have been historically used by security organizations within corporations and security consultants to automate the security testing of http request/responses; however, this is not a substitute for the need for actual source code review. Physical code reviews of an application's source code can be accomplished manually or in an automated fashion. Given the common size of individual programs (often 500,000 lines of code or more), the human brain can not execute a comprehensive data flow analysis needed in order to completely check all circuitous paths of an application program to find vulnerability points. The human brain is suited more for filtering, interrupting and reporting the outputs of automated source code analysis tools available commercially versus trying to trace every possible path through a compiled code base to find the root cause level vulnerabilities.
The two types of automated tools associated with application vulnerability detection (application vulnerability scanners) are Penetration Testing Tools (often categorized as Black Box Testing Tools) and static code analysis tools (often categorized as White Box Testing Tools). Tools in the Black Box Testing arena include IBM Rational AppScan, HP Application Security Center[4] suite of applications (through the acquisition of SPI Dynamics[5]), Nikto (open source). Tools in the static code analysis arena include Coverity,[6] GrammaTech,[7] Klocwork,[8] Parasoft,[9] Pre-Emptive Solutions,[10] and Veracode.[11]
Banking and large E-Commerce corporations have been the very early adopter customer profile for these types of tools. It is commonly held within these firms that both Black Box testing and White Box testing tools are needed in the pursuit of application security. Typically sited, Black Box testing (meaning Penetration Testing tools) are ethical hacking tools used to attack the application surface to expose vulnerabilities suspended within the source code hierarchy. Penetration testing tools are executed on the already deployed application security testing. White Box testing (meaning Source Code Analysis tools) are used by either the application security groups or application development groups. Typically introduced into a company through the application security organization, the White Box tools complement the Black Box testing tools in that they give specific visibility into the specific root vulnerabilities within the source code in advance of the source code being deployed. Vulnerabilities identified with White Box testing and Black Box testing are typically in accordance with the OWASP taxonomy for software coding errors. White Box testing vendors have recently introduced dynamic versions of their source code analysis methods; which operates on deployed applications. Given that the White Box testing tools have dynamic versions similar to the Black Box testing tools, both tools can be correlated in the same software error detection paradigm ensuring full application protection to the client company.
The advances in professional Malware targeted at the Internet customers of online organizations has seen a change in Web application design requirements since 2007. It is generally assumed that a sizable percentage of Internet users will be compromised through malware and that any data coming from their infected host may be tainted. Therefore application security has begun to manifest more advanced anti-fraud and heuristic detection systems in the back-office, rather than within the client-side or Web server code.[12]
Security standards and regulations
- Sarbanes-Oxley Act (SOX)
- IEEE P1074
- ISO/IEC 7064:2003 Information technology -- Security techniques -- Check character systems
- ISO/IEC 9796-2:2002 Information technology -- Security techniques -- Digital signature schemes giving message recovery -- Part 2: Integer factorization based mechanisms
- ISO/IEC 9796-3:2006 Information technology -- Security techniques -- Digital signature schemes giving message recovery -- Part 3: Discrete logarithm based mechanisms
- ISO/IEC 9797-1:1999 Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher
- ISO/IEC 9797-2:2002 Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 2: Mechanisms using a dedicated hash-function
- ISO/IEC 9798-1:1997 Information technology -- Security techniques -- Entity authentication -- Part 1: General
- ISO/IEC 9798-2:1999 Information technology -- Security techniques -- Entity authentication -- Part 2: Mechanisms using symmetric encipherment algorithms
- ISO/IEC 9798-3:1998 Information technology -- Security techniques -- Entity authentication -- Part 3: Mechanisms using digital signature techniques
- ISO/IEC 9798-4:1999 Information technology -- Security techniques -- Entity authentication -- Part 4: Mechanisms using a cryptographic check function
- ISO/IEC 9798-5:2004 Information technology -- Security techniques -- Entity authentication -- Part 5: Mechanisms using zero-knowledge techniques
- ISO/IEC 9798-6:2005 Information technology -- Security techniques -- Entity authentication -- Part 6: Mechanisms using manual data transfer
- ISO/IEC 14888-1:1998 Information technology -- Security techniques -- Digital signatures with appendix -- Part 1: General
- ISO/IEC 14888-2:1999 Information technology -- Security techniques -- Digital signatures with appendix -- Part 2: Identity-based mechanisms
- ISO/IEC 14888-3:2006 Information technology -- Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms
- ISO/IEC 27001:2005 Information technology -- Security techniques -- Information security management systems -- Requirements
- ISO/IEC 27002:2005 Information technology -- Security techniques -- Code of practice for information security management
- ISO/IEC 24762:2008 Information technology -- Security techniques -- Guidelines for information and communications technology disaster recovery services
- ISO/IEC 27006:2007 Information technology -- Security techniques -- Requirements for bodies providing audit and certification of information security management systems
- ISO/IEC 270034-1:2011 Information technology — Security techniques — Application security -- Part 1: Overview and concepts
- PCI Data Security Standard (PCI DSS)
See also
- Countermeasure
- Data security
- Database security
- Information security
- Trustworthy Computing Security Development Lifecycle
- Web application
- Web application framework
- XACML
- HERAS-AF
References
- ^ a b c Improving Web Application Security: Threats and Countermeasures, published by Microsoft Corporation.
- ^ "Platform Security Concepts", Simon Higginson.
- ^ Application Security Framework, Open Mobile Terminal Platform
- ^ Application security: Find web application security vulnerabilities during every phase of the software development lifecycle, HP center
- ^ HP acquires SPI Dynamics, CNET news.com
- ^ http://www.coverity.com/products Coverity Static Analysis
- ^ http://www.grammatech.com/products/codesonar GrammaTech CodeSonar
- ^ http://www.klocwork.com/products Klocwork Insight
- ^ http://www.parasoft.com/parasoft_security Parasoft Application Security Solution
- ^ http://www.preemptive.com/application-protection.html Application Protection
- ^ http://www.veracode.com/solutions Veracode Security Static Analysis Solutions
- ^ "Continuing Business with Malware Infected Customers". Gunter Ollmann. October, 2008.
{{cite web}}
: Check date values in:|date=
(help)
External links
- Open Web Application Security Project
- The Web Application Security Consortium
- The Microsoft Security Development Lifecycle (SDL)
- patterns & practices Security Guidance for Applications
- QuietMove Web Application Security Testing Plug-in Collection for FireFox
- Advantages of an integrated security solution for HTML and XML
- Security Solutions
- patterns & practices Application Security Methodology
- Understanding the Windows Mobile Security Model, Windows Mobile Security]
- Network Security Testing