Forum Discussion

Don_22992's avatar
Don_22992
Icon for Nimbostratus rankNimbostratus
Jul 25, 2008

Extracting Parameters Identified during Learning

I've found while developing our policies, that ASM does a fantastic job in identifying parameters - but collobaration between the developers and the network staff is needed to create the policy...

 

 

Is there any way of exporting the parameter list to a text file, which can then be shared with the developers while developing the policy? A high level of information containing parameter name, parm flow/object, parm level and parm type would be sufficient for my needs. Anyone else?

 

 

In our situation, learning results in a policy that is too narrow/granular. For example, many object level parms can often be replaced by global parms. But then what happens is that one parameter, whose initial use did not result in a violation, ends up giving a false violation in the production environment.

 

 

If we had the list of parameters, those that should be global and those that should be defined on the object-level (etc...) could be identified and defined appropriately.

 

 

Right now, it appears to be a catch-as-catch-can process.

 

 

thanx,

 

Don
app sec
BIG-IP Access Policy Manager (APM)
security
  • Tom_Spector_50's avatar
    Tom_Spector_50
    Historic F5 Account
    Jul 29, 2008
    Hi Don,

     

     

    There is much to be said about collaborating between Developers (application) and IT (security) to create ‘Application Security’.

     

    Being able to integrate ASM into the SDLC is a wonderful thing – it makes developers aware of application security in general and allows the two groups (IT and DEV) to develop a communication channel regarding security.

     

    Currently, there is no supported way to get the information that you want (a flat file with a list of parameters detected by ASM) and I would encourage you to take this up with support so that it can be considered for future versions

     

    I would also suggest considering the following:

     

    When it comes to building any policy (security or other) there is typically no right or wrong but instead a general strive to define the relevant needs and deploy the tools that fulfill these needs. Having an extremely granular policy that has huge manageability costs can be totally fine if for example we are dealing with an application that hosts information that if breached can risk people’s lives (e.g. military, government, etc) and on the other side for sites with less critically the right choice may be a generalized policy with minor manageability overhead.

     

    Assuming you had the functionality you requested:

     

    - Can your developers use such a list? Will they be able to go over it and tell you which parameters are used where and how?

     

    - Is there a process where your developers document new parameters that are being added to the application and a change management process is implemented so that the policy is configured with that information prior to the application changing in production?

     

    - Is the manageability overhead worth the risk mitigation it provides?

     

     

    A good security policy is one that enables your business to function better and create more revenue by balancing availability, integrity and confidentiality which in ASM terms can translate to policy robustness and relevant security coverage.

     

     

    Thanks,

     

     

    Tom.
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Sep 01, 2008
    Hi DJ-Boston,

     

     

    There are existing requests to get a human readable flat file output of the policy for auditing and reporting. I don't have the CR number, but if you would like to support the request, you could open a case with F5 Support and ask them to attach your case to the change request.

     

     

    You can get some detail on the parameters in a rough format by running asmqkview from the command line. The output is a gzip compressed tar archive written to /var/tmp/. If you extract it and go to the tmp\asm_snapshot_temp_dir.XXXX directory, you will find the asm_mysql.dump file. This is the mysqldump of the ASM database. You could either parse this file to get the parameters, or you could load it in another MySQL database off of the BIG-IP. The relevant tables are:

     

     

    PL_GLOBAL_PARAMETERS

     

    PL_OBJECT_PARAMS

     

    PL_FLOW_PARAMS

     

    PL_PARAM_ATTRIBUTES

     

     

    To get the exact details for each parameter's configuration you'd need to join quite a few more tables. But hopefully this gives you a start.

     

     

    Aaron