Events

The road to secure Smart Cars: ENISA approach

At TROOPERS16, Dr. Cédric LÉVY-BENCHETON an expert in cyber security at ENISA, the European Union Agency for Network and Information Security. Dr. Cédric LÉVY-BENCHETON  holds a presentation about cyber security of IoT (Internet of Things) and smart cars he presents the current threats in IoT and Smart cars. ENISA is an agency of the European Union. ENISA assists the Commission, the Member States and, the business community in meeting the requirements of network and information security. Continue reading “The road to secure Smart Cars: ENISA approach”

Continue reading
Building

ENISA Smartphone Secure Development Guidelines

I just stumbled across this document recently published by the European Network and Information Security Agency (ENISA). It’s part of their smartphone security initiative which we’ve already mentioned in this post.

Here’s an excerpt from the introduction:

“This document was produced jointly with the OWASP mobile security project. It is also published as an ENISA deliverable in accordance with our work program 2011. It is written for developers of smartphone apps as a guide to developing secure apps. It may however also be of interest to project managers of smartphone development projects.

In writing the top 10 controls, we considered the top 10 most important risks for mobile users as described in (1) and (2). As a follow-up we are working on platform-specific guidance and code samples. We hope that these controls provide some simple rules to eliminate the most common vulnerabilities from your code.”

After having a first look at the document’s content I can, while not being a developer myself, state there’s a lot of valuable guidance in it. Which is particularly useful as our assessment experience shows that quite some things (examples to be discussed in this upcoming talk at Troopers) can go wrong as for application security on smartphones.

have a good one

Enno




					
				Continue reading
				
					
				
			
			
Building

iTrust. Or not?

A few days ago (on 10/12/2011) Apple launched its new cloud offering which is called — who would have guessed 😉 — iCloud. Since we’re performing quite some research in the area of cloud security, we had a first look at the basic functionality and concepts of the iCloud. Its main features include the possibility to store full backups of Apple devices (at least, an iPhone, iPad or iPod touch running iOS 5 or a Mac running OS X Lion 10.7.2 is required), photos, music, or documents online. The data to be stored online is initially pushed to the cloud storage and then synchronized to any device which is using the same iCloud account. From this moment on, all changes on the cloudified data is immediately synchronized to the iCloud and then pushed to all participating devices. At this point, most infosec people might start to be worried a little bit: The common cloud concept of centralized data storage on premise of a third party does not cope well with the usual control focused approach of most technical infosec guys. The resulting concerns can be attributed to several main cloud computing related risks (which are proposed by ENISA and actually very valuable work:

  • Lock In: According to the way the cloud functionality is integrated into iOS and OS X , usage of the iCloud might result in strong lock in effects. There is neither the possibility to use different backend cloud storage for the functionality nor the possibility to develop a product which provides similar functionality (see later paragraphs for examples).
  • Isolation Failure: is probably the most present threat for many IT people, since it is highly related to technical implementation details. It includes, but is not limited to, breakout attacks from guest systems due to vulnerabilities in the hypervisor or to unauthorised data access due to insufficient permission models in backend storage. Thinking of the trust factor consistency, Apple’s history of cloud based services was not their “finest hour” (as Steve Jobs stated during his keynote on iCloud). Remembering this talk and the awkward MobileMe vulnerabilities, we would agree with that 😉
  • Loss of Governance: The loss of governance over data in the cloud is kind of an intrinsic risk to cloud computing (also refer to the proposed system operation life cycle and the motivation given here). Again, referring to explanations about the technical iCloud implementation in the later paragraphs, this loss might be even more relevant in the iCloud environment.
  • Data Protection Risks: Handing over responsibility for the storage of data to the cloud service provider, a customer also hands over the possibility to protect his valuable (or more concrete: personal) data by controls of his choice. Reviewing Apple’s terms of service for the iCloud, the following paragraphs are somewhat related to data protection issues: You understand that in order to provide the Service and make your Content available thereon, Apple may transmit your Content across various public networks, in various media, and modify or change your Content to comply with technical requirements of connecting networks or devices or computers. You agree that the license herein permits Apple to take any such actions. And in addition, the Apple Privacy Policy states the following: You further consent and agree that Apple may collect, use, transmit, process and maintain information related to your Account, and any devices or computers registered thereunder, for purposes of providing the Service, and any features therein, to you., which kind of reminds of the Dropbox Terms of service which even state that they are allowed to transfer your data to anybody if it is necessary in order to assure the quality of the offered service. Thinking of the trust factor components, all of these risks are getting even more relevant since Apple relies on third party cloud services (which are Amazon Web Services and Azure, according to several sources, including this one), which conclusively must also fulfill certain security requirements in order to lower the vulnerability factors for the presented risks.

There are some more risks according to the ENISA study, but those are beyond the scope of this post. If we do such rough assessments as sample exercises during our cloud security workshops, the participants usually ask what “they can do”. Possible controls can be divided into two groups: controls to reduce the risk to a reasonable level and controls which prohibit the usage of the particular service. When analyzing the cloud, the control always mentioned first is crypto. Speaking of cloud storage, crypto is a valid control to ensure that unauthorized access (e.g. due to isolation failure/physical access/subpoena) to data has no relevant impact. The only requirement is that the encryption is performed on client side (depending on the attacker model and whether you trust your cloud service provider). For example, Amazon provides a feature which is called Server Side Encryption which encrypts any file that is stored within S3. Additionally, Amazon allows the implementation of a custom encryption client which enables customers to perform transparent encryption of all files which are stored in S3. The analysis of the security benefits, attacker models, and operational feasibility of these controls will be the subject of yet-another blogpost, but at least Amazon offers these encryption features. The offered services of the iCloud differ a little bit in functionality (for example, the iCloud iTunes version is a kind-of music streaming platform), but basically there are two API functions which allow access to the iCloud backend. First, it is possible to store documents (where documents can be complete directory structures) in the iCloud, second, a so called key-value store can be accessed. The access is encapsulated in dedicated API calls which take care of the complete data transfer, synchronization, and pushing operations using an iCloud daemon. So any use of the iCloud is strictly connected to an app (I would have called it application ;-)) which has to use the introduced iCloud API calls. Even though I’m not that familiar with the iOS/OS X architecture, I would have guessed that it would have been easily possible to add client side encryption using the internal keychain and usual cryptographic mechanisms. Still, this is not the fact and it is questionable, regarding the user experience oriented focus of Apple, whether this feature will be implemented in the future. This lack of encryption possibility brings up the second class of controls, which shall restrict the iCloud usage. This is especially important in corporate context, where full backups of devices would potentially expose sensitive corporate data to third parties. Even though the usage might be restricted by acceptable use policies, this might not enough since the activation of this feature can happen accidentally: If a user logs in once into the iCloud frontend, which is possible using a regular apple ID, the data synchronization is enabled by default and starts immediately (refer also to the quoted terms of service above). Since most corporate environments use MDM solutions, it is possible to restrict the iCloud usage at least for iOS based devices. The corresponding configuration profiles offer several options to disable the functionality:

  • allowCloudBackup
  • allowCloudDocumentSync
  • allowPhotoStream

For today, this little introduction to iCloud and some of its security and trust aspects will be finished here. We will, however, continue to explore the attributes of iCloud more deeply in the near future (and we might even have a talk on it at Troopers ;-).

So stay tuned… Matthias

Continue reading
Misc

Appstore security: 5 lines of defence against malware

A few days ago the European Network and Information Security Agency (ENISA) published this quite interesting document with the exact title. Here’s what it covers:

“The booming smartphone industry has a special way of delivering software to end-users: appstores. Popular appstores have hundreds of thousands of apps for anything from online banking to mosquito repellent, and the most popular stores (Apple Appstore, Google Android market) claim billions of app downloads. But appstores have not escaped the attention of cyber attackers. Over the course of 2011 numerous malicious apps were found, across a variety of smartphone models. Using malicious apps, attackers can easily tap into the vast amount of private data processed on smartphones such as confidential business emails, location data, phone calls, SMS messages and so on. Starting from a threat model for appstores, this paper identifies five lines of defence that must be in place to address malware in appstores: app review, reputation, kill-switches, device security and jails.”

Just read through it and while I’ve never been a big fan of STRIDE (mainly due the application centric approach which simply is not my cup of tea) I have to say it’s applied elegantly to the “app ecosystem” described in the paper.

The doc somewhat accompanies this one titled “Smartphones: Information security risks, opportunities and recommendations for users” (released by ENISA in late 2010), which is a valuable resource in itself.

Overall excellent work from those guys in Heraklion, providing good insight from and for practitioners in the field.

Have a great weekend everybody

Enno

Continue reading