17 years. That’s a long time. The last time the US Government shut down was December 1995 through January 1996. I was working for META Group at the time, probably on an airplane heading to a meeting with some client. I wasn’t married yet. I could sleep in on a Saturday. Those were the days. Life was fundamentally different. Looking back I don’t remember the specifics of what happened during the last shutdown, as that group of politicians battled each other over funding this, that, or the other thing. In fact, until this latest shutdown because a possibility, I didn’t even remember it happened in the first place. 17 years later, in my mind that shutdown was an inconsequential footnote in history that I needed to look up on Wikipedia to even remember it happened.
I suspect we will see the same outcome this time. 17 years from now I doubt I’ll even remember how this group of politicians fought over funding this, that, or the other thing. The more things change, the more the stay the same. Negotiating deadlines are blown, activities are impacted, and people (a lot of people) aren’t working today because these folks can’t find the middle ground.
But they’ll work it out. They always do. The last time the shutdown lasted for a total of 28 days. Maybe this one will be shorter. Maybe longer. The only thing I know for sure is that it will be more visible. With social media, you’ll be seeing tweets from folks out of work and Facebook blasts talking about how they are right and the opposition is wrong. So even though it’s the same, it will feel worse because we will see much more of it. That’s just the way things go down nowadays.
We know how this movie ends. At some point they will make a compromise. Both sides will claim victory. Everyone will get back to work. Programs will be funded. Money will be squandered. Life will go on. Which is why it’s hard for me to get fired up about this stuff any more. The system is broken, but it’s the one we have. My efforts are far better spent worrying about the things I can control, and the idiotic machinations in Washington just aren’t on that list.
So shutdown all you like. I have writing to do.
Photo credit: “Anarchist computer” originally uploaded by Michael Bingaman
We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too.
Defending Against Application Denial of Service
Firewall Management Essentials
Newly Published Papers
- Continuous Security Monitoring
- API Gateways
- Threat Intelligence for Ecosystem Risk Management
- Dealing with Database Denial of Service
- Identity and Access Management for Cloud Services
- The 2014 Endpoint Security Buyer’s Guide
- The CISO’s Guide to Advanced Attackers
Incite 4 U
- Distributing workloads won’t fill the gap: No, this isn’t my attempt to infringe on Rich’s cloud security coverage. I am talking about the significant security skills gap. In my CISO Roundtables at the IANS Forums this year, a very consistent theme has been the challenges of staffing. From finding qualified folks, to retaining the good ones, to keeping pace with technology… most CISOs spend a large (and increasing) portion of their time dealing with these softer personnel issues. After spending a day with HR, a firewall console probably never looked so good. Michael Santarcangelo explains in his CSO blog how believes that distributing the workload among operational groups is the answer. He even said: “We don’t need more security professionals.” Uh, WTF? That’s dead wrong. I’m not saying we don’t need help, or that we don’t need the rest of the organization to become more security aware. But they have no real incentive to be secure. So over the long run, they won’t. Period. We clearly don’t have enough skills internally to even work with the ops groups and business folks to help them become more secure. So there is a skills gap, and it’s serious – and no amount of internal redistribution is going to solve it. – MR
- MS RAMPing up: For those who don’t know, FedRAMP is the US government’s way of setting up a security baseline for cloud providers. While every agency (well, the ones still in business) needs to still meet its own requirements, FedRAMP is an assessment baseline they can leverage to reduce their overhead. So not every agency needs to deeply audit each cloud provider. Like most cloud security certifications, FedRAMP says the cloud meets a baseline, so you can focus on the bits you deploy above that. Microsoft Azure was just granted its FedRAMP certification (Okay, it isn’t a certification per se, but close enough). Microsoft is the first cloud service to get the sign off-from the Joint Assessment Board (DoD, DHS, and GSA), while Amazon has theirs from HHS and a third party assessor. Why do you care? Even if you aren’t a Fed (and you aren’t, because they aren’t allowed on the Internet right now for no apparent reason), FedRAMP, especially from the JAB, is a decent security baseline. It doesn’t mean you are ‘secure’ on that cloud, but it sure is a nice additional assurance. – RM
- Better memory: Oracle’s big announcement at OOW 2013 was an in-memory database option. With a single configuration change and a metric crapton of DRAM, you basically can run the database in memory. What does that have to do with security, you wonder? Absolutely nothing. This really does not change any threats to the database, to answer a question a couple of you have asked me this week. But what’s most interesting is that the database loads data into memory as columnar and row stores, and the query execution planner/parser makes it all work behind the scenes. This will be amazingly fast, and uncharacteristically “big data” for Oracle. Good move, and database weenies may rejoice. – AL
- To reduce complexity you need to understand it: Clearly a lot of the operational issues we face as technologists (and security folks specifically) are exacerbated by the increasing complexity of our environments. Cloud here, SaaS there, mobile in the other place, and make sure you keep all the crap we have been running for 20 years up and secure as well. Got it? But to manage things better you need to figure out a way to simplify. No one can manage that kind of complexity without serious automation, and increasingly orchestration. So it is interesting to see the folks at Infoblox open source their Tapestry tool, which measures network complexity. The tool is based on “a formula for complexity that accounts for the number of endpoints on a network and how they interact to perform key business functions,” which seems pretty cool. But I am not worried about the algorithms or the empirical relevance of whatever score this tool generates. I think this is an interesting way to track network change to make sure you know if complexity is trending in the wrong direction. Remember that if you are going to “React Faster and Better”, you need to be aware of what’s going on in your environment at all times. – MR
- Tokenization party: Adrian has written a few white papers on tokenization and both of us have been big fans of the technology for years. Despite that, the PCI Council has been slow to move (shockingly enough), we hear mostly due to vendor infighting and lack of guidance from the capos (card brands) in charge. Weirdly, the card brands seem to be coming out with their own tokenization standard. Of course they are. Until we know more, we cannot tell whether this ties directly to their systems or sets standards for payment processors (many of which use their own tokenization with customers). This smells like a pre-announcement, and probably won’t do anything to address back-end systemic vulnerabilities, but if you take payments keep an eye out – something is going to happen. – RM
- Hacking with Big Data: A recent Hacker News post by Paul Houle touches on some interesting ideas about using Infovore as a simple interface to leverage big data clusters. What caught my eye was the recurring idea that to discover interesting things in a big data cluster, you just try different queries on the data. In Paul’s words, that you can “run small jobs and get a quick turnaround can be transformational in the sense that it lets you try things out and ‘fail faster’”. That has been the huge challenge with SIEM/LM, and this is a possible solution, deriving security information via poking data sets with different questions, looking for something novel. This concept comes up a lot, but is clearly only appropriate for those who understand what questions to ask and can infer what the results mean. If you are purely reliant on out-of-the box reports and analytics, poking at a big data cluster will only disappoint you and irritate the cluster. – AL