Extracting Parameters Identified during Learning

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.