Blog Series: Get Familiar with the SDL-LOB Process. Introduction to Phase Four: Verification for LOB

  • Článek

Hello, Anmol here…continuing our discussion of Security Development Lifecycle for Line-of-Business applications (SDL-LOB) process, let’s discuss Phase Four: Verification for LOB today. The SDL-LOB defines the standards and best practices for providing security and privacy for new and existing line-of-business (LOB) applications currently under development or being planned for development. If you missed prior phases, read them here: Phase One, Phase Two and Phase Three.

Phase 4 is all about verifying different security claims made in earlier phases and identifying gaps in implementation. For example, during design review phase, let’s assume an application team identifies that the design is vulnerable to cross site scripting attacks and therefore adds security requirements such as AntiXSS library to be incorporated during coding. During the verification phase, a security SME (subject matter experts) will verify that all user controlled data which needed to be validated and encoded is actually *done*. If there are any gaps identified, they will be triggered as security bugs for the application teams to fix.

Here are a few key tasks to be executed in this phase:

  • Conduct pre-production assessment (white box/black box reviews, deployment reviews of servers & privacy reviews)
  • Identify security issues and applying a severity rating.
  • Compliance: Tracking all risks identified.

Before a line-of-business (LOB) application is deployed in production, the application must adhere to internal security policies, guidance and follow industry best practice. As mentioned above, in this phase expert application security SMEs are engaged. One way a SME verifies an application is by performing a pre-production assessment. What’s a pre-production assessment? It’s an assessment performed based on the service level assigned depending on the application’s risk rating. Back in “ Phase 1: Requirements for LOB ” a Risk Assessment was conducted which determines an application’s risk level. Based on the risk level, a service level is then assigned. Generally white box code review is conducted on applications that are medium or high risk rating. An ideal comprehensive assessment will be a combination of white and black box testing. Having said this, performing the assessment with a mix of manual process automated tools can help save some time. For code reviews (white box) testing, a SME will identify categories of vulnerabilities in the code. Here are some vulnerabilities that are identified:

  • SQL injection. Ensure that the SQL queries are parameterized (preferably within a stored procedure) and that any input used in a SQL query is validated.
  • Cross-site scripting. Ensure that user controlled data is encoded properly before rendering to the browser. .NET applications can leverage Anti-XSS library for encoding data that is more rigorous than the native .NET encoding.
  • Cross-site request forgery. Ensure that the Page.ViewStateUserKey property is set to a unique value that prevents one-click attacks on your application from malicious users.
  • Data access. Look for improper storage of database connection strings and proper use of authentication to the database.
  • Input/data validation. Look for client-side validation that is not backed by server-side validation, poor validation techniques, and reliance on file names or other insecure mechanisms to make security decisions.

See the complete list of vulnerabilities and learn more about verification in this Phase 4. Watch the podcast called “SDL-LOB Phase Three: Implementation” where Eugene Siu, Senior Security Engineer of Microsoft ACE Team, provides an overview of code reviews and more.

Next time I’ll discuss Phase 5: Release for LOB. Till then happy & secure coding.

-Anmol Malhotra
Senior Security Engineer
ACE Team

Comments

  • Anonymous
    August 10, 2009
    hi Anmol, I have a question on ACE reviews. Thanks -Rustin