Security

Response to a social engineering comment

I’ve been trying to think for a bit now as to what I can make a new post about…and with the holidays that ventured and some personal matters, it wasn’t any easier, hah.  But, recently, an individual commented on my social engineering post, and I know I could simply reply to it, but I decided not to.

The comment itself reads:

Good first example, poor oversimplified and subjective second example. The success of social engineering is based heavily not only on the common human being naive but often genuinely interested in helping out someone in need — a need to gain access to information. Unfortunately, it is all to commonly information that they are not privileged to have access to in the first place. The truth is that true security requires people, process and technology. It all begins with education and awareness

I do agree with that social engineering is arguably often due to the intent to help another. That statement, however, also depends on what is trying to be done via this technique. For example, I read on another website recently that a few people got arrested for trying to get a restraunt to give them free food (or something). Now, could the person these people have talked to been trying to just help a fellow human? Possibly. But, either the person was really, really gullable, or the arrestees just got quite lucky, considering they videotaped it and put it on YouTube.

The last three lines I almost 100% agree with. Let me play out two scenarios to bring out both the yay and nay on this.

Lets say your boss has a seperate ID to gain access to a generic ID mailbox (used for FAQ things, spam, whatever need be). Now, the boss has employee A and B who both need access to that mailbox as well. Employee A is more on the educated and aware side, while employee B isn’t. The mailbox isn’t necessarily full of top-secret, CIA-will-arrest-you type of information, but employee B decides that they deem it necessary to forward some mail directed to their boss, to their own mailbox. Did they do anything wrong? Technically no, although you can label this as invasion of privacy, but they did not do anything illegal to get into the mailbox…all the content was readibly available to employee A as well, and the boss. The point that this is trying to make, since I’m not sure if I’m conveying it well enough here, is that not only does “true security requires people, process and technology”, but also trust.

Last scenario…I’ll do this based on what a lot of people at my work do. We get a customer who calls saying that they want the number to this or that technician, or their e-mail, or whatnot…because they missed their call. Now, everyone who works for Ford Motor Company or Ford Credit has access to the same user database as we do, so you feel it’s okay to give out the tech’s contact info. Now, usually we verify that they actually need to talk to this tech by requesting a ticket number or something, but some people don’t worry about that. Now, this scenario doesn’t even require technology or trust, since this can even be done by flipping papers around. But, I do agree that people should be educated and aware of the flaws of not following procedures. Now, in actuality, the procedure for this is to not give them the information anyways, but…that’s a different story.

Well, this is about all that I can think of posting right now. Not exactly a ground-breaking post, but was fun to make none-the-less. I would also like to send a thank you out to the individual who made the comment. You made me start thinking about what I had said in that post, and I agree about the second example.

Encryption and data security

Every company who handles classified information is (or at least should be, logically) concerned about whose eyes are seeing what.  Is password-protecting a file secure?  Sure, just like giving someone a username and password for the computer.  Is encrypting the file secure, as well?  Why yes it is; just as safe as it is to view cookies that store sensitive information.  So how should we eliminate the threat of password-protection and encryption?

Enter TrueCrypt.  Before reading any further, I WOULD NOT recommend reading further if you cannot attempt to use this program if you cannot become root/administrator of your computer.  The reason being is that for Windows, it has to use a driver to create the virtual drive, and that requires administrative rights.  As for root, I’m not sure how TrueCrypt works on *nix-based systems, but their website does state you have to have root privileges.

Okay, so outside of the introduction for TrueCrypt (TC), what’s its purpose?  How does it work?  Why should I even consider it?  Well, I answered #2 in the last paragraph (it creates a drive on Linux as well…which could also explain the root requirement, given most people don’t have write access to /mnt or /dev, I don’t think),  so I will answer the other two with one answer.  Encryption. Now, you’re probably thinking, “wait…didn’t you just say this thing will eliminate the need for encryption?”…well, you are correct, but let me explain this.

Encrypting a file is simply shifting or changing bits of data around, so they cannot be opened unless the person can decrypt it.  Now, TC uses only the 2nd half of that philosophy.   Shortly, here’s what happens.  When you run TC (assuming you already did the configuration for it), it will ask you mount a file.  Now, you’re probably wondering what this has to do with encryption.  Well, with TC, that file is what will be used as a virtual drive.  However, when you unmount that virtual drive, it will be saved…and when it is saved, it’s saved as an encrypted file.  No, this is not the same as what we are trying to avoid, for this simple fact…the data inside of that file is not encrypted.

Think of it this way…you have an archive file (zip, rar, what have you), and you place a few pictures in there.  Next, you decide to encrypt that zip file.  So, now we have the zip file (or the virtual drive file), that is encrypted…but, in actuality, the data inside of the zip file remains intact…just unreadable because the the archive cannot be opened.

Now, I bet you’re even now wondering what this has to do with businesses/you?  Simple enough question.  Let me ask you this, however.  If you entrust an employee with a prototype documentation Word file, what would you rather have: A)  an encrypted Word document where the user can easily forget the password for it and then you lose all that information, or B)  an encrypted virtual drive where you can still restore data from it, and not have to worry ’bout remembering the password for the Word document as well? Sure, you can recover passwords from Word documents, but those programs cost money, and you want to be as cost-efficient as possible, right?  Well, the makers of TC also have a recovery disk available to recover passwords of encrypted disks (info: http://www.truecrypt.org/docs/rescue-disk.php ).  Does it cost money?  Nope…as it says on the page: “During the process of preparing the encryption of a system partition/drive, TrueCrypt requires that you create a so-called TrueCrypt Rescue Disk (CD/DVD) […]”

Really, there isn’t much more to say about TC that would support this entry any more.  Overall, it’s a very useful program, which is also portable (you can put it on your flash drive or such).  The only downfall to this is the root/admin requirement, but if you can get around that, then this is a pretty flawless program.  Especially with the recent release of 5.0, it’s added one function that a lot of people seemed to have been crying for for a while, so kudos to them on that as well.

It’s free, it’s efficient, user-friendly and is quite the indispensable tool.   All in all, I give it a 4.5/5.0, and we already know why it’s not a 5/5, hehe.  But, that’s the end of this story.

P.S.: I was writing a TC entry back in December, but it wasn’t working as well as I wanted it too, so I’m scraping that entry for this much more…professional (sic), entry.

Links/resources:

TrueCrypt homepage: http://www.truecrypt.org/

Quote about TC recovery:  http://www.truecrypt.org/docs/rescue-disk.php (found in the “Documentation” section of the website.)

P.P.S.: This entry in no way is meant to demean the usefulness of password-protecting a file, or encrypting it like many already do…but, this entry is meant to explore a more elegant way to handle sensitive data.  TC is a very powerful program, and I do not recommend it to the people who are not comfortable with the fear of data loss or other severe consequences, but as with any software, that threat does exist.

The UNIX epoch threat

Okay, first off…heh, I know I’ve not been updating this like I’ve said I would…but, with work, personal life (drama), and other stuff…heh, yeah.  But, I’m going to try to be a better informer.

I bet you’re wondering what I’m even talking about.  Well, here’s what this (small) post is about.  In the (not so, depending how you view it) coming years, all 32-bit operating systems that tell time based off of the UNIX epoch time (which is defined as “00:00:00 UTC on January 1, 1970″ by the Wikipedia article on it) will no longer be able to do so from January 19, 2038, on.  The reason being is that epoch is stored as an unsigned 32-bit integer, which means it can only increment so high ((2^n) - 1, or 4.294967295e9 [(2^32) - 1]), before it overflows.  Even though that seems like an awfully long time for something dangerous to happen, businesses that use operating systems or software that base time off of this format should consider what to do.  This will have a dramatic effect on things such as billing software, installation databases, etc…

Off topic, slightly, but I know this isn’t the most informative article written here…but, there’s really not much else to write about this topic, for the simple fact of: 1)  the solution is rather simple…use a 64-bit (operating) system; 2)  by the year 2038, who isn’t going to have at least a 64-bit (operating) system?  That doesn’t necessarily clear the air for software, but by then the problem, I believe will already have been extinguished.

However, this would be an interesting situation at my current work force…hehe.  The people who do use Unix are pretty much all running software that depends on time in some manner or another…and, well, we all know how Unix keeps track of time.

Apologies and update

I’ve neglected this blog FAR more than I really should have.  Anywho…a new topic is on the way.  I know I’ve said this before…but I do have a draft, I just never finished it…so, either I’ll finish that up, or I’ll scrape it and start anew (probably do the latter).

Social Engineering, and the Caveman Threat

The human mind is a very volatile creation.  Level of intelligence various from individual to individual, but yet…we all suffer from the same vulnerability.  We believe the unbelievable.   This is the single-most biggest threat to ANYONE, from conceptual thoughts to fortune 500 corporations, there are many people who will fall for even the silliest stories.

Working where I do, it has become saddenly obvious that everyone, from the floors to the C*O offices will tell you anything if you ask for it.  Granted, some people are more aware and will question you if you flat out ask for their full Social Security Number, but that is far and few inbetween.  If people are more than willing to give out this information, then how do you expect them to keep your latest-and-greatest product under wraps?  This is where this article comes in.  There really is no way to stop this threat, since you don’t control people’s minds…but there are ways to better safeguard your fortune’s life.  Before going into prevention, however, I would like to discuss a little bit of how this topic, social engineering, works.

As already stated, this deals with the human mind, and that’s all.  Most people’s first attempt is to be friendly to the individual they are targeting.  For example, say your janitor of 10 years wants the inside scoop of your newest networking topology…how are they going to get it?  They could just walk right into your office during the night and steal it, but that would get them caught rather fast since they are the only ones to work at night.  So, they just sit and ponder for a while, and realize that your secretary  is new, and probably does not know how to not talk about confidential information.  Over the coming weeks, the janitor begins to befriend your secretary, slowly bringing the topology work into the conversation…just testing the waters.  However, after a couple of months, the janitor’s got all the information they need and they sell the information to another company.

Gathering information isn’t the only purpose of social engineering, though.  As much as I really prefer to steer clear of this type of reference, I want to talk about the beginnings of Microsoft.  Before I begin this, I want to say this…the information on this story is from “Pirates of Silicon Valley”…so the factual integrity isn’t assured.  For those who have seen the movie, you may recall this quite well, but here’s the shortened version of this.  Around the time of Windows (when MS-DOS was being slowly dismantled), both Microsoft and Apple were competing for the first commercially available GUI operating system.  Near the release of both OSs, Apple’s Steve Jobs confronted Microsoft’s Bill Gates, claiming Apple created the exact same GUI before Microsoft did, and Microsoft is just stealing from Apple.  Bill Gates, however, has always been able to “con” his way into victory, and he did not fail here either.  He reassured Apple that what Microsoft is doing is completely legal, and is not violating any copyrights and the like.  Steve Jobs fell for these apparent lies, and Microsoft took over the market eventually.

You might be wondering, after reading all of that, what does that have to do with social engineering?  Well, if Bill Gates hadn’t been able to convince Steve Jobs that he’s following the law, he could’ve been sued, and Apple could’ve taken over the market share.  However, Bill Gates new exactly how to attack Steve Jobs, and he did it successfully by using social engineering.

As I have given two examples, I would like now to examine ways to stop this kind of stuff from happening.  One way is to only let the people who need to know, actually know the information.  This isn’t the most sure-fire way, but it does help…because then you can narrow down who is leaking the information.  Another way is by having the parties involved sign a contractual confidentiality agreement, to where they must agree to not speak of the material in question to anyone who shouldn’t know about it.  This is possibly one of the best ways to handle it, if you want to spend the time and effort into it, because in reality, no one really wants to be sued…especially when they will loose right off the bat.

As of right now, this is all that can really be covered on the topic of social engineering, without repeating myself.  It’s a rather simple concept and act, but the results can be devastating.   Most likely, another article will follow on this issue in the future…but until then, I plan on writing a few different articles.

(Side note: I know this isn’t enterprise-specific, but I feel it hurts businesses a lot more than it would an individual in certain circumstances.)

Small Update

I apologize for not updating this since the intro. post.  I was unable to get onto a computer for about the past week, and had other obligations to fulfill; however, here are some topics I will be covering within the next week or two:

1. User authentication (for both Windows and websites)
2. Maintaining a safe working environment (kind of a series, part one is mainly dealing with misc. applications)
3. Pros and Cons of creating your own software for the business (for example, writing an FTP client when thousands already exist just to add one more feature)
4. Social Engineering (how it’s done, and ways to [hopefully] prevent it)

There will also be more…but those are the main candidates right now.  The reason for these three is because I see a lot of flaws at my current place of employment, and a majority of these flaws are in the above spots.

Introduction

Thank you for viewing “The Security Enigma: How to protect your network.” Before writing any actual content as to what this blog is about, I wanted to make an introductory post.

Here, you will find discussions on various topics dealing with security in an enterprise environment. This ranges from workers to technological security to physical security. My current employment at Ford Motor Company has given me a great deal of knowledge as far as the “do’s” and “don’t’s” goes for security. Every day the experience is something new, and I feel as though it is worth sharing my insights in the broadened scheme of things.

As far as talking about security, I will NOT discuss the security put in place at Ford specifically, for various reasons. However, it is quite easy to explain my thoughts and such in a general way, so it is undertandable by others.