I grew up during the time period when the security landscape was covered by the 10 domains. I’ve chosen to discuss our industry in terms of these domains (although now there are only eight) as opposed to one of the industry’s well-known frameworks because the two are fundamentally different models. The eight domains by and large discuss the theory and science of our field. The many industry frameworks—including those from the National Institute of Standards and Technology (NIST), International Organization for Standardization (ISO), Cloud Security Alliance (CSA), and Center for Internet Security (CIS)— discuss the numerous security controls to be implemented to protect systems and data. The eight domains provide a discussion on the content of the science of InfoSec.

My intent in this book is not to rehash the content of the eight domains, but to merely highlight those sections that I believe you’ll want to focus on when building an InfoSec program. Not all domains are of equal importance when you follow my seven-step process. Knowing which ones to focus on will help you build your program.

As a refresher, the eight domains of InfoSec are as follows:1

1. Security and Risk Management

2. Asset Security

3. Security Engineering and Architecture

4. Communications and Network Security

5. Identity and Access Management

6. Security Assessment and Testing

7. Security Operations

8. Software Development Security

Why Am I Commenting on the Eight Domains?

I view the eight domains as the science of our profession, the “left brain” of our work. These domains provide the technical specifics of the broad field of InfoSec.

When viewed in detail, the eight domains reveal how vast the InfoSec discipline really is. To the newbie trying to break into the field, they can be overwhelming. To the audit professional trying to transition into InfoSec, it’s a wide chasm to pass, and few can make a successful transition. To those of us who have been in the industry for a while, it’s remarkable how much information the security professional needs to absorb relating to our technology, processes, frameworks, and models. I don’t know of another technology area with the same breadth of content.

As an InfoSec leader, you’re required to have expertise in all eight domains. The 8 domains can be decomposed into more than 170 subdomains. That’s right, 170+ subdomains. I recommend that every InfoSec worker be a lifelong student of our trade and master all eight domains. As I say this, I know from my own experience that it is extremely difficult to locate and hire eight-domain team members. And when you require an engineering degree, it’s virtually impossible.

I argue that few have mastered the eight domains. Many in our industry specialize in certain domains and have little exposure to the others. I attribute this to the way InfoSec departments are run and the failure of many managers and leaders to encourage cross-training and professional development.

NOTE

Talent is hard to find, and developing a standard set of interview questions is a good idea for you and your team. Here’s one that I love to ask: “Describe the difference between encryption, compression, and encoding.” Responses are quite entertaining, with creativity you can’t imagine. Candidate responses are often so outrageous it can be hard to keep a straight face. One candidate, when responding to a question about the relationship between bandwidth and throughput, pontificated about the new “10-bit byte” Ouch! There’s much I could say about this, but not in this chapter. (I cover this more in Chapter 9.)

For those who wish to master the eight domains, the SANS Institute is probably your best place to start. Stephen Northcutt and the team at SANS have built a world-class education center for our profession. For free, you can get high-quality training courses on YouTube. I recommend that you take advantage of the many learning opportunities available and commit yourself to a career of learning.

The eight domains are the bedrock of our profession. If after reading this book you decide to follow my seven-step process, you should know that not all domains are of equal importance when establishing your program. Some are best handed off entirely to IT, while others can be sliced up so pieces are transferred to IT or engineering teams. The remainder of this chapter discusses the domains and how each should be viewed and treated in this approach.

Knowing the eight domains will give you the knowledge to traverse the technology and understand its inner workings. But mastering the eight domains will not make you successful in our field. To be effective at your job, you need to understand the art of our profession, which I’ve laid out for you in my seven steps. The intent of this chapter is to provide guidance on how each of the eight domains should be handled if you follow those seven steps to success. The remainder of the book, after this chapter, is dedicated to the details of following those steps.

Domain 1: Security and Risk Management

The Security and Risk Management domain focuses on big, foundational components of your program. Much of your time building out your program will be spent in this domain. This domain consists of the following:

· The confidentiality, integrity, and availability of information

· Security governance principles

· Compliance requirements

· Legal and regulatory issues relating to InfoSec

· IT policies and procedures

· Risk-based management concepts

This is the first and most important domain. You need to get this one right. It sets the foundation for all your future work. The activities in this domain lay the groundwork for your success as an InfoSec leader within the company and in your work with all the other domains. Although this domain covers quite a bit of material, I believe that most of your time and energy should be focused on three of the subtopics covered in this domain: IT policies and procedures, security governance principles, and risk-based management concepts, which I discuss next.

IT Policies and Procedures

One area you need to get right is IT policies and procedures. To get your program off the ground, your initial focus should be on three documents: the information security charter, information security policy, and security incident response plan. These three documents are the bedrock of your department and function.

Your information security policy, which is different from your charter, 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, and engineering staff will 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.

All three of these documents are covered in more detail in Chapter 6.

Security Governance Principles

Security governance principles is the next subdomain where you should spend a lot of time during your early days on the job. Governance is the management of decision making. Security governance is the management of decisions impacting the InfoSec function. As with your IT policy, you have to get this one right too.

Early on in your tenure, you should make most of your decisions through a governance council, to allow others to weigh in on your decision-making process and to show that you are a collaborator. I recommend that you establish three InfoSec councils from the onset to create the governance structure that guides your program going forward:

Security business council (SBC)

The first council includes representatives from each business unit. Through this council, you’ll run your entire InfoSec strategy, new purchases, security architecture, InfoSec policy, plans for awareness and education, and phishing program, to name a few.

Executive security council (ESC)

This group consists of the most-senior people in the company. This council will review the inputs and recommendations from the SBC. The ESC will provide the final review and approval of the major recommendations arising out of the SBC.

Extended security council (XSC)

The third council I recommend you establish consists of the most-technical people in the company. The members on this team are really an extension of the InfoSec team, and their role as advisors is highly valued. Through the XSC, you’ll want to pass all the technical components of your program.

All three councils are critical to your success. They are a visible sign that your management style is open and inclusive to other departments and to their opinions, thoughts, and attitudes toward InfoSec. The frequency at which the councils meet will be dictated by the needs of the business. Whom you invite and choose to chair the meetings is also important. I always attempt to have each council cochaired by someone from outside the InfoSec team. These councils are discussed in more depth in Chapter 5.

Risk-Based Management Concepts

Finally, the risk-based management concepts are about understanding the company’s tolerance for information loss, and then applying the security controls commensurate with that tolerance level. This isn’t easy to do, let alone to get right. You need help here, and using the three councils is critical to getting risk management right. To get a grasp on your company’s tolerance for information loss, ask yourself these questions: If today your company had a major breach or loss of critical data, would the most-senior people in the company care much? Would it rock your business?

I had an incident that answered these two questions for me. I experienced a breach, and it got hardly any attention. A couple of attorneys wondered whether I needed to notify our customers, but within a few days, it had all blown over as if nothing had happened. The company’s response was silence. It was beautiful from my perspective. No one asked for InfoSec’s opinion. No one wanted to call a meeting to understand the root cause of the breach or to ensure it didn’t happen again. No incident report was submitted or lessons learned generated. It was just another event on a very long list of events, each of greater importance.

I slept so much better after this incident. Who wouldn’t? This incident communicated that the company didn’t really care about data breaches. I heard that message loud and clear. My job was to align with the company’s tolerance for information loss (which I discuss in depth in Chapter 5), and I got the message that nobody really cared. In light of this event, I didn’t need to carry with me the stress of an anticipated breach. From that day forward, I didn’t. I had aligned: I would build the program the company wanted.

This incident and the company’s reaction were telling for me. It provided great feedback and an understanding of the environment in which I found myself, the terrain I and my team were traversing. I learned beyond a shadow of a doubt the overall climate for risk. I could sense and feel the indifference from senior management. I understood why InfoSec was under-resourced and didn’t occupy much time on anyone’s agenda. This would bother many InfoSec types and cause them to take up the sword to fight the lack of prioritization of InfoSec or correct others’ misunderstandings. However, instead I told my team to quickly align with the overall direction, get to acceptance, and work within the culture. I had to operate within the framework of the company’s tolerance for information loss, and I did.

After the breach, I was able to revisit our policy during the next review cycle. Having the company’s response fresh in our rearview mirror, I was able to calibrate much of our policy requirements. I wrote broad statements lacking details. Each policy topic was limited to just a few lines. This brevity was intentional. For example, in the section on malware, I put the statement “All company systems must have protective software” and left it at that. No more details.

As I’ll discuss in Chapter 7, your path forward to increased security will be through staff education. Changing attitudes about InfoSec will be achieved only by educating the rank and file up through the executives. You don’t have to accept an attitude of low importance for security. If you begin to educate staff, they will move security forward on your behalf. You’ll be amazed at your results when you educate and empower system owners to take responsibility for the security of their systems. In many cases, they’ll exceed the levels of security your team would have implemented.

The Other Areas in the First Domain

Though I focused on only a few elements of the first domain, I am not recommending you ignore the other areas. What I am recommending is that you prioritize the ones I’ve highlighted and that in your early tenure you place more focus on these areas. These areas are of greater importance because they provide the foundation to your program. Your InfoSec program cannot be built without these.

The remainder of the areas in the first domain (for example, confidentiality, integrity, and availability of information; compliance requirements; and legal and regulatory issues relating to InfoSec) are all important, but they don’t require the same level of attention early in your program as the areas I’ve highlighted. As the new leader of the department, you’re being closely observed as to whether you were the correct hire. You get only one chance and limited time to get the job right, so focusing on the items that matter most is critical to your early days and success.

Domain 2: Asset Security

The Asset Security domain focuses on protection of assets (information, software, and hardware). Much of your time building out your program will be spent in this domain. This domain consists of the following subdomains:

· The classification and ownership of information and assets

· Privacy

· Retention periods

· Data security controls

· Handling requirements

The second domain is super important, but most of its work will be done by other IT and engineering teams. Only two of these subdomains rise to hit my radar as a new leader: the classification and ownership of information and assets, and data security controls. The other three subdomains, depending on the industry in which you work, will have varying degrees of importance.

Data classification can be a lot of work, with the end game being a stratified classification of information. This is necessary in the United States Department of Defense (DoD) and other government agencies. But most likely, where you work, it’s excessive. I’ve found it is most often more appropriate to take the company through a process (possibly utilizing the councils) in which the company’s most sensitive data is identified (along with its information owner) and for each piece of sensitive data, a life-cycle map is generated to show where the data resides in your systems, from creation through destruction.

For example, customer data is super sensitive because a breach of it would result in reporting requirements to your customers. This would be a bad day for the company and no doubt impact your stock price. Therefore, the information owner of customer data should know where customer data exists, from its creation through its destruction. You would also want to paint a picture of who has access to it at its various processing and storage points. The owner of customer data (VP of ecommerce) should find this exercise valuable. The win for InfoSec is that you have the information owner (VP of ecommerce) talking with you about security controls throughout the life cycle of customer data. This is a win for all!

That’s all the attention I would give to this domain except to be consulted during the decision-making process in the other areas. Of course, your team would also provide the policy guidance for the IT and engineering staff members supporting these other subdomains.

Domain 3: Security Engineering and Architecture

The Security Engineering and Architecture domain focuses on vulnerability management, use of encryption, physical security, and security designs in engineering work. Not much of your time will be spent in this domain in your early tenure. Many of these topics are best dealt with by your extended security team and technical leads. This domain consists of the following subdomains:

· Engineering processes using secure design principles

· Fundamental concepts of security models

· Security capabilities of information systems

· Assessing and mitigating vulnerabilities in systems

· Cryptography

· Designing and implementing physical security

This third domain is full of content that’s important to any security program, but it doesn’t contain topics of great concern as you start to build out your program. To begin the conversation with others in the company, I use a defense-in-depth model that’s detailed in Chapter 6.

Domain 4: Communications and Network Security

The Communications and Network Security domain focuses on securing the network infrastructure. This is an important domain, and you’ll need to spend some time on it in your first year. As in the third domain, many of these topics are best dealt with by your extended security team and technical leads. This domain consists of the following subdomains:

· Secure design principles for network architecture

· Secure network components

· Secure communication channels

Next to domain 1, this is probably the most important domain, as all your data communications will traverse over these systems, whether your infrastructure is on premises, in the cloud, or a hybrid of both. The network services team needs to be one of the IT groups you’re closely partnered with. They own so much of the infrastructure upon which the business data rides.

I like to set up a monthly recurring lunch with the network team to discuss security matters and how we work going forward. This is the largest of all domains and contains most of the sexy security technologies, like intrusion detection and prevention systems, firewalls, network scanners, software-defined wide area networks, virtual private clouds, demilitarized zones, Domain Name System, web filtering tools, and virtual sandboxes. Therefore, you’ll need to spend lots of time and energy on this domain.

You’ll want your team members to be all over these systems as well. Ironically, firewalls are discussed in this domain, but they should be also included with access controls, and mentioned in both domains 4 and 5. You and your team will be involved in all of these subdomains. All are important and can’t be ignored or handed off to others to deal with.

Domain 5: Identity and Access Management

This Identity and Access Management domain helps InfoSec professionals understand how to control the way users can access systems and data. It covers the following:

· Physical and logical access to assets

· Identification and authentication

· Integrating identity as a service and third-party identity services

· Authorization mechanisms

· The identity and access provisioning life cycle

I’ve found it best for this domain to be placed on the shoulders of the IT operations team. Your team’s major contribution and influence to this domain will be through guidance in the form of policy, and auditing of credentials. Beyond the policy requirements and auditing, your team’s part in this domain will be limited. This is assuming your company has a good identity and access management group.

The responsibility for compliance with the InfoSec policy falls on all the systems owners and data custodians. They will be the ones selecting the tools and designing the processes. Your hope is that someone from your team will be involved in this selection and design process, but this domain by and large falls on the shoulders of the administrators—and oh, what a beautiful thing that is. Because you all know that the management of end-user and system credentials can be a complicated world. Having the system administrators owning this space relieves you of much of the pain associated with managing it.

Domain 6: Security Assessment and Testing

The Security Assessment and Testing domain focuses on the design, performance, and analysis of security testing. It includes the following:

· Designing and validating assessment and test strategies

· Security control testing

· Collecting security process data

· Test outputs

· Internal and third-party security audits

This domain is once again important to you and your team. All the system audits and testing will be done by your team. You want to maintain good working relationships, so be careful how you go about testing and how you handle and report the findings.

I’ve found that every audit/pentest I conduct should be preceded by a letter of engagement that clearly explains the intent of the audit or assessment. This letter must clearly state the goals and objectives of the audit, the anticipated timeline, and who will receive the final report. The letter should be reviewed by the legal department, the system owner, and their manager. This gets everyone onto the same page before the assessment starts.

It is important that as the findings come in, the system owners are the first to know about them, and not the management of the system owner. This gives the system owner time to fix the findings, so hopefully at the project’s close you can report that all findings were addressed by the system administrator.

Domain 7: Security Operations

The Security Operations domain focuses on security operations and is where most of your monitoring of the infrastructure takes place. Therefore, it is an important domain, and you’ll need to spend some time on it in your first year. As in domain 3, many of these topics are best dealt with by your extended security team and technical leads. This domain consists of the following subdomains:

· Understanding and supporting investigations

· Requirements for investigation types

· Logging and monitoring activities

· Securing the provision of resources

· Foundational security operations concepts

· Applying resource protection techniques

· Incident management

· Disaster recovery

· Managing physical security

· Business continuity

This domain is another important area, and one that will require quite a bit of your time and energy. Most items on this list require partnerships to complete. In your first year, I suggest you spend most of your efforts on investigations, logging and monitoring, establishing some security operations presence, and incident response. The other areas, although important, can be handed off to other teams and require only limited involvement from your team.

Of all the activities your InfoSec team members will perform, none is more important than the work they’ll do supporting the legal department on staff investigations. Of all the subareas within the eight domains, this one needs to be solid, and it needs to be owned by your department entirely. No one else should play in this space with you. Staff investigations are the sole responsibility of the InfoSec team, and no one else.

I always assign one of our best team members to investigations, especially when building the investigation from scratch. This requires an engineer with attention to detail and good people skills, because of the amount of interaction with investigators and corporate attorneys. It will take a unique individual to build this program. To develop the documentation, you’ll need to establish a repeatable and defensible process that will hold up in a court of law. I don’t recommend you outsource this area, as owning this area will be a lifeline to you and your team when times get tough.

If you’re building a forensic capability from the ground up, send one of your team members to a SANS course to get the bible on forensic investigations and to build out this capability. There’s a lot to it. If you have an unlimited budget, you can get outside consulting help. Some firms have nailed the forensic process and can help you kick-start this area. I recommend you don’t keep them around, though, as you want this competency solely owned by your team.

Next to supporting the legal department with forensic investigations, incident response (IR) is another area that you and your team will want to own entirely. The IR process is super important because of the amount of visibility your team gets when the company experiences an incident. Every time an incident occurs, the spotlight will be on your team, so if you don’t have seasoned incident leaders and responders, plan to send a couple of your team members to a SANS course for incident response. It will be money well spent.

Your team’s role in IR will be limited to one of providing leadership (incident commander), analysis of logs, and communications. You will have to be closely partnered with the infrastructure team leads and engineering teams, as they have the right of eminent domain over their systems. Your team will most likely never touch their systems, but the system owners 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 perform the log analysis for conflict-of-interest reasons.

Monitoring of systems is another area of focus for you. If your goal is to collect telemetry from all systems to support monitoring, you’ll need all the system owners and developers to send logs to a central logging service. Good luck with this. This can take several years to fully achieve unless the chief information officer (CIO) is a supporter of security and directs teams to make it a priority. I’ve found that this is a slow road, and to maintain good working relationships, your monitoring program often functions far from its ideal state for several years.

Domain 8: Software Development Security

The Software Development Security domain helps security professionals understand, apply, and enforce software security. It covers the following:

· Security in the software development life cycle (SDLC)

· Security controls in development environments

· The effectiveness of software security

· Secure coding guidelines and standards

This is an important area, because most of our companies are developing software for mobile apps, cloud services, and websites. Depending on the type of business your company is in, you may develop mobile applications, ecommerce websites, cloud services, APIs, desktop software, and IoT/firmware, and you may use open source software and scripting languages to integrate systems. You will want to spend a lot of time on this domain, and have dedicated software security engineers partnered with and integrated into the development processes. Unless the leader of the software teams is a security-minded individual, this area takes much patience and many laps around the track to secure.

It can take much longer than it should to get static and dynamic testing tools integrated into the continuous integration/continuous development (CI/CD) process and have outputs being actioned by the software engineers. This is typically a tough group of people to work with, as they have unique computing needs and often view themselves as security experts in high regard.

Vulnerability and patch management is also an area of great importance. Keeping software up-to-date is one of your top concerns. Operating systems (OSs) used to be at the center of security vulnerability discussions, as we looked to the companies that made the OS patches. In recent years, vulnerability management has largely shifted to the application development space and producing secure code. It’s through the SDLC or CI/CD process that InfoSec requirements are inserted and vulnerabilities are addressed. After development, my team and I have had lots of success utilizing a bug bounty program to get feedback from industry researchers who discover vulnerabilities in our software missed through the CI/CD process.

Some companies require that all new systems be certified by the InfoSec department prior to being placed into production. Theoretically, this is a great idea, but it’s not agile, and updates to production code are being pushed out continually, so it doesn’t make sense. The best approach is to offer the developers technical training relating to secure coding practices. I love this approach, and set aside budget to provide technical training to the engineering departments. This is another win-win. They love the courses, and we, in essence, extende our InfoSec team to those who receive the training.

Conclusion

As an InfoSec leader, you must know all eight domains. They are the science of our profession—the left brain, if you will, of our work. Mastering them will teach you all you need to know about the technical details of your job. However, knowing the eight domains will not provide you a road map of how to implement them or make them effective. This “how” side is what I like to refer to as the art of InfoSec, or the last domain.

No one discusses this last domain of our work. I believe that underappreciation of this last domain is the greatest contributor to many CISO short-lived tenures. If a CISO gets into trouble, it’s usually because they were unable to navigate the many nuances of the work, as the dividing line between responsibilities among teams for security is often very blurry. Or they neglect relationships and don’t get the broader support of the internal community often necessary to move initiatives forward.

To be effective as a cybersecurity professional, you need to understand the art of our profession. This last domain is laid out in seven simple steps in the remainder of this book. These steps have been developed from the many hard lessons I’ve learned over my 25 years in InfoSec. I’ve witnessed each step validated time and time again by those I’ve worked with.

The next chapter provides an overview of the steps. Chapters 4 through 10 then cover each of the seven steps in more detail and lay out in simple terms the road map to building a successful and sustainable InfoSec program that will allow you to enjoy a tenure beyond two years.

1 The eight domains were developed by the International Information System Security Certification Consortium, or (ISC)². For more details, see “The 8 CISSP Domains Explained” by Luke Irwin at the IT Governance UK Blog.