Early availability features

This topic describes features available as Early Availability (EA) and how to enable ASMS's Early Availability features.

ASMS's Early Availability features enable you to access new functionality and support earlier than general availability. Customers partaking of Early Availability often provide invaluable feedback on the design and implementation of these features. Early Availability features have shorter QA cycles than GA features, and therefore are disabled by default.

Warning: We recommend that you do not use Early Availability features in production. They should be enabled only in testing systems, and disabled in production systems.

Arista devices in ASMS

This section describes the ASMS Early Availability support for Arista devices:

Supported features in Early Availability

ASMS supports Arista EOS devices as follows:

  • Geographic Distribution Remote Agent to manage Arista EOS devices

  • VRFs separation

  • Rules visibility

  • Report Generation

  • Topology

  • Change History

  • Risks Calculation

  • Map Visibility

  • Regulatory Compliance

  • Traffic Simulation Query

  • Monitor Cycle

The following functionality is not supported:

  • Integration with FireFlow

  • Changed by (Audit Logs collection)

  • IPT and unused rules (Traffic Logs collection)

Network connectivity

The following image shows an ASMS Central Manager or Remote Agent connected to an Arista device over HTTPS-REST.

Device permissions

To analyze Arista devices, ASMS connects to Arista EOS devices using the REST-based API, ensuring high performance and efficient data collection.

ASMS requires a user with Read permissions, and a HTTPS connection over port 443.

The user must also have permissions to run the following commands via API Explorer:

  • enable
  • show version
  • show interfaces
  • show ip interface
  • show ip route vrf ( all | <vrf-name> )
  • show ip access lists
  • show ip access-lists summary

  • show vrrp vrf all all

If the REST eAPI is not yet enabled, run the following using the Arista CLI:

Arista(config)#management api http-commands

Arista(config-mgmt-api-http-cmds)#no shut

Enable / Disable early availability support for Arista

This procedure describes how to enable or disable support for Arista devices in ASMS.

Do the following:

  1. In AFA, click your username, and select Administration > Advanced Configuration.

  2. Click Add to add a new configuration parameter.

  3. Define the parameter value as follows:

    Name ALGOSEC_EA_ARISTA
    Value

    One of the following:

    • yes = Enable Arista device support
    • no = Disable Arista device support

For more details, see Advanced Configuration. Continue with Add an Arista device to AFA.

Add an Arista device to AFA

This procedure describes how to add an Arista EOS device to AFA.

  1. Access the Devices Setup page. For details, see Access the DEVICES SETUP page

  2. In the vendor device selection page, click Arista > Arista EOS.

  3. Complete the following fields:

    Host

    Enter the host name of the Arista device.

    This is the name that will be displayed in the devices tree.
    User Name Enter the username to use when accessing the device.
    Password Enter the password to use when accessing the device.
    Enable Password Enter the enable password to use when accessing the device.

    Note: In the Geographic Distribution area, you must select Central Manager.

    Arista devices cannot be managed by Remote Agents.

  4. Click Next, and then select the managed devices you want to add to AFA.

  5. Select the following as needed:

    Real-time change monitoring

    Select this option to enable real-time alerting upon configuration changes. For details, see Configure real-time monitoring.

    Set user permissions

    Select this option to set user permissions for this device.
  6. Click Finish. The new device is added to the device tree.

  7. If you selected Set user permissions, the Edit users dialog box appears.

    In the list of users displayed, select one or more users to provide access to reports for this account.

    To select multiple users, press the CTRL button while selecting.

    Click OK to close the dialog.

    8. A success message appears to confirm that the device is added.

Enable ActiveChange for MSO-managed Cisco ACI tenants

ActiveChange for Cisco ACI tenants managed by a Cisco MSO (Multi-Site Orchestrator) is available as an early availability feature.

Note: By default, ActiveChange is supported for tenants managed by an APIC.

With this early availability feature enabled, you can add, modify and remove rules from the policy directly from FireFlow.

When Cisco ACI tenants are managed by an MSO, each APIC in turn can manage one or more tenants. Each tenant contains one schema, with one or more associated templates. Schemas and templates are configured in FireFlow in order to implement ActiveChange on the device.

To enable/disable early availability ActiveChange for MSO-managed Cisco ACI in AFA

  1. In the AFA Administration area, navigate to the Options > Advanced Configuration tab.

  2. Click ADD to add a new configuration parameter, and enter the following details

    Name AlgoSec_EA_MSO_ActiveChange
    Value

    Enter one of the following:

    • true = Enable MSO-managed Cisco ACI tenants ActiveChange support
    • false (default) = Disable MSO-managed Cisco ACI tenants ActiveChange support

  3. Click OK

Note: After switching EA/GA mode, we recommend you restart your system.

Configure ActiveChange behavior for MSO-managed Cisco ACI tenants in FireFlow

In ACI MSO, there is no default value for the schema and template. In order to implement ActiveChange for the MSO-managed Cisco ACI tenants, user-defined schema and templates are required for each tenant.

Configuration Parameter Name Value
CiscoMsoActiveChangePolicyTargets

Defines policy targets (schema and templates) for each tenant.

Format: 

{ <Apic ID/Name> : {<tenant Name> : 
{ "schema":<Schema name>, "templates":[<template1>,<template2>...]}
}}

Limitation: In this Early Availability version, if you define more than one template for a schema, ActiveChange selects only the first template in the list (defined in the FireFlow parameter CiscoACIMSOActiveChangePolicyTargets, see below).

For example, Schema Payroll has templates Detroit, Baltimore and Abu Dhabi. Since changes are applied to the MSO and deployed on the first template defined in the schema, ActiveChange only selects Detroit.

Changes will be made only on the Filters and Contracts that are defined in the template that is configured in FireFlow.
CiscoMsoActiverChangeCommit

By default, FireFlow will apply changes on the MSO and deploy the changes to the relevant MSO-managed Cisco ACI APICs. If required, you can change this so changes will be applied only to the MSO and you can manually commit the changes to the APICs later.

The value assigned to this parameter determines whether or not ActiveChange deploys changes to APICs.

The possible values are:

  • deploy (default): Changes are applied on MSO and deployed to APICs.

  • commit: Changes are only applied on MSO .

To configure ActiveChange behavior for MSO-managed Cisco ACI tenants:

  1. Switch to FireFlow.

  2. Click the Advanced Configuration tab.

    The Advanced Configuration page is displayed.

  3. In FireFlow Configuration, Click ActiveChange and filter for CiscoACIMSOActiveChangePolicyTargets or just scroll to find it.

  4. Click on the edit icon next to the current value field. Define the schema and templates for one tenant.

    For example:

    Copy 
    {
      "10_20_30_40": {
        "10_20_30_40_ActiveChangeEA": {
          "schema": "Payroll",
          "templates": [
            "Detroit",
            "Baltimore",
            "Abu Dhabi"
          ]
        }
      }
    }
  5. Click Update below the current value field to update the value.

  6. Filter for CiscoMsoActiverChangeCommit or just scroll to find it.

    Assign a value to this parameter to determine whether or not ActiveChange deploys changes to APICs.

  7. Click Update below the current value field to update the value.

  8. Click Store Changes at the top of the page.
  9. Restart FireFlow.

Support for NSX-T deployed on AWS (VMC)

This section describes the ASMS Early Availability support for NSX-T deployed on AWS (VMC).

Important: We recommend that you enable this Early Availability feature only in a lab environment.

Supported Features

ASMS supports NSX-T deployed in AWS (VMC) as follows:

  • VRFs separation

  • Rules visibility

  • Report Generation

  • Topology

  • Change History

  • Risks Calculation

  • Map Visibility

  • Regulatory Compliance

  • Traffic Simulation Query

  • Monitor Cycle

Unsupported Functionality

The following functionality is not supported:

  • ActiveChange

  • L2 Rules

  • Changed by (Audit Logs collection)

  • Traffic-related recommendations

  • IPT and unused rules (Traffic Logs collection)

  • IPV6 rules and NSGroups with IPV6 content

Limitations

NSX-T on AWS has the same limitations as NSX-T on-premise, e. g.:​​

  • NSX-T is shown only in TSQ result mini map​

  • ASMS supports only Distributed Firewall (for East-West traffic)

Network connectivity

VMware Cloud on AWS uses NSX-T to create and manage internal SDDC networks and provide endpoints for VPN connections from your on-premises network infrastructure.

Device permissions

ASMS requires minimal, read-only access permissions to access VMware NSX-T data centers and perform data collection.

The user accessing the VMware NSX-T Data Center for analysis and monitoring must have one of the following NSX-T roles:

  • EA - Enterprise Administrator
  • A - Auditor
  • Custom role/permissions (use R flag for all features/components)

Note: If you are using the NSX Manager, we recommend using the built-in NSX Manager user to connect from ASMS.

Enable / Disable early availability support for NSX-T deployed in AWS

This procedure describes how to enable or disable support for NSX-T deployed in AWS in ASMS.

Do the following:

  1. In AFA, click your username, and select Administration > Advanced Configuration.

  2. Click Add to add a new configuration parameter.

  3. Define the parameter value as follows:

    Name AlgoSec_EA_NSXT_Cloud
    Value

    One of the following:

    • yes = Enable NSX-T deployed in AWS device support
    • no = Disable NSX-T deployed in AWS device support

For more details, see Advanced Configuration. Continue with Add a VMware NSX-T to AFA.

Add a VMware NSX-T to AFA

This procedure describes how to add a VMware NSX-T that is hosted on AWS (VMC) to AFA.

Do the following:

  1. From the Administration area, access the Devices Setup page. For details, see Access the DEVICES SETUP page

  2. Click New > Devices > VMware > NSX-T. In the vendor device selection page, click VMware > NSX-T.

  3. For NSX-T that is hosted on AWS (VMC), select In Cloud.

  4. Complete the fields as needed.

    Access Information NSX-T that is hosted on AWS (VMC)

    Device name

    Give the device a name. This is the name that will be displayed in the devices tree.

    Tip: To avoid future confusion, we recommend you use the SDDC name for the device name.
    Organization ID Organization ID (from VMware Cloud interface)
    SDDC ID Software-Defined Data Center (SDDC) ID number (from VMware Cloud interface). Each SDDC needs to be added separately.
    API Token API token. Generate a token from your VMware Cloud services account. Specify the roles required for on-boarding:

    Select the remote agent that should perform data collection for the device.

    To specify that the device is managed locally, select Central Manager.

    This field is relevant when a Geographic Distribution architecture is configured. For more details, see Configure a distributed architecture.

    Select the Learning mode option to specify that AFA traffic simulation should treat traffic that is not specified in a rule as blocked.

    In reality, the default behavior for NSX-T devices is to allow all traffic that is not explicitly blocked. Learning mode enables you to better understand the specific traffic that needs to be allowed on the device.

    Note: Learning mode is supported for NSX-T versions 3.0 and above.

    Specify how AFA should acquire the device's routing information:

    • Automatic. AFA will automatically generate the device's routing information upon analysis or monitoring.
    • Static Routing Table (URT). AFA will take the device's routing information from a static file you provide. For details, see Specify routing data manually.

    Real-time change monitoring

    Select this option to enable real-time change monitoring.

    For details, see Configure real-time monitoring.

    Set user permissions

    Select this option to set user permissions for this device.

    Learning mode

    You can select the Learning mode option to specify that AFA traffic simulation should treat traffic that is not specified in a rule as blocked. By default, DBWs allow all traffic that is not explicitly blocked. Learning mode enables you to better understand the specific traffic that needs to be allowed on the device.

    Note: Learning mode is not supported for NSX-T versions below 3.0.

  5. Click Finish. The new device is added to the device tree.

  6. If you selected Set user permissions, the Edit users dialog box appears.

    In the list of users displayed, select one or more users to provide access to reports for this account.

    To select multiple users, press the CTRL button while selecting.

    Click OK to close the dialog.

    7. A success message appears to confirm that the device is added.

Palo Alto Networks Prisma Access devices in ASMS

Note: AlgoSec supports only Panorama Managed Prisma Access.

This section describes the ASMS Early Availability support for Palo Alto Networks Prisma Access devices:

Supported features in Early Availability

ASMS supports Prisma Access devices as follows:

  • Policy visibility

  • Risk analysis

  • Traffic Simulation Query

  • Remote Networks and Service Connections

The following functionality is not supported:

  • Changes

  • Policy optimization recommendations based on traffic like Intelligent Policy Tuner (IPT) and unused rules

  • FireFlow support

Network connectivity

The connection to Prisma Access is done via the Panorama device that manages it:

Device permissions

Use same permissions required for Palo Alto Panorama devices. See Panorama device permissions.

Prisma Access visibility in the device tree

Prisma Access is added under the existing Panorama tree as follows:

  1. Level 1 Panorama Host (IP/Name )

  2. Level 2 Cloud_Services (Prisma Access) managed by single Panorama devices

  1. Level 3 Cloud_Services_Remote_Networks / Cloud_Services_Service_Connections

  1. Level 4 Cloud_Services_Remote_Networks_<Remote_Network_Name> / Cloud_Services_Service_Connections_<Remote_Network_Name>

Enable / Disable early availability support for Prisma Access

By default Prisma Access is disabled. This procedure describes how to enable support for Prisma Access devices in ASMS.

Do the following:

  1. In AFA, click your username, and select Administration > Advanced Configuration.

  2. Click Add to add a new configuration parameter. For more details, see Advanced Configuration.

  3. Define the parameter value as follows:

    Name AlgoSec_EA_Panorama_Prisma_Support
    Value

    One of the following:

    • yes = Enable Prisma Access device support
    • no = Disable Prisma Access device support

  1. Logout from ASMS and then login again.

  2. If you already have Panorama device(s) that manage Prisma Access onboarded to ASMS, run Edit-Next (Edit device wizard) on this/these Panorama(s). If you do not have Panorama device(s) that manage Prisma Access onboarded, onboard them. See Add Palo Alto Networks devices.

  3. Continue with Configure a Panorama device that manages a Prisma Access .

  1. Continue with Configure a Panorama device that manages a Prisma Access .

Configure a Panorama device that manages a Prisma Access

This procedure describes how to configure Panorama device that manages a Prisma Access in AFA.

Do the following:

  1. Access the Devices Setup page. For details, see Access the DEVICES SETUP page

  2. In the device tree, select the Panorama device to configure for Prisma Access. Click Edit.

  3. Click Next. You should be on the Panorama 2/2 page.

    Prisma Access Tenants are shown with the prefix Cloud Services.

  4. Select the check boxes of the tenants you want AFA to control.

    Note: Log collection Method drop downs are disabled for Prisma Access tenants.

  5. Click Finish. The tree of the Panorama is updated to include Prisma Access elements.