It’s good to read news reports that departments and agencies like NASA and the U.S. State Department have recognized the value of real time, continuous monitoring and rapid threat mitigation instead, and are pushing for more of the Fed to move in that direction. Stonesoft’s own recommendations are along those lines.

Security truly is a process at the end of the day and any tools that facilitate that process should be considered. Geographic mapping of events in real time, effortless log data management and forensics analysis, visualization of events in both physical and virtual environments and all wrapped up in a centralized management center is the way to go. Of course, our own StoneGate solution is designed this way too.

Do you think the new direction of the Fed is good or bad? Stop by Booth 33 at <a href="Black Hat 2010 this week in Las Vegas and discuss it with us. We’d love to hear from you! Or come learn more about network security. Simplified.

The whole idea behind WIL is that a backend Internet Information Server (for example) protects a web path with this technique called Windows Integrated Login.

When a browser attempts to reach it, the web server sends back a challenge for authentication. These credentials are taken from the Windows environment, allowing authenticated users of a given domain to access smoothly.

Other users will have to insert credentials in a popup windows that will appear, getting a HTTP 401 – Unauthorized if validation fails.

To configure a virtual web server or a path as protected with WIL on windows 2003 Internet Information Server is fairly easy.

First, you need to access to IIS Manager console, to browse the various settings available.

Right click on the virtual web server you’re interested in and select Properties. Click on Directory Security tab as shown below:

Uncheck Enable anonymous access and check Integrated Windows Authentication.

Then apply changes to IIS and if needed restart the service.

To configure Windows Integrated Login on StoneGate SSL VPN, access to Administrator interface, click on Manage System and on Authentication Methods.

Add and authentication method of Windows Integrated Login type, give it a name and click on Add Authentication Method Server… and fill in values as detailed below:

• Host => this is the IP of the protected web server where Windows Integrated Login is active
• Port => this is the port the web server is listening to
• Path => this should match the path on the web server where WIL is activated. If the whole web server is enabled for WIL, then type a forward slash (“/”) in this field.
• optionally, it is possible to enable SSL communication and to select the CA to validate the server certificate.

Finally, proceed to create the web resource you need to access using WIL Authentication Method.

Save configuration and Publish.

To test, access to application portal selecting the Windows Integrated Login authentication method. If the domain you are in is not matching the credentials that authentication method server expects, you will be prompted to insert username and password in a popup windows. WIL authentication will be automatically handled when you will click on the resource you want to access.

Secure access to applications with SSL VPN and Windows Integrated Login. Simplified!

As many YouTube videos demonstrate, you never know when someone may be watching. A good thing to keep in mind at Black Hat as well, particularly when you are using a laptop or other mobile device. Be mindful of the fact that hackers may be watching your screen and your fingers as you type. From this they can capture information off your screen and capture your logins and passwords for use later on. Often this hack is accomplished by using a video camera on a cell phone or by pretending to take a picture of a nearby attraction. So keep your fingers covered as much as possible, and be prepared to change your passwords often. If you can avoid using your laptop or smartphone in open areas, do so and reserve the work for after you return to your hotel room or other private location.

Black Hat has also been famous in the use of social engineering and ATM hacks. There’s a presentation on ATMs at this year’s conference. Be sure to avoid any stand-alone or third party ATMs within the casinos, or any ATM that is not at a bank branch office. These stand alone ATMs can be cheap copies, or purchased off eBay or other sites, and reconfigured to capture your account data, while providing no money.

Just one more quick review: turn off wireless and Bluetooth on all devices whenever possible. Avoid wireless if at all possible, and use a 3G cellular modem instead. Be careful typing in passwords, and also what you work on while in open areas. Don’t trust ATMs or storage devices of any kind. Keep your mobile devices up to date with the latest software updates and patches, and use encryption and firewalls whenever and wherever possible.

Remember to enjoy the conference and have a great time knowing you won’t be joining others on the Wall of Sheep!

The X-Files principle of Trust No One holds true in this case as well. We all love schwag, whether it’s simple things like stress balls, to more advanced things like iPad giveaways. In between everyone loves to pick up those USB sticks, which can be plain and simple or disguised as cute animals. But be careful, those animals can turn on you. In general, for a safer computing experience at Black Hat, do not trust any storage device handed to you by others. Whether it’s a USB drive or CD, or anything else (even that iPod you just won), they can contain viruses, Trojans or malware of any form. Even the ones that look professional can be dangerous. At best it’s good to discard them; if not at least scan them on a separate, up-to-date, sacrificial system first.

Second, if you are bringing a laptop, install and verify the operation of full-disk encryption software. Use AES-256 bit encryption or better. If the hard drive has a hardware encryption option as some external ones do, use that instead. And while you’re at the conference, be sure to power off or hibernate your laptop whenever it isn’t in use to maximize the effect of the encryption software. Free disk encryption programs exist, and modern Windows and OS X systems include encryption technologies built-in.

To learn more about computing safely, to try your hand at Hack The Lab, and to learn about Stonesoft’s award-winning network security solutions, be sure to stop by Booth 33!

Our first security tip for a safer Black Hat computing experience is about network security. We’re starting with this one since it’s the heart of our StoneGate network security solutions as well. While at Black Hat, try to avoid connecting to any networks, including wired and wireless ones. For wireless networks especially, don’t connect if you can help it, even if the SSID of the network looks trustworthy (for example, it looks like a network operated by the casino…it may not be). If it’s possible to use a cellular modem instead, it is recommended to do so. If you do need a network, remember that any communications can potentially be intercepted, and passwords and logins should not be sent in clear text.

If you do connect, be sure you are using a VPN with strong encryption and that your laptop or mobile device is up-to-date with the latest patches and updates, and that a firewall and virus scanner are installed, updated and operational. If you don’t need it, be sure to turn off wireless and Bluetooth. If the devices you have use a hardware switch to disable these functions, use it instead of the software option. Whenever you are not using the networks, be sure to disconnect and disable the functionality on your device to reduce your risk exposure.

More tips for a safer experience at Black Hat will follow, so stay tuned!

Today we’ll cover a very interesting topic in this new world of cloud computing and webservices: the Ticket Single-Sign On.

As most of you might guess, Single Sign-On is a technique to perform login to backend applications and systems without the need to retype user credentials, once the user is authenticated and access is granted on the main application portal.

StoneGate SSL VPN supports a wide variety of Single Sign-On techniques for legacy and web applications, ranging from static, adaptive, cookie based, ticket-based and form-based SSO.

I already defined Ticket-SSO as a splendid idea in a previous post, but today I will detail configuration steps to take to implement this technique with a very well known web app in the cloud: Salesforce.com.

The first thing to do is to define in SSL VPN Administrator interface the resource SalesForce.com using the provided wizard.

To do this, click on Manage Resource Access – Add Standard Resource and select SalesForce from Other Web Resources group. Then click on Add this Standard Resource.

This will generate in few clicks a Web Resource and a Single Sign-On domain configured to use the Adaptive SSO technique.

Edit the Web Resource generated and perform the following actions:

• in General Settins, change the DNS name for SalesForce server to match your Organization’s need.
  (for example, login.salesforce.com or emea.salesforce.com)
• Remove port 80 from HTTP Port field
• In Advanced Settings, tab, type a star (*) in Cookies to Check field and ensure that Forward cookies between client and resource box is checked.
• Click Save to apply changes.

Perform a login in StoneGate SSL VPN as an authorized user and try to access SalesForce.com application from within the portal. This will allow the system to analyze SalesForce login page and populate the SSO domain with the needed data.

It does not matter that login to SalesForce is successful, since we will not use these credentials anymore with Ticket-SSO.

Go back to SSL VPN Administrator and click on Manage Resource Access – SSO Domain.

Edit the SSO domain generated by the wizard (should be something like “sfbsso-salesforce-<some-letters-and-numbers>”) as follows:

• Click on tab Domain Attributes.
• Change the item User name mapping to match your SalesForce username (mail). You can also reference this field with a User Storage attribute.
• Click on item Password, then click on Delete… to remove it and confirm.
• Click on Add Domain Attribute… and select Ticket from Attribute Name drop-down menu. Please note that other fields in item configuration become greyed out. Click on Add.
• Click on Save to apply changes.

Ticket SSO has an enormous advantage, it allows a form of federated authentication with no credentials travelling on the internet… and a direct conversation between StoneGate SSL VPN and the other Web Service to perform authentication.

This is different from SAML based Federation ID discussed in previous post, since in that case the user agent (browser) is used as a “router”.

To complete configuration for Ticket SSO, we need to enable the XPI Web Services interface on StoneGate SSL VPN and define a listening resource on the access point.

XPI Web Services configuration

Click on Manage System – Policy Service.

For each Policy Service defined, click on the Service ID definition.

In lower part of the screen, click on the checkbox Enable XPI : Web Services.

Change the port number to a value above well known ports, for example 4433, as shown below:

From Server Certificate drop-down menu, select a valid trusted certificate issued by a known CA (which you imported previously in the system).
Since this is the system which SalesForce.com will contact to perform authentication, if Server Certificate used here is not trusted by SalesForce.com the authentication will not be performed.

It is normal that the XPI WS listening IP address is 127.0.0.1, since we will be accessing through the access point via a web resource we are going to define now.

XPI definition as a Web Resource

The final step to activate this implementation is to configure a Web Resource in SSL VPN Administrator to allow access to XPI Services through Access Point in HTTPS.

Click on Manage Resource Access – Web Resources – Add Web Resource Host. Type the information in fields as described below.

Display Name => SalesForceAuth

Description => XPI Interface Server Resource

Host => 127.0.0.1

HTTP Port => <empty>

HTTPS Port => 4433

Application Portal Settings => uncheck the Make Resource available in Application Portal box.

Click Next.

Click Make public. Click Next.

Click Advanced Settings….

Ensure that Link Translation Type drop-down menu is set to URL Mapping. Leave all other settings as default and click Next.

Click Finish Wizard to create the resource.

The result should be another web resource listed as shown below:

Click on the resource you just created and on the right click on Add Resource Path… to specify the pointer to the Web Services interface.

In field Path, type ticket-sso/services/AuthenticationService and uncheck the box Make resource available in Application Portal.

Click Next and click Finish Wizard to create the path, which will appear below the resource named SalesForceAuth.

Configuration of SalesForce.com Account for Delegated Authentication

This section of the post covers the procedure to configure SalesForce.com account for delegated authentication.

To enable Delegated Authentication in SalesForce.com you need to have the enterprise version of better, or a developer account to test. Proceed as follows:

• Login to SalesForce.com (www.salesforce.com) using an administrative account and create a new profile with SSO enabled.
• Change the user accounts that should use Ticket-SSO to use this profile.
• Click on Administration Setup/Security Controls/Single Sign-On Settings.
• In Delegated Gateway URL, type in the URL where XPI Web Services are available for ticket validation
  (for example, /https/SalesForceAuth/ticket-sso/services/AuthenticationService">https://<your-dns-name>/https/SalesForceAuth/ticket-sso/services/AuthenticationService)

Once the above is configured, the system is ready to perform Delegated Authentication.

To test, log in your StoneGate SSL VPN system and click on the application you defined at the beginning of this post using the wizard and… enjoy secure, authenticated access to your preferred CRM!

Ticket Single Sign-On. Simplified!

In addition to Hack The Lab, we’ll also be featuring the StoneGate IPS component of the powerful, award-winning StoneGate network security solution. You can also register to win the VMware-certified StoneGate virtual firewall or IPS for a year for free!

Stay tuned here as well, as we post our security tips for a safe Black Hat computing event, or follow us on Twitter at @Hack_the_Lab and @Stonesoft_US. Or friend us on Facebook.

But I’m braking this silence now since there is a very important test we have done and I want to share with you all.

I have been assisting a partner in a project to implement federated authentication with our StoneGate SSL VPN solution combined with Microsoft STS (Security Token Service).

For those of you who don’t know what Federated Authentication (aka Federated ID or Brokered Authentication) is, I’ll sum it up by saying that it is a technique to access applications “in the cloud” (private or public) while keeping authentication “at home”.

In short, the idea is to request the access to the application to an entity called Service Provider (SP), who will redirect the user to an Identity Provider (IdP) for authentication purposes. As soon as the identity has been validated, the user is automagically redirected back to the SP who will let the user in because of the trusted relationship created with IdP.

In this post I’ll describe the lab test made with a great guy, hoping that this information could be useful to replicate similar scenarios elsewhere.

The main concept is displayed in the picture below:

StoneGate SSL VPN is acting in this scenario as a Service Provider (although it could play the other role as well), while we rely on Microsoft ADFS 2.0 on STS server for playing the Identity Provider role.

Prerequisites:

We need first to have for each server a Digital Certificate together with the public certificate of the CA who issued the certificate. This is needed to establish a trusted relationship between the two entities (SP and IdP).

Another thing to check very carefully is the clock synchronization, since too high time skews between IdP and SP makes the SAML token unusable, therefore SP authorization to access the protected application will be denied.
As a good rule of thumb, use time servers if any possible.

Configuration – StoneGate Side

Install the CA Certificates and Stonegate SP Certificate

In StoneGate Administrator Interface, click on Manage System – Certificates – Add Certificate Authority… to import the CA(s) for validating the certificates of SP and IdP.

Note: in some cases the root CA for the SP and the IdP could be the same. In this case you have to load the root CA certificate just ones.

Proceed to import of the SP CA certificate.

Leave the default check on “Enable Certificate Authority”, assign a mnemonic name to the SP Root CA certificate, then click “Browse” to upload the digital certificate; optionally you can define a CRL. Click “Finish Wizard” as shown in picture below.

You’ll see the message “Added Certificate Authority <display name of the root CA>” and under Registered Certificate Authorities you’ll see the name of the CA as shown below. Click Publish to activate the configuration.

Repeat the same actions done in the previous step writing a mnemonic name in the “Display Name” text box (for example ‘IdP CA’) and import the CA Certificate to validate the IdP certificate (ADFS 2.0).

Proceed to import the Server Certificate which the SP will use to sign SAML requests and to identify himself to IdP.

Click on Add Server Certificate.

Import the Server Certificate (in PEM or DER format), the Server Private Key (in PK8 format), type in the password for the private key (if any) and select the CA to use to validate the Server Certificate as shown below:

Click Save and Publish.

The configuration page for Certificates should be similar to the one reported below:

Configure Identity Federation

In this section we’ll activate the SP role and define the Identity Provider configuration in SP. This is important to tell to SP how to talk to its federated party.

Click on Manage Resource Access – Identity Federation.

Click on Enable Identity Federation checkbox and select from drop down menu the certificate for the SP.

Click on Add Identity Provider… to add the IdP role definition in SP configuration as shown below:

IdP configuration wizard starts.

In the first page select SAML 2.0 Compliant option (ADFS Compliant is only for old WS-Federation protocol), then click Next.

Click on checkbox Enable Identity Provider and fill the other fields with the following data:

Display Name ==> a mnemonic name (for example IdP or ADFS IdP)

Identity Provider URL ==> https://<ADFS 2.0 Server FQDN>/adfs/ls/idpinitiatedsignon.aspx

CA Certificate ==> The IdP root CA Certificate previously installed

Click Next.

If the SP has not information of the user being authenticated by the IdP, enable the checkbox Allow user not listed in any User Storage, otherwise specify the mapping with the related attribute and (optionally) with the assertion response attribute (if different).

Click Finish Wizard.

The configuration should be similar to the one reported below:

Create an Access Rule to protect the application

We need now to create an access rule to protect the access to application on SP with a redirection to the IdP for authentication.

Click on Manage Resource Access – Access Rules – Add Access Rule.

Type in a mnemonic name (like Protected-by-IdP) and click Add Rule….

Select Identity Provider. Click Next.

From the drop-down menu, select the IdP definition as shown below:

Click Next to confirm.

Check that configuration is similar to picture below:

and click Next.

Click Finish Wizard.

Protect the application.

Supposing we have to protect the access to a website, we have now to assign the Access Rule created to the Web Resource defined in StoneGate SSL VPN.

Click on Manage Access – Web Resources.

Configure a new Web Resource or edit an existing web resource configuration.

Click on Access Rules tab.

From Available Access Rules list click on Protected-by-IdP and click on Add.

Click Next (or Save if you are editing the resource).

Click Finish Wizard if creating a new resource.

Click Publish to activate the configuration.

SP is now ready to operate.

Configuration – Microsoft ADFS 2.0 Side

Here we need to create a relying party in Microsoft ADFS 2.0 MMC.

Expand the Trust Relationship branch and in Actions click on Add Relying Party Trust…

The configuration wizard appears. Click on Start.

Select Enter data about the relying party manually in order to be able to manually insert all needed parameters, then click on Next.

In Display Name text area put the name of the Relying Party configuration displayed inside the ADFS 2.0 MMC.

In Note text area put an optional description of the counterpart.

Click on Next.

Select the profile you’re interested in. Even if ADFS 1.x profile (aka WS-Federation) is supported by both parties, select ADFS 2.0 since it is compatible with SAML 2.0 which is a much widely used standard.

Click Next.

Since we are not using the encryption certificate, click Next again to proceed to URL configuration.

In this screen we define our SP party within IdP, like we did previously for IdP definition in SP. That is, we configure the SAML conversation parameters in IdP.

Flag the check box Enable support for the SAML 2.0 Web SSO protocol.

In field Relying party SAML 2.0 SSO service URL type in the URL where Stonegate SSL VPN SAML Service is listening to consume the SAML Token created by ADFS 2.0.

StoneGate SSL VPN SP requires the URL has to be in the following format:

https://<stonegate_hostname>/wa/auth/saml/<IdP>/

In line above, replace <stonegate_hostname> with the real FQDN of StoneGate SSL VPN (for example sslvpn-test.stonegate.com). Be careful that the FQDN must be resolvable by a DNS or by hosts file and it must be the same name wrote inside the Server Digital Certificate used for the StoneGate SSL VPN.

After the hostname, type in the path /wa/auh/saml/ as shown, to provide the pointer to where StoneGate SAML web services are in listening.

Finally, replace <IdP> with the Identity Provider Name given within the Identity Provider configuration in StoneGate (for example adfs-IdP)

Don’t forget to type the final trailing slash, as it is mandatory in order to have a fully functional configuration.

The final URL could be for example:

https://sslvpn-test.stonegate.com/wa/auth/saml/adfs-IdP/

When you have finished click on Next to continue as shown below:

To add the Trust Party Identifier, type in the SP URL formatted as mentioned before and then click Add. Click Next.

Finally, we need to enable all users to access to the relying party (aka StoneGate SSL VPN acting as SP), select the first proposed option as shown in the following figure and then click Next.

Click Next, ensure that checkbox shown below is enabled and click Close to finish the configuration.

Create the claim rule to define the Subject of the Assertion

In this section we need to create a Claim Rule that will instruct the ADFS (IdP) to request to Active Directory the UPN of the user and put it as the Subject Name Identity of the SAML Token sent back to the SP.

In the Issuance Transform Rule tab click Add Rule.

The first rule that we have to setup is an LDAP query to the Active Directory to receive the User Principal Name of the Domain user and map it with the UPC Claim.
First of all select Send LDAP attributes as Claims in the Claim Rule Template drop-down list, then click Next.

In Claim Rule Name field put a mnemonic name (for example ‘UPN’); in the Attribute store drop-down list select Active Directory; under the LDAP Attribute column choose
User-Principal-Name attribute and in the Outgoing claim type select UPN as shown in the next figure; press Finish to terminate configuration.

Now we’ll create a second rule that will map the UPN Claim with the Name ID claim (the Subject Name Identity of the SAML Token).
This time in Claim rule template we have to select Transform an Incoming Claim and then click Next.

In the Claim rule name put a mnemonic name as SAML Subject Name Identifier (or whatever you want); in Incoming claim type box select UPN and in Outgoing claim type choose Name ID; in Outgoing name ID format you can choose Persisent Identifier (this could be changed for many different kinds of uses).

Then select Pass through all claims values and then press Finish. as shown in the picture below:

After this configuration, the Transform Rules window should be similar to the one below. NOTABENE: the shown rule order is mandatory.
The First rule must be the User-Principal-Name To UPN and the second the UPN to Name ID.

Click Apply and OK.

Importing SP Digital Certificate in IdP

To add the Service Provider Digital Certificate (Stonegate SSL VPN Digital Cetificate) in Relying Party configuration, you have to double click on the name of the configured Relying Party inside the Relying Party Trusts in ADFS 2.0 Management Console.

Click on Signature tab and click Add…

Select the StoneGate SSL VPN .CER (or .CRT) Digital Certificate from the file system and load it. Click OK.

Configuration is now finished.

Test the scenario

Before testing the scenario, your should note that by default when you install for the first time the ADFS 2.0 role on a Windows Server 2008 R2, digital certificates for the Service Communications, Token Decrypting and Signing are automatically created as self-signed certificate. In order to have a good Production Environment it’s extremely suggested to change these certificates with others emitted by a real CA.

If this is needed, please refer to Microsoft ADFS 2.0 manuals to import new digital certificates.

Also, to be able to correctly communicate and exchange SAML Request/Response, it is mandatory that the Service communications Digital Certificate and the Token Signing Digital Certificate (set as Primary) used by ADFS 2.0 are issued by same CA which certificate is loaded inside the Certification Authorities form of the Stonegate SSL.

Note: to enable the feature to Add a Token Signing Certificate through the Management Console the AutoCertificateRollover property of the ADFSProperties must be disabled.
Please refer to picture reported below:

To test the scenario, you should point your browser to the resource URL on SP.

You will be redirected to Microsoft ADFS 2.0 Server to perform authentication.

After successful authentication, you will be automatically redirected to the Federation ID protected resource on StoneGate SSL VPN SP which will grant access.

Federated authentication. Simplified!

SMC 5.2 includes improved support for using Management Client (via Webstart) in OS X environments. Feel free to use the native look & feel when using Management Client from Macintosh.

For those customers that use Domains in SMC, there is one nice filtering feature. When you have logged in to subdomain, you can now decide whether to show only the elements that are located in this domain or do you want to see the inherited elements from Shared Domain too. This toggle option is available in all element lists and tables.

When creating hosts, you can now resolve DNS to both directions. In other words, you can now type also the DNS name, press Resolve button and let the system fill the IP address for your element.

In SMC 5.2, you can also restore individual element’s old version to your current SMC. Just open some old policy snapshot, right-click the element and select “Restore” from the menu that opens.

Both these restore actions launch Import process in which you still have the possibility to review the changes and change the import action (Import/Do Not Import/Rename). See more details about Import Enhancements in SMC 5.2 in here.