J Wolfgang Goerlich's thoughts on Information Security
Thoughts on training after BSides Chicago

By wolfgang. 30 April 2012 12:11

"I am pro training and pro certification." That is about all I had time to say during a career panel discussion at BSides Chicago. Let’s flesh out a little detail on the blog.

First, training is an integral component of being professional. Professional sports stars don’t just show up for games. We need practice to win. We need sustained practice, organized practice, and practice outside of our normal day-to-day duties. That is the only way to know exactly what to do before doing it.

Second, training increases productivity. By dovetailing training with active projects, people can train and immediately apply what they learn. In a positive feedback loop, people’s experiences then drive the focus of the training.

Third, managers with training programs need metrics. Obvious metrics are productivity (changes per x) and quality (failed changes over successful changes). Perhaps less obvious, certifications are ideal because the metric is widely accepted, unbiased, universal, and requires little managerial overhead.

Certifications by themselves can be worthless. However, certifications with experience are invaluable. At the panel, someone brought up the saying that "certifications simply mean you worked for a company with a training budget." By combining job duties with job training and certification, a person can build one heck of a strong technical talent.

Elizabeth Martin (@elizmmartin), one of the panelists, adds: "I agree completely with all of your above comments. One thing I failed to communicate in the panel is the value of the education associated with certifications. If we view certifications in the spirit of their intent as opposed to the letter (e.g. the letters after your name) there is tremendous value in actually learning."

Regards,

Wolfgang

Post script: BSides Chicago was amazing. If you have a BSides event in your area, I strongly recommend you check it out. BSides Detroit is coming this June.

Tags:

Team management

The power of a good story

By wolfgang. 23 April 2012 08:42

Story telling is a key component of managing and marketing an internal IT team. At least, so I have recently come to realize.

How does one market their internal security team? That question was posed to me by Steven Fox recently. Steven is a good friend and he is working on a book. I was hoping to help him, but I was not quite sure how to answer the question. I pushed back. I don’t really think of what I do as branding. But Steven pushed back too, and we got into a great discussion.

I am a firm believer in the power of a good story. Stories can promote the strengths of your team. Cautionary stories of other firms’ failures can help position your team for success. The right anecdote to the right person at the right time is a powerful thing.

I had not thought of this as marketing. But Steven helped me see it in a different light. Story telling provides consistent messaging that helps build a team’s reputation.

Here are some tips on story telling for IT managers:

1) You are story teller rather than the focus of the story. Your team members are the heroes.
2) Keep it real, keep it honest, keep it positive.
3) Maintain a story book or clippings folder for internal success stories and failure stories.
4) Maintain a story book or clippings folder for external stories, particularly those from sources your executives read.
5) Share these stories with your team as well as your stakeholders. A good story celebrating a team member’s accomplishments needs to be shared.

Have a good story? Drop me an email or catch up with me on Twitter.

Wolfgang

Post script: Steven Fox recommended I check out the All Marketers book by Seth Godin.

Tags:

Team management

Thinking inside the box

By wolfgang. 16 April 2012 09:07

How often have you heard the following? "I am thinking outside the box here, and if we only had this budget we could make it work." Or how about this? "I am thinking outside the box but I keep getting shutdown because of the people around here."

Thinking outside of the box has become synonymous with wishful thinking.

It is great to be different, to be unconventional, and to tackle problems from new perspectives. The box, however, is very real. There are budget constraints. There are time constraints. Possible solutions must make sense to the people who will make the idea a reality. Claiming to "think outside the box" while bemoaning a lack of progress is ineffective.

I say, think inside the box. Come up with creative solutions that incorporate as much of what we know about the industry, the organization, the teams, the people. Come up with creative solutions that we can afford, and solutions that we have the time to implement. Leverage the close relationship you have as an internal IT person to make solutions that outperform those that anyone else could do.

First, think inside the box. Then, understanding the box, we can get creative.

Tags:

Team management

Private Cloud ROI

By wolfgang. 11 April 2012 09:49

When and how does private cloud computing pay for itself? What is the return? I recently spoke with Pam Baker (@bakercom1) about this topic. Check out Pam's article in The IT Pro: Cloud ROI: How much and how soon?

Now mixing and matching appeals to me. A team should adopt a strategy and a toolset that enables managing compute resources on-premise and at utilities. The private or public option then comes down to economics, performance, and security. The security component can be a driving factor for economics, too.

Pam quotes an telling statistic from the Aberdeen Group: "companies using private clouds eleiminate 38 percent of security and compliance costs as compared to public cloud users. Further, public cloud users experience 25 percent more problems with hacking, data loss, and audit deficiencies." In other words, organizations are not going full public any time soon, and for good reason.

Tags:

Virtualization

What is the problem?

By wolfgang. 9 April 2012 08:41

About a month ago, I defined a value proposition as focusing on the nexus of business value, passion, and skills. Let's use that lens to troubleshoot a problem within the IT team.

Do we have a situation where we cannot obtain budget, cannot get buy-in from the business stakeholders, or have a project stalled because we are waiting for input from people who will ultimately use the solution? That is most likely a situation with low business value and high team interest. The technology team wants it more than the end-user does. It is a sign that it is time to step back, reassess, and refactor the project plan.

How about a situation where the work is not getting done? It could be a situation with high value and high passion, but low skills. Perhaps some training should be baked into the project. Alternatively, it could be a situation with high value and high skills, but low passion. Perhaps the project needs to be refactored or pitched better to get buy-in from the team.

Most of the time, when there is friction in an IT team or with an IT project, I identify the cause as being out of alignment with the value proposition. It is not always easy getting back into alignment. Some things simply need to get done, regardless of whether they have high value or are interesting. More often than not, however, a few small changes to a project or an initiative to increase alignment puts things back in action.

Here are the eight states a team can be in, and possible next steps:

1. Low value, low passion, low skills. Outsource the process to a partner based on cost.
2. Low value, low passion, high skills. Automate the process leveraging the team's experience.
3. Low value, high passion, low skills. Redefine the passion into an area with value or skills.
4. Low value, high passion, high skills. Automate the process leveraging the team's experience, or find a way to leverage the team's energy to drive business value.
5. High value, low passion, low skills. Outsource the process to a partner based on quality.
6. High value, low passion, high skills. Provide mentoring and boost time spent on aspects that are interesting.
7. High value, high passion, low skills. Provide training and boost the team's skillset.
8. High value, high passion, high skills. Support the team and give the process your full attention.

Tags: ,

DevOps and Project Management

By wolfgang. 2 April 2012 07:24

Scope, schedule, and budget. Perhaps no other concept is as deeply driven into the heads of young project managers. It is the iron triangle. The triple constraint. Scope, schedule, and budget define project quality.
However, the iron triangle fails for in-house DevOps teams.

Consider the following scenario. An employee needs a simple AR aging report. Such reports have been around forever, so the scope is tightly defined. The development team comes in and specs the project. They say two weeks. The project manager promises three weeks. The project comes in at two and a half and produces a flawless AR report. In scope, on time, and on budget. That is a success, right?

Now fast forward a few months. Support gets a call that the aging report is blank. But accounting knows that there are old invoices. Clearly, something has gone wrong with the report. Support starts digging into the problem. There is little to no documentation. Hours are wasted trying to ferret out the logic of the reporting process. It turns out to be a simple error in the inputs, something that could have been caught with some defensive programming. Hours more are spent in addressing the source data.

The actual but perceived quality of any deliverable varies over time. The AR aging report was a success on day one. But it was a failure when it was blank a few months later. Assuming the underlying issue does not get resolved (ie, the code bug lingers in input validation), the problem will continue to periodically occur. Come a year or two down the road, the business owner will complain that the aging report is junk and a new project will be started.

In this scenario, we have a simple logic flaw. Worse, assume the program was written without any security controls. Now all someone has to do is insert a check request in the unprotected source data, and create a fraudulent check. Though well within the iron triangle, such an aging report will contain operational and security concerns.

In the beginning, a project manager or a team manager can score a number of successes by strictly meeting the triple constraint. Each success, however, adds to team’s technical debt. I have seen many teams fail because of such successes.

With separate teams, such debt is someone else’s problem. The development manager has a string of successes while the operations manager is spending increasing amounts of time tracking down glitches. With a DevOps team, such debt is everyone’s problem. This means developers end up spending most of their time troubleshooting and patching old code. Development efforts slow because of this friction. Pretty soon, the business is wondering why it takes so long to get anything done.The solution? First, for in-house development efforts, cost is fixed. We are going to pay our folks regardless if they spend most of their time in support or most of their time on new functionality. Schedules are flexible and can be driven by the team. And scope, scope must explicitly include quality aspects driven by operations and security. That is to say, the project must be secure, it must be sound, it must be supportable, and it must meet the business owner’s needs.

Looking back at the AR aging report scenario, I would propose the following. Take the developer's original estimates. Include estimates for code review. Include time for security review, and for hammer testing the application. Include time for documentation and other meta tasks. Perhaps that now boosts the time for the report from three weeks to six weeks. The project manager may not score a quick win. However, over the lifetime of the report, the business will see this report as more reliable and as higher quality. Further, over time, fewer hours will be required to support broken software. More time will become available for implementing new functionality. Build new functionality to a high standard and we create a positive feedback loop. That loop is key to delivering sustained business value.

Delivering sustained business value requires thinking outside the triangle.

Tags: ,

Team management

    Log in