Leading from the Front: Bringing Planned Disruption To The Organization
By Martin Fisher
What is the most important job/function of a leader?
- Inspire the team?
- Use resources effectively?
- Make tough decisions?
- Set an example?
- Develop others?
All of these are good answers and are important things for a leader to be sure they are accomplishing in an organization.
But none of these is the most important answer.
The number one job of a leader – the reasons leaders exist – is to bring change to organizations.
“That’s silly!” – is a common reply I hear when I make the statement.
“Leaders only bring change if change is what the organization needs. They assess the situation, analyze their resources, and only make changes if there is a reasonable chance of the change improving the organization.”
My response to that, in the words of my teenaged daughter, is “Pssh!”.
Change: If you aren’t doing it, you’re doing Leadership wrong.
Effective leaders are never satisfied with the status quo.
Of course, leaders will continue to celebrate good performances, boast the capabilities of their team, and value the circumstances they find themselves in. But more, a leader has the ability to see and accept the organization as it is and form a clear vision for how the organization can (and should) be.
Leadership, a friend once told me, is the where the science of the possible meets the art of the dream.
Leadership is the nuanced ability to see what could be and come up with the plan to create it out of what is already in existence. Effective leaders almost instinctively realize that slow and incremental change is a prison and that the only escape is dramatic and disruptive change.
Leadership is “Disruptive change?”
That’s crazy talk!
Look at all the people who lost or almost lost everything to disruptive change: New Coke…Webvan…the Pontiac Aztek…Hooters Air…
Only a fool or a liar would say there is no risk to disruptive change. But there are things you can do to minimize that risk:
Think, Rethink, and Rethink Again
The leader has to be completely honest with themselves about the environment they operate in, the resources available, and the chances of the disruptive change actually taking effect.
This thinking must be complete, honest, and is not done until the leader understands the environment completely.
The leader then needs to find a small group of trusted other leaders that they can toss the idea to with the intent of these other leaders shooting it so full of holes that almost nothing remains.
Whatever is left — whatever survives the onslaught — forms the base of the next round of thinking. Once the thinking is done the thoughts have to be able to be put into simple and actionable statements:
- Changing the organizational structure? Then create a org chart to talk to and demonstrate.
- Changing processes? Then show a picture that details before and after with the benefits.
- Changing the mission? Then create a succinct mission statement and show what is being changed and why.
Whatever the change, come up with a picture (1 slide, please, not a full deck – that’s for later) that can be used to explain the “why and how” of the change.
Talk the Team Through The Change
The worst thing to do once the thinking is done (you think) and the picture is ready is to simply dump the change on the team.
One of the biggest (and, sadly, most common) mistakes leaders make is to forget that, while the leader has been thinking through this change for weeks, the team just got told of the change and needs time to process and unpack it. They deserve the chance to see what the change is, how it impacts them, ask questions, and get answers.
The effective leader is able to effectively communicate the change to the team.
Using the picture of the “how and why” to show the team how the change will impact them and how it helps getting team goals accomplished.
Then step back, listen, and engage in the conversation. Remember – the team knows the system and might reveal something to tweak the change. In fact, this could be the difference between success and failure.
“That sounds an awful lot like sales! If I wanted to do sales I’d of taken that job with my cousin at the furniture store!”
Is it like sales?
Well, if “sales” means influencing people to see things from different perspectives – then yes.
But I prefer to think of it as “Casting A Vision” – which is what we’ll talk about next time.
The Solution: Leading People, Managing Objects, and Accomplishing Goals
by Martin Fisher
Those who know me have come to expect me to “correct” them whenever they say “manage people”.
“Objects are managed, people are led,” is my usual retort. Sometimes I am met with a blank look, sometimes with a exasperated grimace, and sometimes (and not nearly often enough) by a questioning stare.
“What?” the quizzical friend often asks. “There’s not a difference worth mentioning.”
Nothing could be further from the truth and nothing, in my opinion, has done more to impede the progress of the information security profession.
The abject failure of leadership, from senior ranks, through middle management, to front-line supervisors has led to a culture that glorifies “meeting expectations”, extols the virtue of “accomplishing goals”, and is satisfied with “getting the job done”. Don’t get me wrong – these things are important – but they miss the vital difference: That a dynamic leader can take a group of people and almost always “exceed expectations”, “surpass goals”, and “get the job done better” and still have a happier team and more satisfied customers.
“How does that happen?” asks the still-quizzical friend, “Isn’t meeting expectations what we’re here for? Isn’t that enough?”
Sadly, it isn’t enough.
All people appreciate leadership. Everyone inherently wants to belong to a team that accomplishes exceptional results. Nobody wants to be in an organization that doesn’t excel.
The key to this is the Leader.
Leaders determine, by applying their leadership talents, just how far the team will go. Setting a goal and managing to that goal ensures that any additional capability is forever lost. Managing to a goal guarantees that the exceptional capability that is native to any team will be lost in a desire to just do “enough”. When we manage people, instead of lead them, we are condemning ourselves to forever experience sub-optimal results, never knowing what could have been accomplished.
“But my team is happy and my customer is satisfied. Doesn’t that mean I’m succeeding?” asks the friend as their frustration with the conversations grows. “You’re making more out of this leadership thing than it really is, aren’t you?”
This is the point where the friend has reached an almost Matrix-esque moment…
“Take the blue pill and this conversation ends. Everything goes back to the way it was and you can believe anything you want to believe. But take the red pill, and I’ll show you how you can take the leadership skills and talents you have and use them to transform yourself and your team. I’ll teach you how to truly get more done with more satisfaction.”
Which pill, my friend, will you take?
The Leadership Challenge in Today’s Security Environment
Management is doing things right; leadership is doing the right things. ~Peter Drucker
Leadership. It’s talked about a lot in today’s information security conferences and books – but how much of it is really happening?
Do we, as professionals, really embrace leadership and its inherent risks, rewards, and challenges? Or, on the other hand, do we really embrace the status quo with its inherent frustration, ennui, and demotivating drag?
Don’t get me wrong – leadership in any field is hard. I’ve led teams that have done such diverse missions as application development to firefighting to deploying the varied weapon systems in platoon of main battle tanks…and I have come the believe that effectively leading teams in today’s information security environment is one of the most difficult tasks I’ve ever taken on. As I look back, around, and forward I’ve made a few conclusions.
Too much focus on the status quo
I wish I had a nickel for every time I heard a “leader” describe a “good day” as one where nothing went wrong, nothing broke, and (truth be told) nobody even noticed she or her team were there.
Why?
I think because for so long the business has seen information security as the “Department of ‘No!’” that any time we fly above the radar we get smacked – or at least that’s the fear. If the systems run today just like they ran yesterday we call that a win and hope that they’ll work tomorrow just the same way.
This primal desire for the status quo is one of the most significant issues that chains down information security leaders today and it’s a topic I’ll address in more detail later – but suffice is to say that the status quo is rarely, if ever, the ally of a successful leader.
Insane focus on a small group of miracle workers
We have developed an almost unnatural dependence in information security on the work and thinking of small groups over very smart people. We rely on that small cadre of “go-to” guys to design and build our systems, respond to incidents, and help develop policies and procedures – but we rarely leverage that small group of folks to develop larger and larger teams of security oriented co-workers.
Whether we realize it or not we begin to live in a cultural echo chamber where everyone listens to the same presentations at the same conferences, reads the same blog post, and anyone who dares speak out against the conventional wisdom for any reason is suspect…
The Status Quo of the Mojo
The last major impediment I’ve seen is a synthesis of the first two. When you combine an overvaluing of the status quo with an over-dependence on small groups the almost inevitable outcome of a culture of “Please $DIETY, don’t let me screw this up!”
Leaders and their teams become so averse to anything negative (especially if it’s outside the accepted norms of the team) that the goal of the team slowly and immutably transforms from providing the best security for the organization to a goal of not wanting to be caught screwing anything up. This fear (and that’s what it is) leads teams to fall into the trap of wanting to build systems that are “perfect” and “unhackable” and resisting efforts to design or implement systems that don’t meet these standards.
The natural progression of this fear eventually leads to leaders and teams developing and attitude that is occasionally indistinguishable from despair. You’ll hear or read comments like “Why should I deploy $SecurityTechnology? HD Moore could hack it in 5 minutes. Rsnake could get root and own me 25 ways from Sunday.”
Rarely will the speaker or writer of such comments even seem to evaluate whether or not $SecurityTechnology will actually help the organization as part of a complete security plan. Defeat, as the philosopher said, is complete even before a shot is fired.
What can we do about it?
For the next dozen or so posts I’m going to address these issues head on and provide you with a (potentially) counter-cultural view of your role as a leader and hopefully challenge you to rise the amazing challenges we face today in information security.
The light you see coming at you – it’s not a train. Trust me.
What are your leadership goals for 2010? Share you challenges and successes in the comments…
Have a workable plan, or else…
by Martin Fisher
As we continue to discuss the Basic Truths of Incident Response Leadership, we’ve briefly gone over the three Basic Truths as well as done a deeper analysis of “Succeeding By Planning to Fail”. This brings us to:
Basic Truth #2: Have A Workable Plan, or Else
As an Incident Response Leader, one of the most valuable parts of your role is to create, test, exercise, and (when called upon) execute Incident Response Plans (IRPs). IRPs run the gamut from a Post-It note on the wall listing contact phone numbers, to plans that take up several 3-ring binders on a shelf somewhere. Plans can be long or short, detailed or vague, paper or electronic, automated or manual…you get the picture. What makes a good plan different from a not-so-good plan can be summed up in a few ways.
First, can you execute the plan using only the resources that you legitimately would have access to during the incident? We’ve all seen plans that call for using network analyzers that aren’t accessible to the organization or that call for numbers of personnel that just don’t exist. You may have written plans that assume that the responding team has skills and experience that your current team just doesn’t have (I have). The key is to map out the current skills and capabilities of your team and employ them as best you can to meet the anticipated incident.
As you identify resources available to you, it pays to be creative. Can other teams identify folks who could temporarily be available during an incident (think of it as an in-house “volunteer fire department”)? Do you have relationships with designated outside incident response consultants? Do you have relationships with local, state, or federal law enforcement? In today’s business environment, Incident Response Leaders need to be creative in identifying resources that can assist during a response cycle.
Second, you have to test the plan. This sounds so intuitive, but many plans never get past the written-down stage before they are needed in an incident, because no leader stepped in to ensure that the plan would work as designed. One of the most effective testing plans for an IRP is also the least expensive – the simple “Talk Through”, where all of the designated players sit at a conference table (pizza is optional, but highly recommended) and talk through the plan, noting any foreseen problems or issues. The team needs to be encouraged to not only point out potential problems, but brainstorm solutions they can implement as-is since (as we talked about in Basic Truth #1) you can only plan on the resources you have, not the resources you want to have.
Plan testing needs to be redone each and every time the plan is modified, or at some regular interval (at least annually). Testing can be announced or (my personal favorite) unannounced. The time spent testing can help the Incident Response Leader assess not only the plan, but the team assigned to execute it. The feedback loop should encompass applications, hardware, processes and procedures, as well as people. Everything is fair game.
Lastly, you need to continually exercise your plan. This, while not as intuitive as testing, is something that many organizations fail to do, claiming “it’s too hard” or “it’s too disruptive” or “it’s already been tested, why should I do an exercise?” Having performed incident response on plans that have been exercised and plans that have not, I can tell you with complete assurance that plans that have been exercised are executed more smoothly, with fewer problems and a better resolution.
Exercises can range from a talk-through (similar to testing but without the constant feedback loop) to a full-on exercise using live equipment. Talk-through exercises can help in quickly familiarizing a team with a new (or newly updated) plan. Talk-through work will also quickly point out assumptions that, while seemingly accurate in testing, don’t fit the way the incident response team works. All other things being equal, I believe that talk-through exercises offer the highest return for time spent in any aspect of prepping for a incident.
Full-on exercises, as powerful and complete as they are, can be very hard to accomplish. Most organizations cannot fully replicate their production systems (even using virtual machines). These exercises, when they can be done at all, are usually done in development or test environments and generate most of their value by allowing teams to actually assess and interpret adversary actions and data. These exercises are an Incident Response Leader’s best chance to simulate the stress and activity of a real incident.
Taking all of this into account, it’s clear that the Incident Response Leader must be able to create, test, and exercise an IRP to be able to effectively respond during the inevitable incident. By creating plans designed around available resources, qualifying the plans with testing, and regularly exercising the plan, you can ensure that you and your organization will be ready when the inevitable incident occurs.
But it’s not over yet. Once you’ve gotten this far you still have one vital task to accomplish. We’ll cover that in the last article on the Basic Truths of Incident Response Leadership.
Communicating with Your Boss
by Martin Fisher
As we looked at the first two of the three Basic Truths of Incident Response Leadership (“Assume You Will Fail” and “Have A Workable Plan”), we focused on activities that the Incident Response Leader does with the incident response team being led. The final truth involves the other direction on the organizational chart…
Basic Truth #3: Communicate Your New Posture To Your Boss
Once you’ve changed your mindset about getting compromised, and you’ve reviewed, tested, and (hopefully) exercised your plans, you are going to enter what is, for some people, the most challenging Basic Truth – explaining what you’re doing to your boss.
Now, to be honest, you should be regularly talking with your boss. Organizations rely on middle level managers to have frank, open, and honest discussions with more senior leaders so that the organization’s efforts are aligned with the overall direction of the business. The role of the Incident Response Leader is to not only train “down” the organizational chain but to educate “up” the chain as well. The best way to do this is through regular conversations.
The potentially tricky issue is that you may have to “un-do” years of senior leader assumptions about the incident response approach of the organization. As difficult as you may have found it to “Assume You Will Fail”, your boss – who is probably much less directly connected to the daily realities of incident response – is going to potentially be much more resistant to change that assumes that problems will occur. Hopefully you’ve been hinting, nudging, guiding, and educating your boss during this process, and this will not come as a surprise (because as a general rule, surprises to your boss are a bad thing).
As you educate your boss, you may need to back up and re-teach some of the the basics of information security and risk management. Your boss may need some catch-up on risk management and analysis. If so, you’re in luck because there will be that much less to un-learn. Over several meetings, take the time to ensure that your boss understands the “why” of what you’re doing before you start into the “how” of what you’re doing. Take the time to demonstrate to your boss that you not only understand the business of Incident Response, but that you understand the business of the organization and your role in it.
Take the time to talk through the benefits of “Assuming You Will Fail” by pointing out that the organization cannot afford “perfect” security, but can afford a quality incident response team to respond to and mitigate any issues. Through discussion you can reframe, redefine, and provide your team with realistic goals and objectives that senior leadership understands and will buy into.
This conversation sets you up for the key discussion – formalizing the performance expectations of you and your team; setting up and documenting exactly what you will do and how you will be measured; and how (most importantly) the organization will define your and your team’s success. If you do this well, you will have turned what previously would have be considered a failure into what is a significant win for the organization, your team, and you.
Accepting and acting on the Three Basic Truths of Incident Response Leadership will enable you to better serve your organization, your team, and yourself. I’d love to hear from other IR leaders to see how this works for you.
Succeeding By Planning to Fail
by Martin Fisher
As security professionals, it’s hard to admit to to our bosses (and ourselves) that all of the work we’ve done to prevent compromise sometimes isn’t enough. We don’t like to think about the possibility that the money and time invested in technology might not prevent an incident from occurring. That’s why I proposed, in my previous article, the following basic truth for Incident Response Leadership:
Basic Truth #1: Assume You Will Fail
One of the issues we face in Incident Response is how we frame success and failure. Too often we define our success with phrases like, “we’ve never been hacked” or, “our systems have never been breached”. These phrases fly in the face of the fact that no system is 100% secure. They dismiss the fact that a sufficiently motivated (or lucky) intruder can get in.
So, re-framing and redefining “success” is key to actually being successful. How do we do that?
First, we have to publicly acknowledge to our bosses, peers, and team that we expect that some small percentage of hosts and devices on the network will someday become compromised. It could be malware, it could be an intrusion; it could be almost anything. We need to help our teams and bosses realize that it’s not only okay to find these flaws, but that it’s actually a vital part of keeping our environment secure.
Second, we have to have a set of plans, procedures, and technology in place that allow for continuous monitoring and detection of problems in the environment. As leaders, we need to push for thorough and repeated examination of our environments and celebrate each and every compromised system our teams identify, contain, and eradicate. We must inculcate a philosophy that finding “nothing wrong” is more a sign that detection systems and processes need improvement, than it is a sign of successful prevention.
Lastly, and most importantly, we have to build the right networks of people, processes, and capabilities to make the most of the monitoring and planning. As Incident Response Leaders, our most critical mission is to build effective individuals and teams that can stand up to the pressures of Incident Response.
But, you ask, how do I do this? It isn’t easy – but Incident Response Leadership rarely is…
To start the process, you need to sit down and honestly assess your network. Bring in some trusted outside advisers if you need to. Are you really keeping anti-virus updated on all of your systems? Are you deploying operating system and application patches in a timely fashion? Are your IDS/IPS systems workable? How much screening do your firewalls really do? If you put on your blackhat – how many ways could you penetrate your network?
Once you’ve completed the process of seeing exactly how secure (or insecure) your environment really is, take a deep breath. The natural response to this kind of in-depth assessment is to think that the world is collapsing and that only huge amounts of effort can ever fix it. Remember, you aren’t here (necessarily) to fix those infrastructure issues right now; you are here to develop the ability to respond to incidents right now.
Now, take the list of perceived weaknesses and map out, using existing resources, how you intend to respond to this kind of incident. Don’t develop detailed plans right now – that comes later. Just identify how you can respond with what you’ve already got. A quick spreadsheet should do the trick here.
Next, invite your boss to have a cup of coffee with you. Let the boss know what you’ve been doing and the relative assessment of the network (remembering that the sky, more than likely, isn’t really falling). Show the boss how you intend to respond to the potential incidents using your map. The key to this meeting is being calm, professional, and not sounding like a) Chicken Little or b) you are about to ask for a ton of new resources. You need to show how you are going to realign your existing resources (which have been good enough so far, right?) to meet the challenge.
The key part of that conversation is to start the process of setting realistic expectations with the boss. Share the truth that you’re doing everything you can; that a lucky and/or motivated adversary could still compromise the system; and that, being the Incident Response Leader that you are, you are going to develop the plan and the team to identify, contain, and eradicate any and all intrusions.
Once you’ve got buy-in from your boss you’re ready to tackle the next Basic Truth: Have a Workable Plan. But that’s for the next article.
Incident Response Leadership: Basic Truths
by Martin Fisher
An organization might spend hundreds of thousands of dollars to implement just one security infrastructure. Millions of dollars can be spent creating a security environment that provides an extensive defense against all nature of attacks and threats. But the true value of that substantial investment can never be realized until one relatively low-cost – but critically important – item is addressed: Incident Response Leadership (IRL).
Incident Response Leadership is the primary task of the management of incident response teams. IRL begins with the creation of incident response plans that minimize the impact of any given incident to the management and leadership of the actual response team during an incident. IRL continues through the recovery/cleanup process by assessing where the incident response plans can be improved.
Effective Incident Response Leadership also recognizes three basic truths. Until your organization embraces these truths, there will be an artificial ceiling on how effective the security program can be…
Basic Truth #1: Assume You Will Fail
Ask yourself this quick question: “How many compromised hosts are on my network?”
If your first gut response was “none” then you might have some rethinking to do. It’s natural to develop a sense that all of the money, effort, and resources it took to build your security environment will keep all of the evildoers at bay. But if you (and the team you lead) begin to operate under the assumption that nothing bad can happen, you will either miss it or react inappropriately when the inevitable incident occurs.
Compromised hosts can take many different forms. It may be a file server that’s functioning as a SPAM relay, it could be a workstation that is part of a bot network, it may be a database server that has a rootkit installed. There are a multitude of methods and techniques to identify and locate hosts using firewall logs, DLP, anti-virus, and so forth. It’s a major IRL responsibility to allocate resources to this work.
Basic Truth #2: Have A Workable Plan, Or Else
How many of us really do regular exercises of our incident response plans? Exercising workable plans that give your team the direction it requires and the flexibility it needs is a low-cost, high-payback activity that builds esprit de corps and keeps your team sharp and ready. Lack of a workable plan will delay your response, make forensic investigations more difficult, and cost you time and money you didn’t need to spend.
There are always challenges to the drive to exercise plans. “Why waste time on this?”, “We’re too busy.”, and peer leaders not making matrixed resources available are a constant refrain that IRL needs to overcome.
Basic Truth #3: Communicate This To Your Boss
Telling your boss you are assuming you will fail can be a tough conversation. The only way to survive it with any sense of dignity and professionalism is to create a series of dialogues with your leadership to explain your incident response program, methods, and assumptions. You can make this a career enhancing discussion by demonstrating your knowledge of the needs, objectives, and goals of the business. You will be able to set realistic expectations for your team and be able to clearly communicate what it will take to move your team to the next level. Demonstrating the fact that success is defined by effectively leading your team through the entire range of security tasks (prevention, detection, response) and not by simply saying “don’t get hacked”, will enable you to truly succeed to the benefit of your organization.
Over the next several articles we’ll dive deeper into each of these Basic Truths, and show realistic steps and obtainable objectives to improve your Incident Response Leadership.
Engage with Michael
-
Journey Into the Breach
