다음을 통해 공유

Appendix V: Lessons Learned and General Policies for Developing LOB Applications

  • 아티클

The efforts of Microsoft IT to inventory, assess, and, if necessary, fix potential security issues that it discovers in its internal line-of–business (LOB) applications have proven to be successful. Microsoft IT has a much better grasp of the number and complexity of the applications that are used to run the day-to-day business at Microsoft. When Microsoft IT discovers any security issue in one application, it searches for that issue in other applications. Tightened security and privacy helps protect business-sensitive data and confidential employee data at Microsoft. Formalizing the security and privacy assessment process by means of SDL-LOB has raised the level of security and privacy awareness among the many internal development teams in Microsoft IT, reduced/identified risk, and improved the security of future development projects.

On This Page

Lessons Learned
Setting Up a Security Team

Lessons Learned

Procedural lessons learned as part of this include the following:

  • Address security during application development. Waiting until the production phase to address security may expose vulnerabilities in the application.
  • Create clearly written and easy-to-access documentation of security and privacy standards.
  • Stabilize the process. Introducing constant changes to the standards or the process creates considerable churn and confusion.
  • Use a process to prioritize which applications are examined or the order in which they are examined to help ensure that the most sensitive application/data is examined first.
  • Develop a thoroughly considered process for tracking policy exceptions.
  • Education is crucial to the success of a security and privacy program. Train developers, testers, and support personnel on an ongoing basis to provide up-to-date information.
  • Security and privacy are ongoing concerns. Implement an experienced security team and a well-developed process to help ensure that applications incorporate ongoing changes.
  • For third-party applications, a written statement from the vendor helps provide assurance that the software does not contain any hidden mechanisms that could be used to compromise or circumvent the software's security and privacy controls.
  • Use an application portfolio management tool to track applications and to manage compliance with the overall governance process.
  • The scope of security and privacy work may require a cross charge model that helps manage a balance between the availability of security/privacy subject matter experts (SMEs) against application release cycles.

Technical lessons learned as part of this include the following:

  • Create security checklists that include step-by-step instructions for securing applications, hosts, and networks.
  • Create privacy checklists that include systematic instructions for appropriate handling of applications that collect, use, or contain personal data (including notification requirements).
  • Use a sound reporting solution to help drive compliance with the process.
  • Ensure regular scanning of network and host to identify vulnerabilities, confirm patch management, and ensure regulatory compliance.
  • Within a security tracking system, maintain an up-to-date inventory of the following items:
  • Applications, their versions, and the hosts (fully qualified domain name) they reside on
  • Compliance with SDL-LOB related tasks
  • Server lists (development, test, and production) by application
  • Policies and related standards
  • Exceptions to policies and standards

Setting Up a Security Team

Depending on the size of your organization, there may be a dedicated security team responsible for conducting reviews, setting standards, and monitoring compliance with regulatory requirements, standards, and policies. Specific responsibilities for this team may include:

  • Security and privacy SMEs who conduct/monitor service delivery for the service levels.
  • Account management that acts as a liaison with application teams, manage the application portfolio, and ensure that the process for SDL-LOB compliance runs smoothly.
  • Remediation and risk management, which both prioritize applications for assessment and manage the remediation of high-risk vulnerabilities found during the assessment.
  • Operations team that conducts network and host scanning post-assessment across the enterprise and production servers.
  • Training and awareness for application teams to ensure that they comply with standards, policies, and best practices.
  • Help desk to answer common questions and, as needed, escalate to the security and privacy SMEs.
  • Authoring checklists, standards, and even corporate policy to meet security and privacy requirements.
  • Resources, tools, and other content that assist application teams building low-risk or medium-risk LOB applications with security and privacy compliance.

In addition, there needs to be a security liaison within each development organization to ensure there is consistent messaging to the application teams and a single point of contact within the actual LOB organization.

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