Does Cloud Backup Meet CIA Requirements?

For most purposes, I am concerned with the CIA definition of security. Confidentiality, Integrity, and Availability. One implication of this is that if you don't have good  backups, you are FUBAR. And, since Murphy is alive and well, you will discover this at the worst possible moment.

I don't generally like to get into the Big Data and Cloud discussions on public fora, as there is entirely too much marketing noise. But sometimes I know of poor decisions being made, and I just can't resist.

It should be obvious by now that we have to bring analytics code to the data, not the obverse. But there are still organizations that want to sell cloud backups, and couch their 'solution' in big data terms. These are all really fashionable terms and all, but please price a OC-192 connection. That's also called a SONET 10G connection, because it very nearly is 10G. It is amazingly easy to saturate a 10G connection. Really. The server consolidation via virtualization shakeup has not yet played out, and you can ask your down-in-the-trenches network people, and you will likely get a couple of horrifying stories.

I'd be happy to hear what you are paying, if you have one. Perhaps prices have crashed, but it was recently in six figures. That's just the connection, not the storage on the other end. It may be very expensive to move Big Data. Things you might consider

• rate of data change
• required storage period
• required access speeds across tiers (on-line, near-line, archival)
• any compliance or regulatory issues (PII, PCI, etc.)
• if the data must be encrypted, how well do you trust key management

In some cases there should be discussions with the legal team and/or the auditors. In more cases it should involve discussions with the bean counters.

If you can do reliable backups into a cloudy infrastructure provider, the financial numbers work, and you feel as if you can trust their service, good for you. But if it were me, I'd have to be very, very convinced before I would forego having a local backup of important data on local tape. If you feel the same way, how does that affect the value proposition of cloudy backup?

Saturday security humor

Because

1. Trust can fail in unanticipated ways
2. It is Saturday, and I am looking at a computer

Valerie Hopkins turned this one up.

As a professional security consultant, I recommend that you have a nice day.

NSA overreach: is it actionable, or just random news?

It has been a busy day. The PRISM furor has the popular press in an uproar. I don't find it surprising at all. This sort of thing has a rather long history, and there were indicators that the status remains quo. That doesn't mean that I am unconcerned; once upon a time this sort of thing was made expressly illegal, and secret law is not a path to success in running a representative democracy.

The net effect on my day is that various people are pinging on me for either an opinion, or sympathy for their sense of outrage. IOW, I am busy, and it's an interruption. Ask yourself if this actionable, in the sense that you should immediately change your behavior or policies? In almost every case, the answer to that question will be no. Write your favorite politician (who are most of the problem, not part of the solution, with notable exceptions), or otherwise do what your conscience demands. But please, do not expect security professionals to be in a white-hot frenzy over this. Unless it's a marketing thing.

Many security practitioners are privacy advocates; it's security on a personal scale, and the same principles apply. Others may see it more from the perspective of a vendor selling tools or services. And some are purely pragmatic, wandering back and forth across that line, as circumstances dictate.

The people being quoted in the media at the moment are not practitioners; they are either managers with a large political bent, or purely politicians. What you are reading is about political agendas. It is of little practical interest to practitioners, because it is not actionable. Anything actionable will come later. Probably months or years from now.

In the meantime, there are more interesting things to think about. PKI is still broken, and possible solutions have been brought forward. Java stills hangs heavily around our necks (and I need to write Part 2 of that post) and Adobe Web products are pretty much as bad. The ability of government and industry to share information is still FUBAR, but there things we can do, today. We have no good handle on the problem of incident response (despite what you may read). We don't even handle code re-use particularly well.

That is the sort of thing that is actionable.

So, back into the trenches of real-world security.

Java Security Revisited--Part 1

Java Security Revisited--Part 1

I have already thrashed on Oracle Java security failings once, but it doesn't hurt to go on with it. There is a human cost to this, in stolen identities, banking details, etc.

At
https://blogs.oracle.com/security/entry/maintaining_the_security_worthiness_of
there is a post titled Maintaining the security-worthiness of Java is Oracle’s
priority.

This is as FUBAR as anything needs to be.

It is perhaps more appropriate to subsitute 'Establishing' for 'Maintaining' in
that title. Java has a long history of problems. You might want to go read that
5/17/13 post first. The one where I claimed that they had more or less fallen
on their sword, and admitted complete security FAIL.

Back now? Great. Let us start with a quote from that blog post. "Hi my name is
Nandini Ramani, I lead the software development team building the Java
platform. My responsibilities span across the entire Java platform and include
platform security."

This is The Man. The guy with the ultimate responsibility (save Larry Ellison,
who will probably fire him if results are not forthcoming, pretty damned
quickly).

"Over the past year, there have been several reports of security
vulnerabilities in Java, primarily affecting Java running in Web browsers."

Over the past year? I don't want to accuse Mr. Ramani of being dissengenuos on
a corporate blog; perhaps he has not been keeping up with even not-so-current
events. But let us look at open source intelligence.

I regard Brian Krebs as one of the foremost researchers of the business
mechanisms behind underground fora, exploit pack proliferation, and botnets,
and related matters. He is focused, talented, and has sources I will never
have. Read
http://krebsonsecurity.com/2010/10/java-a-gift-to-exploit-pack-makers/ in which
Mr. Krebs says, "I also found Java flaws to be the leading exploit vectors for
both the Crimepack and Eleonore exploit packs." This was in October, 2010, not
"Over the past year" and the rabbit-hole goes deeper than that.

At this point, I have no good reason to trust Mr. Ramani. I do, however, have
good reason to question his integrity, competence, or both.

Further down in the post, you will find that Java will be updated four times per
year, in sync with other Oracle Critical Patch Updates. This is obviously going
to increase the testing load for those who have to deploy this stuff. But my
focus is on security, and my take is that this should already be built into
your deployment workflow. If hasn't been, in the past, take it up-stream. Your
workload has certainly increased, and you need an increased budget. It's just
part of the ever-increasing cost of doing business with Oracle.

Mr. Ramani even provides helpful reminders. Summarizing:

February 2012 Critical Patch Update for Java SE provided 14 security fixes
June 2012 release 14
October 2012 release 30
(thus the total number of new security fixes provided through Critical Patch
Updates for Java in 2012 was 58)

February 2013 security releases provided 55 new security fixes
April 2013 Critical Patch Update for Java SE provided 42 new security fixes
(bringing the total number of security fixes released through the Critical
Patch Update for Java in the first half of 2013 to 97.)

The way Mr. Ramani probably does not want you to interpret these data is that
these numbers are a measure of how horribly broken Oracle Java security has
been, and how exposed you have been. Increased pressure on Oracle is indicated.
What else is out there, that you do not yet know about?

"The Java team has engaged with Oracle’s primary source code analysis provider
to enhance the ability of the tool to work in the Java environment. The team
has also developed sophisticated analysis tools to weed out certain types of
vulnerabilities (e.g., fuzzing tools)."

Sounds great, and while fuzzing is hugely useful, that usefulness has only one
domain. Gary McGraw, a recognized authority, pointed out in
Software Security: Building Security In, published by Addison-Wesley, that less
than 50% of vulnerabilities come from implementation flaws. Code analysis tools
do not find architecture flaws.

This is getting way too long, and I am not even remotely done. I am going to
have to continue this in a second part.