trend micro deep security azure hands on lab · • an azure account with an active subscription...

Trend Micro Deep Security

Azure Hands On Lab

Deep Security Azure Test Drive

What will I learn today?

Copyright © 2015 Trend Micro Incorporated. All rights reserved.

azure.trendmicro.com of 49

Table of Contents

1. What will I learn today? ....................................................................................................................3

2. What is Deep Security? .....................................................................................................................4

3. Let's get set up ......................................................................................................................................5

4. Environment set-up ...........................................................................................................................6

5. Setting expectations ........................................................................................................................ 13

6. Know when files change on your virtual machines ............................................................ 14

7. Get automated help designing a security rule set ............................................................... 20

8. Prevent users from uploading content that contains malicious code ......................... 27

9. Protect against invalid web traffic ............................................................................................. 33

10. Know when the operating system configuration changes ............................................... 37

11. Log connections to the application ........................................................................................... 40

12. Scale up and out ................................................................................................................................ 44

13. Review .................................................................................................................................................. 48

14. Appendix: ............................................................................................................................................ 49

15. Ways to run Deep Security Manager ....................................................................................... 49






The Goal of this Trend Azure Hands On Lab (TAHOL) is first to have you deploy Deep Security in Azure in order to get an understanding of how easy it is and secondly to give you an overview of Trend Micro Deep Security. We’ll try to highlight not only how Deep Security can provide protection against today's advanced threats but also how it helps prevent common IT mistakes, all while getting out of your way as much as possible.

That probably sounds like an odd approach for a security company. It is.

With Deep Security, our goal is to help you focus on getting down to business... not on the security protecting your business. This Test Drive will show you how to use Deep Security to provide the protection you expect quickly, easily, and with a minimal amount of effort.

You will learn how Deep Security can help by:

• Letting you know when files change on your virtual machines • Automatically creating customized rule sets for your virtual machines • Protecting your applications from malicious content • Ensuring that only valid traffic reaches your applications • Monitoring operating system log files to notify you of key system level events • Logging all connections to your applications • Providing easy ways to scale your security solution

Let's get started




What is Deep Security?

What is Deep Security?

Deep Security is a security control platform. There are two pieces to the platform: the Deep Security Manager and the Deep Security Agents. The Manager runs centrally, and the Agents are deployed on the virtual machines you want to protect.

The Manager allows you to set up and customize security policy, monitor events, and deliver security rule updates. The Agent does all the heavy lifting by delivering the following controls:

• anti-malware • web reputation (also known as content filtering) • firewall • intrusion prevention • integrity monitoring • log inspection

These controls provide much-needed security to your operating systems and applications. This lines up nicely with the way security works in the Azure Cloud, which operates under the Shared Responsibility Model. This model draws a clear line where Azure responsibility for security ends and where your responsibility begins.

Figure 1The Shared Responsibility Model for security in the Azure Cloud

You can see that as an Azure customer, you need to start building your security controls into the operating system and work your way up the technology stack from there.

Deep Security is designed to help you fulfill your responsibilities quickly and easily.




Let’s get set up

Let's get set up

Before we dive into the Test Drive, let's make sure that you have all of the tools that you will need.

Prerequisits

To successfully complete this Test Drive, you will need the following:

• A reasonably up-to-date browser (IE 9+, Chrome, Firefox, Safari, etc.). You will use the browser to interact with the Azure Portal, Deep Security Manager as well as with the sample application we'll be protecting.

• An Azure account with an active subscription • A Deep Security license. I have a pack of 30-day evaluation licenses, just ask me for one if I forgot to

give it to you. • An RDP (remote desktop protocol) client. You will need the RDP client to make changes on the

protected virtual machine as part of the exercises.




Let’s get set up

Environment set-up

If you have the tools listed above, complete the following steps and then dive into the HOL itself.

NOTE: It would be possible to simply prepare the entire environment, save it as a script, and then deploy it with just running this script. We will do it the cumbersome way to make sure you understand the integration into Azure and how well Deep Security and Azure play together.

In the steps below, you will be setting some parameters when deploying the lab environment. You will need the values below, so make notes of what you set and have them handy.

Parameter Sample value

Deep Security Manager URL

(Also called DSM URL)

https://<DSM URL>.northeurope.cloudapp.azure.com

Note: Remember to replace <DSM URL> with whatever you chose below!

Deep Security Manager

Administrator Username / Password

Username: trendmicro

Password: Trendmicro1234!

Webserver Public IP

(For RDP access)

Note; The above IP can be found in the TAHOLweb virtual machine which can

be found in the TAHOLweb resource group. Can also be found in the DSM.

Webserver logon

(for use in RDP)

Username: trendmicro

Password: Trendmicro1234!

Webserver URL http://<Webserver Public IP>

Note: The ‘Webserver Public IP’ is the same as you use for RDP access. It can be

found in the TAHOLweb virtual machine which can be found in the TAHOLweb

resource group.




Let’s get set up

Deep Security Manager (DSM)

First you will set up the Deep Security Manager (DSM). The management environment includes both a SQL database and the Operating System into which the DSM is installed. We will simplify this a little bit. The DSM comes pre-packaged on the Marketplace and will only require a dozen of settings from you. Let me guide you through this first. (There are some other ways to get a DSM running. Take a look into the Appendix for a description!)

1. Log on to the Azure Portal (https://portal.azure.com) with your Azure account. This account will need an active subscription or you won’t be able to run the HOL.

2. Search for “Deep Security Manager”on the Azure Marketplace (Click the plus sign on the left).

3. Choose the “Deep Security Manager (BYOL) and click ‘Create’.

4. Now fill in the requested parameters. If you use the ones in the image below, all further references will be correct. Password is (without quotes) ‘Trendmicro1234!’. Continue with ‘OK’.

https://portal.azure.com/




Let’s get set up

5. In the next window you only have to change the ‘Deep Security Manager URL’. Since this URL has to be globally unique I suggest you choose ‘tahol<initials>’ where you replace <initials> with your personal initials (or any other text). I used ‘ps’ so my DSM URL is then ‘taholps’. Also, name must be all lowercase. Please take a note of your DSM URL. Whenever you see ‘taholps’ in a URL, replace it with the value you wrote here! You can see that this is also where you choose a larger workload if needed, but the smallest will suffice for this HOL.

6. Supply database values (just choose names) and this is the last time you will see or use these values in the HOL. Normally you’d take a note, but if you are lazy then this is something you may skip today. The password is a bit picky here. Use ‘Tr3ndm1cr0!’ and you will be fine (yup, that’s number three, one and zero in there). Click OK to move on.

7. For the DSM, make life simple and use ‘trendmicro’ as username and ‘Trendmicro1234!’ as password. In the HOL below I may assume that those were the values you chose…

8. In the next step you will see a red exclamation mark which tells you that you have to provide some intelligent input! Well, actually not. Just click on the ‘Subnet field’ and just click Ok and you will be fine. Take a deep breath, coffee is close now!

9. Before hitting the OK button here, take a second to look through your settings. Also note that beside the OK button is a link ‘Download template and parameters’. You can click this if you are just a little bit curious and get a glimpse of how this build could have been scripted. Go ahead, give in for your curiosity!

10. Last page is the legal bla bla which you (of course!) must read carefully and remember (or not). To note here is that the HOL will put some very small charges to your subscription as log as you keep it running. Don’t worry, it’s not much, but do peek in tomorrow or so to get an understanding on the actual cost. When you don’t need the Deep Security Manager any more, just delete the ‘TAHOLdsm’ resource group and you will be good.

11. After clicking ‘Purchase’ in the next step, it will take 10-15 minutes to have DSM environment set up. Time to make sure your coffee cup is filled and I might even go through a few slides.

It will take about 10-15 minutes for the DSM environment to launch, so

grab some coffee. Eager to continue? Look through the instructions for the next

step as it will be a little more tricky soon.




Let’s get set up

Web site setup

You will now set up a website on which you will carry out your sinister experiments run this HOL. First you will fire up a Windows 2016 server with the Deep Security Agent baked in. Since this Agent will connect to your DSM which you created above, it has to run before you can carry on. You will open up the Azure firewall by adding rules to the Network Security Group or you will not be able to access the website.

When Windows Server is up and running, you will log on to run a script which will install IIS, download the website and prepare it for the HOL. Ok, let’s go!

1. From the Azure Marketplace (plus sign on your top left) choose ‘Compute’ and then ‘Windows Server 2016 Datacenter’. Click ‘Create’ to get going.

2. First page is not very different from the last time. Use my values and type in ‘Trendmicro1234!’ for your password. Don’t worry, before the HOL is over you will type that password faster than your name. Ok, maybe not that fast.




Let’s get set up

3. Now it’s time to choose the size of the Webserver. In the HOL the smallest will do just fine. Click OK but don’t rush it too far yet, we need some more settings to do!

4. Add a firewall rule to allow us to contact the webserver. Click on ‘Network security group’ and you will be given the option to add inbound rules. Add a rule for the website on TCP/80 (below). Just use 2000 for priority. Click ‘Ok’ twice to get back to the Settings page. Why didn’t we have to do this for the DSM? Because it was done in the Marketplace template. Very convenient!

5. Before leaving the Settings page, let’s use the Azure integration to have the Deep Security Agent installed on your website. Click on ‘Extensions’, then ‘Add Extension’ and pick Deep Security Agent from the list.

6. To make the Agent register to the DSM you can now add the connection information to the DSM. Remember your DSM URL? Type it in here appended with ‘northeurope.cloudapp.azure.com’. Activation Port is same as Heartbeat port so it is 4120 (remember setting it above?). The DSM you have set up is not multi-tenant so both ‘Tenant Identifier’ and ‘Tenant Activation Password’ shall be set to ‘NA’. Notice that if you had a prepared security policy in the DSM, then we could also set it here.




Let’s get set up

7. A few ‘OK’ later you have arrived to the final Summary page. Before you hit OK, again notice the link next to the OK button. The link will again give you the script template to use if you want to deploy your workloads from PowerShell or something similar.

8. As the creation takes another 10-15 minutes, it is coffeetime again! Go get! Maybe we do some more slides?

9. Back now? Before we finalize the website let’s pop into the DSM and do some groundwork. Open a browser and browse to your DSM. The URL should be https://<DSM URL>.northeurope.cloudapp.azure.com Since I used ‘taholps’ for my <URL DSM> my link is https://taholps.northeurope.cloudapp.azure.com Yours is different.

10. Log on to the Deep Security Manager and go to Administration. Choose Licenses on the left-hand side and add the activation code we have provided. You have a ‘Single Activation Code’.

11. Before leaving the Administration page, change the timezone for your user. Again on the left-hand side you will find ‘User Management’. Under ‘Users’ just double-click your user and change the timezone.

12. Still in the DSM, take the opportunity to change the heartbeat interval for the webserver. That way your changes later on will have effect quicker. Not absolutely necessary, but helps if you don’t like to wait too much later on. First choose ‘Computers’ and double-click the webserver. It will be the one with the IP-address as a name. Take a note of the IP address as you will need it very soon.

13. Looking at the details of the webserver, click ‘Settings’ on the left and change ‘Heartbeat Interval’ to 1 min. A bit short in a production environment, but perfect in a HOL when you want your changes to take effect as soon as possible.

14. Move on to connect an RDP session to our website. You just saw the IP address in the DSM or you can find it by clicking the 3-D cube icon in your Azure Portal, just below the plus sign. This will show you your resource groups. The webserver should be in TAHOLweb so select the TAHOLweb resource group. In the overview, you will see all resources listed and the webserver is the one called




Let’s get set up

TAHOLweb with the icon of a monitor. Select the webserver and there the public IP is. Use it to connect to the webserver. You can also click ‘Connect’ which will hand you and RDP configuration file (TAHOLweb.rdp)

15. I have created a script which will install IIS, download the website files and prepare the website needed for the rest of the HOL. Download the script and open in a text editor. https://tmlabse.blob.core.windows.net/tmlabfiles/TAHOLiisinstall.ps1

16. On the website (in your RDP session) start Windows PowerShell ISE. There are four different PowerShell options, so do choose the right one. In the top right corner, there is a button saying ‘Script’. When you click it, the windows will split in two and there will be a script editor in the top half. Cut and paste the script from the text editor into the script editor. Review the script, please don’t change it, and when done hit the green arrow on the toolbar (or hit F5) to run the script. This will take a few minutes and should not generate any errors. Close PowerShell when script is done.

If you have made it all the way here, you should be set to run the actual HOL. If your environment shows any signs of not working, whatever those signs would be, make sure to sort them out before moving on. Ask for help if needed!

https://tmlabse.blob.core.windows.net/tmlabfiles/TAHOLiisinstall.ps1




Setting expectations

Setting expectations

The scenario

During this Test Drive we will be protecting a simple image-processing application. This application allows the user to upload an image (or provide a URL to an image) which then gets stripped of all of its metadata (like photographer, camera details, date taken, etc.) and then is automatically resized to a standard set of sizes. This is a very simple application, but it is enough that we can use it to highlight several real-world situations that are common to most web applications.

Our Azure virtual machine running Microsoft Windows Server 2016 will power our sample application (which was written in .NET). For the purposes of the Test Drive, we'll deliver the application directly to users from the single virtual machine, but we could just as easily divide this into a standard N- tier application.

HOL structure

The HOL is divided up into seven exercises. Each exercise helps address a specific IT challenge in the real world. The exercises are:

Know when files

change on your

virtual machines

Get automated

help designing a

security rule set

Prevent users from

uploading content

that contains

malicious code

Protect against

invalid web

traffic

Know when

operating system

configuration

changes

Log connections

to the application

Scale up and out




Know when files change on your virtual machines


In this exercise, we're going to walk through how to set up rules to detect changes on your protected virtual machines. Sometimes files change for a good reason, like deploying a new version of the application, but sometimes people make mistakes, or sometimes a file change can be an indicator of an attack in progress.

Deep Security uses the term Integrity Monitoring to describe the feature that monitors for file changes on protected virtual machines. We're going to set up an Integrity Monitoring rule to make sure that we get alerted when something changes.

Take a minute and open a new tab in your browser. Visit the `Website IP` e.g. http://<IP address>. The IP the same as you used for RDP, remember? the web page loads, you should see something similar to this.





Yikes, that is one ugly application! But if you noticed at the top, there's a yellow warning that indicates this is some sort of debug view. That probably shouldn't be deployed to a production virtual machine, and probably means a developer made a change to the virtual machine directly. We'll fix that, but first let's make sure we get alerted if someone tries that again.

1. Open your browser to the ‘Deep Security Manager URL’ e.g. https://taholps.northeurope.cloudapp.azure.com (‘taholps’ is different for your DSM)

2. In the Deep Security Manager, click on the Computers tab in the main navigation bar. Deep Security uses the generic term "Computer", "virtual machine" is the Azure term that we will use throughout this HOL.

3. You will see two virtual machines listed. One is the Deep Security Manager (yes, you can use Deep Security to protect itself!). The second virtual machine is where our sample website is running. Double click on the website virtual machine. This will open up the details window.

4. Select Integrity Monitoring from the list on the left side of the details window. This will load all of the settings associated with file integrity monitoring in the right side of the details window. We need to turn on this security module. In the right side of the details window, in the Integrity Monitoring section, switch the Configuration value to ON.

5. Check the box labelled Enable real-time scan.

6. Click the Save button.

7. In the table labelled Assigned Integrity Monitoring Rules, click the Assign/Unassign... button.

8. This will pull up the rules dialog where we can customize the rules we're using.

9. Click the New button.

10. Select ‘New Integrity Monitoring Rule...’ from the drop down menu. A new dialog will come up where you can define the new rule.

11. On the General tab, in the General information section, enter ‘Social Imageanator’ in the Name field.

12. In the Details section, change the Severity value to Critical.

13. Switch to the Content tab.

14. In the Template section, make sure File is the radio button that's selected

15. In the Base Directory group, enter c:\inetpub\wwwroot in the Base Directory field.

16. Check the option to Include Sub Directories.

17. In the File Names section, in the Include Files With Names Like (One Per Line) field, enter (an asterisk). An asterisk * will monitor all files and folders under the Base Directory you defined earlier.

18. Switch to the Options tab.

19. In the Alert section, check Alert when this rule logs an event.

20. Click the OK button to close the rule properties dialog.

21. Click the OK button to close the rule assignment dialog (our new rule is assigned automatically).

https://taholps.northeurope.cloudapp.azure.com/





22. Click the Save button. This saves our configuration and also queues it up for assignment. This update takes about a minute (Now you understand why you changed the heartbeat interval!). You may notice the status for the application virtual machine in the main Deep Security Manager screen change to Sending Policy. Once the update completes the status will change back to Managed (Online).

The rule we just created and applied will monitor the default folder for IIS (Internet Information

Server) for any changes. If someone changes a file, adds a directory, or makes any other changes to

this directory or any of its subdirectories, this integrity monitoring rule will detect the change and

raise a critical alert.

We know that we don't have the right version live in production at

the moment. In the next step, we're going to fix the website by making some

changes. Deep Security will alert us when the files change, just like we asked it

to.

Let's get our sample website to the point where it's a little more presentable. To do that we're

going to log into our Windows virtual machine using our RDP.

1. In your RDP client connection to your Windows virtual machine, open up Windows Explorer

(the file browser for Windows). Click the folder icon in the taskbar.

2. Navigate to c:\inetpub\wwwroot.

3. Right-click on the Landing.aspx file.

4. Select Edit from the context menu to open up the file in Notepad.





5. You can see on lines 9 through 11 that there is a comment around the production CSS link

that should have been removed.

6. Remove lines 9 and 11 (Don’t remove line 10). These are comment tags that are preventing

our production stylesheet (the <link> tag) from being applied

7. Save the file (Control+S or select File > Save from the menu).

We just made a change to our sample website deployed in production. If you reload the tab if the

application page is still opened in your browser or load it again with the application displayed, you

should see something a lot nicer. Maybe not a blue-ribbon winner yet, but it's definitely a big

improvement.





Since we asked Deep Security to monitor the directory where the application lives

(c:\inetpub\wwwroot), it should have seen the changes and raised an alert (we did tell Deep

Security this was a critical rule for us). Once the Deep Security Agent sees a change to anything in

that directory (or any directory under it), it will raise an event and alert in the Deep Security

Manager.





Let's look for that now.

1. Back in your web browser in the Deep Security tab, click on the Alerts section in the main navigation bar.

2. At the top, you should see an alert summary titled Integrity Monitoring rule (Social Imageanator) alert on 1 Computer(s).

3. Click the Show Details link in the alert summary to see the specifics of where this alert was raised.

Now that we're aware of the change to our sample application, we can investigate and determine if

this was a valid change or something sinister.

In our case, we know this was a good change. I'm sure we opened a change request and went

through the proper process behind the scenes. If we didn't, this is a good example of how you can

use Deep Security to ensure that your applications and servers don't change from their approved

configurations.




Get automated help designing a security rule

Get automated help designing a security rule set

While it only took a couple of minutes to create a custom integrity monitoring rule, we're not going to be able to spend that amount of time designing every rule for each of our virtual machines that we want to protect. That's why Deep Security includes several tools to help automate and simplify the administration of security policies.

Deep Security provides a huge number of rules that can protect a variety of configurations. There are rules for common operating systems (Microsoft Windows, a variety of Linux distributions, even Solaris & HP UNIX!), rules for common applications, standard communications protocols, log formats, and the list goes on.

In this exercise, we're going to see how a feature called recommendation scanning can automate the process of picking the rules that match what we've deployed on our virtual machine.

4. In the Deep Security Manager, on the Computers page, double-click on the website virtual machine to open the details window.

5. Select Intrusion Prevention from the list on the left side of the details window. This will load all of the settings associated with intrusion prevention in the right side of the details window.

6. We need to turn on this security module. In the right side of the details window, in the Intrusion Prevention section, switch the Configuration value to ON.

7. You can leave the radio button labelled Intrusion Prevention Behavior set to Prevent.

8. Near the bottom of the window, in the Recommendations section, for the drop down labelled, Automatically implement Intrusion Prevention Recommendations (when possible), choose Yes.






With those simple steps, we've told Deep Security to do the heavy lifting when it comes to applying intrusion prevention rules. Each time we run a recommendation scan, Deep Security will automatically apply the majority of the rules to our virtual machine. Some rules need custom settings and can't be automatically applied, but don't worry: you'll be prompted about these rules.

Now we'll do the same thing for two of the other security modules: Integrity Monitoring and Log Inspection.

1. Select Integrity Monitoring from the list on the left side of the details window. This will load all of the settings associated with Integrity Monitoring in the right side of the details window.

2. We've already enabled this module, we just need to configure the recommendation scan actions. Near the bottom of the window (you may need to scroll), in the Recommendations section, for Automatically implement Integrity Monitoring Rule Recommendations (when possible), choose Yes.






4. Select Log Inspection from the list on the left side of the details window. This will load all of the settings associated with Log Inspection in the right side of the details window.

5. We need to turn on this security module. In the right side of the details window, in the Log Inspection section, switch the Configuration value to ON.

6. Near the bottom of the window, in the Recommendations section, for Automatically implement Log Inspection Rule Recommendations (when possible), choose Yes.






Now that we've configured the Intrusion Prevention, Integrity Monitoring, and Log Inspection modules to automatically apply the results of a recommendation scan, it's time to run the scan itself. Remember that right now we have one rule applied to our virtual machine: the custom integrity monitoring rule we created in the last exercise.

There are a number of ways to run the scan but the simplest for us is to click the Scan For Recommendations button already showing in the Log Inspection section of the details window. Do that now.





The recommendation scan will take 3-5 minutes to complete. You

will see the status of the virtual machine in the main Computers screen change to

Scanning for Recommendations and then eventually back to Managed (Online)

when it's done, or you can watch progress in the Overview section of the virtual

machine details window.

Now is a good time to take a minute, stretch a bit, fire off a quick tweet about

how fantastic this Test Drive has been so far, you know... usual break-time stuff.





8. If you closed the details window, open it back up again.

9. Select Overview from the list on the left side of the details window. This loads a high-level view of the virtual machine's configuration in the right side of the window.

10. Look at the Status group. You should see a significant increase in the number of rules currently applied to the virtual machine. Before we ran the scan, we had one rule applied. Now we should have lots more:





Note: The number of rules that are assigned to your application system may vary based on the system patch level at the time of Test Drive so it’s Okay if you get less or more # of rules assigned to your client system.

With a few quick steps, we've been able to craft a customized configuration for our Windows virtual machine. The recommendation scan feature takes away a lot of the work associated with building a configuration. That means we can focus on customizing our security to make sure it fits the special circumstances of our deployment.




Prevent users from uploading content that contains malicious code


Our sample application allows users not only to upload an image but also to point the application to a URL to download an image or a .zip of images. As useful as this is, it's also a big risk.

Most of our users won't intentionally point our application to anything bad. Most users won't try to upload anything other than images. But there's always going to be that one bad apple and an un- intentional apple. Ok, maybe the metaphor breaks down a bit here, but the point stands. For our sample application to work, we need to allow for user input, but there's no way we can code out all of the bad possibilities.

That's where Deep Security comes into play. Yes, we will be sure to sanitize the user input as much as possible in our code (e.g. make sure it's an image file, not execute anything uploaded, etc.), but we need to leverage another tool to scan for malicious code.

Let's enable this type of protection now.

1. Still in the details window of our virtual machine, select Anti-Malware from the list on the left side. This will load all of the settings associated with malware protection in the right side of the details window.

2. We need to turn on this security module. In the right side of the details window, in the Anti-Malware section, switch the Configuration value to ON.

3. For the group of fields labelled Real-Time Scan, de-select the Inherited checkbox for Real-Time Scan.

4. In the drop down labelled Malware Scan Configuration, choose Default Real-Time Scan Configuration.

5. In the drop down labelled Schedule, choose Every Day All Day.

6. For the group of fields labelled, Manual Scan, de-select the Inherited option for Manual Scan.

7. In the drop down labelled Configuration choose Default Manual Scan Configuration.

8. For the group of fields labelled Scheduled Scan, de-select the Inherited option for Scheduled Scan.

9. In the drop down labelled Configuration, choose Default Scheduled Scan Configuration.






Now we've got advanced anti-malware controls applied to our virtual machine, but this type of malware protection is only part of the puzzle. The vast majority of today's attacks start with a visit to a URL that's carrying a malicious payload. Deep Security offers protection from these URLs in the form of the Web Reputation module.

Let's turn also this module on now.





1. Select Web Reputation from the list on the left side of the details window. This will load all of the settings associated with Web Reputation in the right side of the details window.

2. We need to turn on this security module. In the right side of the details window, in the Web Reputation section, switch the Configuration value to ON.

3. De-select the Inherited option for Scheduled Scan.

4. Select the Security Level radio button to High.


Now that we've saved these settings, our virtual machine will receive an updated configuration. It may take up to a minute and once the new configuration is in place, we'll run a quick test to verify that we're protecting our sample application against malicious uploads.





1. In a browser tab, open up our sample application. This is the Application URL value you received with the Test Drive access information.

2. Select the Use a URL... radio button.

3. In the Use a URL... text box, enter:

https://tmlabse.blob.core.windows.net/tmlabfiles/eicar_com.zip

4. Scroll down and click the Upload button.

We just asked our sample application to process a .zip file containing a live virus (don't worry, it's benign). There's no way we could have written the application code to search for all known viruses†. However, we did write it to gracefully handle errors, and that's what we'll see after clicking Upload.

† Well, you could, but then you wouldn't be focusing on your core business, would you? At Trend Micro, our business is helping you focus on and secure your business.

You should now see an error message that says Couldn't process the image. Threw exception: Parameter is not valid.

This error is telling us that the application hit an error while processing the requested image: a parameter wasn't valid. That invalid parameter was the lack of an image to process, since the malware protection we applied removed the virus before the application could open it.





We can verify this event back in the Deep Security Manager.

1. In your browser, switch back to the details window for our virtual machine.

2. Select Anti-Malware from the list on the left side of the details window. This will load all of the settings associated with malware protection in the right side of the details window.

3. Select the Events tab. You should see one event listed, the deletion of the `eicar_test_file` virus we tried to upload to our sample application. If you don't see the event, click the Get Events button to force the Agent to send the latest events to the Manager.





Both of these modules (Anti-Malware and Web Reputation) tap into the Trend Micro Smart

Protection Network. That's our massive data-mining framework that rapidly and accurately

identifies new threats. Once it finds a threat, it delivers updates to all of our products and services.

It's a simple (for you!) way of tapping into a much larger pool of knowledge about the threat

landscape. This lets your development teams focus on the task at hand, building the best

applications possible.




Protect against invalid web traffic


At this point in the Test Drive, we've added a number of additional security controls with minimal effort. The controls we've added through Deep Security are in addition to the security group we have protecting our Azure virtual machine. But there are still a few areas where we should shore up our defenses.

Let's see a quick example of where our sample application is still vulnerable.

1. Back in our sample application; select the Use a URL... radio button.

2. In the Use a URL... field, enter: https://tmlabse.blob.core.windows.net/tmlabfiles/south-park.jpg

3. In the Comments field, enter: This is my comment. <script>alert("This shouldn't work");</script> Uh-oh, we just launched an attack

4. Click the Upload button.!





The error message you'll see is from the application framework (Microsoft .NET) that we used to write our sample application. This means our simple JavaScript attack actually reached our application. We were lucky that our framework caught it, but there are many examples where this isn't the case.

This isn't the end of the world (since the attack didn't actually work) but it's a really poor user experience. In fact, this could have just as easily resulted in a successful attack on our application or worse: our users.

Let's fix this now by applying protection from these types of attacks using Deep Security.

1. Back in the Deep Security Manager, in the details windows for our virtual machine, select Intrusion Prevention from the list on the left side of the details window. This will load all of the settings associated with Intrusion Prevention in the right side of the details window.

2. In the Assigned Intrusion Prevention Rules section, click the Assign/Unassign... button to open the rules dialog.

3. In the rules dialog, search for generic cross site scripting.

4. Check the box next to the rule "Generic Cross Site Scripting (XSS) Prevention.





5. Click the OK button to assign the rule to our virtual machine.

Our virtual machine will get an updated configuration and then we can try the same attack again and see the difference. Re-run the XSS attack you just did.

Once you click the Upload button, you'll probably see something along the lines of the image below. Depending on the browser you're using, you may also see an error indicating that the connection was reset. That means Deep Security caught the attack and prevented it from reaching our sample application.

Let's jump back to Deep Security and see what just happened.

1. Back in Deep Security, in the details window for our virtual machine, select Intrusion Prevention from the list on the left side of the details window. This will load all of the settings associated with Intrusion Prevention in the right side of the details window.

2. Click the Events tab of the Intrusion Prevention section.

3. You should see 2-3 events listed (it depends on the browser you used to launch the attack). These events list a number of log actions and a reset action. These events show that Deep Security detected the attack and then automatically reset the connection to stop the attack in its tracks.





This scenario is a good example of why intrusion prevention is needed in your Azure deployments. The sample application has a properly-configured security group in place to protect against transport-level attacks, but it is still vulnerable to this type of application-level attack. This defense also works against injection attacks and many others directed at the application layer.




Know when the operating system configuration changes


Earlier we saw how the Integrity Monitoring control can help detect changes in specific files and directories. It's an extremely useful control that can provide early warning signals to changes on your

virtual machines. But for the rich information stored in log files, it's not enough.

Every time there's a new log entry the log file changes. Integrity monitoring controls would be raising alerts constantly and generating noise. To address this problem, Deep Security provides the Log Inspection module.

In an earlier exercise, we enabled Log Inspection and had the recommendation scan automatically select a rule set for our virtual machine. Let's see that in action now.

4. In your RDP client, reconnect to our sample application virtual machine.

5. Open up the PowerShell application

6. At the prompt, type: Add-WindowsFeature SMTP-Server

This is going to install the SMTP server feature of Microsoft Windows. It will take a few minutes (usually no more than 5) to install this feature. This PowerShell command is the same as using the Features section of the Server Manager application in Windows.





7. Switch back to the Deep Security Manager window with our virtual machine details.

8. Select Log Inspection from the list on the left. This will load all of the settings associated with Log Inspection in the right side of the details window.

9. Click the Events tab. You should see log events listed in the table:





If you don't, that's not a problem. The agent probably hasn't reported in yet. Simply click the Get Events button on the Events tab and you should see the entries in a few seconds.

The Log Inspection module lets you alert on specific log entries that are of concern to you. We've just seen the default Windows event inspection flag Windows audit events for us. This is useful to track specific changes to the operating system and very handy when you have to respond to an audit. Another very common use is to track specific user logins to a system.

With Log Inspection, you can quickly and easily set flags to raise alerts when specific actions are taken on your virtual machines. It's an extremely powerful tool.




Log connections to the application


Many compliance frameworks require that you log all connections to your applications. While the security groups that are part of Azure and Azure VPC are fantastic as security controls, they lack the ability to log connections. That's where the Deep Security firewall can help.

We're going to use the Deep Security firewall to log all of the successful connections to our sample application. In order to prevent blocking access to our own virtual machine, we're going to configure the rules before turning on the firewall.

1. In the details window for our virtual machine, select Firewall from the list on the left. This will load all of the settings associated with the Firewall in the right side of the details window.

2. Under Firewall Stateful Configurations enable stateful inspection.

3. To start, in the Assigned Firewall Rules section, click the Assign/Unassign... button to bring up the Firewall Rules dialog.

As with any firewall, it is possible to configure the Deep Security

firewall to deny yourself access to the virtual machine. If you do make a mistake

and get locked out of the application virtual machine during this Test Drive, don't

worry too much about it. You don't need the virtual machine to be working to do

the last exercise and finish the Test Drive.





4. Check the following rules to enable them: - Allow solicited ICMP replies - Allow solicited TCP / UDP replies - ARP - Deep Security Agent - Remote Access RDP - Web Server - DHCP Client

5. Click the OK button.

Let's create a custom firewall rule to log the connections to our sample application.

1. In the Assigned Firewall Rules section, click the Assign/Unassign... button to bring up the Firewall Rules dialog again.

2. Click the New button and select New Firewall Rule... from the drop-down menu to open the New Firewall Rule Properties window.

3. Under General Information, enter Log all connections in the Name field.

4. In the Action drop down, select Log Only.

5. Click the OK button to close the rule properties window.

6. Click the OK button to close the rule dialog.





8. In the Firewall section near the top, set the drop down labelled Configuration to On.

Once again, our virtual machine is going to receive an updated configuration. This time it will activate the firewall and log all of the connections it accepts. We've also made sure to line up our rules with those of our Azure security group so we'll continue to permit the same types of traffic.

Now that the configuration has been updated, let's generate a few events to see the rule in action.

1. In your browser, switch to the tab with our sample application.

2. Reload the tab (Ctrl+R or ⌘R or F5) a few times.

3. Switch back to the Deep Security Manager window with our virtual machine details.





4. Select Firewall from the list on the left. This will load all of the settings associated with the Firewall in the right side of the details window.

5. Click the Events tab. You should see a few events listed in the table.

If you don't, that's not a problem. The agent probably hasn't reported in yet. Simply click the Get Events button on the Events tab and you should see the entries in a few seconds.

It only took a few simple steps and we've enabled logging connections to our sample application. Of course, we could raise alerts based on these events or tune the rule further, but this example shows how quick and easy it is to get the ball rolling and meet any compliance frameworks you need to.




Scale up and out

Scale up and out

In the last few exercises, we've added several advanced security controls to our virtual machine. Using a few key Deep Security features, it didn't take very long to create a customized configuration based on our unique needs.

As easy as it was, this process doesn't scale. We can't go through these steps for every virtual machine that we start on Azure. That's why Deep Security has the concept of a security policy.

A policy is a defined configuration of security controls that you can apply to any number of computers that Deep Security is protecting.

In the next few steps, we're going to use the configuration we've already created to generate a new security policy that we can apply to other virtual machines. This will help us scale our security in lock step with our application.

1. Back in the Deep Security Manager, click on the Policies tab in the main navigation bar. This will load the policies tools:

2. In the Policies toolbar, click the New button.

3. Select New Policy... from the drop-down menu to load the New Policy Wizard window.

4. In the Name field, enter `Social Imageanator`.




Scale up and out

5. Click the Next button.

6. The next screen prompts, Base this Policy on an existing Computer's current configuration? Leave the default radio button Yes selected.

7. Click the Next button to arrive at a selection screen:




Scale up and out

8. Select the application virtual machine (52.169.214.152, yours will be different!) by checking the box next to it.

9. Click the Next button to display the policy creation options:




Scale up and out

Since we know future virtual machines will be configured the same, we can leave all of the default options. This means our new policy will be the same configuration as our virtual machine.

10. Click the Next button.

11. The final screen summarizes our choices; click the Finish button to create our policy.

12. Once the policy creation is complete, we see a completion screen. Uncheck Open Policy Details on 'Close'.

13. Click the Close button to return to the policy tools.

With a few quick steps, we've taken the custom configuration of one virtual machine and created a re- usable policy from it. Now, when our application scales we can automatically assign this Deep Security policy to all of the new virtual machines, ensuring that we have a unified set of security controls across the entire deployment. Remember creating the webserver VM and you added the Deep Security Agent extension? Then you were prompted for a security policy but left it blank since there was no policy designed yet. Well, next time this is the one you can use.




Review

Review

Thank you for taking the time to complete the Deep Security Test Drive!

Over the course of this Test Drive we've seen how Deep Security can help with:

▪ Letting you know when files changed on your protected virtual machines using a custom Integrity Monitoring rule;

▪ Automatically creating customized rule sets for your virtual machines using the recommendation scan feature;

▪ Protecting your application from malicious content using Anti-Malware and Web Reputation controls;

▪ Ensuring that only valid traffic reaches your application using Intrusion Prevention controls; ▪ Monitoring operating system log files using the Log Monitoring controls to notify you

of key system level events;

▪ Logging all connections to your application using the Firewall controls; ▪ Scaling your security solution by turning your virtual machine's configuration into a re-

usable policy.

You now have a better understanding how Deep Security can help you protect your applications from a variety of problems -- from the malicious to everyday IT issues.

There's a lot more that Deep Security offers to help you secure your application workloads on the Azure Cloud and fulfill your responsibilities in the Shared Responsibility Model.



Appendix:

Ways to run Deep Security Manager

In this HOL you have set up a DSM in Azure and You have seen how easy it was considering that you not only installed a virtual machine, but also a SQL server and set up database on it. You know what? It can be even easier!

Deep Security as a Service (DSaaS)

When running Deep Security as a Service, you will run as a tenant in a DSM hosted by Trend Micro. The DSM is fully maintained by Trend Micro and all you need to do is hooking up your workloads for protection. Billing is on usage basis, so if your workloads come and go all the time, this can be the cheapest option for you.

DSaaS can be provisioned through the Azure Marketplace or by visiting Trend Micro at http://www.trendmicro.com/azure. You can try it out by signing up for a 30-day free trial and be up and running within less than an hour.

Deep Security Manager (BYOL)

When deploying a Deep Security Manager from Azure Marketplace, you can have Azure do the heavy lifting when it comes to installation and you can provide a license which you have purchased from your reseller. This is the option we used in this lab and I provided you with the 30-day eval license.

Deep Security Manager

The last option from Azure Marketplace is same as the BYOL option, except that this time the license cost is included in the runtime cost of the Deep Security Manager. You choose how many clients you will connect to the DSM and you can see that your hourly bill will pick up the cost. For short bursts, this option is very convenient as you keep full control and only pay for your usage.

Hybrid Cloud deployment

If you have your own datacenter and want to manage all your workloads from one place, you can choose to run the Deep Security Manager inside your datacenter. In-house workloads and cloud workloads all register to the DSM in your datacenter. License is purchased through any of our resellers and entered into your Deep Security Manager. This option is very similar to what we did in this HOL, only that you run all workloads and the SQL server in your own datacenter.

http://www.trendmicro.com/azure

trend micro deep security azure hands on lab · • an azure account with an active subscription...

Documents