Security Development – Microsoft Secure Blog In-depth discussion of security, cybersecurity and technology trends affecting trust in computing, as well as timely security news, trends, and practical security guidance Thu, 20 Jul 2017 16:02:01 +0000 en-US hourly 1 Secure Development Blog Thu, 17 Mar 2016 17:52:30 +0000 Read more »]]> We’re proud to announce Secure Development at Microsoft, our developer focused security blog at Microsoft. The blog was created to inform developers of new security tools, services, open source projects and best development practices in order to help instill a security mindset across the development community and enable cross collaboration amongst its members.

Blog posts will be written by Microsoft engineers to give developers the right level of technical depth in order to get them up and running with integrating security assurance into their projects right away. We’ll cross reference their posts to make sure anyone following this blog can also check out the technical side of what we do.

Check them out!

What’s New with Microsoft Threat Modeling Tool 2016 Thu, 08 Oct 2015 02:02:27 +0000 Read more »]]> Threat modeling is an invaluable part of the Security Development Lifecycle (SDL) process. We have discussed in the past how applying a structured approach to threat scenarios during the design phase of development helps teams more effectively and less expensively identify security vulnerabilities, determine risks from those threats, and establish appropriate mitigations.

The Microsoft Threat Modeling Tool 2016 is a free tool to help you find threats in the design phase of software projects. It’s available as a free download from the Microsoft Download Center. This latest release simplifies working with threats and provides a new editor for defining your own threats. Microsoft Threat Modeling Tool 2016 has several improvements.

  • New Threat Grid
  • Template Editor
  • Migrating Existing Data Flow Diagrams

New Threat Grid

The threat grid has been overhauled. Now you can sort and filter on any column. You can easily filter the grid to show threats for any flow. You can sort on the interaction column if you want to group all the threats for each flow. You can sort on the changed by column if you want to find that threat you just edited.

Template Editor

Microsoft Threat Modeling Tool 2016 comes with a base set of threat definitions using STRIDE categories. This set includes only suggested threat definitions and mitigations which are automatically generated to show potential security vulnerabilities for your data flow diagram. To offer more flexibility, Microsoft Threat Modeling Tool 2016 gives users the option to add their own threats related to their specific domain. This means users can extend the base set of threat definitions using the template editor.

The template editor also allows users to modify the stencils available on the drawing surface.  If you have a stencil you would like to make available for your DFDs, you can add it.  If you need another stencil property, you can add that.

Migrating Existing Data Flow Diagrams

Threat modeling is an iterative process. Development teams create threat models which evolve over time as systems and threats change. We wanted to make sure the new version supports this flow. Microsoft Threat Modeling Tool 2016 will load any threat model from Microsoft Threat Modeling Tool 2014, in the .tm4 format. Threat models created with v3 version of the tool (.tms format) must be migrated to the Microsoft Threat Modeling Tool 2014 format (.tm4) before they can be loaded in Microsoft Threat Modeling Tool 2016.  Microsoft Threat Modeling Tool 2014 offers a migration tool for threat models created with version 3.1.8. (NOTE: For migrating threat models from v3.1.8 only, Microsoft Visio 2007 or later is required).

Additional Information

We hope these new enhancements in Microsoft Threat Modeling Tool 2016 will provide greater flexibility and help enable you to effectively implement the SDL process in your organization.

Thank you to all who helped in shipping this release through internal and external feedback. Your input was critical to improving the tool and customer experience.

For more information and additional resources, visit:


Alex Armanasu is an Engineer on the Secure Development Tools team at Microsoft. He’s responsible for the Threat Modeling component of the Security Development Lifecycle (SDL).

New Version of BinScope Binary Analyzer Thu, 20 Nov 2014 19:50:11 +0000 Read more »]]> We are delighted to announce the availability of an updated version of the BinScope Binary Analyzer, Microsoft BinScope version 2014. BinScope is a tool used during the Security Development Lifecycle (SDL) verification phase. It is available as a free download from the Microsoft Download Center here.

BinScope was designed to help detect potential vulnerabilities that can be introduced into Binary files. The checks it implements examine application binary files to identify coding and build practices that can potentially render the application vulnerable to attack or to being used as an exploit attack vector.

The specific changes in BinScope 2014 Update include:

  • Correctly handles CompilerWarningsCheck with the use of –W4 on the command line.
  • Correctly processes the warning levels which are explicitly enabled from the command line.
  • The __declspec(safebuffers) check no longer fires on GsDriverEntry for x86 drivers.
  • ATL version check now fails on known bad ATL headers only; no longer produces failures on unknown ATL headers.
  • Removed deprecated switches from showing as part of /?.
  • Allows new-line delimited file lists getting parsed as response files.

BinScope 2014 Update is inclusive of all the improvements that were part of BinScope 2014, such as:

Improved Diagnostic Messages

A key focus for BinScope 2014 was to ensure that diagnostic messages are clear and actionable for engineers when a potential vulnerability is detected. We believe that being able to quickly understand not only the potential issue but its mitigation is key.

New Minimum Compiler and Minimum Linker Version Switch

By default, BinScope 2014’s CompilerVersionCheck adheres to the compiler and linker versions defined in the SDL guidance. However, we recognize that compiler and linker versions will evolve over time, as a result two new command line switches were added. These switches, known as /MinimumCompilerVersion and /MinimumLinkerVersion, provide the ability to adjust the minimum linker and compiler versions that BinScope will detect when running the CompilerVersionCheck.

Increased Performance

Another important focus for us was to improve the performance of BinScope when executing a scan, particularly with large binaries. As a result, we have been able to improve the scanning performance of BinScope by up to 4 times.

Other changes in BinScope 2014 include:

  • Removal of the Graphical User Interface (GUI).
  • Removal of directory scanning, instead individual binary paths should be provided.
  • General bug fixes.

For more information and additional resources, visit:

IoT Security Does Not Have to be an Oxymoron – Part 2 Mon, 10 Nov 2014 17:03:55 +0000 Read more »]]> As my colleague Kevin Sullivan wrote in part 1 of this two-part series, the Internet of Things (IoT) holds great promise for organizations and consumers. But like many new technologies, it brings with it a number of security and privacy challenges. The industry can work to help address many of these challenges by building on some of the lessons learned from decades of experience connecting traditional computing devices to the Internet, as well as understanding the unique challenges that the IoT presents.

Among those unique challenges is the diversity of devices encompassing the IoT, that range from very simple devices that only transmit data, to complex devices with processors and sophisticated software. Before millions or billions of these devices are deployed across the world, some security and privacy fundamentals need to be carefully considered including:

  • Insecure design: Some of the early IoT devices I have seen in the market today have not been designed with security in mind. Some of these devices lack basic security capabilities, while others have security capabilities, but they are inappropriate for all the scenarios that the device can be used in. It’s also easy to imagine that some IoT devices have been released with insecure default settings.
  • Disclosure of personal information: When devices, sensors, appliances, etc., are connected to the Internet (or when physically accessible), it can raise concerns that everyday activities, preferences, and sensitive information, could be monitored and disclosed without proper authorization. Additional concerns arise with the possibility that data gathered from IoT devices could be correlated with other sources of data and used for purposes, such as the creation of self-learning autonomous systems, without the appropriate consent from the data owner.
  • Limited ability to receive updates and change configurations: Keeping systems up-to-date with security updates is one of the most effective security practices today. As vulnerabilities are discovered and attackers attempt to exploit them, it’s critically important that vendors have a well thought through response plan and the capability to update and reconfigure systems to mitigate these attacks. Not all IoT devices are going to be the same. Different devices are going to have different hardware and software, and subsequently different capabilities. Some devices might have limited update capabilities or might not even have an operating system. What’s the plan to update a t sensor that doesn’t have a full operating system installed on it? This type of requirement needs careful consideration.
  • Insecure data: How IoT devices store and transmit data is another important consideration. Securing data communications, including authentication, and encrypting data at rest, have become common expectations for systems today. The ability to manage settings for such security features is also a common expectation. Many IoT devices might be connected to networks that are themselves insecure making how well these devices protect data in untrusted or hostile environments a consideration.

What should industry do to help address security and privacy related to IoT? Building software with security in mind during every phase of development has proven to be very effective – something that can inform the development process for IoT devices as well. Among the unique challenges for the IoT is the diversity of devices encompassing the IoT, which range from very simple devices that only transmit data, to complex devices with processors and sophisticated software. Broadly applicable design considerations should include:

  • Secure by design, secure in development and secure in deployment (SD3): This is the same mantra we started in Trustworthy Computing at Microsoft many years ago. IoT devices and services should be designed and developed in manner that improves security and privacy during the lifecycle of the device by applying secure software development processes such as Microsoft’s Security Development Lifecycle.
  • Secure communications: Presumably, in the future many IoT devices will operate on the public Internet or on other networks where they may face a variety of threats to data confidentiality. IoT devices and services should utilize strong encryption techniques to protect data, and networks should use the latest communication protocols and up-to-date security architecture. On IoT devices that host third-party applications, the security of these communications needs to be addressed as well. Some more primitive IoT devices will lack the ability to perform encryption themselves. In such cases, one possible solution would be to design the device to allow its data to be encrypted by an intermediary gateway device on the local network before the data is sent over the Internet.
  • Manageability and security updates: Many IoT devices will likely be built for single purpose applications and will have limited input/output capabilities to manage the device. IoT devices need to be designed to apply important functionality and security updates, preferably with the option of automatic updates requiring little or no administrator interaction. Devices should be designed to respond to security issues impacting devices, services, or applications. Awareness of the security or privacy issues related to other services and devices with dependencies should also be accounted for in update planning. IoT devices lacking the physical requirements for manageability and updates should be designed to allow security management by an intermediary gateway device on the local network before the data is sent over the Internet – as one possible solution.
  • Privacy and data use: Because of the potential volume of personal or proprietary data that can be produced and stored by the IoT, both consumers and businesses will insist that the privacy of their information be protected. IoT products should take privacy-impacting collection and use of data into consideration from the earliest stages of design through development and deployment. IoT devices and services that seek to collect data pertaining to people should undergo appropriate scrutiny and evaluation for privacy concerns. Companies should also consider how they manage the commercial sharing of data as the IoT becomes a platform for trading information.
  • Appropriate level of cloud service capacity: Cloud services will need to be designed for a significantly higher number of simultaneous connections and greater volumes of data traffic given the expected proliferation of IoT devices. If cloud services are unable to manage the expected data flows generated by the IoT, they could be overwhelmed.

What should consumers do to protect their security and privacy related to IoT?

  • Evaluate security and privacy at purchase: Understand what security and privacy controls the device and services provide.
  • With updatable devices, keep software/firmware for your devices up-to-date: If the device offers automatic updates, consumers should enable them. Otherwise, consumers should check the manufacturer’s website regularly for new security updates.
  • Stay informed: Be aware and learn more about IoT devices and services.

You can learn more about Microsoft’s Internet of Things strategy here.

Trust me, I’m a cloud vendor Tue, 14 Oct 2014 17:42:26 +0000 Read more »]]> I visited my sister and her family a while ago and somehow ended up playing a game with my seven year-old niece. I forget what it was called now, but the objective was to describe colors without being able to relate them to an object. In other words, describe the color blue without referring to the sea, or the sky.

Try it. It’s tough. Though apparently not for seven year-olds.

Don’t ask me how, because I really don’t know, but on the drive home the game got me thinking about the concept of trust and how it relates to the cloud and cloud services. Just how do you explain something as ethereal as trust and yet come across as genuine and well, trustworthy?

In today’s environment, winning and retaining their customers’ trust is every cloud provider’s ambition. But how do you earn the right to be trusted? What do you say? Somehow starting a conversation with the words ‘trust me’ seems to have the opposite effect.

Here’s another phrase: actions speak louder than words. And that is what we have tried to do at Microsoft – set out the things we do to make our cloud services more secure, private and reliable. With 200 online and cloud services serving a billion customers and 20 million businesses in more than 76 countries/regions we know that organizations won’t use technology they don’t trust.


Security and privacy have been ingrained into our culture for more than a decade. It’s part of our DNA. To help our customers decide whether they can trust our cloud we invite them to consider our efforts in four main categories: cybersecurity, data privacy, compliance and transparency.

There’s a lot to cover in each of these categories, but, as I learned playing the colour game with my niece, there’s a benefit in brevity. Over the next few weeks I’ll cover each of these in a bit more detail, starting with cybersecurity.


Cybersecurity is engineered into Microsoft products and services from the initial design stage using the Security Development Lifecycle (SDL) – a holistic and comprehensive software development process for writing more secure and privacy-enhanced code, and enabling more reliable products and services. We invented the SDL and today it is broadly regarded as the industry standard for writing more secure software. Many of its key elements have been adopted by organizations including the Government of India as well as commercial entities, including Itron, MidAmerican Energy, Adobe and Cisco as the basis for their secure development regimen. Our SDL was also recognized as a case study on how to do software security development in the ISO standard 27034-1.

To help protect against Internet-based security threats and continuously assess and enhance the security of our services, we utilize Operational Security Assurance (OSA). OSA combines the knowledge from our security development and security response programs, with the experience of running hundreds of thousands of servers in data centers around the world. This depth of experience helps make Microsoft cloud-based services’ infrastructure more resilient to attack by decreasing the amount of time needed to prevent, detect, and respond to real and potential Internet-based security threats, thereby increasing the security for our customers.

For many years, we have incorporated encryption into our products and services to help protect customers from online criminals and hackers. However, since June of 2013, public concern about the methods governments use to collect data has led many organizations to be concerned about the privacy of their information. We not only understand the concerns our customers have, we share them. While we have no direct evidence that customer data has been breached by unlawful and unauthorized government access, we are addressing this concern head on by pursuing a comprehensive engineering effort to strengthen the encryption of customer data across our networks and services.

Although this is a significant engineering effort given the large number of services we offer and the hundreds of millions of customers we serve, we are committed to moving quickly. Many services already benefit from strong encryption in all or part of the lifecycle. For example, is protected by best in class security such as Transport Layer Security (TLS) and Perfect Forward Secrecy (PFS) encryption for both outbound and inbound email. We are also expanding encryption across all our services to provide best in class encryption solutions for data in transit between a user and the service, data in transit between data centers, data at rest, and end-to-end communications between users. And for customers looking for another layer of protection, we have also invested in giving customers the ability to use their own encryption mechanisms to encrypt their data.

Please look in on the Cyber Trust Blog next week when I’ll talk further about what we are doing specifically in the area of data privacy.

Oh. You’re this color when you’re sad and yet when you look up on a sunny day it makes you happy. That’s how a seven year old girl explains blue.


Trust: what’s it all about? Thu, 09 Oct 2014 18:52:15 +0000 Read more »]]> Today I delivered a keynote about trust in the cloud at the Cybersecurity Expo 2014 event in London. I’ve been thinking about how to tackle a topic like ‘trust’ and how it applies to cloud computing. I don’t know about you, but when someone you don’t know very well says ‘you can trust me,’ I kind of feel the opposite. I believe that actions speak louder than words.

With that in mind, I approached the topic by talking about four key areas that Microsoft believes are important for cloud service providers to demonstrate trustworthiness; areas that Microsoft delivers in the 200+ cloud services customers use today. As I did with the delegates today, I invite readers to consider cloud provider efforts in four main categories: cybersecurity, data privacy, compliance and transparency.

For Cybersecurity, Microsoft works to protect, detect and respond to threats against customers. We have invested in developing more secure products and services for more than a decade via the Security Development Lifecycle (SDL) – a holistic and comprehensive software development process that we created to help write more secure and privacy-enhanced code and enable more reliable products and services. Today the SDL is regarded as the industry standard for writing more secure software and is included as a case study in the ISO standard 27034-1.

Our online services adhere to a rigorous set of security and privacy controls that govern operations and support through a process called Operational Security Assurance (OSA). We have strong data encryption polices that help to protect our customers, partners and internal data within our networks. In support of this, in July we provided examples of how we are expanding encryption across our services to help protect customer data:

  • Office 365 – Provides message encryption, an email service that allows you to send encrypted mail to anyone.
  • Microsoft Azure – ExpressRoute, enables customers to access Azure services from their premises without having to traverse the Internet.
  • – Protection is provided by Transport Layer Security (TLS) encryption for both outbound and inbound email. has also enabled Perfect Forward Secrecy (PFS) encryption support for sending and receiving mail.
  • OneDrive has enabled Perfect Forward Secrecy (PFS) encryption.

Microsoft has a global, 24×7 incident response team that works to mitigate the effects of cyberattacks and malicious activity. The incident response team follows established procedures for incident management, communication, and recovery, and uses discoverable and predictable interfaces internally and to customers. We also proactively partner with law enforcement to combat cybercrime through our Digital Crimes Unit.

Our commitment to data privacy begins at the development stage and is part of the SDL as well as a set of internal guidelines, called the Microsoft Privacy Standard. As a result, our enterprise cloud services include world-class privacy features like Data Loss Prevention (DLP), Rights Management Services (RMS), and various controls that help customers manage risks to their data. As a result, we are currently the only cloud vendor whose commercial contracts meet the European Union Data Protection Authorities’ stringent standards for international transfers of data, a fact recognized by the “Article 29 Working Party”.

Third-party certifications help demonstrate compliance readiness to customers, auditors and regulators. Independent third-party companies, such as Deloitte and the British Standards Institution (BSI), regularly assess and verify our capabilities and adherence to a comprehensive set of requirements. Our structured approach to compliance is built on commitment to comply with a broad range of certifications, in many cases setting the pace for others to follow.

In March 2013, as part of our commitment to increased transparency, we began publishing details on the number of demands we receive each year in our Law Enforcement Requests Report and providing clear documentation of our established practices in responding to government legal demands for customer data.

It is important to recognize that the threat landscape will continue to evolve to keep pace with advances in security and data protection – that’s a given. Microsoft remains committed to protecting customer data through innovation and collaboration to help manage risk from cybercriminals.

For more information on our cloud services, check out

Vuln Hunt: Find the Security Vulnerability Challenge #2 Thu, 09 Oct 2014 16:27:43 +0000 Read more »]]> Ex-Netscape engineer Jamie Zawinski has a great quote about regular expressions. He said: “Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.” That’s certainly true for this week’s Security Vuln Hunt. Two points are possible, plus an extra bonus point.  The question:


The programmer here has written an input validation regex to test whether a given string matches the format of a URL, and while we should give him credit for designing his application to validate input, the particular regex pattern that he’s using is vulnerable to a denial of service attack.

The subexpression (\.[a-zA-Z0-9\-\._]+){2,} in the pattern contains a grouping expression with repetition (\.[a-zA-Z0-9\-\._]+) that is itself repeated via the expression {2,}. The worst-case operation time for such a regex construction is exponential time O(2n), and this could allow an attacker to craft a relatively short input value that would hang the application in an exponential processing loop.

Give yourself a point if you found the regular expression denial-of-service (ReDoS) vulnerability in the code.

Give yourself a point if you used the SDL Regex Fuzzer ( to find the vulnerability. These types of vulnerabilities are extremely difficult to find through manual code inspection, so why not take advantage of free tools that are available to help you?

Finally, give yourself a bonus point if you realized that in .NET 4.5, you can limit the amount of time that Regex spends trying to find matches by setting a matchTimeout value in the Regex constructor. This is an excellent defense-in-depth measure against ReDoS attacks.

Next week, we’ll look a sneaky SQL Injection vulnerability.

Vuln Hunt: Find the Security Vulnerability Challenge #1 Thu, 02 Oct 2014 16:19:18 +0000 Read more »]]> Whether it’s a riddle, puzzle, or detective mystery novel, most of us like to solve a good brain teaser. As security and program experts, these types of conundrums keep us on our toes. During the next few weeks, I’ll share some of my favorites, and see if you can find the security vulnerability. For this first one, let’s take a look at authenticated encryption. Two points are possible for solving this stumper, plus an extra bonus point.  Question:


First off, let’s give one point to the programmer, who realized that many encryption algorithms do not in themselves provide any integrity protection.

Encryption prevents an eavesdropper “Eve” from reading the message that Alice sends to Bob, but contrary to popular belief, it does not prevent Eve from intercepting and tampering with that message. (There are notable exceptions such as Galois/Counter Mode (GCM) and Counter with CBC-MAC (CCM) encryption modes, but for the purposes of this question we will assume that a non-authenticated encryption mode such as Cipher-block Chaining (CBC) was used.)

We also give a point to the programmer for using an encrypt-then-MAC design.

Alternative approaches (MAC-then-encrypt and encrypt-and-MAC) are extremely dangerous and have led to several serious security vulnerabilities: read Moxie Marlinspike’s blog post on the “Cryptographic Doom Principle” if you’d like to delve deeper. Give yourself a point if you realized that an encrypt-then-MAC approach is not a security bug.

However, although the programmer correctly validates the HMAC before decrypting, he does so a byte at a time and returns false as soon as he gets a mismatched byte. This means that a tampered HMAC value will fail slightly faster if the first byte is wrong than if the first byte is right. A persistent attacker may be able to exploit this timing difference to craft a valid HMAC for a tampered message. Give yourself a point if you found this timing attack vulnerability in the for-loop.

Finally, although it’s not a security “bug” per se, give yourself a bonus point if you noted that this code uses hardcoded cryptographic algorithms and is therefore not cryptographically agile.

All crypto weakens over time, and while HMAC-SHA256 is considered a strong algorithm now, that may change in the future (and perhaps suddenly). You should plan for this eventuality now and avoid hardcoding cryptographic algorithms into your code: see “Cryptographic Agility” for more details.

While finding a solution can be entertaining, it can also be serious business when it comes to security. For us, the goal is to provide even greater protection for data across all the great Microsoft services you use and depend on every day.

Next week, we’ll take a look at regular expressions.

Vuln Hunt: Find the Security Vulnerability Challenge Thu, 25 Sep 2014 18:15:54 +0000 Read more »]]> There’s a saying that many people have heard, “If it was snake, it would have bitten you.” More often than not, that’s the case with software vulnerabilities. A security class bug can often be so subtle in a program that human reviews, static code analysis and other sophisticated tools might not find it. Yet at the same time, finding that vulnerability can be critical, especially if it is exploitable.

During the next several weeks, in our ‘Vuln Hunt: Find the Security Vulnerability Challenge,’ we’ll share a few light-hearted examples from our Microsoft security experts that illustrate how subtle security vulnerabilities can be. Some of the examples they will share, can make even the savviest of us take a second look. Let’s see how well you do in with our first challenge that takes a look at authenticated encryption.

If you haven’t already, I also encourage you to check out another great security story “Life in Digital Crosshairs; the dawn of the Microsoft Security Development Lifecycle.” This story is about the industry-leading Security Development Lifecycle (SDL) which has been helping public and private organizations for the past 10 years, change their engineering cultures and develop more secure software, and help find where the vulnerabilities may be.

Enjoy the challenge!

SAFECode on Confidence: One Size Does Not Fit All Fri, 23 May 2014 15:00:00 +0000 http://marcbook.local/wds/playground/cybertrust/2014/05/23/safecode-on-confidence-one-size-does-not-fit-all/ Read more »]]> In a recent post by SAFECode, a non-profit organization of software vendors dedicated to increasing trust in information and communications technology products by improving security and assurance methods, Eric Baize of EMC and Steve Lipner of Microsoft discuss the challenging subject of trustworthiness of acquired software.  How a customer gains confidence in acquired software is a frequently asked question of developers.  The latest SAFECode blog discusses three approaches that a customer can use to assess the security of acquired software with varying levels of confidence.

]]> 1