Step 1 focused on the value of relationships and getting to know your organization, its people, and culture. Step 2 was a necessary process of calibrating yourself to align with the company’s prevailing culture toward information security. Both steps are about getting to know others and making the internal adjustments within yourself to calibrate your approach to security, so that you can give your company the security department it wants from you.

This chapter covers the work of putting pen to paper and establishing what I like to refer to as the cornerstones upon which the early years of your program will be built. For steps 1, 2, and 3, you don’t need to hire anyone. All this work can be done by you alone.

The Four Cornerstones

With progress being made in steps 1 and 2, you can now turn to the actual work of building your cybersecurity program. There’s no time requirement for steps 1 and 2, so when you start on step 3 (the four cornerstones) will be dictated by your unique work situation. I do want to highlight that as you begin the work of the four cornerstones, you should never stop the work of building and maintaining relationships, and calibrating yourself to the company’s culture.

Let’s now look at these four cornerstones, the foundation of any InfoSec program:

· Documentation

· Governance structures

· Security architecture

· Communications

These four areas, along with relationships and alignment, always make up the bulk of your 30-, 60-, 90-, and 180-day plans you provide to management.

WHAT ABOUT A PENTEST?

Some of you may argue that I’ve omitted the obligatory pentest or risk assessment that should always take place in the early days of your tenure. I would counter this argument by positing that you don’t have enough information yet to scope the pentest, and executing one at this time would do little to ingratiate yourself with your new organization. While you’re trying to establish good working relationships, let’s not drop that pentest “love letter” on their desks.

As you follow my seven-step process, there will come a time when an initial audit or risk assessment will make sense. But let’s spare your new colleagues the heartache of doing one until your good working relationships are well established and your outlook about your job is aligned with the company’s.

Cornerstone 1: Documentation

You need to put in place three documents early in your tenure to lay the groundwork for success. These three documents are the bedrock of your department and function:

· Charter

· Information security policy

· Security incident response plan (SIRP)

Putting these in place early is critical to your success. Let’s take a look at each document and my recommendations for what each should contain.

The Charter

Simply stated, the charter enumerates what company leadership wants from your InfoSec department. It lays out in clear and simple statements the responsibilities of the InfoSec team while also enumerating the responsibilities of the IT and engineering teams for protecting the company’s information assets. The charter is important because it is a clear statement from company management regarding the roles and responsibilities of your team and how each of the eight domains is divided among you and your colleagues outside of the InfoSec team.

The charter spells out your team’s purpose for being employed at the company. Having a charter in place allows you and your team to align with the intentions and wishes that senior management has for InfoSec. The charter forces their hand to make a statement about InfoSec. It will set the tone and define the boundaries of your activities.

The charter is the primary vehicle for discussing with other departments (IT and engineering) the role your team will play in the company. These discussions are invaluable to your long-term success. More importantly, while writing the charter, you allow senior managers in IT and engineering to insert their ideas and interests in InfoSec and for you to enlist them in your work.

Fundamental to any sound InfoSec program is the belief that everyone is responsible for information security. Protecting information assets does not rest solely on the shoulders of the InfoSec team; it is everyone’s responsibility. The charter documents this shared responsibility. As the CISO, it is your job to make it everyone’s business. Chapter 7 covers this topic further.

Where to begin and what to focus on

You may discover that you work for a company that doesn’t care as much about InfoSec as you do. That’s OK, as long as you realize it. Codifying the company’s interest level and translating that interest level into your charter is what this document is all about. Deloitte has published an InfoSec chart that shows the InfoSec space comprising approximately 175 areas; knowing which ones will be your responsibility and to what degree is a main goal of the charter. Ultimately, the charter will clearly communicate to the IT and engineering departments about everyone’s shared responsibilities for protecting the company’s information assets. The charter is a RACI (responsible, accountable, consulted, and informed) chart in prose form.

So where do you begin with the charter? I recommend starting with the eight domains. List them one through eight. Then next to each one, write one simple management edict or statement about what your team will do to support this domain. One sentence is all you need. For example, for domain 6, Security Assessment and Testing, your one statement could read something like this:

Conduct periodic risk assessments to ensure that the security strategy and architecture are keeping pace with technology and the changing needs of the company.

That’s all you need. This gives you and your team the responsibility for conducting audits of systems and data to ensure they are being safeguarded in accordance with the needs of the company and the capabilities of technology in the market.

Next, include a section on roles and responsibilities: one for the CIO, IT management, IT staff, engineering staff and management, and the InfoSec team. Write one or two sentences describing the responsibilities of each group. For example, here is a statement that could be included to spell out the responsibilities for IT management and staff:

IT management is accountable for the security of the systems data that supports their business processes. They are responsible for implementing and maintaining systems, in accordance with cybersecurity policy and standards.

For example, if the IT department is responsible for providing video teleconferencing solutions like Zoom or Webex to facilitate virtual meetings for employees, then the IT department is responsible for the security of those systems. Likewise, if IT is responsible for providing laptops and end-user computing equipment to employees, then IT is also responsible for securing those assets throughout their life cycles.

As you develop your charter, I encourage you to keep it to one page in length.

How to pull it together

It’s your responsibility to write the charter, but you’ll want management and staff from across the company to be involved in its creation and approval process. To get the document reviewed, you’ll have to “drag it through the streets” and solicit feedback from the many teams impacted by the document. This also means that your charter may not come back looking anything like the document you initially created. That’s OK. It’s part of your alignment activities. In fact, that’s what you want! Appreciate the feedback and collaboration.

Before you discuss the charter with senior management, you should share it with your direct reports. Their inputs to your simple statements are critical. Your direct reports should share it with their team members for feedback as well. The only rule at this time is to do your best to keep the document as short as possible. Remember, write simple statements about each of the domains—no books and no long-winded paragraphs.

I’ve found that just by developing the charter collaboratively with others from across the organization, staff members start to own the security function with you. The charter (and other documentation) is one of the cornerstones of your legacy. And the beauty of the document is the process you follow to create it. Crafting the charter through conversations and meetings with others is the ultimate alignment method. During the document’s development, both parties align with each other. You, as the security expert, have the opportunity to hear the thoughts and wishes of those outside security. While the general staff members are confronted with aspects of security often for the first time, that must be addressed in their daily lives.

Keep two thoughts central to the outcome of the charter development process: senior leadership participation is critical, and the role of protecting the company’s information assets must be shared by everyone in IT and engineering. If you keep these two goals central to your efforts, the charter will be a success.

When taking the document to senior management, I’ve found the most beneficial way to gather their input is to first provide a copy of the charter and then visit them in person. Spending one-on-one time with each of them is key to gathering their thoughts. Not only will you get more information added to the document, but the discussion you share allows you to help shape their thoughts on security, for better alignment. You will quickly find out where management stands on security and who your advocates and detractors are.

This process also ensures they’ll own the charter going forward. I’ve found that having these conversations equates to getting what we want out of the document while still giving credence to the ideas that came from management. Just the conversation alone leads them to believe the ideas came from them and invests them in the final document. In the end, you don’t care who “owns” the ideas, as long as senior management has been part of the development. This will be critical when you and your team share it with their staff members.

You, as CISO, will have final editorial rights. My guess is that the charter ultimately won’t stray too far from what you want. If the document doesn’t look like what you anticipated, that’s OK as well.

MEETING WITH THE BOSS

Once your document has incorporated all the thoughts and input from the meetings, the final step is to discuss it with your boss. I suggest you get an hour of your boss’s time, if they can afford it. This meeting can be very telling.

It was during a charter meeting with my boss that we were able to discuss and develop our shared vision for the InfoSec program. During this conversation, I learned my boss knew more about security than anyone on his staff of three thousand. In addition, he was emphatic that to successfully protect our company’s information assets, everyone had to be involved.

Furthermore, he believed that he, and only he, could make security a responsibility in everyone’s job description. I couldn’t have asked for a better meeting. I hardly said a word the entire time. But when we were done, we were on the same page, and I knew he supported me and my function. The charter was completed. All senior managers had a hand at crafting it, and my boss blessed it as is and signed it. Alignment was well underway.

Now comes the difficult work of communicating the charter to the organization. This could take many months to complete and requires participation of everyone on your team. With the charter as our guide, we met with each IT and engineering group to talk about security. This was our opportunity to extend the hand of collaboration further. We wanted them to know we were not there to rat anyone out, but to partner with them to move security forward. Because senior management had blessed the charter, none of what we had to say was a surprise, and our goals were mutual.

Information Security Policy

After the charter has been signed into effect, your next chore in documentation is to get an information security policy in place. This policy lays out the expected behaviors the company wants from its employees regarding their responsibilities for InfoSec. It sets the boundaries on security and provides guidance to all staff. You’ll probably need to devote more time to this document than any other document you’ll write. HR, legal, corporate audit, corporate security, IT management, and engineering staff all need to review it before it gets approved. Being thoughtful in the way you create and design this document is critical to your long-term success.

Where to begin and what to focus on

The information security policy fundamentally reflects the behaviors and actions the company desires of its staff to protect the company’s systems and data. If all policy requirements were achieved, the company would attain the level of security it wants for protecting its information and computing assets. If your policy doesn’t reflect this, you’ve got the wrong policy.

The key to getting the policy right is that it must align with the risk culture of the company. It must capture the company’s intent for information security in written form. To get the policy right, you must assess where the security needle is pointed in terms of risk tolerance and then write a policy that aligns with that tolerance level.

This is not an easy process, and far too many InfoSec leaders start with a government website or industry standard. This is the wrong place to start unless it aligns with the company’s appetite for information risk or is required for compliance reasons. Most industry standards (for example, ISO, NIST, and Open Web Application Security Project, or OWASP) are written assuming that the security meter is pegged at maximum security, National Security Agency style.

ISO documents have been developed collaboratively by the best minds in our industry, and the security they’ve built into those documents are Fort Knox certified. This is not bad, but it most likely doesn’t reflect the risk tolerance of your company. The government has high standards for information security. Your company probably doesn’t.

Therefore, the level of detail in your information security policy, and the requirements of the security controls, need to be carefully considered. For example, consider your password policy. Deciding its length, strength, and composition may be better left to a committee and mandated through a company-wide standard. In contrast, the policy statement for passwords may require only that all systems be protected by passwords, without specifying the requirements.

You’ll also need to decide who signs the policy. As with all other company policies, I recommend this be the most senior person in the company. After all, the information security policy has just as much weight as an HR policy, or the code of conduct, or any other company policy, for that matter. The enforcement of the policy does not fall on the InfoSec team any more than the enforcement of company working hours falls on the HR team.

Managers must enforce all company policy. This is their job. This is to avoid situations where, for example, someone visits a website they shouldn’t and the company wants the InfoSec team to police this and address the culprit. The policy should clearly state that this is the manager’s responsibility, so we always pass these types of issues along to the employees’ manager. Let them handle all policy violations in their area, just as they would if someone were sexually harassing another employee.

Drafting and reviewing your policy

Creating and writing the first draft of the policy is fairly easy. Reviewing it and soliciting feedback from the myriad of teams, leaders, and managers who need to review it takes several months to complete. Ultimately, when the policy finally gets presented to senior management for signing, you want to be able to say that “you dragged it through the streets” and that every IT team, engineering group, and HR leader provided feedback, similar to the way you developed your charter. This brings credibility to your process and ensures that you’ve aligned the policy to the company’s culture and risk profile.

Finally, part of the process for maintaining the InfoSec policy is a periodic review. I recommend every six months you review and update the policy, cover to cover. This process is important, as it allows you to make adjustments to your original document and calibrate it to align with the company’s risk needle. After several review cycles, you’ll probably have your policy dialed in to the company’s culture and attitudes toward information risk—right where you want to be.

Getting the policy published is a lot of work. For the InfoSec leader in a new organization where no information security policy exists, this will be a heavy lift. For the InfoSec leader who inherits an existing policy, I recommend you wait six months before you suggest any changes. This allows you the necessary time to learn how the organization works and understand the company’s culture. If you touch the policy document too early in your tenure, you may be seen as overly aggressive, recommending policy changes in an organization that you’re not that familiar with. Avoid this.

Security Incident Response Plan

The final piece of documentation needed to complete this cornerstone is the SIRP. Incident response (IR) is the process of responding to and leading the company through an analysis of events that have put systems and data at risk by threatening the loss of confidentiality, availability, and integrity.

In this day and age, incidents are the soup du jour, so documenting this process is unavoidable. Once it’s documented, you must train the organization on their roles and responsibilities. This is often best done through a tabletop exercise.

Where to begin and what to focus on

The SIRP is super important because it is used only when the company’s systems and data are at risk, and all eyes are on you and your team. Given the amount of visibility your team gets when the company experiences an incident, you’ll need to have well-trained incident responders on your team, able to lead during a time of chaos and uncertainty. If you don’t have seasoned incident responders, plan to send a couple of your team members to a SANS course for IR training. Incident response is another area that you and your team will want to own entirely.

Your team’s role in IR is one of leadership (incident commander), and analysis (of logs). You will have to be closely partnered with the IT team leads and engineering teams as they have “right of imminent domain” over their systems. Your team will most likely never touch their systems, but they will look to you and your team to tell them what has happened in the environment. Your discovery from log analysis will provide this insight. I don’t recommend you let the infrastructure team be the only team to perform the log analysis, because of potential conflicts of interest.

How to write the SIRP

Obviously, you will write the first draft, but like the charter and information security policy, the SIRP document needs to be reviewed by the system owners since they will be the ones whose systems and data are the focus during an incident. The SIRP should contain a section on roles and responsibilities, as well as a flowchart indicating how incidents are handled and who is involved at each phase. Each incident should be closed out with a lessons learned session, and a final report generated to company leadership, telling the story from root cause through steps taken to restore company systems and data.

Takeaways

Keep in mind that the completion of the documentation for the first cornerstone happens early in your tenure—say, the first six months. This is done while you’re building relationships, and aligning yourself with your new employer and its tolerance for information loss. Your job is to build the InfoSec program the company wants and needs from you.

You can always turn up the dials on your program as the company becomes more educated regarding InfoSec. However, in your early tenure, allow the various groups to be involved in your decision-making processes. The outcome of those processes will produce documents that are in line with the relationships and alignment you’ve achieved across the company at this stage in your tenure.

Cornerstone 2: Governance

Governance was discussed in detail in Chapter 5, so I will not give it much discussion here beyond a quick review and summary. As mentioned in that chapter, governance is the management of decision making. Security governance is the management of decisions impacting the information security function.

I recommend that you open your decision making “town hall” style. This will allow others into your processes and show that you are a team player. Similar to your approach to writing documentation, letting others in on the decision-making process helps you achieve alignment with the organization. This is helpful to you as a security leader, since our natural tendency is to push for full security even if it isn’t necessarily what the company desires or needs. Letting others influence your decisions can be disconcerting because it implies handing over your decision-making responsibilities to others. But trust me, it’s to your benefit.

For every manager or leader, it is critically important to establish an early set of quick wins to gain momentum while building the InfoSec program. Doing so creates positive optics for you and helps others see you as a “winner.” Establishing an open governance process can easily be one of those early wins.

I recommend that you establish three information security councils: the Security business council, Extended Security Council, and Executive Security Council (all covered in Chapter 5). The existence of these councils creates a governance structure that guides the establishment of your InfoSec program. Each council is made up of different sets of people from across the company (technical leads, representatives from the lines of business, and executives).

The key to all councils is to let its members weigh in and voice their thoughts and opinions. You want this. Don’t get this confused with relegating your decision-making authority over the InfoSec function. It’s not. You’re asking for their input and guidance to allow you to make better decisions. For more details on each of the governance councils, refer to Chapter 5.

Cornerstone 3: Security Architecture

The third cornerstone is security architecture, or the thoughtful design of your security tools and processes. This is yet another area where you need others involved in its design and implementation. As you know, many of the security tools in the modern enterprise are managed by others outside the InfoSec department.

Security architecture can be an obscure topic for many, so I suggest you start by presenting the organization with a simple logical model focused on security controls at each layer of your computing stack: application layer, mobile and laptop devices, the network layer, servers and data centers, and cloud services—for example, Amazon Simple Storage Service (S3), virtual private cloud, and Elastic Compute Cloud (EC2) instances. If you’re able to document these, highlighting any gaps in your first year, this would be great progress.

What Does Architecture Look Like?

I like to represent the security architecture by using a simple defense-in-depth model (Figure 6-1). This concept is easy to grasp when represented in logical concentric circles, which also makes it easy to document all your security controls (logical, physical, and administrative) by layer or concentric circle. This simple model will resonate with both the techies and executives, and year after year it will be an easy way to measure the progress the organization is making in addressing any gaps in your security controls.

Figure 6-1. Defense-in-depth model

The defense-in-depth model starts with each concentric circle representing one layer of your company’s IT infrastructure or systems architecture. The layers of your infrastructure are up to you, whether you are mostly cloud based, on premises, or a hybrid of both. Most companies will fall into the following situations: cloud systems, perimeter networks, internal networks, data center/servers, desktops, handheld devices, data, and personnel.

With the inclusion of cloud computing, the model still works, but the names of each circle will change to reflect the cloud layer and technologies like VPCs, security groups, zones, and workloads/microsegmentation. On each layer, list your current security controls. Include the technological, physical, and administrative controls.

Then you can show a picture of the threats your company faces and any gaps you have in the defense-in-depth model in addressing those threats. I know it looks simple, but that’s part of its effectiveness. I’ve found that for most IT and engineering types, this is the first time they’ll see the state of their security defenses. It’s also a good idea next to each control to indicate the team responsible for that control. This will give the viewer a good picture of the role the many groups are playing in the security of company assets.

How to Put the Security Architecture Together

To build your first security architecture, I suggest you plan meetings with each of the IT departments to introduce them to the model and the overall defense-in-depth concept. Naturally, these discussions will lead to their “concentric circle” of responsibility. For example, during your first meeting with the end-user computing team or client engineering team, you might find they have the following set of security controls in their circle: anti-malware controls, encryption of hard drives, logging, host-based intrusion detection systems (IDSs), backup processes, DLP tools, OS hardening, and vulnerability management practices.

I suggest you document their existing security controls and do so without much discussion about gaps or threats. This is their current as-is architecture. It’s neither good or bad, adequate or sufficient at this time. Your goal is to get it documented and to get them talking about their current set of security controls. Save discussion of changes for future meetings.

During your next lunch meeting with the client engineering team, I suggest you share the security controls for laptops as contained in the NIST document. The NIST framework is not intended to be your standard for laptop security, but to educate the client engineering team on the variety of security controls available to them. I guarantee that by projecting this list, you’ll trigger a great discussion with their thoughts on the security controls they could implement. Two meetings in, and they are already discussing security improvements.

What’s the Outcome of Developing the Security Architecture?

Taking the various IT and engineering teams through an architecture exercise has many benefits. Foremost is education. The teams will gain an understanding of the many security controls available, many of which they weren’t aware of. For example, the client engineering team may discover that installing host-based IDSs will help combat the spread of malware and provide safeguards for malware missed by the anti-malware software installed. Most client engineering teams are unaware of host-based IDSs until your team informs them, often by reviewing a list of best practices for securing laptops.

Another outcome of developing a security architecture is that teams will start to think about their road maps for security and make plans to implement security controls in future iterations of the systems they support/own. For example, our client engineering team realized after their second meeting looking at best practices that they had only 5 of the top 10 security practices implemented. As a result, they placed the remaining five on their road map for the following year, presented it to leadership, and received funding for all the planned security controls. We attended those presentations and had to say very little. Instead, the client engineering team did all the talking. They sold every new security control to leadership and presented the tools and costs. It was wholesale approved on the spot.

One more advantage to having these architecture meetings with the many IT and engineering teams is that you and your team have the opportunity to ask the key question they should consider when designing their security architecture: what are the threats you face? That’s the key question for the client engineering team. What are the key threats to confidentiality, integrity, and availability, and how have you taken steps to mitigate those risks?

The outcomes of this type of discussion are huge for you and the company. This leads the client engineering team to begin to think about the “why” of their work. For example, if the laptop is lost or stolen, what security controls are in place to protect the company from loss of sensitive information? The team will get to the solutions of encryption, remote wipe capabilities, strong passwords, backups, LoJack, and possibly more. This is a win for you and your team, and all you had to do was order some lunches, present some industry frameworks, and discuss best practices.

On that note, the last benefit of the security architecture exercise is that management will see that you are under-resourced for the task at hand. I’ve been in this position many times, and it’s nice to hear management acknowledge, “InfoSec is going to need more people!” Often at this point in my early days I’ve been asked for a staffing model for the InfoSec organization. I find this to be the best path forward, with management admitting you need to increase your staff.

Cornerstone 4: Communications, Education, and Awareness

If you subscribe to my assertion that your only hope to protect the company’s information assets is to get everyone involved, then you’re going to need a communications plan. A communications plan will contain your strategy to reach every staff member in the company regarding their unique responsibilities for information security. Staff members won’t know their responsibilities unless you tell them. They won’t know their responsibilities unless you communicate what’s expected from them regarding information security. It’s the communications plan that makes this a reality. Communications is a never-ending process, and so important that I hire a dedicated staff member to lead our communications and education efforts.

Not many InfoSec teams will dedicate a head count to a communications person. To me, they are the most important person on the team, focused solely on communications, awareness, and education. With one staff member dedicated to this function, the rest of the team will likely for the first time consider ways to reach areas of the company that otherwise would have gone overlooked.

One of the common rules of marketing is that people have to hear something seven times to make it stick. InfoSec requires just that kind of communication—clear, concise, compelling messages repeated over and over. Chapter 7 covers the details of communications, education, and awareness.

The Benefits of Training and Educating Others

Part of your communications plan is training. Providing training to others is one area where the InfoSec team gets to shine. If you train the organization’s IT and engineering staff through a variety of InfoSec technical training courses, you’ll deputize a powerful group into the security team. The IT staff should be your closest ally in protecting the company’s information assets, and providing specific and relevant training will be like adding staff to your department. In fact, I’ve found that once you train the IT staff about information security, you’ll find them owning the security in their areas and not needing much help from your team.

Plan to spend a large percentage of your budget on awareness and training for all staff. This amount of investment is challenging to most InfoSec managers because training doesn’t fit their model for security, and it doesn’t play well to their experiences or their skill sets. Fundamentally, many security types doubt its value and view it as a waste of time, so suggesting they devote a large portion of the budget to this activity seems nonsensical.

However, my experience tells me that a customized training and education curriculum for administrators, general staff, managers, and executives will give you the highest ROI of your team’s time. As you provide training to others, you’ll quickly see results and understand the value of the training. Training of IT and engineering staff helps other teams understand your foundational documents like the charter or the information security policy. On their own, these documents don’t mean much to general staff, but after you provide InfoSec training, you’ll witness how these documents are taken more seriously. Training will also educate IT and engineers on the SIRP. This will be a huge lift for your team. Deputizing trained engineers in the way of IR makes incidents so much less challenging, they almost become nonevents because for those trained in the process, they become second nature.

Developing a communications strategy is key to your success. It details the messages to be delivered to everyone in the company, along with who from your team will deliver the message and the frequency. If you take communications, awareness, and training seriously, your organization will become a true, self-defending company.

All of the communications activities I’ve listed here, and those I discuss in Chapter 7, will do more for increasing the security of your information assets than any technology or increases in staff. While you’re building relationships and aligning with the company’s culture, you can start these activities immediately.

Conclusion

All security programs consist of eight domains, and over time you’ll be deep into all of them. The four cornerstones I’ve highlighted in this chapter are where I urge you to start if you’re new in your job. For those tenured in your positions, these cornerstones can also be used as a quick benchmark. Focusing on the cornerstones of documentation, governance, security architecture, and communications will set you up for success and allow you to build the security function your company wants from you. The walls of information security surround the entire organization. Implementing the four cornerstones will require lots of hustle to complete, but hopefully you enjoy building a program as opposed to just maintaining one.