Chapter 7 discussed the importance of communications and education to the security leader. Hopefully, you’ll give some thought to the role communications plays in your organization, and the multiplicative effect it can have in your efforts to secure information assets. As you educate others in the company, and especially those in technical positions, you’ll often be able to either partner with another team or completely transfer to that team a piece of the InfoSec pie.
Don’t resist transferring security responsibilities to others outside your team. Although our natural tendency is to keep those responsibilities under our control, releasing them to another team is putting in place the neighborhood watch throughout the company. Remember, I said your company doesn’t stand a chance unless everyone is involved in protecting its digital assets. Giving portions of your job away to other colleagues is a blessing you shouldn’t pass up.
Giving Your Job Away, a History Lesson
Let’s take a brief look at the history of computing since the 1990s to understand how security responsibilities have naturally transferred to other teams as our industry has matured. This transition of InfoSec responsibilities to others in the company wasn’t my idea; it’s been happening for a while. I just happened to spot the trend in the late ’90s and have watched it accelerate since then.
The question for every security leader is, what role do you play with those teams now responsible for some portion of the security pie? To effectively “manage” these transferred processes, you need well-established governance practices, as highlighted in my discussion on security councils in Chapter 6.
The 1990s
To those of you who were in the industry 25 years ago, you will remember that most, if not all, security activities were performed by the security team. Before browsers existed, we used search tools called Archie, Gopher, and Veronica, which crawled our directories to retrieve files we searched for. These services were first found among government agencies and universities.
I was in the Navy during this time, and all InfoSec functions were performed by dedicated security engineers and cryptographers, most of whom were DoD contractors. Electronic communications, depending on the classification level, were encrypted using encryption keys that were manually rotated at predetermined intervals. Most computer equipment was stored in secured locations called sensitive compartmented information facilities (SCIFS), which were restricted vaults containing classified materials. Most of the security processes and controls were physical controls. For example, you often needed two people to enter the SCIF, and written logs were kept to record the names of individuals entering along with the date, time, and purpose of the visit. For top-secret SCIFs, each of the two people entering had a portion of the key required to unlock the door.
Later in the ’90s, we were busy installing wired networks like Fiber Distributed Data Interface rings and 10-baseT Ethernet networks, and in the early ’90s we were just beginning to connect these networks to the internet. With new internet connections, firewalls had to be installed, but not many were available on the market. The first firewall I used was from Trusted Information Systems, out of Rockland, Maryland, called the Gauntlet. The firewall was treated as the ultimate access control device and not managed as a network device. As such, its administration was naturally performed by members of the security team, and not by the network support folks.
The Gauntlet firewalls were super innovative, as they had site-to-site virtual private network (VPN) capabilities, the ability to transfer public keys over the wire, and a layer 7 proxy (no other firewall to date had this type of innovation). Prior to the Gauntlets, you had to install keys using a floppy disk (5 1/4”) and coordinate the date/time of the key installation. The Gauntlets automated all this for us.
For disk encryption, we were using the NSA’s Fortezza cards, which encrypted the hard drive through the Personal Computer Memory Card International Association (PCMCIA) slots. For file encryption, AT&T had a desktop package called Secret Agent that was a handy application allowing for file-level encryption and the ability to attach files to one of the few email systems in use, in our case, DEC’s TeamLinks.
My point in mentioning these technologies is to illustrate that in the early days, all of these tools were administered exclusively by the security team. Nobody else on the IT team was allowed to touch them. We wouldn’t think of letting others outside of security management have control over these systems.
The Early 2000s
As we approached the early 2000s, security teams often continued to administer and manage the organization’s firewalls. However, that responsibility quickly shifted to the network services team as we acknowledged that firewalls were basically networking devices (routers) with access control list (ACL) capabilities. A similar transition also took place on desktops and laptops. InfoSec teams were previously responsible for all the security controls on the end points. Technologies such as antivirus software, disk encryption, end-point firewalls, host intrusion detection, log collection, and backups all were responsibilities of the InfoSec teams.
By the mid-2000s, all of those tasks had migrated to the IT engineering teams. This transfer of security tools marked the beginning of the shift of security responsibilities from the security team to others throughout the company. Among the security departments privy to these shifts, we discovered we played more of a governance and oversight role than a hands-on administration role for these tools. The great shift was in full swing.
The Late 2000s
By 2010, identity management (IDM), also known as identity and access management (IAM), was one of the last functions to be transitioned out of security and into the system administration or operations team. Ownership for directory services (AD and LDAP) or Amazon Web Services Key Management Service was transitioned to the system administrators or operations team. Rarely would you find the security team performing IAM functions. Whether we liked it or not, by 2010 we found ourselves in a distributed model of security, or what I have coined the neighborhood watch.
In simple terms, the neighborhood watch is an operating model that makes system owners (for example, a Unix administrator or network engineer) solely responsible and accountable for the security of their systems. As in a neighborhood with limited police presence, the neighborhood watch shifts some of the responsibility for “policing” into the hands of the residents. Everyone is expected to be on the lookout for suspicious behavior, and to report crimes or suspected crimes when they’re observed. This is the model for the neighborhood watch.
As this trend to give security tasks to other IT and engineering groups continues, I strongly recommend you leverage it. I believe it’s your only hope to truly secure the company’s digital assets. If you encounter an opportunity to transition some of your work over to other teams, give close consideration to it. You’re not going to lose your job, and it only helps to further your cause as the security leader. The neighborhood watch is a great model to strive for, and it is for the overall benefit of the company.
2010 to Today
Today, the security function secures an IT infrastructure that is all cloud based, and our security responsibilities look nothing like they did 25 years ago. Yes, many of the same tasks are being performed, but not by the InfoSec team. For example, the DevOps team does almost all of the security for its environment. We supply some basic enterprise identity services, and mandate the use of cloud orchestration and compliance software, but all core security functions and decisions for our cloud operating environment are performed by the DevOps team. It’s through governance models, as discussed in Chapter 6, that the InfoSec team is able to provide leadership and influence.
The security of platform as a service (PaaS) is largely a responsibility of the development teams. The software security engineers who report to me have little to do with securing the development processes. We can suggest, consult, offer assistance, and try to influence, but in the end it falls on the shoulders of the developers. Welcome to the neighborhood watch! Today few security teams are involved in supporting any of those tasks beyond consulting and policy guidance. It’s why I’m a big fan of RACI charts, and being very clear on roles and responsibilities for security and who is doing what.
Understanding Your Challenge
Many of our functions have transitioned to other teams, and I propose this is good for you and the company. But it does create a dilemma for you: although this transition has taken place, your company leadership still thinks you’re responsible for security across the company and that you’re involved in all of these areas, providing leadership. In many cases, company leadership looks to you as responsible and accountable, even though the truth is, you’re not.
As I mentioned in Chapter 1, the odds are against you because nobody really knows your job. Few senior executives have any security experience. This is why I suggest you use RACI charts among all your security partners so everyone is clear regarding roles and responsibilities for security in their areas. Creating RACI charts is time-consuming, but the task is well worth the effort. Going through the process with the teams will lead to clarity around roles and responsibilities for their security tasks. This will benefit both parties and help solidify the neighborhood watch, a model I believe you want.
MCAFEE, YOU SURPRISED ME
I want to put in a plug here for McAfee, because it made a brilliant move: McAfee hired a prior CISO to be its CIO. What a great move by McAfee! I’ve been predicting this trend would happen for years.
If you look at the to-do list of most CIOs and infrastructure folks, it’s a long list of security initiatives. The hardware and software in our systems is not unstable, as it was 15-20 years ago when lots of outages led to significant system downtime. Today our systems are so stable and reliable that availability is rarely an issue.
And with the advent of software as a service (SaaS) and infrastructure as a service (IaaS), there isn’t much in-house work for CIOs to do anymore. Most of the development (cloud services, mobile apps) has been handed over to engineering teams. Other than business process work, CIOs have lost the core of their work to SaaS companies, which have taken the place of in-house developers.
Most CIOs I meet with now claim they have security experience—no doubt to protect their jobs. So this move by McAfee to hire a prior CISO to fill the CIO position was brilliant. Naturally, that person will be on top of all the security issues, and if they have the customer service skills required of CIOs, then it will be a great move for McAfee and its clients. I believe this trend will continue. And more current CIOs will claim they have security in their backgrounds.
Relationships and the Neighborhood Watch
As the InfoSec world has moved to this new distributed model of the neighborhood watch, the value of relationships has escalated. The new neighborhood watch asks the business and systems to share and own responsibilities that they historically never had. For example, an InfoSec team may not be that involved with the company’s data sciences team and blind to where the team pulls its data from, and where the output of their analysis is stored. If this is the case, the InfoSec team will have little insight into the security controls throughout the process.
InfoSec provides some general security controls for authentication, network layer security, and encryption of data at rest, but we most likely have no idea of the security controls used throughout the data analytics process. One of the messages in the neighborhood watch is that the InfoSec team is here to help, but like the local police department, we must be called in to be of assistance. If invited in, we get as involved as the system owner would like, but until we’re invited in, we’re able to influence only through policy.
In the neighborhood watch model, the security team should be involved in discussions with the system owners about the many security controls possible to them as system owners. Not that you approve or review the details, but you’re involved across the systems landscape with the security decisions being made. You don’t want your system owners performing security functions without your involvement.
Being involved connects you back to the many cybersecurity governance councils I spoke about earlier. Through these councils, you’re able to partner with your fellow neighbors (system owners) to provide the proper guidance and technical support they need in order to feel as though they have sufficiently protected their assets.
The Need for Governance
As security tasks and responsibilities get spread out among the various teams, the importance and need for governance rises. As I discussed in Chapter 6, governance is an essential way to align with the organization. In the world of the neighborhood watch, governance becomes a cornerstone of your efforts as a security leader. All of the security councils should be owned by you and your team, and through these councils you have an opportunity to establish and maintain good working relationships.
If you fail to maintain outstanding working relationships as you establish the neighborhood watch, you may be putting your job in jeopardy. I believe it’s why we see so much turnover in the CISO ranks. CISOs aren’t focused on keeping relationships central to their program. Those of us who get fired usually do so because we’ve failed to invest in relationships. Hopefully, this book has convinced you of the need to spend more time with others, cultivating good working relationships.
The flip side of effective governance occurs when you get the “invisible middle finger” instead of a hand of partnership from those who resist or resent your involvement in their security decision-making. I’ve always encountered a handful of teams that play respectfully with you, but silently don’t want anything to do with you or your program. They’re operating independently from your processes, out of arrogance or self-centeredness. Although they behave politely in meetings and say all the right things, the minute the meeting is over, they have no intention of doing anything that was discussed. They do all they can to stay as far away as possible. You know who they are.
They don’t consider themselves neighbors in the neighborhood watch, but operate from a point of independence and self-sufficiency. They may resent you as the security leader or not respect your skills, believing you have little to offer them, so why bother to be involved with you and your team? These folks are not good corporate citizens. Without strong company leadership directing them to “play” with the rest of us, they will be rogues in your environment.
In situations like this, it helps to keep in mind that the security game is played out over many laps around the track. Some teams need more time before playing nicely with the rest of the company. In some situations, I’m not sure you ever really win them over, but your goal should be to get them to a place where they participate in your governance processes and contribute to the overall security of the company, which benefits everyone. Be patient with groups that give you the invisible middle finger. In the absence of good leadership from above, kindness and patience is your best approach in dealing with this crowd.
Understanding the Risks to Giving Your Job Away
As I’ve highlighted, the transition of security functions to other teams began in the late ’90s and early 2000s, and no doubt this trend will continue into the future. As a security leader, you are responsible for a function consisting of a workforce of many neighbors, each playing a part in the neighborhood watch. However, risks come with this type of distributed operating environment. I list a few of those risks in this section, with suggestions on how to navigate your way through them.
Risky Situation 1
In this situation, the team that “owns” a piece of the security pie isn’t performing its security responsibilities very well. This is a tough situation to be in. The problem is that company leadership most likely views you as responsible and accountable for security in this area, and changing this perception will be hard. You’re at best able to influence the team members, but ultimately they are doing the work. What do you do in a situation like this?
First you need to do a better job educating leadership on the roles and responsibilities of key IT and engineering teams. Although you may never present management with RACI charts, you nonetheless should convey the key messages of those charts to leadership and management. You should emphasize the viewpoint of the neighborhood watch, and the importance of everyone being involved, to help them understand. This situation will pop up again since you don’t “own” the security in many areas, but the company leadership believes you should or do.
If you encounter this situation, tell the truth, but do so in a way that is favorable to the system owners. For example, indicate that they’re making lots of progress, that they’ve come a long way over the past year, and that they started with little to no security controls.
Focus on the road map for this area, and where you hope to be in the next six months. I’ve found that praising the team for their accomplishments, even if they are not where you’d like them to be, will serve you better than telling the blatant truth and throwing them under the bus. This doesn’t serve you well.
The next thing you could try to do is meet with the underperforming team to review one of the many industry frameworks that enumerate the security controls possible for the systems they own. Often I’ve found that merely reviewing the section of the NIST framework relating to their systems helps them see the need for increased security. Using the framework allows you to raise awareness among the team, without the message being delivered from their peers from the InfoSec team. It almost always works. Give it a try.
Risky Situation 2
You may also encounter a team responsible for the security of a function that is making poor security choices. Team members may be buying tools that don’t integrate well into the company’s security architecture, or may be choosing to run the tool so infrequently that it’s rendered ineffective (for example, monthly). How do you handle this situation?
My recommendation here is again to be patient and kind. This team doesn’t work for you, so keep in mind that your interactions will be more influence based than directive. Although the system owner may not make the choices you would like, they are taking ownership over their area, and for this they should be acknowledged and praised. As I have said, I like to view progress in terms of laps around the track. In this case, patience with the team will mean that during the next lap, they will have the chance to improve upon their decisions and move security forward. In addition, between now and then, you can bring in security training courses that hopefully move them in the right direction.
Finally, praising the team members in front of their management usually causes them to drop any walls they might have between your two teams. Once they know that you are genuinely seeking their success, you’ll find them to be more willing to look to you and your team for input and guidance. This is a win for everyone.
Risky Situation 3
In the third risky situation, you may find yourself working with a team that is difficult to work with. The team members don’t want anything to do with your team, and they make that blatantly clear. You’ve probably never encountered this, right? If not, count your blessings. I see it frequently. As I mentioned earlier, it’s the classic invisible middle finger situation, and like surgery, it needs to be handled delicately.
If you haven’t personally seen or felt the invisible middle fingers, you may have missed them. Here’s what they’ve looked like from my experience. One of your client teams will meet with you, but once the meeting is over, you know they have zero intention of doing anything that was just discussed. Before you hit the door of the conference room, they’re grinning at each other and nodding their heads, acknowledging to each other that the meeting was a colossal waste of time, and that they realize there is little to no consequence for ignoring company security policy or anything that was just discussed. They’re just playing you, and you got played.
This leads me to yet another guiding principle: go where you’re wanted. There’s lots of work for you and your team. There’s all the work you’re directly responsible for, and there’s all the work you must be involved in because you’re the head of cybersecurity. So knowing your time is limited, work with those who want to work with you. In time, the outliers will come into the fold. In the meantime, patience is your strong card. Play it often.
Working with Your New Neighbors
As I mentioned previously, Deloitte decomposed the InfoSec space into more than 175 subcomponents. Outside of your team, few could name even 25 of the areas. You’ll never be staffed to secure 175 areas, so just accept that you’ll need help, and spend your time getting others involved to ensure more areas within InfoSec are covered for the company. Now that you understand that the neighborhood watch is your remit, how do you get it started? How do you get others involved so that they can take responsibility for their systems and areas?
Let’s look at the network services team as an example. Your first meeting with this team should be over lunch with the sole purpose of connecting on a personal basis. Do not discuss work. If you have a team, assign one of your folks to this area as a collateral duty—meaning this isn’t their full-time job, but rather a secondary duty, working through influence only. It’s their job to work with network services to raise awareness of the many security controls available and to be mindful of security in all they do. Much of today’s networking functions are really security tasks.
I believe that at most companies, network security has been relinquished to the network services team. Needless to say, this team is a big partner of yours. These team members are so important that I recommend you offer them network security courses. This will ensure they are educated on the security of the systems under their ownership. This will cost a little bit of money, but once again the ROI is off the charts.
At the second meeting with network services, I recommend you begin the discussion of roles and responsibilities for the security of the network. You could start with your charter, with statements like this:
IT management and staff, working with their business counterparts and InfoSec, are accountable for the security of the data and systems that support their business processes and goals. They are responsible for implementing and maintaining systems, in accordance with InfoSec policy and standards.
Usually, other teams want to “own” the entire space of their services and don’t want others, like the InfoSec team, involved in their work. Working within a model of shared responsibilities is a delicate balance, and it requires management finesse to pull off. In these partnership situations, you need their cooperation, so allow them to embrace security at their own pace. I’ve found that over time, the other teams are actually doing more for security than I had hoped for. It’s a beautiful situation.
Helpful Hints for Working with Other Teams
Take every opportunity to recognize the many teams and individuals who move the company toward increased security. Public recognition of others always pays dividends, often in ways you can’t fully appreciate. It also has the effect of showing others that you put them first and are willing to acknowledge their contributions in front of others. This is contagious. Make recognition of others a part of every presentation. Be known as a leader who gives credit to others.
Next, meet with all the other teams performing security work at least quarterly. If, for example, they are securing end points (like the client engineering team), I suggest monthly or every other month. This team is so important and central to your strategy that it warrants meeting with them more frequently. I recommend that all the meetings be over lunch. I try to open every meeting with 15 minutes of personal connection and not discuss business or the meeting objectives. This can wait.
Next, maybe twice a year, meet with the management of every team with responsibilities for security. Take the time during these meetings to acknowledge all their contributions and how appreciative you are of their accomplishments. Let the boss hear from you about the great work they’ve accomplished and the improvements in security in their area. You want a professional partner for life? Praise them in front of their boss and you’ve sealed the deal.
Finally, make plans to offer professional security training courses to these other teams. All techies love professional training, and offering cybersecurity technical training classes shows that you care. Before the classes are offered, meet with the instructor to discuss the course objectives and ensure that their materials align with your environment and policy. If done correctly, these courses can be your extended voice to the other teams. This should be a huge win for you, so plan it wisely.
Conclusion
As I said at the start of this chapter and elsewhere in this book, your only hope for securing the company’s information assets is to get everyone involved. In particular, you need the IT and engineering teams involved, as they own most of the company’s systems. Since the early 2000s, the trend has been to shift security responsibilities to the system owners. Many in the company, especially the leadership, may view the CISO as responsible and accountable for InfoSec, but in actuality the CISO is usually able to only influence other teams and nudge them toward greater security. Operating in this type of environment takes more time to get security right across the company.
As you work with your new “neighbors” and give your job away, focus on what matters most. Be patient with your new neighbors. View the journey with them as having many laps around the track. Praise them as often as possible, especially to their management.
Finally, treat everyone with kindness. Ignore the invisible middle fingers. Go where you’re wanted and work with those willing to work with you. Bring in professional training courses to enhance the skill sets of other teams. And remember, governance grows in importance as you add new neighbors into the neighborhood watch. If you practice just some of these actions, you’ll be well on your way to building a solid InfoSec program.