Chapter 11 — User Roles and Policy Modification 1-41 Chapter 11: User Roles and Policy Modification Chapter Objectives After completing this chapter you will be able to: ‘© Define user roles and create a user with a specific role ‘* Define and create partitions ‘© Use Policy Diff and merge policies ‘© Edit and export an application security policy * Describe common ASM deployment types * Define ASM synchronization © Define the purpose of the ASMQKVIEW file Defining User Roles In many organizations, it is not uncommon for network management and security management to be separate. Furthermore, in many ASM implementations, different individuals may be responsible for ‘managing application security or managing the network. AP system resources. You assign a user role to each jons for accessing BIG-IP system resources. More User roles are a means of controlling access to BI user and, in doing so grant the user a set of permi specifically, a user role defines: © The resources a user can manage ~ For example, a user with the role of Application Security Administrator can manage all components of the ASM module, but has no access to LTM or TMOS objects—such as virtual servers and pools. By contrast, a user with the Administrator role can manage all objects on the BIG-IP. © The tasks a user can perform on those resourees — For example, a user with the role of Application Security Editor can view security policies and attack signatures, but cannot create ‘or manage those resources, ‘The ASM-specific user roles of Application Security Administrator and Application Security Editor exist with managing ASM security in mind, A third role of Resource Administrator can also be assigned toa user. Application Security Administrator The Application Security Administrator user role does not have access to virtual servers and pools. This access level grants full access to Security Policies, Statisties, Logs, and options in ASM on the BIG-IP. This role is only available with ASM. Configuring BIG-IP ASM v12 W4111-2 Chapter 11 - User Roles, policy modification, and other deployments Application Security Editor This access level provides full read/write access to security policies which are in the partition(s) where the user has the role, In that case, this user will have no access and will not be able to view other security policies. This role has no access to the ASM internal settings and attack signatures — but has access to logs. This role is only available with ASM. Resource Administrator This access level grants users complete access to all objects, except access to user account objects. This, role can also perform configuration synchronization on a redundant system, load, and save configuration files. This user role has access to ASM internal parameters, security policies, and logs. Administrative Partitions An administrative partition is a logical container for BIG-IP system objects, such as virtual servers, pools, profiles, and monitors. By putting objects into partitions, you can then allow or disallow specific partition access for specific users, Rather than have control over al! resources or no resources, a user account can be configured to have control over only those resources defined within a particular partition. Users themselves are considered resources (or objects) in terms of partitioning. User account objects can be put into a partition for the purpose of giving other users administrative access to those accounts. Each user account on the BIG-IP system has a property known as Partition Access that defines the partitions the user can access, A user account can have access to either one partition or all partitions (also known as universal access). The following configuration objects can exist in separate partitions: User accounts Virtual servers Pools Pool members Nodes Custom profiles Custom monitors SSL keys Certificates Certificate revocation lists iApps templates and application instances, Application security policies Until you create other partitions on the system, all objects that you or other users create automatically reside in the Common partition. If you create other partitions later, you cannot move an object in ‘Common to one of the new partitions. Instead, you must delete the object from Common and recreate it in the new partition. With respect to permissions, all users on the system except those with a user role of No Access have read access to objects in the Common partition, and by default, the Common partition is their current partition. ‘The current partition is the specific partition to which a logged-in user currently has access, as determined by the properties of that user's account. Whenever a user performs an action on the BIG-IP system, the system automatically performs that action within the current partition. A user account grants permission to access either a single partition (other than Common) or all partitions. Ifa user has permission to access one partition only, the user cannot select the current partition. Instead, the BIG-IP 11-2 Configuring BIG-IP ASM v12Chapter 11 — User Roles and Policy Modification 11-3 system establishes the user’s current partition at login time, based on the particular partition access that is specified in the properties of that user account. Users who have permission to access all partitions ean actively select the current partition, that is, the specific partition they want to view or manage. Allowed Object References across Partitions ‘A default partition called Common is created when you first install the BIG-IP system. (Up until now, all the configuration objects you have created on your BIG-IP system have been defined in Common.) This partition is unique in that the objects in the Common partition can be referenced by objects that are contained in other partitions that, for lack of a better term, we'll call tenant partitions. For example, as illustrated below, a virtual server definition in tenant PartA and another in tenant PartB can both reference the profile called client_ssl that is in default partition Common. Part of the reason for this special relationship is that the Common partition is “home” to all the default BIG-IP objects such as default profiles, default monitors, and default authentication iRules, as well as to any custom profiles, monitors, iRules, and other configuration objects that network administrators might define to be shared across tenant partitions. /Parta /Parté ve_parta vs_partb profile profile /conmon/eclient_ssi /common/client.s ‘/Common Figure 1: A vital server definition in PartA and another in PartB can both reference the profile called client_ss that is in default partition Common. Until tenant partitions are explicitly created on the BIG-IP system, all objects will be placed in the default Common partition. Once an object is placed in its partition “folder.” it cannot be moved to another partition without deleting it first from its existing partition, and then redefining it in the new partition Configuring BIG-IP ASM v12 11-311-4 Chapter 11 - User Roles, policy modification, and other deployments Partitions Facilitate Administrative Agility You can assign an authorized partition (known as partition access) to a user account. A partition access assignment gives a user some level of authority over the specified partition. For all user roles, you can assign universal access to partitions, which grants users permission to access all partitions instead of one ‘non-Common partition only. Note that assigning partition access to a user does not make the user @ member of that partition, nor does it necessarily give the user full access to all objects in the partition. When a user logs in to BIG-IP, they will be automatically placed in the one partition they are assigned to and have no ability to navigate to other partitions, whether using the GUI or tmsh. Users with universal access (access to all partitions), will automatically be placed in the Common partition upon logging in, Navigation to other partitions can be done via the Partition menu. Figure 2: The partion menu isin the top right-hand comer ofthe user interface. 11-4 Configuring BIG-IP ASM v12Lab 11.1 - Configuring User Roles & Partitions Lab Objectives ‘© Create a new partitions © Create new users assigning different roles with access to different partitions ‘© Verify access to security policies Estimated time for completion: 20 minutes Lab Requirements © Access to the auction site via a working Virtual Server with Application Security Policy enabled © A working user account on the auction site Adding a New Partition 1 2. Click the Create button. 3. Within the Properties section, specify the following: to System >» Users: Partition List. meu n Lg errors Partition Name ‘security editor_partition Retiree nek Device Group Accept defaults ‘When complete, click... Finished 4, From the Partition drop-down menu in the top right comer of the window, verify that your new partition is added. 5, Ensure you are still in the Common partition before continuing.Adding a User with Access to all Partitions 6. Click the User List tab. 7. Click the Create button. 8. Within the Account Properties section, configure the following: OSCE a cae ese Cd ae eee ay User Name ‘sec_admin Password New =a Confirm = at Role From the dropdown menu, select Application Security Administrator Partition Access All (default for Application Security Administrator) [With user configured, cick... | Add When complete, click. Finished Adding a User with Access to the security_editor partition / 9. Click the Create button 10. Within the Account Properties section, specify the following: System » Users: User List » New User. raed | user Name sec_editor Password _| New = et Confirm = et Role From the dropdown menu, select Application Security Editor Partition Access: security editor_partition ‘With user configured, click... | Add When complete, click... Finished Selecting a different Partition 11. From the Partition menu in the top right corner of the screen, select seeurity_editor_partition. Let's create a very simple test security policy in the seeurity_editor_partition. ies, and then click Create. 12. Go to Application Security: Security Policies: Active Poli 13. In the Local Traffic Deployment Scenario section, select Do not associate with Virtual Server, and then click Next. 14. Accept the default option to Create a security pol and then click Next, 15, In the Security Policy Name field, enter partition_test, and then click Next. 16. Accept default settings for Atack Signatures, and then click Next. 17, Accept default settings on the Configure Automatic Pol ling screen, and then click Next.18. Click Finish. Verifying Security_Editor Access 19, Log out of the Configuration Utility and log back in with the see_editor account,~ 20. Notice this user has access to only the security_editor_partition. There is no dropdown merfa to select other partitions 21. Goto Ap 22. How many policies and what actions on them are available to this user? The only accessible policy is the one created in the security_editor_partition, mn Security: Security Policies: Active Policies. 23. Go to Local Traffic. Does this user have access to all Local Traffic objects such as virtual servers and pools? The user should not. ~) 0, Verifying Security Administrator Access and log back in with the see_admin account: 24. Log out of the Configuration Utili 25. Go to Application Security: Security Policies: Active Policies. / 26. Does this user have access to all security policies? The user should. Examining Virtual Servers and partitions AA virtual server in any partition can use a security policy in the Common partition. However, a virtual server in the Common partition cannot use a security policy in a different partition. Let's examine this: 27. Log out of the Configuration Utility and then log back in as admin. 28. Go to Local Traffic »» Virtual Servers: Virtual Server List. 29, From the Partition menu, select seeurity_editor_partition. 30. Click asm_ys. 31. Click Security and then click Policies. 32. Are you able to assign the security policy in the security_editor_partition to this virtual server? You ~~ should not be able to do so. Expected Results: After completing this lab you should have an ASM user with limited access to certain partitions and local traffic objects.PO muri Tena Lab Cleanup Let's deactivate the test security policy. This action will move it to the Inactive Security Policies list where it can be deleted. Then you will delete both test partition users and the security_ 33. Ensure you are in the seeurity_editor_partition 34. Go to Application Security: Security Policies: Active Policies. 35, Select the radio button to the left of your test security policy, and then click Deactivate _/%&: Click OK when prompted, and then click the Inaetive Policies tab 34% Select the checkbox for your test security policy, and then click Delete. 38. From the Partition menu, select Common. 39. System >» Users: User List. AO. Delete see_admin and sec_editor. 41. At the top of the screen, click the Partition List link. 42 Delete the security_editor_partition| F Chapter 11 - User Roles, policy modification, and other deployments 11.9 Comparing Security Policies Some administrators use security policy comparisons for auditing purposes, to ensure similar function between two policies, or to view the differences between staging and production versions. Policy Diff can be used to calculate differences between two policies in order to help the administrator determine if and how the attributes of one policy should be merged into the other. Policy Diff Requirements ‘© The two policies must be on the same BIG-IP system, or accessible from the system you are using ‘* Policies must have the same language encoding © Policies must have the same protocol (Differentiate between HTTP and HTTPS URLs) configuration © Policies must have same case sensitivity configuration Working Mode: Protecting the original security policy It is a recommended practice to safeguard the original security policy in the event that an administrator needs to revert from a merged policy. To facilitate this, there are three options for working on a policy merge: Work on Copy Use this mode when you want to keep the selected policies intact. Changes are only made to copies of the original security policies, and the copies are placed into the Inactive Policies list after the merge is complete. Work on Original This mode incorporates changes to one (or both) of the original security policies without making any copies. Changes made will overwrite current settings, and the settings of the original policies will not be saved. Make a Copy Use this mode when you want to work on the original security policies and overwrite their settings. ASM will still save copies of the original security policies and place them in the Inactive Policies list where they can be used as backups if necessary. Policy Dit FestPokey Polcy,A __* or Choose Fle /Nofie chosen ‘Second Polcy Polcy.& _* or Choose Fie |No fe chosen Figure 3: Policy Diff calculates differences between two policies. Configuring BIG-IP ASM v12 11-914-10 Chapter 11 - User Roles, policy modification, and other deployments Merging Security Policies After calculating differences, the administrator must decide if ASM should auto-merge differences, or if each one should be examined and merged individually. The Policy Differences Summary screen lists, differing entity types. Each row is clickable and leads to a configuration screen for a specific difference. ‘oye Sn A aici onmeanab colt Com tt hal ea ett ae Onin cun ITP cheeks ‘ 1 ° 1 « 2 Figure 4: Policy ciferences aro grouped by entity on the summary sereen fusing the manual method, the administrator can choose to ignore different entities and attributes from one policy and prevent them from being merged into the other. Defining Auto Merge options Handle missing entities This option allows the administrator to decide how to treat entities that exist in one security policy but not the other. By default, both checkboxes are selected. The Auto Merge process adds unique entities from each policy into the policy from which they are missing. Handle missing entities @ Add all unique entities from “;CommonvLaby1t_a’ 'iCommonvLab1t_ @ Add all unique entities ftom "CommonvLabt1_b" "iCommoniLabtt_a" Figure 5: Entiies missing in one policy can be added from another policy. 1, To move missing entities from the second policy to the first, select Add all unique entities from to 2. To move missing entities from the first policy to the second, select Add all unique entities from to . It you do not want to merge missing entities, leave both checkboxes blank. 11-10 Configuring BIG-IP ASM v12Chapter 11 - User Roles, policy modification, and other deployments 14-11 Handle common entities 3s that have conflicting attributes, such as This option allows the administrator to decide how to treat e a wildcard staging, or byte length differences for a parameter. Handle common entities for “/Commoni.ab11_a” and "Common jab11_b" © Leave unchanged ‘Accept all from "/CommoniLab11_a” to "/Common/Lab11_b" Accept all from "(CommoniLab11_b" to "/Common/Lab11_a” Figure 6: Entities with conflicting attributes can be merged. 1. Tomake no changes to either policy when entities are different, select Leave unchanged. 2. To use the differing entities from the first policy and move them to the second, select Accept all from to . To use the differing entities from the second policy and move them to the first, select Accept all 3, from to . Configuring BIG-IP ASM v12 11-1111-12 Chapter 11 - User Roles, policy modification, and other deployments Editing and Exporting Security Policies You can export a security policy as a binary archive file or as a readable XML file. This allows users to compose a security policy in XML-format and import that into ASM. You can also export existing security policies into XML-format and modify the file manually or programmatically. When exporting, all wildcard entities (file types, URLs, and parameters) are exported according to their wildcard order. When wildcard entities are imported, they will automatically be assigned indexes beginning with 1. ‘according to their order in the XML file. To view the security policy in XML format, perform the following steps: 1. Go to Security » Application Securit ‘es: Active Policies. 2. Select the radio button for the security policy you wish to export. 3. Click the Export button ‘This will open a popup window with a choice to either perform a binary export of the selected security policy or export the details of the selected security policy as an XML file. When opened, the XML file displays the configured settings of the security policy items in a readable format. If you choose to export the security policy as an XML file, you can select the option to export in a compact format, which results in a smaller XML file. The differences between a security policy in regular format and in compact format are important. In compact format, ASM does not export the staging state of attack signatures. In compact format, ASM exports information regarding the following items only if they are different from how they were created by default: Meta-Character sets Blocking Page Learn, Alarm, and Block settings Response Pages IP Reputation Categories Restoring with Policy History From the Policy : History screen you can view a list of policies organized by when they were last applied and when they were replaced by a newer version. A security policy gets versioned each time it is applied. Itis possible to restore a policy to a previously known version using the policy history. fated At = When the security policy was last applied, Un = When the security policy was outdated by a newer version. You can restore a previous version of the security policy or copy a previous version of the security policy to the inactive security policies list ‘© Current Policy “name of security policy” replaces the current active security policy with this version of the security policy. ‘© Inactive Security Policies policies list. {st copies this version of the security policy to the inactive security 14-12 Configuring BIG-IP ASM v12Lab 11.2 — Using Policy Diff and Po! Lab Objectives icy Merge ‘© Create two different policies ‘© View differences ‘¢ Merge an attribute of one policy into another Estimated time for completion: 15 minutes Lab Requirements * Access to the auction site via a working Virtual Server with Application Security Policy enabled * Aworking user account on the auction site '* Access to a text editor application on your workstation Create a new Security Policy 1. Go to Application Security: Security Policies: Active Policies. 2. Click Create. 3, Select the Do not associate with Virtual Server option. 4, Click Next. 5. Inthe Select Deployment Scenario panel, select Create a policy manually or use templates (advanced), and then click Next. 6. Configure the following settings for the new security policy Pura) Configure Security Policy Properties Securty Policy Name labtt_a Application Language Unicode (utf-8) Application-Ready Security | ensure None is selected. Policy When complete, click. Next 7. Accept the default attack signatures, and then click Next. 8. Accept the default settings for Explicit Entities Learning and then click Next. 9. Click Next. 10. Click Finish.Create a second Security Policy 1. Go to Application Security: Security Policies: Active Policies. Click Create. Select the Do not associate with Virtual Server option, Click Next In the Select Deployment Scenario panel, select Create a policy manually or use templates (advanced), and then click Next. 6. Configure the following settings for the new security policy: Dera ei) Ce aaa ay ‘Security Policy Name labtt_b Application Language Unicode (ut-8) Applcation-Ready Securty | Rapid Deployment security policy When complete, click. Next 7. Accept the default attack signatures, and then click Next. 8. Click Finish, Let's modify the attack signature set attributes of the labl -efsily from labLI_a. _b policy in order to differenti 9. On the Security Policy Properties page, click Attack Signatures Configuration 10. In the Attack Signatures section, click Change. 11. Select one of the signature sets not currently applied to this policy, and then click Change. 12. Click Save and then Apply Policy. Complete Policy Diff 13. Go to Application Securit 14. Click the Policy Diff tab. 15, From the First Policy menu, select labL1_a. Security Policies: Active Poli 16, From the Second Policy menu, select lab11_b. 17. From the Working Mode menu, accept the default option to Work on Ori 18, Click Caleulate Differences View Policy Differences Summary 19, Locate Policy Signature Set in the Entity Type column. (It is near the bottom of the list.) 20. There should be a value in the Only in/Common/lab11_b column because that signature only applied to lab11_b. areEct Cra 21. Click Auto Merge. 22. Use the diagram below to configure the merge so that unique entities from lab11_b are added to lab1L_a. Handle missing entities | | Ade ll unique enies trom ";Common/ab1_a’ to "iCommon/ab1_b" | | | | | | | | % Add all unique entities trom "/Commonviab11_b* to "/Commonvlab11_ Handle common entities for "/Commontlab11_¢ "¥Commonvab11_b' ® Leave unchanged nd, ‘Accept all from */Commonvlab 11_a" to "/Commonviabt1_b” ‘Accept all from "/Commonilab11_b" to "/Commonviab11_a° Cancel| Merge 13. Click Merge. 24 On the right-hand side of the Pt 25. View the attack signature properties of lab1_a. You should see the attack signature set merged from labLL_b. icy Diff window, click Apply Poliey. Expected Results: At the end of this lab, you should see be able to complete a Policy Diff operation between two policies, and then merge different attributes from one policy into another.Lab 11.3 -Security Policy Editing Lab Objectives * Export an existing security policy | * Modify the existing security poticy | * Import and load changes into ASM ‘© Verify configuration changes Estimated time for completion: 15 minutes Lab Requirements ‘© Access to the auction site via a working Virtual Server with Application Security Policy enabled ‘© A working user account on the auction site © Access to a text editor application on your workstation ‘© Anexisting security policy from the previous lab View Current Configuration Settings 1. Go Application Security Click labLt_b. : Security Polici ity Policy Properties menu, select Advanced. Let's review several policy settings which you will modify later. 4, What is the Maximum HTTP Header Length? 5. 15503 an Allowed Response Status Code? 6. Isthe policy in Blocking mode? Export security policy 7. Go to Application Security: Sec ity Policies: 8. Ensure that the radio button for lab11_b is selected. 9. Click the Export button Active Policies. 10. Ensure that the Export security policy in XML radio button is selected. 11. Click the Compact format checkbox, and then export the file to your desktop. Modifying securi policy 12. Save the file to your desktop. 13, Double-click the XML file to open it in your default web browser.14, Notice that many XML tags, such as poliey_name at the top of the document, map to many of the GUT items you have already configured. 15, To modify the file, right-click on the XML document and Open with WordPad. Make the following modifications to the security policy (you can use find and replace in WordPad). - Set Maximum http length to 5000 bytes - Change the enforcement mode of the policy to blocking (use lower case in the XML tag) = Delete lowed response code 503 16, Save your modifications and close the document. Import modified security policy Let’s import the modified security policy into ASM and verify that your changes have been made, 17, Goto Application Security: Security Po! 18, Click the Import button (located in the top right hand comer of the screen.) 1 click Choose File, and then double-click on your policy 19, In the Import Securi XML file, 20. In the Import Target section, select the radio button for Replaced Policy, and then select lab11_b. This will replace the existing lab11_b policy with the file you modified. Poliey secti 21. Click Import. You should receive a message indicating the success of the import operation, 22. Click OK. Verify configuration changes 23. On the Application Security: Security Pi policy is now in Blocking mode. ies: Active Policies page, note that your imported 24. Click on the link for the imported policy. 25. From the Security Policy Properties menu, select Advanced. 26, Notice the Maximum HTTP Header Length has changed to 5000 (from the default of 8192) bytes. 27. 1s 503 still an Allowed Response Status Code? It should not be. Expected Results: ‘At the end of this lab, you should see the changes you made to a security policy by editing its XML file configured in the GUI. You have completed the lab for modifying, exporting, and importing a security policy.11-18 Chapter 11 - User Roles, policy modification, and other deployments Examples of ASM Deployment Types ASM Standalone ASM standalone deployment is very useful when load balancing is not essential, cost may be an issue, and web application developers want to configure, manage, and secure their sites. ASM standalone devices do not have load balancing capabilities. These devices support only one member per pool. Because of the decreased functionality, the cost of a standalone device is less than an ASM module on LM. On many occasions, engineers have BIG-IP LTM implemented in their production environment. ‘The need arises for web application security, thus the need for ASM. With standalone devices, the web application security team has full configuration and management access to just their web applications. Multiple ASM devices behind a BIG-IP LTM Multiple ASM devices can be deployed behind a BIG-IP LTM. There are several reasons that organizations consider this methodology. The performance of the ASM module is sufficient for most environments; however some organizations may have performance requirements that the module can't meet. Deploying multiple, dedicated ASM devices behind a BIG-IP LTM delivers a higher performance level. Deploying dedicated ASM devices behind a BIG-IP LTM allows organizations to scale on demand. When another ASM device is needed, it can easily be added to the BIG-IP LTM pool By using BIG-IP LTM in front of the ASM devices, administrators can operate ASM in fail-open mode. AS long as at least one ASM device is still available, the BIG-IP LTM sends traffic there. In the unlikely event that all ASM devices are unavailable, the traffic is sent directly to the LTM pool members. ASM in-line with BIG-IP LTM ASM can be deployed in-line with BIG-IP LTM. In certain environments, there is a need to send web application traffic through BIG-IP LTM and have that traffic secured by a single BIG-IP ASM standalone system, With BIG-IP ASM in-line with BIG-IP LTM, load balancing can occur when LTM deploys multiple poo! ‘members (i.e. ASM Virtual Servers) in one pool. This configuration adds BIG-IP LM functionality such as load balancing, SSL termination, and SNATs along with web application protection through BIG-IP ‘ASM. ASM module on BIG-IP LTM ASM can be deployed as an add-on module on a redundant pair of BIG-IP L'TMs. By deploying ASM in this manner, organizations can leverage the existing features of BIG-IP LTM, such as load balancing, high availability, and synchronization, secure more than one web application server per pool, and keep all traffic management and security features in one device, ASM Virtual Edition (VE) ASM can be deployed in a VE, either as a standalone device or add-on module for BIG-IP LTM VE. ‘ASM VE delivers the same functionality as the physical edition and can be deployed in production and lab environments. Organizations can take advantage of BIG-IP ASM VE within their production environment by creating, testing, and maintaining their security policies during the development phase. Issues like false positives that require security policy adjustments can be addressed before deployment. 11-18 Configuring BIG-IP ASM v12Chapter 11 — User Roles, policy modification, and other deployments 11-19 ConfigSync and ASM Security Data When there is a redundant system configuration, itis essential that each ASM system synchronizes its ‘current configuration data with its peer unit. Ifan ASM system does not share its configuration data with its peer, the surviving unit can’t process traffic for that peer ASM system. For this reason, recommended to synchronize data initially and on an on-going basis. When the config syne process has been executed, a MySQL dump is performed placing all security policies and web applications databases in the .ucs file. This file is located in the /var/local directory. ASM security policies, and security policy history are synchronized using a MySQL online database replication process. Some parameters, such as traffic learning and requests, are not synchronized. The parameters stored in the /config/bigip_base.conf may be unique and are not synchronized Device Groups ‘A device group is two or more BIG-IP devices using the same configuration and providing consistent security policy enforcement. ‘You can set up application security synchronization, for example, behind an Application Delivery Controller where multiple BIG-IP systems running Application Security Manager are deployed as ‘members of a pool. The options and security policies on all of the systems stay in syne regardless of where you update them. This implementation comprises two phases: 1. Establishing a trust relationship, known as a device trust, between the ASM devices that you want to share security policies and configurations. The device trust initiates a line of communication between the ASM devices (in a trusted way by using digital certificates). 2. Adding the ASM devices that are members of the device trust to a device group, then enabling ‘ASM synchronization on the device group. The ASM-enabled device group is the collection of BIG-IP devices that trust each other and can synchronize their ASM configurations and security policies. ‘When you set up ASM synchronization, in addition to security policies, other settings, such as custom attack signatures, logging profiles, SMTP configuration, anti-virus protection, system variables, and policy templates, are synchronized with all devices in the ASM-enabled device group. ‘When using device management with ASM, you need to be aware of the following considerations that apply specifically to application security synchronization, ‘+ ABIG-IP system with ASM can be a member of only one ASM-enabled device group. * AILBIG-IP systems in a device group must be running the same version (including hot fix updates) of ASM (version 11.0 of later) «The BIG-IP systems in the ASM-enabled device group synchronize application security configuration data and security policies, providing consistent enforcement on all the devices. © Real Traffic Policy Builder can run on only one system per web application. For example, you can set up automatic security policy building on one system that is a member of an ASM-enabled device group, the policy is built on that system and then automatically updated on all of the systems in the device group. © [fusing a VIPRION platform (with multiple blades), itis considered one device, and you need to add only the master blade to the device trust and group. BIG-IP ASM v12 11-1911-20 Chapter 11 - User Roles, policy modification, and other deployments Synchronizing Multiple ASM systems You need to have already set up the BIG-IP systems you want to synchronize in a device trust and a device group. ASM must be provisioned on all the systems in the device group. ‘You can enable ASM synchronization on a device group to synchronize security policies and configurations on all devices in the device group. You do this task on one system; for example, the active system in an active/standby pair. I. On the Main tab, click Application Security>Synchrot device groups of which this device is a member. ion, The system displays a list of 2. For Device Group, select the device group whose members you want to synchronize. 3. Click Save. The BIG-IP ASM systems for which you want to share security policies and configurations are part of a device group with ASM synchronization, ASMQKVIEW: Provide to F5 Support for Troubleshooting ‘The qkview script automatically collects configuration and diagnostic information from a standalone BIG-IP ASM system. The information is gathered into a single file, which can then be provided to FS "Networks Support to aid in troubleshooting. F5 Networks Support requires qkview output in all cases where remote access to the product is not available. If BIG-IP ASM js running as a licensed module on a BIG-IP system, the asmgkview script can be run instead. ‘The following BIG-IP ASM related configuration files and log files will be collected and archived by the asmakview seript: © /var/logiasm* ivarilibimysql/*.err is/log/* *cfig under /ts MySQL dumps of DCC and PLC databases Running asmqkview (On ASM systems, you can run asmgkview from the command line. To run asmgkview, perform the following procedure: 1. Log in to the command line. Run asmgkview, by typing the following command: asmqkview 3. Collect the output file from the /var/tmp/ directory. The output file name is .qkview where is the hostname of the device on which you are running asmakview. 11-20 Configuring BIG-IP ASM v12Chapter 11 - User Roles, policy modification, and other deployments Command options To specify a maximum size limit for the asm_snapshot file, you can use the following syntax: asmgkview --size_limit= To include the request log in the asmkview command output, you can use the following syntax: asmqkview ~add-proxy-log Configuring BIG-IP ASM v1211-22 Chapter 11 - User Roles, policy modification, and other deployments Chapter Resources Solution Number Solution Title SOL14895 ‘Overview of BIG-IP ASM user role permissions SOL6824 ‘Overview of the asmakview script $01L75221274 ‘Automatically merging BIG-IP ASM security policies Manual Chapter BIG-IP System: User Account User roles ‘Administration 11-22 Configuring BIG-IP ASM v12