Part I is here.
Part II is here.  
Part III is here. 

Solution #4:  Encryption

Considered by many to be the silver bullet to any security problem, encryption does very little to mitigate the insider threat.

Transport encryption can indeed mitigate the risk of a malicious insider snooping on an internal network (e.g. a rogue network admin). Backup encryption and laptop encryption can certainly lower the risk of careless insiders (e.g. in the case of backup media loss or laptop theft). However, a malicious or compromised insider with legitimate access rights to the sensitive data naturally has access to the information in its unencrypted format. This access can be abused for further leaking the information. Moreover, a malicious insider with legitimate access to the information can tamper with it regardless of where exactly encryption is applied.

Some forms of malicious insider threat can be mitigated if end-to-end data encryption is used (e.g. when the malicious insider is a database administrator). That is, the application code is responsible for encrypting the business data before it gets sent to the database. On the down side of it, this scheme requires proper key management mechanisms between applications and does not solve the threat of insiders operating through applications, or administrators who compromise the application servers. The cost of such solutions -other than the complexity of key management - is sometimes found in poor data retrieval performance (when the encrypted data is part of an index or of a search criterion).

So, while encryption can be useful in some cases, it is definitely not a silver bullet and it comes with the cost of complexity and performance.  

Amichai Shulman, Imperva CTO

From today's news, it seems China may have hacked US satellites.

I think that for years the basic information security assumption by military and government agencies was that they keep their data on isolate network that are not connected in any way to commercial and public communication infrastructure. With this assumption and staff screening they believed that the systems are safe. However, in today's reality most military and government systems are interconnected among themselves and have substantial data links (some online and some offline) to public and commercial systems and networks. Hence, once the "total isolation" assumption proved to be false, the traditional military security model collapsed in a magnificent way.

The latest (alleged) Landsat incident is a clear example of that. While the system is a military system operated mainly from military facilities and systems it can be accessed from a commercial station in Norway which in turn is connected to the Internet. The report hints that attack on the control system was indeed related to this commercial control system. This is yet another wake up call for these organizations to gradually abandon their older model and start deploying in-depth layered security into their information systems, much like the commercial organizations do. We should remember though that making this change (both mentally and logistically) is a long process given the huge scope of these systems.

Part I is here.
Part II is here.  

Solution #3:  Built-in Access Controls

Access controls attempt to solve the problem of individuals accessing the data store when they do not have permissions to do so. Consequently, they fail to mitigate the threats posed by malicious insiders abusing their legitimate privileges, or by compromised insiders working under their rightfully granted privileges. In addition, there are three other major shortcomings to using built-in access controls:

• They do not provide proper segregation of duty capabilities, in particular when the malicious insider is an administrator. In most systems administrative roles practically operate outside of the scope of internal ACL mechanisms.
• They are extremely hard (not to say impossible) to manage and maintain.  On the face of it, structured data has the benefit of a central management for access control (usually administrators). However, its distributed usage model of complex applications, written by a multitude of programmers, often leads to excessive (or rather, promiscuous) privileges. In the case of unstructured data, the discretionary access controls - where file owners are entitled to set individual access privileges for their files - leads to a complete ACL chaos. These shortcomings are exacerbated due to the lack of “test drive” capabilities in built-in access control mechanisms. In other words, when a certain control is set -or a certain privilege is removed- it immediately affects the ability of users and applications to access information. Thus a mistake in setting privileges can quickly lead to a business disruption. As a result, administrators and data owners tend to constantly grant more access privileges without removing unused ones.
• They lack the required granularity on the one hand, and the context semantics on the other hand. These two elements are required in order to express the true nature of access control requirements. For example, most built-in data access mechanisms cannot express the simple policy of “allow access to a given table through a specific application” or “allow a specific account to be used only from a specific machine” or even “do not allow access to specific data outside of business hours”. Further, access control constructs cannot express how many records can be retrieved, and which criteria to use in order to retrieve the data.

Yesterday, we did a big webinar on SQL injection.  In our webinar, we detailed the current hacker process for performing SQL injections and, more importantly, how to prevent them.  

Ironically, the Register reports that Sweden experienced the biggest security breach in that country's history. Nearly 210,000 login details from nearly 60 websites were compromised (the population of Sweden is about 9M so this breach represents 2% of the country's inhabitants.  For comparison, a breach of this magnitude in the US, with a population of 307M, would be about 6.14M lost records). About 90,000 of these accounts were taken from a Swedish blogging service and posted through a compromised Twitter account belonging to an MP.

The blogging service say that hack was through an underlying platform vulnerability.  Could it be a SQL injection?  How can you determine the cause without talking to the hackers or victims?

To begin, start with the exploited site "bloggtoppen.se."  If you conjecture that it was via SQL injection, simply do a Google search combining the site name with  some relevant SQL injection terms, such as "union select dump":

Here is the result from the first page of the search:

The first link above shows Flashback.org, a popular Swedish site - ranked #39 in Sweden by Alexa (http://www.alexa.com/siteinfo/flashback.org).  This first link also takes you to a discussion regarding what Google Translate calls "safety" which probably better translated as "vulnerability."

By looking at this page courtesy Google caching, you see the role of SQL injection very clearly:

Further, you see the role of Havij, an automated SQL injection tool we detailed in our study on SQL injections:

Part I is here.

Solution #2:  Built-in Audit Trail and Internal Trace

Built-in audit mechanisms provide logs which can (presumably) pinpoint what proper or improper activity was performed on the database and its contents. Once perceived to be the ultimate security mechanism to detect abuse against data, it is apparent today that audit logs don't always cut it. What's missing? One step:  leverage the logged information into a detection mechanism against internal data abuse. To do this requires linking a collection mechanism with a rules engine to look for violations. Even with such a complementary mechanism in place, most built-in audit trail mechanisms do not scale up to the level that is required for the collection of meaningful events for a production database.  This is because most of the DB server resources are invested in actual data processing. In addition, built-in audit trail mechanisms do not provide any separation of duty capabilities which leave the monitored system to abuse by privileged users (e.g., DBAs). 

While a built in audit trail can be useful in some cases as a forensic tool, and as an accountability trail, it cannot provide the true mitigation of the insider threat. In fact, we constantly witness media reports where the  accounts of data breaches clearly show that the existence of a detailed audit trail far from guarantees the timely detection of data breaches.

We’ve blogged on the insider threat issue and outlined how to profile potential problems. We saw what information was mainly being targeted and we even raised a few indicative signs of wrong-doing. Before we start delving into solutions, it’s important to recognize also what does not work so we can properly budget and prioritize. 

Solution #1:  Data Leak Prevention (DLP) 

The term DLP has been around for nearly a decade. The term is mostly used for describing solutions that detect sensitive data (using a variety of methods) as it flows outside of the organization. Accordingly, enterprise policies on such extrusion processes are applied. DLP solutions are traditionally deployed on the exit channels of the enterprise network (such as email, IM, FTP), and to a lesser extent, on end-points.

While initially hyped as the ultimate mitigation against the insider threat, traditional DLP solutions didn't meet expectations. Why?

• Most deployment projects get stuck in the stage of identifying all sensitive content within the incomprehensibly huge corpus of enterprise documents. This stage turns out to be a Sisyphus effort since by the time all of the original documents are “classified”, numerous new documents have already been created.
• The “Consumerization of IT” together with the mobility of workforce allows malicious insiders and compromised insiders to export the ill-gotten inside information, while operating outside of the enterprise networks. Further, this can be done and in an encrypted way that goes undetected by the DLP engine.
• Finally, DLP solutions are incapable of protecting against data tampering by insiders.

While DLP solutions continue to be sold on the market – each time under a different marketing term such as “content-aware DLP”, “DLP-lite” and so forth, dealing with insider threats effectively requires more. 

Recently, we blogged on the value of credit cards on the black market. This site showed the value of credit cards for sale online.  However, there's another site (which we won't promote) that also lists the value of credit cards.  

Here are the screen shots showing the credit card values for the various regions (click on the images to BIGGIFY):

US:

Canada:

EU:

Some interesting trends:

1. The price of the credit cards is consistent with what we posted previously posted, with Visa and MasterCard fetching the lowest average cost with AmEx getting more. However, this new set of pictures shows how premium cards, i.e., platinum or business cards, command higher value.  In our previous post, the lesser-used Discover cards commanded the highest value.
2. Cards belonging to Americans also see the lowest value.  Why?  There may be several reasons:
   1. Supply and demand--the US has a larger population with more credit cards, driving down black market value. 
   2. In Europe, the existence of a smart cards.  Having a smart card makes it much harder to conduct fraud so getting a usable credit card in Europe would drive value up.  Not surprisingly, according to this article, "MasterCard told ATM owners that those who don’t upgrade their ATMs to accept smart cards by 2013, will be responsible for any fraud committed through their machines. Likewise, Visa gave a deadline of 2015 for retailers to make the necessary upgrades if they don’t want to be liable to pay for any fraudulent transaction that has occurred in their stores."

Imperva CTO Amichai Shulman

I read the NYT article citing the deliberations the US government went through regarding a cyber attack on Libya.  

There’s an interesting historical example and precedent.  In 1982, Israel launched a full scale aerial raid on Lebanon and Syria, as a preparation of which the entire Syrian anti-aircraft radar system was taken down using various techniques available at that time. Most of these techniques are also very effective today against the aging Libyan anti-aircraft systems and probably wouldn’t be difficult.   But taking into consideration what other nations would do from a cyber attack perspective seems odd.  If foreign governments have hijacked US traffic and massive cyber attacks on American systems—why would the Obama administration think holding back on Libya would mitigate future attacks? 

Great study (reg required) from PWC on the readiness and status of American health providers ability to properly manage the process of converting physical records into electronic ones.  Since most of you don’t have time to read a 37 page document, here’s some highlights.

First, a note on the study’s methodolgy.  The survey involved around 600 provider, health insurer, and pharmaceutical/life sciences professionals on the privacy and security implications of the explosion of new data sources and uses in the healthcare industry.

Interesting finding #1:  The most frequently reported issue among providers was the improper use of protected health information (PHI) by an internal party, and improper file transfer containing PHI among health insurers and pharmaceutical and life sciences companies.  Pharmaceutical and life sciences respondents appeared least aware about these issues—64% saying they did not know if their organization had experienced a privacy/security-related issue in the last two years.

Comment:  This is the most disturbing aspect of the research.  Medical records will be very attractive to both insiders and hackers.  Recently, UCLA medical center had to pay $1M in settlements when celebrity health information was leaked by opportunistic insiders capitalizing on celebrity medical records.  Victims included Drew Barrymore, Arnold Schwarzenegger, Tom Hanks, Leonardo DiCaprio, Farrah Fawcett and others.  And its not just celebrities.  In the UK, a lonely male hospital employee accessed the records of 431 females 597 times.  Hackers like medical records since their completeness (social security numbers, address, credit card numbers for co-pays) facilitates identify theft.  In fact, the medical industry remains a consistent favorite among data thieves, with between 2 and 6M records stolen per year since 2008.  This does not include one of the largest breaches in history—70M medical records—lost on a hard drive by the Department of Veteran Affairs.

Interesting finding #2:  Only 58% of providers and 41% of health insurers reported including appropriate EHR use as a component of their employee privacy training.

Comment:  Training is a big deal.  Without training employees don’t know how to properly handle data or, more importantly, how to respect it.  You wouldn’t give a newbie a loaded gun without instruction.  Likewise, you don’t give a medical professional a few megabytes of data and expect it to be properly protected or destroyed.

Interesting finding #3: Of the 11 million people affected by data breaches since September 2009, 55% were affected by data breaches involving business associates. Healthcare organizations have only grazed the surface when it comes to ensuring their business associates can be trusted with PHI. Only 38% perform pre-contract assessments of their business associates and just 26% conduct post-contract compliance assessments.

Comment:  In September of this year, 300,000 medical records were discovered sitting in a file.  It is presumed that an outsourced hospital partner unintentionally leaked this data.  Similarly, Stanford University experienced a breach due to a similar mix up.  Failure in securing the complex web of health care providers, insurance firms, government and pharmaceutical companies is not an option.  But it seems it is an option...

Interesting finding #3:  Nearly three-quarters of healthcare organizations PwC surveyed said they are using or intend to use some form of secondary data, but less than half have addressed or are in the process of addressing privacy and security. Providers are most likely to participate. Top challenges mentioned were establishing information security functions, appropriately encrypting data, and creating multiple levels of separation between the data and the end consumer.

Comment:  The last sentence above represent the basic elements of data security.  If they’re struggling with these aspects—not a good sign.  Also troubling is the use of “secondary data”, i.e., data that is used, for example, to help judge the efficacy of new medical treatments or drugs.  Secondary data could be problematic.  For example, what if secondary data isn’t anonymized properly?

Imperva's Tomer Biton examines a new mass script injection attack targets ASP ASP.NET websites.  As usual, this is a major technical dissection.

First, by searching the javascripts payload names in Google we can see the mass of the infected pages (click image to BIGGIFY):

 The injection includes iframes to one of the following javascripts payloads to two sites (URLs not listed).

 The Injected Script (click image to BIGGIFY):

Now, let's deobfuscate the script:

The script targets visitors of 6 particular languages:

• en = English,
• de = German (Standard).
• Fr = French
• It = Italian
• Pl = Polish
• Br = Breton (yes, for real).

The redirector:

We can see the ‘go_to’ statement that redirects the visitor’s browsers to www3.strongdefenseiz.in domain:

By robtex.com:

strongdefenseiz.in returns 302 redirection response with one of the following domains: 

• hXXp://www2.strong-dvmaster.rr.nu
• hXXp://www2.simple-guardo.rr.nu

 How do you like your malware?

We were able to identify 3 different scripts from above domains. The scripts are downloaded as a gzip encoded.  However, with the Malzilla tool we can see get them in a better view (click image to BIGGIFY):

Once the scripts get executed in the visitor’s browser one of the following pages loads (click images to BIGGIFY):

Script # 1: Top 10 Famous Celebrity Sex Scandals

Script #2: Emma Watson never seen before home video

Script #3: Scarware/Fake Anti-Virus

What About The Malware?

The malware's main characteristics include:

• FileSize: 292.00 KB (299013 bytes)
• MD5: 8DACD674BF9F7A08BFF667721E53B106
• SHA1: 38954871CE0D2249BCFA500F24A00A5FAF93BFA0

The binary presents a layer of UPX compression.  The Section Header is composed as usual by the following sections:

•  .UPX0
• .UPX1
• .rsrc.   

This sample designed to redirect web search results of Bing.com and Google.com.  It uses rootkit techniques to hide its presence from the victim and security products. This is not the first time we see this kind of behavior, malware from the TDSS (TDL3 and TDL4) and ZeroAccess/Serifef families were involved in nearly all cases of those annoying redirects.

I’m guessing, the sample is routing the traffic eventually to Google after monitoring it or logging it for whatever reason.

Once executed the sample creates a service by loading a kernel mode driver – 5640.sys:

 SYSTEM process (PID 4) gets infected by a malicious thread injection (click to BIGGIFY):

The local pharming technique?  The sample modifies locks and set as hidden the system file /etc/hosts (click to BIGGIFY):

After entering ~ 60 CRLF lines also adds the following entries (must pageDn in order to see the entries):

The sample also copies itself to a tmp folder with a .tmp extension:

As described above, the sample is designed to redirect user searches from ‘Google’ and ‘Bing’.  After infection pinging Google.com and bing.com returned the same IP (click to BIGGIFY):   

Before Infection                 After Infection

Whereas Facebook.com is not a target:

Be safe.