Basic sanity checks

This section describes how to perform basic sanity checks, which should be run after making changes to your environment, such as for clusters, distributed architectures, and upgrades.

These sanity checks also define standards for basic ASMS functionality, and enable you to verify that your environment is functioning as expected.

ASMS basic functionality

Basic functionality for ASMS is defined as follows:

Hardware or VM

Basic functionality on virtual machines deployed with ASMS, or on AlgoSec Hardware Appliances, includes all necessary processes running.

For details, see Test basic ASMS processes.
AFA

Basic AFA functionality includes:

  • Add and analyze devices completely and successfully
  • Identify device changes correctly
  • Send email alerts

For details, see Test basic AFA functionality.
FireFlow

Basic FireFlow functionality includes:

  • Both requestors and privileged users can successfully submit change requests
  • A single change request can move through all stages of the configured workflow
  • After changes are implemented on the device, the Validation and AutoMatching functions respond correctly

For details, see Test basic FireFlow functionality.
AppViz

Basic AppViz functionality includes:

  • New applications can be added
  • Flows can be added to applications, connectivity is accurately updated, and the relevant change requests are opened
  • Applications can be decommissioned

For details, see Test basic AppViz functionality.

Back to top

Test machine installation and configuration

This section describes how to test that your ASMS machines are installed and configured correctly. Do this after making changes to your configuration, deploying a new system, or upgrading.

Do the following:

Open a browser, and browse to IP address of your AlgoSec machine.

If the AlgoSec home page appears, your machine is connected and configured correctly. For example:

If this page or another like it does not appear, check to see that your basic configurations have been done correctly. For details, see Basic sanity checks.

Back to top

Test basic ASMS processes

This procedure describes how to test that basic ASMS processes are running on your machines.

Do the following:

  1. Connect to the Administration Interface. For details, see Connect to the Administration Interface.

  2. Enter 17 to verify service status.

    Output similar to the following should appear, confirming that all of these services are running:

    |======================================|

    | 147.172.44.40 |

    | |

    | (Thu Nov 28 13:45:10 IST 2019) |

    |--------------------------------------|

    | crond | OK |

    | httpd | OK |

    | postgresql | OK |

    | activemq | OK |

    | mongo Database | OK |

    | syslog-ng | OK |

    | apache-tomcat | OK |

    | AlgoSec microservices | OK |

    | metro | OK |

    | map diagnostics | OK |

    | Vulnerabilities | OK |

    | cloudlicensing | OK |

    | backup/restore | OK |

    | watchdog | OK |

    | device manager | OK |

    | trafficlogmanager | OK |

    | batch application | OK |

    | configuration | OK |

    | aff-boot | OK |

    | ABF | OK |

    |======================================|

Back to top

Test basic AFA functionality

This procedure describes how to test basic AFA functionality.

Do the following:

  1. Prepare for your test

    1. Define an email server.
    2. Define a user with permissions for all devices. Specify that the user receives email notifications for all reports and configuration / policy changes.

  2. Test device definition and analysis

    1. Define a new device and assign a user with permissions for it, or use an existing device to test AFA functionality.

    2. Run a manual analysis on the device.

    3. Verify that all sections of the new report have valid results.

      In the report, on the Policy Optimization tab, in the Rule Usage Statistics area, click All Rule Usage.

      Check the first text line to verify that the report is based on logs collected today.

  3. Test change monitoring

    1. Add a rule to the device's policy.
    2. Wait for the next monitoring cycle to run. By default, this runs every 20 minutes.
    3. View the device's Monitoring tab and verify that the change was detected.

  4. Test email alerts

    1. Check that the user you defined back in Prepare for your test receieved an email alert about the analysis completed in Test device definition and analysis.
    2. Check that the same user received an alert about the change you made to the device in Test change monitoring.

  5. Test the mapping topology

    1. Add more devices to AFA, and then run an analysis on ALL_FIREWALLS.
    2. Navigate to the ALL_FIREWALLS > MAP tab, and verify that the map generated successfully.

  6. Run a traffic simulation query and use the Topology Advisor.

    Save your results for comparison later. For details, see Run traffic simulation queries and Improve the map.

  7. Schedule recurring analysis.

    Schedule a device analysis job for the ALL_FIREWALLS group, and verify that it runs as configured.

    For details, see Schedule analysis.

Back to top

Test basic FireFlow functionality

This procedure describes how to test basic FireFlow functionality.

Do the following:

  1. Test change request submission

    Do the following as a Requestor user, and then again as a privileged user:

    1. Log in to FireFlow and submit a change request. If your organization uses a customized template or workflow, use the custom version.
    2. Verify that the change request was submitted successfully.

  2. Test workflow functionality and validation

    1. Locate one of the change requests you created in Test change request submission , and move it through the various stages of the workflow.

    2. Verify that the following stages produce valid results:

      • Initial Plan: Shows the relevant devices for the change request.
      • Risk Check: Shows a list of risks.
      • Work Order: Shows a valid suggestion to implemented the requested change.

    3. When you get to the Work Order stage in the change request, implement the change on the device.

    4. After the next monitoring cycle is complete, browse to the Validation stage of the workflow, and verify that accurate validation results are shown.

    5. In AFA, run an analysis on the device. Wait 2 hours, and then browse to the AutoMatching FireFlow stage, and verify that the change request and change are listed in the correct section.

Back to top

Test basic AppViz functionality

This procedure describes how to test basic AppViz functionality.

Do the following:

  1. Test new applications

    1. Create a new application, and add flows to it. Add at least one flow that is currently blocked by the organization's firewalls.
    2. Verify that the application is created successfully.

  2. Test connectivity and change requests

    1. Apply the application draft and check the application connectivity.
    2. Verify the connectivity for each flow, and that the connectivity of the entire application updates automatically.
    3. In the Change Requests tab, verify that a change request was created for the new flows.

  3. Test application decommissioning

    1. Decommission the application you created in Test new applications.
    2. Verify that the application's status changes to Decommissioned.
    3. Verify that the relevant change requests were opened to drop the application's traffic.

Note: If the application contains flows that are in use by other applications, change requests for this traffic will not be opened.

Back to top