Everyone shuffles in slowly on the second morning of the con. I spent the pre-keynote hour with other attendees sitting around looking tired and comparing notes on gout symptoms. (PSA: if the ball of your foot starts hurting really bad one day, it’s gout, take a handful of Advil and go to your doctor immediately.)
- Impact Security
You can also see a bunch of great pictures from the event courtesy Catherine Clark!
The keynote this morning is from Robert “RSnake” Hansen, now of White Hat. It’s about blind spots we all have in security. Don’t take this as an attack, be self reflective.
Blindspot #1 – Network & Host Security
Internetworked computers is a very complex system and few of us 100% understand every step and part of it.
How many people do network segregation, have their firewall on an admin network, use something more secure than a default Linux install for their webservers, harden their kernel, log off-host and log beyond standard logs? These are all cheap and useful.
Like STS, it was only considered very tightly and the privacy considerations weren’t identified.
Blindspot #2 – Travel and OPSEC
Security used to be more of a game. Now the internet has become militarized. Don’t travel with your laptop. Because – secret reasons I’ll tell you if you ask. (?)
[Ed. Apparently I’m not security 3l33t enough to know what this is about, he really didn’t say.]
Blindspot #3 – Adversaries
You seed to be able to see things from “both sides” and know your adversary (personally ideally). Some of them want to talk! Don’t send them to jail, talk and learn. Yes, you can.
Blindspot #4 – Target Fixation
Vulnerabilities aren’t created equal. Severities vary. DREAD calculations vary widely. Don’t trust a scanner’s DREAD. Gut check but then do it on paper because your gut is often not correct. Often we have “really bad!” vulnerabilities we obsess about that aren’t really that severe.
Download Fierce to do DNS enumeration, do bing IP search, nmap/masscan/unicornscan for open ports.
Blindspot #5 – Compliance vs Security
These aren’t very closely related. Compliance gets you little badges and placated customers. Security actually protects your systems and data. Some people exercise willful negligence when they choose compliance over security. Compliance also pulls spend to areas that don’t help security. Compliance doesn’t care about what hackers do and it doesn’t evolve quickly.
Blindspot #6 – The Consumer
Consumers don’t really understand the most rudimentary basics of how the Internet works and really don’t understand the security risks of anything they do. They’re not bad or stupid but they can’t be expected to make well informed decisions. So don’t make security opt in.
We the security industry are not pro-consumer – we’re pro-business. Therefore we may be the first ones against the wall when the revolution comes. Give them their privacy now.
So pick one, work on it, we’ll be less blind!
Big Data, Little Security?
By Manoj Tripathi from PROS in Houston.
Big Data is still emerging and doesn’t have the mature security controls that older data platforms have.
Big data is a solution to needs for high volume, high velocity, and/or rich variety of data. Often distributed, resilient, and not hardware constrained (but sometimes is).
Hadoop is really a framework, with HDFS, Zookeeper, mapreduce, pig/hive, hbase (or cassandra?). He’ll talk a lot about this framework because it’s so ubiquitous.
NoSQL – Cassandra (eventually consistent, highly available, partition tolerant), MongoDB (consistent, partition tolerant).
Security is an afterthought in Big Data. It can be hard to identify sensitive data (schemaless). He says there’s provenance issues and enhanced insider attacks but I don’t know… Well, if you consider “Big Data” as just large mineable data separate from the actual technology, then sure, aggregate data insights are more valuable to steal… His provenance concern is that data is coming from less secured items like phones/sensors but that’s a bit of a strawman, the data sources for random smaller RDBMSes aren’t all high security either…
Due to the distributed architecture of hadoop etc. there’s a large attack surface. Plus Hadoop has multiple communication protocols, auth mechanisms, endpoint types… Most default settings in Hadoop on all of these are “no security” and you can easily bypass most security mechanisms, spoof, accidentally delete data… Anonymous access, username in URL, no perm checking, service level auth disabled, etc.
Hadoop added Kerberos support, this helps a lot. You can encrypt data in transit, use SSL on the admin dashboards.
But – it’s hard to configure, and enterprises might not like “another” auth infrastructure. It also has preconditions like no root access to some machines and no communication over untrusted networks. And it has a lot of insecure-by-default choices itself (symmetric keys, http SPNEGO has to be turned on in browsers, Oozie user is a super-user with auth disabled by default). No encryption at rest Kerberos RPC is unencrypted. Etc, etc, etc.
To Cassandra. Same deal. CLI has no auth by default. Insecure protocols.
NoSQL vulns – injections just like with SQL. Sensitive data is copied to various places, you can add new attributes to column families.
Practical Steps To Secure It
Cassandra – write your own authorization/authentication plugin. [Ed. Really?] But this has keyspace and column family granularity only. 1.2 has internal auth. Enable node-node and client-node encryption. If you do this at least it’s not naiively vulnerable. Also, use disk support for encryption.
Hadoop – basically wait for Project Rhino. Encryption, key mgmt, token based unified auth, cell level auth in hbase. Do threat modeling. Eliminate sensitive data, use field level encryption for sensitive fields, use OS or file level encryption mechanisms. Basically, run it in a secured environment or you’re in trouble. Apache Knox can enforece a single point of access for auth to Hadoop services but has scalability/reliability issues. Can turn on kerberos stuff if you have to…
Also. commercial hadoop/cassandra have more options.