TLS Compliance Monitoring

A big change happening in a lot of environments right now is the shift to enforcing the use of TLS 1.2 as your primary protocol provider.  Standards with PCI compliance now require any site accepting credit card information for payments use TLS 1.2.

This is a complex topic so ensure you do your research and understand how the configuration of these settings present in an environment and whether your settings are secure.  Additionally, security sensitive topics are always subject to change and I will try to keep this up to date. 

The configuration takes MANY things into consideration such as OS versions, hotfixes, .Net versions, and multiple registry keys.  To simplify the tracking of your progress and identification of systems out of compliance I have created a Management Pack to assist you in this.  This Management Pack will test each of the following items and ensure whether you are forcing TLS 1.2 on your monitored machines or not.

  • Testing Reg Key configurations to ensure neither Client or Server keys allow any unsecure protocols to be either Enabled or Negotiable.
    • SSL 2.0
    • SSL 3.0
    • TLS 1.0
    • TLS 1.1
  • Testing TLS 1.2 Registry Key to ensure it is Enabled.
  • Ensuring you are enforcing strong cryptography.
  • Allowing applications to use the OS Default settings.
  • OPTIONALLY: I report in the discovery on the .Net Framework Version
    • A workflow can be enabled to generate alerts for versions below 4.7
      • Having a .Net Version at or above this level can simplify your compliance configuration.
MP presentation in the Monitoring Pane
TLS Compliance State View – Displaying all configurations for discovered instances.

As a cherry on top.  This MP also has some discoveries and optional monitors to test configurations for secure Ciphers, Key Exchange Algorithms and Hashes as these can factor into your overall picture of compliance.

Cipher State View – Additionally a monitor can be enabled to check for secure configurations
Key Exchange Algorithm State View
– – Additionally a monitor can be enabled to check for secure configurations


Lastly, a big thank you to a few individuals that help me put this together.  Robin Kenny, Husam Hilal, Tyson Paul, Kevin Holman, and Hugh Scott. Without them this would not have been possible. 

Download “TLS Compliance Management Pack for SCOM” TLSComplianceMP_2.0.0.1.zip – Downloaded 175 times – 245 KB

22 Replies to “TLS Compliance Monitoring”

  1. Hello,

    I have implemented this mgmt pack and have disabled all protocols (via GPO and registry entries) with the exception of TLS 1.2 (client and server). App TLS is set to use OS, Strong Cryptography is Supported. The only thing not set is SSL Functions.
    My end point status says that Less Secure Protocols are still unhealthy. How do I get my endpoint to a Healthy state and what is with the SSL Functions? I see no information on how to set this option.
    I used this link for the IE GPO:
    https://technethub.com/disable-tls-1-0-and-tls-1-1-on-windows-10-pc-through-gpo-2/
    I used this link for the registry settings:
    https://docs.oracle.com/cd/E72933_01/doc.462/E71108/index.htm?toc.htm?208092.htm

    Thank you.

    1. @ServerGeek,
      Sean is traveling and will return next week. Hopefully he will have an easy solution for you. Thanks for your patience.

  2. I figured it out. Setting TLS 1.2 to 1 & 1 as suggested in the Knowledge Summary of the mgmt. pack caused me to lose heartbeat. When setting Disabled by Default to 0 and Enabled to 1, my endpoint is now healthy. Thank you.

    1. Hi servergeek, thanks for bringing this to my attention. Its a typo in the knowledge base. The only required setting for TLS 1.2 is Enabled with a value of 1. No DisabledbyDefault value should be in your registry settings for TLS 1.2 I will update it!

  3. Hi Sean – 2012R2…all settings match requirements, but Strong Crypto and App Default Security remain in unhealthy state. Any advice/recommendations? Thanks

    1. There are 4 Keys in the KB article that are tested for these values. Look at the KB and ensure you have made the setting in all 4 places. Also if you manually generated the keys check your spelling of the value names.

  4. Thx for is MP !!
    We see this in our Production Environment
    Clusterressources are also checked

    A suggestion from our Windows Prod team:
    create a Powershell task to check the compliance in the Task-View

    1. Thanks for the feedback! A task to check compliance over the monitor? Also, heads up there is a 2.0 version dropping sometime this week with some positive changes in the MP.

  5. My company is currently going through an implementation of disabling TLS 1.0 but not TLS1.1 (not yet). I like this MP to be able to see in a global view all the configurations. I don’t see a way to override individual protocols (say for example I don’t want to monitor the state of TLS 1.1, or maybe I have to have it enabled for a specific one off app). Any plans to implement individual overrides?

    1. Its been discussed but not at this time since the focus of the MP is TLS 1.2 Compliance. You could use the MP to guide your remediation and when 1.1 is the only remaining unsecure protocol remaining you could create an override to ignore that machine or group of machines.

      1. As long as we’re offering workarounds, you could simply unseal the MP and modify line 346.
        Change this: $BadProtocols = @(“SSL 2.0″,”SSL 3.0″,”TLS 1.0”, “TLS 1.1”)
        To be this: $BadProtocols = @(“SSL 2.0″,”SSL 3.0″,”TLS 1.0”)

        OR if you wanted to be slightly fancy, you could simply make $BadProtocols an overridable parameter for the monitor so that you could control which protocols are “bad”.

        1. Thanks! Right now, I have the monitor turned off and I’m using it to help us guide through the configuration. It gives us a quick glance to see how things are looking.

  6. I take it the monitor does not take into account the different default tls settings based on operating system version?
    IE: 2008 needs reg entries to turn on tls 1.2, while server 2016 does not.

    1. That’s correct. This does not fully evaluate Windows server 2008 or 2008r2. There are some caveats for Windows 7 and Server 2012 addressed in the MP guide as well.

    1. DisabledbyDefault = 1 Means its not enabled(by default) but will negotiate the request. Its important to understand this. To FULLY Disable you must have the other setting.

      Disabling any protocol requires Enabled = 0 AND a value for DisabledbyDefault. This could be a 1 or a 0. both would be correct but you cannot just have the Enabled = 0 setting you must also have a value for DisabledByDefault. By default I look for 0 as per the docs site example.

      1. Thanks Sean, yes I understand how to fully disable using the other setting – I am only asking about the DisabledbyDefault setting here – as I still interpret as it should be set to 1 to disable it by default (and of course set the Enabled to 0 to fully disable the protocol).

        I have raised it with the docs site too, as their examples contradict themselves. e.g. they say
        “To disable TLS 1.0 by default, create a DisabledByDefault entry and change the DWORD value to 1. The following example shows TLS 1.0 disabled in the registry” but then it shows DisabledByDefault set to 0 in all of their pictures!

        I also use Kevin Holman’s TLS lockdown script for SCOM Management Servers, which sets this to 1:
        https://kevinholman.com/2018/05/06/implementing-tls-1-2-enforcement-with-scom/

        I will post back when I get a response from Microsoft on their article.

        Thanks

          1. I have a response back from the people behind the article on the Microsoft site. They have had a lot of feedback around that article!

            My feedback request is here: https://github.com/MicrosoftDocs/windowsserverdocs/issues/4926

            Their final summary below basically states that setting DisabledByDefault=1 is the “clean” way for that setting to have it disabled by default (which is what Kevin Holman has also done for his script) BUT they are also saying that in regards to DisabledByDefault, that it is as a subset of the Enabled=1 setting and that Microsoft make things difficult with double negation and further complicates it with dual flags overriding each other.

            As we too set it the “clean” way like it is in Kevin’s SCOM TLS lockdown script, DisabledByDefault will be set to 1 – which means the monitor in your Management Pack will always alert this as Non-Compliant, as it expects this value to be 0.

            QUOTE from https://github.com/MicrosoftDocs/windowsserverdocs/issues/4926:

            “So, back to your question, while the clean settings for a completely disabled protocol are:

            – DisabledByDefault=1 (Disabled by Default)
            – Enabled=0 (Disabled)

            in reality, the following combination also completely disables the protocol:

            – DisabledByDefault=0 (Enabled by Default)
            – Enabled=0 (Disabled)”

            Your previous comment is in line with this too Sean, however my interpretation of all of this is that setting DisabledByDefault to 1 is the clean way to do it which ideally the monitor should be configured to look for.

          2. Steve are you running the most current version? We did address this after the rev 2 release. The compliance monitor expects DisabledbyDefault to be 1 OR 0.

            I understand your point however both settings are correct and achieve disablement. Thank you for all the research and follow up on this.

  7. Thanks Sean – yes I am running version 2.0.0.1 and the “TLS Compliance Monitor” Product Knowlege states that it expects DisabledByDefault to be “0”, but for us that will never be the case and could cause confusion. But nevermind as I might override the monitor anyway and just use the views and reporting functionality of the MP.

    At least Microsoft said they will be updating their article to reflect the clean way is to have it set to “1” anyway, which is what we have.

    Cheers for the MP though – good stuff!

Leave a Reply

Your email address will not be published. Required fields are marked *