The application does not validate the case sensitivity for user-id on the login page, which may allow attackers to exploit this weakness using automated tools to initiate attacks. And the application has enabled copy and paste feature on the Password field of the Login pages of the application which allows an attacker to steal the password.

The application does not use any CAPTCHA or account lockout for entering the wrong login credential. This may allow an attacker to use an automated tool and to brute force the valid login credential of the application users.

The application transmits cleartext password from login page, forgot password page, change password page and compulsory change password page over HTTP. An
attacker over network may steal the login credentials of victim users leading to account compromise.

In VAPT observation it is raised, used tool:Burp Suite 

Is there any solution to overcome above raised issues. Is there any alternative solution for it. 

I'm answering with numbered answers relative to the queries raised above:

1. Unless someone knows something I don't, I'm not sure how to solve this one without contacting IBM.  I'm also saying this without trying to log into an appliance via SSH using, say, "ADMIN".  If that still works, then, IBM will have to solve it.  If it *does not* work, you can turn on "Restrict admin to serial" in the "Account Policy" tab of RBM Settings.
2. This can be controlled through RBM settings "Account Policy" tab.  I don't know if yours are disabled (using 0 (zero) as the "Max failed logins" value).  But, you can control this one.  You should ask yourself a couple of questions here.
   1. Is the vulnerability team testing against lab type machine you can recover if they screw up the "admin" account?
   2. If the appliance is physical and they are able to totally screw up credentials so you cannot get back in, are you prepared to unrack it and send it back to IBM for recovery?
3. I'd have to know more about this one.  I honestly have never even tried to setup appliance management interfaces without using secure transfer, so if that is possible, I'm not sure what the complaint is, providing I'm understanding it correctly.  Ask them to show you an unencrypted HTTP transfer of credentials, or, are they concerned an already compromised user machine is vulnerable.  IMHO and notwithstanding an otherwise valid concern, if the threat actor is already that far in, the problem lies elsewhere and you've got bigger problems than what you have direct control to resolve.