Hackers

Hackers
Since 2004, Verizon Business have been publishing reports focused on data theft, security breaches, and cyber-crime trends based on external forensic investigations. Data has been contributed by the United States Secret Service, NHTCU, AFP, IRISS, and PCeU and is all based on first-hand evidence.
These reports contain hundreds of pages analyzing thousands of incidents and more than a billion compromised records. They can be downloaded from Verizon Business, and a couple are also found at the United States Secret Service. We encourage you to read them. Here are also direct links to the 2010, 2011, and 2012 reports.
The numbers in this page refers to the most recent report (2012) that contains analysis of data breaches during 2011.

You Are Vulnerable

You might not know how or why, but the numbers speak for themselves. The reports claim that “Most data thieves are professional criminals deliberately trying to steal information they can turn into cash.”
Which might explains these figures:
  • In 85% of breaches, initial compromise was obtained in minutes (97% were compromised within hours).
  • Compromised database servers account for 6% of breaches and 96% of compromised records (33% of breaches and 98% of records in large organizations)
  • Personal information (Name, SS#, Addr, etc.) accounts for 4% or breaches and 95% of compromised records (27% of breaches and 98% of records in large organizations)
  • The use of stolen login credentials accounts for 32% of the breaches and 82% of the compromised records (30% of breaches and 84% of records in large organizations)
And large organizations are far from being immune, as the reports claim:
  • “So, what about larger organizations? Surely they’re a lot more difficult to infiltrate, right? Sadly, our data seems to suggest otherwise; it does not appear that cybercriminals have to work much harder to compromise larger organizations than they do for smaller ones.”
  • “Lest larger organizations read this and believe themselves immune to such rapid compromises, they should take heed of the following statistic. A notmuch-better 71% of them fell within minutes. Granted, the actions that felled them were often different (e.g., SQL injection), but does that really matter when the result is the same?”

Key Statistics

To understand the risk of hacking, it is important to first be familiar with some real world numbers:
Who?
  • 98% of the breaches were from from external agents
  • 79% of the victims were targets of opportunity
Discovery
  • 92% of the incidents were discovered by a third parties
  • 85% of the breaches took weeks or longer to discover
How?
  • 81% of the breaches used hacking
  • 96% of the attacks were not highly difficult
Prevention
  • 97% of the breaches could be avoided through simple or intermediate controls
  • 96% of the victims that were subject to PCI-DSS, were not compliant

What the Numbers Mean?

Almost all the breaches were done by external hackers and most of them where breaches of opportunity. Breaches of opportunity are not targeting specific organizations, but go after “easy targets” (see Protecting the data). It could be a password the hackers came across, a vulnerability they discovered in one of your systems, or any other random chance.
Breaches of opportunity are difficult to defend against because they start from something you cannot predict. They also tend to compromise systems through something that is considered secured (e.g. the DBA’s password) and therefore lacks monitoring.
This also explains the fact that most breaches took a long time to be discovered, and were discovered by 3rd parties. Organizations that lack internal monitoring tend to rely on preventative measures for protection. Once those measures have been compromised, the organization is left completely defenseless and unaware of that fact.
The fact that most breaches used hacking and were not difficult supports the fact that there were done by external sources and were breaches of opportunity.
Maybe the most disconcerting is the fact that most victims were not compliant with security regulations and that simple or intermediate controls would have prevented those breaches.

Detection & Prevention

The reports contain many recommendations and we encourage you to read them. The same recommendations repeat every year because the same problems resurface again and again. Some of the recommendations refer to networking (like firewalls), terminal security (like phishing and keyloggers) and more, but some are relevant to databases:
Stolen Credentials
  • Detection using user behavioral analysis indicating anomalies (Intelligent Auditing)
  • Detection by monitoring all administrative/privileged activity (Declarative Auditing)
SQL injection
  • Detection using IDS (Intelligent Auditing)
  • Prevention using secure development practices
  • Prevention by using bind variables and/or stored procedures
Unauthorized access via default credentials
  • Prevention by changing the default credentials (prior to deployment)
  • Prevention by deleting or disabling of default accounts
  • Prevention by scanning for known default passwords (following deployment)
Brute-force attack
  • Detection by identifying of numerous failed login attempts (Declarative Auditing)
  • Prevention by enforcing password policies (length, complexity, clipping levels)
  • Prevention by account lockouts (after x tries)
  • Prevention using password cracking tests
Backdoors, Command and Control
  • Detection using IDS (Intelligent Auditing)
  • Detection using routine log monitoring
  • Prevention using data loss prevention (DLP) tools
Pretexting (Social Engineering)
  • It is very difficult to detect social engineering as it is designed to exploit human weaknesses and bypass technological alerting mechanisms. Unusual communication, requests outside of normal workflow or policies should be suspicious.
  • Prevention using general security awareness training that includes recognition of suspicious pretexting attempts
  • Prevention using clearly defined policies and procedures and training to verify suspicious requests through trusted methods and channels
It should be pointed out that other measures that are not at the database level are effective and should be considered.

Additional Quotes

Many things in the reports are worth mentioning, but here are a few more choice quotes about fraud, partners, and compliance:
  • “We hypothesize that many insider crimes go unreported because the organization is unaware of them, or because they decide for political reasons to handle it internally.” (do not disregard the risk of Fraud)
  • “A partner’s lax security practices and poor governance — often outside the victim’s control or expertise — are frequently catalysts in security incidents.”
  • “We still hear the common mantra “How could I have been breached?—I’m compliant!” We cannot stress enough that while compliance definitely helps drive security, compliance does not equal security.”

The Bottom Line

The Oracle database built-in security measures are somewhat limited in most production environments (see Security Scope). What you can do, you probably already have done – changed default passwords, lock out accounts due to excessive failed logons, grant the least privileges, etc.
The underlying problem is that you cannot limit access further, and that your systems are still vulnerable to silly things like:
  • A stolen password
  • A password that contains the user’s first name followed by the number of the month
  • Someone putting a password in a script
  • Putting a post-it note on the monitor with the password
  • Saving passwords in a spreadsheet on the file server
No preventative measure can protect against these problems. The only solution is to audit the activity and see what’s going on in the database.
All these and many other problems can be mitigated through database auditing. It is one of the most fundamental controls missing in Oracle databases today.
Ideally activity should be monitored both by automation (intelligent auditing) and scanned by personnel (declarative auditing).. but any monitoring is better than none. Try Core Audit and see the visibility you are lacking.

What's next?

I want to know more about Core Audit!
Great! Here are a few options:
  • Read more about Core Audit features, reports, etc.
  • Try our Online Demo and play with Core Audit right now
  • Ask for a Personal Demo from one of our experts and get all your questions answered
  • Download a Free Trial and experience Core Audit on your systems
I only want more information, not a product
Not a problem, here is a list of relevant pages, and we are always available to answer any question
  • Fraud – Read
  • Intelligent Auditing – Read
  • Rationalizing Oracle database auditing – Read
  • Oracle security checklist – Read
  • Incident investigations and forensic analysis – Read
  • Oracle Database Vault security problems – Read
  • Cost of a database breach – Read
  • How to prevent a database breach – Read
  • Oracle database security – Read