Tonight starts the Jewish New Year celebration – Rosh Hashanah. So L’Shana Tova to my Jewish peeps out there. I send my best wishes for a happy and healthy 5771. At this time of year, I usually go through my goals and take a step back to evaluate what I’ve accomplished and what I need to focus on for the next year. It’s a logical time to take stock of where I’m at. But as I’ve described, I’m moving toward a No Goal philosophy, which means the annual goal setting ritual must be jettisoned.

So this year I’m doing things differently. As opposed to defining a set of goals I want to achieve over the next 12 months, which build towards my 3 and 10 year goals, I will lay down a set of ideals I want to live towards. Yeah, ideals seem so, uh, unachievable – but that’s OK. These are things that are important to my personal evolution. They are listed in no particular order:

• Be Kind: Truth be told, my default mode is to be unkind. I’m cynical, snarky, and generally lacking in empathy. I’m not a sociopath or anything, but I also have to think consciously to say or do something nice. Despite that realization, I’m not going to stop speaking my mind, nor will I shy away from saying what has to be said. I’ll just try to do it in a nicer way. I realize some folks will continue to think I’m an ass, and I’m OK with that. As long as I go about being an ass in the right way.
• Be Active: As I’ve mentioned, I don’t really take a lot of time to focus on my achievements. But my brother was over last week, and he saw a picture from about 5 years ago, and I was rather portly. Since that time I’ve lost over 60 pounds and am probably in the best shape I’ve been since I graduated college. The key for me is activity. I need to work out 5-6 times a week, hard. This year I’ve significantly increased the intensity of my workouts and subsequently dropped 20 pounds, and am finally within a healthy range of all the stupid actuarial tables. No matter how busy I get with all that important stuff, I need to remain active.
• Be Present: Yeah, I know it sounds all new age and lame, but it’s true. I need to appreciate what I’m doing when I’m doing it, not focus on the next thing on the list. I need to stay focused on the right now, not what screwed up or what might (or might not) happen. Easier said than done, but critical to making the most of every day. As Master Oogway said in Kung Fu Panda:

You are too concerned about what was and what will be. There is a saying: yesterday is history, tomorrow is a mystery, but today is a gift. That is why it is called the ‘present’.

• Focus on My Problems: I’ve always been way too focused on being right. Especially when it doesn’t matter. It made me grumpy. I need to focus on the things that I can control, where I can have an impact. That means I won’t be so wrapped up in trying to get other people to do what I think they should. I can certainly offer my opinion, and probably will, but I can’t take it personally when they ignore me. After all, if I don’t control it, I can’t take ownership of it, and thus it’s not my problem. Sure that’s a bit uncaring, but if I let someone else’s actions dictate whether I’m happy or not, that gives them way too much power.
• Accept Imperfection: Will I get there? Not every day. Probably not most days. But my final ideal is to realize that I’m going to continue screwing things up. A lot. I need to be OK with that and move on. Again, the longer I hold onto setbacks and small failures, the longer it will take me to get to the next success or achievement. This also applies to the folks I interact with, like my family and business partners. We all screw up. Making someone feel bad about it is stupid and counterproductive.

Yes, this is a tall order. Now that I’m paying attention, over the past few days I’ve largely failed to live up to these ideals. Imperfect I am, that’s for sure. But I’m going to keep trying. Every day. And that’s my plan for the New Year.

– Mike.

Photo credits: “Self Help” originally uploaded by hagner_james

Recent Securosis Posts

With Rich being out on paternity leave (for a couple more days anyway), activity on the blog has been a bit slower than normal. But that said, we are in the midst of quite a few research projects. I’ll start posting the NSO Quant metrics this week, and will be continuing the Enterprise Firewall series. We’re also starting a new series on advanced security monitoring next week. So be patient during the rest of this holiday week, and we’ll resume beating you senseless with loads of content next week…

1. FireStarter: Market for Lemons
2. Friday Summary: September 3, 2010
3. White Paper Released: Understanding and Selecting SIEM/Log Management
4. Understanding and Selecting an Enterprise Firewall:
   • Application Awareness, Part 1
   • Application Awareness, Part 2
5. LiquidMatrix Security Briefing:
   • August 25
   • September 1
   • September 2

Incite 4 U

1. We’re from the Government, and we’re here to help… – Yes, that sentence will make almost anyone cringe. But that’s one of the points Richard Clarke is making on his latest book tour. Hat tip to Richard Bejtlich for excerpting some interesting tidbits from the interview. Should the government have the responsibility to inform companies when they’ve been hacked? I don’t buy it. I do think we systematically have to share data more effectively and make a concerted effort to benchmark our security activities and results. And yes, I know that is totally counter to the way we’ve always done things. So I agree that someone needs to collect this data and help companies understand how they are doing relatively. But I just don’t think it’s any government. – MR
2. Injection overload – Dark Reading’s Ericka Chickowski looks at SQL Injection prevention, and raises a couple good points. Sure, you should never trust input, and filtering/monitoring tools can help block known injection attacks while the applications are fixed. But for the same reason you should not trust input, you should not trust the user either. This is especially important with error handling: a proper error hierarchy to dole out graduated information depending upon the audience is necessary. It’s also incredibly rare to see a design team build this into the product because it takes time, planning, and effort. But you must be careful which error messages are sent to the user otherwise you may leak information that will be used against you. Conversely, internal logs must provide enough information to be actionable, otherwise people will wait to see the error again, hoping the next occurrence will contain clues about what went wrong – I have seen my own IT and app teams do this. Missing from Ericka’s analysis is a strategy on how to deploy the 5 suggestions, but these tips will be integrated into different operational processes for software development, application administrators, and security management teams. Good tips, but this is clearly a more complicated discussion than can be addressed in a couple paragraphs. – AL
3. Snake oil continues to be plentiful… – I suspect we’ll all miss RSnake when he moves onto blogging retirement, but he’s still making us think. So let’s appreciate that. One of his latest missives gets back to something that makes Rich’s blood boil – basically making faulty conclusions based on incomplete data. RSnake uses a simple analogy to show how bad data, opportunistic sales folks basically selling snake oil, and the tendency for most people to be lemmings, can result in wasted time and money – with no increase in security. Right, it’s a lose lose lose situation. But we’re talking about human nature here and the safety in doing something that someone else is doing. So this isn’t going to change. The point is to make sure you make the right decisions for the right reasons. Not because your buddy in the ISSA is doing it. – MR
4. When is Security Admin day? – LonerVamp basically purged a bunch of incomplete thoughts he’s had in his draft folder probably for years. I want to focus on a few of his pet peeves. First off because they are likely pet peeves for all of us. Yeah, we don’t have enough time, and our J.O.B.s continues to want more, faster, for less money. Blah blah blah. The one that really resonated with me was the first, No Big Box Tool beats a good admin. True dat. In doing my research for the NSO Quant project, it was very clear that there is plenty of data and even some technology to help parse it, and sort of make sense of it. You can spend a zillion dollars on those tools, but compared to an admin who understands how your network and systems really work? The tools lose every time. Great admins use their spidey sense to know when there is an issue and identify the root cause much faster. Although it’s not on the calendar, we executive types probably should have a way to recognize the admins who keep things moving. And no, requesting they cover all our bases for less money probably isn’t the right answer. – MR
5. Oil-covered swans – Regardless of whether you agree with Alex Hutton (on anything), you need to admire his passion. On the New School blog, he came a bit unglued yesterday in discussing Black Swans or the lack thereof. I have to admit that I’m a fan of Taleb (sorry Alex) because he put math behind an idea that we’ve all struggled with. Now identifying what is really a Black Swan and what isn’t seems like intellectual masturbation to me, but Alex’s points about what we communicate to management are right on the money. It’s easy to look at a scenario that came off the rails and call it a Black Swan. The point here is that BP had numerous opportunities to get in front of this thing, but they didn’t. Whether the resulting situation could have been modeled or not isn’t relevant. They thought they knew the risks, but they were wrong. More importantly (and I suspect, Alex’s real point) is that better governance wouldn’t have made a difference with BP. It was a failure at multiple levels and the right processes (and incentives and accountability) need to be in place at all levels to really prevent these situations from happening over and over again. – MR
6. Mixed messages – For all of the time and money SIEM and Log Management products are supposed to save us, we still struggle to extract meaningful information from vast amounts of data. Michael Janke’s thoughts on Application Logging illustrate some of the practical problems with getting a handle on event data, especially as it pertains to applications. So many event loggers are geared toward generic network activity that pulling contextual information from the application layer is tough because the event formats aren’t really geared for it. And it does not help that application developers write to whatever log format they choose. I am seeing tools and scripts pop up, which tells me a lot of people share Michael’s wishes on this subject, but it’ll be years before we see adoption of a common event type. We have been discussing the concept for 8 years in the vulnerability space without significant adoption, and we don’t expect much different for application logging. – AL
7. It’s someone else’s problem, until it’s not… – Funny, in last week’s Friday Summary both Adrian and I flagged Dave Shackleford’s hilarious 13th Requirement post as our favorite of the week. If you can get past the humor, there is a lot of truth to what Shack is saying here. Basically, due to our litigious business environment, anyone’s first response is always to blame someone else. Pointing fingers both deceives the people who need to understand (the folks with data at risk), but also reduces liability. It’s this old innocent until proven guilty thing. If you say you are innocent, they have to prove you are guilty. And the likelihood a jury of your peers will understand a sophisticated hack is nil. So Shack is right. If you’ve been hacked, blame the QSA. If you are a QSA, blame the customer. Obviously they were hiding something. And so the world keeps turning. But thanks, Shack, at least we can laugh about it, right? – MR