With the re-emergence of CI-CD (Continuous Integration – Continuous Deployment) as well as other software engineering techniques like No Patch environments and Blue/Green Deployments, teams are under immense pressure to quickly deliver working software with no downtime to customers.  Whether it’s pushing application updates in a streamlined fashion multiple times a day or redeploying new Azure VM’s with the code updates, an application control tool needs to be as flexible as the deployment it is protecting.


Deep Security with its Application Control module enables you to implement software changes in a dynamic way which enables your development team to create and deploy their software without the roadblocks of a security tool.

The first way Deep Security achieves this is with its implementation of Application Control.  When you first enable it, the host takes inventory of the virtual machine and automatically adds all software installed into its approved list.  Perfect for no patch and blue/green deployments, when your new virtual machines are built with the new code, they are automatically added as approved by Deep Security.  Gone are the days of adding every new build to an approved list before the code is pushed.

But, what if you are deploying new code and re-using existing Azure VMs?  The Maintenance Mode feature with API tie-in is the solution for this environment.  Maintenance mode allows a virtual machine to be patched or updated, while automatically adding any changes to its approved application list.  Because Deep Security has an open API architecture, you can add this maintenance step into your code deployment tool like Jenkins.

By using the following API call, you can turn on maintenance mode for x minutes just prior to doing the code deploy.


Here in the GUI, you can see that Maintenance mode has been turned on via the API call:

Also, within Deep Security under the “Actions” section, we give you a comprehensive list of applications that are running in an environment that have yet to be approved so you can quickly see changes that have occurred.  This gives you the ability to approve new programs being deployed or remove access from files which are deemed suspicious or malicious.

With Deep Security, you have the power of Application Control, along with our other security controls, all that be accessed programmatically to help your security be as dynamic and agile as your development teams.

For more information, please contact us at azure@trendmicro.com


The Deep Security team released support today for identity provider integration using SAML 2.0. When you integrate Deep Security with your identity provider, you no longer need to manage users, passwords, and MFA tokens in Deep Security. By offloading user management to your identity provider, you can also use features like password strength / change enforcement, one-time password (OTP), and two-factor / multi-factor authentication (2FA/MFA) with your existing policies. We have tested Deep Security SAML integration with Microsoft Windows Active Directory Federation Services (ADFS), Okta, PingOne, and Shibboleth.

This article will help you integrate your ADFS server with Deep Security. I’ve tested the instructions with ADFS 4.0 (Windows Server 2016), but you can set up the same configuration with older versions of ADFS back to ADFS 2.0.

You can follow the instructions in this article today if you have an account on Deep Security as a Service, Trend Micro’s hosted Deep Security solution. SAML support is coming soon to the AWS Marketplace and software releases starting with Deep Security 10.1.

Create a SAML Identity Provider and roles in Deep Security

The Deep Security Help Center has a great SAML single sign-on configuration article that will walk you through the steps to set up Deep Security to trust your ADFS server. You’ll need the federation metadata file from your ADFS server, which you can get from https://<your ADFS server name>/FederationMetadata/2007-06/FederationMetadata.xml.

Adding Deep Security as a relying party in ADFS

This is a quick-start blog post, so I won’t get into a lot of detail. There’s a link at the bottom of the article if you want the full reference documentation.

In this example we’ll use the user’s email address as the Deep Security user name (RoleSessionName in Deep Security SAML-speak).

We’re also going to use a handy trick here that lets us use Active Directory groups to manage the role claims that we issue. This trick uses two custom rules, one to extract the Active Directory group information and the second to transform the group information into claims.

To make this work, you’ll need to have a naming convention where your Active Directory group names can be transformed into Deep Security roles. In this example, we’ll use Active Directory group names in the format TMDS-<tenant ID>-<role name>, so TMDS-0123456789-READONLY would be transformed to the URN for the Deep Security role urn:tmds:identity:us-east-ds-1:0123456789:role/ADFS-READONLY.

To create these AD groups, you’ll need the identity provider and role URNs from the Create a SAML Identity Provider and roles in Deep Security procedure described earlier.

We’ll also create a rule that includes a PreferredLanguage claim that takes its value from the preferredLanguage LDAP attribute. This is optional and won’t do any harm if you don’t have this attribute set, but it can be handy if you have a diverse user base.

Finally, we’ll create a rule that includes a SessionDuration claim limiting the user’s sessions to a maximum of eight hours (28800 seconds). This claim attribute is also optional, and the Deep Security administrator can further limit session duration if they want.

Microsoft provides an ADFS Powershell cmdlet that lets you completely configure everything we need in a single command. Run this as admin on your ADFS server to set up Deep Security as a Service as a relying party for your ADFS. If you’re trying to integrate your own Deep Security installation, replace the Name and MetadataURL parameter values, and check to make sure the URNs in the Roles rule match what you have.

[bs_icon name=”glyphicon glyphicon-warning-sign”] Always read Powershell scripts carefully and make sure you understand what they do before running them. Also, be wary of copy & paste attacks! Always paste into a text editor and review what you’ve copied there before running the script.

Add-AdfsRelyingPartyTrust -Name 'Trend Micro Deep Security as a Service' -MetadataURL 'https://app.deepsecurity.trendmicro.com/saml' -IssuanceAuthorizationRules '@RuleTemplate="AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value="true");' -IssuanceTransformRules '@RuleTemplate = "LdapClaims"
@RuleName = "RoleSessionName"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("https://deepsecurity.trendmicro.com/SAML/Attributes/RoleSessionName"), query = ";mail;{0}", param = c.Value);

@RuleName = "Get AD Groups"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

@RuleName = "Roles"
c:[Type == "http://temp/variable", Value =~ "(?i)^TMDS-([^d]+)"]
 => issue(Type = "https://deepsecurity.trendmicro.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "TMDS-([^d]+)-", "urn:tmds:identity:us-east-ds-1:$1:saml-provider/ADFS,urn:tmds:identity:us-east-ds-1:$1:role/ADFS-"));

@RuleName = "Session Duration"
 => issue(Type = "https://deepsecurity.trendmicro.com/SAML/Attributes/SessionDuration", Value = "28800");

@RuleTemplate = "LdapClaims"
@RuleName = "Preferred Language"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("https://deepsecurity.trendmicro.com/SAML/Attributes/PreferredLanguage"), query = ";preferredLanguage;{0}", param = c.Value);'

That’s it!

Well, close to, anyway. You’ll still need to set up groups in Active Directory that match the pattern you defined (in the examples above, TMDS-<tenant ID>-<role name>) and assign users to those groups, but then you’re done!