SyncEXPERT

The image of the herald is one that pervades Western culture. The Biblical image of the archangel Gabriel announcing the forthcoming births of both John the Baptist and Jesus is one that Christians are very familiar with.

I’m not much of a herald. I’m hardly angelic, and I don’t own a horn much less own one. I think I would have made a great town crier, though. I’ve been told that my voice carries - over cube walls, through doors, down hallways, across vast expanses, etc. I’m reasonably sure that being told that I have a voice with such a unique gift for being heard above the din of an office setting is a compliment. Isn’t it?

All of this self-analysis brings me to the reason for my post today: my self-appointed role as town crier for news and announcements of interest to my loyal readers. To you, my faithful minions, I thrice toll my bell of harkening and lift my voice to loudly proclaim:

DataDirect to Support ADO.NET Entity Framework for Oracle Data Sources

Admittedly, this announcement is anti-climatic, for those of you who read this posting on the Microsoft blog last week, but it does bear repeating. There is a lot of interest right now among developers in the ease-of-use of LINQ and the productivity of the Entity Data Model. <marketing hat> Our announcement is meant to reaffirm that LINQ-based and Entity Data Model-based applications will experience the same unique benefits of using DataDirect’s Connect for ADO.NET providers for relational database access as ones built to use current technologies such as DAAB. </marketing hat> (Sorry for that segueway, but you know I’ve got to give a shout out to now and again in order to pay the bills ^_^)

While this is hardly earth-shattering news or something with the weightiness of, say, a royal proclamation, it is one that we’re proud to make because it’s a signal of where our products are headed…sort of like a graduation announcement. It’s enough to make a tough guy like me misty-eyed and emotional - it’s like I’m witnessing a precocious little tyke growing up right before my eyes! *sniffle*

That’s all for now. I’m off to hum a few bars to warm up for my daily auditory assault of my co-workers. Your comments and feedback are welcome so long as it doesn’t compete with the “11″ setting of volume knob of my strident self-important braying.

“Gee Mike, how can I become as wise about data connectivity as you?”

The above question is proof that although a question may be easy to ask, the answer may not be simple (nor the questioner sane in this case). My professional career started without even cursory knowledge of what a driver was, how relational databases worked, or even how to program in something more modern than FORTRAN (not dating myself as much as hinting that my college career was somewhat atypical for someone in my position). Since that time I have become “sufficiently proficient” in the subject of data connectivity to get myself into trouble, but not quite good enough to get myself out - sort of an anti-Macgyver in that regard.

Anyway, the purpose of this post is to share with you the secret of how I managed to acquire the thimbleful of lore that I have to date: listening to people smarter than myself. Thankfully for me, I haven’t had to look far for overqualified individuals at my place of employment - it’s like looking for a tall tree in a forest of redwoods. The great news is that these resident geniuses are actually more interested in going forth and helping others who grapple with the weighty questions involving data connectivity than they are in trying to give me the “Dick and Jane” version of every new concept that comes along.

You can meet these Superstars of Standards-Based Database Access APIs at DataDirect’s Architect Tutorials at one of the following dates and locations:

Thursday, October 4th | St. Louis, MO - Hilton Frontenac
Thursday, October 11th | Toronto, ON - Westin Harbour Castle
Tuesday, October 16th | Irvine, CA - Hyatt Regency

This year’s theme is, “Successful Strategies for SOA Enablement & Data Connectivity,” which sounds much more useful and technical than “See Spot Program ‘Hello World’ In FORTRAN”. If my personal recommendation amounts to anything - attend and don’t forget to bring a warm thinking cap.

I’ve been told that I should start this first post with a comment indicating that this is my first post. OK, that was fun - I’m glad that is over with.

I read an interesting editorial this morning on the issue of database encryption that got me thinking about the parable of the 6 Blind Men and the Elephant. In the editorial, the author discusses the possibility of using database-level encryption as a means of protecting sensitive data from a user who was not allowed to see it.

What got me thinking was the fact that the author, who has worked or is currently working as a DBA, takes an approach that I think overemphasizes the importance of database security features in addressing data security while not addressing other areas of greater risk. He can be forgiven for this view - from my experience, DBAs tend to be very smart but very narrow in focus. Of course a DBA would attempt to address problems from the perspective of the database - it’s what DBAs know and work with every day and it’s what they are most comfortable with. So in that way, DBAs are describing the “elephant” of data security using the knowledge that they have “in hand”.

While I won’t claim to be able to see the entire elephant, I do believe that there is much more to data security than simply configuring database security settings. Most people would agree that when managed well, relational database management systems offer an extremely secure environment for sensitive data. Through the use of features such as authentication, authorization, permissions (user-level and group-level) auditing, and more, it is very, very difficult to accomplish unauthorized access to database information. Unfortunately, there always comes as time when the information stored in the database must be processed or consumed by an application and that is when the risk to the data becomes greater.

In a typical configuration, a production database is running on its own server while the application accessing it is located across a network on a separate client or server platform. If database encryption is employed, the data that is sent to the application must first be decrypted before being sent to the application over the network. In an era where quality network packet sniffing tools are available to anyone with a a little know-how and an internet connection, there is always a possibility of someone capturing and logging the packet information. Despite this possibility, articles like the editorial mentioned above fail to emphasize the importance of securing critical data once it leaves the security of the database and passes over the network.

Most commercial database vendors now support some form of encryption of data over the network, typically through the use of SSL or some related data encryption protocol. In this scenario, before data is transmitted over the network via TCP/IP, it is encrypted. Once across the network and received, the packets are then decrypted and processed appropriately. If intercepted in transit by a packet sniffer, the data is gibberish and useless. When used in conjunction with database encryption, such network encryption makes the overall data environment much more secure and much less vulnerable to viewing by inappropriate audiences.

To be clear - there is more to data security than database encryption and network encryption. All of the security features employed within a production environment must work together and compliment each other - in contrast to the blind men in the parable who each believe his own narrow view of the elephant is correct. If you don’t consider all of the pieces of the application stack that handle your sensitive data - application, data connectivity, database, network, servers, etc. you could end up with a security infrastructure that protects your elephant’s tusks, but not it’s tail.