Friday, October 21, 2011

Why iOS Data Protection is Adequate for Corporate Use (And Why The Siri “Vulnerability” is a Non-issue)

First things first. The so-called Siri "vulnerability" that was widely reported this week is a dumb non-issue created by journalists seeking sensationalist headlines. A simple setting disables the ability to use Siri without unlocking the phone rendering the whole issue moot. What the sensationalists fail to take into account is that the iPhone is a consumer device. Most consumers don't even use a passcode. The obvious default setting for Siri in this case, as one of the attractive new USPs of the iPhone 4S, is to allow use even when the phone is locked - I don't think you can fault Apple for this.

Now on the other hand, things need to change when these consumer devices are allowed in an enterprise. Exchange Active Sync (EAS) or Mobile Device Management (MDM) software should be used to apply minimum security policies, which should always include a complex passcode of more than 4 characters, auto wipe on multiple failed passcode attempts and, of course, disabling Siri without unlock (this latter capability would required MDM, since it is not available in EAS). There are many other security settings that should be addressed too, but the main one is the passcode.

Once the passcode is enabled, Data Protection is turned on. Now, Data Protection is NOT full disk encryption, although encryption IS turned on globally. However, you should assume that it only encrypts data in applications that support the Data Protection APIs (this is an over simplification, but the details are too complex for a blog post and are the subject of an Analysis Brief that will be available shortly to NSS subscribers).

Out of the box, that is the iOS Mail client, for example. Other commercial apps will support Data Protection too, though these are few and far between right now - GoodReader is one of the best known. Others include USB Disk Pro, mobilEcho and the Box.net iOS client. There are several more, but not enough of them given that these capabilities have been available since the pre-release of iOS4, and we are now on iOS5!!! This continues to be a sore point with me as many developers make a big deal out of pushing their apps as business-class, yet spend more time making nice UIs and not enough securing the data that they are supposed to be protecting. Bear in mind that these apps will typically be used to access corporate documents, in many cases storing locally on the device outside the control of corporate IT. That data needs to be encrypted.

With apps that support Data Protection, you have an additional layer of encryption on the iOS device. If you have a passcode set on the iPhone and you turn on Data Protection in GoodReader, all of the docs stored in the GoodReader sandbox will be encrypted in the same way as data stored by the Mail app. You can even have some data in the clear and restrict encryption to certain files or folders.

So far so good, but what about those “researchers” that have written about the fact that jailbreaking an iOS device or connecting one to Ubuntu will provide access to all data on that device? Yes, unfortunately it is possible to jailbreak an iOS device and completely bypass the passcode. There are other ways to bypass the passcode too (such as that issue with Ubuntu). Because of the way iOS implements the Data Protection capability, once the passcode is entered or bypassed, all of the data on the device that is not protected by Data Protection APIs specifically is unencrypted on the fly.

Therefore, if someone jailbreaks my iPhone they will be able to access all of the documents stored in the ReaddleDocs or PDF Expert sandbox because the iPhone will decrypt on the fly as the data is accessed. However, if they try to access my Mail data or anything stored in the GoodReader sandbox, they will only see encrypted data. Same thing goes for items stored in the keychain. Anything stored in the clear will be accessible when a device is jailbroken. Anything written using Data Protection APIs will remain encrypted.

Only by entering the passcode can that encrypted data become available. This is an important distinction that needs to be understood. Jailbreaking/bypassing the passcode DOES NOT BREAK iOS ENCRYPTION - it merely bypasses the basic protection on the device. Anything stored using Data Protection APIs WILL REMAIN ENCRYPTED EVEN FOLLOWING JAILBREAK.

There is no way to brute force the passcode off-device since it is tied to the hardware. If you have auto-wipe turned on, too many attempts to brute force the key on-device will result in a wipe. One nasty problem is that you CAN do brute force attempts on-device without triggering auto-wipe by bypassing the UI APIs that ask for the passcode, so that is why security-conscious folk need to ensure they use a longer, complex, alphanumeric passcode that will resist brute force attempts.

So there you have it. Could Apple’s encryption scheme be better? Yes, of course it could. There are some caveats, and I would have preferred it to be full-device encryption, or at least to have a central document storage area that is always encrypted by default. However, my opinion is that iOS devices are perfectly acceptable and secure enough for corporate use PROVIDING they have a sensible security policy applied, Data Protection is turned on, a complex passcode is used and any sensitive data is ONLY stored within apps that support Data Protection APIs. Corporate users should always ask iOS developers if their app supports Data Protection and avoid those that do not.

The Sophos post and original Fraunhofer research, and any others spouting similar opinions, can be dismissed with a simple analogy, since they appear to assume Data Protection is not being used - if that is really the case, it is like leaving your keys in the ignition and locking the door, then complaining when someone smashes the window and drives off with your car!

I am taking a significant number of inquiries from NSS client each week on this subject, proving that it remains confusing for many. I hope this helps a little. In addition, as I mentioned earlier, there are a couple of NSS Labs Analysis Briefs in the works covering iOS Data Protection and other security issues facing corporate users of consumer devices. These will be available to subscribers only. Follow me on Twitter (@bwalder) to keep informed as new research is released.

Friday, September 30, 2011

Testing Times for CISO's

Performance and effectiveness claims from vendors of network security products can never be taken at face value. In a process crucial to making the right buying decisions, how do the CISO, CIO and other security professionals ensure that new in-line security products are tested thoroughly in an environment that replicates as closely as possible that found in his or her own network?

Selecting security products is a complex process that carries significant risks if not executed correctly; poorly chosen products can fail to protect against serious threats, cause serious performance problems for enterprise networks and waste scarce financial resources. CISO’s, CIO’s and other security professionals need to develop and execute an enterprise-specific in-house testing plan before evaluating and purchasing security products.

Failing to test security products before buying them means organizations run the risk of performance limitations, security failures and overspending. Weaknesses in security coverage can often remain undiscovered for long periods of time, leaving those organizations at risk of losing corporate assets or compliance status. Installing in-line security devices such as Firewalls, Intrusion Prevention Systems (IPS), and Secure Web Gateways can lead to a false sense of security unless vendor claims are verified. Critical servers often remain unpatched in the belief they are protected by an IPS, when claimed coverage is actually less effective than promised. In addition, fear of false positives can lead enterprises to run IPS devices in a less secure IDS mode, thereby forfeiting protective properties and increasing operating costs and risk. Selecting the wrong network security device can thus expose a company to serious threats from both inside and outside the network perimeter.

Poor performance from an in-line device once placed in a live network can also have serious consequences as latency increases to unacceptable levels. High latency or frequent “fail closed” events can result in active devices being redeployed in a passive state or having blocking disabled, significantly reducing their effectiveness.

Cost is an issue too. Without performing relevant tests in-house, organizations could be persuaded to overspend significantly, purchasing devices with performance and coverage levels that are not required.

In-house testing can help alleviate many of these problems, and it is important for organizations to use testing procedures designed for their own threat environment to determine the best in-line network security products for their specific needs.

NSS Labs has recently published an Analysis Brief covering key points CISO’s need to know about testing security products, entitled The CISO’s Guide to the Importance of Testing Security Devices (subscription required). Follow me on Twitter (@bwalder) to keep informed as new research is released.



Thursday, July 21, 2011

How Will You Manage iOS5 Devices in Your Corporate Network?

I have taken a significant number of inquiries recently from NSS Labs’ enterprise clients to discuss the increase in the level of demand for employee-owned devices to be used on corporate networks. One of the disturbing trends is the number of CIOs admitting that end users are connecting those devices to the enterprise network with or without permission. Where security requirements and risk profiles permit, many organizations would be better advised to accommodate and control this behavior rather than attempt to prohibit it.

In the past, it has been possible to enforce centralized control over mobile devices, and many companies standardized on single-vendor solutions such as the BlackBerry Enterprise Server (BES) from Research In Motion (RIM.) Users do not typically select Blackberry devices for personal use, however, and are bringing increasing pressure to bear on IT departments to permit access to corporate resources from a single device – their own.

In many cases, employees will discover for themselves how to configure their personal mobile devices for corporate access, leaving IT departments with a dilemma – locate and prohibit unauthorized access, potentially limiting employee productivity in the process, or embrace the consumerization trend and find a way to manage and secure access via personal devices.

IT departments need to exercise control over smartphone and tablet devices, whether company-owned or employee-owned. Employees are typically reluctant to cede control of their personal devices to IT. However, the added benefits of being able to access corporate resources such as email and file shares is frequently enough to persuade them to submit to some degree of centralized management.

With the release of iOS version 4, iOS devices such as iPhone, iPod Touch and iPad can be more effectively deployed, managed and secured in enterprise environments providing sufficient care is taken over securing the data on these devices and enforcing suitable corporate security policies. iOS5 will allow us to take things a step further, particularly given its ability to enable mobile devices to exist without being connected to iTunes (previously a huge bugbear for many organizations worried about deploying consumer-grade software in an enterprise network.)

One caveat here is that this move to a completely untethered, over the air (OTA) deployment scenario of the OS, updates, device activation, backup/restore, and even day-to-day synchronization may well introduce new attack vectors.

Business customers also need to realize that Apple continues to consider itself primarily a consumer company. It retains no sizeable enterprise sales force, offers no specific enterprise-level support (forcing enterprise customers to rely on third parties), and refuses to communicate road map details outside of the company. Organizations need to consider these issues as part of their evaluations of iOS devices for enterprise applications. One glimmer of hope is that the recent introduction of Apple’s B2B App Store program permitting volume purchasing of apps (though not yet volume discounting!) may mark the beginning of an increasingly enterprise-friendly Apple. Well, we can hope!

NSS Labs has recently published an Analysis Brief covering iOS management and security issues in more detail, entitled Managing iOS Devices Securely in the Corporate Network (subscription required).

I also have an Analysis Brief in production right now for our subscribers that will address the Data Protection capabilities in iOS4 and iOS5, and how they should be used to protect sensitive corporate data. Follow me on Twitter (@bwalder) to keep informed as new research is released.

Thursday, June 23, 2011

Can you have too much security?

Where organizations rely on application-aware security policies for their network security devices, or rely on Data Loss Prevention (DLP) products to prevent leakage of sensitive corporate material outside the network perimeter, the use of encrypted traffic means that those devices are suddenly blinded to the content, rendering deep packet inspection to the application level impossible. Cybercriminals are aware of this, and often make use of encrypted channels for covert command and control communications for botnets, as well as data exfiltration from the corporate network.

Given the risk that encrypted channels may be used by malicious entities for botnet command and control or data exfiltration mechanisms, enterprises are faced with an unpalatable choice – leave traffic in the clear or lose visibility into the encrypted data stream. Of course, there are solutions to the problem – there always are! – such as ensuring that network monitoring and security products can handle decryption, inspection and re-encryption of traffic on the fly.

The only issue is, how much of your already straining-at-the-seams security budget can you allocate to add SSL inspection capabilities to your infrastructure?

And while this may seem the obvious solution, on-the-fly SSL inspection can have a number of issues that need to be considered, not least of which privacy and performance. Vendor data sheets usually do not reflect accurately real-world impact on performance, forcing organizations to perform their own testing to ensure network security devices are fit for their intended purpose.

NSS Labs has a group test report in the pipeline covering SSL inspection capabilities of network security devices, and in the mean time, we have published a useful piece of research on What CIOs Need to Know About SSL and its Effect on Network Traffic Inspection Capabilities (subscription required).

Follow me on Twitter (@bwalder) to keep informed as new research is released.

Thursday, June 09, 2011

Apple Gets Cozier With Enterprises With iOS5

One of the most frequent questions I hear in inquiry calls with our enterprise clients at the moment is “how do we manage and secure iPads on our corporate network?”

Not “tablets” (at least, not yet), but “iPads” specifically.

Whereas the smartphone began the push for consumerization and “bring your own device” (BYOD) in the enterprise, the iPad has consolidated that move. The dynamic has changed because the iPad appeals equally to senior executives and mere mortals, and the IT department finds it much harder to push back when the CEO demands his corporate email on his new iPad. Secure board communications systems (BCS) are also something of a hot topic right now, and the iPad is making a significant impact in that market too, offering, as it does, an attractive alternative to lugging around giant paper-based folders of corporate documents.

With the release of iOS4, Apple introduced a number of features that finally allowed IT departments to consider the iPhone and iPad as “enterprise ready.” Mobile Device Management (MDM) APIs and Data Protection capabilities provided the means for enterprises to manage and secure both the devices themselves and the data stored on them.

Questions remain as how best to secure both device and data, and forthcoming research from NSS Labs on Data Protection and MDM will provide actionable advice to assist our enterprise clients in deploying these devices in corporate networks.

iOS4 still fell short in a couple of key areas when it came to enterprise deployment, however. The lack of secure email support and reliance on iTunes – a consumer-grade software product - for critical processes such as device activation and backup were two major concerns.

As expected, both of these will be addressed in the latest iOS5 release, though it remains to be seen how welcoming enterprise customers will be about certain aspects of Apple’s new baby. Having installed iOS5 on a few devices, I can say that it appears very solid so far for a beta product, though it is still missing some features that were promised in the WWDC keynote.

S/MIME support addresses the secure email concern adequately, and it appears to work well. I tested using both standard commercial and self-signed certificates, and digital signing and encryption functions worked fine for sending and reading messages. Certificates are installed via configuration profiles using the iPhone Configuration Utility (IPCU), following which they need to be selected for signing, encryption or both on a per-mail account basis. This process will need to be streamlined in larger deployments by the use of third-party MDM solutions in order to scale. Grabbing certificates from messages sent to you to store in the address book is a simple, one-click process.

The objection to iTunes has been addressed by the new “PC free” capabilities in iOS5. Apple explained at its developer conference that the aim was to add sufficient features on the device to remove the requirement for users to tether to their desktop. At the consumer end of things this includes features such as on-device photo editing, calendar creation and mailbox creation. For the enterprise, the killer blow comes with on-device activation and over the air (OTA) operating system updates, eliminating the requirement for iTunes in deploying iOS devices. Delta updates are also possible now, meaning that it will no longer be necessary to download the whole OS each time Apple issues a change. Backups will be achieved via the new iCloud service, and it remains to be seen how secure and acceptable this proves to be for enterprises (at this point in time I am unable to test all of the iCloud features.)

So nothing earth shattering, but a steady evolution of the system to make it ever more acceptable to enterprise customers. Apple could, and should, have gone further, however.

Multiple email signatures with per-account defaults is a feature to which users are accustomed on their desktop mail clients. This is still missing from iOS and, while not a major problem, is something I find irksome on a daily basis as a business user.

More serious is the continued omission of support for the iOS Data Protection APIs by Apple’s own “business” apps – Pages, Keynote and Numbers. Apple announced Data Protection with a fanfare with the release of iOS4 and informed us that, although Mail was the only native app to support those APIs back then, others would quickly follow. That appears to be an empty promise, since I am not aware of any other apps in the Apple stable that support the encryption APIs today.

This capability becomes even more important with the announcement of the multi-device synchronization capabilities of iCloud, which could easily see confidential documents created on a Mac desktop pushed out automatically and invisibly to iPhones and iPads, where they will rest unprotected.

Finally, we still do not have the ability to prohibit the creation and use of the escrow keybag when synchronizing to iTunes. This would be a simple feature to implement, and would provide an additional layer of protection for those relying on Data Protection capabilities to protect their data on mobile iOS devices. One other option would be to force permanent “PC free” mode, prohibiting iTunes synchronization at all, though that would require apps to support iCloud natively for file transfer, and is not something we are likely to see in the immediate future.

I have an Analysis Brief in production right now for our subscribers that will address the Data Protection capabilities in iOS4 and iOS5, and how they should be used to protect sensitive corporate data. Follow me on Twitter (@bwalder) to keep informed as new research is released.

[UPDATE]: Some have reported issues with S/MIME in iOS5, and the beta implementation does certainly seem to be a little "quirky" at the moment. I found issues when using certificates issued by public CAs such as Verisign, which I circumvented by installing self-signed certificates that I created using OpenSSL. Naturally, this does not play well in the world outside your test environment, but if you are just looking to test functionality, I found that both sending and receiving signed and encrypted messages worked fine using this solution.

Sunday, April 17, 2011

Curated App Stores, Security, And Why The Next Kindle Will Be An Android Device

We have been having some interesting discussions internally about the recent Android malware fiasco and how things need to be improved if Android ever wants to be taken seriously as an OS fit for use in an enterprise environment.

There has been some serious rhetoric against Apple's "walled garden" approach in recent months but, like it or not from a philosophical standpoint, it certainly provides more protection for users than the Android Market. Some claim that the Apple approach stifles innovation. Pah! (Yes, I said "pah" - add to that a "pish and twaddle", if you will.) One needs look no further than the sheer number of apps to shoot holes in that argument. Granted far too many of them are designed to emulate the passing of gas - some of us might argue that more controls are required, not fewer!

At the other end of the spectrum there are some truly excellent apps. Evernote, PDF Reader, TeamViewer, WebEx, GoToMeeting, Pages, Numbers, Keynote, QuickOffice, DocsToGo, SoundNote - these are all apps on which I rely daily. And for sheer awesomeness look no further than GarageBand and iMovie. No shortage of innovation and quality there then.

And from the point of view of the user - particularly the non-computer savvy user - all of this just works. Couple of clicks to search for your app. One click to purchase, download and install. And - most important of all - Trojan-free once it arrives. Curated app stores are essential to the well-being of the ecosystem.

Google needs to emulate that experience with its Market, though its very credo seems to suggest that will never happen. Yet without it the store will descend into anarchy, with users scared to purchase for fear of what new and terrible piece of malware they might be introducing to their phone or tablet.

So along comes Amazon from nowhere, and in one fell swoop it might have beaten Google at its own game. Amazon has the position of trust. It has the customer review infrastructure in place. It already has our credit card details (who hasn't bought anything from Amazon?) And now it has an Android Appstore (TM) to go with it. Now all it has to do is make sure that the stuff it sells is safe.

It has promised to do that, by applying both quality control and security vetting to the app review process. So why wouldn't you buy from there rather than the Google Android Market? Well, I would - I already have. But my Auntie Edna probably wouldn't. It is way more difficult than the Apple process, and right now requires a multi-step process just to get the Appstore app on your phone. It is not that difficult, but it is certainly a sub-optimal user experience compared with the "It Just Works" approach of Apple.

So what needs to happen for the Amazon Appstore (TM) to succeed? Simple - it needs to arrive pre-installed on Android devices. Lots of them. And while I am sure Amazon is probably in discussions with a bunch of carriers to achieve that objective, what better way to make sure it happens than to ship it in huge numbers on Amazon's very own Android tablet - The Kindle IV?

Give us that great Kindle experience with Android flexibility at a super-low price point, and you might just have your iPad-killer... I certainly haven't seen one among the devices announced so far.

Don't forget to follow me on Twitter (@bwalder) to be kept informed of new research.

Thursday, March 17, 2011

Secure Low-Cost Data Sharing and Collaboration With iPad

Cloud-based storage services offer a low-cost alternative to high-end enterprise-class collaboration tools. At the same time, a new class of intelligent mobile devices — smartphones and tablets, spearheaded by the iPad — is driving the need to share sensitive data while on the move. For many organizations, the basic requirement is the ability for a small group of users to share a set of documents related to a specific project.

With business needs and the sudden availability of viable mobile platforms driving this initiative, IT departments are struggling to determine the security of the cloud and mobile platforms that compose this new infrastructure. Senior management's adoption of new and attractive devices, such as the iPad, makes it extremely difficult for IT departments to prohibit their use on corporate networks. Dropbox and iPad have become an irresistible combination.

Given the availability and low cost of these low-end solutions, users are taking advantage of them in their own homegrown solutions, often regardless of corporate policy. Thus, it is imperative that IT departments address these low-end solutions quickly to restrict their use, or transition users to a more appropriate environment to ensure that those solutions are as secure as possible.

I have a new Analysis Brief in the pipeline that examines the security issues surrounding the use of cloud-based data sharing and collaboration services to share sensitive corporate data with your iPad.

Follow me on Twitter (@bwalder) to be kept informed of new research.

Wednesday, February 23, 2011

Testing Times In Security

I am speaking to more and more enterprise clients who are doing their own in-house testing of security devices. Some of them invest in large, dedicated test networks and knowledgeable personnel, others invest in a single rack of virtualization and load generation equipment. But for all of them, the aim is the same - reduce risk of compromise by throughly testing equipment against enterprise-specific criteria before purchase.

Security vendors' marketing claims are often exaggerated, and frequently do not reflect real-world or enterprise-specific conditions. Performance of complex network security devices is difficult to determine accurately, yet failure to do so can result in significant negative impact on the network should the wrong device be selected or a chosen device configured incorrectly.

Testing is not necessarily about proving that the most-capable, most-expensive product is the best choice. A well-designed testing plan may actually show that a lower level of performance is acceptable at certain points on the network, and this can reduce purchase and deployment costs. IT organizations that do not perform relevant tests in- house may introduce serious security and performance issues to their networks by purchasing underspecified devices, or may overspend significantly on higher levels of performance and coverage that are not required.

Security effectiveness of complex security devices is often the most-difficult area to evaluate, because it requires expertise with attack traffic, and even live exploits. Evasion testing in particular seems to be a challenge for even the best-equipped enterprise test labs (hardly surprising, since it also appears to be something of a challenge for many of the security vendors out there!) For those with the requisite expertise in-house, however, a basic security effectiveness test bed can be created at a relatively low cost using virtualization technology and commonly available test tools. Virtual machines can be used to create an environment that is safe and repeatable, allowing security-conscious organizations to verify the often inflated vendor marketing claims.

Although it requires little in the way of specialized expertise and test equipment, testing the user interface (UI) and device management capabilities is often overlooked when evaluating complex network security products.

This is a mistake, however. A management system that does not meet organizational requirements reduces the effectiveness of a security solution. If a task is too difficult to perform, then it will be executed poorly or inconsistently, if at all. Operational costs can also be reduced drastically via well-designed centralized management systems.

Those who take testing seriously also implement continuous testing programs, making them an integral part of the ongoing security maintenance regime. I have seen numerous instances in the past of a single poorly written signature crippling the performance of an IPS. Firmware updates can also break previously solid inspection processes — anti-evasion techniques appear to be particularly prone to disruption between firmware updates.

Once initial deployment of your security device is complete, perform a full benchmark test to establish a baseline for your existing deployments. Every time a new firmware upgrade, signature pack update or change in security policy is applied — however minor it may seem — the device should be retested and the results compared against the baseline. In-place, ongoing penetration tests on the live network can also help to identify changes in security effectiveness following updates. This process of continuous monitoring makes it possible to monitor, identify and correct adverse impacts on performance or security effectiveness.

We currently have a number of ANalysis Briefs in the pipeline covering performance testing, security effectiveness testing and managing security devices. Together these will provide you with plenty of background material gleaned from almost 20 years in the security testing industry, along with some actionable advice to help you avoid costly mistakes when selecting and implementing complex network security devices.

Don't forget to follow me on Twitter (@bwalder) to be kept informed of new research.