Monday, 18 July 2011

At the recent OWASP AppSec EU conference, Dan Cornell provided an update on the technical issues and risks posed by the use of applications on smartphones, building upon his talk last year. The talk focused on the security testing side and provided a great introduction to this area and is well worth a read if you are involved with mobile applications.

From a wider Information Security focus and as an aid to anyone dealing with the implementation of smartphone based apps, I have developed a short questionnaire that can be used to gain an initial understanding of the application and highlight any specific areas of risk (such as sensitive data being stored on the smartphone without encryption!). This can then be used to conduct more targeted assurance activities.

The Questionnaire

Data Related:

Could you please describe the type of data involved with this app?

Could you please confirm if any information will be stored on the device?

If stored, will the data be encrypted within the app itself?

Does the app encrypt data during transit?

If so, what method of encryption is used?

App focused:

What platforms will be supported?

Where will the app be available for download?

Does the app synchronise data to other end devices (such as via iTunes to user laptop)?

Does the app use 3rd party active content?

Supporting Infrastructure:

Please describe how the app will be updated / content managed?

Will web services be used to manage the app?

If so, will the web services infrastructure sit within owned networks?

Technical Assurance:

Will the app be subjected to a security code review as part of development process?

If so, will the report be shared?

Will the app be subjected to security testing as part of the development process?

Tuesday, 12 July 2011

The recent BCS Information Security Specialist Group conference in Edinburgh focussed on the threat from Insiders. The main focus was on how individuals with authenticated access can do real damage to an organisation. A lot of effort within organisations goes into tackling the threat from Insiders and it is often treated as a separate category of threat. But is this right? Should the Insider threat be treated in isolation?Defining the Insider Threat

The insider threat is often defined as someone acting from within an organisation’s internal systems. This is principally treated as an individual with authenticated access and stands in contrast to an external attack which originates outside of the organisation and does not have permission to access to the network. These definitions result in these threats being treated separately and in isolation of each other.

The idea of there being a difference between an insider and outsider is predicated by the assumption that there is a clear boundary between the internal network of an organisation and the outside world. However, in today’s world the reality is very different. There is often a blurred line between what is an internal system and the outside world. The boundary is no longer at the firewall, the real edge of your network is now the user’s device, be it a smartphone, laptop or home pc (using remote access to the organisation). This is because the end user device has Internet connectivity for email or web browsing and in many organisations egress filtering is lacking and services such as instant messaging can be used. This enables organisations’ internal systems to become visible to an external attacker, even where inbound filtering has been implemented. These recent developments in end user devices therefore provide greater opportunities for an external attacker to compromise a device and use it to access an internal system.

External Attack – Inside Threat

Historically, where an attacker is able to compromise a user’s device, the expected action is to then use this to attempt further compromise of the internal network. This approach can be quite noisy and may prompt internal alerting, but if successful enable the attacker to gain access to internal systems. This method makes it obvious that the external attacker has broken into the network.

However, an external attacker can also choose to masquerade as the user within the internal network and access systems and resources within the context of that user. One approach to achieve this would be for the attacker to use the user’s security token that is stored within the operating system. It is possible to ‘steal’ this token and assume the user’s identity within the internal network. At this point the external attacker can be seen to be an ‘insider’ threat as they are now conducting attacks against the organisations data as an internal user would.Detecting the Insider – External Attack

An external attack can develop this technique to gain the information required without arousing suspicion. If the user doesn’t have the level of access required the attacker can steal other valid tokens and use this approach to escalate a user’s privileges, even to administrator level. Doing so enables the attacker to then target information held within the network without the need to conduct further hacking or compromises. The key point here is that the traffic generated would look like normal network traffic and access to systems would be as valid users.

Insider / Outsider - Does it Matter?

This example demonstrates that an external attack can act as an ‘Insider’ Threat would. Organisations continue to define the Insider threat as the authenticated user within their firewall, however, the recent developments in end user devices has provided greater opportunities for an external attacker to access a network masquerading as an ‘Insider’. The Insider Threat is based on out-moded definitions of what is inside the network and no longer effectively describes the threat. These definitions are no longer relevant. So how do we deal effectively with the ‘Insider Threat’?

As an external attacker could choose to access a network and masquerade as an insider, there is little value in focussing too much on the classic insider / outsider threat categories. Instead organisations should focus their security on what an attacker could do, regardless of their starting point, and look to be able to detect / react to and recover from ‘any’ compromise. By taking this resilient approach to security, organisations are better equipped to identify, respond and recover from an attack regardless of where it originated.

Followers

Blog Disclaimer

All data and information provided on this site is for informational purposes only. The opinions expressed by individual Bloggers and those providing comments are theirs alone, and do not reflect the opinions of 7 Elements Ltd. 7 Elements Ltd is not responsible for the accuracy of any of the information supplied by the Bloggers.