InfoSec Career Panel Thoughts

The BSides Chicago career panel generated a fair amount of buzz. The Rats and Rogues podcast brought members of the panel back for a reunion tour. The call featured Nick Donarski (@kizz_my_anthia), Todd Haverkos, Elizabeth Martin (@elizmmartin), and was moderated by Michael (@SecurityMoey). They invited me to join and share a hiring manager’s perspective. You can listen to the career panel here, and I’ve listed some thoughts below.

First, starting your own business remains a strong way to launch a career path. I mentioned the startup I did in my late teens and early twenties, where we served non-profits for free to build technical know-how and social contacts. Nick Donarski shared a similar experience. He started his own information security business at 17. Nick invested in training and used certifications “to leverage to get business. At the client side, the client also used [certifications] as a metric.”

The panel did revisit the certification question. Chris J came out strongly in favor of “use it or lose it”, mentioning that many paper CCNA certified techs could not even describe a subnet in a standard hiring review process. There was sense that some certification bodies may not be policing their ranks as well as they should. I mentioned “vote Wim Remes” as a rallying call, because I believe that people who feel the certification process should get involved. Remes joined the ISC2 board to raise the value of the CISSP. Todd Haverkos, too, sets a good example by participating on the LPT board.

“Education, Education, Education,” that was Elizabeth Martin’s take-away. Elizabeth drew an fascinating comparison between compliance and certification. In both, it is easier to meet the letter of the rules than it is to meet the spirit. Certification not about getting a couple letters after your name. It is about lifetime education that coincides with and is in support of your career path.

But what happens if your career path does not align with your organization’s needs? It comes down to negotiating with your management. Michael: “We are talking about having difficult conversations with you and your manager. The approach I have taken as of late is to be completely honest and transparent. And I don’t think anyone could ever fault you for that.” With a nod to BSides Chicago’s slogan this year, have these conversations early, have these conversations often.

Elizabeth Martin added: “It is the employer’s responsibility to provide you with the opportunities, the tools, and the training. It is up to you to set the path.” She recommended setting 10 year plans with milestones at 1, 3, 5, and 7 year marks. You can always change plans, but only if you have a plan.

We wrapped up the conversation talking about ways to build the next generation of information security professionals. Mentorship works and we are discussed ways to foster that within the local community. It takes a full commitment from all parties. As Todd put it, “In addition to us doing a better job mentoring and creating people, don’t sit idly by. You get what you go for.”

Such mentorship programs, too, should address the entire lifecycle of employment; from hiring to career changes. Then, Elizabeth and Michael took the wraps off a new project: the Mock InfoSec Job Board. Here, hiring managers can host interviews and help candidates hone their skills.

It was a good 90-minute chat and my brief summary does not do it justice. You can listen to the panel here at Rats and Rogues.

Key take-aways:

• Certification is only one metric of many; consider the candidate’s experience and aptitude to get a broader perspective.
• Volunteer with certification organizations if you are unhappy with the certification process.
• Maintain alignment with your reports and with your managers by having regular conversations about career paths and goals.
• Find ways to build up the next generation of information technology and information security professionals by volunteering in your local area.
• People looking to practice their interview skills should check out the Mock InfoSec Job Board, and hiring managers looking to build the next generation should consider volunteering.

In the run up to BSides Detroit, one of the speakers pitched his talk as learning the table stakes of Linux security. This was new term for one of our younger organizers, and the organizer’s question had me thinking of blogging on it.

Table stakes in poker is the minimum amount needed to be in the game. In business, table stakes is often used as a metaphor for the minimum amount needed to enter a market. Jeff Reich (@jnreich) referred to table stakes as the minimum security required in a system on the Down the Security Rabbithole podcast. Since then, more folks have been referring to infosec table stakes.

Now it is helpful to understand technology table stakes. What is the bare minimum that a business expects from the information systems department? Maybe things like back office applications, email, Internet connectivity, and so forth. What expectations are value-add? Line-of-business apps, hopefully, along with services that differentiate one business from another in a given market.

For most any company, there will be many more systems than there are people to secure and operate them. That is the nature of technology today. The trick is to know what systems are table stakes and what systems are differentiators. Once we know that, we can automate, outsource, and minimize the time spent on table stakes. We can then align the team with the differentiators and spend the majority of the time driving business value.

This is in response to an article by Klint Finley (@klintron):Devs vs. Ops: Sushi vs. Meat and Potatoes.

“J. Wolfgang Goerlich … led his IT ops team to adopt agile operations practices before the Dev team adopted agile development practices.”

My DevOps story is a bit of an exception, stemming from a two year lead up to the team integration.

My organization first made the shift from traditional IT to highly virtualized and highly automated IT. From there, we made the shift to private Infrastructure-as-a-Service IT. The transition entailed high degree of infrastructure rationalization. This put tremendous strain on the network operations staff. We could not take a waterfall project approach to implementing these changes.

From 2008 to 2010, the team became good at agile. We got good at change, and continuous change, and repeatable change, and seamless non-impact change. We changed things daily. On a good day, the community noticed and appreciated the change. On a typical day, the change went unnoticed. On a bad day, the change broke something. And we learned how to quickly and quietly recover and fix things. It was very much a DevOps success story without the Dev.

We addressed that in mid-2010 when the application development folks joined our team. Their organization was still very much projected and followed the standard waterfall model. Cycle times were long and rework was high. Technical debt was also high, stemming from ten years of ad hoc projects in a variety of languages and on a variety of systems. We integrated the two teams and began a process of software rationalization.

“Are there any less obvious solutions to the Dev/Ops divide?”

A successful DevOps team works from the same playbook, has a shared understanding of the system, and is measured by the same metrics.

A core component of this is cross training. Developers, who have been very successful at adding functionality, need to step up their game on providing operational excellence. Operations, who have been very successful at up-time and response, need to step up on providing a service to the organization. My team regularly holds knowledge sharing meetings where a person explains their latest work in terms of the impact to the business and the requirements from the system.

The next integration point is support. My team integrated support on the front-end through one telephone support hotline, and one support email address, and one ticketing system. One person from development and one person from operations are on-call at all times. This creates a partnership when responding to incidents and implementing new functionality.

To complement these integration points, a single set of metrics are applied to both development and operations. The metrics track features delivered, rework, and up-time. This encourages development to adopt rugged techniques. (See the Rugged Software Manifesto, which perfectly captures our mentality towards new code.) The metrics also encourages network operations to deliver new features via configuring existing software.

In the end, our “one team, one system” approach addressed the divide by improving the team’s shared skill-set and by measuring both specialties with a common set of metrics.