How did your technical skills fare in 2010?

Well, my first full year at SAIC is coming to an end and it is time to take stock of what I've learned, technically, over the past year. I hope to have another blog on management, project, and customer engagement skills, because, truth be told and like it or not, I've grown more in that area than technically in the past year.

Now your day job shouldn't be the only thing determining the level of your technical skills, but it is obviously a major factor. In the last quarter, I picked up leadership/management responsibilities so I will mindful in 2011 to ensure that I at least maintain the skills I've got and not become "soft" and hands-off. This point has been made crystal clear to me as I've been reviewing folks resumes (but have seldom interviewed them) that have let their skills go. A cautionary tale. And some that that I have managed to interview, I've heard the line "I could learn that again if I needed to" one too many times. Folks hold on to the skills they hold precious, even if you have to do it on your own time or change jobs. It is just too easy, especially if you are doing well and making an impact for your organization to let things go.

Coding
The last year has been no different that other periods. Historically, coding occurs in fits and stops. At the beginning of the year I was involved in a research project where I was doing a bunch of Python development with MongoDB, but that ended early on. Near the end of the year more light scripting mostly using dpkt, scapy, and nfqueue-bindings for some protocol testing testing that will hopefully end soon so I can stop the dreaded commute two times a week to Tysons Corner.

Networking & Security Products
I really enjoyed working with ScreenOS on the lower end Juniper SSGs. Most of my firewall experience was Cisco (or PF) so it was a refreshing change of pace. It was a bit frustrating at first, both the ScreenOS CLI and WebUI are preferable to anything from Cisco has ever developed. On the other hand, I did not enjoy working with Garretcom industrial switches, especially their screwed up way of configuring trunk ports and and VLANs. Not to mention their screwed up Flash UI. Working with one of the wireless clients/bridge/APs commonly used by some of the armed services was also a mixed bag, but I learned a little bit about RF surveys and the pros and cons of Mesh vs. Bridge vs. Client/AP wireless architectures. And then there is Air Defense, which I probably haven't learned as well as I could have but there wasn't enough time. In the lab, I kept up my skills up with IOS and ASA based SSLVPNs, but this was actually something I first learned in 2009.

Design/Build/Test/Deploy
A few of my projects have been true engineering (as opposed to assessment) projects that involved specific requirements (either that were provided to us or we had to develop ourselves for the client) where we were responsible for network/system design, configuring all these components and finally bringing them to deployment and handing the components over the customer. The "big enterprise" operational/IT skills I picked up at Hewitt definitely helped here. A couple of projects have required designing and implementing a new wired and wireless network infrastructure (as well as the appropriate C&A activities necessary to connect it) and this has been an interesting challenge, sort of like putting together a puzzle as you figure out to connect all the various L2/L3 infrastructure and security devices together.

Miscellaneous Stuff
Besides fooling around with MongoDB for about a month solid, I learned that some of the RAID controllers on Compaq hardware are lame and that backing up and restoring ESX filestores can be extremely slow and painful if you have SATA drives. Hands-on experience (mostly just getting it working and defining an appropriate security architecture vs. hard core device hacking) with several different smart meters, collectors, and headends, but nothing to write home about and certainly nothing I'd pose for a newspaper for in front of my hacking gear. Last, but not least, I've had the pleasure working with a great new client of taking a deep dive into a popular SCADA system and architecting a real time vulnerability management solution that will be deployed in the new year. Didn't learn any new products here but definitely a new experience of developing a solution from scratch.

It seems like I should have done more than this, but perhaps this is even better than 2010. I learned some new products, APIs, and wrote a bit of new code. I guess it could be worse as a senior engineer for a large government contractor I could be writing technical proposals and pricing non-stop. Fortunately I've been able to dip down and keep my hands dirty now and then, in addition to the normal QA (and tough questions) to keep engineers honest and on track.

So it's been a decent year, but in 2011 I need to do better, and this will be a challenge as there is no doubt that more of my time will be involved managing employees as opposed to just leading projects.Undoubtedly I will need to do work on my own time to keep it real. Stay tuned for some goals I will define for the new year.

Five Quick Interview Tips for Security Folks

So I've been spending 1-2 days a week for the last month or two interviewing folks for some open reqs. And yes I'm still hiring.

I've done quite a bit of interviewing (on both sides of the table) over the years in both big and small companies. In terms of the "big guys" I probably view Microsoft's process as the "gold standard." I also interviewed onsite with Amazon a while back and definitely incorporated some of what I experienced as a candidate from these west coast firms in what I do as an interviewer. Early in my days at Cisco we also did some good interviewing of candidates.

But based on recent experience, here are some things I've noticed, both in terms of tips and turn-off's. Most of these are of these are common sense.

1) Speak in concrete and specific (vs. abstract and general) terms about deliverables, responsibilities, tasks, and accomplishments. Convey a clear sense of who you are, what you like to do, and what you have accomplished. What is your career trajectory? Connect the dots for me. Even if you are "paper security" person (as opposed to a hands-on technical type) you can and should speak in specific standards, documents, and processes and data.

2) If asked about a given technology, the wrong answer is "another team did that" or "we weren't allowed to do that." Even if it is true. Find another way. This is a common problem with IT/Operational types and makes it difficult for me to envision you working in consulting, R&D, or other roles where you need to be flexible and will fill gaps where you find them.

3) Admit that you have forgotten certain technical skills if you've been "doing security" (or anything technical) for any period of time. If you say you haven't forgotten anything, you are either lying or a robot. In the long run, it is better to communicate in clear terms what you do or do not know. Plus, if you do get hired, something you claimed you were able to do (but perhaps wasn't able to be verified during the interview process, for whatever reason) may come back to haunt you as you will most certainly be passed a task.

4) When asked a seemingly factual question, the wrong answer is "I don't know" or "I could google it and find out." That is not the point. The point is to figure out what you know "around" that problem space. Plus, you are not going to get off that easy. I will take the question down a notch.

5) If asked if you can code, never, ever say you took Java/C programming in college, but haven't done any coding since then. Even if it is true. The "Modern American Poetry" classes I took are just as relevant. And resumes should err on the side of fewer skills than more skills. It makes it a pleasant surprise when you happen to know something not listed on your resume. And realistically if you put Nmap or Nessus (and most security folks do) please know what these do, because I will ask.

Altitude Induced Peace and Grown Up [Security] Jobs

So while en route from PHX to BWI, late Thursday night after a couple of (what appear to be) successful days onsite with a new-ish client, I couldn't help but a feel a bit of satisfaction, or perhaps, more importantly, lack of restlessness that has characterized much of my infosec^H^H^H^H^Hcybersecurity career. Things actually made sense. My career had some sort of meaningful trajectory. I had not just been hopping around every 18 months for the the last decade. There was a method to the madness.

(Perhaps it is no coincidence that the we've finally settled and bought a house north of Baltimore, that I wasn't on pins and needles while out of town when talking to my wife, or that the start of the school year has gone surprisingly smoothly for my two oldest children, or that my oldest's BPD, et. al. is reasonably under control, but I digress)

Around the turn of the century (and perhaps longer), I definitely had a case of the what do I do next? What is the next big thing? How can I scratch that itch?

I got my start as a trainer, which was a monkey I had on my back for a few years, only made worse that I had a B.A. in English and History from an engineering school and that my first job out of college was as an 8th grade reading teacher of all things!

So I relished the chance to leave Trident (only after my stock options from the Veridian acquisition were safely deposited) on to a all too brief stint as a security consultant at SBC (where I mostly wrote proposals and coded tools nobody would ever use) to my 5+ years at Cisco (internal consulting, then R&D, then back again) which was just as frustrating as it was rewarding. Politics. Personalities. My own naiveté. But exposure to Big Corporate life and a hell of a lot of cool technology. Then, fleeing to a small company, which was also as rewarding as it was frustrating. Mostly the working at home thing and not having enough people to work with, which was maddening, because I found out I was more social than I thought, culminating in that fateful move to Chicago for operational IT work and a hell of a lot of Ruby coding. On call. Weekend upgrade. BSD! Then back to training because I was burned out of ops work and wanted an easy way to move back East. And I actually enjoyed teaching. Adults (in the military) and kids (when I was a middle school teacher).

What triggered my thoughts at 28,000 feet (or whatever 737-700s fly at Eastbound) was recalling how natural early in the morning it was to be up at the whiteboard in the meeting I was having: drawing network diagrams, proposing solutions, debating implementations, cracking jokes. How this was just like teaching--or at least how I liked to teach. And I realized that there was no way that I could have felt this comfortable if I hadn't had the last two (no, scratch that, three) jobs.

One of the best things about teaching at Tenable (more so with the Enterprise classes than my Nessus classes) was how I'd get all sorts of weird questions based on peculiar aspects of a student's network (or political) environment. This kept me on my toes. And before then, at Hewitt, getting just enough of a taste of the keeping-shit-running hell of operational work and large, complex, global networks that makes a SCADA system seem simple. And before that all the lessons learned from Dale (who was channeling Tom Peters) about projects and clients and who you really are. So despite the fact that I still haven't stayed in one place for more than 18 months in the last two years

But the "grown-up" part in the title? What is that about?

Perhaps because I was (or still am) only a mediocre bug-hunter (or pentester or whatever, though I loath the term) but that of vulnerability sort of work I did at Cisco (and later at Digital Bond) never seemed to make a difference. And if I'm honest about it, the learning about a new product, application, protocol, or whatever was more interesting than actually finding flaws in it. Besides, you never really knew would be fixed or not--certainly was not in the critical path, was only at the tail end. Maybe things have changed now in appsec as it has gone mainstream? Maybe I got involved in that field too early. I know I got interested in fuzzers way too early. That's for damn sure.

Although I still do some of this sort of work, these days most of what I do now involves building things, not breaking things. And it is in the critical path. Secure network & system design is in the critical path. Hell, even compliance work is in the critical path.

That cool, technical work where you could wear shorts and sandals into the office every day and never had face to face meetings with your clients and never had to record time or worry about how much time you are billing, burn rate, or profitability--that was not in the critical path.

As much as I miss Austin, that is what I'll be thinking of when I head down 95 and pull into the office in the BWI flight path tomorrow morning for the first time in a week.

A year later am I still scared? And some lessons on proposals

A year ago, when I started my current job at SAIC, I referenced a Tom Peters quote about how your projects should scare you. Well, a year later, I'm no longer scared if the new job will work out, if I will hate it, if there will be enough billable work to keep me employed--or at least from spending too much time in IR&D-land. In fact I'm not scared at all, although I'm certainly being challenged. This is a good thing, obviously.

I'm at that point where I'm at thought I would be based on my standard 18 month cycle. It is interesting how this cycle has repeated itself as I've moved from job to job. About now, things are firing on all (or maybe too many) cylinders and I have the confidence that I lacked for a while. That confidence partially comes from having gotten over that "prove yourself" hump. (One of the consequences of switching jobs is that you have to prove to yourself and others at the beginning the way you don't if you stay in the same role years and years. Of course if you have a continuing stream of new projects where you have to prove yourself to new clients, you get some of that but it is not the same level of stress)

Right now, I have too many projects (this week I billed to 6-7 different charge codes, which is way too many as there is a reason you should have only 2-3 projects at a time) and tasks and they key challenge to to delegate and distribute the load so I don't burn out.

And to say no. I will never forget how during my interview at Hewitt the to-be-CISO asked me if I could say no. I don't remember my answer, but I learned why it was necessary and I certainly see that now. And the need to disengage. Tonight, I told my boss (or at least my boss for a few more days now if the rumors are true) that I was taking the night off and my wife and I watched The Edge of Heaven. Highly recommended if a bit slow moving at first. No, I wouldn't be working on that proposal tonight.

Which leads me to the original idea for this blog. So proposals? What have I learned about proposals? Right now, I'm going through one of those frustrating periods at work were I'm doing less technical work and more proposals and pricing than I'd like. These periods are a necessary evil and they are worth the thrill of the award, but they are not fun. I thought I hated technical proposals but pricing is worse. And there are things worse than pricing, but I wont go there.

So it seems like I've done a lot of proposals in the last year. Maybe I have maybe I haven't relative to folks in similar roles in similar sized companies, but there has definitely been variety. A few technical proposals I've written from scratch (more or less) and done all the pricing and am now leading the project but most where I'm part of a larger proposal team. And this is where the idea for this blog came in mind as I was stuck in traffic on 695 this afternoon.

What are some lessons of writing projects proposals (or at least participating in proposal teams) from the last year?

Who is the boss? This seems easy but it doesn't always happen. Even if there are multiple PMs or team leads involved, you need to appoint one who will run the proposal process. Ambiguity as to who is driving the process can be a disaster. It will screw it up.

Err on the side of more conference calls and less emails. I can't believe I'm saying this. Especially if there are folks that haven't worked together before or are from different organizations. You have to build up that trust. Don't hesitate to pick up the phone. Just sending out calls to contribute and review a document isn't going to cut it.

Divide and conquer. Assign tasks to specific questions in the RFP. Yeah, the folks assigned may screw it up and somebody may need to clean it up and rescue that section, but there needs to be clarity on who has to write what.

Tell folks when things are due. When does the client need it? What the internal process hurdles? When are you tasks due. Open ended tasks also won't get done. Especially if folks are using spare cycles they need to know when to perform that context switch.

Get some sleep. Yes, since proposals are typically on top of your normal project it does require nights and weekend.

And on that note.

Why must I be Unnerved? (#25 from Brand You 50)

About 18 Months Ago I blogged about a conversation I had with a friend and how we both were stuck in an 18 month job cycle. Several months ago (besides worrying that my 18 month clock was ticking, and for those that follow my personal twitter feed, know the egg timer rang and I'm starting a new job tomorrow) I ordered another copy of the must have Brand You 50 and started reading it again.

This was something I hadn't done for a while, but something I highly recommend.

So tonight I read #27 (TO STEER ME INC THROUGH THE WHITE WATER OF CHANGE IS TO DARE, DAILY) contained some clues to decipher my (and I assume, others) 18 month curse.

From the T.T.D. at the end of the chapter, I ran across the question "does my current project scare me shitless?" and I think Tom is really on to something here. Believe it or not I think it is possible to be confident on your abilities and experience, yet still be unnerved about the leap you are taking. If you aren't a little bit scared about what is before you, how could you possibly grow from the experiences around the corner. I can definitely remember this anxiety about various projects at past employers and unfortunately this often occurs only in the beginning of the job. Near the middle and the end things become repetitive and it becomes increasingly difficult to maintain a steep learning curve.

I'll return to the topic in 18 months to see where I'm at!

NOTE: This topic is not unrelated to the survey a month or so back that One in Two Security Pros are Unhappy in Their Job tp which my wife cynically responded that this is only because the security job market is so strong and you can bounce around...

Lessons from Netflix Culture: The 9 Behaviors & Skills

Culture

View more presentations from reed2001.

While some folks were making a big deal about the fact that Netflix doesn't have a formal vacation/time off program (and I've actually worked at a place like that before) what caught me eye from the presentation was the 9 behaviors and skills.

Notice they don't use the term "values," probably because values seem to imply things that you just have (or are) vs. things you can learn or be taught.

The 9 values they define are judgment, communication, impact, curiosity, innovation, courage, passion, honesty, and selflessness.

I really encourage you to drill down and look at the bullet points. I'm sure you'll find some you do well at and others where you need some work. I know I did.

I picked 9 of the ones I found the most interesting and important. And folks that have worked with me before know that some of these I'm pretty good at, while others continue to be a work in progress:

You exhibit bias-to-action, and avoid analysis paralysis.

You listen well, instead of reacting fast, so you can better understand.

You make tough decisions without excessive agonizing.

You say what you think even if it is controversial.

You contribute effectively outside your specialty.

You smartly separate what must be done well now, and what can be improved later.

You make time to help colleagues.

You think strategically, and can articulate, what you are, and are not, trying to do

You treat people with respect independently of their status or disagreement with you.

Yep, there are some tough ones in there and there is a lot more gold these 128 slides that reinforced by my experience in small and large companies alike.

(NOTE: If you register for a slideshare account you can download a .pptx version and print them out for you cube/office wall like I did.)

Another word for stakeholders

This is probably more worthy of a tweet (funny how tweeting has cut down on my blogging) but Alex Payne writes about the challenges of securing twitter (a relevant topic given my Twitter usage lately)

The thing about security is that it requires stakeholders. I have a security background, but Twitter’s security isn’t my job. In fact, my job is pretty much the opposite: I open up as much of Twitter’s functionality as I can without (hopefully) making the system insecure. So while I’ve usually been a “first responder” to security incidents because of my background, it requires a major mental context switch from the work I normally do.

Several months after I joined Twitter in early 2007, I suggested to the team that we do a full internal security audit. Stop all work, context switch to Bad Guy Mode, find issues, fix them. I wish I could say that we’ve done that audit in its entirety, but the demands of a growing product supported by a tiny team overshadowed its priority. Now we‘re in an unwelcome position that many technical organizations get into: so far into a big code-base that’s never seen any substantial periodic audits that the only way to really find all the issues is to bring in some outside help – something I sincerely hope we end up doing, but is not my call.

This post is depressing on a number of levels, mainly because it reminds me of the attitudes (and my own personal frustrations) from back in the early years of doing product security at Cisco.

I hear thing have actually have improved (however slowly) there, but obviously in the supercool world of 2.0 and social networking, they are still pre-2001.

Stakeholders, yeah I'll tell you another word for stakeholders: people that give a shit.

I remember a certain Director of Marketing in the Security & VPN BU. These guys have long since cashed out their options (and the product is killed off), so I don't feel any reservations about blogging about it. Yeah, he was a stakeholder all right, he told us (a small, understaffed, security testing team with no power or authority) that his remote access VPN product was a communication product so security didn't really apply. (Leaving out the far more interesting & cynical quote from a GSR Director of Marketing)

So I understand the frustration, but the idea (that even even if you are a developer, product manager, system administrator) that suddenly you put on your security security hat, stop the presses, fix everything is a quaint notion alongside that 20th century concept that your application, device, or TCP/IP enabled Kleenex box (a big shout out to the Hewitt appsec crew!) is behind a firewall (or not on the Internet) so therefore security isn't a big deal.

You are the stakeholder. And to paraphrase The Wire, "Is you up or is you not?"

Security is not about losing the big battles. It is about winning the small ones. The one's you can win. You do what you can and don't whine about it. If it is not your call, then it is not your problem. Worry about what is your call. That is all you can do.

Been there and done that, you are wasting a lot of time and energy. Trust me.
If you don't believe me, read Unfettered. Bless his heart, Joe is still preaching (nobody gets it, nothing is being done, etc.) the same way he did the first conference of his I attended on SCADA security back in 2003.

Either they get it or they don't and maybe if they don't appear to get it, it is because it really isn't that important in the grand scheme of things. Or maybe you aren't explaining it well enough. If it is really important it work itself out in the long run.

Andy v. Alan: Two Man Enter

Having been on both sides of the fence this is amusing.

Come with me on a little journey. What if she had convinced him to buy her product? Well, that would only happen in one of a couple of ways. First, he decided to make the decision on his own not knowing what the business requirements for this product are. He has no business being CIO. Second, he comes to me and tells me that he wants it and asks for my input. I tell him we don't need it at the moment, there are more pressing projects and I haven't decided on a vendor. He still buys it. He has no business being CIO. So we now have a product that we don't currently need, may not meet all of our requirements, may not be the best fit or the best value for us and I have another piece to force into my security program.
Who wins?
Not me. I've now got another product forced on me and I am learning that my input and opinion are not really valuable to the company so why not move on.
Not my CIO. He has lost my respect and possibly my services. Now he has to find someone else to come in and learn the environment, business and everything else.
Not my company. They just spend a lot of money that wasn't necessary and may not meet their needs.
Not the sales person. She has damaged relationships with a potential customer down the road.
Not the vendor. They have now sold a product that if it doesn't do as expected or doesn't meet the business requirements will only cause the customer to have a bad taste in their mouth.
All of this could have been avoided if the sales person simply chose to wait until next year when a "real" decision could be made.

Literally Marinating in Vulnerabilities

Gunnar Peterson has an interesting blog which reflects his "asset focus", which I think is on target.

Money quote from The Economics of Finding and Fixing Vulnerabilities in Distributed Systems

Why does a talk on finding and fixing vulnerabilities start with valuing assets? The reason is that vulnerabilities are everywhere, we are literally marinating in them. Interesting vulnerabilities are attached to high value assets. In a world that quite literally presents us with too much information, we need screens to sift out what is worth paying attention to. You can run your vulnerability assessment tool of choice on your system, and come back with hundreds or thousands of vulnerabilities, but which ones should you pay attention to and act on? The first part of answering this question is asset value.

Tom Peters on Obama

From Caught in the Act.

Not a lot that you haven't heard before but some reasons (or at least how he articulated them) that stand out

among other things our major problems are likely to be with us for decades—and cannot primarily be dealt with by aircraft carrier superiority, a tough thing for a true blue Navy man to admit. I believe Mr Obama meets the Churchillian standard of "jaw jaw beats war war." I am fearful of Mr McCain's bellicosity and perhaps some volatility.

and

Though I am an avowed supporter of undiluted capitalism (my faith, like Mr Greenspan's, is being sorely tested), I believe that the growing inequity in America is a clear and present danger of the first order. As Mr Buffett said, and I paraphrase, "There's a problem when my secretary has a higher marginal tax rate than I do."

and

I think the time has come to pass the torch to the next generation, and I believe Mr Obama would be an excellent symbol of a new generation of leader. (I think Mr McCain has the haggard look of yesterday, and is, like myself, advertised to be a cranky old man. Age matters—take it from me, and feel free to wish me "happy 66th" on 7 November.)

At least the bleeding has stopped!

On the market from 4/15-10/20, but finally sold!

Now that we don't have a mortgage to worry about, the 2nd Great Depression can begin!

From leaving-skokie-20-june

How is CIP different from "Joe the Plumber" security?

When I was a member of CIAG Research, one of the problems that I had to grapple with was distinguishing normal "network security" or "Internet security" from "Critical Infrastructure Protection."

Given that our [dangerously vague] charter was to conduct and fund research that would improve the security of the critical infrastructure[s] we engaged in a lot of soul searching [and heated discussion] about which projects were appropriate? Was web application security within the domain of CI? Probably not, but maybe? How about routing protocol security. BGP security, definitely. RIP, not so much. How about L2/L3 Enterprise best practices? Maybe? Certainly, if they applied were applied to manufacturing and control system networks. Adding SCADA protocol awareness to firewalls, definitely.

So through these are the mud-colored glasses that I read Perry Pederson's inaugural post at Wurldtech.

So on first blush, and after suffering through a number of Control Systems standards efforts that spent too much time focusing on whether attackers were terrorists, disgruntled employees, or script kiddies, I was sympathetic to his lack of concern for the identity or motivation of threat agents:

So, when it comes to protecting these critical infrastructures, the motivation of the attackers is of less value than the response. In other words, it really does not matter if it was a terrorist, an animal rights group, or someone protecting the environment from us humans.

But I would argue that this is equally true for "Joe the Plumber" security as well. You know, the dirty jobs that small and large companies have to deal with: patching, logging, vulnerability management, application security, incident response, etc. Unless they translate into concrete defensive actions (blocking specific target sources or enabling monitoring for specific toolsets) it is irrelevant who or why you are being attacked. Besides, "Joe the Plumber" does not have access to the sort of [classified] threat intelligence that would make this relevant.

On the other hand (particularly in this season of government intervention to secure the private sector ) perhaps motivation and identity is more important to Critical Infrastructure Protection. If the largely privately-owned critical infrastructure is of so critical to the national interest and there is actionable intelligence to intervene through some national-level asset (electronic, physical, military, etc.) in order to obviate the need for a response within the private sector. But given that critical infrastructure depends on the public private partnership (and this should not just be a cliche on the part on government agencies to let Industry and public infrastructure owners to do whatever they hell they want without fear of regulation) the private sector should focus on the response but the public agencies must focus on incident prevention -- and this requires actionable intelligence on threat identity, capabilities, and intentions. Perry also discusses this need for prevention however I think "information sharing" is another one of those critical infrastructure cliches that executives like to talk about (and have been talking about since PDD-63) but sharing information is a means and not an end to itself. Besides information sharing across large enterprise IT organizations (each which is trying to cover it's ass in response to an incident or outage) is probably no different than the sort of challenges in sharing information between the private and public sector or within government agencies in response (or prior to) incidents.

Based on my experience in the first Cyberstorm exercise (and not just because I've heard directors and VP go on and on about them ad nauseum) I can't help but be a little cynical about efforts to that focus on "information sharing," incident response, "situational awareness", and "connecting the dots." Not only are these problems not unique to critical infrastructure but more often that not "raising awareness" and "improving communication" often are a cheap substitute for action.

Words Fail Me

(Yeah, the line about flamethrowers)

As they say in Kansas, "Fat Chance!"

MATTHEW, your request to pay off your loan has been received. If you're currently in the process of financing with another lender, we want to keep your valuable business.

Based on your current payment history, we are now authorized to offer you a Preferred Customer Discount of up to 1 point off the discount points on your next home loan.¹ This means you may save thousands of dollars² — the larger your loan amount, the larger your discount value!¹

You mean you actually want people that pay their bills?

How quaint.

(Quaint is obviously my bitter word of the evening)

Sequoia on Startups and the Downturn

Sequoia Capital on startups and the economic downturn

View SlideShare presentation or Upload your own. (tags: depression recession)

This was an interesting presentation. I still need to spend some time on. My only window into what is going in Silicon Valley was a couple of weeks back when I heard a friend of mine's startup was going to shit.

The LinkedIn metric? When folks add contacts within their company (outside the normal growth cycle) the company is getting ready to go down?


Hat Tip: James Fallows

The Upside of Black Swans

Tom Peters has been blogging about Black Swan's for a while and he recently posted some rules for success in "Looney Times" such as these. Some good

My favorite one was

This is your life. Think upside!

Much more inspirational than watching your IRA/401k go to shit.

Lessons from the Other Company that Turned Ten

Sure you knew Google turned turned ten but so did Digital Bond.

I never regretted by decision to leave Cisco and do my usual "18 month tour" there. It was the perfect antidote for all the cynicism and negativity that entered my bloodstream after five years of working at Cisco in Austin. 

Some days I wish I could have stuck around to see the dramatic growth over the past few years,  but patience has never been one of my virtues. 

But among the many things I learned from the experience is that in small companies is that you are not happy, you only have your self to blame. You can't blame the status quo, the slow pace of change, politics, dysfunctional teams because it is all on you. And particularly relevant to periods of economic anxiety, is the good feeling working on teams (or projects) that you can directly trace revenue for the organization to your own deliverables. That's one of the reasons I like what I'm doing at Tenable right now. Just as with consulting, developing and delivering training provides a tangible, concrete metric on the value you are providing to an organization.

And last but not least Dale introduced me to to Tom Peters who at first I thought was sort of cheesy, but I continue to read today.

Go To a Non-Technical (Non-Security) Conference, Dummy!

So I've been to a lot of conferences and trade-shows over the past 15 years, but the last two days at the SALT Interactive Technologies Conference in Crystal City has been refreshing and not just because I took the MARC down.

I also learned that taking public transportation from Western Maryland is sort of impractical, because each way the commute took over 2 hours. But I was able to work the majority of the time, so it wasn't wasted time and there were only a few places on the Brunswick Line the EVDO faded out.

My main objective in a attending the conference was to brush up on instructional design and get a jump start on e-Learning tools and technologies. But there were three things that I noticed that were refreshingly different from most of the technical security conferences I've been to as long as I can remember.

1) There weren't all the big egos.

2) The speakers could actually communicate effectively.

3) There was none of "the sky is falling"/"we are so F-d" talk that seems to be the norm.

Among the better presentations were by Marie-Pierre Huguet (on blending constructivism and behaviorism in instructional, a talk on thinking strategically (when developing eLearning solutions) by Mark Siegel.

There was also really good talk on rapid development of training using a modified spiral development model used quickly develop FISA training on the Protect America Act last summer. So you can guess the agency affiliation of these "DoD" and bah.com duo that gave the talk.

So if you've been doing security (or technology) for more than 5-6 years (that was about when I started to get restless and start wishing for a career change that would never come) I encourage you to find a business, or training, or knowledge management -- or something non-technical for a change of pace.

You won't regret it!

Used/Refurb Computer Stores in MD?

One of the [many] cool things about living in Central Austin was being minutes from Discount Electronics but the closest thing I can find appears to be PCRetro any other ideas?

Welcome Playbook!

In a past life, I had the pleasure of working with Max and some of the other Matasano folks (as a alpha/beta Playbook customer) so it is good to see it finally see the light of day!

If you know the pain^H^H^H^Hfun of managing rulesets on a large cross-platform firewall deployment, well you know why something like this is necessary.

So is SCADA Security "Pushing Rope" Too?

Rothman has his doubts on VirtSec. Hell, if IT has 18 month buying cycle's and SCADA has 15 (or even 25 year, depending on who you talk to) what does that say about the SCADA security Market?