13 posts • joined 22 Dec 2007
There are a lot of comments here...
...so this may have been covered already. Apologies if it has.
Some poor guy is now being pilloried as being responsible for this because he 'commited' it. The real culprit is the QA process that lead up to that commit. Name them.
Ethical Hacking <> Any Idea of Governance
They may be certified to hack you but they have no $%$^ idea how to protect you.
Cloud comes with a whole range of risks that are very difficult to address. They obviously did not employ their own 'skills' on their own Cloud provider.
Or maybe they did...which gives you a lot of confidence in their 'certified' graduates.
Re: What about financial security/
MegaUpload - Kim DotCom - if I have the references correct.
You should have no confidence it it is 'freemium' and limited confidence otherwise. They can be located anywhere and you probably don't have the $$$$'s to chase them if they decide to dump you.
@boltar Re: Oh the security....
The resources required are in this case related to the effort dedicated to governance. This doesn't really correlate with the complexity of individual systems but will be correlated with the complexity of the systems run across the organisation and the impact of a compromise of those systems.
Looking at it from a different perspective, Email may be (relatively) simple (ever configured sendmail?) but the contents of email will be very sensitive. This warrants a high level of governance.
So the simplicity of the technology is trumped by the sensitivity of the information it maintains.
@Mike Pellat Re: Oh the security....
It comes down to whos contract is being executed. If it is the service providers then what you say is very true. If, on the other hand, it is your contract in your jurisdiction then you may have a leg to stand on. But if it is a big provider you are probably signing their contract.
Oh the security....
"Some mission-critical enterprise apps will not lend themselves to cloudification and security concerns for some will trump cost considerations. But why would you not use cloud versions of software such as CRM, email, billing and office apps?"
This is all from a very jaundiced security perspective, and it is only scratching the surface.
A good starting point is probably ISO27K certification to verify that the controls are documented and then SOC1 and SOC2 certification to verify that the controls are being operated effectively. Map this to a not uncommon scenario where the 'service provider' you are dealing with is using compute infrastructure from a second party who is, in turn, using physical facilities from a third party. The physical guys may have heard about SOC1 and may well have ongoing certification because it's good for business, the layer up may have heard of ISO27K and are likely to be getting certification 'any time now' but a SOC2 will bring a wrinkle to their brow. The organisation that your business wants to deal with is looking at you blankly on all fronts.
Stop that or you will go blind.
Are you getting on top of your network/system/application/user/admin/.... monitoring? Have a SIEM and starting to get some value out of it? Factored that into your Cloud solution? So you have events arriving via syslog or you are polling using WMI to get a view of your assets that is comparable to that which you get with on-premise solutions? Dream on.
Dependence on exposed services.
Calling web services or doing other fancy stuff with DNS resolution on public DNS servers? Are you factoring in the risk of these services being compromised? The more entangled you get from an infrastructure perspective with your cloud service provider the greater the likelihood that you will have to start looking at these issues.
Disgruntled employees. Is it a concern for you within your organisation, how do you deal with them? How do all the potential organisations in your supply chain deal with them (see Due Dilligence).
There are some interesting challenges here. Is the cloud provider signing a contract with you are are you signing a contract with them, if the latter then you are going to have very little control. The whole due dilligence here will also be way beyond your procurement folk and concepts like data sovereignty are going to take a lot of explaining. If you are also moving into an environment where date breaches can attract serious penalties (like here in the land of Vulture South) then you have to try and factor that into the contractual arrangements.
So you have a contract. Fabulous. Has anyone seriously seen all the clauses in the contract managed and enforced? Have you estimated how much effort that will take given that you have lost visibility of a lot of things that are important?
"CRM, email, billing and office apps". These are all probably significant if you have data breach legislation.
Is it really worth the effort?
Since June last year
I have seen GET /HNAP1/ HTTP/1.1 requests dropped at my (personal) edge servers. It ramped up in December last year.
So it has been known for quite a while?
Do you ever really know what you are buying?
I found out about the embedded Computrace application late last year. I checked up on one vendor and found that they didn't hide the fact that this was part of their package, they just didn't broadcast it.
Haven't read the small print, but this should be in the large print on any product that you are purchasing. It falls right into the sort of embedded capability that the Snowden leaks revealed and really begs the question as to who is funding this.
Would be really interesting to see an analysis of what it can potentially do.
Your slip is showing...
Well your age anyway :-)
No progress then....
The German magazine c'T demonstrated the same thing in 2002 (an English translation of the report is not hard to find with Google).
Money, Money, Money!
The price of software is based on what the market will bear. Different segments of the market will bear different prices - e.g. consumer -v- corporate - and have different buying patterns - eg. single unit -v- volume.
Problem: How to extract maximum revenue across the entire market?
Answer: Pitch different 'versions' with different prices at each identified segment of the market with careful feature selection to minimise uptake of lower priced versions in segments targeted for higher priced versions.
"... the most CISC ever..."
Actually the VAXen were microprogrammed beasts and at the core you had a RISC processor. You could, at one time, buy some software from DEC to roll your own microcode. So instead of having all these macros in RISC assembler to perform common operations they just appeared as part of the micro-coded instruction set.
Are they fit for any purpose?
A sequence diagram usually only represents one path, out of many, through a use case. They don't handle exceptions very well and they don't handle message content particularly well.
All of this is evident in the examples given.
Why not use BPMN - Activity diagrams ++ - instead?
- Mounties always get their man: Heartbleed 'hacker', 19, CUFFED
- Analysis Oh no, Joe: WinPhone users already griping over 8.1 mega-update
- Leaked pics show EMBIGGENED iPhone 6 screen
- AMD demos 'Berlin' Opteron, world's first heterogeneous system architecture server chip
- OK, we get the message, Microsoft: Windows Defender splats 1000s of WinXP, Server 2k3 PCs