This
is a _very_ interesting paper just published by some researchers (mainly) from
RUB (Ruhr-University Bochum). Here’s the abstract:
“Cloud Computing resources are handled through control interfaces. It is through
these interfaces that the new machine images can be added, existing ones can be
modied, and instances can be started or ceased. Effectively, a successful attack
on a Cloud control interface grants the attacker a complete power over the
victim’s account, with all the stored data included.
We recently performed a Proof-of-Concept (PoC) implementation of certificate
based auth with iPads in some large environment. So far the focus has been
mainly on WLAN access; VPN and EAS authentication are going to follow in the
next step.
As we figure that the topic might be of interest for some of you, we’ve
extracted a certain, not-too-customer-specific part of the deliverable and
converted it into an
ERNW newsletter.
Special thanks go to Rene Graf for leading the project! 😉
After having introduced the basic elements of our concept of trust, control and
confidence in
this
post, today I’ll try to strengthen your (and maybe even my own as well ;-))
understanding of these ideas by applying them to another candidate, that is
Dropbox. Hence this post is mainly about performing a certain analysis method to
some object; conclusions as for the question if Dropbox is suited to be used in
enterprise environments processing sensitive data are out of scope and are left
entirely to you, the valued reader.
… the corrupt DEA agent in Luc Besson’s great movie “Léon (The Professional)”.
I’m sure quite some of you, dear readers, know the plot…
Just before the final shootout, when sending the first men of the NYPD ESU team
into Léon’s apartment, he tells them to “Be careful!”. After learning those men
got killed he just comments: “I told you”.
[btw: before yelling to bring “EEEEEEEVERYONE!!!!”, as those familiar with the
piece will certainly remember ;-)].
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.”
I’m currently involved in a “Remote Access Security Assessment” and you might be
wondering what exactly this means. Well, so did we. At least to some degree
(btw: last year we provided some notes on types of security assessments
here).
It happens quite often we’re brought into an organization to perform “a security
assessment” of “some item” (“our network”, “that new procurement portal”, “the
PKI” etc.). It happens as well the customer does not have a very clear idea of
the way such an assessment should be carried out (telling us “you are the
experts, you should know what to do”). Or the five people from the customer’s
side present in the kick-off meeting have five different concepts (ok, four. as
one of them only wants “to get that damned assessment done so we can finally go
live”) and we end up moderating their arguments on what should be tested, how
this should be done, when this is going to happen, which type of report format
is needed (obviously, there’s different ones, depending on the
goal/scope/methodology of the assessment…) etc.
This advisory
describes an interesting attack vector:
“In the period of December 2010 until August 2011, Cisco shipped warranty CDs
that contain a reference to a third-party website known to be a malware
repository. When the CD is opened with a web browser, it automatically and
without warning accesses this third-party website. Additionally, on computers
where the operating system is configured to automatically open inserted media,
the computer’s default web browser will access the third-party site when the CD
is inserted, without requiring any further action by the user.”
Hi everybody,
eye-catching title of this post, huh?
Actually there is some justification for it ;-), that is bringing
this excellent document covering the exact topic
to your attention.
Other than that this post contains some unordered reflections which arose in a
recent meeting in a quite large organization on the “common current iPad topic”
(executives would like to have/use an iPad, infosec doesn’t like the idea,
business – as we all know – wins, so bring external expertise in “to help us
find a way of doing this securely” yadda yadda yadda).
Which – given those nifty little boxes are _consumer_ devices which were
probably never meant to process sensitive corporate data – might be a
next-to-impossible task… at least in a way that satisfies business expectations
as for “usability”…[btw: can anybody confirm my observation that there’s a
correlation between “rigor of restriction approach” to “number of corporate
emails forwarded to private webmail accounts”?]
This again is going to be a little series of posts. Their main topic – next to
the usual deviations & ranting I tend to include in blogposts 😉 – is some
discussion of “trust” and putting this discussion into the context of recent
events and future developments in the infosec space. The title originates from a
conversation between Angus Blitter and me in a nice Thai restaurant in Zurich
where we figured the consequences of the
latest RSA revelations.
While we both expect that – unfortunately – not much is really going to happen
(surprisingly many people, including some CSOs we know, are still trying to
somehow downplay this or sweep it under the carpet, shying away from the –
obvious – consequences it might have to accept that for a number of environments
RSA SecurID is potentially reduced to single factor auth nowadays…), the long
term impact on our understanding of 3rd party (e.g. vendor) trust might be more
interesting. Furthermore “Broken Trust” seems a promising title for a talk at
upcoming Day-Con V… 😉