At the beginning of this year, we invited security leaders to talk about their past failures and the lessons they wanted to pass on. We called it If we had to do it again, and people really liked it. A number of folks approached me wanting to tell their stories as well; so a month later, we did part two. Here are more “If I had to do it again” stories that readers sent us.
Plan the growth of your program
Paul Farrall, Vice President and CISO, Skytap
Over the past 15 years, I’ve worked at a number of rapidly growing startups that needed security programs built from scratch. What typically happened in these situations was that we built security programs in an ad-hoc fashion, and added new controls as fires erupted. (“An important customer requires that we have a Disaster Recovery Plan. Quick, go write one!”)
The problem with this approach is that before you know it, you find yourself maintaining a patchwork jumble of security controls. There’s no master theme, and you’re possibly maintaining multiple separate compliance programs with overlapping, duplicated work. This might seem obvious in hindsight—but in fast-moving startups, it can sneak up on you.
Here is what I do differently now: At a very early stage (i.e. before we think we need it), we create one master controls spreadsheet based on a comprehensive security framework such as NIST 800-53. As we develop new security controls, we document them in the master controls spreadsheet. In the same sheet, we maintain mappings to all the other security and compliance frameworks we need to support.
This approach highlights remaining gaps as we develop the security program, and makes adding support for additional security and compliance frameworks easy. We just reference everything back to the master controls spreadsheet.
What typically happened in these situations was that we built security programs in an ad-hoc fashion, and added new controls as fires erupted.
The Patience of Portfolio Management
Preston Hogue, Senior Dir of Security Marketing, F5
There's been a number of times in my career where I've stepped in as the first security lead within an organization. You know how bad those situations can look in terms of outstanding risk. Stepping into that CISO role, I immediately identified hundreds of problems that needed fixing. I dove right in trying to mitigate all of them, which was hugely stressful.
I hadn’t yet learned that I needed to wait for the world to catch up with where I thought things should be. Organizations don’t change overnight. I'd have saved myself a lot of stress if I'd realized that I could be strategic and patient in managing our assets, risks, controls, and network security at a reasonable pace. I needed to trust the process instead of fretting that everyone needed to be secure today.
In time, I learned that my job was to move things forward every day. I now understand the concept of security portfolio management, and that there were about six key security programs that needed maturing. I didn't need them all to be fully matured at once.
As long as the program evolved, and risk was reduced instead of trying to do seven things at once, I could unclench. Everything takes time—even maturing the security processes inside an organization.
Stepping into that CISO role, I immediately identified hundreds of problems that needed fixing. I dove right in trying to mitigate all of them, which was hugely stressful.
Buy In from the Beginning
Taeil Goh, CTO and head of IT, OPSWAT
As CTO and acting CISO, I started implementing a security master plan a few years ago with only passive senior executive buy-in. Nearly a year after the roll-out, I realized I had made two important mistakes.
The first mistake was that I focused most of my attention on the risk owners identified by the senior executives. I didn’t invest enough effort convincing senior executives of the importance of the plan and the subsequent follow-through by their staff. This resulted in lack of motivation and priority conflict for the risk owners.
The second mistake was that I launched the program without simple metrics that would have helped demonstrate the progress of each owner to senior executives without going into minutiae. Eventually, I proposed a single security score that was measurable and understandable to both senior executives and risk owners.
As the acting CISO, my initial roll out of the plan was based on the naive optimism, and lack of understanding of the inter-departmental dependencies, associated with my security master plan. I learned how the human factor—in this case, senior executives’ consensus—is just as important as the technical details for a successful outcome.
I didn’t invest enough effort convincing senior executives of the importance of the plan and follow through by their staffs. This resulted in lack of motivation and priority conflict for the risk owners.
Share Your Story
The stories you read here were collected from people wanting to pass on their experience so others may learn. If you have a story of something you’d like “Do Over” in your career, send it in to us at f5labs@f5.com and we’ll run a part four.
