Phase 1: Requirements for LOB The Risk Assessment section that follows is exclusive to designing a security plan for LOB applications. It includes information on completing an application portfolio, assessing application risk, and determining service levels.

On This Page

Risk Assessment
Security Requirements
Mapping Risk to Security SME Service Levels
Security Recommendations
Resources

Risk Assessment

The Risk Assessment phase captures general security and privacy ‘‘qualities’’ to determine the appropriate amount of oversight. During this phase, an application is assessed to understand the potential risk it creates. If an application is high risk, it receives more oversight in the SDL-LOB process. If an application is low risk, it receives less oversight in the SDL-LOB process. The application team and application security team work in partnership to complete this phase.

When an application team proposes a new application or updates to an existing application, a risk assessment is completed. Application teams understand they must complete this step as a prerequisite for installing the application in a supported production environment. This risk assessment produces repeatable guidance on the type of oversight the project will receive in the SDL-LOB process.

There will be a close collaboration between the security and privacy subject-matter experts (SMEs) and the risk management/governance team for your organization. Risk management helps identify business objectives and therefore guidance for evaluating the risk posed by individual line-of-business applications. Risk management also affects and influences guidelines for rating the risk posed by individual vulnerabilities and classes of vulnerabilities filed during internal review and verification phases. For more information, see the Microsoft Security Risk Management Guide.

Security Requirements

• Application portfolio

  • Application teams enter application details in an application portfolio system that is used to track the life cycle of LOB applications within the enterprise.
  • The portfolio system can track information, such as contacts, dependencies, version history, deployment considerations, milestones, testing information and history, locations of relevant documents, and tasks and security controls used during the applications life cycle. Ideally, the portfolio would feature support, such as automated notification if the application is not in compliance with required (and, as appropriate—optional) controls. If you have a dedicated security team, the portfolio would also track the security SME assigned to perform an assessment, assessment history, artifacts, and, if appropriate, actual bugs.
  • Development teams must enter a new entry for the application if a new version of the application is being released so that it can follow this process cycle again.

• Application risk assessment

  • Application risk level is determined based on a questionnaire filled out by the application team. This determines the SDL-LOB tasks the application owner must complete and is used to determine if the application is in scope for a security and privacy assessment. Please see Appendix P: SDL-LOB Risk Assessment Questionnaire for more details.
    Note: The risk posed by an application may increase or decrease between successive releases and should be evaluated accordingly.

Mapping Risk to Security SME Service Levels

The output of the risk assessment dictates the degree of oversight from a security SME. Questions in the assessment are weighted together into an overall “score,” while questions may dictate a review regardless of the overall “score.” The sample questionnaire provided gives some guidance in this respect, but you will need to tailor it for your specific business and customer needs. This approach ensures consistency and reputability combined with flexibility. Experience has shown that a “one-size-fits-all” approach is not effective.

For example, based on application risk (High/Medium/Low), applications are serviced accordingly during various phases of the development. Note that all applications require oversight; however, application teams are still responsible for compliance with your implementation of the SDL-LOB (including appropriate requirements and recommendations from main SDL described earlier in this document).

Mapping of risk level to service levels are depicted in the following table:

Application Risk Level	Application Service Level
High	Threat model Design review Comprehensive review, which includes most or all of the following: Code review (white box) Penetration test (black box) Privacy review Deployment review
Medium	Threat model (recommended) Code review (white box) Privacy review (as appropriate) Deployment review (as appropriate)
Low	Threat model (as appropriate) Deployment review (as appropriate)

• Application risk level. The application risk level is based on the type of data managed by the system, the system functionality, and the environmental controls. Sample framework for determining risk level is as follows:

  • High-risk applications. Internet-facing applications that handle personal data, other highly sensitive data, or executes sensitive/critical functions.
  • Medium-risk applications. Internal-facing applications that handle sensitive data (not highly sensitive) or execute important functions that are not critical.
  • Low-risk applications. Applications that manage publicly available data or execute functions that do not play a key role.

• Application service level

  • Threat model. The application team needs to create (or update) a threat model for the application. Threat modeling is, in some sense, a discovery process wherein you look at your application through a lens of security and/or privacy. The application team should own the creation of the threat model in consultation with a security/privacy SME.

    Note: Threat models are recommended, but compliance is not typically enforced for low and sometimes medium risk applications.

  • Design review. Similar to and distinct from threat modeling, a design review addresses additional issues, such as reviewing your design approach to critical areas in your application, including authentication, authorization, input/data validation, exception management, user provisioning/deprovisioning, and other areas. Finally, you conduct a tier-by-tier component analysis and examine the security mechanisms employed by your key components, such as your presentation layer, business layer, and data access layer.

  • Comprehensive assessment. This effort is the exhaustive testing of the application and the vulnerabilities found in the code base in an attempt to determine the exploitability of the issues found. Severity of findings can be influenced by the results of exploit testing. This service may include all or some of the following tasks as appropriate:

    • Code review (white box)
    • Penetration test (black box)
    • Regulatory compliance (privacy review)
    • Deployment review

  • Code review (white box). Conducted to determine how many code defects exist. Severity of findings is based on deviation from policy, standards, and best practices. The review should balance a line-by-line code inspection against prioritizing sensitive parts of the application, such as authentication, authorization, handling of sensitive data, and avoiding common security vulnerabilities, such as poor input validation, SQL injection, and failure to properly encode web output. In addition, the code review should verify compliance with security/privacy standards and policies. Violations of standards and policies are viewed as must-fix, Critical vulnerabilities.

  • Penetration test (black box). Uses a mix of tools, such as wire sniffers and scanners, combined with actually running the application to verify expected and unexpected behavior.

  • Deployment review. Executed against production environments to ensure primarily that access control and architectural issues conform to requirements; this niche serves double duty. This service level is a good starting point for applications that do not immediately warrant the two higher levels. These are often internal medium risk applications.

  • Privacy review. Ensure the application complies with corporate, domestic, and international privacy requirements to prevent malicious monitoring of behavior, obtaining sensitive information, or identity theft.

Security Recommendations

• Visual Studio .NET Team System (or equivalent) can be used for bug tracking and management purposes.

• Dedicated security and privacy subject matter experts assist the application team during application development. These SMEs serve as resources for conducting all of the SDL-LOB tasks but, in particular, help perform specific tasks, such as a code reviews and penetration tests, among others.

Resources

• Privacy home page.

• Microsoft Operation Framework Deliver Phase provides guidance for getting operational concerns reflected during the Requirements phase of project development as well as getting release readiness in place as a validation step prior to production.

• Governance, Risk, and Compliance Service Management.

Content Disclaimer

This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products. This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it. This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. © 2012 Microsoft Corporation. All rights reserved. Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported