Security Considerations

From nuBuilderForte
Revision as of 14:31, 6 February 2021 by Apmuthu (talk | contribs) (→‎Open Source Application Preferences)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

nuBuilder Security

  • Personal logins
  • Permission roles
  • Restrict access to forms, reports, PHP functions
  • Users cannot run server-side scripts without permission
  • Users cannot modify SQL queries

Further security measures

Among others, the following are also supported natively (or through documented implementation procedures):

  • Restrict access to own records
  • Create Password Policies
  • Use 2FA
  • Implement IP restrictions
  • Log Login activities
  • Log other activities
  • Audit Table

Systems Security

To add another layer of security for nuBuilder Applications, ensure users connect by VPN which your systems personnel can take care of, leaving others to manage external threats.

Incidentally, MS Access is purely in a client - server mode (other than ASP/DOTNET/IIS) which generates a lot of LAN and ODBC traffic, VPN notwithstanding. nuBuilder replacements do not have to suffer such traffic issues.

General Open Source Software security considerations

The following is also true for nuBuilder.

WordPress example

  • WordPress is open source and free too and powers nearly 40% of all websites on the internet.
  • It has hundreds of thousands of theme and plugin combinations out there.
  • It is not surprising that vulnerabilities exist and are constantly being discovered.
  • However, WordPress usually gets a bad rap for being prone to security vulnerabilities and inherently not being a safe platform to use for a business.
  • More often than not this is due to the fact that users keep following industry-proven security worst-practices like:
    • Using outdated WordPress software,
      • nulled plugins,
      • poor system administration, credentials management, and
      • lack of necessary Web and security knowledge.
    • Enabling lots of properties, themes, plugins and making it easier to use for end users without IT background, creates among others, lots of
      • gaps,
      • bugs,
      • vulnerabilities,
      • breaches

Dependent Applications Issues

  • The Web server needs to be configured for security too.
  • It must be running on a limited user account.

Take these with a pinch of salt, especially, as latest is not generally the greatest across major versions and many cutting edge fixes themselves could have serious bugs and can potentially break installations:

  • Keep your "PHP up to date".
  • Fix security-related updates in the past several years.
  • The "system" as a whole needs to be continually updated.
  • If it's a Linux system (any OS for that matter), it's important to "keep everything up to date", but especially the "kernel".

If it ain't broke, don't fix it may apply in some circumstances only.

Open Source takeover by Commercial entities

Taking over trusted Open Source Applications (PHP, MySQL after certain versions) has its ramifications for the end user / sysadmin like:

  • forcing users into their "latest" versions
  • doctored benchmarks measuring a fish's ability to climb a tree
  • hiding / removing fixed versions available before control
  • forced update channel URLs to create a gradient to unknowingly follow "the path"
  • injection of "paid experts" to obfuscate with esoteric programming constructs
  • hijacking understandability for the self-taught programmer

Those in management quickly learn the adage - "If you can't beat them, join them and then scuttle them".

Webserver's exposure calibration

Security countermeasures include:

  • getting a valid SSL/TLS certificate,
  • configuring TLS to use only strong cipher suites, and
  • configuring php.ini for security

While there is a lot involved, the general mitigation principle is to

  • disable dangerous PHP functions.

Open Source Application Preferences

  • reliability
  • proven continued functionality
  • having a strong community