May 02

cloud security outlook… still, well, cloudy

By alberg best practices, CSO, malware, online security, worst practices Comments Off

Cloud storage provider DropBox provides a great example of some of the security issues that individuals and companies face when entrusting sensitive data to the cloud.  Over the past few weeks,  DropBox has made the news twice regarding its security and we all know that making the news is generally not a good thing when it comes to security.

Dropbox’s first issue came up in early April, when a security researcher named Derek Newton discovered a significant weakness in the service’s authentication mechanism.  One of the primary benefits of DropBox is that it allows the user to set up synchronized file systems across multiple devices.   When files are added to, modified on or deleted from any DropBox enabled computer, iPhone, iPad or other device, the changes are automatically replicated to all of the other devices associated with the user’s account.  This is a really useful feature for many people.  In order for this file synchronization to work properly, you need to install a piece of software on each device used to access your account.  Newton found that the Windows  DropBox  client stores the information needed to access the DropBox server in a configuration file which contains a “host ID” used to authenticate to DropBox.  Simply by copying this file to another computer with the DropBox software installed on it, an attacker would have full read/write access to the files in the DropBox account.

This opens up a whole range of possibilities for attackers.  For instance, it would be possible to write malware which specifically looks for the DropBox configuration file and sends it back to the attacker.  Once an attacker has the configuration file, they would have continued access to the compromised DropBox account even after the malware was removed from the user’s computer.  The user would have to remove their own computer from the list of devices allowed to access their DropBox account and reinstall the software to close the door on the attacker.

As of today, the vulnerability still exists… DropBox plans to rollout a software update which would make the configuration file useless on a second machine, but has not provided a timeline for remediation.  I would recommend not using DropBox until such a fix is made.

DropBox also made the news for a change in their terms of service.  The original terms of service assured users that since their files were stored in encrypted form on the DropBox servers, DropBox employees could not peek into their data.  Well, it turns out that this is not exactly the case.  A “limited number” of DropBox employees do, in fact, have the ability to decrypt user files in order to comply with law enforcement requests for data in connection with an investigation.  Now, I understand that DropBox wants to be a good corporate citizen, but there is a significant distinction between “our employees can’t read your data” and “only some of our employees can read your data.”  I applaud DropBox for making their terms of service clearer (and more accurate), but this incident (and the reaction from DropBox users) is an example of one of the major problems facing users and organizations when they make the decision to move their data to the cloud.

The problem is two fold… customers don’t know the right questions to ask and vendors just don’t seem to understand that users require security for their cloud data, even if they cannot exactly describe what security measures they are looking for.  A recent Ponemon survey on cloud computing providers’ views of the security of their services showed that among survey respondents (who we can assume are amongst the more security aware providers), vendors had the least confidence regarding some important security features of their services, such as

  • Their ability to authenticate users before granting access
  • Their ability to prevent or curtail external attacks
  • Their ability to encrypt sensitive or confidential information assets whenever feasible
  • Their ability to determine the root cause of cyber attacks

It is clear to me that many individuals and business are rushing in to take advantage of the cost advantages and convenience of cloud computing without knowing how safe or unsafe their information is while it rests in the cloud.  The efforts of organizations like the Cloud Security Alliance to develop baseline language, best practices and assessment tools are a step in the right direction, but the road to cloud security is still foggy and treacherous.

 

 

 

Share
Apr 12

video musings on the epsilon breach & malware

By alberg best practices, hacks, malware Comments Off

Each Tuesday morning, the New York Metro Infragard Members Alliance runs an excellent live webcast on all sorts of security topics from 9 AM – Noon NYC time.   On any given week, tuning in to IGtv will provide you with information on subjects ranging from information security to physical security to counter terrorism.  I am a regular contributor to the program, talking about hacks and attacks.  This morning, I spoke about the recent Epsilon data breach as well as some tools for checking out potential malware – the video below is about 18 minutes long.

Links mentioned in this talk:

Virus Total

Wepawet

PDF Examiner

Comodo Instant Malware Analysis

Cuckoo

Sandboxie

You can see more videos from IGtv on YouTube

 

 

Share
Jan 12

score one for paranoia and just plain common sense

By alberg best practices, online security Comments Off

OK - who was our 7th grade teacher, punk?

Here is a story to warm the hearts of even the most cynical infosec professional… When Tracy got an unexpected Facebook chat from a classmate she had not spoken to in the last 30 years asking her to take a survey, she got suspicious and quizzed the “classmate” about some events in their common past.  When the “classmate” couldn’t answer and abruptly dropped the connection, Tracy knew that her intuition saved her from an attempted scam.  I wish all users were as on the ball as Tracy!  Read the story at Sophos’ (excellent) Naked Security blog.

Share
Oct 03

why hack when you can just ask?

By alberg best practices, CSO, hacks Comments Off

At this past summer’s Def Con hacking convention, the folks at www.social-engineer.org decided to run a “Capture the Flag” competition to highlight the risks posed by social engineering, the art of extracting information from employees in order to make hacking a company’s systems or processes easier.  The test was run under a number of constraints; participants were not allowed to ask for passwords, credit card numbers and the like, due to legal concerns.  Instead, they were tasked with finding out things like the target companies’ operating systems in use, PBX vendors, VPN equipment, payday dates, trash handling and the like.  A total of 15 companies were targeted for open source research and follow up calls.  The results?

  • 14 out of the 15 companies provided one or more of the requested pieces of information.
  • Only 7 companies gave the attackers any resistance to answering the questions they were asked.
  • Out of 135 calls made, only 11 individuals put up any resistance to answering the attackers’ queries.

Some interesting (and depressing) take aways from this report…

Most employees offered no resistance to the attackers’ requests for information. Those that did offer resistance could often be persuaded to give up the goods with a little more conversational kung-fu on the part of the attacker.  Of course, it is possible that the contest’s rules against asking for really sensitive personal information like passwords and credit card numbers may have come into play here.  I would think that the employees would have put up a bit more of a fight if the information being asked for was perceived to be more valuable.  This being said, getting information of low perceived value can help the attacker build a more convincing cover story for later attempts to get to the crown jewels.

Eighty percent of employees called were willing to visit a web address supplied by the attacker. This is pretty disturbing, as it provides the attacker with a great way to collect information about victims’ computers and to install targeted malware on vulnerable interesting systems.

In many cases, the only thing that stopped an attacker from getting a particular piece of information was the employee’s ignorance  or the fact that they were too busy to continue the call. In some cases, employees went out of their way to try and find the information in order to be helpful.  The fact that many of the people called worked in customer or employee facing call centers seemed to work in the attackers’ favor – after all, the call center exists to be helpful.

Attackers calling to ask “survey questions” were able to extract information from their victims pretty consistently.  The context of a survey allows the attacker to ask a series of questions and when the call is delivered in an engaging manner, the employee can be coaxed into providing lots of information.  Security awareness programs should include periodic reminders that employees should not provide answers to questions posed by callers “as part of a survey.”  At my office, I ask employees to transfer these types of calls to Security so we can mess with them.

Ex-employees can also be a source of information about your company.  An attacker armed with a list of recently departed employees could gather information by calling them posing as an employment recruiter.  In this context, asking questions about systems and processes can seem innocent.  It is important to have confidentiality agreements in place with employees and to remind them of their continuing obligations under those agreements after they leave the company.

While this contest was limited in its scope and realism (due to the limits on what could be asked for), I would recommend reading the report to get an idea of what we security professionals are up against.  In these times of limited or shrinking budgets, closing up the security holes that result from human behavior can be a very effective – and cost effective – way to protect our organizations.  Let your employees know about the threat of social engineering attacks and give them a procedure to follow when a call gets suspicious (like having them transfer the call to Security).

Let’s make the hackers work a little bit, folks!

Share
Aug 25

password strength take 2

By alberg best practices Comments Off

A few days ago, I posted on the subject of password strength… and then I saw some new research on the issue from Georgia Tech which adds some additional paranoia to password issue.   According to the folks from the Peachtree State, recent advances in repurposing the Graphics Processing Units (GPUs) on computer graphics cards put some serious computing power in the hands of password crackers:

“Designed to handle the ever-growing demands of computer games, today’s top GPUs can process information at the rate of nearly two teraflops (a teraflop is a trillion floating-point operations per second). To put that in perspective, in the year 2000 the world’s fastest supercomputer, a cluster of linked machines costing $110 million, operated at slightly more than seven teraflops.”

 

The bad news is that these easily harnessed teraflops make it possible that passwords shorter than 12 characters could be brute forced quickly enough for attackers to make use of them.  Now, as I mentioned in the previous posts, well designed systems should implement some mitigating factors to prevent brute forcing from working, the most important of which is intruder lockout and alerting.   However, the attacker going after offline data such as encrypted files could make use of brute force attacks.  And it is important to remember that many current attacks depend on keystroke loggers – once the attacker has a logger on your system, the length and complexityof your password does not matter any more.

In the end, my recommendations stay the same – run (and update) anti malware software on your machine, and use different, well constructed passwords for every site you visit (LastPass is a great way to keep track of these).  It is amazing how many people use the same passwords for different sites… c’mon people – let’s make the bad guys work just a little bit!

Share
Aug 16

so long, SAS70!

By alberg best practices, CSO Comments Off

SAS70 season - the most wonderful time of the year!

Since 1992, many organizations have relied on SAS70 audit reports to determine whether their service providers’ controls are appropriately designed and effectively implemented. 

In the information security field, the SAS70 has become the unofficial standard for how service providers provide assurance to their customers that their systems are safe and secure.  This is not what the SAS70 was originally designed to do – SAS70 reports are supposed to focus on financial matters, but the people have spoken.

Since my employer is a service provider, we conduct an annual SAS70 Type 2 audit with an external audit partner.  We then provide the resulting report to our customers’ information security and risk teams to help convince them that they can trust us with their sensitive information.  This is pretty typical for the industry.

It is important to remember that the SAS70 standard simply describes the format for the report produced by the external auditor.  There is no such thing as being “SAS70 Certified.”  It is even more important to realize that the scope of the SAS70 report (in the form of the list of controls to be tested) is pretty much up to the organization being audited.  If the organization does not want to test certain controls, they can simply leave them out of the report.  For this reason, when evaluating a SAS70 report from a vendor, you need to read carefully – what is not said in the report is probably even more important than what is included.  (very zen, don’t you think?)

The new SSAE 16/ISAE 3402 standards which took effect in June of this year are meant to replace the SAS70.  SSAE 16 is the US version of the standard, while ISAE 3402 is the international version.   These new frameworks do provide some improvements over SAS70 for those evaluating outsourcers.  I am pleased with two of the changes in particular:

  • While the SAS70 was centered around the description of controls, SSAE 16/ISAE 3402 adds a requirement to include a description of the system being audited.  This description must include transaction flows as well as significant non transaction events.  While this is going to mean more reading for the recipient of a report, it also provides the recipient with much better context to evaluate whether the controls described later on are sufficient.

 

  • The new standard also requires organization to do a risk assessment and make sure that the controls that are reviewed address the risks to the system described.  The service provider does not have to include the risk review in the report, but the auditor will be looking for risk/control linkages during the review process.  I think that this is a good thing, especially for smaller service providers who may not have a mature enterprise risk management function, as it will force management to take stock of risks in a systematic way.

While these are welcome changes, they do not really address what I think is main problem with SAS70 as an information security assurance tool – the lack of common objective criteria to be assessed.   The approach that I have taken in the SAS70 that I am responsible for is to map out all of the controls described in the report against the ISO 27002 standard, which provides provides  ”established guidelines and general principles for initiating, implementing, maintaining, and improving information security management within an organization.”  While my shop has not gone through the formal certification process for 27002, I feel that using the standard as a framework provides the readers of our SAS70 with some additional assurance that we are including all of the relevant infosec controls.

So, as we bid a (somewhat) fond farewell to SAS70, I look forward (somewhat) to our new, improved minty fresh SSAE 16 reports.  My company will be doing our first SSAE 16 early in 2011 – I’ll report back on how the process differs from what we have done to date.

Share
Aug 15

google and the government

By alberg best practices, online security Comments Off

The US Federal Government has given Google the FISMA certification needed to allow government agencies to outsource their (non secret) email and calendar systems to the search giant’s cloud data centers.  In order to get the feds’ stamp of approval, Google had to set up dedicated servers located in the continental United States for government data and have a third party perform an assessment of whether Google’s security practices were in alignment with FISMA, the Federal Information Security Management Act, which sets standards for security on government systems.  Apparently, the documentation provided by Google to back up their application ran to over 1500 pages.

So, does this mean that since the cloud is secure enough for Uncle Sam, all of us in the private sector can ditch our Exchange servers and move to the cloud?  I’m not yet convinced. 

 

  • As private sector users, our data doesn’t get its own servers located in the US and presumably shielded from the great unwashed masses of the Internet and watched very carefully by a dedicated security team.

 

  • Seeing the FISMA evaluation report would help the private sector determine whether the testing performed meets our requirements for security.  Google currently offers the report documentation to government organizations considering moving to Google Apps. 

I love the idea of being able to outsource non core functions like email and calendaring – the cost savings are very compelling.  But before making that kind of decision, I’d have to see a lot more disclosure from Google on their security practices.  I would also want some sort of assurance that my organization’s email would not be used by Google’s mighty data analysis machines for purposes other than providing services to my company.  The Googlers are great at mining the data they have for profit… I am not sure that I would want to add my corporate email (or my government’s email) to their ever expanding database.  

I still need a lot of convincing that this is a good idea.

Share
Aug 14

truecrypt – disk encryption for everyone

By alberg best practices, useful stuff Comments Off

 

It is amazing how much (sensitive) information we can now carry around every day.  I have 8 gigs of all sorts of interesting stuff on a flash drive on my key ring, and hundreds of gigs on my laptop.  Keeping that data out of the hands of evildoers should I lose my keys or have my laptop stolen is really important to me.

 

That’s why TrueCrypt  is one of my favorite open source software products – it provides full disk encryption for Windows, Mac OS X and Linux systems at an unbeatable price point (free).  One of its nice features is that you can create a fully encrypted flash drive (or hard drive) on, say, a Windows system and then take that device and use it on a Mac or Linux system with TrueCrypt installed – quite handy for those of us who use different operating systems on a regular basis.  For the most paranoid amongst us, you can even set up hidden encrypted volumes within encrypted volumes to further shield your data from prying eyes.  Version 7 of this vital part of my personal information security toolkit was released back in July, and adds the ability to have volumes automount when they are connected to the computer as well as protection of crash dump and hibernation files on Windows 7 systems.  If you haven’t had a chance to play with TrueCrypt, give it a try today!

Share
Aug 13

just how strong are your passwords?

By alberg best practices 1 Comment »

not a great password

When choosing a password, a couple of characters can make a big difference, and you can see just how big a difference by using the online TGP Password Strength Checker.  This web based tool provides estimates of how long it would take a well equipped adversary to brute force a given password.  The results are very instructive. 

If your password is “apple” you can expect it to be guessed in under a second by an automated brute force attack by a well funded attacker.  Now, let’s try changing a few parameters and see what happens to the effort required:

Apple - still less than a second… that capital letter did not help too much

Apple450 – now the estimated time jumps to about 27 hours… better, but still pretty darn easy if the attacker is motivated.

Apple*450 – adding that special character really helped, now the attacker would have to crunch the numbers for about 350 days to guess the password.

Apple*+450 – OK, now we’re talking… adding in a second special character just raised the brute forcing time to approximately 73 years.

Apple*+*450 – That last * really made a difference – unless our attacker has 5,547 years to spare, brute force attacks agains this password are pretty futile.

Password length makes a real difference.  For example, the password “Cantaloupe450″ would take a very well funded adversary about 2.9 million years to guess (as opposed to 27 hours for “Apple450″).  Length and character set diversity are your friends.

Now, I would not recommend putting your real passwords into the online checker… while the person who wrote it is a well respected security researcher who says that none of the tested passwords are stored, you never know, do you.  However, by experimenting with passwords of a construction similiar to the ones you use, you can get an idea of what you need to do to make your passwords as crack resistant as possible.

Now this system does not take in to account “dictionary” attacks which use word lists like dictionaries or lists of sports team names, proper names or really stupid passwords that people insist on using.  These attacks would be much more efficient.  We security types always tell you not to use dictionary words, but we know that you do… they are easier to remember.  A couple of things you can do to make passwords with dictionary words in them more secure:

  • VarY tHE cAPitalIZAtion of the word
  • Place numbers or special characters within the word – butter324fly or busy*45bee

Of course, in a well designed system, accounts would be set to lock out after a small number of password attempts, making it pretty much impossible for such dictionary and brute force attacks to work.  But not all systems are well designed (thus keeping people like myself employed and writing blogs).  Protect yourself with a decent password.

Share
Jul 20

playing in the sandbox for security

By alberg best practices Comments Off

Sounds like Adobe is planning to take action to make Reader a less attractive target for hackers.  According to a report out today, the maker of the ubiquitous document rendering software will release a new version of Reader which “sandboxes” PDF documents in a restricted environment while they are read.  This will mean that if the file contains malicious code, that code will be trapped in a virtual jail and will be unable to access the underlying operating system for its nefarious purposes.  Similar technology is used in Google’s Chrome browser (my personal favorite) and Microsoft Office 2010.  The first version will just block writes to the host computer, but later versions will also control other operations from PDFs.  While this is not a cure-all, it sounds like a great step forward and will provide another layer of defense from evil PDFs.

In other sandbox news, Dell’s KACE systems management division released a free tool which combines Mozilla Firefox browser with Adobe Flash and Acrobat Reader into a virtualized package which allows web browsing to take place within a sandbox isolated from the rest of the Windows environment.  They also offer a management appliance (not free) which will allow enterprises to deploy and manage Secure Browsers on hundreds or thousands of computers.  I have not yet had a chance to play with this tool, but it looks promising.

Share
Previous Entries Next Entries
preload preload preload