Incite 12/12/2012: Love the Grind
As I boarded the bus, which would take me to the train, which would take me into NYC to work my engineering co-op job at Mobil Oil, I had plenty of time to think. I mostly thought about how I never wanted to be one of those folks who do a 75-90 minute commute for 25 years. Day in, day out. Take the bus to the train to the job. Leave the job, get on the train and get home at 7 or 8 pm. I was 19 at the time. I would do cool and exciting things. I’d jet around the world as a Captain of Industry. Commuting in my suit and tie was not interesting. No thanks.
Well, it’s 25 years later. Now I can appreciate those folks for who they were. They were grinders. They went to work every day. They did their jobs. Presumably they had lives and hobbies outside work. After 20-something years in the workforce, I have come to realize it is a grind even if I don’t have a commute and I do jet around the world, working on interesting problems and meeting interesting people. But it’s still a grind. And it’s not just work where you have to grind. After almost a decade wrangling 3 kids, that’s a grind too. Get them to activities, help with homework and projects, teach them right from wrong. Every day. Grind it out.
But here’s the thing. I viewed those salarymen taking the bus to the train every day as faceless automatons, just putting in their time and waiting to die. But for some activities, being a grind doesn’t make them bad. And grinding doesn’t have to make you unhappy. In order to have some semblance of contentment, and dare I say, happiness, you need to learn to love the grind. It’s a rare person who has exciting days every day. The folks who can do what they want and be spontaneous all the time are few and far between. Or lucky. Or born into the right family… so still lucky. The rest of us have responsibilities to our loved ones, to our employers, to ourselves.
Again, that doesn’t mean some days the grind doesn’t get the better of me. That’s part of the deal. Some days you beat the grind, other days the grind beats you. So you get up the next day and grind some more. At some point, you appreciate the routine. At least I do. I have been fortunate enough to travel the world – mostly for work. I have seen lots of places. Met lots of people. I enjoy those experiences, but there is something about getting up in my own bed and getting back to the grind that I love. The grind I chose.
And the grind changes over time. At some point I hope to spend less time grinding for a job. But that doesn’t mean I’ll stop grinding. There is always something to do. Though I do have an ulterior motive for grinding day in and day out. I can’t make the case to my kids about the importance of the work ethic unless I do it. They need to see me grinding. Then they’ll learn to expect the grind. And eventually to love it. Because that’s life.
PS: Happy 12/12/12. It will be the last time we see this date for 100 years. And then it will be in the year 2112, and Rush will finally have their revenge…
Photo credits: Angle Grinder originally uploaded by HowdeeDoodat
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.
Building an Early Warning System
Understanding and Selection an Enterprise Key Manager
Newly Published Papers
- Implementing and Managing Patch and Configuration Management
- Defending Against Denial of Service Attacks
- Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments
- Pragmatic WAF Management: Giving Web Apps a Fighting Chance
Incite 4 U
Responsible agonizing: I don’t expect us to ever reach consensus on the disclosure debate. There are far too many philosophical and religious underpinnings, mired in endless competing interests, for us to ever agree. What’s responsible to one party always looks irresponsible to another, and even the definition of responsible changes with the circumstances. That’s why I am so impressed with Cody Brocious (Daeken)’s heartfelt discussion of his thought process and the implications of his disclosure this summer of a serious vulnerability in hotel locks. For those not following the story, Cody devised a way to easily unlock a particular lock model widely used in hotels, with under $50 in hardware. He discovered it years ago but only made it public this summer. A few weeks ago criminals were discovered using his technique for real world theft and the manufacturer subsequently had to open up a massive, very expensive, response. Cody weighs his thoughts on his decision to disclose and the consequences. Whatever your disclosure beliefs, this is the kind of thought and focus on customers/users that we should not only hope for, but expect. – RM
How much information is enough? Early in my career as a network analyst product differentiation was generally based on speeds and feeds. My thing is bigger than your thing, so you should buy it. We still see that a bit in network security, but as we move towards understanding the value of security and threat intelligence (check out the Early Warning series to learn more) I wonder how big is big enough. Over on the Risk I/O blog they talk about crowdsourcing vulnerability intelligence, but it’s really about aggregating information to determine activity patterns. Once you reach a certain point, does it really matter whether a vendor or service provider fields 5 billion or 65 billion IP reputation queries a day? Whether they have 10 million or 100 million sensors deployed around the world? I don’t think so. There is definitely a critical mass required to have enough information to statistically see things around the same time as everyone else. But anything beyond that is just trying to differentiate based on speeds and feeds again. – MR
It’s the law: If you follow Brian Krebs (and if not, why not?), you have seen the stream of posts on smallish companies having their bank accounts drained of hundreds of thousands of dollars. The script is sadly consistent: Company has its money siphoned off electronically by thieves without its knowledge. At least until it’s time to run payroll. And the bank’s typical response, if they provide one, is to point the finger at the customer, blaming them for sloppy security. But for the first time we have seen a civil court rule in favor of one of these small firms, stating the “bank’s electronic transaction security procedures failed to meet the standard required under the Uniform Commercial Code (UCC) as ‘commercially reasonable,’” making the bank liable for the fraud. Firms don’t address security unless there are financial penalties, but don’t expect a lot of change in security buying trends because banks already have monitoring systems in place. What will happen is that “commercially reasonable” security will be defined by banks as the absolute freakin’ minimum security they need to have, and validated through internal IT audit. But these situations will continue to be arbitrated by the legal system until a consistent standard is set. – AL
Driving up the cost of detection: Security folks have long been searching for some way to change the economics of online fraud. If we can make it more expensive for attackers, perhaps they will attack less or find another line of work. Fat chance on that. The malware arms race continues. First the researchers started building farms of virtual machines to analyze files. Then the attackers started detecting VMs and shutting down their malware to evade detection. So the ball is back in the researchers’ court, because testing by executing every possible malware sample in a separate physical machine would be infeasibly expensive. The only thing we can count on is more attacks and counterattacks. Even better, some new malware establishes a chat session with a compromised device to ask for sensitive information. That’s pretty bold – and requires us to continue training users not to respond to unsolicited calls, chats, or emails looking for personal information. – MR
Harnessing data analysis: Credit card brands and processors have been doing it for years: detecting misuse and failure by looking at meta-patterns in overall systemic transaction data. A fraction of a percent dip in transaction volume indicates a network failure, and a fraction of a percentage increase in total funds indicates fraud. And they have historic data to differentiate what should be happening from what is happening. Robert Lemos predicts that Catching Attacks From The Inside Means Crunching More Data, but that concept applies to all types of misuse – not just insiders and not just specific user actions. I expect big data systems to be harnessed for misuse detection in coming years because they are an inexpensive way to analyze trend data, for both the micro and macro views. Better still, this approach is both inexpensive and accessible_ – which means writing fraud detection scripts need not require months of painful effort. SIEM vendors will scream that they can already do this, but most of their products are so clumsy and complex that it is simply unfeasible for security staff to even try. Simple big data systems will likely fill the gaps until the rest of the SIEM and log management industry gets agile and accessible enough. By then it may be too late for that specific use case. – AL
The Big G lights up Amazon AWS and HP’s public cloud: In our first point/counterpoint here at Securosis, Rich and I discuss our views on a recent article from Gartner on IaaS Service Level Agreements.
Rich’s take: Don’t blame the SLA: Years ago I joked that the only two security controls you have in cloud computing are your contracts/SLAs and the cloud provider’s documentation. It must be 3-4 years later now, and my little joke is all too true. That’s why I was so amused when I read this article quoting Lydia Leong slamming AWS and HP cloud SLAs. Here’s a pro tip: what’s worst is often best – it all depends on what you want. AWS and HP are focused on delivering low-cost, highly dynamic cloud services. As a provider, it is impossible to deliver on agility and cost if you are locked into diverse or restrictive contracts. You simply lose the economies of scale. Amazon doesn’t negotiate their cloud contracts because to do so would destroy their efficiency and agility. Go to IBM if you want someone to FedEx you a contract to negotiate… your competitors will be happy to see you wait. – RM
Mike’s take: The lawyers won’t keep your systems up: Evidently legal shenanigans should take the place of solid survivability architectures. Our friends in Big Research recently called out Amazon for having crappy SLAs. And that’s news? Evidently you need to run your apps in two availability zones and have them both go down to trigger the SLA. Wait, you mean you actually need to architect for failure? And the nerve of those Amazon folks to actually mandate, through their contracts, that customers architect their systems for redundancy before demanding it from their providers. Let’s be clear: your customers and senior management don’t give a rat’s ass about the SLA. You get paid to keep your systems up and protected. Which requires technical chops – not legalese. That doesn’t mean you won’t push for the best SLA you can to mitigate your risk as much as possible. Of course you should. But if you think an SLA will save your job if the system craters as a result of poor architecture, you have another think coming. – MR
Actually, though, Rich and I don’t really disagree. Basically we both wrote up the same report and I figured I could get some creative dissonance going by positioning it as a point/counterpoint. But at some point we should start airing our dirty laundry, as we hash out our research positions… – Mike