May 08

encrypted.jpgA security vulnerability in the way that online storage provider DropBox (and possibly rival Box) handles links to shared files caused some documents (which were supposed to be viewable only people designated by the file owner) accessible and available to web site owners using Google’s visitor analytics and advertising tools.  The rival online storage firm which found the issue claimed to have reported the problem (which gave access to sensitive files like mortgage documents and tax returns) to Dropbox last November.  Dropbox fixed this issue, which it insists is a feature rather than a security flaw, this past Monday.

This issue highlights the need to make encryption of files and data stored on cloud service providers with keys stored on the user’s local system simple enough for non technical folks.  The solution also needs to be able to support sharing of encrypted files securely with a third party or with other cloud services you authorize.  If cloud providers can get this right (no small feat), living your life in the cloud will truly be ready for prime time.

Some solutions which currently exist:

  • Boxcryptor is a software solution which sits on top of Dropbox and other storage providers and automagically encrypts files as they are sent to and received from the cloud.  They provide secure sharing as well as mobile apps for the major platform.  Of course, since Boxcryptor is an overlay to services like DropBox, using this product would break the integration between DropBox and other cloud apps.
  • There is at least one consumer usable provider (SpiderOak) which currently claims to offer this type of Zero Knowledge Encryption.

The real answer to the issue of cloud encryption lies in having the encryption built in to the platforms in a standard and interoperable way.  C’mon cloud vendors, you can do it!

 

May 04

One of the nice things about Apple’s iOS platform is the “hardware level encryption” that protects “all of the information on the device.”  At least, that used to be the case.

Starting in iOS 7,  email attachments stored on iPhones, iPads, and iPod Touches (remember those?) are not stored in encrypted form.  A security researcher recently announced that he was able to retrieve plaintext attachments from encrypted iPhones using standard forensic tools.  Apple never corrected its previous statements indicating that all data in iOS was “protected by hardware encryption,” so millions of personal and business users have been working under a false assumption of security for a couple of months now.

When the researcher reported the issue to Apple, he was told that they were aware of it but had no date for a fix.

This is why I continue to recommend that corporate users stick with containerized solutions for their iOS and Android mobile users.  Consumer level mobile devices are not designed with the level of security appropriate for business (especially in highly regulated industries like Finance and Health Care).  Yes, it would be nice to use the native apps on personal devices to deliver corporate data from an ease of use point of view, but if your users are carrying around sensitive information in their email attachments, you have to consider the risk of an adversary extracting that information from the device relatively easily.

Apple really dropped the ball on this one.  They were not up front with their users regarding the loss of a key security feature and didn’t give them the chance to make an informed decision based on that information.   Not cool.  This incident underline’s Apple’s lack of commitment to and understanding of  the corporate market.  If they want to be a corporate player, they need to step up and accept the responsibilities that the role entails – otherwise, stop trying to do things half way, guys.

Apr 27

In this article over at Ars Technica, we get the scoop on Standford University’s new password policies which vary the requirements for password complexity (use of special characters, upper case, lower case, numbers, etc.) based on how long the user chooses to make their password.  As the password chosen gets longer, the user is given more latitude to reduce the amount of complexity.   I think that this is a great idea, providing users with choices in how their passwords are constructed while maintaining a level of security relevant to those choices.  Unfortunately, this is not a policy which can be implemented off the shelf on today’s most ubiquitous operating systems – you would have to create some sort of a front end program to vet users’ password choices and then store them in the OS.   Sounds like a great idea for an open source project to me.

Apr 20

Heartbleed strikes again… according to respected security consulting firm Mandiant, one of its corporate customers’ SSL VPN appliances was compromised by attackers using the Heartbleed vulnerability.  The attackers were able to hijack logged in sessions and thus access the organization’s network.  The key to detecting hijacked sessions is to look for log entries which show sessions switching between two different IP addresses at short intervals.  Mandiant isn’t telling which vendor’s SSL VPN is vulnerable, but Cisco,  Juniper, and the open source OpenVPN project have all issued security advisories related to Heartbleed.   Infosec people should be checking for new VPN vendor patches and scanning logs for telltale IP address changes.

 

 

Apr 11

 

SANS recently published the latest edition of their “OUCH!” security newsletter for end users – this month’s topic is Yes – You Actually ARE a Target! - something that we usually have to remind users about on a regular basis, in spite of the regular coverage of hacks, data breaches and other cyber shenanigans which are always afoot these days.

OUCH is a good (and free) resource to augment your organization’s Security Awareness efforts.

SANS OUCH Newsletter

www.securingthehuman.org 

Jul 11

Via Gizmodo

Feb 24

Some spear phishing wisdom from Security BSides SFO today…

Rohyt Belani of PhishMe told an interesting story highlighting just how much research attackers do when choosing their targets and crafting spear phishing payloads. In an attack on an energy company, employees received an email appearing to be from the company’s HR department offering information on discounted health care premiums for employees with more than 3 children. The only employees to receive the message? The two people at the company with 4 or more children.

This raises two issues for InfoSec professionals…

First, the attackers are doing their homework, people. They are taking the time to craft their social engineering payloads in ways that target very specific targets. This means (IMHO) that they are extremely motivated – most probably by money or ideology.

Second, our coworkers are helping the attackers with their targeting by sharing all sorts of personal information via social networking platforms. We need to educate them about:

+ The fact that their social media profiles are visible not only to friends and family, but also bad guys who will use that information to craft their attacks. The “familiarity cues” which we tend to use to determine whether a message or request is from a friend or a foe just don’t work anymore.

+ Their ability to control who sees their social networking information by using the privacy features offered by Facebook, LinkedIn, and to a lesser extent, Twitter. They need to think about what they are posting and who will see it – not only to protect the company, but to protect the privacy of themselves and their families.

While we put all sorts of technical solutions in place to protect our systems and information from malware, our users are the front line defense against the most serious threats we face. Educating them to be aware of how their actions both inside and outside the office affect the organization’s security is one of the most important tasks we face as InfoSec professionals.

Jan 21

java: threat or menace?

By alberg best practices, CSO, hacks Comments Off

Too much Java can make you cranky…

It has been a pretty bad few weeks for Oracle’s Java language – zero day vulns, followed by an out of band patch, with another serving of zero days to top things off.   “Uninstall Java – it is dangerous at any speed!” was the message from some security experts.

The things that make Java attractive to web app developers (it’s cross platform compatibility and pretty ubiquitous distribution) are the same things that make it such an attractive target for malware authors.  Add to that a seemingly endless supply of critical security vulnerabilities, and you have a recipe for big trouble.

I have pretty much had it up to here (my hand is at neck level) with Java as a web plugin and would love to just uninstall the whole bug infested mess from my users’ computers at the office.  (Of course I could say the same thing about Flash)  However, some pretty critical parts of our business rely on Java web apps to bring in revenue (some of which goes to pay my salary – nuff said).  So, I had to get a bit clever in coming up with a defensive strategy.

After looking at my web proxy logs, I determined that Java usage at my firm pretty much fell into two buckets:  a small number of business related apps from trusted business partners and a whole bunch of totally non business related apps accessed during recreational surfing.  This made my job pretty easy… I figured out where the business apps came from and created a whitelist.  Then I set the web filter to block all .jar and .class file downloads from other locations.  In the two or so weeks that this policy has been in place, I have gotten exactly one request to whitelist a new jar file.  The result?  A much reduced attack surface for the company.  My users seem to be OK with the new policies, which I explained in an email blast.

Yes, we will continue to update our Java Runtime Environments – after all, there could be some locally installed software which needs the JRE and using the latest and greatest versions is just good practice.  And we’ll continue to implement other good practices (getting rid of unused software, keeping an eye on our log files and network traffic, keeping patches and fixes up to date and the like).

While I can’t say that we are totally protected from Java based attacks, I do feel that we have struck a pretty good balance between security and the need to let the business do business on this one.

 

 

Tagged with:
Sep 26

The most valuable piece of security equipment in your organization

For the past few years, the Social Engineering Capture the Flag contest has been a highlight of the Defcon security conference.  The report from the 2012 edition of the contest provides some interesting insight into the social engineering threat and what companies need to do to protect themselves.

The targets of this year’s contest were 10 firms in the retail, oil, freight, telecom and technology industries.  The oil industry got the highest marks for keeping their information secret, which makes sense to me.  Their employees probably have a lot less interaction with the public on a day to day basis, so unusual requests for information would probably stand out from the norm.  Retail giants Walmart and Target brought up the rear, giving up the most information.

The theme of this year’s contest was “Battle of the SExes,” pitting male social engineers off against their female counterparts.  While the male contestants scored higher than the social engineers of the fairer sex, the small sample size (10 men and 10 women) and the fact that female participants in prior years of the contest were few and far between, makes me wonder if these results are indicative of a trend.

The contest participants were given two weeks to perform “open source intelligence” (the gathering of information about their targets from public sources on the Internet).  A number of the companies targeted provided attackers with lots of information during this phase.  Some of the more noteworthy information leaks resulted from photos posted on social media, which yielded pictures of employee ID badges and layouts of facilities – either which could help an attacker get physical access to their targets.  Other information gathered from social media included ESSIDs of wireless networks and location checkins by employees.

The real fun began when contestants got on the phone.  A number of pretexts were used to explain the callers’ requests for information.  The trickiest pretext was that the caller was an employee of the targeted organization.  Knowing the right jargon and using widely available caller ID spoofing services bolstered these callers in some cases, but maintaining a believable cover story here was difficult.  Callers who purported to be “taking a survey” or calling from a vendor did not do too well, since many employees find these types of calls annoying and thus routinely terminate such calls quickly.  One more successful pretext was that the caller was a student doing research on the targeted company for a school assignment.

The conclusions in the report were what you would expect:

  • Employees need to be better educated against social engineering threats (true, in spite of  the report writer’s business in performing such training and social engineering tests).
  • Employers need to tighten their social media policies to control the leakage of confidential information to the Internet.

The second finding, while it sounds great, is potentially problematic for US companies.  As I have noted in previous posts, US law does not allow companies to place many restrictions which make sense from a corporate security perspective on employees’ personal social media accounts.  The regulations are aimed at preventing employers from quashing employees’ rights to discuss their work environment and organize unions, but have the side effect of making it very difficult to write social media policies which both protect the organization and stand up to legal scrutiny.  If you haven’t reviewed your social media policies in a while, now is a good time to do so – and include your legal counsel.

The restrictions on social media restrictions make the need for employee education all the more important.  The social engineers are out there and they are gunning for your company’s crown jewels.  Taking the time to strengthen your Human Firewall is a worthwhile investment.

Jul 20

A while back, I wrote about how US organizations writing social media policies need to beware of the National Labor Relations Board’s requirements that these policies not interfere with the rights of employees to discuss their working conditions or organize unions.  At the time of my original post, the NLRB had released a guidance document which raised more questions than it answered.  Since then, they have released additional guidance which includes a number of examples of bad policies and explains the specific problems with each.  More importantly, it includes a sample policy which is in compliance with NLRB rules and which can be used as a guide in writing (or updating) your company’s social media policy.  It is really worth taking a look at this document – many things that any normal, reasonable infosec professional would expect to be acceptable (ie. “don’t post confidential information to social media sites”) are not.

preload preload preload