When I recently discussed SaaS & cloud risk, with particular regard to Baynote, it received some attention, both positive and negative.
Having made Dr. Deviant's list for “stating the bleedin’ obvious” ;-), I must say it's hard to disparage the man's view.
Yet, there is a key point that eludes those detractors of my view that SaaS and the cloud present enhanced risk.
Yes, lots of software, operating systems, browsers, wikis, yada yada yada, ad infinitum, exhibit flaws and put users at risk of compromise. But most often, those resources at risk are also under those user's near or immediate control.
Not so of SaaS or cloud offerings.
When you commit your enterprise to the cloud, you yield control, plain and simple.
To which I can only offer, ask the right questions before doing so.
A recent comment on the heels of El Reg's coverage of the Baynote flaw discussion was written as if from my own keyboard (I assure you it wasn't), and I will use it to close, with my compliments to Raife Edwards:
The difference is that... IF... you own, and run, your own servers, or systems/software... AND, a "common vulnerability" exists, and is exploited... You MAY be vulnerable... you MAY have a security issue... you MAY be targeted... you MAY not have adequately protected your system... you MAY be hit by the problem... you MAY have issues, and losses... possibly.
If, however, you are dependent upon any, EXTERNAL, single point-of-attack/vulnerable-point... then you WILL be hit... you WILL be affected... you WILL have losses... and you WILL be totally-dependent upon EXTERNAL-interests in "fixing", and recovering... based upon THEIR competence, and on THEIR time-table... and, to suit THEIR perception of THEIR interests.
In other words, ALL YOUR EGGS in [SOMEONE ELSES] basket.
Precisely.
del.icio.us | digg | Submit to Slashdot
Russ McRee's HolisticInfoSec™ includes articles and research, as well as feedback and an occasional rant. HolisticInfoSec™ promotes standards, simplicity, tooling and efficiency in achieving holistic information security.
Subscribe to:
Post Comments (Atom)
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ... -
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
Ladies and gentlemen, for our main attraction, I give you...The HELK vs APTSimulator, in a Death Battle! The late, great Randy "Macho...
4 comments:
I love that last quote. I recently had a heated discussion with my developers on whether they should be able to use Google apps for managing communications. I was firmly against it in favor of a locally hosted and managed solution.
I found some serious holes in the local solution this week, and some of the developers reacted with "I told you so". However, I was able to patch and upgrade to fix them the next day. Google, on the other hand, is completely outside of our control.
That scares me.
@Russ - you can't have the title of "Capt. Obvious"... I refuse to give that one up.
Great job, keep at it...
Hosted Apps --> ASP --> SaaS --> Cloud Computing --> [Next buzz-word]
Hello again. I am prepared to be wrong - it does happen... :)
How does Company A managing their CentOS server in the cloud differ from Company A handing over the keys to someone like IBM to host in their Datacenter? Chances are if you are in the latter category, you have no local IT skills, and are reliant on IBM for their managed service.
Having seen the IT industry out-source, in-source and out-source again I would suggest that if Company A hired it's own technical infrastructure team to manage their own server farm then Company A's eggs are firmly in Company A's basket. The benefit the cloud gives you here is pretty clear I think (resilient infrastructure with no capital outlay).
If you host with IBM, or the cloud, you have the same leverage if they do not provide the service you need - vote with your feet. Admittedly that's not easy for an organisation once they are embedded.
At the end of the day, as application owners we are all at the mercy of the application vendors - look at the last couple of Microsoft patches - they got slated for finally fixing a bug that has been around for months.
I would suggest that the only added vulnerability the cloud gives over any other hosting solution (all else remaining the same) is the IP address range and that it could be used for targeting.
We run our own servers in the best datacentre in London. A week ago the air conditioning unit in the datacentre failed and the entire server room had to be shut down to prevent over-heating. We were down for 3 hours during this process.
The point is that unless you're running your own datacentre, you are still exposed to a certain degree.
Additionally, if the exposed risk lies with you, you are assuming you can fix it quicker than the collective ability of the Cloud's technical resources. If it was your flaw that caused the breach, you're assuming you'll be able to find and fix it? You might not.
Post a Comment