The preceding chapter discussed the importance of partnering with others in the company to share InfoSec responsibilities. I urged you to give parts of your job away and to place the responsibility for security on the system owners. Why does this make sense? Two reasons. The first is to enable the concept of the neighborhood watch, with the goal of getting everyone in the company to do their part. The second is that your InfoSec department is likely grossly under-resourced for the task at hand.

From my experience, all InfoSec departments have one thing in common: not enough staff or money to protect the company’s information assets from the litany of threats they face. Like the many heads of the mythical hydra, threats to security seem to multiply with each new technology. So few companies have the staff or budget to keep up with those threats and demands for InfoSec services.

We make choices about which “crisis” to handle among the many crises that pop up every day. It’s an exercise in risk management triage every day, all day. I don’t know about you, but I’ve always been under-resourced and never had the luxury of downtime or quiet time. It’s 911 all day. It’s the nature of our work. As I’ve said before, InfoSec is like a game of hockey: fast and full contact, with no bench time. It’s not a job or career for sprinters. Our jobs are marathons with no opportunities to stop or catch your breath.

So how do you hope to survive in this situation? The answer is the neighborhood watch. It’s your only hope. Get everyone involved, especially other technical teams. It’s time to imagine a world where the security knowledge required to protect the “town” is in the hands of the company’s staff. If you subscribe to the neighborhood watch model, I believe you can be very effective as a security leader with a small staff.

Identifying the Type of Talent You’ll Need

If you’re new to your job, you’re in one of two situations: you’ve either just inherited an existing InfoSec team, or you have to build one. Both have their challenges. My preference is to be able to hire your own people and build the team you need. Let me start with that scenario.

In my seven-step process, you need a certain type of security person in order to be successful: technical types with good interpersonal skills. This type of staff member will make life easy for you and will enable you to build the InfoSec program the company wants. Not having staff with technical and interpersonal skills will make your work much harder and inevitably lead you into difficult management situations.

I recommend that everyone on your team be college graduates, preferably with engineering degrees. This ensures they have the theory of computer science/engineering and understand the computing stack. College grads are usually more agile and can easily grasp the technical nuances of new areas. This sort of agility provides you with the flexibility you’ll need as you reassign people to different areas, as one team member backfills for another.

Next they should have expertise in some area of computing. It doesn’t matter which area of technology, but they must be deep in that area. If you have people with college degrees from the right disciplines and they’ve spent time in at least one area of IT and acquired expertise in that area, then they have a good foundation to be successful as an InfoSec type.

Finally, and probably the most difficult attribute to find among the technical people I just described, but that is essential to the success of your program, are interpersonal skills—or people skills. Unless you have a large InfoSec team, you should not sacrifice on this point. It’s better to have someone with fewer technical skills and abilities than to compromise on this area. Let me say it again: your new hire must have great people skills, no exceptions. I’ve worked with and retained technically brilliant people who had zero to no people skills. They were often toxic to the organization and found themselves in technical battles and disagreements with their colleagues whenever they had the opportunity. These types have the natural ability to piss people off without even knowing it. And it happens far too often. I now avoid these types. They’re too expensive to maintain.

As a reminder, relationships are the foundation upon which you will build your program, and at the heart of relationships are people skills. If your team members don’t have people skills, their value to your team greatly drops. It will be your team members who evangelize the security messages throughout the company. Great people skills will allow them to manage through the sticky situations that often arise for security types—for example, the handling of an incident or the discovery that one of the system administrators has been grossly negligent in their responsibilities. If you take away only one message from this chapter, let it be this: you need folks with great interpersonal skills. Without them, building an InfoSec program will be a continual uphill battle.

Managing a Preexisting Team

If you’re inheriting a preexisting team, you potentially have your hands full. This is much more difficult than hiring your own team. Some of the people you inherit will have wanted your job, or at least thought they should be considered for your job. Others on the team will have close relationships with your predecessor and are likely still in contact with that person. Still others will question your qualifications and be tapping into their network of people in the industry to get the skinny on you. In the end, this team isn’t “yours,” and you’ll face a potential landmine of possibilities when you take over a preexisting team.

So how do you evaluate your newly adopted team members? Here’s what I’ve learned from being in that situation a time or two. I suggest you meet with each member of your team as soon as possible. You’re not going to make any decisions based on these initial conversations, but they are the beginning of your evaluations of them. I would also ask them what their core technical competencies are, and what they’ve been doing within the company during their tenure. From this first meeting, you’re evaluating two competencies: technical skills and interpersonal skills.

People skills are the easiest to identify, and you can usually tell during these meetings who the keepers are. To some extent, you’re looking for salespeople, individuals who can work with others while not pissing them off. You want people who can run meetings, make presentations in front of various groups, and walk the halls and evangelize the organization with you. Security types who can do these things are worth their weight in gold. They can do more to advance a security program than anyone else on the team. Those who can’t do this may have much to offer, but they may be limited to the technical side only.

Once you’ve met all the team members, I usually plan for a meeting of all staff members, where I can begin to share the direction I’d like to take the team as well as my expectations. This staff meeting is important, and you need to be well prepared. Understand and practice each of your talking points and what you hope your team takes away from the meeting.

NOTE

Over the years, I’ve refined a set of bedrock expectations for the smooth functioning of any team. I keep this list in a journal so I have it ready whenever I need it. I typically review it a couple of times a year, even when I’ve been with a company for four or five years. Team members need to hear these talking points over and over, and the list also helps new team members who may not have been part of the team from the onset. Going over the list in staff meetings a couple of times a year allows me to reinforce our direction and the expectations we have as a team.

At this initial staff meeting, share your philosophy or approach to InfoSec. Let them know why you were hired and your beliefs on how best to protect the company’s information assets. Hopefully, this will all be about the neighborhood watch.

Once your vision and approach are shared, tell everyone they have x number of days to decide whether they’d like to be part of your team. You’re basically asking them to decide if they are in or out. They can use this time to decide whether they want to be part of something new or would prefer to take their talents elsewhere. I usually give them 30 days. The difficulty is in identifying those who give you lip service that “they’re in,” and who show some demonstration of a willingness to stay, but really aren’t in at all. My message is simple: if I don’t see a clear and compelling demonstration, it’s time to part ways.

Your biggest impediment to growing the program won’t be the resistance you receive on the streets; it will be the resistance from the naysayers on your team who have not bought into the new direction. It’s better to have a team of 3 who are all “rowing” in the same direction than to have 10 guys with a couple of naysayers quietly working against you.

Good luck in your early tenure, as the message you convey to your team as well as the expectations you have of them are important for them to hear. I also have a document of guiding principles developed over the past 20 years that I share with everyone during these first few meetings. The principles cover such topics as the importance of operating with humility and kindness toward others, treating others as we’d like to be treated, listening first, and seeking to understand before we speak.

Where You Report in the Organization Matters

I started this book by making the argument that nobody understands InfoSec and nobody really cares about it. To support my argument, look at where you report in your organizational chart. A recent Ponemon Institute study reported on the CIO & Leader website indicates that about 50% of us report to the CIO.

But placing InfoSec under the CIO creates so many conflicts of interest. For example, the results of pentests or vulnerability assessments can be overlooked because the system owners are busy with other “more important” business priorities. Or system owners may resist sending logs to the central logging service because they say they are too busy with other higher priorities, when in fact they just don’t want to provide others with visibility into their administrative activities or negligence. Reporting to the CIO also often means that security initiatives will take a back seat to IT projects, which compete for system owner time.

If you report to the CIO, the likelihood of being moved to somewhere else in the organization is next to zero. CIOs like to have the InfoSec team under their wings, to control our work and the message communicated throughout the company. It also looks good on their resumes. Your team also puts lots of points on the board for them, which they desperately need in our new world of growing importance for InfoSec. You also probably present to the board a couple times a year, and they do not, but they can take credit for your presentation and come along with you while you do. Finally, and where it hits home the hardest, is that smart CIOs don’t want the scrutiny that would come from an InfoSec department reporting on the shortcomings of the IT department. This would happen if you reported to someone else in the organizational chart. So if you report to the CIO, learn how to live with it, because it’s not going to change anytime soon.

Working with the Infrastructure Team

Once you’ve identified the keepers on your team, it’s time to distribute the work of InfoSec to those who’ve elected to stay. It should come as no surprise that the majority of the work in InfoSec is focused on the infrastructure team. The infrastructure comprises all those components upon which the company’s business data resides: cloud service providers, virtual machines, Amazon Machine Images (AMIs), EC2 instances, networks, operating systems, end points, servers, the data center, and so forth.

I like to assign each security team member to one of those areas as their primary customer. These team members are responsible for attending their customers’ staff meetings, for working with them to secure the components under their control, for building baselines, developing security processes, configuring systems, researching security issues, and staying side by side with their customer team members while they improve the security of their own systems and data.

When issues arise in these areas, it is your team member’s responsibility to work with the customer to solve them. It’s a model that works well and allows for individuals on the team to work initially in areas of their own choosing. These assignments will represent about 50% of their job. If you have only 5 folks on your team but 10 infrastructure areas, combine the areas logically and assign each team member to 2 areas. These areas will be their customers, their client base. In addition to these infrastructure areas, they’ll be given application support areas and other business unit responsibilities, depending on how your company is organized.

This is where the need for people skills is really required. Those who are successful will literally blitz their areas with their presence, emails, and presentations. In a relatively short time, the InfoSec message will get through to their colleagues, and the partnership for securing company assets will have begun.

Organizing your team is one of the four cornerstones of your program, as I outlined in Chapter 6. You can’t afford to get this wrong or hire weak players. Alignment with the organization matters, so each InfoSec team member will likely have multiple client groups. If you’ve selected the members well, your team will be an agile group with the ability to serve multiple clients at the same time.

The really good ones flourish in this environment and operate as if they’re running their own business. Once they get the philosophy of risk advisory, they can skillfully move from one department of the company to the next. Getting your people assigned and positioned into the business units is key and will net huge returns quickly.

Dealing with Toxic Security Leaders

In many of my security leadership positions, I was often hired on the heels of an InfoSec leader whose approach to InfoSec was absolute. They were security purists: security types who believe security is an all-or-nothing game. They live in a binary world of step functions; you’re either secure or you’re not.

They believe security is attainable if it achieves their idea of security. They lack business sense and misunderstand the concept of risk management. They take their job personally and seldom compromise. To compromise is to sell out or admit defeat. They are often aliens in the companies where they work—strangers, unable to get comfortable in the environment or ever settle in. These security leaders blame the organization for “not getting it.” The resistance they encounter is often rationalized as “the company doesn’t get it.” They believe that if the company understood security, it would embrace them and their approach.

These types often lack the self-awareness to understand that the organization forms antibodies against them in an effort to rid them of the toxicity they bring. The host is defending itself against them.

The concept of alignment is foreign to the absolute security type. They see their lot in life as one of martyrdom and view the persecutions as a badge of honor. They’re misguided and out of touch. They wish the organization understood the value of security, but it never does, and they therefore exist like foreigners from a strange land. Separation from the company is inevitable.

Eventually, the antibodies get so great they are removed completely. The organization excels without them, and there’s a sigh of relief among all when they depart. I could write a book about these types and the harm they cause their companies. Let’s save that for another day.

I have often been hired into this type of environment and faced the challenge of cleaning up the mess they left behind. Relationships must be mended. Credibility must be established, and a whole new complexion put on the face of InfoSec. Following one of these Genghis Khan–type leaders isn’t easy. It is, however, how I learned the value of relationships and developed the neighborhood watch model. If you do follow someone who left the InfoSec team in shambles, you’ve inherited the challenge of turning things around.

Turning Around an InfoSec Enemy

Most of you will encounter some passive-aggressive behaviors from other teams within the company. I’ve encountered this everywhere I’ve worked, especially during the early days on the job. At one company, it was the network services team members. They gave me no love. Their history with the InfoSec team was bad to the bone.

When I met the leader of the network services team, I was taken aback by their suspicion of me and their sarcastic tone. They’d seen many of my predecessors come and go. Each was equally toxic and harmful to the organization as the next. All were “flamers,” crash-and-burn types, and this leader didn’t like any of them. They assumed I was cut from the same cloth, and I couldn’t blame them.

After meeting with the network services leader, I assigned a new security engineer to work with their team. My team member did not know the history between the departments, and, like me, they were fresh meat for the old-timers in network services. In many ways, I felt as if I were feeding my team member to the lions.

I accompanied them to our first staff meeting and introduced them to the 15 members of the network services team. I took a few minutes to share with them our new approach to InfoSec, and how we wanted to establish the neighborhood watch with them. I asked for their patience and their feedback if we got off track in any way. You could have heard a pin drop. Not one of them said a word. All of them had a look of disbelief on their faces, and I wasn’t sure whether that was good or bad. I trotted on. I shared with them that my team member would be the InfoSec representative to their team, and all matters relating to InfoSec should include them. I went so far as to suggest a cubicle in their area be given to my team member as a place to sit when they were there.

After a moment, people started asking questions. We responded to them all. We both understood the challenge ahead of us. This was a rough group. They had strong bonds among themselves and had built up antibodies to all interactions relating to the InfoSec team.

We listened to their stories about the atrocities committed during previous InfoSec regimes and how they were still paying for them. I listened to the systems they were required to deploy in response to audits that were driven up their backsides by my predecessors. I listened to the verbal lashings they’d received from the CIO about their carelessness for security. Their resistance to security unified them. I had been in this position before; it was not new to me. We had to approach them with an extended hand and a willingness to support their efforts. But I realized the odds were stacked against us.

The engineer assigned to them from my team was technical and possessed good interpersonal skills. They were one of a rare breed whom I’ve worked with over the years. They loved both the widgets and the people. They were a perfect fit. They also had thick skin and welcomed the challenge. Even as a new hire like myself, they volunteered for the job, knowing the group was a pack of wolves.

I coached my team member about our approach, as they wanted to be successful. They were moldable. They jumped straight into network services with both feet. They immersed themselves in the network services staff meetings, made presentations, and worked shoulder to shoulder with their engineers. They learned the network architecture, reviewed the firewall rule sets, and spent time on designs and system configurations. They assisted in the provisioning process and helped with audit remediation. Whatever the network services team was doing, they were there. They became a part of the team. Their presence alone had an immediate impact for good. They spent lots of time with them, and actually was given a cubicle in their spaces. They were a natural, and it was easy for them to partner and be accepted. The plan worked brilliantly.

While they were immersed in all their work, we also spun up several network security courses for the network services team—courses like network pentesting, securing firewalls and DMZs, and network security monitoring. Many network services team members attended the courses. The word spread among their team that the courses were high speed and worth their time. Within just a few months, we had converts. The network services team appreciated the training. No one had brought world-class training in-house before. The courses were a huge win for us all.

Within a short time, the network services team members bonded to us. They became our partners. They took ownership over the security of their systems. We were no longer viewed as enemies of their team, and the animosity between the teams was gone. When trade-offs between security and performance were raised, we rolled in their favor. In the early days, we didn’t insist on security but let them make the decisions. After a couple of years, several of the network services team members went so far as to ask how they could get on the security team. We were honored.

Defining Roles and Responsibilities of Team Members

Now that each of your team members has been assigned to the various departments, it’s time to define what they will do with their new customers. I suggest your team members initiate their new relationships over hosted lunches. I even budget for lunches in the InfoSec annual budget. It’s one of the smallest line items in the budget, but the best spent money of all my expenses.

For the first lunch, I suggest that business not be discussed. Keep it all on a personal level. I’ve found that asking everyone to introduce themselves and share their favorite Netflix series is usually a great place to start. People love to share their favorite series, and this will easily take up most of the time. If you run out of time, ask for their favorite movies.

At the second hosted lunch, it would be a good time to introduce an industry standard framework that touches on the IT or engineering function they are assigned to. For example, if they are assigned to an end-user computing group, I like to share the NIST 800 and flip to the section on securing end points. The goal of this meeting is strictly education, to get the client team to start thinking about security and what they’ve implemented on the systems they administer.

No doubt, a look at industry frameworks will lead to a discussion from the team about which controls they should target for the next version of the system they are rolling out. Leave this up to them. You’re just a consultant at this point, and the decision is theirs. It is like magic to watch, though: all you did was present an industry framework of best practices, and in two simple hosted lunches, you’ve got them making a road map of changes they’d like to make.

During future meetings, you can begin to discuss which controls make sense in your environment. This will lead to a gap in controls and a discussion of whether any of the missing controls should be implemented. You’ll be amazed at how powerful it is to merely project an industry framework and see how the discussion goes. Other frameworks that make sense (depending on the team you’re meeting with) are OWASP, CIS Top 20, CSA, and ISO standards.

Next, I suggest your team member assigned to each area present a defense-in-depth model, as shown in Chapter 6, Figure 6-1. A good place to start is to ask them to identify all the security controls (logical, physical, and administrative) they’ve implemented for their system. Documenting this on the concentric circle they own will be a powerful visual. At future meetings, have your team member share the InfoSec charter, policy, and SIRP that you developed in step 2 (in Chapter 5). Finally, have your team member identify one technical training course to offer to this team.

Remember, security is a shared responsibility among all staff members and the InfoSec team. The team must be organized to serve the various business units of the company. Each team member should be assigned to an infrastructure team, and/or one of the application services or business unit teams.

STRUCTURING YOUR TEAM

To help you get a feel for how to structure your team, here is a sample of the responsibilities for one of my team members and their goals:

InfoSec road map and architecture

1. Develop/update a defense-in-depth architecture to reflect all the security controls within your assigned area. Present it to management for review and feedback.

Improve customer relationships

1. Identify team-building activities for IT groups that struggle with InfoSec policy.

2. Make four staff presentations to the various IT groups.

3. Ensure positive working relationships with all customers, third-party vendors, and contractors.

Educate and raise awareness among staff

1. Conduct 12 lunch-and-learns.

2. Collaborate with our communications person to promote awareness. Share with the team the items you’re working on and solicit feedback.

3. Collaborate with other InfoSec members to prepare a presentation for all IT areas. Make quarterly staff presentations to the various IT groups you support.

Build an extended InfoSec team that includes representatives from each IT area

1. Conduct monthly lunch meetings with agendas. Have the agendas reviewed by the head of InfoSec and presented at an InfoSec staff meeting.

2. Advertise the InfoSec meetings and ensure that representatives from the areas you support participate.

3. Chair the meeting as required.

4. Develop a list of the top 10 risks. Present this list to the CIO.

5. Validate all security policies and standards with the team.

6. Provide feedback to members’ sponsors on their involvement.

7. Own the action items from the meetings and follow up with the assigned areas.

Manage the top 10 risks across IT

1. Manage the top 10 risks in assigned areas. Track progress against all high-risk categories.

2. Develop metrics to track progress against all high-risk categories.

InfoSec representative to network services

1. Attend network services staff meetings.

2. Ensure participation in all projects and provide updates at the InfoSec staff meeting.

3. Ensure that network assets are scanned for vulnerabilities and patched per policies.

4. Participate in all audits that impact network services.

5. Be responsible for all security matters as they relate to network services.

6. Conduct pentest(s) and provide results back to network services management.

InfoSec representative to sales and marketing IT

1. Be responsible for all security matters as they relate to sales and marketing IT.

2. Conduct training for sales and marketing IT staff.

3. Attend staff meetings.

4. Participate in all projects.

IDS project

1. Complete the IDS project.

2. Ensure that all IDSs are operational and providing feeds to our monitoring service.

3. Obtain IDS certification for all installed systems.

4. Provide updates to InfoSec staff on the status of the project.

5. Manage all contracted support personnel.

Pentest

1. Lead and manage one announced pentest. Ensure that all areas (external web and cloud services, network perimeter, telco, wireless, and social engineering) are assessed and measured.

2. Track metrics for each assessment.

3. Develop a spreadsheet or reporting mechanism to store findings and remediation efforts.

4. Collaborate with IT groups to remediate findings.

5. Identify staff members who have moved the security boulder up the hill and recognize them in front of their peers and possibly monetarily.

6. Share all reports and progress at weekly staff meetings.

Audits (team goal)

1. Support corporate audits as required.

2. Support IT business unit audits.

Contract management (team goal)

1. Perform contract management duties as they relate to your assigned areas.

Perform on-call duties

1. Respond to managed security service provider (MSSP) alerts.

2. Manage InfoSec alerts received.

3. Manage the SIRP.

4. Respond to all emails received.

Common goals

Comply with all standards, policies, processes, and tools.

These are a lot of goals for one individual to carry, but I remind the team they are aspirational. We review everyone’s goals regularly at staff meetings so as to make adjustments along the way. No one feels overwhelmed or pressured by their goals.

As you can see by reviewing the goals, each team member is assigned to several business units within and outside the IT and engineering departments. Depending on the staff member and their level of experience, they may also have responsibilities to support one of the big-five departments: legal, HR, corporate security, corporate audit, and members of the C-level suites. In general, these groups are so important that I seldom delegate this responsibility but do most of the liaison myself.

Conclusion

Most InfoSec teams have one thing in common: they are grossly under-resourced to protect the company. You will never have enough staff or money to get the job done. This is our reality. I’ve seen only one or two exceptions in the financial services industry and among Silicon Valley tech companies.

For this reason, hiring the right type of engineers with outstanding people skills allows you to assign them to multiple teams. The process laid out in this book emphasizes relationships and team building, so people skills are nonnegotiable for success. Don’t hire someone who will create more trouble than they’re worth. You don’t have the time to manage them. Instead, hire energetic engineers who love to work with people and you’ll set yourself up for success over the long run. I’ve followed this rule for over 20 years, and it has never let me down. It has ensured my success and allowed me to build the InfoSec function the company wants from my team.