I had my first lessons in security from two major
sources.
First, my father. J
Stanley Aughenbaugh II was a mainframe Systems Programmer long before IBM even
admitted to having such a title in their company. He showed me a lot of interesting things as
a child. I had my first computer when I
was eight and by the age of ten I had managed to figure out how to log into IBM
systems from the house phone. Dad was
not pleased. Shortly thereafter a lock
appeared on the power switch for the computer and I could only use it with his
permission. I soon figured out that a screwdriver
was a handy tool to own. That and a
watch so I would know when to expect him to be home from work.
The Second source of Security came from a locksmith I had
spent a couple (hundred) hours apprenticing to while I was in my second tour
with the US Navy. This was fun stuff, he
taught me all about locks, how their design made them strong and weak. I learned how to pick a lock for the security
that was required, but also how to pick the lock when security had to be
broken, mostly when the key was lost.
My first lessons in security are these:
1 1. Never assume that a system is so secure that a
child can break into it by simply hitting a few buttons
2 2. A lock serves exactly two purposes:
a.
To keep an honest man honest. (dishonest ones
will eventually find a way to break the lock, or the door, to get what they’re
after)
b.
To delay the dishonest men, so that the attempt
can be thwarted or at least detected.
Why bring this up now?
Because I have been having some fun with these concepts lately. We have a lot of experts and a lot of
technology that can be used for security of our systems and data already, yet,
we still see stories of classified leaks and whatnot.
When I look at the stories of Edward Snowden and others that
have leaked this info to the press I have mixed emotions. But the one thing I have always known is that
these were privileged users and had decided to use their access for a purpose
it was not intended for.
Companies and governments have privileged information some
may be important enough to hide from many eyes but I often wonder if the
systems and databases involved have any controls on when certain information is
read not just controlling the access to it.
Enter the fun techno toys that I have been playing
with.
When Oracle published the 11g version of the database they
included an interesting capability that, til now, has gotten little recognition
and less respect from our industry. I
only recently came across it and instantly the ten year old with a screwdriver and
the 20-something with lock picks saw differently from the rest.
Virtual Columns
This feature allow you to place an empty column on a table
with the ability to reference any non-virtual column of the record and apply
some basic functions to them. They have some
specific restrictions on how the table is built but they can be altered
thereafter to allow you to apply a user-defined function that is the center-point
of a potential security feature. Besides
the ability to return a simple value to say whether or not a user is privileged
enough to see that data. (many of us
have done this in views in the past) the stored function can also be used to
record when certain records have been read and by whom.
What this method gives us is the ability to place this
function one level lower, not just in a view.
Remembering that a lock will only keep an Honest man honest,
it will not prevent someone with direct table read access from viewing the
record but it can still provide the “detection” element of security. What happens if that user can replace the security
function? Well if that user is less than aa DBA for that system, even then, you may have bigger
security problems than most at this point.
This idea and method is not a standalone measure but one more tool that
could be leveraged to enhance security of our apps and data.
I have some examples I am cleaning up of just such a
method. I’ll publish them later when
they are presentable.
Cheers
