Fine. Allow me to be more pedantic^H^H^H^H^H^H^H^Hthorough, since you've decided to try to be clever. I'll try not to use words loaded with overtones of logic.
One needs more than insight and creativity to excel at mathematics. One also needs discipline, endurance, and the ability to perform arithmetic. I posit that computers exceed humans in all three of the latter traits provided a sufficiency of resources. Feel free to disagree.
Computers provide all of those latter traits, and are a valuable tool to mathematicians. We've already established that there are truths we would not know to be truths without the use of computers.
How about this for a simpler way of putting it:
Not all mathematics are possible without computation.
Current fraud detection systems in use in the financial industry are based on two primary knowledge bases:
1. A knowledge of your purchasing pattern as a consumer. To wit, having a statistically significant sample of what are valid transactions as well as knowing your credit score and income.
Do you shop at high-end stores? Do you use your card for primarily travel and entertainment? Do you use your card for everyday purchases? How much of your line-of-credit do you tend to use?
2. A comparison of recent transactions. For example:
A sudden wave of big-ticket purchases very close together in time, such as hitting a Best Buy the same day as buying jewelry.
A single card making multiple high-value transactions (3 or more) within an hour.
A pattern of unattended-auth-transaction (think pay-at-the pump) to big ticket purchase to unattended-auth and back.
Using geometric statistical analysis could only complement pattern analysis in any case, and I fail to see how it's superior to the existing behavior scoring algorithms which are based on an individual's past history, weighting each new transaction to determine if it's "out of profile", and if so, by what margin. Sometimes the fraud is only revealed by several transactions scoring progressively higher on the fraud-o-meter, and I suspect the geometric statistic analysis would fail to trigger that as an event, as it would be a continuation of the pattern.
My ability to read statistics papers is sadly out of date. Anyone want to give a shot at translating this into non-doctoral English?
It's magical from the perspective that unless one provides the database encryption key to the system, one can't read cleartext from encryption columns/tables, because the database won't let you.
You also can't update, insert, or delete from those table either. I'd say they're read only, but it's more like they're "look-at" only, because you can't read them.
The problems I have with stored procs are manifold:
1. Stored procs are not always used to manipulate or select data. For example, if I have to "fix" data from a bad program run, I know I'm lots more inclined to run straight SQL which does what I tell it too -- because SQL is a declarative language, not a procedural one.
2. So, what if I don't use your stored proc? Oh, you'll use triggers? Triggers can be disabled, and some applications/APIs (such as Oracle's direct-path option within SQL*Loader) never passes through the SQL interface, so triggers, even if enabled, do not get called. Congratulations -- your encryption routine never got called.
Telling Oracle to encrypt my data like this:
ALTER TABLE SECRET_STUFF MODIFY CC_NUMBER ENCRYPT USING '3DES';
is declarative integrity. The logic to perform those operations is built into the kernel and is 99.44% sure to have been optimized within an inch of its life.
Declarative integrity will always be as or more performant because it will not require more SQL calls to verify the integrity than equivalent procedural code. The integrity checks (SELECT for DELETE RESTRICT, UPDATE for CASCADE UPDATE SET NULL, DELETE for CASACADE DELETE) are in the kernel, not requiring a full client SQL call. It's got a shorter round trip for each deleted row, so it will be no slower, and may be faster.
Declarative joins will always be as or more performant than procedural joins because the database can perform your join in fewer calls, and it might be able to find a better access plan than you thought of when coding.
Quit treating SQL and RDBMS's as access layers -- it's not dbFAT, it's not dbISAM. It's not even some big VMRAM area for writing HashMaps and Arrays. SQL is a language -- a language with warts, to be sure -- but it's the best available tool for working with the database. Procedural solutions to generally indicate either a lack of understanding of SQL or a lack of features in the database.
If you are a processor of Visa and/or MasterCard transactions (not a merchant, but a financial institution or payment processor) then it applies. It's got differing levels of compliance required depending on the volume of transactions processed -- a small processor has a lower bar than, say, First Data Corporation, one of the (if not the) largest payment processor.
It's similarly light on the implementation details -- which means there's plenty of good money to be made by consulting/auditing firms.
Actually, I was projecting (read: guessing) HIPAA requirements were every bit as stringent as PCIDSS (which I've do understand). I work in the payment card industry, not the healthcare industry.
Here's what PCIDSS boils down to from a database perspective:
Thou shalt not store Track2 (magnetic stripe) or CVV (card verification value) outside of the authorization system.
Thou shalt encrypt customer sensitive information, at a minimum, credit card/account numbers.
To further comply with Gramm-Leach-Bliley and California... 1950, I think, you better also encrypt information which might be of interest to identity theives, including:
Social Security Numbers / Tax ID numbers Drivers License Numbers
I don't believe there's a defensible requirement to encrypt customer name/address listings, as those are more or less public domain.
I am somewhat concerned if HIPAA requirements are not more stringent than PCIDSS... but that's a different issue.
Indexes are gibberish if and only if each row (tuple) uses a different initialization vector, or in Unix vernacular, salt.
Oracle's Transparent Data Encryption by default uses a different initialization vector for each encrypted column and for each row. Oracle will not permit you to index columns with row-level initialization vectors, but it will permit you to use index columns with no row-level initialization vectors. This preserves the use of indexes for keyed reads, although not for range (or skip) scans.
You can also specify the initialization vector for a given column, which means that you can have two identical cleartext values in different tables being stored with identical ciphertext, which means indexes can be used in join operations.
There's definitely a tradeoff between usability and security -- after all, if all CC's use the same column-level IV and no row-level IV, then once you break the crypto on one row, you break the crypto on all rows.
Incidentally, the book under review (which I hammered through last night at Borders) uses a design where the IVs are stored in line, in the table. Yeah -- everyone's gonna rewrite their app to store the attribute's IV. Sure they are.
Packet sniffing : database file scraping:: panning for gold : strip mining or Packet sniffing : stealing a backup set:: robbing a liquor store : robbing a bank
Yes, you can steal data. However, you can only steal the data that passes over the network. If you scrap the files or steal a backup, you get all of the data.
The key is stored in a password protected Oracle Wallet, which can either be an encrypted file or in an HSM.
Stored procedures and triggers, ah, so very performant. And completely bulletproof. Unless, of course, someone disables a trigger or doesn't use the stored procedure to perform DML.
Also, if your keys are embedded in your code (server or client), how do you rotate them? Oh, you're using public/private keys? Well, have fun with bad crypto performance.
Oracle rather sensibly renamed DBMS_OBFUSCATION_TOOLKIT to DBMS_CRYPTO in 10g -- don't blame them for using a stupid name back in... 1999, was it?
If you're thinking you can code procedural encryption that is in any way faster or more robust than declarative encryption, you're not thinking clearly. Hell, if you think you're that good of a coder, why bother using declarative RI or constraints? Handle all those in stored procs and triggers as well.
Lastly, having more languages does not a better system make -- having more languages means... having more languages. Oracle natively supports C, COBOL, and Java as external languages, and that's probably sufficient unto the day.
With Oracle, neither the application nor end user need know the specific value of the encryption key. Oracle's been able to do that using DBMS_OBFUSCATION_TOOLKIT for several releases now. However, using statements like yours above means you can not manage or rotate keys easily. If you can't do that, you don't have an encryption solution, you have a disaster in waiting.
Further, you're relying on application calls to the DBMS to do the encryption -- which assumes your app is the one and only app to get data into or out of the database.
Which is not a practical assumption in the real world.
... but it sure is now, and here's two giant reasons why:
HIPAA PCIDSS
Both specify, more or less, that sensitive information must be encrypted within the database. That means the data at rest on disk must be encrypted. Encrypting customer-sensitive information in the database will prevent exposure of customer sensitive information from:
Disk-scraping attacks (such as if the storage rep who replaces a failed drive in the SAN is ethically challenged) Backup attacks (where a complete database backup can be restored and hacked)
What doesn't it save you from? Users who have rights they don't need looking at data they don't need. Users who don't need access to the system but have it anyway. Poor security standards (not changing default passwords, insufficient password strength, etc). The DBA, who can always log in and see whatever the heck he wants(I almost said he or she, but who am I kidding). The SysAdmin, who can become the DBA, and can scrape the disks himself.
What are the costs of encryption? 1. It will cost you CPU cycles. (Don't even think about sending all the crypto calls over the wire to a hardware module -- it'll cut application througput in half). 2. You won't be able to have queries like "Select name from patients where ssn between '5030000000' and '503999999'" use indexes, as the ordering of crypto is gone forever.
What's being done about this? Enterprise vendors are busy rolling out encryption solutions (the other security holes already have support around them, but often aren't implemented in applications.) DB2 lets you encrypt the file system, or tables, or values within tables.
Oracle lets you encrypt columns within tables with AES128, AES192, AES256, or 3DES. (You can also set it up so that the same value in 2 columns has the same ciphertext, which is a good thing.)
SQL Server's got... something, but I don't support it, so I don't care.
(PostgreSQL and MySQL users, I left you out on purpose. I said enterprise vendors, and I meant it.)
If its information that you don't think someone who gets a backup tape should be able to read, then you better encrypt it.
At a minimum, you should look at encrypting all the account numbers, ssn's, credit card numbers, and the like. Encrypting text data -- such as names and addresses will likely impose a significant usability performance on your system.
Go to technet.oracle.com and register. That will enable you to download Oracle's documentation.
Read and understand the Concepts guide. It's important.
Then read the Oracle Spatial User's Guide and Reference.
After that, you should have some semblance of a clue. If you want good Oracle books, any of Tom Kyte's or Jonathan Lewis' would be a good place to start.
Oracle 9i supports full outer joins using the FULL OUTER JOIN syntax.
I find the Oracle's heirarchical structures significantly simpler than the ANSI standard, which reminds me a lot of the MODEL stuff that Oracle introduced in 9i.
Definitely. Getting certified exposes you to some aspects of a product you might not have known about, and also might help point out some of the things you know that just ain't so, or at least just ain't so anymore.
Do you pay for them? Does the company pay for them?
I struck a deal with my boss. I paid for every exam, and if I passed, I got reimbursed. No risk for the company, and I had plenty of incentive to learn well enough to pass the first time.
Is it worth being certified if you do not get a pay raise for it?
Who's to say the pay raise you get is immediate? After all, getting certification demonstrates a professional commitment, and it could be the dealbreaker between you and the other slack-jawed yokels you compete with for raises and promotions. Never ever forget that your co-workers are your competition too.
Also, it's makes getting that next job (and the accompanying pay raise) ever so much easier when it comes to getting passed the HR trollkin.
What certifications bring more than others? Are specialized more employable than general certifications?
My perception is that specialized certifications will always be more valuable than generalized ones. One of the key things I think Oracle does that I don't know if Microsoft and Cisco do is version their certifications. Just because you got an MCSE when NT 3.51 was king doesn't mean you know diddly about ActiveDirectory, f'rinstance.
Is there such thing as being TOO certified for a job?
Yup. Too many certifications and I'd suspect you're a dilettante, or that you spent too much time reading braindumps. A 25 year old with a CCNA, OCP, MCDBA, A+, and an MCSE probably lacks depth in any those products, and is therefore truly dangerous if unsupervised.
I'm not sure that the reporter from the Times who's being held in contempt is right now subject to conspiracy or accessory charges for any crimes precipitated by the use of an anonymous source. That would be the main difference I see -- that of criminal liability. Civil liability is already covered to some degree by slander/libel.
Yes, I know that the Bill of Rights are the protections of the people against the government; however, the Fifth Estate considers itself to be performing a governmental function (namely, oversight), so one could conceivably argue that the protections of the Bill of Rights could and should be extended to protect against the press, as well as to protect us against each other.
I'm arguing that the protections provided by that amendment could and should be extended beyond criminal law and into civil law.
The larger point is that true anonymity yields a lack of accountability. While that may be good for dissidents, it can really suck when someone uses the press as a tool of character assassination.
Slashdot Mirror
Leverage is also a transitive verb. Sure, it maybe the buzzwordization of English, but it qualifies as accepted use.
Fine. Allow me to be more pedantic^H^H^H^H^H^H^H^Hthorough, since you've decided to try to be clever. I'll try not to use words loaded with overtones of logic.
One needs more than insight and creativity to excel at mathematics. One also needs discipline, endurance, and the ability to perform arithmetic. I posit that computers exceed humans in all three of the latter traits provided a sufficiency of resources. Feel free to disagree.
Computers provide all of those latter traits, and are a valuable tool to mathematicians. We've already established that there are truths we would not know to be truths without the use of computers.
How about this for a simpler way of putting it:
Not all mathematics are possible without computation.
I don't know how much clearer I could be, considering the use of the phrase "necessary but not sufficient" in a discussion about math.
Insight and creativity are necessary, but not, in all cases, sufficient. Reference the initial Apple-Haken proof of the Four Color Theorem.
I know, semantics. But if anything is based on semantics, it's math.
Mobility Radeon 9600 and up are natively supported by the ATI Catalyst drivers.
TFA is written by Harry Jenkins.
Who botched the joke again?
Current fraud detection systems in use in the financial industry are based on two primary knowledge bases:
1. A knowledge of your purchasing pattern as a consumer. To wit, having a statistically significant sample of what are valid transactions as well as knowing your credit score and income.
Do you shop at high-end stores? Do you use your card for primarily travel and entertainment? Do you use your card for everyday purchases? How much of your line-of-credit do you tend to use?
2. A comparison of recent transactions. For example:
A sudden wave of big-ticket purchases very close together in time, such as hitting a Best Buy the same day as buying jewelry.
A single card making multiple high-value transactions (3 or more) within an hour.
A pattern of unattended-auth-transaction (think pay-at-the pump) to big ticket purchase to unattended-auth and back.
Using geometric statistical analysis could only complement pattern analysis in any case, and I fail to see how it's superior to the existing behavior scoring algorithms which are based on an individual's past history, weighting each new transaction to determine if it's "out of profile", and if so, by what margin. Sometimes the fraud is only revealed by several transactions scoring progressively higher on the fraud-o-meter, and I suspect the geometric statistic analysis would fail to trigger that as an event, as it would be a continuation of the pattern.
My ability to read statistics papers is sadly out of date. Anyone want to give a shot at translating this into non-doctoral English?
You also can't update, insert, or delete from those table either. I'd say they're read only, but it's more like they're "look-at" only, because you can't read them.
The problems I have with stored procs are manifold:
1. Stored procs are not always used to manipulate or select data. For example, if I have to "fix" data from a bad program run, I know I'm lots more inclined to run straight SQL which does what I tell it too -- because SQL is a declarative language, not a procedural one.
2. So, what if I don't use your stored proc? Oh, you'll use triggers? Triggers can be disabled, and some applications/APIs (such as Oracle's direct-path option within SQL*Loader) never passes through the SQL interface, so triggers, even if enabled, do not get called. Congratulations -- your encryption routine never got called.
Telling Oracle to encrypt my data like this:is declarative encryption, just as: is declarative integrity. The logic to perform those operations is built into the kernel and is 99.44% sure to have been optimized within an inch of its life.
Declarative integrity will always be as or more performant because it will not require more SQL calls to verify the integrity than equivalent procedural code. The integrity checks (SELECT for DELETE RESTRICT, UPDATE for CASCADE UPDATE SET NULL, DELETE for CASACADE DELETE) are in the kernel, not requiring a full client SQL call. It's got a shorter round trip for each deleted row, so it will be no slower, and may be faster.
Declarative joins will always be as or more performant than procedural joins because the database can perform your join in fewer calls, and it might be able to find a better access plan than you thought of when coding.
Quit treating SQL and RDBMS's as access layers -- it's not dbFAT, it's not dbISAM. It's not even some big VMRAM area for writing HashMaps and Arrays. SQL is a language -- a language with warts, to be sure -- but it's the best available tool for working with the database. Procedural solutions to generally indicate either a lack of understanding of SQL or a lack of features in the database.
PCIDSS -- Payment Card Industry Data Security Standard.
i sa/ops_risk_management/cisp_PCI_Data_Security_Stan dard.pdf
http://usa.visa.com/download/business/accepting_v
If you are a processor of Visa and/or MasterCard transactions (not a merchant, but a financial institution or payment processor) then it applies. It's got differing levels of compliance required depending on the volume of transactions processed -- a small processor has a lower bar than, say, First Data Corporation, one of the (if not the) largest payment processor.
It's similarly light on the implementation details -- which means there's plenty of good money to be made by consulting/auditing firms.
Actually, I was projecting (read: guessing) HIPAA requirements were every bit as stringent as PCIDSS (which I've do understand). I work in the payment card industry, not the healthcare industry.
Here's what PCIDSS boils down to from a database perspective:
Thou shalt not store Track2 (magnetic stripe) or CVV (card verification value) outside of the authorization system.
Thou shalt encrypt customer sensitive information, at a minimum, credit card/account numbers.
To further comply with Gramm-Leach-Bliley and California... 1950, I think, you better also encrypt information which might be of interest to identity theives, including:
Social Security Numbers / Tax ID numbers
Drivers License Numbers
I don't believe there's a defensible requirement to encrypt customer name/address listings, as those are more or less public domain.
I am somewhat concerned if HIPAA requirements are not more stringent than PCIDSS... but that's a different issue.
Indexes are gibberish if and only if each row (tuple) uses a different initialization vector, or in Unix vernacular, salt.
Oracle's Transparent Data Encryption by default uses a different initialization vector for each encrypted column and for each row. Oracle will not permit you to index columns with row-level initialization vectors, but it will permit you to use index columns with no row-level initialization vectors. This preserves the use of indexes for keyed reads, although not for range (or skip) scans.
You can also specify the initialization vector for a given column, which means that you can have two identical cleartext values in different tables being stored with identical ciphertext, which means indexes can be used in join operations.
There's definitely a tradeoff between usability and security -- after all, if all CC's use the same column-level IV and no row-level IV, then once you break the crypto on one row, you break the crypto on all rows.
Incidentally, the book under review (which I hammered through last night at Borders) uses a design where the IVs are stored in line, in the table. Yeah -- everyone's gonna rewrite their app to store the attribute's IV. Sure they are.
No argument. However, in SAT-ese:
:: panning for gold : strip mining :: robbing a liquor store : robbing a bank
Packet sniffing : database file scraping
or
Packet sniffing : stealing a backup set
Yes, you can steal data. However, you can only steal the data that passes over the network. If you scrap the files or steal a backup, you get all of the data.
The key is stored in a password protected Oracle Wallet, which can either be an encrypted file or in an HSM.
Stored procedures and triggers, ah, so very performant. And completely bulletproof. Unless, of course, someone disables a trigger or doesn't use the stored procedure to perform DML.
Also, if your keys are embedded in your code (server or client), how do you rotate them? Oh, you're using public/private keys? Well, have fun with bad crypto performance.
Oracle rather sensibly renamed DBMS_OBFUSCATION_TOOLKIT to DBMS_CRYPTO in 10g -- don't blame them for using a stupid name back in... 1999, was it?
If you're thinking you can code procedural encryption that is in any way faster or more robust than declarative encryption, you're not thinking clearly. Hell, if you think you're that good of a coder, why bother using declarative RI or constraints? Handle all those in stored procs and triggers as well.
Lastly, having more languages does not a better system make -- having more languages means... having more languages. Oracle natively supports C, COBOL, and Java as external languages, and that's probably sufficient unto the day.
Yeah -- but key management is the hard part.
Which you apparently don't know yet.
With Oracle, neither the application nor end user need know the specific value of the encryption key. Oracle's been able to do that using DBMS_OBFUSCATION_TOOLKIT for several releases now. However, using statements like yours above means you can not manage or rotate keys easily. If you can't do that, you don't have an encryption solution, you have a disaster in waiting.
Further, you're relying on application calls to the DBMS to do the encryption -- which assumes your app is the one and only app to get data into or out of the database.
Which is not a practical assumption in the real world.
... but it sure is now, and here's two giant reasons why:
HIPAA
PCIDSS
Both specify, more or less, that sensitive information must be encrypted within the database. That means the data at rest on disk must be encrypted. Encrypting customer-sensitive information in the database will prevent exposure of customer sensitive information from:
Disk-scraping attacks (such as if the storage rep who replaces a failed drive in the SAN is ethically challenged)
Backup attacks (where a complete database backup can be restored and hacked)
What doesn't it save you from?
Users who have rights they don't need looking at data they don't need.
Users who don't need access to the system but have it anyway.
Poor security standards (not changing default passwords, insufficient password strength, etc).
The DBA, who can always log in and see whatever the heck he wants(I almost said he or she, but who am I kidding).
The SysAdmin, who can become the DBA, and can scrape the disks himself.
What are the costs of encryption?
1. It will cost you CPU cycles. (Don't even think about sending all the crypto calls over the wire to a hardware module -- it'll cut application througput in half).
2. You won't be able to have queries like "Select name from patients where ssn between '5030000000' and '503999999'" use indexes, as the ordering of crypto is gone forever.
What's being done about this?
Enterprise vendors are busy rolling out encryption solutions (the other security holes already have support around them, but often aren't implemented in applications.) DB2 lets you encrypt the file system, or tables, or values within tables.
Oracle lets you encrypt columns within tables with AES128, AES192, AES256, or 3DES. (You can also set it up so that the same value in 2 columns has the same ciphertext, which is a good thing.)
SQL Server's got... something, but I don't support it, so I don't care.
(PostgreSQL and MySQL users, I left you out on purpose. I said enterprise vendors, and I meant it.)
... oh, heavens.
You're serious, aren't you?
That's just way too cute.
Comply with Visa/MC's PCI (pdf warning):
i sa/ops_risk_management/cisp_PCI_Data_Security_Stan dard.pdf?it=search
http://usa.visa.com/download/business/accepting_v
If its information that you don't think someone who gets a backup tape should be able to read, then you better encrypt it.
At a minimum, you should look at encrypting all the account numbers, ssn's, credit card numbers, and the like. Encrypting text data -- such as names and addresses will likely impose a significant usability performance on your system.
Go to technet.oracle.com and register. That will enable you to download Oracle's documentation.
Read and understand the Concepts guide. It's important.
Then read the Oracle Spatial User's Guide and Reference.
After that, you should have some semblance of a clue. If you want good Oracle books, any of Tom Kyte's or Jonathan Lewis' would be a good place to start.
Oracle 9i supports full outer joins using the FULL OUTER JOIN syntax.
I find the Oracle's heirarchical structures significantly simpler than the ANSI standard, which reminds me a lot of the MODEL stuff that Oracle introduced in 9i.
Was it worth getting certified?
Definitely. Getting certified exposes you to some aspects of a product you might not have known about, and also might help point out some of the things you know that just ain't so, or at least just ain't so anymore.
Do you pay for them? Does the company pay for them?
I struck a deal with my boss. I paid for every exam, and if I passed, I got reimbursed. No risk for the company, and I had plenty of incentive to learn well enough to pass the first time.
Is it worth being certified if you do not get a pay raise for it?
Who's to say the pay raise you get is immediate? After all, getting certification demonstrates a
professional commitment, and it could be the dealbreaker between you and the other slack-jawed yokels you compete with for raises and promotions. Never ever forget that your co-workers are your competition too.
Also, it's makes getting that next job (and the accompanying pay raise) ever so much easier when it comes to getting passed the HR trollkin.
What certifications bring more than others? Are specialized more employable than general certifications?
My perception is that specialized certifications will always be more valuable than generalized ones. One of the key things I think Oracle does that I don't know if Microsoft and Cisco do is version their certifications. Just because you got an MCSE when NT 3.51 was king doesn't mean you know diddly about ActiveDirectory, f'rinstance.
Is there such thing as being TOO certified for a job?
Yup. Too many certifications and I'd suspect you're a dilettante, or that you spent too much time reading braindumps. A 25 year old with a CCNA, OCP, MCDBA, A+, and an MCSE probably lacks depth in any those products, and is therefore truly dangerous if unsupervised.
Sure, discriminate against the Irish and Scots.
Paddy McSean
If a round of golf only takes three hours without a cart, then:
a: you have the course to yourself, and
b: you like to run while you play golf.
Also, if you're not enjoying a few tasty beverages (often with ~100-150 calories per) while playing, well, then, what's the point?
Actually, at any level above little league, the "weakest" outfield player is generally the left fielder, as a right fielder needs a better arm.
Reference players historical (Roberto Clemente) and current (Vladimir Guerrero).
I'm not sure that the reporter from the Times who's being held in contempt is right now subject to conspiracy or accessory charges for any crimes precipitated by the use of an anonymous source. That would be the main difference I see -- that of criminal liability. Civil liability is already covered to some degree by slander/libel.