Archive

Posts Tagged ‘Compliance’

Improving U2 Security

April 11, 2010 3 comments

The general IT knowledge of security has come along way in the last 20 years. Even more dramatically when considering the last 10 years.

People are generally aware that unless due care is taken, their computer could be injected with a virus, have personal information stolen from it or even be used to facilitate crime. Major OS Vendors have picked up their game and now are putting in a better attempt to prevent compromises from the OS level. Sure, you still hear the odd story about the latest privilege escalation, but compared to what it use to be…

Network level security has been given most of the attention (and IT budget funding) and is *generally* fairly secure these days. Application level is where most of the major hacks are happening now, but unfortunately, corporate uptake on securing their systems at the Application level hasn’t been as good as it was with the Networks.

Let’s be honesty and not undersell ourselves, securing complex applications is no mean feat. It takes knowledge, planning, lots of time & patience and sometimes out-of-the-box thinking. Thankfully, most modern programming languages and Database Management Systems do the heavy lifting for us. From the security features built into C# and Java to the vastly improved safety net found in SQL engines with fine-grained access control and in-built functions for preventing SQL injection, a lot of the basics have been solved.

This is where the U2 family has a few gaps to be filled. UniBasic needs some inbuilt functions for sanitisation, UniObjects needs some form of access control built around it and UniQuery/RetrieVe prepared statements/stored procedures would be nice.

With the increase push in integrating U2 servers as databases for modern front-ends such as web applications, data sanitisation is going to become a prevalent topic in the community. Built-in functions for UniQuery/RetrieVe, SQL and HTML sanitisation/encoding would be welcome additions to the UniBasic command family. Even better would be some form of prepared statements for the query languages. This make it simpler and easier to obtain better program security.

UniObjects is touted as a standard method of connecting GUI application front-ends to a U2 back-end. However, due to the limited access control supported by UniObjects, it is a dangerous hole in your system to have the required port open for anything other than back-end servers. Take into considering user ‘X’. User ‘X’ has appropriate login credentials for the old green screen system. IT brings out a new Windows GUI application, lets say for reporting, that runs on the user’s machine and uses UniObjects to connect to U2. In the old green screen system, User ‘X’ was limited to set menus and programs to run and could not get access to ECL/TCL. With enough knowledge (and malice), User ‘X’ can now freely use his green screen login credentials to log into the U2 system via UniObjects read/write records directly and even execute raw ECL/TCL commands.

So what exactly is the problem with UniObjects? Quite simply put, it has no fine-grained server-side control of what actions can be done, or commands issued via UniObjects. As long as you can log in, you can get a free pass to the back-end’s data. Let’s take MsSQL as a counter example. You can create views, stored procedures, grant or deny users a suite of privileges to tables and commands. Essentially, UniData needs to be able to have some access control scheme for UniQuery that allow you to define whether the users and read/write records in certain files. Ideally, all read/writes would be done through U2 UniBasic subroutines, with RPC daemon having the ability to have a command ‘white-list’ setup. That way, all data access can be moderated with UniBasic code and the RPC daemon having a white-list that only allows access to calling those subroutines.

All this highlights an issue we need to overcome as a community. The lack of U2 specific security literature. Where is the UniData/UniVerse security manual? Where is the “Top 10 common security mistakes” for U2? Sadly, security does seem to be an afterthought. Sometimes even a ‘neverthought’.

Advertisements

Security is not Obscurity. Even in U2 [Part 2]

January 22, 2010 Leave a comment

I hope everyone had a relaxing and enjoyable holiday season!

I also hope everyone is considering what information they log. Is it too little for when things go wrong? Is it too much and compromising your security?

Lets start with too little.

Say you have a system that services requests from an external system. Maybe it does login requests as well. Now, you need to explain something that has changed in your data. Do you have log files with enough information to look back on and determine when the change happened and who made the change? Do you have logs at all?

Without appropriate logs, you leave yourself vulnerable to unexplainable and unaccountable changes. Effective logging not only gives you diagnostic capabilities for when mistakes happen (user OR developer), but can also act as a deterrent for would-be malicious parties.

On the flip side, it is possible for too much information to be logged.

Aside from the administration headache causes by excessive amounts of data, it is possible that you are recording normally secure information in unsecured log files.

Typically, log files have security practices that are much more lax than the most secure data on your system. Log files are more likely to be found on developers machines, in print-outs and generally unencrypted.

With that in mind, you must make sure that sensitive information is effectively censored from logs. This means information such as passwords, credit card details and clients personal information. This should be done in the program that creates the data to be logged, as it should know which sections should be censored. If this isn’t possible, the log files should be censored by another program before being accessible by anyone else.

Think of any programs you have that do custom logging or create printer spools. Don’t forgot to check log files that you can get UD/UV to automatically create for you such as COMO logs, Protocol logging and system logs. Also important to consider is the logging done by applications that talk to your U2 system.

Remember

When considering security of Data in Motion and Data at Rest, it is highly likely that it is at rest in more places than just your database. Sure, may have your U2 system locked up tight, but if the information unscrupulous parties are after can be accessed elsewhere, you can bet they will just get it from the easier target.

Categories: Security Tags: ,
%d bloggers like this: