From ‘bit player’ to a major player. Application security used to be more of an afterthought than anything else in software design. Today it has become one of the top concerns as security teams grapple with the never-ending supply of applications and their availability over networks. Taking a proactive approach and building security into applications reduces the likelihood that hackers will be able to manipulate applications and access, steal, modify, or delete sensitive data. Protect your software, hardware, and procedural methods by utilizing assessments.
Q: Why should I do an Application Security Assessment?
A: Many times applications are written and coded in less than ideal conditions. Most applications are coded by multiple programmers with differing philosophies and levels of expertise. New functionality may be added to old applications without a thorough examination of the existing code base. Often these additions are performed by personnel who were not around when the initial design of the application took place. Issues such as these can lead to flaws that cause security issues.
Q: How do you approach conducting an Application Security Assessment?
A: We begin by creating a surface map of the application, then develop a threat model (the objectives of the attacker), complete a vulnerability assessment and penetration test on the application, perform a cascading failure analysis, and finally we would generate three levels of reports.
Q: What areas are examined with an Application Security Assessment?
A: The MSI methodology closely examines:
- Authentication (the how and why of accessing an application)
- Logging (what’s being tracked and where is it recorded)
- Data Validation (how does the application behave when given good and bad information)
- Data Encryption (how is the information kept secret)
- Component Interaction (how do the distinct application components interact)
- Database Interaction (how does the application interact with associated database)
- Network Security (are the hosting platforms properly configured and deployed)
Q: Can you give examples of what you will be looking for within the application?
A: Cross site scripting, buffer overflows, hidden passwords, poor data protection, inadequate authentication mechanisms, SQL injection, user session faults (session hijacking, replay and repudiation issues), fuzzing, etc.
Q: Wouldn’t my QA process catch the security holes?
A: In most cases, security issues are likely to be overlooked. Quality Assurance teams are under tremendous pressure to “release” applications quickly. Testing is often concentrated on the issues of load tolerance, reliability and the expected behaviors of the application and its users. Identifying insecure coding practices and testing unexpected user behavior is not the primary focus of most QA teams. As a consequence underlying security issues often go undetected.
Q: What are the costs of application testing?
A: Costs vary for each application depending upon its size, complexity and the resources required to test it. Several service options are available, depending on the criticality of the application and the level of testing required. Contact your account executive for more specific information and for help scoping and pricing an engagement that addresses your specific needs.
Q: Who can I contact to discuss Application Security Assessments in more detail?
A: Your account executive can answer any questions you may have. You can reach an account executive by sending email to firstname.lastname@example.org.