This blog has moved

This blog is now located at http://dbsec.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://dbsec.blogspot.com/feeds/posts/default.

Compliance with regulations can have good results

A lot of people are only concerned with security because they have to be to comply with rules and regulations. Although I'm not a fan of the over-regulation that sometimes appears to permeate our lawsuit-happy society, I have seen some good effects of, for example, the Sarbanes-Oxley legislation. Due to the requirements of Sarbanes-Oxley, many superfluous IT projects are shelved and the ones deemed appropriate are spec'ed out much more meticulously on the front end -- as they should be.

To explain this another way, IT professionals have been howling about onerous project demands for years, e.g., constant tweaking of automated reports, lack of support during design phase, lack of user testing and sign-off, no attempt to define requirements. Going to a "release model" of software improvements was only done at one company I've consulted with and they had 30 people in the IT department. Smaller IT departments don't possess the clout to promote agendas to management, moreover IT professionals are often not the best evangelists for proper application design and implementation. Incredibly, it took two Washington politicians who probably know nothing about application software design to inadvertently help solve our problem by forcing us to follow documented procedures.

The implementation of formal data security policies should not be considered to be different than other IT projects or other security projects. Establishing application architecture security is just as important as the lock on the check safe or, as I've mentioned before, the lock on the President's or CEO's door. But in the past having the system "up and running" was the finish line at which we went back to replacing bad cables and resetting forgotten passwords. The reality of "up and running securely" should be considered the goal in today's security-conscious IT department. And then we can comply with whatever new mandated security regulations "they" come up with -- by default!

As I expected...

According to a colleague who has more experience with other major databases such as Oracle, Progress comes "out of the box" much less secure than these others. Rephrased, users and permissions must be added within an Oracle database -- Progress allows a "user-less" database to exist.

This has been a problem which can be fairly easily remedied as I've explained before. Adding one user is enough to invoke DB security. Why isn't this simple procedure always performed? Many people in IT departments accept the un-integrated security layer set up within Progress-based applications as good enough. Manuals for ERP packages and other enterprise systems should at least include a side-bar about setting up some non-application-related database security to restrict access to data outside the application.

I'll write it for them -- or for you, if you can use it for, say, HIPAA, SOX, etc.

Security "Bugs" reported by securitybugware.com

Here's a report on the $DLC variable security problem. The solution provided is to upgrade to version 9.1D05.

Same solution for this security problem, "Progress Database unchecked buffer in BINPATHX leads to overflow." Great site, thanks fellows.

Another strike against PC Netlink

Now isn't this lovely? I have run into problems already with PC Netlink from Sun due to the inflexibility of security and permissions options. It seems like you can only set up 1 user account with access to any given directory/folder. This means people are continuously "locking each other out." This is an administrative burden because the people (my "boss" and I) with the highest privileges are constantly being called to remedy the situation. Developing....

Secure everything!

Throwing a firewall between your precious database server and the outside world or the internet is a good first step. Unfortunately many firms literally never get beyond this. It would be like putting a lock on the front an back door, but not on the president's door, the controller's door or the company safe. This leaves database information unsafe and vulnerable to anyone with access to the "hallways" or your company's network, that is, vulnerable to the "inside job".

If I can "see" the start-up script, I can copy it somewhere, edit it and run it, find out what files I have access to and begin dumping them. There is a simple protection against this, but rarely have I seen it done because of the extra layer of administration involved.

Do it, do it, do it - you will not regret it one bit. My next entry will give you the steps.

Password complexity and compliance

To comply with HIPAA, Sarbanes-Oxley and other compliance authorities, some ERP packages, especially older ones, must be modified. A client of mine has had changes inserted in the code for "mf1a.p". This all appears after the statement: update global_userid passwd with frame welcome. They call procedures which track attempts and that supersedes the date logic which forces changes that are much stricter.

This is a really good idea and they use external program calls to encapsulate the logic and so as not to clutter the login screen code.

Compound measures, not redundant

The different steps taken in securing a database can be seen as sometimes compound, but they should not be redundant. Redundancy could be symbolized by two locks on the same door - what if they pry it open from the hinges? But how about one lock and reinforce the hinges, or one lock and an alarm? That would represent compound measures.

Recently someone asked me about adding an operating system group level for ownership of sensitive financial information at the R-code level. Obviously that's a good idea, but if you can keep them out of the editor of the database and you lock up the usr_mstr then this could represent a redundancy requiring extra resources. I almost think that it would be better to "trap" someone running a compiled procedure that they weren't supposed to. My favorite way would be via an email script embedded in every sensitive program, but that's just me. The -yx parameter can be used as well but it's useless in the event of ID spoofing.

Create Progress users from QAD file

Fortunately the same encoding is user in QAD and Progress passwords. So you can do the following after the QAD set up is complete.


for each usr_mstr no-lock:
  find _user no-lock where _user._userid = usr_userid no-error.
  if avail _user then next.
  create _user.assign
    _user._user-name = usr_name
    _user._userid = usr_userid
    _user._pass = usr_passwd.
end.

Then you'll still have to use the dictionary admin menu to assign security permissions, etc. All this would really do is prevent an "unknown" user from being able to compile programs which look at tables; it does nothing to secure the application programs. This would be suitable for small shops possibly, but the assumption would be that of no malevolence, usually not good. I believe a better tack would be to only set up developers in this table.

Single-user access depends on UNIX attributes

Connecting to a database in multi-user mode is independent of the ownership and permission mode of the database file(s). However if there is no server process running and an attempt is made to connect in single-user mode by a user who does not own the database file(s), the attempt to connect will fail unless the read/write permissions are open ("-rw-rw-rw-"). So use the command:

$ chmod 666 [dbname].??

before attempting a connect with -1.

Lock down the DBs

Three things you simply have to do even if you protect, move or remove all the powerful and dangerous programs.

1. Add at least one user. Use the dictionary program, then go to Admin/Security/Edit User List.
2. Choose one user who can change security (Admin/Security/Security Administrators).
3. Disallow blank userids. Go to (Admin/Security/Disallow Blank Userid Access...) - this will still allow entrance to the Procedure Editor to blanks, but will keep them from being able to compile any code which references the tables in the secured database.

Realize that doing all these things won't affect the functionality of a properly configured database client session providing all the application code is compiled. In other words, the "-p mf.p" of a QAD client script will keep the Progress DB security window from even appearing.

Lock users out of the Progress editor

In QAD, to prevent users from either executing the editor program (_edit.p) or escaping to the editor (F4 / P from main menu) there are 2 records which should be modified. Here's a program to help accomplish this:

for each mnd_det where (mnd_nbr = "" and mnd_sel = 1) or
  (mnd_nbr = "36.24" and mnd_sel = 3) with no-box:
  display mnd_nbr format "x(6)" mnd_select
    mnd_label format "x(18)".
  update mnd_canrun format "x(50)".
end.

Output will resemble this when complete:

Menu Sel Selection Label Access codes
------ --- ------------------ --------------------------------------
         1 Progress Editor    admin1,developer1,developer2
36.24    3 Program Execute    admin1,developer1,developer2

Move edit and dict programs

To eliminate the hacker threat mentioned earlier you can always use -rq in the startup script for Mfg/Pro. It would be really nice to run it with -rr, but it won't work out of the box. I'm not exactly sure why yet, however it's possible that it's hitting a source snag somewhere. The error message is different though...investigating...

The work-around I have at this stage is just putting the Editor and Data Dictionary programs out of arms reach. The programs to move out of their natural habitat (in UNIX, probably $DLC/tty/_edit.r and $DLC/tty/_dict.r) into a place that only your developers have access to, also renaming them. You could just change the mode on them, but make sure to get rid of read permissions as well; I'd make them 440 - period. I would advise creating a qad and a qaddev group - developers would be members of both groups, users would be members of qad only.

Master File Auditing limitations

OK, it's definite. The master file audit system in QAD does not track changes made outside the menus. So if I get into a Procedure Editor that can compile I can do something like this:

find ad_mstr where ad_addr = "C00100A2".
assign ad_city = "Pittsburgh" ad_state = "PA".

...and it will never show up in the master file audit system. Likewise:

find mnd_det where mnd_nbr = "36" and mnd_select = "3" no-lock
  no-error.
create usr_userid.
assign
  usr_userid = "me"
  usr_passwd = encode("me")
  usr_lang = "us"
  usr_groups = if avail mnd_det then mnd_canrun
               else "IS,IT,MANAGER".

...will allow me to get into the system as "me". But a really suave hacker would scan the usr_mstr table and decided who he wanted to spoof and write down the 16 letter encrypted usr_passwd. Then he'd change it, log in, do his dirty work and switch back afterward.

This is another reason to lock down the Procedure Editor.