The TEN Commandments of Facebook

Posting certain photos or information on the site puts you at risk of being fired, a victim of crime, or even worse. There are computer programs called 'data mining' that sweep Facebook to collect dates of birth, phone numbers, addresses etc. Here are the things you should never post on Facebook.

Date and place of birth: This places you at massive risk of identity theft. They are the most commonly used security questions on password resetting sites.

Mother's maiden name: A lot of sites use your mother's maiden name to authenticate who you are. They also commonly use the school you went to as a security question.

Address: It again puts you at risk from identity fraud, but also from burglars and stalkers.

Holidays: Don’t put any update about your holiday or outing that means you are basically saying: "Come and rob me."

Short trips away from home: Again, this can put you at risk of burglary and stalking.

Inappropriate photos: Don't post racy, illicit, offensive or incriminating photos. Bosses and prospective employers are increasingly looking at Facebook pages.

Confessionals: These can also get you fired or haunt you for the rest of your life.

Phone number: Unless you want to be bombarded with unsolicited phone calls from people trying to sell you something don't.

Children's names: These can be used by identity fraudsters or, more sinisterly, by paedophiles. It is much easier to steal a child's identity.

Don't post a full public profile: It won't just exist on Facebook, it will go on any internet search such as Google. Only give the bare bones such as a name. Keep everything else private.

The TEN Most Common Database Vulnerabilities

Protecting databases is hardly an easy task, but it is often the attacks that go after the simplest vulnerabilities that are most successful.

The common thread in this list is that databases security and their configuration is not a fire-and-forget operation for database administrators. Organizations must continually assess packages to determine if they are really necessary and disable those they don't need to reduce attack surfaces. They need to be vigilant about keeping on the lookout for default or weak log-in credentials. They have to put sound privilege and authentication practices into play. And most important, they need to patch regularly.

1. Default, Blank, and Weak username/password

It might be a daunting task at an organization that has to keep track of hundreds or even thousands of databases. But removing default, blank and weak log-in credentials is an important first step to change your database default username/passwords. The bad guys are keeping track of default accounts, and they'll use them when they can.

2. SQL injections

When your database platform fails to sanitize inputs, attackers are able to execute SQL injections similar to the way they do in Web-based attacks, eventually allowing them to elevate privileges and gain access to a wide spectrum of functionality. A lot of vendors have released fixes to prevent these problems, but it won't do much good if your DBMS remains unpatched with latest updates.

3. Extensive User and Group Privileges

Organizations need to ensure privileges are not given to users who will eventually collect them like janitors collect keys on their key chains. Which can be managed collectively more easily than if users were assigned direct rights.

4. Unnecessarily Enabled Database Features

Every database installation comes with add-on packages of all shapes and sizes that are mostly going to go unused by any one organization. Since the name of the game in database security is to reduce attack surfaces, enterprises need to look for packages that don't use and disable or uninstall them. This not only reduces risks of attacks through these vectors, but it also simplifies patch management.

5. Broken Configuration Management

Similarly, databases have many different configuration choices and considerations available to DBAs to fine tune performance and enhanced functionalities. Organizations need to be on the lookout for unsafe configurations that could be enabled by default or turned on for convenience of DBAs or application developers.

6. Buffer overflows

Another hacker favorite, buffer overflow vulnerabilities, are exploited by flooding input sources with far more characters than an application was expecting say, by adding 100 characters into an input box asking for a SSN. Database vendors have worked hard to fix the glitches that allow these attacks to occur. This is yet another reason why patching is so critical.

7. Privilege Escalation

Similarly, databases frequently sport common vulnerabilities that allow attackers to escalate privileges within a little known and low privilege account and gain access to administrator rights. As these vulnerabilities are uncovered, administrators need to reign them in with timely updates and patching.

8. Denial of Service (DoS) Attack

SQL Slammer provided a very illuminating illustration of how attackers can use DBMS vulnerabilities to take down database servers through a flood of traffic.

9. Unpatched Databases

This could be repetitive, but it bears repeating. So many database administrators don't patch in a timely fashion because they're afraid a patch will break their databases. But the risk of getting hacked today is way higher than the risk of applying a patch that will go haywire. That might not have been true five years ago, but vendors have become much more rigorous with their testing.

10. Unencrypted Sensitive Data at rest and in motion

Perhaps it is a no brainer, but organizations should never store sensitive data in clear text within a database table. And all connections to the database should always use encryption.

Safe E-mail Usage Sending

Sending mail is a little more care free. There are some things you can do to make sure your conversation is secure though. The first is to ensure your connection is secure. There are also methods to allow you to digitally sign your messages, which guarantees that the message is from you and has not been tampered with en route. And for maximum security, you can encrypt your messages to make sure no one reads them. Digital signatures prove who e-mail comes from, and that it has not been altered in transit. If you establish the habit of using digital signatures for important e-mail, you will have a lot of credibility if you ever need to disown forged mail that appears to be from you. They also allow you to encrypt e-mail so that no one can read it except the recipient. PGP in particular offers high levels of encryption which to break would require extreme computing power.

Digital Certificates
A digital certificate is unique to an individual, kind of passport, and is composed of two parts. These two parts are called as public and private key. The certificate is unique to one person, and typically certificates are issued by a trusted Certificate Authority, or CA. The list of Certificate Authorities you trust is distributed automatically (if you are a Microsoft Windows User) by Windows Update and the list is accessible in your browser under tools>internet options>content>certificates. You can go here to view certificates installed on your machine (yours and others), and other certificate authorities you trust. You can disable the automatic update of CAs, and choose to remove all CAs from the list, although this is not recommended. Instructions on how to do this are on Microsoft’s web site.


Digital Signatures
A digital signature is generated by your e-mail software and your private key to assure the authenticity of your e-mail. The purpose of the signature is twofold. The first is to certify it came from you. This is called non-repudiation. The second is to ensure the contents have not been altered. This is called data integrity. The way an e-mail program accomplishes this is by running the contents of your message through a one way hash function. This produces a fixed size output of your e-mail called a message digest. This is a unique value, and if the mathematical algorithm that produces it is strong, the message digest has the following attributes.

• The original message can’t be reproduced from the digest.
• Each digest is unique.

After the digest is created, it is encrypted with your private key. The encrypted digest is attached to the original message along with your public key. The recipient then opens the message, and the digest is decrypted with your public key. The digest is compared to an identical digest generated by the recipients’ mail program. If they match, then you’re done. If not, your mail client will let you know the message has been altered. There are two types of signing / encryption functions, S/MIME and PGP. S/MIME is considered to be the corporate and government choice, possibly because it uses the less labor intensive certificate authority model for authentication, and because it is more easily implemented through Microsoft's Outlook Express e-mail program. PGP is more often the choice of the computer user community, because it is based on a non-centralized web of trust for authentication, where a user's trustworthiness is validated through the 'friend of a friend' system, where you agree that, if you trust me, then you can also trust those people who I trust.