3 Replies Latest reply: Apr 20, 2017 10:35 AM by zaneta22 RSS

SecurityCenter 5 SQL credentialed Scans

djs75 Novice

I need to do credentialed SQL Scans from SecurityCenter. My issue is that SecurityCenter does have the option when creating a Database account to select the Windows authentication type (NTLM Hash or kerberos)(it does have the options under windows but these do not extend to SQL windows authentication), it only attempts LM. Using just a Windows account with Kerberos or NTLM Hash without a Database account fails. The sa account is disabled and can not be used per the hardening requirements. I logged into the Nessus scanner and was able to successfully troubleshoot the cause as Nessus has the option to be more granular on the database account, but it does not resolve the issue of managing it from SecurityCenter. Additionally, Nessus has the ability to pull from a Password Policy servers like CyberArk and Thyotic Secret Server, where SecurityCenter does not, the windows type authentication can be set on these solutions.

 

Is there any effort to align these settings betwen Nessus and SecurityCenter to make it more consistent?

  • Re: SecurityCenter 5 SQL credentialed Scans
    zaneta22 Expert

    The only way I was actually able to get a credentialed SQL scan was with my actual domain admin account which is not allowed so I just do  not do it anymore. I had to create a test server for scanning to see what the issue was. When trying to scan from security center with the service account it was changing the account username once it got to the database. So if I used acasscan account and check the sql logs it would show as administrator. My domain account was the only account allowed to scan through security center, nessus, and then into the server and any instances on it.

    • Re: SecurityCenter 5 SQL credentialed Scans
      djs75 Novice

      I agree "Domain Admin" is unacceptable. The windows account I am using has "sysadmin" rights within SQL. The same account was used from the Nessus scanner and on SecurityCenter. The problem I ran into based on the logs - outlined above is that SecurityCenter errored on the SQL authentication with Windows event id 4776 and 4625. These events directly relate to enforcing NTLMv2. As stated above, from the Nessus Scanner Kerberos and NTLM Hash successfully perform the SQL audit as the option is there for credentials . When attempting to do this on SecurityCenter when you create a DB account and select Windows Authentication - you do NOT have the option for NTLM Hash or Kerberos, only password, which a hardened SQL server will cause to fail authentication. ACAS as a DoD provided tool means you need to abide by DISA IASE STIGS and your GPO as mentioned would force Kerberos or NTLMv2 for authentication, so like me you would need them to be consistent or schedule it at the Nessus scanner. Scheduling at the Nessus scan defeats the point of centralizing management in SecurityCenter.

       

      Hence, my question on the original post, is there an effort to align the user experience?

      • Re: SecurityCenter 5 SQL credentialed Scans
        zaneta22 Expert

        "Hence, my question on the original post, is there an effort to align the user experience?"

         

        I have been battling this for some time and it only seems to be getting more difficult as the product versions change. Maybe someone else knows another way this can be completed. There use to be an option where I could add it in the actual scan policy but that has Mongo as one of the systems to authentication.

         

        If I get this figured out I will let you know. They have a lot of authentication methods in the new security center but there are no directions on how to actually use them. I am going through each one and testing them one by one to make a reference guide for myself. Most of them I am struggling with.