Top 3 reasons legacy applications are insecure

 
 

There is a vast number of legacy applications from CRM and HR to manufacturing, billing and timesheet systems; however with few exceptions they have several weaknesses in common. Here are 3 of the key problems:

The ‘trust environment’ has changed.

Most legacy applications were built before the ‘internet’ prompted connectivity from anywhere to anywhere and the architecture was designed for a client-server model accessible within a single organisation. This applies even for applications with a WEB-based front-end and in-house servers. This was a ‘full-trust environment’ – the requests made of the server were presumed to come from trusted sources – not from people who could be trying to hack the system. Since then the computing environment has changed to accommodate far greater connectivity. If the legacy application server is located outside of the organisation, or accessible via the WEB, then it is a different ball-game. The application should now securely verify every server request before executing it; yet most legacy systems do not do this and still operate as if the environment is trust worthy!

UI permissions and system permissions

Most systems had some sort of permission system built into the core modules. Obviously those that don’t are highly insecure, but for those that do they often went with both a UI and system permissions approach, they did not have the ability to create dynamic query based permissions.
Systems permission allowed you to set what permissions users/roles had to items / areas in the application. However, this required manually changing the permissions for each item whenever it was required, (a problem many are familiar with). To get around this most systems also included an easy ability to configure the UI, such as hiding panels/screens, locking fields, etc.
The problem with this UI method is it was applied by the client application – it does not represent the true permissions the user actually had to the data. The true permissions were still set by the system permissions. This meant most users had full access, but were prevented from doing/seeing things through the UI. This was fine when the application was local; however as with ‘trusted environments’ as soon as the application was placed on a WEB server accessible to multiple offices anyone can call that web server without using the installed application. Thus most of these systems are heavily susceptible to a simple attack by someone writing code to login to the WEB server and downloading or modifying data. Of course they still required a login (hopefully), but that user would normally have full access to everything as there would be no UI permissions in place to prevent them.

Data is held locally.

We are all familiar with hearing of security risks or data protection issues when laptops are mislaid or stolen. This is because legacy applications keep their data locally on the laptop – a problem Cloud based systems are simply not susceptible to, all the data is safe in the Cloud and not on the missing laptop.

WhiteSky Studio addresses these security concerns as it is a Cloud based platform built from the ground up with security in mind. All server calls in WhiteSky Studio (whether through the API or regular calls) are verified and logged. Within the application you can create full system permissions, and queries that dynamically define the permissions for users/groups – this removes the need for creating UI workarounds as there is no longer an administrative overhead associated with maintaining permissions.