Blog by Peter Lammersma
For today’s businesses, they say, data is more important than ever. I don’t agree with the ‘today’ part: data always has been businesses’ most important asset, and always will be. There is a difference between now and back then, though. The IT landscape is now extremely dynamic and reliant on innovative IT. Dependence on technology leads to enormous growth of data and, at the same time, of the number of attacks on the data.
Can a potential risk be turned into a business opportunity? During our second workshop / ‘pizza session’ of 2019 we answered that question. Before I explain how, we need to look at the cause of the growth of security problems. Although we all think security problems will never happen to us, investments in security were never higher than they are today. Return on security investment is one of the key figures that management uses to steer the business.
Client/Server
We feel safe with ‘good old’ client/server, with all the visible security measures: it’s like having a barrier to the carpark, a security guard near the entrance and a kind but resolute receptionist. Contracts and non-disclosure agreements must be signed, and sometimes employees must have a certificate of conduct. Before one can even start working with the application, passwords on computers and networks are mandatory. And, on top of all these safeguards, you and I have created the best authorization and authentication algorithms in the world!
Within this ‘fortress’, it feels as if the data is safe inside the organization walls. But it is not, despite all the visible and invisible security. According to ‘IBM 2016 Cyber Security Intelligence Index’ more than 60% (!) of all attacks on data have an internal cause. These are people you trusted! Did they break through all the security precautions? Are they spies? Criminals? The reality is less exciting, but just as frustrating. In most cases, the problem is just that the innocent users of the application opened an attachment that they should not have opened.
All the effort in securing the building, the network infrastructure, the workstation, the database, and the application has lost its value because of one detail: the connection to the data(base). Once you know how to get to the data, there’s not much that can stop you. Compare it with a defensive wall that loses its value with every hole. The connection from the client to the database looks like a tunnel. A long tunnel, perhaps, but at the end you see the data as shining gold.
It doesn’t matter what technology is being used on the client. Every technology has its ‘holes’. Criminals are not interested in any of the secure parts, but in that one single thing that is not: SQL injections, readable connection strings in assignment files, data source names from your ODBC or SQLNet. Allowing direct access to the data is a risk. Somewhere in the application, a connection string to the database must be available. As soon as this connection string can be found on the computer, all other security has lost its value.
Even the size of the application is irrelevant. Let’s assume you have a web application with hundreds of DSPs. From a user’s perspective there is no direct connection to the database. But what if this application also has one or two forms for maintaining a table? Then this can be the rabbit hole leading to your data. As we learned in the pizza session, prevention is better than cure, so let’s see what can be done to plug this rabbit hole.
Multi-layer versus multi-tier
It’s not client/server, per se, that causes the problems. It’s the way it is used. Traditionally, client/server is two-tier: the client for presentation and the server to store the data. But an application is more than just presentation and data. The real value is in the business rules and the business logic. By the way, those are not the same! I have seen a lot of applications that claim to be multi-tier (multi > 2 😊), but they are multi-tier in name only. They are really only multi-layer.
So what’s the difference between multi-layer and multi-tier?” Multilayer is separation in the application’s logic. Services for reading data, services for business rules, reports, forms, etc., are layers. Using multiple layers in the application structure is a very good habit, but it does not do anything for security.
Multi-tier, on the other hand, is a technical separation. It allows the application to run its processes on several machines: the presentation layer on the client, the business logic on an application server, and the business rules on the database server.
The fun part is that Uniface allows us to move layers into tiers – without changing our coding! At least, you can if you’ve used the layers consistently. In the pizza session we worked on this concept.
Moving data access to a server
The starting point of the pizza session was a typical client/server application: all the processing on the client and all the data on a server. Take a look at Figure 1: you’ll see a Uniface application on the client with two form components and one service. Reading and writing is done in the components.
In the worst case, the assignment file has one of the following path settings:
· $DATA_DBMS_MQL = MQL:server:database|username|password
· $DATA_DBMS_TLS = TLS:server+port|username|password|database
· $DATA_DBMS_MSS = MSS:DataSource:database|username|password
· $DATA_DBMS_ORA = ORA:t:host:database|username|password
You might have secured everything, but the connection string to the data is readable in the assignment file. This means your data is as open as it can be! The technology that is used to connect to the data is not relevant, nor is the security of the connection, application or network.
A setup like this is only fine for development purposes – with fake data.
In my Uniface career I have seen hundreds of applications, and a lot of them had the database details in assignment files on the client, even in production environments. Having the connection string data in a readable format in the assignment file makes it pretty obvious. Using the Uniface PathScrambler makes the connection strings unreadable. That feels a bit safer. But remember that somewhere in the process, the connection string must be unscrambled. That information is stored in memory and so it can be found with the right tools.
It’s a good habit to use a service for reading and writing to the database. In the pizza session, we changed the application in Figure 1 to something like Figure 2.
The normal behavior of the Uniface read process is, as we all know, activating the retrieve trigger. Uniface then invokes the read trigger to read and fetch the data from the database. To change this so a service can be used to read the data, an operation on a service must be called. On the form for the entity, the ‘Data access’ property is set to ‘non-database’.
Advice: create subtypes for all modeled entities. Have one subtype that allows database access and another subtype that is non-database. The first can be used on a service that does the reading and writing. The other can be used on the client to display the data.
At this point, two things are achieved:
1. The application uses a service to read and write. Officially, the application has a Service Oriented Architecture.
2. The application is multi-layer.
So, we’ve scored points! However, from a security perspective nothing has changed. As shown in Figure 2, there is still a direct connection from the client to the database.
But now take a look at Figure 3. The only thing that’s changed is the execution of the service. For a Uniface developer, this is just a small step:
1. In the assignment file on the client:
a. All connections to the database can and must be removed;
b. Replace them with a path to the server:
$TCP_EXEC = TCP:servername+port|username|password|pizza_2_exec
c. Add:
[SERVICES_EXEC]
* = $TCP_EXEC:*
2. Install URouter on the server. In the URouter’s assignment file:
pizza_2_exec = userver -asn=pizza.asn -dir=path -adm=path
3. In the assignment file (in this example pizza.asn), add the connection string to the data.
Now, when the service is activated from the form, the processing is executed on the server – without any modification to the application! Suddenly the application is multi-tier.
Why is this more secure? From now on, when someone tries to look into the metaphorical tunnel between client and server, there is no shining gold data but just a Uniface UServer-process. There is no direct access to the database. It is impossible to send SQL requests to the database on the server, because there is no direct access to the database.
From here on, it is up to developers like you and me. The only way to access the data on the server is by requesting data or submitting a change to a Uniface service. With our development skills, we can secure this data: it’s just a matter of authentication and authorization.
But there is more!
In the pizza session, we played with the configuration. The data is safely hidden behind a service. The only possible way to read the data is by calling the service from the Uniface form components. But what if you want to be able to read the data with other tools?
It’s highly advisable to implement all your business rules in services and execute these on a server. So, now you have your data and the business rules on the server. Let’s suppose that, although you’re happy with your Uniface desktop application, you also want to be able to make the data available to an external system, or you want your data to be part of a mobile solution.
As soon as you have your most valuable assets (business rules and data) executing on the server, you can access them with any technology you want.
Look at Figure 4. By adding a webservice to the configuration, all of a sudden, the Uniface service can be used by and/or in any other technology!
Conclusion
In just a few steps, a potential risk can be turned into a huge business opportunity.
When you started reading this article, your data felt secured but in reality it wasn’t. With a few changes in the Uniface configuration your data is very secured. And, at the same time, you created a new business perspective because the data can be made available to third parties in a way that you can control.
To summarize, the steps are:
- Stop reading and writing in the presentation layer
- Implement services that do all the reading and writing
- Move the execution of these services to the server
- Add webservice functionality to the services
If you want advice about the level of security of you application or need any help with the configuration of your deployment environment, you can always contact me. In the next BLOG / pizza sessions, we will take a closer look at the fourth step and beyond. Trust me, with Uniface you can do anything.