Late in 2011, Max Schrems asked Facebook for a profile the social networking company assembled based on his posts, likes and friends.  Max received a 1200 page PDF file with lots of personal details.  Being a law student, understandably, Max examined the information from a privacy perspective.  But what about security?  We examined the content from Max’s report and asked: 

• What Facebook data do hackers find interesting (part I)?
• How can hackers go about and obtain that data (part II)?

In the first of this two-part series we’ll tackle each question respectively. But before we do, some background on personal information and social media:

• Facebook contains much more data than most people realize.  Again, Max Schrems got a 1200 page document from Facebook.  Max noted that the document contained not just a lot information about him—but on his friends as well.
• Not all of the user’s private data is directly accessible to the user. Although some of the information is accessible via the application (a user can view their pictures, wall, and so forth), some of the data is not as accessible. For instance, dynamic data (such as unsaved chat logs) or geo info (such as IP addresses) are not typically retrieved. These are the things that Max, an EU citizen, requested to receive. Facebook, complying with EU regulations, obliged Max with all of his “inaccessible” data.
• The issue is not confined to Facebook alone.  Webmail apps, for example, hold much more revealing personal information. Further, Google’s recent privacy policy change allows Google to cross-referencing the content with the user’s search queries and GPS location. This type of cross-referencing may potentially have more severe implications, raising many privacy concerns.

So what data does Facebook contain?  It is a treasure-trove for information diggers since it contains:

• Personal Identifiable Information (PII) as well as general personal information. Included in this category are date of birth, home address and even the mother’s maiden name (and yes, some banks still use this information as an identifier). Even social security numbers can be extrapolated from many Facebook profiles, as shown by researchers at Carnegie Mellon University.

This type of data can be used for various purposes. With enough gleaned information, a hacker can even gain control of the user’s other online accounts. For example, using the “Forgot Password” feature which exists in many systems. This feature requires people to identify themselves by supplying an answer to a pre-determined personal question, such as the name of the user’s dog. An information digger can retrieve that type of info from the individual’s Facebook profile (click to BIGGIFY):

Hackers can also use this information to create more credible phishing emails. The email may contain a personalized message requesting that the user click on a link which actually refers to an attacker-controlled site, or even download a malware-laden file.

Hackers can also use this information for extortion purposes. A student in Pennsylvania, for example, was told by hackers that they would post a private video of online unless he wired $500 to a man in Morocco. 

Finally, professional identity thieves can use much of this data to build a better profile of the victim.

• Passwords. Although this may also be considered PII, we found it reasonable to include it as a separate section due to its sensitivity. Gaining access to the victim’s account ultimately gives the hacker the knowledge and control over the user’s password. Consumers are notorious for using the same password across multiple sites, and the Facebook password may just as well be the same password to other online services. In effect, allowing the hacker to impersonate the users to other services.
• Friend-Mapping. Facebook is all about “Friends”. From a hacker’s perspective, this means that getting hold of a victim’s account will also provide the knowledge of the user’s circle of friends.  Once in a circle of friends, a hacker posing as a trusted friend can cause mayhem:
  • This allows hackers to create better scams (aka “419 scams”).  For example, a message could seem to come from a friend requesting the transfer of monetary funds (“This is your friend, Tom. I am stranded in the middle of Paris with no money”). These phishing messages could be similar to those described above - containing links to malware or include malware-laden files. Since they purportedly come from the victim’s friend, the victim may be more susceptible to follow those links.
  • Through friends-mapping, a hacker can also gain enough personal information on the user which can also be used for extortion purposes. For instance, MIT researchers released a piece of software which can determine a user’s sexual orientation according to their circle of friends. Many raised the implications of this to the outing of closeted individuals.  The same approach could be applied to race or religion.
• Organizational structure. Similarly to friends-mapping, hackers can analyze the interleaved connections between individuals and analyze them in order to map out the structure of members of different organizations – as well as units within the organization. This is a stronger concern with other social networks, such as LinkedIn. However, this type of mapping can also be applied in Facebook, especially with businesses adopting “Fan” pages. The organizational structure can be used for corporate espionage, foreign-government and even military intelligence.  
• Business plans. As a professional social network, LinkedIn provides a hotbed for competitive intelligence. But even Facebook provides enough info which is usable for competitive intelligence. In fact, different companies exist which offer exactly this kind of service. Users can follow what their competitors are discussing and what conversations they are participating in.  
• Geo location information. Through geo-location information, a hacker can build a profile of the victim’s whereabouts. There were cases where law enforcement agencies actually were able to use this type of information to find and capture fugitives.  Geo location data is all together more valuable when cross-referencing it with the organizational structure. This can be very useful, say, to gain military intel on the location of the adversary’s military units. In fact, last year an IDF operation was cancelled following a soldier’s status update of the operation’s time and location.

Who then are the hacking groups who would attempt to use or hack Facebook?

• Private hackers: This is your regular hacking for profit types. They just want to make money by duping consumers. As such, their focus is more on gleaning PII and passwords. Private hackers have also been known to perform extortion.  Here's an example of one hacker who is trying to build a business hacking Facebook (click to BIGGIFY):

• Government-sponsored hackers:  These hackers work for governments with the purpose of advancing some national agenda. They may use Facebook data for military intel purposes, uncover dissidents, and squashing dissention.

• Corporate-espionage hackers: These hackers may work for a certain organization or independently. The independent hackers may attempt to glean sensitive business information over time and then sell it to interested competitors. These hackers are mostly focused on corporate structure, business plans, and gaining enough information which will lead them to access other accounts (for you Girl With a Dragon Tattoo fans, think Lisbeth Salander).
• Hactivists: So far, hacktivists have used Facebook as a means of communication as opposed to a resource for taking data.  For example, Anonymous claims to have taken some “revealing” photos of BART spokesperson Linton Johnson from Facebook.  As hacktivism evolves, this will likely change. For example, we could see Facebook data exposed by hacktivists designed to embarrass individuals or an organization.

In the past, we've discussed, at length, how automated tools are used in all kinds of hacking campaigns.  The Register just published a story on two South Korean men who stole data from the country's two major telcos.  But the real interesting aspect is that:

...the men allegedly developed software designed to harvest personal user information and location data without the knowledge of the user and then sold it on for up to 300,000 won (£168 or $265) per set of information.

Automated tools are getting into the enterprise. We've discussed automated tools in context of the external threat--but here you have its usage by malicious insiders (subcontractors). These folks purchased an online commercial tool, used it to harvest user data and then sold off that data.

Could this be a future trend?  Possibly.  Many organizations have deployed DLP which likely would not have blocked this.  Proper mitigatation against such a threat would require database tools that recognize--and block--aberrant behavior.  In this case, the aberration massive data downloads at inhuman speeds.

A federal court reversed a conviction against a Goldman-Sachs developer who allegedly stole source code.

However, the court is not saying why. The reversal was without explanation; it said an opinion would follow “in due course.”  It looks like this is a case which was a precedence for the digital espionage law, demonstrating that the law itself requires updating:

A crucial issue in the appeal — and a main focus of Thursday’s oral argument — was whether Mr. Aleynikov’s actions constituted a crime under the statutory language of the Economic Espionage Act. The debate centered on whether Goldman’s high frequency trading system was a “product produced for interstate commerce” within the meaning of the law.

This reversal really shows how costly the insider threat is for businesses. Not only did Goldman lose proprietary code, but is now losing the case.  In addition to the fact that they can’t they be compensated for the code loss, Goldman now has deal with heavy legal expenses.

This is an interesting piece. The SC DMV is suffering from constant attacks--90 attacks since the beginning of the year.

The DMV contacted the FBI, since most of the hackers are attacking from foreign countries. The FBI's local cyber-security squad is assisting the DMV to make sure everything possible is being done to protect the DMV database, which contains not only drivers' names and addresses but also Social Security numbers and copies of birth certificates.

Why is this happening?  Possibilities include:

1. Foreign government gathering citizen information.  Though possible, it doesn't seem as likely.
2. It's not necessarily a foreign government, but a foreign entity gathering data.  Why?  The data could be useful for different purposes, such as for spear-phishing and impersonation. This type of information could be helpful for commercial hackers.
3. Data brokers may be stealing this information and simply selling it to whoever may be interested.

State governments sit on good quality data and probably haven't invested a lot in data security.  This makes them an attractive target.

Why the urgency? The vulnerability stems from implementation flaw in the application server code. It is not specific to a particular application and cannot be mitigated through better coding of the application code. Any application built on top of the vulnerable application server (ASP.NET, Java, PHP) is exposed.  

How does this attack work? Applications commonly store HTTP request parameters in a data structure called “hash tables”. These are very common structures as they work, on average, quickly. And that’s the point: on average. If a hacker creates an HTTP request in a particular manner, using many parameters, the “hash table” begins to run in its worst case scenario – which is actually very slow. If hackers slow the server down too much, they can effectively cause a DoS.

Is this a new attack?  It depends on how you look at it. This class of attacks, which exploits the worst case scenario of an algorithm, or a data structure, are called “Algorithmic Complexity Attacks”. As the following list shows, we’ve seen them before. However, as you can see, all these attacks were demonstrated against lower level devices – such as routers or firewall – and not against Web applications:

• The notion of a low-bandwidth attack exploiting an algorithm’s worst case can be traced back to an attack using nested HTML tables. In 1996, Garfinkel showed how some browsers’ algorithms perform super-linear work to determine the layout of the table. Thus, a maliciously crafted web page can cause the browser to freeze
• In 2001, Dean and Stubblefield proposed a solution to an attack against an SSL server that may lead to the paralysis of e-commerce websites. In their scenario, the attacker requests the server to engage in expensive RSA decryptions without first having done any work.
• Another example includes the attack presented in 2004 by Gal A., Probst C and Franz M.  In their work, the attacker takes advantage of the fact that the Java bytecode verification scales quadratically with the size of the program and so keeps the verifier busy in order to constitute a denial of service. The authors develop this notion in order to construct complexity attacks against mobile-code systems.
• In 2003, Crosby and Wallach introduced this family of low-bandwidth denial of service attacks called algorithmic complexity attacks. These attacks exploit algorithms’ worst-case behaviors. Using their method the adversary can create specific inputs that all fall into the same hash bucket, causing the hash table to degenerate into a simple linked list. They successfully carried out their attacks on different applications, such as the IDS, Bro (Paxson, 1999) and several Perl versions. They showed how within 6 minutes they were able to cause the server to consume all of its CPU as well as to drop most of its received packets.

Why should I care that this attack basically “moved up the stack”? This attack is not about using a bunch of bots in order to flood the network. It’s not about causing the network-layer devices – such as routers – to slow down. It’s not even about bringing down network-layer defenses, such as firewalls. It’s all about sending one single Web request specifically crafted – and legit. In fact, the HTTP RFC never put a restriction on the number of parameters so application developers would not necessarily see the request as abnormal. This attack sets to remind us once again how DDoS is moving up the stack.

What can be done to mitigate this threat? The initial recommended solution is to block any HTTP request which has a large number of POST parameters. The suggested threshold is currently set to 1000. Web application firewalls, for instance, can apply such a policy quickly to thwart any attacks before the underlying languages will be patched.

As for the language developers, the researchers who disclosed this attack suggest randomizing hash functions. This type of randomization should also be considered carefully. In 2006, Prof. Avishai Wool and Noa Bar-Yosef showed how under different scenarios and parameters, randomization does not necessarily solve Algorithmic Complexity Attacks. You can read the paper here.

Rumor has it that hackers have obtained the source code for Symantec’s Norton AV. A posting on pastebin presented the file list and hackers are claiming that they also have the code itself. While the code is not yet out, hackers are saying that it is just a matter of time as they are considering how to best publish this information.

As a major DLP vendor, this is quite embarrassing on Symantec’s part. It’s reasonable to assume that the retrieval of such a list could be a result of the files residing on a test server which was mistakenly exposed, or a posting to FTP which unintentionally became public.  It also seems, if you trust the hackers' boasting, that the code was obtained from the Indian military.  Many governments do require source code from vendors to prove the software isn't spyware.  

If the rumors turn out to be true, the implications of the anti-virus code leakage will not keep the Symantec folks awake too late at night, and certainly not their customers. After all, there isn’t much hackers can learn from the code which they hadn’t known before. Why? Most of the anti-virus product is based on attack signatures. By basing defenses on signatures, malware authors continuously write malware to evade signature detection (in 2007, antivirus could only detect between 20-30% of malware). We noted in our blog on the Black Hole Exploit that only 30% of AV would have been effective. Further, malware versions continuously evolve in such a rate where signatures cannot keep up with them in the first place. The workings of most of the anti-virus’ algorithms have also been studied already by hackers in order to write the malware that defeats them. A key benefit of having the source code could be in the hands of the competitors.

If the source code is recent and hackers find serious vulnerabilities, it could be possible to exploit the actual anti-virus program itself.  But that is a big if and no one but Symantec knows what types of weaknesses hackers could find.

Some interesting news from the healthcare industry:  There have been 355 medical data related breaches, involving 10,120,287 records that have been made public since 2010. 

However, the article highlights a survey showing that consumers are in fact pretty practical when it comes to electronic health records:

Despite all this bad news, a recent survey found that such occurrences probably won't temper the trust consumers have in data sharing or using electronic health records. According to a survey of 1,000 consumers conducted by the PwC Health Research Institute, 60 percent of respondents would be comfortable having their health data shared for improving overall care, 54 percent for improving decision-making in their care, and 36 percent to provide data for better analysis of doctor's performance.

That being said, security is a factor in the consumer's mind:

However, only 30 percent of respondents said, if factors such as cost, quality, and access were even among competing providers, clear security and privacy policies would impact their healthcare decisions.

A Symantec global survey of nearly 2,000 SMBs showed that 50 percent did not consider themselves an attack target. Looking at today’s threat landscape, this is a big misconception. If a site is online, regardless of its popularity, it will be targeted.

Why are SMBs attractive to hackers?
Hackers are going after low hanging fruits. These are the companies who are less security aware and do not have the proper defenses in place. According to the 2011 Verizon Data Breach Investigations Report, hackers are increasingly targetting smaller, softer, less reactive organizations since these provide a lower-risk alternative to better-defended financial institutions.

Why would someone want to hack an SMB site (an application or server)?

• Data retrieval. Nearly all data may considered of value to any hacker who can later exchange this data on the cyber-underground. Hot commodities include the usual: credit card numbers, employee details, login credentials.
• Malware hosting. Hackers hack legitimate sites to host malware on them. Visitors to these compromised sites may then unknowingly download the malware. The benefit to hackers is that they do not need to setup their own server. More importantly, since these sites are legitimate, it avoids the suspicions raised from dubious sites.
• Compromising the company’s servers. A server under the hacker’s control, can be used to carry out further attacks against other targets. The hacker gains a couple of advantages. First, the hacker does not attack the target directly thus concealing their identity behind a legitimate server. Second, attacks originating from servers are powerful. In fact, as we've described in the past, one compromised server is equivalent to 3,000 compromised PCs under the hacker’s control.

How do hackers find an SMB site to hack?
Hackers are increasingly leveraging search engines such as Google, Yahoo! or Bing to scan the Web for vulnerable sites. With a list of potentially vulnerable resources, the attacker can create, or use a ready-made, script to exploit vulnerabilities in the pages retrieved by the search campaign. In August 2011 USA Today reported that 8 million websites, mostly belonging to small companies, were infected and hosting malware. In this case, the hackers used the technique of “scan and exploit” in order to conduct such a massive attack campaign within such a short period of time.

How can SMBs protect their sites?
Attacks today are completely opportunistic in nature. Organizations can overcome these threats, by introducing different security measures into the systems:

• Placing security devices on site. For example, placing a Web Application Firewall (WAF). A WAF is a device which inspects incoming traffic targeted at the application and alerts on malicious traffic. WAFs may or may not be combined with application vulnerability scanners which test the application itself for known vulnerabilities. However, these tools usually prove to be too costly for SMBs.

• Building secure application code. This will solve the root cause of the issues. However, many SMBs are reluctant to choose this path as returning the code to development is expensive: it requires developers who are more experienced with security, delayed releases, and is a never-ending process.

• Using the cloud to provide security. Different offerings exist which allow traffic to be re-routed via a security offering in the cloud. These services sift out the bad traffic from the good so that eventually only the good traffic arrives at the application. This is usually the preferred choice for SMBs as cloud offerings are cheaper and are usually provided as subscription-based services based on traffic throughput. 

We discussed what does not work to mitigate the insider threat. But what works? We lay out here three separate processes that should be placed, and used in conjunction, at the workplace:

1. Technical solutions
2. Human Resources
3. User Education

This blog will first detail six key technical solutions:

1. Monitor access to data stores

The company’s digital assets are stored in databases and file servers. It is safe to assume that client side protections are unreliable against malicious or compromised insiders. Therefore any effective mitigation plan must start by centrally monitoring access at the data source. Monitoring serves two purposes: detecting, in a timely manner, abusive or unauthorized access and keeping a detailed audit trail of important events. Organizations maintain huge quantities of digital information in their data stores. Achieving effective security requires that most attention be given to those parts of the data store that contain the most sensitive information and to those pieces of information that are most sensitive for the organization. In other words, the amount of protection effort and data collection should be proportional to the value of the information. Thus, effective deployment of monitoring comprises the following stages: find the data to focus on, set up policies to detect abusive or unauthorized access and set up logging policies.

a)     Find the data to focus on

This requires the mapping of obvious data reservoirs in order to deploy the necessary security controls around.

In the case of structured data (such as databases), it is further possible to drill down and pinpoint those database tables which contain the sensitive information. For example, tables holding transaction details, employee information, credit card numbers, etc. Once these tables have been located, the security focus should be on them. This is made possible because database tables don’t tend to change their role over time and changes to database structure are usually performed by a central authority (DBA).

The case is somewhat more complex with unstructured data (e.g., files) where static classification is not a viable option (see “What’s not working”). File contents may change over time and are managed in a distributed (“collaborative”) manner by individual users. Additionally, metadata and file properties seldom attest for the sensitivity of the file’s contents.

b)     Set up policies to detect abusive or unauthorized access

Once sensitive data stores have been identified, activity of these servers can be monitored. Together with information about the business role of individuals this information can be correlated to detect abnormal (odd) and abusive access patterns. These patterns can be defined as violations of corporate policies, deviations from normal behavior or clear traces of known attacks. Detection of an abusive pattern should generate an alert and in some extreme cases, blocking of the detected access requests should be applied.

Given the variety of methods that must be used in order to detect conspicuous data access, a robust solution must be able to monitor all activity and apply detection mechanisms to it. This approach is effective, as opposed to choosing in an a priori manner the specific activities to monitor in hope to find the traces of abuse within that activity.

In order to create an effective detection mechanism the monitoring solution must extend its knowledge about each transaction, beyond the standard definition of when, who and what. For example, the “who” part of the information should include information not only about the name of the individual but also about that individual’s organizational role. The “what” portion of the information should be extended to include not only operation and table name but the entire SQL statement, values of bind variables and the amount of extracted data. In some cases, “what” may also reflect the actual data records that have been accessed (e.g. VIP records in a hospital system). Additionally, the concept of “how” should be introduced, depicting attributes such as the client application, the machine used for accessing and rate of access.

By combining the above capabilities it is possible to set up policies that detect odd and abusive patterns such as the following:

-Accessing unusual volumes of data.
-Unusual number of failed access attempts.
-Access to sensitive data outside of normal business hours.
-Access to sensitive data from unusual machines or IP addresses.

Anomaly detection mechanisms traditionally rely on either black-listing some behaviors (defining attack patterns, setting up corporate policies) or on white-listing all allowed behaviors. Black listing has many disadvantages that are exacerbated in the insider threat domain. Mainly, black-listing is limited to detecting expected bad behaviors. Pure white-listing approach is limited to those environments in which activity shape is very strict. If used in internal environments as the only criteria, white-listing detection can generate a lot of noise. However, combining black-listing and white-listing into a single detection mechanism attributes to a more accurate solution, one that is fit for the insider threat. As an example, one possible definition of “anomaly” is access outside of the “white-listed” behavior that occurs outside of business hours

c)     Setting up an audit trail policy

The audit trail is obviously required for regulatory purposes but also serves to investigate and contain incidents post-mortem. As such, the audit trail must contain more information than required for the timely detection of a breach. At the same time, massively recording unnecessary information affects the ability of an organization to perform an efficient post mortem analysis of a breach. For example, we have seen cases in which organizations opted to an “audit all” policy, but the prohibitive costs of storage forced the administrator to reclaim old record storage for new records. As a consequence, in the event of a breach the amount of information available for analysis becomes very limited in timeframe. The audit trail must record all the information available for the monitoring solution, as discussed in the previous section.

Log collection policies are usually set up in a static manner. Examples of important static policies are:

-Record all changes to database structure
-Record all permission changes on files
-Record all retrieval activities of sensitive data
-Record all data access by users from the IT department

It is important for a monitoring solution to provide capabilities of setting dynamic log collection policies. These are policies that are triggered based on some unusual event and then collect data that is relevant to the event. Usually, dynamic collection policies should trigger based on anomalies detected by the previously mentioned policies. Then, they should proceed to collect all the events on the same session that triggered the anomaly, or even on all sessions by the same user who triggered the anomaly.

2.    Enforce segregation of duties

At a business level, the concept of segregation of duties prohibits, for instance, the individual who orders invoices to also confirm the invoices. This simple concept prevents issues such as fraud as in the case where an Ofcom IT director created false invoices sent to him.

At a technical level, the database or system administrator should not be allowed to change, or bypass, the system’s security controls. For example, the database administrator should not be the one permitted to turn off auditing.  In other words, make sure who’s watching the watchdogs.

From a practical perspective, it implies that at least some parts of the monitoring solutions must be implemented outside the control of a single database or system administrator.

3.    Avoid careless distribution of sensitive data

One of the classic manifestations of careless insider is inadvertently placing containers of sensitive data on public facing servers. Only recently, the University of York inadvertently exposed student details when the student records were left on a test area of the university’s website. Another prominent process through which sensitive data finds its way to the wrong hands within the organization is duplication of production data to be used by developers and QA engineers.

There are a few processes that should be put in place in order to avoid such careless distribution of sensitive data:     

• Put detection policies in place (using the data source monitoring solution) to depict move of sensitive data to public facing servers.
• Regularly schedule “clean ups”. Every once in a while, a clean-up should be scheduled in order to verify that no sensitive data resides in these publicly accessible servers.
• Periodically look for new data stores that hold sensitive data. Tools exist today to assist in the task of detecting database servers in the network and classifying their contents.
• Put processes and tools in place to perform data masking on production data before delivering it to QA or engineering. Masking is a non-trivial transformation of the data that maintains a lot of its original qualities while removing most of the sensitive qualities of it. Masking solutions are able to consistently replace pieces of sensitive information like individual names, personal identifiers and even amounts across an entire data set (and sometimes across multiple, correlated data sets).

4.    Reduce the amount of stored sensitive data

The motivation here is simple – lower the odds. The less sensitive information there is, the smaller the probability of it getting lost and the higher chances to control access to it. This step mainly conforms to structured data (i.e., databases), while equivalent solutions for unstructured data are still lacking.

While schema normalization (i.e., making sure each piece of information is stored only once in the database) is the first lesson to be taught in Databases 101, rarely do we see in practice enterprise environments that adhere to it vigorously. Consequently, it is not easy to reduce the amount of sensitive information without invoking major design changes in deployed applications. For example, reducing the number if stored instances of SSN for example in an environment where the SSN is used as a key identifier for various database objects is bound to impact all applications that access the database. Some specialized solutions named “tokenization” solutions are offering an alleged simpler path to reducing the number of stored instances for specific types of data (mainly credit card numbers in the context of PCI). These solutions offer to replace existing instances of credit card numbers within the database with a token that references a single secure storage either on premise or in the cloud. Still migrating applications to work with the new tokens may prove to be a daunting task.

Common sense is a powerful tool in reducing the pain of storing sensitive data. For example, many smaller vendors have chosen to completely avoid any storage of payment information by outsourcing the entire payment process to a 3^rd party service provider. In other cases, carefully choosing the necessary data to collect proves to be the right way to avoid unnecessary data breach.

5.    Periodically assess user and access management

There are a few measures to consider here:

a)     Identify and remove excessive rights.

While it is evident that the problem of excessive rights is not going to disappear, there are processes that can be followed. This will allow the identification of obvious cases where excessive rights can be eliminated. Examples include:    

-Access privileges to sensitive objects granted to all users.
-Privileges assigned to users per their previous roles in the organization.
-Administrative privileges granted to non-administrators.

The right solution to apply for identifying excessive rights must be able to correlate the access control information with the organizational role of individuals and should contain preset policies based on industry benchmarks (e.g. DISA STIG).

b)    Enforce proper authentication policies

Enforce the use of strong passwords across enterprise systems. Where appropriate, enforce the use of two factor authentication. The use of TFA enforces strong personal accountability and eliminates the threat of credential theft.

c)     Clean up unused (dormant) accounts and privileges

Policies should be put in place to disable employee accounts upon departure. Within a defined time frame these dormant accounts should be removed with all objects changing ownership. Policies should also be defined for the removal of redundant privileges as employees move between different roles within the organization.

At the same time, a process should be put in place to correlate between existing account and privileges and actual usage (as depicted by the monitoring solution) to identify inactive accounts and redundant privileges.

6.    Encrypt backup data

Backup data is a condensed and mobile instantiation of the enterprises sensitive assets. Its format makes it inherently susceptible to loss and theft. Making sure that these copies of sensitive data are encrypted ensures their safety in the case of falling to the wrong hands.

As shown in the section “What does not work?”, the point here is not to encrypt the data in the database, or the transport encryption. Rather, this is data on backup media: data taken directly from the database or data encrypted on the user’s end-machine. Such a measure lowers the risk of data exposure in the case of a lost or stolen device. 

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.