Deep Security For Service Providers

Transcription

1 A Trend Micro Technical White Paper July 2015 Deep Security For Service Providers Deep Security Architecture and Design Paper >> This paper is aimed at service providers that are offering cloud services such as Infrastructure as a Service (IaaS) and are looking for a security solution to provide security controls to their subscribers to help protect their workloads from various threats. This paper will help you design, implement, and integrate the Trend Micro Deep Security Platform into your cloud service offering. It contains a collection of best practices based on knowledge gathered from previous AWS deployments and lessons learned by Trend Micro from running Deep Security Software as a Service (DSaaS) in AWS.

2 Contents Getting Started...3 Introduction...3 Intended Audience...3 About the Paper...3 Help and Support...3 solution component and concepts...4 Deep Security Solution Components...4 Supporting Infrastructure Components...4 proposed architecture and design...5 What is Required for the Proposed Architecture?...5 Architecture Considerations...6 NETWORK AND SECURITY DESIGN...7 VPC Subnets...7 Network Communication Flows...8 From Subscribers (Incoming)...8 From Solution Components (Outgoing)...9 Between Solution Components...9 Security...10 SOLUTION COMPONENTS CONFIGURATIONS...10 Amazon EC2 AMIs and Instance Types for each Solution Component...10 Amazon RDS...11 AWS RDS Engine...11 Provisioned IOPS...11 AWS RDS Instance Class...11 Deep Security Manager...11 Agent Initiated Communication...12 ELB Integration...13 Simple Service Integration...13 Multi-Tenancy...13 License Model...14 Tenant Isolation...14 Tenant Template...15 Branding...15 Elastic Load Balancer...15 ELB-1 (For DSM Console Access)...15 ELB-2 (For DSA Heartbeat Communication)...16 ELB-3 (For DSA update Communication)...16 DEPLOYMENT AND MONITORING...17 Tenant (Subscriber) On-Boarding...17 Tenant (Subscriber) Authentication...17 Agent Deployment...18 Agent Deployment Script from the Script Generator...18 Health Checks...19 Changeback...19 Conclusion...20 Page 2 of 20 Trend Micro Technical White Paper

3 Getting Started introduction The Trend Micro Deep Security Platform provides a comprehensive security solution to help address a number of key requirements for service providers and their subscribers. Enterprises that are moving their workloads to hosted and public clouds as a means to gain flexibility, agility, or cost reductions expect to have a trustworthy and cloud-aware security solution. Trend Micro offers service providers a complete portfolio of security solutions with Deep Security that provides advanced server security for physical, virtual, and cloud servers, all from the same platform. By leveraging Deep Security, service providers can easily build and integrate a security solution into their cloud offerings. INTENDED AUDIENCE This paper is intended for Service Providers integrating Deep Security with their cloud solution offering. It is expected that the reader is comfortable with common computing, networking, and Amazon Web Services (AWS) terminologies and topics since the proposed architecture and design in this paper uses AWS. ABOUT THIS PAPER This paper includes architectural considerations and configuration steps for implementing highly available Trend Micro Deep Security in the AWS cloud. It discusses how to leverage AWS services, such as Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancer, AWS RDS, and Amazon Virtual Private Cloud (Amazon VPC) to build and integrate Deep Security in AWS. This paper is aimed at service providers that are offering cloud services such as Infrastructure as a Service (IaaS) and are looking for a security solution to provide security controls to their subscribers to help protect their workloads from various threats. This paper will help you to design, implement, and integrate Trend Micro Deep Security into your cloud service offering. It contains a collection of best practices that are based on knowledge gathered from previous AWS deployments and lessons learned by Trend Micro while running Deep Security Software as a Service (DSaaS) in AWS. HELP AND SUPPORT This paper is not meant to be a substitute for product documentation. For detailed information regarding installation, configuration, administration, and usage of Deep Security, please refer to the following links to online resources, documentation, and self-help tools: Page 3 of 20 Trend Micro Technical White Paper

4 Solution Components and Concepts To better understand how Deep Security and its solution components can be hosted in AWS and integrate with your service offering, first we have presented an overview of Trend Micro solution components and then list the supporting infrastructure services that are selected to implement the solution in AWS. DEEP SECURITY SOLUTION COMPONENTS Deep Security Manager (DSM) This is the management component of the system and is responsible for sending rules and security settings to the Deep Security Agents. The DSM is controlled using the web-based management console. From this interface, the administrator can define security policies, manage deployed agents, query status of various managed instances, etc. Deep Security Agent (DSA) This component is the enforcement point for all protection functionality on an EC2 instance using an agent. The nature of that protection depends on the rules and security settings that each DSA receives from the Deep Security Manager. Additionally, the DSA sends a regular heartbeat to the DSM, and pushes event logs and various other data points about the instance being protected to the DSM. Deep Security Relay (DSR) Deep Security Relay (DSR) relays Deep Security Updates from the Trend Micro Global Update Server to Deep Security Agents. You can create relay groups and assign members to the appropriate groups to create an update hierarchy if required. Database For Deep Security The database contains all persistent information that DSM needs to operate. This includes configuration details and event log information for each individual protected host, and other records required for DSM operation. In an xsp model when multi-tenancy is enabled, individual tenant s databases (called Tn) are also created to provide isolation. These Tn databases contain the security information, policies, users, and various tenant-specific data points. SUPPORTING INFRASTRUCTURE COMPONENTS Amazon Relational Database Service (RDS) To store Deep Security Data, we propose RDS service instead of running a dedicated database server on an EC2 instance. Trend Micro Deep Security supports MS SQL and Oracle DB. We recommend an AWS RDS with Oracle engine. The RDS choice simplifies the architecture since you don t have to setup individual instances to host DSM DB and make various architectural decisions. Once a database is created, you connect to the endpoint and only have to concern yourself with backup and restore windows and scaling the database. Elastic Load Balancing (ELB) To route communication traffic to Deep Security Solution Components (i.e., DSM and DSR) from the agents running on your subscribers instances, an Internet-facing ELB will be used. With this, you can add and remove DSM and DSR EC2 instances as your needs change without disrupting the overall flow of information among the solution components. Page 4 of 20 Trend Micro Technical White Paper

5 Amazon VPC The Deep Security components will be hosted in an AWS VPC environment with public and private subnets. VPC subnets that need to be accessible from the Internet through the VPC Internet gateway will be in public subnet. Subnets that will not be accessible from outside the VPC will be private. Amazon Simple Service (SES) To send messages for system alerts and reports from Deep Security Manager to your subscriber s inbox, we ll integrate DSM with SES. Amazon CloudWatch This monitors the health of Deep Security components and retrieves various monitoring data for them. These data metrics can be used to help troubleshoot and spot trends, etc. They can also be used to take automated action based on the state of your hosted environment. AWS Route53 This provides a highly available and scalable Domain Name System (DNS) service to provide name resolution for the Deep Security solution components. Proposed Architecture and Design WHAT IS REQUIRED FOR THE PROPOSED ARCHITECTURE For a highly available design, the following minimum 1 numbers of AWS and Trend Micro components/resources are needed: 1 RDS Instance to host Deep Security Application Data with Multi- AZ support enabled 1 EC2 Instance that serves as a NAT instance (1 per DMZ in each AZ) 1 EC2 Instance serving as a Remote Desktop Gateway (RDGW) server (1 per DMZ in each AZ) 3 Elastic Load Balancers (ELB) to route traffic to the Deep Security components 2 EC2 Instances to host the Deep Security Manager Application 2 EC2 Instances to host the Deep Security Relay Application scenario for HA 3 Public DNS names to assign to ELBs to allow component communication 1 If availability zone (AZ) failure is a concern then you will need extra resources based on the # of AZ in your final architecture. Page 5 of 20 Trend Micro Technical White Paper

6 The diagram below provides a high level view of the proposed architecture and design: Figure 1: High level view of the proposed architecture and design ARCHITECTURE CONSIDERATIONS In this proposed architecture we ve placed both DSM nodes in one AZ. This deployment choice is recommended to ensure the highest possible performance between Manager Instances and the Database and for cost reasons. In addition, Deep Security Manager is only used to configure the agents and define policies, etc. Thus, registered hosts remain protected in the event of an availability zone (AZ) outage. If AZ failure is a concern then you can host an additional node for DSM in another availability zone and also place additional relays in other AZs. These additional components can be either active to receive traffic or can be turned off and only turned on in case of AZ failures. We ve divided the reminder of this paper into the following sub-sections to discuss the proposed architecture and design shown above. Network and Security Design: in this section we ll discuss various best practices to set up your networking and security mechanisms available in AWS, e.g., Security Groups to enable authorized access and communication between tiers, instances, and traffic from your subscribers. Page 6 of 20 Trend Micro Technical White Paper

7 Solution Components Configurations: this section covers the details involved in the set up of the various solution components for each tier and their roles in the implementation. Deployment and Monitoring: this section provides details on deployment, monitoring, and management of the Deep Security Solution components. Network and Security Design VPC SUBNETS Networking is one of the most critical components of any implementation. When building and integrating Deep Security into your service offering there are various design decisions involved that will dictate your overall network design. We propose a multi-tiered (web, application, and database) network design by leveraging the AWS EC2-VPC platform, which allows you to reserve an isolated portion of the AWS cloud in which to deploy and manage your solution servers. The diagram below provides a high view of the proposed VPC layout with public and private subnets: Figure 2: Proposed VPC layout Page 7 of 20 Trend Micro Technical White Paper

8 NETWORK COMMUNICATION FLOWS From Subscribers (Incoming) The following network communication flows needs to be present to allow traffic from your subscribers: DSM Console: This is required to provide your subscribers (tenants) access to the DSM console via the ELB. DSA Heartbeat: This is required to provide your subscribers (tenants ) Agents access to the DSM for heartbeat via the ELB. DSA Security updates and plug-ins: This is required to provide your subscribers (tenants ) Agents access to the DSR to get security updates and fetch plug-ins via the ELB. We recommend having all incoming communication over TCP port 443 via ELB to avoid any subscriber s side firewall and security groups issues, since communication to Internet over TCP port 443 is usually allowed. The high level view for this recommended incoming communication channels is presented below: Figure 3: Incoming network communication flow Note: All ELBs will have externally resolvable DNS names, details are discussed later in this paper. The Relays can also be co-located on the DSM nodes to keep the cost down, when desired. Page 8 of 20 Trend Micro Technical White Paper

9 From Solution Components (Outgoing) The following network communication flows need to be present to allow traffic from the solution components: DSM: This is required to provide DSM access to the license update server and to download software packages from the Trend Micro Download center via the NAT server. DSR: This is required to provide DSR access to Trend Micro Active Update to get new pattern and engine files and security updates. DSA: This is required to provide DSA access to Trend Micro Web Reputation and File Reputation Services. The DSA is installed on DSM nodes for self-protection. All external network communication is done over TCP Ports 80 and 443. The high level view for this outgoing network communication channels are presented below: Figure 4: Outgoing network communication flow Between Solution Components The following network communication flows need to be present to allow traffic between the solution components: DSM to RDS: This is required to provide DSM access to AWS RDS for its data and configuration storage. DSM to DSR: This is required to provide DSM the Deep Security Rule updates to ensure the communication direction for DSR instances is set to Bi-Directional. DSR to DSM: This is required to provide DSR access to the Deep Security Manager to download plug-ins and software. Page 9 of 20 Trend Micro Technical White Paper

10 security To enable network traffic security for the incoming and outing traffic of your VPC and its specific subnets, there are two design choices available: Security Groups (SG) and Network ACL (NACL). We propose leveraging the security group approach and creating these security groups to control network communication as follows: Security Group Name Elastic Load Balancing Security Group Web Tier Security Group Application Tier Security Group Database Tier Security Group NAT Security Group Remote Desktop Security Group Purpose The ELB should be placed in this SG and accept connections from DSA on TCP port 443. The DSR should be placed in this SG and accept connections from the ELB SG on TCP port The DSM nodes should be placed in this SG and accept connections from ELB SG on TCP ports 4119, The DSM DB (AWS RDS) should be placed in this SG and accept connections from APP SG or DSM Nodes on TCP Port The NAT instances should be placed in this SG and accept connections from the solution components, i.e., DSM, DSA, and DSR for external access to the Internet for TCP ports 80 and 443. The RDGW should be placed in this SG to accept RDP connections from your on-premises operations team workstation on TCP Port 3389 or 22. Table 1: AWS security groups Solution Components Configurations AMAZON EC2 AMIS AND INSTANCE TYPES FOR EACH SOLUTION COMPONENT Each Trend Micro solution component has distinct requirements for software and infrastructure resources, such as CPU, RAM, and disk storage. Deep Security Solution Components can run on a variety of Amazon EC2 instance types, e.g., Windows and Linux. Below are the recommended specs for a typical xsp implementation. Solution Component Server Recommended Hardware Specs Available EC2 Instance Types AMI s Available Deep Security Manager Processor (vcpu) RAM HDD 64 bits (2-8 vcpu) 16 GB 80 GB m3.large, m3.xlarge, c3.xlarge, c3.2xlarge Windows: Microsoft Windows 2012 (64-bit), Windows Server 2008, 2008 R2 (64-bit), Windows 2003 R2 (64-bit) Linux: Red Hat 5, 6 (64-bit) Deep Security Relay Processor RAM HDD 64 bits (2-4 vcpu) 4 8 GB 40 GB m3.medium, m3.large Windows: Windows Server 2008, 2008 R2 Windows Server 2003 R2 (64-bit) Linux: Red Hat 5, 6, 7 (64-bit), CentOS, 5, 6, 7 (64-bit), Ubuntu 10.04, 12.04, (64-bit), SUSE 10 SP3, SP4 (64-bit), SUSE 11 SP1, SP2, SP3 (64-bit) and Amazon AMI Linux EC2 (64-bit) Table 2: Solution components AMI hardware specifications Page 10 of 20 Trend Micro Technical White Paper

11 AMAZON RDS We propose AWS RDS service instead of running a dedicated database server on an EC2 instance. This choice simplifies the architecture since you don t have to set up individual instances to host DSM DB and make various architectural decisions. Once a database is created, you connect to the endpoint and only have to concern yourself with backup and restore windows and scaling the database. The rest of the server maintenance, database system upgrades, operational monitoring is all handled as part of the AWS service. AWS RDS Engine Trend Micro Deep Security supports MS SQL and Oracle DB. We recommend AWS RDS with the Oracle engine for service providers-based deployment because: For the Deep Security Multi-Tenancy feature, running an MS SQL-based RDS will result in the creation of a separate DB each time you create a new tenant. This means that each tenant would trigger the minimum storage and hourly computational costs for RDS. When using Oracle as a database engine, DS uses multiple schemas within the same database to implement multi-tenancy. Scaling storage after launching a DB instance is currently not supported for SQL Server. The minimal storage requirements for MSSQL RDS instances are significantly higher than Oracle. When the MT feature is used in Deep Security, Multi-AZ support is also required on the DB level. Note: Visit for the limitations around AWS RDS, e.g., the total storage limit for all DB instance is 100 TB. Provisioned IOPS Trend Micro Deep Security requires fast and consistent I/O performance, hence we recommend Provisioned IOPS (input/output operations per second) storage. Start with 1000 IOPS and increase it when needed. The ratio of the requested IOPS rate to the amount of storage allocated is important. The ratio of IOPS to storage, in GB, for your DB instances should be between 3:1 and 10:1. For example, you could start by provisioning an Oracle DB instance with 1000 IOPS and 200 GB storage (a ratio of 5:1). You could then scale up to 2000 IOPS with 200 GB of storage (a ratio of 10:1), 3000 IOPS with 300 GB of storage, and up to the maximum for an Oracle DB instance of 30,000 IOPS with 3 TB (3000 GB) of storage. AWS RDS Instance Class We recommend memory allocation for the AWS RDS instance to be a minimum of 10% of your DB size plus some available memory for overhead. This will ensure the DB indexes are kept in memory for better performance. DEEP SECURITY MANAGER The Deep Security Manager will be a member of the Application Tier Security Group created for servers running in the Application Tier. Both DSM nodes (DSM1 and DSM2) should be running in the same AZ where DSM DB (AWS RDS - Primary) is running. It is recommended to host DSM nodes in the same AZ where the DSM DB is running to avoid network latency issues. The DSM node accessing the DB in a separate AZ has shown hit in performance so it s very critical to put DSM nodes in the same AZ as DSM DB. If Multi-AZ support is required then consider hosting three DSM nodes, two in the same AZ where DSM DB is running and one in the other AZ but shut down. This third node will not receive any traffic from ELB. You can start this node in case of a primary AZ disaster. Page 11 of 20 Trend Micro Technical White Paper

12 Agent Initiated Communication To Allow Deep Security Manager to Deep Security Agent communication, Deep security provides three communication direction choices as follows: Bi-Directional: By default, communications are bi-directional. This means that the Agent normally initiates the heartbeat but still listens on the Agent port for Deep Security Manager (DSM) connections. This allows the Manager to apply changes to the security configuration to the Agent as they occur. Manager Initiated: With this option, The Deep Security Manager always initiates the communication with Agent. This includes security configuration updates, heartbeat operations, and requests for Event logs. Agent Initiated: With this option selected, Agent initiates the communication with the Manager. In this mode, communications between the Manager and the Agent only occur on every heartbeat. If an Agent security configuration has changed, it will not be updated until the next heartbeat. We recommend using Agent Initiated communication since this configuration is easy to implement for your subscribers instances in EC2 or inside a VPC. For EC2 instances, your subscribers don t need to do anything. Since all outbound communications in EC2 are permitted, agents will work by default. Within a VPC, your subscribers must enable an outbound route through an Internet gateway. They must also add a rule to allow outbound communications for TCP over port 443. Most configurations will benefit from a rule that allows TCP over port 443 to address block /0 (everywhere). But if you prefer to lock down this rule further for your subscribers, then depending on where you have implemented this solution and where your subscribers are, they can restrict outbound communication to 443 to your service AWS security group, i.e., < owner ID>/<SG>. The agent initiated communication direction should be configured at the Base Policy Level under Settings > Computer > Communication Direction as shown: Figure 5: Agent initiated communication direction Page 12 of 20 Trend Micro Technical White Paper

13 ELB Integration The Deep Security Manager should be configured for ELB integration to allow the incoming communication flows that we discussed earlier in this paper. The settings that you must configure for this integration are listed under Administration > System Settings > Advanced as shown: Figure 6: DSM integration with ELB The Manager, Heartbeat, and Relay hostname fields should be pointing to the externally resolvable DNS name of these ELBs. If CNAME records for ELB are created for ELB s DNS addresses, then these fields should contain the CNAME records. Simple Service Integration The Deep Security Manager should be configured for SES integration to receive various alerts, notifications, and reporting features. The settings that you must configure for this integration are listed under Administration > System Settings > SMTP as shown: Figure 7: AWS SES integration with DSM Multi-Tenancy Multi-Tenancy lets you create multiple distinct management environments using a single Deep Security Manager and database server installation. It fully isolates the settings, policies, and events for each tenant and makes use of a number of additional infrastructure scaling options. Multi-Tenancy helps you, as a providers, provision Deep Security to subscribers within a service model. Multi-Tenancy is enabled under Administration > System Settings > Advanced. Page 13 of 20 Trend Micro Technical White Paper

14 LICENSING MODEL There are two license modes that you can implement: Inherit Licensing from Primary Tenant: Gives all tenants the same license that you as a provider (Primary Tenant) have and all the licensed security modules that you (the Primary Tenant) are licensed for will be visible to all tenants. Contact your sales representative on XSP pricing for further details. Per-Tenant Licensing: As the name implies, it is a per-tenant license and only the licensed security modules for each tenant will be visible to tenants. We recommend using Inherit Licensing mode and then controlling the security module visibility at the tenant level. Doing so will avoid the step required to acquire a license key from Trend Micro. Tenant Isolation Multiple tenants (subscribers) exist within the same Deep Security Manager installation but their data is highly isolated. The majority of each Tenant s data is stored in a separate database. This database may co-exist on the same database server (AWS RDS) as other tenants, or it can be isolated onto its own database server (AWS RDS). In all cases, some data only exists in the primary database (the one Deep Security Manager was installed with). When multiple database servers are available, tenants are created on the database with the least amount of load. In the first option, a single RDS DB is used to host both the main database and all of your tenants databases. This option is suitable where the number of tenants is not high (less than 100). In the second option, 3 RDS instances are used. 1 RDS is reserved for the main database and the other 2 are used to host tenants databases. You can start with 2 RDS instances (1 for the main database t0) and the other for all tenants (t1, t2, t3 tn) and can add further RDS instances to the pool when needed. The high level view for these design choices are shown below: Figure 8: Multi-tenancy architecture in Deep Security Page 14 of 20 Trend Micro Technical White Paper

15 Tenant Template The Tenant Template feature of Deep Security provides a convenient way of creating a customized out-of-the-box experience for your subscribers. While Deep Security provides advanced server security for physical, virtual, and cloud servers, all from the same platform, some of the available features are not applicable to your implementation, e.g., AWS-based deployments. For this reason, it is recommended as a service provider you create a tenant based on your implementation and fine tune out-of-the-box policies and settings. We recommend setting the agent communication direction to Agent Initiated in the template for all subscribers as discussed earlier. All of your future Tenants will have the example policies and rule update versions included in the snapshot (tenant template). As always the examples are meant to be a starting point. Tenants are encouraged to create policies based on their unique needs. The Tenant Template is created under Administration > System Settings > Tenants as shown: Figure 9: Tenant template Branding You can customize and add your own logo to the Deep Security Manager Console for branding purposes and replace the Deep Security logo at the top-right of the Deep Security Manager interface. (The logo also appears on the sign-in page and at the top of Reports.) The graphic has to be a PNG image 320 pixels wide x 35 pixels high, and smaller than 1 MB. (A template is available in the installfiles directory of the Deep Security Manager.) ELASTIC LOAD BALANCER The ELBs are used to route DSA and DSM console traffic to Deep Security Manager as discussed under the communication flows section. A total of three ELBs are needed to cover all types of communication flows. All of these ELB instances will be a member of the ELB Security Group and have an externally resolvable DNS name. ELB-1 (For DSM Console Access) The subscribers will access the DSM console using a browser over HTTPS, hence a trusted certificate needs to be imported into the ELB configuration to avoid certificate warnings each time your subscribers access the DSM console. The listener should be created as HTTP/HTTPS for this traffic flow and session stickiness should be enabled with 30 minutes or higher expiry time period as needed. For the instance health check you can use the DSM GUI access port, The DNS name for this ELB could be anything that is relevant to your implementation but consider appending app in your subdomain part for easier reference purposes, e.g., app.provider.com. The DSM node 1 and DSM node 2 instances should be registered in this ELB. Page 15 of 20 Trend Micro Technical White Paper

16 ELB-2 (For DSA Heartbeat Communication) The DSA to DSM agent communication is SSL-based and requires mutual authentication, hence it is required to pass through the DSA > DSM communication from the ELB instead of breaking the SSL connection. The listener should be created as TCP for this traffic flow. The DNS name for this ELB could be anything that is relevant to your implementation but consider appending agents in your subdomain part for easier reference purposes, e.g., agents.provider.com. The DSM node 1 and DSM node 2 instances should be registered in this ELB. Figure 10: SSL passthrough (non-terminating) listener for Heartbeat traffic ELB-3 (For DSA Update Communication) The DSA to DSR communication is SSL-based but it doesn t require mutual authentication, hence it is not required to pass through the DSA > DSR communication from the ELB. Instead breaking the SSL connection at ELB is fine. The listener should be created as HTTP/HTTPS for this traffic flow and session stickiness should be enabled with 30 minutes or higher expiry time period as needed. A trusted certificate is not required for the ELB configuration. A self-signed certificate for this ELB configuration is fine. For the instance health check you can use DSR port 4122 for the ping test as shown. Figure 11: DSR health check from ELB The DNS name for this ELB could be anything that is relevant to your implementation but consider appending relays in your subdomain part for easier reference purposes, e.g., relays.provider.com. Page 16 of 20 Trend Micro Technical White Paper

17 Deployment and Monitoring TENANT (SUBSCRIBER) ON-BOARDING The tenant on-boarding can be done either: By leveraging the REST API and integrating it with your service portal By leveraging the out-of-box Tenant Creation Wizard in Deep Security Manager During the tenant on-board process, the tenant DB is created and populated with pre-configured security policies and settings from the tenant template you created earlier on. The tenant admin can then login to their isolated deep security environment and protect their workloads. TENANT (SUBSCRIBER) AUTHENTICATION Tenant management capabilities are also available via the REST API so as service providers you can integrate Deep Security into your existing portals. Regardless of how you decide to present the Deep Security Manager Interface to your subscribers (either through your portal via REST API s integration or direct access), the tenant authentication is performed against the tenant database. The login page includes Tenant Name that provides the context information to Deep Security when authenticating tenants. The following diagram provides the high level view of tenant authentication: Figure 12: Tenant authentication Page 17 of 20 Trend Micro Technical White Paper

18 AGENT DEPLOYMENT There are multiple ways the agent can be installed and deployed into your subscribers instances. Subscribers can also integrate the deep security agent into their provisioning process of instances: It can be a direct installation using the installer packages for the supported operation systems It could be any software delivery method the subscriber is using, from SMS to in-house scripting, to cloud management tools like Rightscale, Chef, Puppet, or Amazon Cloud Formation. Deep Security also provides shell-/power shell-based scripts that can be generated from the Deep Security Web Console. It can also be embedded into your AMI. When embedding an agent into the AMI, ensure the agent is not activated. Agent Deployment Script from the Script Generator The shell/powershell script-based method to install and deploy a Deep Security agent is an easier way to automatically generate a deployment script from a Trend Micro Deep Security Agent which can include tasks such as: Download Deep Security Agent from the Deep Security Manager server or from an S3 bucket Do a silent installation of Deep Security Agent Call Deep Security Manager and then request activation against the specific subscriber (tenant) installation Request a specific security policy assignment (e.g., security policy for a web server or security policy for database servers, etc.). The deployment script can be generated from Administration > Local > Generate Deployment Script. Figure 13: Agent deployment script Page 18 of 20 Trend Micro Technical White Paper

19 This deployment script can then be used in instance provisioning e.g., in user-data field as shown: Figure 14: Agent deployment via user-data HEALTH CHECKS The Deep Security Manager gathers monitoring information every minute and provides a dashboard widget to show system memory, CPU, and raise warnings if these resources reach their configured limit values. Figure 15: DSM widget to monitor system resources In addition, Amazon provides CloudWatch under AWS. Amazon CloudWatch basic monitoring collects and reports metrics for CPU utilization, data transfer, and disk usage activity from each Amazon EC2 instance at a five-minute frequency. You can also consider using Detailed Monitoring to collect metrics at 1-minute intervals. You can then use these metrics and take actions to automate the majority of the solution through AWS API in case of failures. CHARGEBACK The Deep Security Manager stores information about tenant usage that can be used by the services providers to charge their subscribers. The information is available in: Widget Form: Shows various metrics about tenant usage, e.g., protection hours, DB use, etc. Report: This report details protection hours, the current database sizes, and the number of computers (activated and non-activated) for each tenant. REST API: The API s stored data can also be pulled directly from the DSM DB to produce reports for chargeback. Page 19 of 20 Trend Micro Technical White Paper

20 Conclusion We used AWS as a computing environment to design, implement, and integrate Trend Micro Deep Security into your cloud service offerings. The similar design approach can be used to implement and integrate this solution in Microsoft Azure or even in your on-premises data center. By incorporating Trend Micro Deep Security into your solution offerings you get: Increased service adoption rates and market share by acquiring security-conscience buyers Differentiation from rival providers not offering brand-specific or other security complements Collection of effective cloud security technologies proven to work within the unique cloud environment Additional revenue through application, server, and data protection services Combined brand recognition and publicity through partnership and co-marketing activities Trend Micro Incorporated is a pioneer in secure content and threat management. Founded in 1988, Trend Micro provides individuals and organizations of all sizes with award-winning security software, hardware and services. With headquarters in Tokyo and operations in more than 30 countries, Trend Micro solutions are sold through corporate and value-added resellers and service providers worldwide. For additional information and evaluation copies of Trend Micro products and services, visit our Web site at by Trend Micro Incorporated. All rights reserved. Trend Micro, the Trend Micro t-ball logo, and Smart Protection Network are trademarks or registered trademarks of Trend Micro Incorporated. All other company and/or product names may be trademarks or registered trademarks of their owners. Information contained in this document is subject to change without notice. [WP01_DS_xSP_MT_DesignGuide_150714US] Page 20 of 20 Trend Micro Technical White Paper