Missed your meeting deadline...but from what I've seen Connectwise doesn't want to work with 3rd parties unless the 3rd parties are willing to let them rent seek double-digit profits from their partners. 

I've moved my development efforts to MeshCentral and Tactical RMM which are much more open (on github) and willing to work with integrations. Screenconnect will probably one day leave my infrastructure entirely after 10+ years of use.

...so since the code is local for on-prem, and it's all asp.net and C# code...anyone delved into how to customize connectwise and disable blocking of the developer extension and adding your own extensions? #AskingForAFriend

Renaming/not using "administrator" (admin, root, user, owner etc) as the username has been best practices recommendations in the computer industry for decades. Microsoft windows domain setup guides are the first I was exposed to the practice in the late 90's. They even have a GPO for auto-renaming computer "administrator" accounts on first joining the domain. 

Using/having default usernames is bad. 

Developers carving exception out of security features to allow uninformed admins to do bad security is worse and not much better than hidden backdoor passwords/access. Hackers will find, and exploit them. 

Could Screenconnect have better onboarding/setup wizard to guide new installs on the path to better security? Yes. As we all know this is a product that has been around for long time now. I've already written up a different feature request about enhancing the "status" section so that best practice testing can be done at any time because in terms of hacker targets: Remote access/RMM system are priority one targets. Recent Solarwinds hacks show the best in the world hackers are on constant attack at those juicy targets.

Renald: Reviewing this: https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Security_guide

Goes over IP blocking. It doesn't have IP based fail2ban style greylist/autoban interface but does offer some options.

This is for locking user accounts (not IP's): https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Administration_page/Security_page/Internal_user_authentication/Edit_user_password_requirements_and_configurations

Which has MaxInvalidPasswordAttempts

It would be nice for smarter greylisting and blacklisting based on IP...but I'm not holding my breath on that.

Unfortunately this isn't a find-a-workaround situation. 

Legally speaking if you want to comply with HIPAA/FINRA/SOC/ISO compliance certification then:

If you want to use product x, it needs to do abc. If it doesn't, you can't use it. Audit trail with logs, held and maintained for 2+ years is part of that compliance.

If you use something not in compliance, your regulatory compliance is going fine you x dollars, hold you libel, and remove your compliance certification. No more business for you.

Priorities....and noone has reported them to Medicare or the SEC as non-compliant software due to no audit log. Were they also hacked like Solarwinds? Who knows...and you'll never know because there's no audit logs!

...4 year old thread about a glaring compliance hole in the product, and posts to workarounds that could have been integrated years ago...good thing we have https://www.connectwise.com/software/control/remote-support/security "World Class Security" on our side.

...an argument could be made that the lack of an audit log makes use of Connectwise Control in Healthcare (HIPAA regulated) and Financial Services (Sarbanes-Oxley regulated) illegal and in violation of their respective requirements of: Maintain and auditing access logs.

https://www.securitymetrics.com/blog/what-are-hipaa-compliant-system-logs

Event, audit, and access logging are required for HIPAA compliance. HIPAA requires you to keep logs for at least six years. These three HIPAA requirements apply to logging and log monitoring:

• § 164.308(a)(5)(ii)(C): Log-in monitoring (Addressable). [Implement procedures] for monitoring log-in attempts and reporting discrepancies.
• § 164.312(b): Audit controls (Required). Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.
• § 164.308(a)(1)(ii)(D): Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.

Still pending on this one? Maybe this should be moved up in the list now that you're enforcing 2FA and strongly encouraging use because of all the MSP targeted hacking going on of late. 

For both (powershell and cmd dialogs) 

Should have QuickEdit Mode enabled:

and set Screen Buffer Size Height (scrollback) to something big aka 9000