Video walk-through for SVM on-premises customers who need to check their Vulnerability Manager Tracking database has synchronized with Flexera. Commands mentioned in the video:- Connecting to the Database console mysql -u root -p Listing the Databases show databases;  Selecting the "vuln_track" database use vuln_track The query select max(vuln_create_date) from vuln;   ... View more

The subject of PKI Certification is quite extensive and the cryptography behind it is the realms of mathematics and science and can seem like a mystical black art to most, but to make use of certification and understand how it applies and how to use it within your environments does not require an understanding of cryptography or a computer science degree, this article aims to provide some general understanding of the of where certificates apply to Software Vulnerability Manager. So what is certification used for? Certification is used to ensure a level of trust between one point and another and is used for encryption of data traffic between two points, you will be familiar with SSL/TLS and the lock in your browser when you access a trusted website.  Most modern browsers will not let you access websites that are not secured with a valid certificate. Certification is also used as a proof of trusted identity, most commercial software will be code signed so that your PC can guarantee the software has come from a trusted source, and also software such as hardware devices drivers, in Windows 10 these have to be signed or you cannot install them. Certification Authorities A certificate authority is the holder of the “root certificate” by which all certificates generated by the authority is based upon, and by which all certificates that have been issued can be verified against.  It is also where you request and obtain a certificate.  The certification authority also maintains the “Certificate Revocation List” which as it states is a list of certificates that have been revoked by the authority for whatever reason. There are public certificate authorities that exist on the internet, and there are private certificate authorities that exist on a corporate enterprise network.  Public Certification Authority needs to be used when you want a certificate to secure a connection to a publicly accessible website. These authorities verify the identity of the certificates applicant (you or me, or the company) and issue a certificate that is publicly verifiable, which means that the third party accessing your website can check that the certificate is valid and has not been revoked. The verification process is automatically done by your browser before the website loads.  Software developers will also request Code Signing Certificates from these public authorities for signing their installer packages that it intends to make available to the public. A private Certification Authority usually exists within a corporate enterprise network, it is responsible for the issuance of certificates for various purposes, such as securing internal intranet sites, securing access to internal web-based devices, client authentication, and lots of other purposes where an encrypted secure connection is required between one to one and one to many scenarios, or where a trusted identity is required. Within a corporate network it is quite common to find a certificate authority hierarchy, meaning there is a Root Certification Authority (Root CA), and Subordinate Certificate Authority (Intermediate) the subordinate certificate authority issues certificates on behalf of the Root Certification Authority.  In Windows-based domain networks, the Root Authority is generally shutdown with the subordinate issuing all of the certificates. If a Certificate Authority exists on your corporate network, copies of any root certificates and intermediate certificates are generally distributed to all the computers on the network by a group policy, the reason for distributing the root and intermediate certificates is so that computers on your network know to trust any certificates issued by the root or intermediate authority. These certificates will exist in the Trusted Root Authority & Intermediate Certificate Authority containers in the certificate store for the local computer account on all of the corporate machines. What is the difference between a PKI Certificate and a Self Signed Certificate? You will come across the term self-signed certificates within the documentation so to help you understand the main differences. Self-Signed Certificates Self Signed certificates are generated on the computer that you are intending to secure, there is no certification authority issuing the certificate, they cannot be renewed, they cannot be revoked, Self-signed certificates must be distributed to all the other computers Trusted Root Certification Authority stores in order for them to be trusted by any other computer or device.  They are fine to use and where a Certificate Authority does not exist and is indeed required. PKI Issued Certificates These are issued by your enterprise Certificate Authority, they can be renewed when they expire, they can be revoked by your administrator if required, and provided the RootCA Certificate and any intermediate CA certificates have been distributed to devices are automatically trusted. So no need to separately distribute the certificates.  The only caveat in Windows networks that if you have a Code Signing Certificate issued by your PKI Certificate Authority the public key certificate must be distributed to the client computers “Trusted Publishers” store for the local computer account. So how does all this apply to Software Vulnerability Manager ? In SVM we use certificates in 3 ways:- SSL Certificate for the SVM Console (On-Premises SVM Server) to secure the browser connection between the SVM Server and the console operators computer Code Signing Certificate, used for signing packages delivered to WSUS from SVM so the packages can be trusted by the client PC’s and are allowed to be installed. Certificate Authority Root Certificate, so that the SVM Server can trust certificates on the local domain, required when configuring LDAPS SSL Certificate for SVM Console (On-Prem Only) To secure access to the SVM Web Console and your PC, you will need to acquire and install a Web Server SSL Certificate that has been issued by your internal certificate authority to the web address that you intend to use for your SVM Server, the web address (svmservername.domain.local) is applied to the certificates common name field in the certificate request. T he certificate will need to be supplied to you by your certificate administrator in PFX format (PKCS#12) which is a file that contains both the Private and Public Keys. To install the certificate on your on-premises SVM Server please see our current product documentation This document tells you how to import your PKF File into your Linux Server https://docs.flexera.com/csionpremredhat/Content/helplibrary/Import_Your_Own_SSL_Certificate.htm#rhel_ssl_ldap_2379745888_1047666 This document covers how to configure SVM to use SSL https://docs.flexera.com/csionpremredhat/Content/helplibrary/RHEL_7_2.htm#rhel_ssl_ldap_2379745888_1048375 Code Signing Certificates As mentioned earlier in this article, Code Signing Certificates are used to sign software installation packages so that they can be trusted by the computers to which the software packages are to be installed. When a patching package becomes available within the SVM console to fix and patch discovered software vulnerabilities these packages must be published to your local WSUS Server so that they become available within your System Centre Software Update Point, so they can be subsequently deployed to computers. Part of the publishing process is to sign the packages using a code signing certificate before the package is delivered to the WSUS Content Store and appears in the WSUS Database. I have covered creating an installing a Windows Certificate Authority Code Signing Certificate in another KB article, which gives you guidance on how to successfully create and install a Code Signing Certificate for your WSUS Server. https://community.flexera.com/t5/Software-Vulnerability-Manager/Creating-Windows-CA-Code-Signing-Certificate-for-WSUS/ta-p/149698 Although the above article mainly covers creating the Code Signing certificate, it contains the information on how to successfully install the certificate even if this has been obtained from a non-Windows CA Root Certificate for LDAPS The SVM Console can be set up to verify logins using your Windows Active Directory or another type of LDAP server, as this is the exchange of login information between your AD and the SVM Server it is recommended that you configure LDAPS (LDAP Secure).  For LDAPS to work you will need to copy your Root Certificate Authority Certificates and if applicable any Intermediate Certificate Authority Certificates to your on-premises SVM Server. These need to be copied to the directory  “/etc/pki/ca-trust/source/anchors” on your SVM Server, then you need to run the command “update-ca-trust” which will update the CA Trust bundle and this will allow the SVM server to trust the LDAPS server on your local network the SVM Server is querying for logon information.       ... View more

Summary This document reviews the functionality of Cloud Management Gateway and if it supports third-party patches published by vendors like Flexera Software Vulnerability Management. A recent request by one of our Partners as to whether the scenario of using Software Vulnerability Manager to deploy patches and updates to remote machines via Microsoft’s Cloud Management Gateway product for Microsoft Endpoint Configuration Manager (SCCM). An initial review of the Cloud Management Gateway documentation was undertaken to find out what exactly CMG was and what it did, this led to the opinion of “Yes” and that our SVM product can deploy updates and patches to remote client machines via CMG.  But without actually testing it and proving the concept we were not in a position to say “Yes” for definite, but that we believe that it would and that we would test and prove it for ourselves. Cloud Management Gateway For those familiar with SCCM and how it works you will also be very familiar with Distribution Points and Management Points, well to put it plain and simple it is a Management Point and Distribution Point in the Microsoft Azure Cloud for deploying software, updates, and patches to remote machines that are part of your enterprise network but are not connected to the network directly or connected via VPN. This takes the headache, the risk, and the cost out of having to try and expose your Enterprises internal SCCM infrastructure to the internet. Why do I need it? The requirement for this has become greatly highlighted in the recent situation where employees are having to Work from their home, by deploying CMG Enterprise Administrators can still manage these remote machines, deploy software to them, deploy updates and patches, and also Compliance & Configuration settings without having to provide VPN’s or exposure the internal infrastructure as mentioned above. What we did In order to prove that CMG would work with Software Vulnerability Manager, we created a mini enterprise environment consisting of a DC, CA, SCCM/WSUS/SQL, and a selection of Windows 10 clients. We also required a cloud subscription to Software Vulnerability Manager**, a Microsoft Azure Active Directory account which is free. To implement CMG we needed to upgrade to Azure Active Directory P2 Premium so we are able to configure Device accounts with the Azure Active Directory (AAD) , this is termed as a Hybrid Azure AD Joined account, this means that your machines are both joined to your Windows Domain and to your Azure AD at the same time. The purpose for this is to give your remote machines an identity in Azure that corresponds to the on-premises computer account,  the reason for the auto-enrolment is so that domain-joined machines will do this automatically when you add them to your Windows domain.  We also need a subscription for Azure Services and that the subscription is enabled to purchase other cloud services, as part of the CMG deployment process is the creation of a resource group, a virtual machine which hosts the CMG Web Service, and storage (for Updates to be stored and to host the VM), the two services that need to be enabled within the Azure subscription are Microsoft.ClassicCompute & Microsoft.Storage. The services don’t need to be created manually the subscription just needs to have them enabled so that the services can be created in Azure during the CMG deployment process. The use of an internal PKI Infrastructure is required for the setup, in our test environment we have a Root domain and our root Domain uses PKI and has a certification authority (CA) configured as ROOT CA, A certificate authority server has been created in our child domain and this has been configured as a subordinate (intermediate) certificate authority of the Root Domain this means we have a certificate chain to consider.  Part of the configuration process of the CMG requires the use of our Domain Enterprise PKI,  as we need to issue a web server certificate which will be applied to the CMG Web Service that the remote clients will connect to and you will also need the Root certificates and the immediate certificates in the chain that apply to your environment, Client Authentication certificates will be required to be issued to the client machines on the domain, this is a requirement of SCCM anyway, so if you are already using SCCM this should already be done, the client machines should already have the Root Certificate and the Intermediaries already deployed to them as part of them being set up for Client Authentication certificates, I would always check to be sure. We also needed an external public domain name to work with so that we could create some DNS Server entries for the cloud services.  For our test domain, we purchased a new domain for this purpose the domain is “secuniacmg.co.uk” and we have configured the DNS Servers for this domain to be the Microsoft DNS Servers the reason we used MS DNS is mainly for ease as using Microsoft DNS means that all the domain configuration DNS entries that are needed for the Microsoft Services such as Enterprise Enrolment are created automatically as part of adding the public domain to Azure, and also we can manage the domain within the portal this also means will be only 1 entry that we need to create manually for the CMG Service, which will be a CNAME record that points to the Azure CMG Web Service URL (yourcmg.cloudapp.net) that is automatically created by the CMG service deployment to Azure. In regard to what changes are required for the configuration for our Software Vulnerability Manager product to support CMG, well the answer to this is nothing, provided your SVM Solution is currently able to publish updates to WSUS/SCCM and is working, there are no changes that need to be made to the configuration of SVM.  ** CMG can work with an on-premises SVM Server, but in order for the SVM Agent that is installed on the client machines to communicate scan results back to the on-premises SVM server a VPN would be required, or alternatively use the SCCM Inventory Import Function within Software Vulnerability Manager to collect client machine software inventories. The Lab Environment   The Domain we have created in our mini enterprise environment, our test environment domain is a child domain of a root Enterprise Domain called “flexdev.com”, our child domain is “secunia.flexdev.com” This domain consists of:- svmsup-dc-01.secunia.flexdev.com ·        Domain Controller ·        DNS ·        Global Catalog svmsup-ca-01.secunia.flexdev.com ·        CA Authority – secunia.flexdev.com svmsup-sccm-01.secunia.flexdev.com ·        SCCM Site Server ·        WSUS Server ·        Software Update Point ·        Distribution Point ·        Management Point etc. svmsup-fs-01.secunia.flexdev.com ·        To run Azure AD Connect   Microsoft Azure Tennant For this lab test we also have created a tenancy in Microsoft Azure, with a subscription to Microsoft Azure AD P2 Premium. Domain Name & DNS Records If your domain already exists and is hosted on external DNS Servers, and not Microsoft DNS Servers you will need to configure all of the DNS records required for Enterprise Enrolment. Please see this article: - https://docs.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider?view=o365-worldwide Once your domain DNS records are configured for Microsoft 365 services and that the domain has been set up correctly within Azure. This article explains further the configuration to configure your domain name for Azure AD https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain#:~:text=Add%20your%20custom%20domain%20name%20to%20Azure%20AD,-After%20you%20create&text=Search%20for%20and%20select%20Azure,Select%20Add%20domain. Once the domain is configured in Azure, the next stage is to create a synchronization between your on-premises enterprise Active Directory and Azure AD Azure AD Connect Azure AD Connect tool creates a regular synchronization of on-premises Active Directory Objects to the Azure AD, the first stage is to install the tool on a member server, in our lab environment a server has been created specifically for this purpose, do not install AD connect on a Domain Controller as you will not be able to amend the AD Connect configuration afterward which you will need to do later to configure Hybrid Domain joins. The Microsoft article below explains further details for Azure AD Connect along with some “how to’s”, but for the first stage is getting the user's synced https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-azure-ad-connect Once you have configured AD connect and it has done its first synchronization you will be able to see the synchronized users in the Azure Portal. Azure AD Connect – Hybrid Domain Join The next part is to get the machine accounts synchronized, where machine accounts are concerned they are not actually synchronized they are registered (enrolled) within Azure AD as Hybrid Joined. To configure this you will need to revisit the AD Connect configuration as per this article: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-device-options Once configured and figured and synced (which will take some time) your devices should appear in the Azure AD as below:-   To summarise, the Azure Active Directory and Device Hybrid Domain join must be configured correctly and in place before you configure CMG components within SCCM PKI Pre-requisites. All machines must have Client Authentication Certificates issued by their enterprise CA All machines must have the Enterprise CA root certificate, and any intermediate certificates that may apply to your environment deployed to the relevant stores. A Web Server certificate will need to be generated from the Enterprise CA which will be applied to the CMG Web Service. https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/certificates-for-cloud-management-gateway You can use a public certification authority for the CMG Web Service Server certificate, but in our test environment we have used our internal PKI IMPORTANT NOTE: If you are using your internal PKI it is unlikely that your Certification Revocation Lists will be publicly available. During the setup of CMG there is a checkbox which is checked by default for Verify Certificate Revocation, this must be unticked. Also during the CMG setup you will be asked for the Enterprise Root Certificate and any intermediate certificates that are applicable. Azure Subscription Within your Azure tenant, you will need to create a subscription, this article explains how to create a subscription https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription Once the subscription is live, you will need to enable two Azure Services within resource providers, the two services that are required are Microsoft.ClassicComputer & Microsoft.Storage This article gives you some guidance on enabling these resources. https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types IMPORTANT For the CMG to deploy successfully, the Azure user account used to create the CMG Service within SCCM must be the same user account that is the owner of the subscription, this user also needs to be a Global Administrator within Azure. You can add additional owners to the subscription to do this, this article explains how to make changes to the subscription administrator. https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/add-change-subscription-administrator Setup CMG This is the main article from Microsoft for setting up Cloud Management Gateway, it does cover several of the points that I have mentioned in this document. https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/setup-cloud-management-gateway       ... View more

1.0         Code Signing Certificates. The purpose of code signing is a method to prove the origin of an item of software that came from a trusted source and that it has not been tampered since it was released by applying a digital signing to the software package. In the case of Windows updates, the update files that sync from Microsoft to your WSUS Server are already digitally signed by the vendor, as is all device drivers from hardware vendors, and all software that you may download from other trusted software vendors.  The Windows operating requires that these items are all digitally signed before it will permit their installation. How this applies to the Software Vulnerability Manager System is all patches that are delivered to your SVM console are delivered as an SPS Package ready to be created into an install package for deployment, with certain configuration options.  During the creation of an installation package that is to be deployed to your client machines, the WSUS Server digitally signs the packages that are created before publishing them to your WSUS server, ready for deployment using either WSUS or SCCM. When an update or a patch is installed the client machine verifies that the software has come from a trusted source by checking its digital signature, if it isn’t digitally signed or if the certificate to which a package was created using has expired the software will fail to install. It is quite critical for the functionality of the SVM System that certificates are created and applied to the WSUS correctly to prevent publishing issues. There are three ways of doing this, the first being is to obtain a code signing certificate from an external Trusted Certificate issuer, but this can be expensive, and this would only be required if you were wanting to make your WSUS Server public on the Internet.  We will not cover this scenario in this document as it is a highly unlikely scenario. The second is on Windows enterprise networks that run a root Certification Authority to request a code signing certificate from the Root CA.  We will cover this scenario in this document. The third method is to use a WSUS self-signed certificate generated by the WSUS server itself using the SVM connection tool contained in the console plugin. Note:  If using a self-signed certificate, you will need to distribute the certificate to the client machines using a GPO, this is covered later in this document. Important Note: Creation and management of certificates will require a user with Administrative Privileges on the domain. 2.0         How to generate a Windows CA Code Signing Certificate for WSUS Code Signing Purposes. The process of creating a Code Signing Certificate is in two parts, the first part is the configuration that will need to be undertaken is on the Windows RootCA Server, and the second part is the requesting of the certificate from the RootCA on the WSUS Server.  Please ensure you have administrative access to both of these servers before continuing. 2.1         Windows Root CA Server Connect to your Windows RootCA server and navigate to the Certificate Authority Console.     The first thing we need to do is to create a code signing certificate template, we achieve this by selecting certificate templates in the left-hand pane and right-clicking to bring up the menu.     Now click on “Manage” and this will bring up the Certificate Templates Console 3.0         Certificate Template Console Once the Template console has loaded look for the Code Signing template that is in the Templates list   Right Click on the Code Signing Template, and select “Duplicate Template” as shown below   Once you click Duplicate Template, the template configuration will display. 3.1         Certificate Template Configuration There are several tabs within the template configuration that you need to set the first tab to pop up will be the compatibility tab as below:- Compatibility Tab No changes are required on this tab, please click on the general tab and see below Click on the “General” tab General Tab Give the certificate template a name, in this case, I have just used “WSUSCert” as the name. Set the validity period. I have used 5 years, but this can be set to a period of your choice, it makes sense to use a long validity time as this ensures all your published patches will continue to work for a long period. Click on Apply Request Handling Check Allow Private Key to be exported, this is very important that it is ticked. And select “Prompt the user during enrollment” Click on Apply Subject Name Select “Common Name” in “Subject name format” Only select UPN in the checkboxes below Click on Apply     Security Tab Make sure you allocate permissions for a specific user or user group to be able to Read & Enroll, this example shows authenticated users with these permissions. Click Apply Extensions Tab Select Key Usage and then edit and see the next screen.         Edit Key Usage Make sure that “Digital Signature” & “Make this Extension Critical” are both checked Click Ok on the box, or cancel if no changes need to be made. Click on Apply on the Extensions Tab   Once this part is complete you can now close the Certificate Templates console, and return to the CA Console, the next part is we need to issue the template so that it becomes available to the users to be able to request a certificate. 3.2         Certificate Authority Console – Issuing Template. Right click on the Certificate Templates, Select New then select Certificate Template to Issue   Once you have selected New Certificate Template to Issue, the list of available templates will be displayed as per below, in the list find the name of the template you have just created, select it and click ok. Your new template will now appear in the Certificate Templates container in the main Certification Authority Console   This completes what needs to be done on the CA, you can now log off your CA Server as you should not need to connect to it again during this process unless you have a domain certificate policy that requires Certificates to be approved on the CA. 4.0         Requesting a WSUS Code Signing Certificate The next part needs you to log on to your WSUS Server, the first thing that we need to do is to open an MMC Console. Right Click on the Start menu and select run.    When the MMC Console has started, select File then Add/Remove Snap-in Add the Certificates snap-in   Check “My User Account” and click “Finish” To request the certificate, first select the “Personal” folder in the left-hand pane of the Certificates console. Right click on the “Personal” folder and select “Request New Certificate” The certificate enrollment Wizard will now start, once the following screen appears click “Next”   By default the Active Directory Enrollment Policy is present, you should not need to make any changes on this section, please click “Next   When the types of certificates box appear, look for the Certificate Template you created earlier on the CA, and Check the Template, it should be showing as per the box below. Click on “Enroll” When you have clicked Enroll you will be shown the results of your request, it should show succeeded.   Your new Code Signing Certificate will now appear in the “Personal\Certificates” folder as below   5.0         Exporting the Certificate. The next part of the process we need to export the certificate to a file along with its private key, click on certificate to select it then right click, and select “All Tasks” then “Export”   5.1         Certificate Export Wizard. To continue, click “Next” Select “Yes, export the Private Key” Click “Next” Make sure “Include all certificates in the certification path” is selected. Make sure “Export all Extended Properties is selected. Type a password and confirm it and Click “Next” Click “Browse” Select a location to save the certificate, I would suggest creating a folder on C:\ and saving it there.   With the filename and path completed click “Next” Check what is displayed looks ok and click “Finish”   You should now get a message saying that your Certificate Export was successful 6.0         Importing Certificate into WSUS / SCUP PKI generated certificates can only be imported into WSUS using a PowerShell Script.  Open Powershell as Administrator on your WSUS Server. 1. Open up PowerShell as Administrator on your Upstream (Primary) WSUS server, or Software Update Point of SCCM. 2. Run the following to set the WSUS server and its configuration to an object. [Reflection.Assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") $updateServer = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer() $config = $updateServer.GetConfiguration() 3. Next, run this snippet to set the new code signing certificate. $config.SetSigningCertificate("<Path to pfxFile>", "<PFX file password>") Bear in mind, this will be a file with both the public and private keys (pfx usually). You'll need to replace the path and private key password within the placeholder values in quotes. 4. Now save the changes. $config.Save() You will need to resync your Software Update Point to make the certificate display in the Software Update Point Configuration. 7.0         Troubleshooting Certificate Stores (WSUS Server) If you have been running with a WSUS Self Signed Certificate and are looking to move to use a PKI Certificate generated from your Enterprise Windows CA, once you have installed the certificate as above, please check the WSUS Certificate Store for the Local Computer Account, to make sure you are only showing the one certificate in the WSUS Certificate in this store and this should be the Certificate you have generated from your CA this Certificate should show you have the Private Key that corresponds to the certificate, there should be no other certificates in this store, also check that the certificate is appearing in Trusted Publishers without the Private Key. WSUS Certificate store for Local Computer Account   Showing Private Key Software Update Point If you are having difficulties with synchronisation, sometimes this can be caused by the software update point not importing the certificate into the SCUP which it does during synchronisation. To resolve this you need to open the SUP and remove all the classifications, then resync the SUP it might take a couple of goes to get it to work,  it will start a sync import the certificate as there are no classifications to sync. You can check that the certificate is the correct one by checking the Third Party Updates tab in the SCUP configuration to see if the certificate has changed to the correct one. Once it appears re-enable your classification and resync the SCUP. The two logs to check for the above issues are “wsyncmgr.log” and “wcm.log”   SUP Showing PKI Certificate after Software Update Synchronisation ... View more