Browser Crash May Leads to Bank Account Compromise

Microsoft DNS Logging Feature

Troubleshooting network problems can be a nightmare, especially if you don't know where to begin. Microsoft provides some tools that can help you in this situation. One feature that Microsoft built into almost every service is logging. Logging allows you to log the service activity and, thus, find out what's going on behind the scenes. 

A service that supports logging is the DNS service, which allows you to specify which messages you want to log. For instance, you may only want to log queries, updates, or answers.

Debug logging can be useful, but you shouldn't use it in day-to-day operations on production servers. Logging will have an impact on the performance of your servers, depending on how many options you select. So don't enable this option simply because you can, and once you do enable it, select as few options as possible.

To start debugging logging, open the DNS console by going to Start | Programs | Administrative Tools | DNS. In the console, right-click on your DNS server name and select Properties. Go to the Logging tab; you'll notice several debug logging options.

After enabling an option (e.g., queries), you'll have to wait quite a while for the DNS service to start logging. Microsoft left a bug in the user interface, so the system won't log anything if you select only queries or any other option. Before the logging will start, you have to enable logging of UDP or TCP (or both) protocols. Now the DNS service will log everything in the Dns.log file located in the %SystemRoot%\System32\dns folder.

Cell phone Hacked ? (Panic .......)

6 year ago accessing the voice mail of some once else cell phone was fun for me. Now 6 year down the line being in security profession I consider it as crime. But recently I come across a case where the data from smart phone was compromised.

What data?

Yes data which include your emails, sms, calendars, events, logs , notes and more over if you are accessing your bank account some of the vital information about that too. Ya don’t you think that if these information goes in the wrong hands can cost you a lot of pain, money, and heartache. Again, hopefully you phone is never hacked, but you should be aware that it is possible.

How does it sound to you?

Scary, Yes I am having same feeling and scared now. Since my cell phone is my universe around me. That’s a human nature some of the events bound us to think about the objects or subjects which is very obvious for us and we never thought about it.

Since then I started thinking about

What needs to be done if I am thinking my cell phone is hacked?

What should I avoid if I am not interested to allow anyone to hack my personal data?

Research gave me fair idea but; again memory full so it’s better to share before it’s dropped from my memory. Might be 6 year down the line someone will give me my tips back to me with addition of his findings.

First what facilitate hacking of your cell phone by others?

1. Open source freely distributable cell phone tracking software. (Used for tracking the lost/stolen cell). These apps are having ability to read the most sensitive information and pass a feed to server. Wow I never thought that how come this feature can be exploited to gain the information from others. Are you?

2. Integrating your personal device with for official work aha (BYOD). Gotcha one pit fall of BYOD. (Can’t you think that if organization is taking a declaration that they are authorised to wipe a data on your device if they feel that organisation data is compromised). If I have access of such server which is pushing these policies I would definitely love to see some of the communications of selective people.

3. Downloading the trial version of applications for your device. (could be malicious too)

How I will get to know that my cell phone is hacked?

Ticking Noises – If someone is tapping into your conversations, you could hear some ticking noises in the background as the device works. These are typically the devices that have to be implanted into the phone or near it. Technology is moving quickly beyond this requirement, but it is possible.

Disrupting Sounds – This can be difficult to decipher because many cell phone providers are so crappy these days. You can’t really tell if that is your provider’s network messing up, but you should be aware of these sorts of sounds. They could be someone listening into your conversation.

Abrupt Disconnections - If your phone typically doesn’t drop calls, but all of a sudden you are experiencing it more than normal, then you may be hacked. Again, depending on your wireless provider, this could be common, but hopefully you have a network worth staying with. If not, then switch.

Accounts Tampered With – If your accounts have been tampered with, then you know something is wrong. This could be your bank account, facebook account, or anything else. Inconsistencies mean someone is in your phone, computer, or has direct access to your information. It is time to change passwords and make sure you cut off the source.

What should I do if my cell phone is Hacked?

1. First of all need to change all the passwords and everything to them, not using your phone. Go into the institutions and get this done in person. You cannot allow this situation to spill over into your money. (Bank account, email, Facebook, LinkedIn etc. etc.)

2. Disconnect all the data connection and if possible change the sim to decade old cell phones.

3. Next you need to take your phone into your provider and have them run a diagnostic test on the phone. Your provider should be able to spot any sort of hacking program on the phone and make sure it is eliminated/not eliminated if you are interested to sue the person or organization who is responsible for this.

4. If you are interested to file a law suit take cell phone as is for forensics and get the evidences of hacking. (In lot of countries these evidences are considered as secondary evidence and can be produced alone in court of law)

5. Format and reload the cell phone OS (Again not from same PC where you regularly connect this cell phone.)

6. Delete all the backup data of cell phone from your PC or laptop.

7. Install only most required and useful apps only.

8. Regularly monitor usage of installed app on your cell phone.

9. Avoid rooting or jailbreaking.

How to prevent my cell phone to be Hacked?

Let’s start from very basics

1. Use complex passwords.

2. Don't share your phone passwords with anyone at work or in social contexts. Shield input of passwords when in public.

3. Disable Voice Mail (Why you need a voice mail on Cellphones?). It’s always with you and if you are not available you are genuinely not available.

4. Don’t use the same password for all your phone accounts.

5. Update your phone password as often as possible.

6. Disable Bluetooth and if it’s required avoid discoverable mode.

7. Install reputable security software on the phone

8. Do not integrate your very personal devices with your organization systems.

9. Keep your cellphone always with you.

10. Disable cookies, flash, javascript, and other extension within the mobile browser.

11. Do not remember the password on browser and applications.

12. Avoid unsigned applications downloading.

13. Monitor the applications usage installed on your cell regularly. (If you feel that any of the apps not used by you and it’s showing in recently used list investigate it.)

14. Very important segregate the personal and official cellphones.

Be secure be happy :)

Good SVP National Police Academy Refer My Blogs !!!!!!

Getting a good feeling that in National Police Academy of India my bogs are getting referred. Hope in next 5 years good number of IPS would know me by name.

Also feeling good that some of my write-ups and article is useful for such a prestigious organization in India.

I got to know about it today when I was trying to analyse the audience of my blog and their interest.

But yes it's happened when I left India after getting a huge pain and trauma from Police Department and Regional Passport Office of Hyderabad.

Keeping it for my memories.

Which DLP Solution is Better for VDI

That's a Nice Topic, isn’t ?

I am getting lots of mail on advising them which solution is better for VDI.

Network Based DLP or End Point Agent Based?

What's your thought about it?

Will wait for comments on this and then going to publish my opinion.

Hardening the TCP/IP stack to SYN attacks in Linux

Friends,

     Although I am having limited experience in Linux so thought of publishing Solaris Tuning Parameters First. While got lots ofrequest for Linux so compliling the hardning parameters of Linux First. Please feel free to add your comments if some thing I missed in this part.

Linux operating systems, has implemented a SYN cookies mechanism which can be enabled in the following way:

# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Note that to make this change permanent we need to create a startup file that sets this variable. We must do the same operation for other UNIX variables described because the values for these variables will return to default upon system reboot.

SYN cookies protection is especially useful when the system is under a SYN flood attack and source IP addresses of SYN packets are also forged (a SYN spoofing attack). This mechanism allows construction of a packet with the SYN and ACK flags set and which has a specially crafted initial sequence number (ISN), called a cookie. The value of the cookie is not a pseudo-random number generated by the system but instead is the result of a hash function. This hash result is generated from information like: source IP, source port, destination IP, destination port plus some secret values. During a SYN attack the system generates a response by sending back a packet with a cookie, instead of rejecting the connection when the SYN queue is full. When a server receives a packet with the ACK flag set (the last stage of the three-way handshake process) then it verifies the cookie. When its value is correct, it creates the connection, even though there is no corresponding entry in the SYN queue. Then we know that it is a legitimate connection and that the source IP address was not spoofed. It is important to note that the SYN cookie mechanism works by not using the backlog queue at all, so we don't need to change the backlog queue size. More information about SYN cookies can be found at http://cr.yp.to/syncookies.html.

Also note that the SYN cookies mechanism works only when the CONFIG_SYNCOOKIES option is set during kernel compilation.

A tcp_max_syn_backlog variable defines how many half-open connections can be kept by the backlog queue. For instance 256 is a total number of half-open connections handled in memory by Linux RedHat 7.3. The TCP/IP stack variables can be configured by sysctl or standard Unix commands. The following example shows how to change the default size of the backlog queue by the sysctl command:

# sysctl -w net.ipv4.tcp_max_syn_backlog="2048"

A tcp_synack_retries variable is responsible for controlling the number of retransmissions in Linux operating system. Its default value is set to 5 for most Linux operating systems, which causes the half-open connection to be removed after 3 minutes. In the below table there are calculations for other values.

# sysctl -w net.ipv4.tcp_synack_retries="2048"

Value	Time of retransmission	Total time to keep half-open connections in the backlog queue
1	in 3rd second	9 seconds
2	in 3rd and 9th second	21 seconds
3	in 3rd , 9th and 21st second	45 seconds

Hardening the TCP/IP stack to SYN attacks in Windows

All of us know how problematic protection against SYN denial of service attacks can be. Several methods, more or less effective, are usually used. In almost every case proper filtering of packets is a viable solution. In addition to creating packet filters, the modification of the TCP/IP stack of a given operating system can be performed by an administrator.

While SYN attacks may not be entirely preventable, tuning the TCP/IP stack will help reduce the impact of SYN attacks while still allowing legitimate client traffic through. It should be noted that some SYN attacks do not always attempt to upset servers, but instead try to consume all of the bandwidth of your Internet connection. This kind of flood is outside the scope.

What can an administrator do when his servers are under a classic, non-bandwidth flooding SYN attack? One of most important steps is to enable the operating system's built-in protection mechanisms like SYN cookies or SynAttackProtect. Additionally, in some cases it is worth tuning parameters of the TCP/IP stack. Changing the default values of stack variables can be another layer of protection and help better secure your hosts. We will concentrate on:

           •           Increasing the queue of half-open connections (in the SYN RECEIVED state).

           •           Decreasing the time period of keeping a pending connection in the SYN RECEIVED state in the queue.

Which is accomplished by decreasing the time of the first packet retransmission and by either decreasing the number of packet retransmissions or by turning off packet retransmissions entirely. The process of packet retransmissions is performed by a server when it doesn't receive an ACK packet from a client. A Packet with the ACK flag finalizes the process of the three-way handshake.

Note that an attacker can simply send more packets with the SYN flag set and then the above tasks will not solve the problem. However, we can still increase the likelihood of creating a full connection with legitimate clients by performing the above operations.

We should remember that our modification of variables will change the behavior of the TCP/IP stack. In some cases the values can be too strict. So, after the modification we have to make sure that our server can properly communicate with other hosts. For example, the disabling of packet retransmissions in some environments with low bandwidth can cause a legitimate request to fail.

We will discuss tuning parameters for Microsoft Windows first 

These variables are similar or the same in current releases.

Definitions: SYN flooding and SYN spoofing

A SYN flood is a type of Denial of Service attack. We can say that a victim host is under a SYN flooding attack when an attacker tries to create a huge amount of connections in the SYN RECEIVED state until the backlog queue has overflowed. The SYN RECEIVED state is created when the victim host receives a connection request (a packet with SYN flag set) and allocates for it some memory resources. A SYN flood attack creates so many half-open connections that the system becomes overwhelmed and cannot handle incoming requests any more.

To increase an effectiveness of a SYN flood attack, an attacker spoofs source IP addresses of SYN packets. In this case the victim host cannot finish the initialization process in a short time because the source IP address can be unreachable. This malicious operation is called a SYN spoofing attack.

We need to know that the process of creating a full connection takes some time. Initially, after receiving a connection request (a packet with SYN flag set), a victim host puts this half-open connection to the backlog queue and sends out the first response (a packet with SYN and ACK flags set). When the victim does not receive a response from a remote host, it tries to retransmit this SYN+ACK packet until it times out, and then finally removes this half-open connection from the backlog queue. In some operating systems this process for a single SYN request can take about 3 minutes! 

            The other important information to know is that the operating system can handle only a defined amount of half-open connections in the backlog queue. This amount is controlled by the size of the backlog queue. For instance, the default backlog size is 256 for RedHat 7.3 and 100 for Windows 2000 Professional. When this size is reached, the system will no longer accept incoming connection requests.

How to detect a SYN attack

It is very simple to detect SYN attacks. The netstat command shows us how many connections are currently in the half-open state. The half-open state is described as SYN_RECEIVED in Windows and as SYN_RECV in Unix systems.

# netstat -n -p TCP

tcp        0      0 10.100.0.200:21            237.177.154.8:25882     SYN_RECV    -

tcp        0      0 10.100.0.200:21            236.15.133.204:2577     SYN_RECV    -

tcp        0      0 10.100.0.200:21            127.160.6.129:51748     SYN_RECV    -

tcp        0      0 10.100.0.200:21            230.220.13.25:47393     SYN_RECV    -

tcp        0      0 10.100.0.200:21            227.200.204.182:60427   SYN_RECV    -

tcp        0      0 10.100.0.200:21            232.115.18.38:278       SYN_RECV    -

tcp        0      0 10.100.0.200:21            229.116.95.96:5122      SYN_RECV    -

tcp        0      0 10.100.0.200:21            236.219.139.207:49162   SYN_RECV    -

tcp        0      0 10.100.0.200:21            238.100.72.228:37899    SYN_RECV    -

..

We can also count how many half-open connections are in the backlog queue at the moment. In the example below, 769 connections (for TELNET) in the SYN RECEIVED state are kept in the backlog queue.

# netstat -n -p TCP | grep SYN_RECV | grep :23 | wc -l

769

The other method for detecting SYN attacks is to print TCP statistics and look at the TCP parameters which count dropped connection requests. While under attack, the values of these parameters grow rapidly.

In this example we watch the value of the TcpHalfOpenDrop parameter on a Sun Solaris machine.

# netstat -s -P tcp | grep tcpHalfOpenDrop

        tcpHalfOpenDrop     =   473

It is important to note that every TCP port has its own backlog queue, but only one variable of the TCP/IP stack controls the size of backlog queues for all ports.

The backlog queue

The backlog queue is a large memory structure used to handle incoming packets with the SYN flag set until the moment the three-way handshake process is completed. An operating system allocates part of the system memory for every incoming connection. We know that every TCP port can handle a defined number of incoming requests. The backlog queue controls how many half-open connections can be handled by the operating system at the same time. When a maximum number of incoming connections is reached, subsequent requests are silently dropped by the operating system.

As mentioned before, when we detect a lot of connections in the SYN RECEIVED state, host is probably under a SYN flooding attack. Moreover, the source IP addresses of these incoming packets can be spoofed. To limit the effects of SYN attacks we should enable some built-in protection mechanisms. Additionally, we can sometimes use techniques such as increasing the backlog queue size and minimizing the total time where a pending connection in kept in allocated memory (in the backlog queue).


Increasing the backlog queue

Under a SYN attack, we can modify the backlog queue to support more connections in the half-open state without denying access to legitimate clients. In some operating systems, the value of the backlog queue is very low and vendors often recommend increasing the SYN queue when a system is under attack.

Increasing the backlog queue size requires that a system reserve additional memory resources for incoming requests. If a system has not enough memory for this operation, it will have an impact on system performance. We should also make sure that network applications like Apache or IIS can accept more connections.


Decreasing total time of handling connection request

As we know, SYN flooding/spoofing attacks are simply a series of SYN packets, mostly from forged IP addresses. In the last section we tried to increase the backlog queue. Now that our systems can handle more SYN requests, we should decrease the total time we keep half-open connections in the backlog queue. When a server receives a request, it immediately sends a response with the SYN and ACK flags set, puts this half-open connection into the backlog queue, and then waits for a packet with the ACK flag set from the client. When no response is received from the client, the server retransmits a response packet (with the SYN and ACK flags set) several times (depending on default value in each operating system) by giving the client a chance to send the ACK packet again. It is clear that when the source IP address of client was spoofed, the ACK packet will never arrive. After a few minutes the server removes this half-open connection. We can speed up this time of removing connections in the SYN RECEIVED state from the backlog queue by changing time of first retransmission and by changing the total number of retransmissions.

Another technique of protection against SYN attacks is switching off some TCP parameters that are always negotiated during the three-way handshake process. Some of these parameters are automatically turned off by mechanisms described in the first section (SynAttackProtect and Syncookies).

Now, I will describe TCP/IP stack variables which allow a decrease in the time half-open connections are kept in the backlog queueBuilt-in protection mechanisms of Windows

The most important parameter in Windows  is SynAttackProtect. Enabling this parameter allows the operating system to handle incoming connections more efficiently. The protection can be set by adding a SynAttackProtect DWORD value to the following registry key:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

In general, when a SYN attack is detected the SynAttackProtect parameter changes the behavior of the TCP/IP stack. This allows the operating system to handle more SYN requests. It works by disabling some socket options, adding additional delays to connection indications and changing the timeout for connection requests.

When the value of SynAttackProtect is set to 1, the number of retransmissions is reduced and according to the vendor, the creation of a route cache entry is delayed until a connection is made. The recommended value of SynAttackProtect is 2, which additionally delays the indication of a connection to the Windows Socket until the three-way handshake is completed. During an attack, better performance in handling connections is achieved by disabling the use of a few parameters (these parameters are usually used by the system during the process of creating new connections). The TCPInitialRTT parameter, which defines the time of the first retransmission, will no longer work. It's impossible to negotiate the window size value. Also, the scalable windows option is disabled on any socket.

As we can see, by enabling the SynAttackProtect parameter we don't change the TCP/IP stack behavior until under a SYN attack. But even then, when SynAttackProtect starts to operate, the operating system can handle legitimate incoming connections.

The operating system enables protection against SYN attacks automatically when it detects that values of the following three parameters are exceeded. These parameters are TcpMaxHalfOpen, TcpMaxHalfOpenRetried and TcpMaxPortsExhausted.

To change the values of these parameters, first we have to add them to the same registry key as we made for SynAttackProtect.

The TcpMaxHalfOpen registry entry defines the maximum number of SYN RECEIVED states which can be handled concurrently before SYN protection starts working. The recommended value of this parameter is 100 for Windows 2000 Server and 500 for Windows 2000 Advanced Server.

TcpMaxHalfOpenRetried defines the maximum number of half-open connections, for which the operating system has performed at least one retransmission, before SYN protection begins to operate. The recommended value is 80 for Windows 2000 Server, and 400 for Advanced Server.

The TcpMaxPortsExhausted registry entry defines the number of dropped SYN requests, after which the protection against SYN attacks starts to operate. Recommended value is 5.

Aside from described above TcpMaxHalfOpen and TcpMaxHalfOpenRetried variables, in Windows the number of connections handled in the half-open state can be set through a dynamic backlog. Configuration of this dynamic backlog is accomplished via the AFD.SYS driver. This kernel-mode driver is used to support Windows Socket applications like FTP and Telnet. To increase the number of half-open connections, AFD.SYS provides four registry entries. All of these values, corresponding to AFD.SYS, are located under the following registry key:

HKLM\System\CurrentControlSet\Services\AFD\Parameters

The EnableDynamicBacklog registry value is a global switch to enable or disable a dynamic backlog. Setting it to 1 enables the dynamic backlog queue.

MinimumDynamicBacklog controls the minimum number of free connections allowed on a single TCP port. If the number of free connections drops below this value, then additional free connections are created automatically. Recommended value is 20.

The MaximumDynamicBacklog registry value defines the sum of active half-open connections and the maximum number of free connections. When this value is exceeded, no more free connections will be created by a system. Microsoft suggests that this value should not exceed 20000.

The last DynamicBacklogGrowthDelta parameter controls the number of free connections to be created when additional connections are necessary. Recommended value: 10.

The table below shows the recommended values for the AFD.SYS driver:

Subkey Registry Value Entry      Format  Value

EnableDynamicBacklog             DWORD            1

MinimumDynamicBacklog          DWORD            20

MaximumDynamicBacklog         DWORD            20000

DynamicBacklogGrowthDelta     DWORD           10

In Windows, the default time for a first retransmission is set to 3 seconds (3000 milliseconds) and can be changed by modifying the value of the TcpInitialRtt registry entry (for every interface). For example, to decrease time of a first retransmission to 2 seconds we have to set this registry value to 2000 milliseconds in decimal format. The number of retransmissions (packets with the SYN and ACK flags set) is controlled by a TcpMaxConnectResponseRetransmissions registry parameter which has to be added to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters registry key.

The table below contains a few examples of values and corresponding times for keeping half-open connections in the backlog queue (the time of a first retransmission is set to 3 seconds).

<><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><>

Value	Time of retransmission	Total time to keep half-open connections in the backlog queue
1000	-	1 second
5000	in 2nd second	5 seconds
10000	in 2nd and 5th second	10 seconds
60000	In 2nd, 5th, 11th, 23rd and 47th second	1 minute

Understand Data Loss Prevention System for Deployment

First of all please make a note that DLP is about risk reduction, not threat elimination. It's important to know what kinds of policies can be defined and what enforcement options are available before beginning a deployment. Later, the proper workflow needs to be in place to handle policy violations. While human resources and legal teams are rarely involved in a virus infection, they may be intimately involved when an employee tries to send a customer list to a competitor. Setting up a good baseline early; know what data needs protection, the capabilities of the tools in place to protect it, and the workflow for handling incidents will actually easy the DLP implementation in any organization. The below mentioned Small write-up will help Security Council members to understand what DLP is what are industry best practices adopted by different organization for DLP Implementation.
Basically now data protection efforts of organization are shifting toward the internal users (Vendor/Employee) as compare to external threats like earlier. As 80% of breaches are reported by internal users accidental or intentional only 20% are by external forces. Hence now companies are interested to do the right investment decision and like to protect any potential breached due to their own employees. There are many avenues in which confidential data or proprietary secrets can leave an organization via the Internet:

• Email
• Webmail
• HTTP (message boards, blogs and other websites)
• Instant Messaging
• Peer-to-peer sites and sessions
• FTP

Current firewall and other network security solutions do not include data loss prevention capabilities to secure data in motion. Missing are such important controls as content scanning, blocking of communications containing sensitive data and encryption. While companies have attempted to address the data loss problem through corporate policies and employee education, without appropriate controls in place, employees can (either through ignorance or malicious disregard) still leak confidential company information.


If categorize all the avenues available to employees today to electronically expose sensitive data, the scope of the data loss problem is an order of magnitude greater than threat protection from outsiders. Consider the extent of the effort required to cover all the loss vectors an organization has the potential to encounter:

• Data in motion – Any data that is moving through the network to the outside via Internet.
(Solution provided by: Web-sense, Symantec and CA)
• Data at rest – Data that resides in files systems, databases and other storage methods.
(Solution provided by: Iron port, CA, Vontu)
• Data at the endpoint – Data at the endpoints of the network (e.g. data on USB devices, External drives, MP3 players, laptops, and other highly-mobile devices) (Solution provided  by: Digital Guardian: SOPHOS)

There are two different types of Content Aware DLP solutions available:

1. Single Channel solutions – Focuses on the data loss channel we want to address such as email or Web.
2. Enterprise DLP solutions – Involves lengthy implementations and big budgets. It can also be very disruptive to the organization but delivers much more coverage.

DLP is shipped with hundreds of pre-defined policies. Port authority by WebSense boasts over 140 pre-defined templates for major regulatory statutes. These policies have rules for anywhere from identification of social security numbers to US regulatory laws. The very popular ones are HIPAA, Sarbanes Oxley, GLBA, etc. In addition, vendors are even willing to create a custom policy based on customer requirements. This is based on the business model of a particular customer. Default policies can be fine tuned to suit our needs and gets even more accurate when data matching is applied against context. For Ex. If a payroll employee is observed viewing someone else’s remuneration package, this event is a normal behavior and can be ignored. However, if this event were to occur from another department, the DLP should raise a flag and hence it should be escalated. One key to point to note in writing a signature is the tradeoff between false positives and false negatives. Some vendors call them wide and narrow rules. If the matching occurs at broader scope, it can result in a high number of false positives. On the other hand, we run into the risk of not catching a true positive, if we were to keep the rules too narrow. This is a business decision an organization should make based on the sensitivity level of the content vs. resources allocated for remediation. After all, customers do not want to end up in a similar situation as they are with IDS.

While making a DLP Investment I would advise following points should be considered.

1. Ensure Effective, Comprehensive Coverage :
Means overall, a DLP solution must be able to effectively and comprehensively detect attempted policy violations. This includes:
• Multi-protocol monitoring and prevention
• Content-level analysis of all major file and attachment types
• Selective blocking and/or quarantining of messages
• Automatic enforcement of corporate encryption policies.

2. Make the Solution Unobtrusive:
The next important aspect for a DLP solution is that it’s non-intrusive. Overcoming the challenges of maintaining effective communications (while ensuring management and control of customer and sensitive information) requires both well thought out policies, and processes for monitoring communications content.

3. Should have a Work Flow, Administration and Reporting capabilities:
To help keep total cost of ownership low, the selected product should be simple and fast to implement effectively within the organization’s infrastructure – leveraging plug-and-play capabilities to minimize integration requirements. Robust reporting capabilities allow policy officers to readily access information to:
• Analyze and improve the organization’s DLP capabilities
• Automatically deliver decision-making information in a timely manner
• Easily generate instant reports for executives.

4. Combination of Network/End Point and Heterogeneous.