CHAPTER 2

First 90 Days on the Job

Establish Trust and Credibility with Peers and Key Stakeholders

Whether you were promoted into the CISO or IT risk management leader role or you are new to the organization in this position, establishing trust and credibility with your peers and key stakeholders is critical.

Your first act after the new-hire orientation should be to identify your peers and key stakeholders and meet with them individually. Some key stakeholders may not warrant an ongoing meeting schedule (like the CEO or governing body members), but your IT peers and key stakeholders at your level (likely the compliance or internal audit leaders) should be on your calendar for monthly one-on-one meetings. You can keep these to 30-minute meetings and, of course, cancel if there is nothing new to discuss, but these connection points create a steady cadence and audience for you to learn about your program’s effectiveness. It also affords you the opportunity to float ideas and hear what they are working on and how your team might support their efforts.

You may find you can create synergies and goodwill with mutual stakeholders if you team up with these peers to achieve similar goals and objectives. As an example, in one position, I recognized that our vice president of internal audit conducted an annual series of interviews with senior leaders across the organization. The purpose of the meetings was to gather input for the following year’s audit and assessment plan. Knowing that I needed to gather information on IT risk for my first annual enterprise IT risk assessment, I asked if I could team up with her, attend these meetings, and ask a few high-level IT risk questions. I sweetened the pot by volunteering to modernize her interview questionnaire by making it much more visually appealing and easier to follow. She took me up on this offer and we “killed two birds with one stone.” Leaders we interviewed were thrilled that we condensed two meetings into one, that we both brought new information to the meeting, and that we had streamlined the interview materials. What did I get in return? I got my high-level IT risk assessment questions answered, I accumulated many ideas to help enable the business from my team’s efforts, and last but certainly not least, I got to meet a lot of leaders I normally wouldn’t meet outside of such an exercise.

Aside from the partnership benefits you will receive, it will be vital for you to consistently demonstrate to your peers and key stakeholders that you are addressing (or at least thinking about) their IT risk and security concerns. This is how you earn trust and credibility.

This next part applies to everything you do in life but is certainly relevant in your new leadership role. Do what you say you are going to, do it timely, and do it well? Nothing, again, nothing diminishes your credibility faster than failing to deliver on your commitments. It will be important to jump on that low-hanging fruit, fix people’s pain points, and deliver on your promises early. Remember the phrase, “First impressions are lasting impressions?” So true in this arena. What you do in your first 90 days to pull thorns out of people’s sides, show you care about using your program to help them be successful, and be a good team mate will set the tone for your career in the role.

Do something “excellent” for your peers and key stakeholders. I wish to relate another anecdote: I was meeting with a senior business leader during my first 90 days on the job as CISO and he expressed extreme pain and frustration with our faxing policy. It became evident that someone in IT had told him (years prior, of course) that faxing sensitive information was the only acceptable means of transmission for hard copy forms. This was contrary to the desired mode of transmission, which was scanning and e-mailing or using an electronic faxing application. The leader further explained that he had multiple employees spending all their time using the antiquated fax process and that morale and productivity were low. I volunteered to investigate the decision and see if I could “pull out that thorn.” It took me less than a week to review the decision history, collaborate with our compliance and IT operations departments, and return with a solution that completely met their needs. I made a friend and earned trust and credibility with this business unit with little effort on my part.

Investments of your time to build these relationships, personally, will pay dividends beyond what you can comprehend in the short term. Earning trust and credibility with peers and key stakeholders is crucial in your first 90 days. Do it!

Prior Assessment/Audit Report Review

If you are very lucky, you may come into a role where a newly delivered program assessment was provided to management. One of my recent CISO roles, and my director’s role, was created based on management responding to a third-party IT risk and security program assessment. The assessment specifically identified a lack of seasoned program leadership and a current program maturity level of 1.8 out of 5.

In addition to the leadership gap, the report identified several areas of immaturity and risk. The program was lacking formal risk assessment capability, incident response process and documentation, training and awareness coverage, and certain technical safeguards that peers had already implemented. The assessment was conducted by a reputable, large consulting firm, so I took the results at face value.

To complement the assessment report I inherited, I asked the internal audit department for a summary of findings from the past two years of IT audits. This objective window into the performance of the IT organization and security team was valuable in understanding what gaps existed from their perspective and where we stood in terms of management action plans to address the issues. For example, these reports confirmed for me what I had already suspected: inventory and management of clinical/biomedical devices were very immature, and management was struggling with a solution to mitigate the risk this situation presented. Good to know information when you are new in the role! You may find, as I did, that you are inheriting several audit findings with near-term expectations on remediation—also good information to know early in your role. You will want to make friends with your internal audit team and view them as a strategic partner to advance your program’s goals. To do this, make sure you put addressing their audit findings at the top of your list. You won’t want to appear on a list to senior management or to the governing body as the leader who is delinquent on their management action plan.

Conduct/Refresh Program Gap Analysis

You have come into your new role and have reviewed the existing program assessment (if there is one). You have also perused a summary of internal audit findings related to IT and/or security. You now have a historical perspective on what others think about your program. Within your first 90 days, you should either conduct your own assessment (if one doesn’t exist) or refresh the assessment based on your knowledge and experience.

Conducting or refreshing the program gap analysis achieves multiple objectives. First, it lets your boss and peers know you are knowledgeable in your field and are looking to bring your own insights into the areas where the program can improve. Second, it is a valuable mechanism to learn about the existing IT and security architecture, organization, strengths, and weaknesses. Lastly, your assessment—combined with previous assessments and audits—will form the basis for your program business case and three-year plan.

If you have never conducted your own program gap assessment, do not fear! This chapter contains all the relevant information that you can use to evaluate, along with a few examples and templates you can use to communicate your results. Once you have done a few of these, you will become a pro and have more than enough artifacts to conduct these efficiently. Warning: Don’t rush to hire a consultancy to do this work on your behalf. Part of the reason you are conducting the assessment is to learn the environment yourself and demonstrate you have opinions on what areas to focus. Your peers do not want to engage with your consultants; they want to engage with you directly. Recall the previous advice on building and maintaining peer relationships. This activity is part of that process.

All that said, if you have assumed the leadership of a team, you should certainly engage them in the process as they likely have much of the historical information you need. For example, has someone tried a solution in the past and failed? Why? This intellectual property is something you should tap into early in the assessment. You will look foolish if you propose a risk mitigation strategy in your plan only to learn it knowingly isn’t feasible based on your unique IT architecture.

Let’s get started. How do you organize your assessment? I like to keep things simple, as any good business-minded CISO would. Organize into People, Process, and Technology components. These are categories to which the CIO and other senior leaders can relate and easily understand.

People

No matter how much technology advances or how many security tools you have, you will need highly skilled and intelligent people to help you manage your program. In fact, the continued acquisition of technology often begets the need for more people to manage it. You will want to carefully balance your recommendations around hiring, cosourcing, outsourcing, and automation.

I have been a witness to IT colleagues who have made the critical mistake of creating an organizational chart, hiring lots of people, and then trying to figure out what those people are going to do or how to keep them busy. This practice is not good for them and makes you look like an “empire builder.” The business-minded CISO thinks like a businessperson by making decisions about spending money and hiring employees as if it were his or her own money. Hire when a need absolutely exists and only when it is more cost-effective to bring on an employee versus a consultant or managed service provider. You will score significant points with your boss and other senior leaders by achieving more with less and running a lean shop than touting how large your organization has become and how many employees report to you.

The following explains how to conduct the People assessment.

Since organizations are all somewhat unique in terms of size, industry, culture, and focus of the IT risk and information security program, you will need to understand what is expected from your team. Quick example: In some organizations, the IT risk and information security department handles all aspects of the program, which means they perform security operations functions (provisioning, deprovisioning of access), incident management and response, IT risk assessments, training and awareness, firewall and endpoint management, and so on. Conversely, some programs have a narrower focus with other IT operational teams managing network and security help desk functions. You need to ascertain what role your team plays in all of this today and what the expectations of your team are going forward. It could be that other teams have been covering for yours and want to hand things back. In other instances, you may determine that you are covering a function that does not belong in your group.

You should inventory the current and desired functions in a service catalog. I have used Microsoft Excel or SharePoint in the past, but any tool that will help you list and document these will work. Beside each function or offering, you should list who on your existing team is responsible, how many hours a week it requires, intervals, and other vital statistics. Figure 2.1 is a screenshot of an example from SharePoint.

Figure 2.1 Sample service offering inventory

Note that the service owner in this example is blocked to protect their privacy, but all other information is actual databased on an intrusion detection system (IDS) alert function performed by a security operations team. The hours per week metric is listed as 10.0 under the effort column. This data point is the most crucial to capture because once you have your current and desired service catalog completed, you can perform a simple division equation to quantitatively and objectively communicate your staffing needs. Here’s how it works.

Let’s say for simplicity that your team currently has 10 functions or services that are performed on behalf of the organization.

Function/Service	Weekly Effort
1. IDS alert monitoring	20 hours
2. Incident management	10 hours
3. Enterprise risk assessment	10 hours
4. Help desk tickets	14 hours
5. Policy review/revision	1 hour
6. Audit responses/remediation	10 hours
7. Training and awareness	20 hours
8. Vulnerability scanning	15 hours
9. IT risk advisory/consultation	30 hours
10. Data loss prevention	10 hours
Total Hours Weekly	140 hours

Equation: 140 hours/40 hours in a work week = 3.5 FTEs

This is a model for a small company with a simple IT environment. Certainly, a large bank or health care organization would have many more functions, hours of effort, and FTEs associated with the program.

Now let’s say you currently have two FTEs on your team. You are currently operating at a 1.5 FTE deficit and unless you have a 0.5 person laying around, you have a 2.0 FTE deficit. In this situation, you could make the argument that you either need to hire two FTEs or find a service provider to take on some of the functions/services you are expected to perform. This is the beginning of your business case analysis.

That was a current state analysis. What if during your function/service catalog inventory effort you are asked or expected to take on five additional functions? You are asked to add:

Your future state equation now looks like:

140 current + 234 future = 374 weekly hours/40 hours a week = 9.35 FTEs

This is where the fun starts! You will be happy to take on these additional responsibilities, but you are not going to be able to handle it with your existing two FTEs. When you speak with your boss and governing body, this analysis (along with alternatives) will be your vehicle for a meaningful discussion. You may ask and receive the additional FTEs, especially if your team is newly formed or being formed around you. Alternatively, you may ask your senior stakeholders what functions or services you should remove to meet your FTE future state allotment. Lastly, you may be able to outsource some of these functions and achieve them without having to hire additional employees.

Function/Service	Weekly Effort
Business continuity planning	20 hours
Identity and access management	80 hours
Regulatory reporting	4 hours
Human resources investigations	10 hours
IT compliance	120 hours
These additional functions add:	234 hours

I caution you not take on a significant amount of additional functions or responsibilities on behalf of the organization if you are not provided the people to achieve the desired outcomes. This is not the time to try and be a hero. You should be courageous enough to convey the need to your leadership and/or work with them to arrive at a compromise where you have the right number of resources to be successful.

The numerical equation above is just part of the People evaluation.

Often in management you are fortunate to work with what I describe as “athletes.” Athletes are employees that can do almost anything, have a passion for learning, require almost no oversight, are self-motivated, and overall make your life easy. Within your first week of taking on the IT risk leader or CISO role, you should meet individually with your team members and begin to ascertain whether you have any athletes. Athletes can sometimes do the work of two or three FTEs. Conversely, poorly performing employees sometimes do the work of 0.25 employees. You need to evaluate your existing team to finalize the number of team members you will ultimately need to deliver on program expectations.

Obviously, you would like to have a small team of athletes and no poor performers, but you will rarely be that fortunate. You should attempt to “coach up” your poor performers and support and encourage your athletes. Ultimately, you may have to make do with the staff you inherit, but hire slowly, one at a time, and build an athletic team around you.

Lastly, you may have the right number and skill sets on the team you have, but are they in the right reporting structure, have the right job titles, being compensated appropriately? This is your chance to make a big difference to your team internally—and on your way into the job. In one new CISO role, I immediately restructured the reporting relationships to divide the team among my directors and I so that we could give more personal attention to each of the team members and focus them on specific functions. I also reclassified several of their roles and was successful in getting them pay raises. While no one outside of our team knew or cared about these changes, it meant a lot to our team and I was able to earn some quick respect points with them.

Process

The best way to build and maintain a sustainable IT risk and information security program is to ensure you have documented and practiced processes. According to Merriam-Webster’s Online Dictionary, a process is defined as “a series of actions or operations conducing to an end.” In the IT risk and information security world, having standardized, documented, trained, and practiced processes is critical to managing a mature program that can respond as expected in a crisis and produce a desired result.

A process is something that someone on your team or some piece of technology is operating or executing for you to achieve a desired outcome. “Security alert and event management” is a process on most security operations teams. This process is usually managed by people on your team using various bits of technology. What you will likely find in your first 90 days is that this process, and many others, may be happening but won’t be clearly documented and your staff may or may not be trained appropriately.

Below is a sample list of processes you should assess.

• Enterprise IT risk assessment and management
• Security alert and event monitoring
• Security incident response and recovery
• Threat and vulnerability management
• Identity and access management
• Data loss prevention
• IT vendor risk assessment
• Training and awareness
• Policy and procedure development/revision
• IT risk and security governance

The following is a brief description of each of these processes, as well as the key assessment points associated with each.

Enterprise IT Risk Assessment and Management

Whether you know it or admit it, you are in the risk management business. The most important and meaningful process you need to assess is how you conduct IT risk assessments and manage IT risk on an ongoing basis. The risk assessment should gather inputs from various sources across the enterprise. The National Institute of Standards and Technology (NIST) Special Publication 800-30 is a useful guide for crafting your risk assessment approach and assuring others you didn’t just make up an approach on your own. The guide can be accessed online at http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf

Whether or not you use NIST as a reference, you should tailor your approach to fit your industry and organization. In the health care industry, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule requires periodic risk assessments of the protected health information (PHI) environment. For many in this industry, HIPAA regulatory and meaningful use attestation requirements must be baked into the risk assessment and risk management efforts of the team.

The risk assessment report should drive the risk management activities of the organization. With financial, technological, and human resources limited in most organizations, you will have to design and operate your program based on risk. Most organizations have enough critical or high-risk findings to keep them busy, so using the risk assessment process to identify these is paramount. To manage IT risks on an ongoing basis, many are turning to electronic governance, risk, and compliance (eGRC) platforms to assist in the tracking and monitoring of risks in a register-type format.

Key assessment points:

• Do you conduct periodic IT risk assessments?
• Do the risk assessment inputs include incident reports, interviews, internal audit reports, vulnerability scan results, and other inputs that provide a lens into IT risks enterprise wide?
• Does your risk assessment framework consider specific regulatory or business process requirements (e.g., Payment Card Industry Data Security Standard (PCI DSS))?
• Do the risks identified have meaningful risk mitigation plans associated?
• Do the critical risks identified have owners who are accountable for the risk mitigation plans?
• Do you have an eGRC platform to help you automate the IT risk management functions?

Security Alert and Event Monitoring

One of the key functions of the security operations team is designing alert features in your environment and monitoring for security events that trigger them. Security tools should be configured on endpoints, internal network, and perimeter devices to alert when certain actions occur or thresholds are met. For example, if you only operate in the United States, you could have an alert or rule configured to send an e-mail to your analysts when someone logs into your network from a foreign country. Your security alert and event monitoring process should establish the design of these alerts and correlation rules, establish a method for ranking their severity and priority, and identify the follow-up actions analysts need to take as a result.

Key assessment points:

• Do you have an existing and documented security alert and event monitoring process?
• Does it include roles, responsibilities, process flows, and desired outcomes?
• Has the process been tested in a table-top exercise or is it routinely practiced during security operations team meetings?
• Is the process documentation revised based on the test results and any technology changes?
• If this function/process is outsourced to a third party, how are you kept informed on their ability to monitor for your alerts and events?

Security Incident Response and Recovery

The security incident response and recovery process is subsequent to the process described above. It is considered a separate process because often alerts and events do not rise to the level of requiring the invocation of a response and recovery action. If an event alert does present a significant concern, this security incident response and recovery process will be the most important one you manage. This process identifies and documents the specific roles and actions that security operations and other IT operational teams should take during this critical time. Unlike an IT event where the goal is to restore systems as quickly as possible from an outage, a security incident response and recovery process may dictate that you preserve certain system memory (forensic images), disconnect systems, or disconnect from the Internet completely. The design of your response and recovery program should include taking advantage of your network segmentation strategy (if you have one), quarantining certain hosts or subnets, preserving forensic data and images, and restoring from backup media.

Response may include the invocation of an emergency response retainer, engagement with law enforcement, or participation by key vendors. Recovery may require the participation of key vendors or consultants to rebuild damaged systems and/or repair critical data sets.

Key assessment points:

• Do you have an existing and documented security incident response and recovery process?
• Does it include roles, responsibilities, process flows, and desired outcomes?
• Has the process been tested as a table-top exercise or is it routinely practiced during security operations team meetings (in coordination with the security alert and event monitoring process)?
• Is the process documentation revised based on test results, real events, and any technology changes?
• If this function/process is outsourced to a third party, how are you kept informed about their ability to respond and recover your critical systems and data stores?

Threat and Vulnerability Management

Threat and vulnerability management are extremely important functions your team should be performing every day and in real time. Understanding the likely threat vectors for attack in your industry and your company will help you design the right proactive and detective safeguards. You cannot protect everything all the time, so having a sound process to identify and evaluate threats—as well as conduct regular vulnerability management activities—is critical to a risk-based program.

The Federal Bureau of Investigation (FBI), the Department of Justice (DOJ), and National Information Sharing and Analysis Centers (ISACs) are among the organizations that are partnering with private companies to share threat intelligence. In addition to these organizations, many next-generation security tools come with Open Threat Exchange (OTX) or fee-based threat intelligence capabilities. In some cases, leveraging an MSSP makes a lot of sense considering having threat intelligence or malicious software (“malware”) researchers on staff is not feasible for many organizations. Ask yourself: Will your team really know about the next zero-day attack from Eastern Europe before a large MSSP who specializes in this work around the clock?

Vulnerability management can be achieved by ensuring you have a process in place to regularly scan your network and devices—both as they are provisioned to the environment and once attached. There are many tools and service providers in the market for vulnerability scanning—just ensure the reports they produce are actionable and risk-based. Simply having vulnerability scan results with 10,000 lines of vulnerabilities is neither meaningful nor actionable.

Key assessment points:

• Are the likely threat vectors for your industry and company known?
• How are indicators of compromise (IOCs) identified in your network?
• Are security events logged and monitored? Are events to be logged clearly identified?
• How are threats identified, triaged, and mitigated?
• How are patches managed? Do you have specific thresholds for critical versus important security patches?
• What steps are taken to protect systems against malware? Are the scope of systems and scope of malware clearly defined and updated?

Identity and Access Management

The identity and access management (IAM) process at your company is an important component to the overall protection of your network infrastructure and sensitive data. This is especially true for privileged or “super users” in your environment. The IAM process governs how access is provisioned, modified, terminated, and escalated.

A good process balances the need for security with the ease of use and functionality available to your user community. Depending on your industry, you may have greater success with tighter controls in this space, or you may have to live with leaning more toward the “ease of use” side of the continuum. For example, in the health care industry, adding clicks or steps to the login process can be difficult to implement in a clinical setting. Health care professionals are pressed for time and focused on providing care and charting. Asking them to use military-grade logins will not make you popular with this group of stakeholders. You could potentially be a hero, though, by designing and implementing secure single sign on (SSO), proximity badge sign on/off, or biometric sign on. These solutions are not only secure but make logging on and off easier.

Privileged users, such as database administrators, have access to large caches of data and typically move this data around for testing, reporting, and other valid business reasons. Strictly managing their identity and access rights is a must if you are to protect your company’s most valuable information assets. Network administrators usually try and have shared credentials to administer network appliances, firewalls, and so on. Don’t allow this practice. Look to implement a privileged access solution or password vault solution to manage, monitor, and audit these accounts.

Key assessment points:

• Do you have a policy and procedure for granting, modifying, and revoking access for applications and supporting infrastructure for all users in your environment?
• Does the policy and procedure identify privileged accounts and special management practices for them?
• Does your IAM strategy consider SSO or federated access models for various stakeholder groups? For example, you may want customers or frontline staff to have streamlined sign on and application-to-application pass through of credentials to provide for a more efficient user experience.

Data Loss Prevention

Data loss prevention (DLP) is simply the practice of using people, processes, and technology to prevent sensitive data from being accessed internally or externally by unauthorized parties. If you are fortunate to have a data classification scheme, it is simple to apply DLP tools based on classification. For example, what your organization classifies as “secret” information may be blocked completely from transmission outside of the corporate network. DLP tools can scan endpoint devices, e-mail messages, and other repositories—as well as web traffic—and take actions based on predefined rule sets.

If you do not have an enterprise wide data classification scheme (many do not), one of your key assessment activities should be to understand what types of data you have in your environment, and where your most sensitive information is stored/transmitted. Certain business units may have a legitimate business reason to share sensitive information with others in the organization or external partners who are part of your operations. Without a clear data classification strategy, you will need to identify these business units and work with their management to apply DLP controls so that a balance between functionality and security can be achieved.

Key assessment points:

• Does your organization have a data classification scheme?
• Do you have a data protection policy that considers data at rest, data in transit, and data on endpoint?
• Do you have a DLP strategy, including the use of DLP tools that proactively act on policy violations?
• Are you addressing all sensitive data storage and transmission media in your organization (e.g., personal cloud storage uploads, use of personal e-mail and webmail accounts, unsecure electronic data interchange (EDI) such as file transfer protocols (FTPs), etc.)?

IT Vendor Risk Assessment

IT vendors have, over time, come to represent a large proportion of organizational vendors overall. Very few business projects are devoid of any IT impact. Everything runs on information systems, and IT vendors are important partners in achieving organizational goals and objectives.

Partnering with IT vendors can be both a strategic advantage and an administrative nightmare. You need them to deliver IT functions, but they introduce risk and complexity that you would not normally have in working with a solely in-house IT team. To determine the level of risk an IT vendor is introducing, and to determine whether the benefit outweighs the risk, you should have a standard IT vendor risk assessment process. This process should be initiated early in the procurement process so that vendor selections can be guided by the results of your assessment. Often, I have seen the IT vendor risk assessment conducted after the vendor has been selected and contracted, or even a week before a deliverable from them is due. This late engagement renders the risk assessment process moot.

You should make sure you have a standard assessment criteria checklist that evaluates the vendor’s compatibility with your IT environment, their information security safeguards and controls, their service level agreements (SLAs), regulatory and compliance adherence, and other factors to help facilitate a smooth integration into your environment. Make sure the IT risk assessment facts and decisions are well documented so they can be referenced later.

Key assessment points:

• Are existing IT vendors inventoried? Are current and legal department-approved contracts in place with existing IT vendors (e.g., SLAs, Business Associate Agreements (BAAs), Non-Disclosure Agreements (NDAs))?
• Are new IT vendors subject to a review process by various teams within IT?
• Is there a recurring, standing technology review committee that follows a standard checklist or procedure for risk assessing new IT vendors?
• Are enterprise wide procurement functions educated on the technology review committee process and required to consider the committee’s review prior to a purchase decision?

Training and Awareness

No matter how much process improvement you make or fancy technology you implement, maintaining a secure and relatively low-risk environment requires assistance from your people and user community. Phishing e-mails are a perfect example. All the web filters in the world will not prevent some malicious e-mails from reaching your user community. One phishing campaign my team initiated to gather the company’s baseline statistics resulted in a 36 percent click rate on simulated phishing e-mails that were sent.

The only way to reduce this surprising fail rate is to increase training and awareness activities on the subject. Beyond phishing, there are many other topics for which technology users need regular training and awareness. Think about physical security, protection of mobile devices, safe password management practices, and acceptable use of social media. You must strike a balance between information risk and security training and awareness activities. If you are too much in the user community, they begin to tune out. Not enough, and they forget. I have always found a quarterly training schedule to be about the right balance.

The first activity of your training and awareness program should be to assess where you have the highest risks or concerns and build out a training and awareness campaign schedule to address those areas first. Be creative. I have been using 30-and 60-second videos to deliver key messages, interesting posters in break rooms and common areas, quizzes and blogs on our intranet site, and so on. If you build interesting content and make it available to everyone on a useful intranet page, you will see success in the campaigns you produce.

Key assessment points:

• Do you have a training and awareness program beyond annual mandatory compliance training?
• Have you assessed your organization’s weakest security knowledge areas and built a campaign schedule to address them?
• Are you creating interesting content tailored to your various organizational audiences? Training for bank tellers might be very different than training for banking application developers.
• Do you have an intranet site where content, news, and other information security learning material can be accessed by the workforce?
• Do you have metrics defined to evaluate the effectiveness of your training and awareness program?

Policy and Procedure Development and Maintenance

While not the most exciting security topic to discuss, policies and procedures are the foundation on which we communicate expectations of behavior to users. Most information security policies and procedures are rooted either in legal or regulatory requirements, industry standards, or leading practices. It is almost always the first place an assessment or audit of your program will focus, followed by how well your organization complies with them.

Policies should be short, easy to understand, and reviewed regularly. No one will read or try and understand a 70-page information security policy. My favorite approach for policies and procedures is to create short, specific documents on granular topics such as remote access, acceptable use of IT systems, and so on. If you can keep the policies to just a few pages, people can access and read those they have questions about quickly rather than paging through a novel.

Make sure your policies are on your intranet site where they can be easily located and reviewed. I cannot express how many times I have consulted at a company that thinks the world of their information security policies and procedures; yet when I inquire of everyday users, they have neither seen the policies nor do they know where to turn if they have a question.

Key assessment points:

• Do you have information security policies and procedures?
• When is the last time they were revised? Policies that are more than one to two years old are likely outdated or have sections that are no longer applicable due to technology and business changes.
• Are your policy and procedure documents short and easy to comprehend by the average end user?
• Are your policies and procedures stored on your intranet where users can easily access them?

IT Risk and Security Governance

While not a process per se, you should evaluate how IT risk and security decisions are discussed and supported across the organization. I’m not talking about day-to-day decision making, but the big decisions that impact broad sets of stakeholders. For example, if you are terminating access to personal cloud storage at your company, you better have had a broad discussion with stakeholders to determine both the impact and acceptance of such a decision.

As discussed in the opening chapter, I find having a dedicated committee for IT risk and information security governance to be extremely valuable. Membership should represent a broad cross-section of your organization and be made up of experienced leaders who can truly speak on behalf of their business units. This governance team will provide you with invaluable feedback on any significant IT risk and security proposal, as well as be your advocate/evangelist for the work out in the field. Treat these folks right and they will support you; leave them in the dark, and they will fight you every step of the way.

Key assessment points:

• Do you have at least one governance team that provides feedback and direction for your program?
• Do they meet frequently enough to support you in driving key initiatives?
• Is the membership composed of the right breadth and leadership level to help you make key decisions quickly?
• What is your value proposition to them? Do you keep them informed on key plans, proposals, and performance metrics?

Technology

IT risk management and information security technologies are a critical component of your program. That said, don’t fall for allure of “it does everything” or “a single pane of glass” sales pitches that the thousands of vendors in this space are spouting. Undoubtedly, the next-generation technology available to us as practitioners is helping to automate parts of IT risk management and security operations, but you must guard against purchasing “shelf ware” or multiple point solutions from which you will only utilize partial functionality.

One approach to assessing your technology capabilities is to use the Lockheed Martin Cyber Kill Chain® Framework as a mapping tool, which can be found online at https://lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html

The Cyber Kill Chain framework is part of the Intelligence Driven Defense® model for the identification and prevention of cyber intrusions activity. The model identifies what the adversaries must complete in order to achieve their objective. Stopping adversaries at any stage breaks the chain of attack, ideally at the earliest stage possible. Adversaries must completely progress through all phases for success; this puts the odds in our favor as we only need to block them at any given one for success.

The kill chain model is designed in seven steps:

• Defender’s goal: understand the aggressor’s actions.
• Understanding is intelligence.
• Intruder succeeds if, and only if, they can proceed through steps 1–6 and reach the final stage of the Cyber Kill Chain.

Figure 2.2 shows an example of how to graphically represent current technology capabilities to desired technology capabilities. Note that the mapping is vendor agnostic; the focus is on what you want the technology to be able to do for you. I have found this method of visually depicting current versus desired technology capability to be impactful. You could also use a separate map to illustrate when you would be able to implement this technology—more on this later when we discuss your business case and three-year plan.

Figure 2.2 Sample current technology capabilities versus desired technology capabilities

Source: https://lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html

Building this map will take a little time during your assessment. Likely, your team will not even own or operate some of these technologies, so you will need to get out and speak with the network, infrastructure, application, and web services teams to determine where these technology capabilities exist. That said, try not to get caught up in who owns what. As the new IT risk management or CISO leader, it is far more important to build relationships with these teams than to attempt a “land grab” in your early days in the role. Over time, it may make sense for some of these technologies to be managed by your team, but it is far safer to let the existing teams continue managing them while you are assessing your own program and team’s skills.

There is a compelling argument that it is far better to be a consumer of data from these various sources (into your log aggregator or SIEM solution) than to administer and operate each of these solutions yourself. In other words, don’t look a gift horse in the mouth. If someone or some other group is willing to administer these for you, you may benefit from that structure by being able to deploy your team to more strategic, risk management, and security operations-type functions.

Architecture

As part of your technology assessment, you should spend some time with your network and/or security architects. Certain security technology solutions may have been purchased and installed due to the unique way your network is architected. Similarly, your unique network architecture may limit your ability to implement certain security technologies. You should understand these earlier decisions and future limitations as part of your assessment and technology mapping.

As an example, retail organizations typically have a significantly decentralized network architecture. They may have thousands of point-of-sale locations that require network architecture and security technologies to similarly operate while decentralized. On the other side of the coin, a single hospital provider organization may have one Internet connection and a data center in the basement. Understanding the existing architecture and architecture plans for the next few years will play a major role in your decisions around security technology.

Lastly, you may be inheriting technology that you wish you weren’t. I once started a role where the infrastructure team entered into a five-year contract with an endpoint security vendor that I was forced to live with for four and a half years. The cost and effort to “rip and replace” this solution was certainly not worth getting my preferred technology in place, but this earlier decision severely limited the security technology solution I could attempt on endpoint. I shifted to network-and perimeter-based security technology evaluations where I have the flexibility to rationalize and replace technologies that had expiring licenses or where existing solutions did not exist.

Pricing, Vendor Evaluations, and Proof of Concepts

You are the most popular person in your company now! You will be invited to as many happy hours, fancy dinners, and sporting events as you can possibly handle. Security vendors have grown exponentially over the past five years. If you recall what the vendor exhibition hall looked like at the RSA conference back then compared to now, you know what I mean. While I don’t have the statistics to prove it, it certainly feels like most startups are in the security technology space or have a significant security component embedded as a selling feature.

First and foremost, realize you are in a strong bargaining position. Security technologies—particularly startup vendors—have tremendous flexibility in how much they can charge for their licenses, appliances, and/or services. Be a strong negotiator. Certainly, don’t pay list price. If you work for a nonprofit or academic institution, ask for reduced pricing based on your tax status. If your company is willing to let the vendor use you as a reference client publicly or use your logo on their website or marketing slicks, often the vendor will cut you a break on pricing as well. Every time—yes, every time—I have rejected a vendor’s first quote for their technology, they have chased me down with a significantly lower price. You must drive hard bargains since every dollar you spend with a vendor is budget you won’t have for process improvement or human resources.

Vendor evaluations are always an interesting exercise. Your first question to a security tool vendor should be, “What existing security capabilities do you replace, combine, or enhance?” If they can’t give you a convincing answer, you might choose to move on from them quickly. Most vendors can perform similar security functions in their space, but are they better at it than their competitors? This is where proof of concepts (POCs) come in.

A POC is a great way to understand how well the security technology meshes with your infrastructure, as well as how well it performs against peers. If you are evaluating malware sandboxing solutions, try to plug them in at the same time and see how they perform concurrently. I did this exact POC and found that one technology vendor’s product significantly outperformed the other. POCs should be free from the vendor and last at least 30 days. If you can convince the vendor to let you POC their solution for 60 or 90 days, even better. Before beginning your POCs, make sure you establish what the purpose of the POC is, what the expected outcomes are, and the success criterion for those solutions. It will be helpful in building your business case—which will be covered in the next chapter—to have these report cards when you are budgeting and planning the implementation of these solutions.

I have encountered multiple scenarios where the technology looked great but didn’t work in our environment. Just as many times, it worked great, solved a problem, but I could not afford it. You can cut to the chase very quickly with vendors if you start with the following premise. I say to every vendor who is pitching me a new product (feel free to steal these lines), “I’m the easiest person in the world to sell to. If we need your product, if it works in our environment, and we can afford it, I’ll buy it. I control the first two and you control the last one.”

Lastly, you may find that your architecture, budget, staffing level and experience, or other factors lend themselves to considering an MSSP. MSSPs are in this business full time and provide SIEM, network threat hunting, malware sandboxing, and practically every other service or capability you are looking to buy and maintain yourself. Do this assessment first, determine whether your ability and cost to manage these technologies is lower, and then call in MSSPs for discussions. Once you have this assessment complete, you will know what you may want their services for and can then request bids to fill the gaps you can’t fill yourself.

Key assessment points:

• Do you have an enterprise wide inventory of security technologies and capabilities?
• What does your existing architecture support in terms of enhanced security tools?
• Have you evaluated the existing technology contracts and commitments to understand where you are in the existing refresh lifecycle?
• Are you able to map out existing versus desired technology capabilities using a tool like the Lockheed Martin Cyber Security Kill Chain?
• Are you capable of conducting POCs of concurrent technologies to compare performance?
• Do you have an existing MSSP relationship or are you able to articulate the potential use cases for entering one?

Maturity Versus Risk Measurements

Assessing a program is typically a highly subjective exercise. It is difficult to quantify—on say, a Likert scale—how experienced your people are or how effective your processes or technology are at mitigating risk. That said, assigning a numerical value for both maturity and risk in each of your program functions will help establish a baseline from which you can measure progress over time.

Thus far, we have discussed key points for assessing your people, process, and technology components, but a more detailed approach will be outlined—along with an example output—in the next chapter as part of developing your business case and three-year plan. For now, let’s discuss sources of technology risk and how technology risk is created.

Sources of risk can broadly be attributed to two categories: “insiders” and “outsiders.” Insider risk is often a result of well-intentioned staff who sometimes expose sensitive information when corresponding with outside parties. It could also result from uninformed or unaware employees engaging in risky behavior intentionally or unintentionally. Outsider risk is what most security teams focus on and includes malicious outsiders who are looking to steal sensitive information to use for themselves or to sell in the ever-growing information black market. The most common outsiders include nation-state sponsored, organized crime, and hacktivists. Despite the majority of focus and security spend on addressing outsider risk sources, over 40 percent of data breaches are the result of insider actions (half intentional, half accidental).1

What is technology risk? Here is the simple definition: A risk exists when a vulnerability can be exploited by a threat source.

As an example, Figure 2.3 is a graphical representation of risk creation in the retail industry.

There are a plethora of frameworks to reference when ranking risk in your technology environment, but which one to pick is not nearly as important as applying that choice to all your risk assessment activities in order to have apples-to-apples comparisons over time. If you use a five-by-five risk ranking scale one year, and then switch to a three-by-three scale the following year, you will spend more time converting risk rankings than addressing the risk.

Figure 2.3 Graphical representation of risk creation in the health care industry

Source: Icons from https://pixabay.com/

Figure 2.4 a simple risk ranking criteria map I have used over the years.

Figure 2.4 Sample risk ranking criteria map

Using this approach, a maximum score on the likelihood and impact scale would yield a score of 25 [5 (Likelihood) x 5 (Impact)]. In Figure 2.4, this would result in a critical risk and be represented in the far upper right corner. Of course, ranking the likelihood and impact on this one-to-five scale is subjective, but you can develop and align organizationally on what very low means as opposed to critical. Maturity ratings were similarly discussed on a one-to-five scale using the Capability Maturity Model® as a reference. Using this maturity-versus-risk comparison is helpful in prioritizing resources in the lowest maturity/highest risk areas of your program.

An example of this analysis is represented in Figure 2.5.

Figure 2.5 Program maturity-versus-risk analysis

Source: Icons from https://thenounproject.com/

With a similar analysis completed at your organization, you will have the foundation communication vehicle for people, process, and technology needs discussions with your CIO and other senior leaders. Remember to think like a businessperson. Keep it simple and use the examples in this chapter as references for developing your own assessment that other business leaders can understand.

Summary Points

1. Your first 90 days on the job are critical to your long-term success as the new CISO or IT risk management leader. You must build relationships and earn credibility early to pave a path of success for your program initiatives.
2. Take advantage of prior assessments, audits, or reviews of the IT risk management and information security program as it accomplishes two goals. First, it accelerates your knowledge of the environment by leveraging work others have already completed. Second, it shows that you are considerate of your peers’ and stakeholders’ time and that you will not visit with them to ask the same question an auditor asked two months ago.
3. Conduct your own assessment using simple, easy-to-understand criteria like people, processes, and technology, evaluated on risk and maturity scales. If you present a practical, reasonable assessment of your program in business terms, the likelihood of you successfully selling your business case and three-year plan (discussed in Chapter 3) will greatly improve.

---