Software Developers' Top 12 Secure Software Development Lifecycle (SSDL) practices by Microsoft

The Microsoft Secure Software Development Lifecycle (SSDL) is a software development process designed and published by Microsoft back in January 2004. It was based on the spiral model of the SDLC. In the initial period of development, it mainly benefited the company to reduce the maintenance costs of the software, and improve the reliability. Version 1 to Version 3 was not released to the public until January 2006. Version 3.2 was released in 2008.

After the successor versions, Microsoft SDL practice focused more on the reliability part of the software, security vulnerabilities, threat modeling, compliance, reporting, cryptography Standards, and incident response. After the latest version 5.2 (2012), Microsoft Secure Development Lifecycle (SDL) became an industry-leading software security practice models and widely recognized by private and public sectors around the globe.

I couldn’t agree more that “it’s one of the best secure Software assurance (SwA) practices to be followed and used”. Take my word for it. Since 2004, the SDL played a significant role in supporting and forming the world’s leading practices.

The two terms “security and privacy” in Microsoft is like an electron’s bombardment on an atom”, which cant be separated from its software culture and the development phases. The transparency we get from the published documents is sufficient enough to develop a secure product upon its release.

Reader's Mind:

In this section, we defined the target audience responsibilities that includes from an individual member, developers, testers, project managers, product managers, product directors, Trainers, and other individuals assisting in the SSDLC.

Today, we gonna evolve deeply into the concepts and principles currently used by Microsoft on its products and services, and at the same time, Microsft doesn’t disclose any of its core proprietary technologies and resources in this Microsoft SDL methodology V5.2. You know, Microsoft mind voice is like “you can have my Ice cream, not the recipe”, hahaha make sense to us.

Alright, in this article we will discuss and learn something useful about the secure SDL methodology, and how to implement in your organization or even you may introduce it to your manager or the board members to take it into consideration.

Microsoft SDL Optimization Model:

When public or private sector organizations integrate the Secure SDL concepts into the existing developmental model (let’s say DevOps), things are always tough in the beginning with the changes and the cost of adoption.

But, the impact and likelihood of the changes and cost could be controlled when you understand the core elements of the traits in secure SDL principles and concepts by establishing on your company’s products and services.

Let me highlight some of the key issues that could be resolved or reduced with adopting this Secure SDL.

• Improved security models.
• Privacy and data protection
• Risk and severity of the vulnerabilities are reduced.
• User’s personally identifiable information (PII) is under observation (data leakage avoidance)
• The community support
• Reputation brings values into the organizations
• To meet the compliance standards

In addition to these, the SDL Optimization Model also defines the practices and capabilities in four levels of maturity in these areas — Basic, Standardized, Advanced, and Dynamic, all of which we will discuss it later.

I will make it easy for you, Traditional Vs Simplified versions of the Secure software development life cycle (SSDLC).

The Traditional five capability’s in the Secure software development life cycle (SSDLC):

Figure 1: Secure software development life cycle (SSDLC).

The Simplified versions of the Secure software development life cycle (SSDLC) defined in 12 stage process (stages or practices) as follows:
Microsoft calls it practices, others call it stages, steps, phases, process, etc.

Pick any keyword that makes you feel comfortable. That’s matters to me.

Stage 1: Education and Awareness (training).

Stage 2: Product requirement (security and privacy).

Stage 3: Define and follow design requirements (best practices, protocols, tools, documents).

Stage 4: Define security features with cryptography standards.

Stage 5: Metrics, criteria, and compliance reporting.

Stage 6: Product risk assessment (define context, risk identification, risk analysis, risk treatment).

Stage 7: Manage and understand the security risk of using third-party components.

Stage 8: List of approved SDL tools.

Stage 9: Static Analysis Security Testing (SAST).

Stage 10: DynamicAnalysis Security Testing (DAST).

Stage 11: Penetration testing.

Stage 12: Establish a Standard Incident Response Process (planning, execution).

Figure 2. Microsoft Secure SDL-12 stage process.

Traditional Microsoft Product Development Process:

Since 2002, a formal process begins with many software development groups at Microsoft due process to Trustworthy Computing (TwC) directive. The main cause of TwC is to bring inherently secure, available, and reliable security to the code development process.

After a while, Microsoft coined “SD3+C” to enforce a secure by design, by default, by deployment, and communications to understand the comprehensive security and privacy efforts required in all 3 areas.

Figure 3. Traditional Microsoft Product Development Process under- SD3+C Directive.

Post Integration of Security Development Lifecycle (SDL) + SD3+C:

After you integrate the two modules together the post integration steps will look likes in the development process as shown in Figure4.

Figure 4. Post integration of SDL + SD3 stages.

Stage 1: Education and Awareness (Training):

Both private and public sector organizations should instigate competent training programs, and encourage their employees to understand that security isn't a “single person’s job” its “everyone’s job”.

All participating members of the project such as software developers, software testers, program engineers, service engineers, team lead, product manager, and product director should inherit the basic security traits and concepts to know how to build security into any software products & services. This is how a product should be painted with security to meet the industry standards and address all the customer’s requirements and delivery protocols.

The perspective:

The perspective of the key concepts is important to build a successful software product with a guarantee of privacy & security.

Figure 5. Stage 1: Education and Awareness (Training).

Stage 2: Product Requirement (Security and Privacy):

In this product requirement stage, it’s very early and crucial to consider “security and privacy (S&P)”, it helps (provide) an individual and organization to understand the fundamental elements of developing secure applications. Security in SDLC is like watering a plant, requiring continuous updates and reflect those changes into the practices to defend and counter the emerging threat surfaces. The more you act early could reduce the future headache (minimize disruption / security issues / cost / burden). Early bird gets the worm. So, do it in this stage for improving S&P to meet the business needs.

Security Requirements:

1. Try to develop a “short or brief”, Q&A alright let’s call that an internal survey to verify whether your development team is subject to Security Development Lifecycle (SDL) policies, also remember to consider these two objectives when framing the Q&A.
   
   (i)If the project is subject to SDL policies, a Security Advisor (SA) is mandatory to act as a PoC and do the Final Security Review (FSR). Let’s make them accountable, haha.
   
   (ii)If the project is not subject to SDL policies, it is not mandatory to assign a Security Advisor (SA), mark in the document as exempted with additional reasons.
   
2. To prepare the team or individual that is responsible for coordinating, tracking, and communicating, managing security issues for the products. In S&M company’s usually one manager is responsible for the above job.
   
3. To make sure that bug reporting tools can track security issues. Prepare a database that can be queried dynamically for all security bugs at any time.
   
4. To define and document the set of criteria in the project’s security bug bar. When a security advisor puts forth a stringent security bar, the project team must do the negotiation of a bug bar because it should not be relaxed.
   
5. When you are using a newly released 3rd-party licensed code or hardware, be aware and ensure to get the proof of compliance with a predefined list of SDL requirements:

In addition to that code verification, outputs, logs can be verified by an eternal agent as well.

Security Requirements:

During the design phase, it’s very useful to craft a security plan with the required timing, resources to outline the overall process and workflow for your team members throughout the development process. These requirement items as follows:

• Team training.
• Threat modeling.
• Security push.
• Final Security Review (FSR).

The “Security Bug Effect” and “Security Bug” Cause field items should be set to one of the following STRIDE values to ensure that we configure bug reporting tools correctly in order to limit access to security-related bugs, and avoid any security-related implications to the project.

Quick Tip: STRIDE concept was created with security in mind, it consists 6 categories of threats. It was developed by Praerit Garg and Loren Kohnfelder at Microsoft, for identifying computer security threats.

So, why do we are using STRIDE ?

To identify security threats, and each threat comes with a violation of a desirable property for a system or software.

Figure 6. STRIDE (security) Threat Model.

Figure 7. Threat Relates to Property.

Security Bug Cause:

Figure 8. Security Bug Cause.

Cost Analysis:

It's very important and one of the foundations for any project out there, that’s cost. One must know how to evaluate in handling the data with privacy and security related risks, and required development and support costs. That's how you keep up with your business needs.

Security Recommendations:

We conduct a security risk assessment (SRA) on our products to identify the security-related aspects such as (Risk, Threat, Vulnerability, Exposure, Risk impact, countermeasures).

A simplified SRA or a detailed SRA should be carried out to meet the project scope. What portions of the project will require (Threat models, code review, penetration testing, analysis, fuzz testing).

Privacy Requirements:

The Privacy Impact Assessment (PIA) is a quick way to determine your Privacy and the Impact. It helps users to estimate the required work to be compliant by assigning a rating (P1, P2, or P3) to represent the degree of risk to your software.

• P1 High Privacy Risk
• P2 Moderate Privacy Risk
• P3 Low Privacy Risk

1. Stores personally identifiable information (PII) or transfers it from your computer (P1)
2. Provides an experience that targets children or is attractive to children (P1)
3. Continuously monitors the user (P1)
4. Installs new software or changes file type associations, the home page, or search page (P1)
5. Transfers anonymous data (P2)
6. None of the above (P3)

You should create, conduct, review, test, discuss and get approval from your privacy Advisor.

Stage 3: Define and Follow Design Requirements (Best Practices, Protocols, Tools, Documents)
and
Stage 4: Define Security Features with Cryptography Standards:

In the design process where you could build the plan, visualize, and project how it will take your project throughout the SDL process from implementation to the final release.

Here we establish the best practices on industry, protocols, tools, document the defined threats and vulnerabilities in your software applications.

It is important to consider the Design specifications how we should implement these features and how to implement all functionality under secure features. In a careful way so that every part of data is looked at and processed cryptographically.

Security requirements:

A security design review should be conducted with your security advisor regardless of the project that you are doing. That being said low-risk components might not require a detailed security design review. It’s quite pretty ironic Hahn, isn’t it?

AllowPartiallyTrustedCallersAttribute (APTCA):

It enables an assembly to be called by untrusted code. It depends on the version of the framework you are using.

• To determine whether or not this attribute is enabled or disabled, make sure to look at your “annotations” in the “source-code”, also you could tool like “FxCop” which will flag usage for you. piece of cake.
• In case, if it is enabled already find a project security expert and demand a review. Tell him right now do it else I will kick your ass, lol.

Relying Party Suite (RPS) v4.0 SDK:

What is it? It provides a security advantage over the current Passport Manager (PPM) SDK version, it helps to mitigate several security issues involving keys such as key distribution, key deployment, and key administration.

User Account Control (UAC) environment:

It is a popular security feature in windows vista, XP, server2008, srver2008r2, It was defined to help the transition to regular use of non-administrative privilege by client applications. It helps the team to design and develop their applications by elevating the admin functions.

Firewall Rules and Requirements:

If a user required an open port, use Firewall Rules and Requirements guidelines to define and control it.

All cryptographic choices must comply with the Microsoft defined Cryptographic Standards for SDL-covered products & services.

Figure 9. Microsoft Cryptographic Standards.

Security Recommendations:

Once the design specifications are completed its time to define the size of the attack surface because it indicates the likelihood of a successful attack on the surface.

1. Write a security architecture document.
2. Default installation should be secure.
3. Minimize default attack surface/enable least privilege
4. Consider a defense-in-depth approach.
5. Software with well-defined dependencies
6. Deprecate outdated functionality (evaluate older protocols, file formats, and standards, and strongly consider removing them in the new release.)
7. Conduct a security review
8. Implement any new code using managed code
9. Migration of any possible legacy code from unmanaged code to managed code
10. Remain informed about security issues in the industry.
11. Be aware of unsafe functions and coding patterns.
12. Ensure appropriate logging is enabled for forensics.
13. Page flow integrity checking should be performed.
14. Hardware security design review.
15. Integration-points security design review.
16. Strong log-out and session management.

(.NET) security features:

(i)Refuse unneeded permissions.

(ii)Request optional permissions.

(iii)Use CodeAccessPermission Assert and LinkDemand carefully. Use Assert in as small a window as possible.

(iv)Disable tracing and debugging before deploying ASP.NET applications.

Stage 5: Metrics, Criteria, and Compliance Reporting:

In this stage, project members define the security issues associated with risk assessment frameworks such as (establish the context, Risk identification, Risk analysis, Risk evaluation, Risk treatment). It's crucial it will help you to find, fix, secure your application from damages. By using a risk rating matrix (Critical, High, medium, Low), you define risk.

To make sure that bug reporting tools can track security issues. Prepare a database that can be queried dynamically for all security bugs at any time. To define and document the set of criteria in the project’s security bug bar. When a security advisor puts forth a stringent security bar, the project team must do the negotiation of a bug bar because it should not be relaxed.

SDL Security Bug Bar and SDL Privacy Bug Bar (Sample) is illustrated as in Figure 10 and Figure 11.

SDL Security Bug Bar:

Figure 10. SDL Security Bug Bar.

SDL Privacy Bug Bar:

Figure11. SDL Privacy Bug Bar.

Stage 6: Product Risk Assessment (Define Context, Risk Identification, Risk Analysis, Risk Treatment).

Important things to consider in the risk analysis that includes the following:

• Threats and vulnerabilities that exist in the project’s environment.
• It is very important to carefully evaluate any external code from other sources. when team is unaware of the code likely cause security vulnerabilities.
• A review of the high-risk (P1) vulnerability and privacy projects should discuss with a privacy subject-matter expert (SME).

A detailed privacy analysis to document your project’s key privacy aspects:

1. What personal data is collected?
2. What is the compelling user value proposition and business justification?
3. What notice and consent experiences are provided?
4. What controls are provided to users and enterprises?
5. How is unauthorized access to personal information prevented?

Risk Rating Factors:

The factors we used to determine the vulnerability. Ideally, we should use all risk factors as rating factors.

Risk identification descriptions:

a) Describing threats in terms of who, how, and when.
b) Establishing into which threat class a threat falls.
c) Determining the threat likelihood.
d) Determining the implications on the business operations should a threat achieve success.
e) Assessing the impact of the results as less serious, serious, or exceptionally grave injury.
f) Assigning an exposure rating to every threat, in terms of the relative severity to the organization.
g) Prioritizing the impacts /likelihood pairs, according to the determined ratings.

In the design phase, the development team should review all the “Privacy and Security “ requirements, and overall expectations to identify the potential risks that matter. Microsoft introduced a threat modeling concept into the SDL. The main function of threat modeling is to apply the systematic process to identify threats and vulnerabilities present in the software. Remember the word “structured fashion” threat modeling applies to all products & services, and all platforms.

So, the development team must complete the milestone (threat modeling) during the project design stage. Because, if you do not do that, one can not build secure software. In Figure6.STRIDE (security) Threat Model, we discussed common threat areas, also don’t forget to apply this along with the threat modeling.

Threat Modeling: Part of your routine development lifecycle.

Figure 12. Threat Modeling.

Benefits:

Communicate about the security design.Analyze those designs for potential security issues.Suggest and manage mitigations for security issues.

Stage 7: Manage and Understand the Security Risk of Using Third-Party Components.

In both public and private sector organizations pretty much the majority of software projects are built using 3rd-party components and open-source tools.

So, the vulnerabilities drive through your organizations rapidly than ever before, following the commercial and non-commercial codes, tools are crucial for a successful secure SDL.

The dependency cant is controlled on modern software projects, because from open-source software to operating systems, from back-end to front-end-user interface.

Third-party Component Management Life Cycle (TPCM):

In TPCM Maintain, Assess, and Mitigate phases depends on each other outcomes, but Monitor phase considered as an independent process that is required throughout the entire third-party component life cycle.

• Monitor
• Maintain.
• Assess.
• Mitigate.

Figure 13. Third-party Component Management Life Cycle (TPCM)-safecode.

Security Risks of Open Source — (Act First, Rest Later):

What these practices recommend the team members should aware (keep-an-eye) of newly released modules, updates, notices in the community to find a patch and keep it updated. When you are lagging to do the upgrades to the latest version, in the meantime the adversaries could do the reconnaissance on your environment and could launch an exploit. So, Act First, Rest Later.

Benefits of Open Source:

• Increased time to market.
• Community.
• Higher quality.

Recommendation on Open Source:

Take the minimum precautions to properly manage this risk:

1. Identify what Open-source tools (OST)are used.
2. Centralize the inventory management on OST.
3. Ensure the OST is secure and updated.
4. Report and React to the security vulnerabilities indicates theSecurity Response Processes.

• Use
• Distribute
• Collaborate
• Contribute

Stage 8: List of Approved SDL Tools.

It's one of the important stages in the Secure SDLC to define and approve the list of approved tools, and understand the security objectives such as compiler, linked notifications, and warnings. Software engineers take one step ahead to use the approved versions of the latest tools.

Figure 14. Microsoft’s list of approved tools.

Stage 9: Static Analysis Security Testing (SAST)
and
Stage 10: DynamicAnalysis Security Testing (DAST):

In the Verification phase, software engineers’ core task is to ensure that written codes meet the defined privacy & security requirements in the previous stages. When engineers analyze the source code prior to any sort of compilations provides scalability to the code review, also guarantees that the team meets the coding policies.

SAST is inherited into the commit pipeline process, an optimal frequency for performing SAST should be discussed with the team to extensively identify vulnerabilities in the software package. when we do that we could able to balance our productivity and meet adequate security.

Speaking of which, privacy and security testing addresses the Confidentiality, integrity, and availability (CIA) triad of the software and data processed by the software.

Security Requirements:

All issues must be fixed according to the Bug Bar.

Win32/64/Mac:

Where any input to file parsing code could have crossed a trust boundary, then a file fuzzing must be performed on that code and each file parser should be fuzzed through a approved list of tools.

WinCE and Xbox:

A Template optimization scheme is applied based on the code coverage of the parser. Recent studies proved the double fuzzing increased effectiveness. Do you know a minimum of 500,000 iterations, and have fuzzed at least 250,000 iterations since the last bug found/fixed that meets the SDL Bug Bar.

Do you know since the last bug found/fixed more than 100,000 bug-free iterations happened over time according to the Microsoft SDL Bug Bar’s guidance statistics.

If the program exposes to a remote procedure call (RPC) interfaces, be ready to use any of the RPC fuzzing tools to test for problems.

If your project uses “ActiveX controls”, use an “ActiveX fuzzer”, to test for problems because they pose a significant security risk on the applications.

The Application Verifier helps to identify issues that are MSRC patch class issues in unmanaged code.

Define, Document, Verify every bug according to the security bug bar in Figure 10.

Online services and/or LOB applications:

Use approved cross-site scripting scanning test tool to find vulnerabilities, also together check for XML parsing problems as well. it saves your golden time. considered this as a double date, hahha.

Make sure you addressed it before the Final Security Review(FSR). He will yell at you. haha

Kernel-mode driver testing:

• Driver Verifier.
• Device Path Exerciser.
• Read-Only Unauthenticated Sites and Services.
• COM object testing.
• Authenticated Websites.
• Authenticated Web Services.
• JavaScript.

Security Push:

A security push occur when the product enters the verification stage, it is a team-wide effort on threat models to discover changes that might have happened during the software development time, gives you time to identify, remediate any new or missed vulnerabilities. It is essential to get the point straight here, that the goal of a security push is to find vulnerabilities, not to fix them. You may ask a question when we will do the fix, we do it right after you complete the security push steps.

Push Preparation:

Allocate time and resources.

The security coordinator determines what resources are required, and helps to organize, create the needed supporting materials and resources.

The security representatives should determine how to communicate security push information to the rest of the team.

To determine when the push will be completed.

Push Duration:

The amount of time, energy, and team-wide focus on a push differs because it depends on the attention from your team members given to security earlier in development.

Privacy Requirements:

• Changing the style of consent.
• Substantively changing the language of a notice.
• Collecting different data types.
• Exhibiting new behavior.

Stage 10: Dynamic Analysis Security Testing (DAST):

To perform the run-time verification of your fully compiled software packages to check the functionality is running. When using DAST prebuilt deck of tools, that specifically monitor application behavior for memory corruption, user privilege issues, and other critical security problems.

Again similar to the SAST deck of tools, there is no one-size-fits-all solution and while some tools, such as web app scanning tools, can be more readily integrated into the continuous integration / continuous delivery (CI/CD) pipeline, other DAST testing such as fuzzing requires a different approach. It is reasonable to execute the black-box fuzzing, which makes our job much easier because it doesn’t require manual code inspection of our source-codes. You can then improve the coverage, as needed, according to the methodology that is described in this article.

Stage 11: Penetration Testing:

A Penetration test is an authorized simulated security analysis task, often performed in conjunction with your computer system/Applications/Network, to evaluate the security status of the system. The objective of a penetration test practice is to uncover existing or likely new potential vulnerabilities resulting from coding errors, system configuration faults, or other operational deployment weaknesses with a variety of vulnerabilities.

Random Tip: Please, refer to the SDL Security Bug Bar in Figure 10.

Attack Surface Analyzer:

Microsoft developed an Attack Surface Analyzer(ASA) tool and published it as open source. This open-source ASA tool helps to analyze the attack surface of a target system and reports on possible security vulnerabilities introduced during the installation of a software or software misconfiguration.

Who can use it?

(I)DevOps Engineers — View changes to the system attack surface introduced when your software is installed.

(ii)IT Security Auditors — Evaluate risk presented by when third-party software is installed.

Microsoft provided Scenarios:

Attack Surface Analyzer can help identify potential security risks exposed through changes to services, user accounts, files, network ports, certificate stores, and the system registry. It also includes some support for “live” monitoring of certain system changes (i.e. file system and registry).

Another key use for the tool is in ensuring your software development process and products are following best practices for least privilege and reducing the attack surface for your customers by providing evidence, to your security and release teams, that your code does only what it claims. Maintaining customer trust is one reason why it is recommended from the Microsoft SDL Practices.

Core Features:

• File system (static snapshot and live monitoring available).
• User accounts.
• Services.
• Network Ports.
• Certificates.
• Registry.
• COM Objects.
• Event Logs.
• Firewall Settings.

Stage 12: Establish a Standard Incident Response Process (Planning, Execution):

The Microsoft Security Response Center (MSRC), Product Security Incident Response Team (PSIRT), Azure security-center is part of the overall defender community on security response. Be prepared and preparing an Incident Response Plan (IRP) is crucial for helping to address rapidly emerging threats on the surface.

Organizations should create an Incident Response Plan (IRP) in coordination with your organization’s dedicated Product Security Incident Response Team (PSIRT). Because, this plan should include an “Incident Commander” with a POC in case of a security emergency, and establish an internal emergency protocol for security servicing. The incident response plan (IRP) should be tested and deployed prior to the emergency situation.

Post-SDL Requirement: Response:

Security Servicing and Response Execution

After the software is released to the public or delivered to the customer, the product development team must be available to respond to any possible security vulnerabilities or privacy related issues that required an immediate response to call actions. That being said develop a response plan that includes preparations for potential post-release issues to tackle.

— — — — — — — — — — — — -THE END — — — — — — — — — — — —

Quote of the day: 石橋を叩いて渡る (Ishibashi o tataite wataru).

Explanation: For instance, consider a stone bridge very solid in structure. However, like any kind of bridge, stone bridges could potentially collapse at any time if their structure has weakened. It’s the necessity of taking precautions even though it may seem safe at first.

Thanks for reading!

Have a pleasant day!

Previously published here.