To date, we’ve helped customers address these issues by adding TLS 1.2 support to older operating systems, by shipping new logging formats in IIS for detecting weak TLS usage by clients, as well as providing the latest technical guidance for eliminating TLS 1.0 dependencies.

Now Microsoft is pleased to announce a powerful new feature in Windows to make your transition to a TLS 1.2+ world easier. Beginning with KB4490481, Windows Server 2019 now allows you to block weak TLS versions from being used with individual certificates you designate. We call this feature “Disable Legacy TLS” and it effectively enforces a TLS version and cipher suite floor on any certificate you select.

Disable Legacy TLS also allows an online or on-premise web service to offer two distinct groupings of endpoints on the same hardware: one which allows only TLS 1.2+ traffic, and another which accommodates legacy TLS 1.0 traffic. The changes are implemented in HTTP.sys, and in conjunction with the issuance of additional certificates, allow traffic to be routed to the new endpoint with the appropriate TLS version. Prior to this change, deploying such capabilities would require an additional hardware investment because such settings were only configurable system-wide via registry.

For a deep dive on this important new feature and implementation details and scenarios, please see Technical Guidance for Disabling Legacy TLS. Microsoft will also look to make this feature available in its own online services based on customer demand.

Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post TLS version enforcement capabilities now available per certificate binding on Windows Server 2019 appeared first on Microsoft Security Blog.

We have been recommending the use of TLS 1.2 and above for some time. To help provide guidance, we are pleased to announce the release of the Solving the TLS 1.0 Problem, 2nd Edition white paper. The goal of this document is to provide the latest recommendations that can help remove technical blockers to disabling TLS 1.0 while at the same time increasing visibility into the impact of this change to your own customers. Completing such investigations can help reduce the business impact of the next security vulnerability in TLS 1.0.

In the second edition update we added the following:

• Updates covering all of the new products and features Microsoft has shipped since the first version of the white paper, including IIS custom logging fields for weak TLS detection, TLS 1.2 backports to legacy OSes, and more.
• Introduction of the Office 365 Secure Score Customer Reporting Portal to help Office 365 tenant admins quantify their customers’ own weak TLS usage.
• Much more detail on .NET recommendations and best practices to ensure the usage of TLS 1.2+.
• Pointers to DevSkim rules for detection and prevention of TLS hardcoding.
• Tips for using PowerShell with TLS 1.2.

Read the Solving the TLS 1.0 Problem, 2nd Edition white paper to learn more.

The post Solving the TLS 1.0 problem appeared first on Microsoft Security Blog.

We are pleased to announce the release of a research paper, Securing the Future of Artificial Intelligence and Machine Learning at Microsoft, focused on net-new security engineering challenges in the AI and machine learning space, with a strong focus on protecting algorithms, data, and services. This content was developed in partnership with Microsoft’s AI and Research group. It’s referenced in The Future Computed: Artificial Intelligence and its role in society by Brad Smith and Harry Shum, as well as cited in the Responsible bots: 10 guidelines for developers of conversational AI.

This document focuses entirely on security engineering issues unique to the AI and machine learning space, but due to the expansive nature of the InfoSec domain, it’s understood that issues and findings discussed here will overlap to a degree with the domains of privacy and ethics. As this document highlights challenges of strategic importance to the tech industry, the target audience for this document is security engineering leadership industry-wide.

Our early findings suggest that:

1. Secure development and operations foundations must incorporate the concepts of Resilience and Discretion when protecting AI and the data under its control.

• AI-specific pivots are required in many traditional security domains such as Authentication, Authorization, Input Validation, and Denial of Service mitigation.
• Without investments in these areas, AI/machine learning services will continue to fight an uphill battle against adversaries of all skill levels.

2. Machine learning models are largely unable to discern between malicious input and benign anomalous data. A significant source of training data is derived from un-curated, unmoderated public datasets that may be open to third-party contributions.

• Attackers don’t need to compromise datasets when they are free to contribute to them. Such dataset poisoning attacks can go unnoticed while model performance inexplicably degrades.
• Over time, low-confidence malicious data becomes high-confidence trusted data, provided that the data structure/formatting remains correct and the quantity of malicious data points is sufficiently high.

3. Given the great number of layers of hidden classifiers/neurons that can be leveraged in a deep learning model, too much trust is placed on the output of AI/machine learning decision-making processes and algorithms without a critical understanding of how these decisions were reached.

• AI/machine learning is increasingly used in support of high-value decision-making processes in medicine and other industries where the wrong decision may result in serious injury or death.
• AI must have built-in forensic capabilities. This enables enterprises to provide customers with transparency and accountability of their AI, ensuring its actions are not only verifiably correct but also legally defensible.
• When combined with data provenance/lineage tools, these capabilities can also function as an early form of “AI intrusion detection,” allowing engineers to determine the exact point in time that a decision was made by a classifier, what data influenced it, and whether or not that data was trustworthy.

Our goal is to bring awareness and energy to the issues highlighted in this paper while driving new research investigations and product security investments across Microsoft. Read the Securing the Future of Artificial Intelligence and Machine Learning at Microsoft paper to learn more.

Listen to the Security Unlocked podcast

Hear more from the author of this blog on episode #7 of Security Unlocked. Subscribe for new episodes each week covering the latest in security news.

Listen now

The post Securing the future of AI and machine learning at Microsoft appeared first on Microsoft Security Blog.