CISM EXAM PREP - Domain 3B - IS Program Management

Welcome back to the CISM exam prep series. So domain 3 part B will really test your ability to apply your foundational technical knowledge that you bring with you to the CISM exam, particularly on the topic of security controls. So in this section, we'll touch on control design and selection, implementation and integration, and finally, control testing and evaluation.

Now, a couple of things to remember here. Number one, you shouldn't be directly tested on these technologies, but you should understand when to recommend each, the use cases where they fit, and you should know their features and their benefits. Then we'll talk about security awareness and training, keeping our users up to date. And then looking outside the organization, we'll take a look at managing external services. We'll finish up with a dive into communication and reporting to ensure we can keep senior leadership in the loop on our risk mitigation efforts.

Welcome back to our continuing coverage of domain 3 that focuses on the information security program. Here in part B, we'll focus on security program management. And while you may know me for my exam prep content here on YouTube, in my 9-to-5, I'm a cybersecurity strategist and a VCSO for a regional bank where I'm exercising my cybersecurity knowledge every day, like that which you'll find here on the CISM exam. More importantly, last year I helped thousands achieve cybersecurity certifications like the CISSP, CCSP, and the Security Plus exams, and I'm bringing that proven formula to you here with the CISM exam.

As with all my exam prep courses, you'll find a PDF copy of this presentation available for you in the video description to leverage in your exam preparation as you require. You'll also find a clickable table of contents available in the video description, and it should appear automatically on your YouTube video timeline.

So we are still focused on domain three, information security program, and in our logical flow here where we have a part A and a part B for each domain, we are in domain three, part B. So in our previous session, we focused on program development. We have that same logical flow we've seen throughout the syllabus. We're moving into program management. Here we're going to put a lot of focus on controls. So we'll talk about control design and selection, control implementation and integration, control testing and validation. So a lot of that technical knowledge you're expected to bring into this exam with you that you won't be tested on directly, it comes into play in domain 3 part B. We'll talk about awareness and training, and we'll even take a look at outside the organization at our vendors with management of external services, and we'll wrap with a look at information security program communication and reporting. But we see that logical flow from development to management.

Supporting tasks of the 37, there are about five that apply directly to domain 3 part B. So 15 is establish, promote and maintain a program for information security awareness and training. So our goal here is to build a security-aware culture within the organization. 16. Integrate information security requirements into organizational processes to maintain the organization's security strategy. So here, integration is the key word. Security is not a silo. It's designed to support business goals. We want to make sure that we integrate our requirements across the business unit, and we also want to focus externally. So number 17 is to integrate information security requirements into contracts and activities of external parties. So well-structured contract clauses are legally enforceable, ensuring vendors live up to their promises. Number 18 is to monitor external parties' adherence to established security requirements, alignment with organization policies, legal and regulatory requirements, and the organization's risk appetite. And number 19, define and monitor management and operational metrics for the information security program. So here we're talking about ongoing care and maintenance, which are essential in ensuring the program is still meeting the organization's needs.

And that brings us to 3B1, control, design, and selection. Here we'll talk through the people, process, and technology behind it. Managing risk through controls, control design considerations, and we're going to cover some of those foundational technologies that you're supposed to be familiar with when you come into this exam, just to make sure you have that technical foundation if it hasn't already popped up in your work experience. Let's dig in.

So, a successful program is going to balance three key elements. People, so ensuring staff understand and support risk management. We're going to guide them with awareness, training, clear definition of roles and responsibilities. Process, so documented administrative and technical procedures, our policies, our standards, and our guidelines. And then technology, the technical tools used to enforce security. So this balance is important in achieving the goals outlined in the security program's business case. We know security only exists to support the business.

So what technical knowledge do you need for this area of the CISM exam? It's a good question. It's a question I hear a lot. In the ISACA syllabi and materials, list many technologies, but the deep dives aren't the focus. You don't need to be an expert on how the technologies work internally. You do need to understand when to recommend a technology. You need to understand its use cases. You do need to know its general features and benefits for security. Prior technical knowledge helps, like if you've taken the CISSP exam, but the key technologies you need, I'm going to try to cover for you in this session to make sure you have that foundation.

So let's talk controls and control objectives. So at a high level, controls are the practical implementation of policies, procedures, and guidelines. And we'll talk more about the categories of controls and the types of controls later in this session. A control objective is a clear statement of the desired result or the purpose of implementing a control. Essentially, what should it achieve? A couple of plain English examples. Logical access. Only authorized users can access systems and perform only authorized actions. Physical access. Only authorized personnel can physically access computer resources. Very plain language and clear to business and technical users alike. And our control objectives must align with overall business objectives and be cost-effective.

So when we're designing controls, they should be designed based on the organization's acceptable risk levels. So if we were to lay it out in steps: Step one, identify risks, understand threats and vulnerabilities impacting the organization's assets. Step two, define acceptable risk levels. So, how much risk is the organization willing to tolerate for a specific threat-asset pair? Step three, design controls with risk in mind. The goal is to reduce identified risks down to a level acceptable to the organization. And remember, the control objective is our design goal. It's the effectiveness metric. They're all different ways of basically getting to the same bottom-line statement.

And it's going to be normal that we'll combine control types. Often, a single control objective requires multiple control types working together. So, for example, we have a firewall. A firewall is a technical control. It needs to be in a secure location with stable power. That's going to be what we'd call a physical control. We need configuration standards, rule review process. Anytime we ever touch the configuration of that firewall, we're going to call that an administrative control. And the operation requires monitoring and alerting. That's going to be technical and administrative. So there's a mix of control types coming together here. The ultimate objective is a control that is effective not only in theory, but in practice in the real world. The most effective security control in theory, if it's simply something everyone works around because it's so complex, it's not an effective control.

So, let's talk about selection criteria. Certainly, cost-effectiveness is one of those bottom-line objectives, but you should also evaluate the productivity impact. So, does a control significantly slow down legitimate work? We prefer controls that keep our user population safe without impacting their productivity in any way. It's simply a control they don't really notice. Total cost. So when we look at the acquisition, implementation, training, operations, maintenance, what does our bottom-line total cost of ownership look like? User acceptance. Will people actually use it correctly, or are they going to try to bypass it, making it ineffective in a practical sense? Then we need to look at legal and regulatory requirements. Does compliance mandate certain controls? Adaptability. Can the control evolve with changing threats and business needs over time? We don't want to have to repurchase frequently. Scalability. Can it handle future growth? If we see a spike in users, in data, in traffic, in customers, is it going to scale to our needs? Monitoring and notification. Can its status be monitored? Can it alert us when it sees issues? And then robustness or resilience. How well does it resist attacks or failures?

So the big picture, we want to think about physical security. Physical security is the foundation, and without physical security, other controls can be easily bypassed. So, information security often collaborates with facilities management, the people on the front line of physical security. We want to clearly define roles and responsibilities for physical access. Common controls would include badges, biometrics, cameras, guards, fences, lighting, locks, man traps or what we call access control vestibules, sensors, bollards to prevent automobiles from impacting our building. But remember, there is no security without physical security. If I can get into that wiring closet, it doesn't matter how effective your network configuration is, I can start pulling cables.

And think about controls based on who manages them. So if we were to put control technology categories and management into focus here, we have native controls. These are built-in system features, like operating system permissions or web server authentication settings. These are usually managed by IT operations. It's going to maintain segregation of duties to make sure we don't have one person with too much control over an end-to-end process. Supplemental controls. These are add-on security tech. This is the firewalls, intrusion prevention, single sign-on, MFA. These are often managed by more specialized security personnel in the organization, oftentimes collaboratively with IT. We'll want to talk with the broader technology organization, maybe even business process owners, to make sure that we're putting the right type of control and settings in place. And then management support controls. So these are tools for security team operations. This is where a SIEM that's aggregating our logs would fall into the mix, or a SOAR solution that automates some of our security investigation and response. These are primarily going to be used by the security organization, and our information security managers really need to see the big picture. They need a holistic view. So we want to combine all the native and supplemental controls from the overall technical defense structure. Understand how all the pieces integrate and work together. We want to avoid focusing on individual point solutions. We really need to look at end-to-end business processes and data flow and make sure that the combination of controls we have in place are going to keep us secure adequately end-to-end, reducing the risk down to a level the organization can tolerate, but focus on bottom-line objectives, business alignment, real-world efficacy, and cost-effectiveness.

Next, I want to step through some questions we need to be prepared to ask ourselves as we're reviewing controls. So we'll start with key policy questions. So, fail-safe versus fail-open. So, what happens when a system fails? We usually prefer what we'd call fail-secure, but not always. More on that in a second. Restrictive versus permissive. So, restrictive is where we deny by default, or permissive where we allow by default. So, which approach? We're usually going to prefer restrictive unless there is a reason that we might do otherwise. Least privilege. So, is access limited to the absolute minimum needed? Alignment. Does the control configuration match policy and business needs? So, bottom line, safety-critical systems like fire doors should fail open, and security-critical systems like a banking system, for example, should fail closed. And so you want to look at the practical nature of the system to figure out which is the right thing. Of course, we want fire doors to fail open so people can escape if the building's on fire, right? Because our number one concern is human safety, but most of your systems are going to tend to fall into that security-critical category, and that's where we're failing closed.

So, key implementation questions. So, there's policy compliance. Have we implemented according to standards? Self-protection. Can the control resist tampering? Alerting. Does it notify personnel on failure or errors? Testing. Has it been tested to confirm it works as intended? Logging and monitoring. Are activities logged and reviewed? Do we have an audit trail there of configuration changes? Does it achieve its defined purpose? Has it met the control objective? Mapping. Are control objectives clearly linked to business goals? Asking these questions ensures real-world control alignment and efficacy.

Next, we have placement questions. So, location. Is it placed correctly within the architecture? For example, did we put the firewall in the right place at the edge of the network? Layering. Are controls layered effectively? We want to make sure that we have defense in depth, a layered defense in place. Redundancy. Is redundancy needed? Is it implemented correctly? If we did need redundancy, perimeter. Are perimeter controls effective? Are we blocking threats at the edge of our network, at the edge of our physical location? Bypass. Are there ways around the control? And if there are ways around the control, are those bypasses likely to be exploited? Are they exploitable? So we want to check physical, network, system, app layers, all the way up the stack to make sure that the bypasses are dealt with from the front door to the application layer.

And then key effectiveness questions. Reliability. Does it work consistently? Minimality. Is it the minimum needed, or is the control overly complex? Productivity impact. Does it unduly hinder users and their productivity? Automation. Is it automated, or is it a control we have to touch manually? Generally speaking, automated is preferred over manual, but an effective manual control is preferred over an ineffective automated control. Monitoring. Is it actively monitored, ideally in real time? Circumvention. How easy is it to bypass?

And then key efficiency questions. So, what is the breadth of protection? How widely does it protect our environment? Does it cover one system or does it cover many? That's certainly going to affect how efficient it is and how cost-effective it is, potentially. Specificity. Is it tied to one resource or broadly applicable? Single point of failure. So, if the control fails, does the application stop working? Single point of failure from a security perspective. If the control fails, does the overall security posture collapse? Unnecessary redundancy. Are there overlapping controls that provide no extra value? That's going to be potential cost savings and potential complexity reduction and potential reduction in ongoing operations and management effort.

And then key measurement questions. So, responsibility. Who is responsible for measuring effectiveness? We need monitoring, reporting, and effective metrics in place. But who's going to be responsible for measurement from a reporting perspective? How, to whom, and how often are outcomes reported? So we ensure that our controls continue to be effective, and everybody knows. Testing. Who performs tests? The owner versus an independent team like audit and compliance. Thresholds. What defines normal versus error conditions for reporting? Remember, metrics need to be relevant, measurable, and actionable. If we have a metric out there that does not trigger action, it's not terribly useful. So, our metrics should be relevant, measurable, actionable.

So, let's shift gears and talk through some of those foundational technologies I told you wouldn't be directly tested, but would be important for you to be familiar with on exam day. We'll start with the digital certificate. A certificate where two keys are generated: a public key and a private key. The private key, of course, only held by the certificate holder. So, the private key is used for identity. Common use cases for digital certificates include authentication, code signing, document signing, and we see certificates often used in VPN configurations. So, the Public Key Infrastructure, or PKI, is the service that issues and manages our digital certificates. So, the Certificate Authorities in the PKI create digital certificates and own the policies. The PKI hierarchy can include a single Certificate Authority that serves as the root and the issuer of certificates as well. This is generally not recommended for security purposes. You may also hear a Certificate Authority called a Certification Authority by some vendors, or simply a CA. All references to the same capability.

So, just taking a peek at the roles within a typical PKI hierarchy. We have the issuing Certificate Authority. We have a subordinate or intermediate CA. And then we have the root CA. So the root serves as the root of trust in our Public Key Infrastructure. It issues certificates to new subordinate CAs that generally manage our policies. They're also called policy CAs or intermediate CAs. They will issue certificates to new issuing Certificate Authorities. The issuing CA is the one that is responsible for issuing certificates to clients, servers, devices, websites, and users. This is the role that does most of the day-to-day lifting. And when we use a certificate in a situation such as for authentication, the chain of trust goes all the way back to the root CA in the environment.

Now, I mentioned that a single server could handle all of these roles, but we don't recommend that. So, generally speaking, you know, you could consolidate to one or two levels. We don't for this reason. If our issuing CA is compromised, we want to be able to cancel those certificates, revoke those certificates, as we say, and reissue them from a new issuing CA. We would simply cancel all of that compromised CA's certificates, deploy a new CA, and reissue those certificates. If we have all of these roles rolled up into a single server, we have compromised our entire PKI. So in a three-tier system, if we have a compromised issuing CA, we can simply revoke certificates, destroy that CA, and then issue a new certificate out to a new issuing CA from our subordinate and so on and so forth. And in a two-tier system, we still have some of that resiliency.

And don't get too wound up in the way these arrows flow. So you see the chain of trust I said me, I mentioned goes all the way back to the root CA. We could say that trust flows down from the root CA as well. So a few other PKI-related concepts that deal with our management of digital certificates include Registration Authorities, or RAs, which are the entities responsible for verifying the identity of certificate requesters and forwarding those requests to our CAs. We have the Certificate Revocation List, which contains information about any certificates that have been revoked due to compromises to the certificate itself or to the PKI hierarchy. As I mentioned earlier, the CRL of issuing CAs contains the information on the revocation of certificates that particular CA has issued. So each Certificate Authority issues its own, generates its own CRL, and your CAs are required to publish these Certificate Revocation Lists, but it's up to certificate consumers if they check these lists and how they respond if a certificate has been revoked. Is it possible to configure an endpoint or a browser to simply accept any certificate it is presented? Sure. But that's not a good idea. We definitely want our browser to tell us if we're visiting a website where a certificate has been revoked or there is some problem with that chain of trust back to the root. But again, your CAs are required to publish. Consumption on the client and is purely optional. Each CRL is published to a file, and the client must download that file, which in some environments, in high-use scenarios, high-traffic scenarios, can grow quite large over time. And that's where the Online Certificate Status Protocol, or OCSP, comes into play, because it offers a faster way to check a certificate status compared to downloading that CRL file. So with OCSP, the consumer of a certificate can submit a request to the issuing CA to obtain the status of a specific certificate. Quicker, easier, less bandwidth consumed.

Then there is the Certificate Signing Request, or CSR, which records identifying information for a person or device that owns a private key, as well as information on the corresponding public key. It's essentially the message that's sent to the CA in order to get a digital certificate created. It is the request. You may see Common Name mentioned, which will definitely come up in the properties on a digital certificate. That is generally speaking the fully qualified domain name of the entity to whom the certificate has been issued, like the web server. There's the concept of an online Certificate Authority and an offline Certificate Authority. So an online CA is always running, and an offline CA is kept in a powered-off state except for specific issuance and renewal operations. So offline is best practice for your root Certificate Authority. Your intermediate CAs don't necessarily need to all be online day-to-day as well. Your issuing CA, of course, is the one that's doing that heavy day-to-day lifting. So the issuing CA is always going to be online. Your root CA is typically going to be offline except when we renew certificates, such as for our issuing Certificate Authority, when it gets more than halfway past its lifespan. There is stapling, which is a method used with Online Certificate Status Protocol, which allows a web server to provide information on the validity of its own certificate. Essentially, it's done by the web server by that server downloading the OCSP response from the certificate vendor in advance and providing it to browsers. So it's a configurable behavior. There's pinning, which is a method designed to mitigate the use of fraudulent certificates. So with pinning, once a public key or certificate has been seen for a specific host, that key or certificate is pinned to the host, and should a different key or certificate be seen for that host, that might indicate an issue with a fraudulent certificate.

You should also be familiar with the four goals of cryptography. The first is confidentiality, ensuring that information remains secret from unauthorized parties. Integrity, guaranteeing that information has not been altered during transmission or storage. Authentication, which verifies the identities involved in communication or accessing resources. And non-repudiation, which prevents entities from denying their involvement in a transaction or communication. You should be familiar with symmetric and asymmetric cryptography. Symmetric cryptography relies on the use of a shared secret key. So the downside of symmetric cryptography is it lacks support for scalability. Key distribution is a challenge. It can't help us with non-repudiation. Asymmetric comes into play here, which uses a public-private key pair for communication between parties. So that's going to be more scalable when we take a conversation out to multiple parties. Key distribution is going to be easy with asymmetric, and we can actually use asymmetric to distribute a symmetric shared key securely, and asymmetric comes into play with non-repudiation. So a few common uses: symmetric is typically used for bulk data encryption. It's going to be faster than asymmetric. Asymmetric is going to be used for distribution of symmetric bulk encryption keys, the shared key we were just talking about. We see asymmetric in identity authentication via digital signatures and certificates, in non-repudiation services, and key agreement. So, symmetric basically uses that single key for encryption and decryption. And there are several use cases for symmetric encryption. The one we most commonly think of is bulk data encryption. That's where it excels. And the most commonly adopted symmetric encryption algorithm is the Advanced Encryption Standard, or AES, which is even used by the federal government for encrypting their top-secret data.

And to illustrate the same for asymmetric encryption. In asymmetric, we have a public and private key for each party. And if we were sending a message to a recipient, we would use their public key to encrypt the message. They would use their own private key to decrypt the message. You'll also hear asymmetric cryptography called public key cryptography. So if we just look at that key exchange, we have Franco and Maria. Franco sends a message to Maria requesting her public key. Maria sends her public key to Franco. Franco uses Maria's public key to encrypt the message, and he sends it to her. Maria uses her private key to decrypt the message, and that exchange would happen through whatever application in the context of whatever information exchange was taking place. And we'll talk about common use cases here in a moment where asymmetric cryptography can even help symmetric.

So let's talk hashing for a moment. So how is hashing different from encryption? Well, encryption is a two-way function. What is encrypted can be decrypted with a proper key. Hashing, on the other hand, is a one-way function that scrambles plain text, like a password, for example, to produce a unique message digest. There's no way to reverse a hash if it's properly designed. So, common uses for hashing include verification of digital signatures, generation of pseudo-random numbers, and integrity services. For example, we can hash a file before we send it and run that hash again after and make sure that it matches, that the data arrived intact. And you've no doubt heard the phrase password hash. It's a hashing function that's used to hash your password, which is then passed between parties in the authentication process. So file integrity services, monitoring validation of data transfer. Hashing is used in file integrity monitoring where we have a security product that monitors our sensitive system files to make sure that they're not changed without authorization, or validating data transfer, as I mentioned, hashing a file before and after transmission. So a good hash function has five requirements. It has to allow input of any length. It has to provide fixed-length output. Needs to make it relatively easy to compute the hash function for any input. It needs to be quick, in other words, and it needs to provide that one-way functionality. It can't be reversed, and it must be collision-free, meaning that every unique input must always produce a unique hash output. So just to illustrate the hashing function, as we did the other algorithms, with the hash function, we have an input of any length that must produce a unique hashed output. So it needs to be collision-free. That's actually why MD5 is limited in the operations it's used for today because it's somewhat susceptible to collisions.

So then, just to piece these together in terms of their common uses, we said symmetric is typically used for bulk data encryption. Asymmetric is distribution of bulk encryption keys. So we can use asymmetric to distribute that symmetric encryption key to multiple parties, which is a shortcoming of the symmetric algorithms. And then I'll just add hashing to the list here, where we talked about verification of digital signatures, generation of pseudo-random numbers, and integrity services. I put some examples of algorithms on there. We won't be tested on those on the exam, of course.

Then we have digital signatures. So digital signatures are similar in concept to handwritten signatures on printed documents that identify individuals, but they provide more security benefits. It's an encrypted hash of a message encrypted with the sender's private key. So in a signed email scenario, it provides three benefits. Authentication, number one, it positively identifies the sender of the email. Ownership of a digital signature secret key is bound to a specific user. Non-repudiation, so that sender cannot later deny having sent that message. This is sometimes required with online transactions. It would be highly desirable, in fact. Integrity, it provides assurances that the message has not been modified or corrupted in transit. Recipients know that the message was not altered on the way to them from sender to recipient. So these are the basics that would be important for something like the Security Plus exam, and you should be familiar with the function. You won't be directly tested on them for the CISM, though. And just to visualize, as we did with the algorithms, so with a digital signature, remember we encrypt with the sender's private key for signature generation and verification using the sender's public key.

And that brings us to the end of section 3B1. So let's test what we've learned here with a practice question. So, security technologies should be selected primarily on the basis of their: A) benefits in comparison to their cost. B) evaluations in trade publications. C) use of new and emerging technologies. Or D) their ability to mitigate business risks. So, they're asking us what they should be selected on primarily. So, what's the most important of these? So, there are a couple we can cross off right away. Evaluations and trade publications might tell us what others are using and give us a starting point in our exploration of options, not our primary metric. And then use of new and emerging technologies. We know we want to use modern technologies that can help us with modern threats, but that's also not going to be the most important metric. So we see A is benefits in comparison to their cost. So that's cost-effectiveness. Or D, their ability to mitigate business risks. Both important, but on the CISM, you're going to see that often that you'll have adjectives like primarily or adverbs like primarily or first or next. So our option here, the best option here is D, the ability to mitigate business risk. So that's the most fundamental evaluation criterion for the appropriate selection of any security technology. It needs to be able to do the job. Secondarily, it must also be able to do so for us cost-effectively.

Moving on to section 3B2, we're focusing on information security control implementation and integration. So we'll touch on the categories and types of controls. We'll talk about baselines, and we're going to dig into a number of details through the implementation process, ancillary considerations, but we'll wrap up with a look at some foundational technologies, some of that tech know-how you need to bring into the exam with you, but that you will not be tested on directly. It's really going to be referenced more in the context of control selection.

So, security controls are measures for countering and minimizing loss or unavailability of services or apps due to vulnerabilities. So the terms safeguards and countermeasures are generally used interchangeably. If we were to get technical about it, safeguards are proactive controls that reduce the likelihood of occurrence, and countermeasures are reactive. They reduce impact after occurrence. They're often simply called controls in CISM literature. It's fairly rare I see security controls mentioned, but used interchangeably for purposes of our discussions.

So there are three control categories. You should be familiar with the technical controls, sometimes called logical controls. This is the technology, the hardware and software mechanisms used to manage access and to secure our assets. Administrative controls, the policies and procedures defined by the organization, security policy, and other regulations and requirements. And then physical controls, these are items you can physically touch. So controls that protect us in the physical world.

There are several control types you should be familiar with, and I think you'll find these names are largely self-explanatory. We have deterrent controls, which are deployed to discourage violation of security policies. They deter bad behavior. Preventive controls, deployed to stop unwanted or unauthorized activity from occurring. Detective controls, deployed to discover or detect unwanted or unauthorized activities. Compensating controls, which provide options to other existing controls to aid in enforcement of security policies. They're kind of a backup control to other controls. And then we have the corrective control, which modifies the environment to return systems to normal after an unwanted or unauthorized activity has occurred. And then the directive control, which directs, confines, or controls the actions of subjects to force or encourage compliance with security policies.

So, here are some examples of controls that fall into the different categories of controls. So, here's a good list of technical controls. You'll see there's a lot of technology there. Physical controls, controls that work in the physical world, like guards, fences, lights, cameras, alarms, locks. And then we have the administrative controls. I think of these as the policies, procedures, and the paperwork that fall into this category. So remember, technical is also logical, that's the technology, the hardware and the software. Physical or tangible, touchable. And managerial or administrative are the policy and policy implementation, largely.

So let's talk about control overlap. It's a reality that one control can serve in multiple roles, multiple types. That single control can be identified as a different type depending on the context of the situation. Basically, controls are designed to work together, and their functions do often overlap. So, for example, a security camera is both a deterrent. It's going to deter unwanted entry because the bad actor will see that camera and know that they are being watched. It's also a detective control. So, if that bad actor goes ahead and tries to breach a facility, for example, we're now recording that unauthorized activity. But the context matters. The classification of a control can depend on how it's implemented and the specific risk it's addressing. For example, an access control list can be primarily preventive if it blocks unauthorized access, or detective if it mainly logs access for later investigation. And you can focus on keywords. Some exams will use specific keywords or phrases to hint at a control type. It can help you to understand what the question is asking of you. So here are a few kind of trigger words or phrases that you can associate with the different types of controls. And if you go back and look at the examples, for example, a corrective control, backup, restore, incident response, patching, that's bringing the environment back to where it was before you started, right? A compensating control, I mentioned, is a backup control. So, a redundant control, an alternative control. Just a few tidbits there that may be helpful in keeping the different types straight in your head.

So, let's talk about control baselines. You want to be familiar with their function, their benefits, how they're used in the real world. So, a baseline to start is a predefined minimum set of security controls applied to all new systems or to systems based on a data classification level. So they can be based on risk appetite, industry standards, or other regulations. And high-risk assets may require supplemental controls in addition to the baseline. The purpose is to establish essential, documented security requirements for a baseline level of risk. So, for example, required authentication methods, standard logging and auditing settings, like in our Windows security event log, default role-based access control settings, and data encryption for data in transit. You want to be ready on the exam to justify deviating from a baseline. Usually, this means applying stricter controls for critical assets based on risk assessment, or such as for those high-risk assets that I mentioned.

So what is the role of the information security manager in baselines and system development? Well, we're going to help with evaluation, assessing if the proposed solution meets baseline requirements and aligns with acceptable risk. Due diligence, so identifying and communicating any control gaps in solutions, developing mitigating or compensating controls. They'll oversee or help direct some sort of code review, ensuring that secure coding practices, especially for critical systems, are in place. And this may involve independent third-party review, some sort of external assessment. Testing coordination, making sure that security requirements are actually tested during QA and user acceptance testing. So before we go into production, and issue resolution, collaborating with project teams to prioritize and fix identified security flaws. The risk acceptance process. So if issues can't be fixed before launch, ensuring senior management formally reviews and accepts the residual risk. And of course, documenting that acceptance. It should be recorded in the written record. The idea is to integrate throughout the systems development life cycle, ensuring we have segregation of duties and security testing built into the entire SDLC. We're not bolting on after the fact where it's more expensive and more complicated and more disruptive. But security isn't an island. It has to integrate seamlessly with IT governance and management.

So our number one goal: security measures should enable, not unduly impede, business operations. Controls have to be effective in practice in the real world. It's great if something looks effective on paper, but we need to make sure that functionally it's as effective in operation as it is in theory. Goal number two, ensure non-security personnel clearly understand their roles and responsibilities in security processes. So we do this through things like security awareness training and defining roles and responsibilities. Maybe establishing a RACI matrix to ensure this is the case. But the InfoSec manager has to consider that human element of program management, the people, their roles, their skills, our organization's culture, and it's going to depend on well-defined roles, having folks with the necessary skill sets, and a strong security culture. So the information security manager is going to allocate personnel, identify skill needs, whether those are technical skills or administrative skills, plan training, and when we don't have the necessary skills or resources in-house, contracting that expertise externally. Typical security positions involved here would include engineers, QA and testers, access admins. We sometimes see those as identity and access engineers, project managers, compliance liaison that might interface with legal and compliance, architects, some sort of awareness coordinator handling some of that security awareness, communication, education, and training, auditors, policy specialists. The roles are often combined in smaller organizations, but we need to develop the communication and integration across our business units, and we can use training for internal staff or contract external specialists when we don't have the necessary skills in-house. So, for example, if we have the occasional need for deep cryptography experience to talk about the algorithms that we're implementing as part of a specific process, we may need to go out and find a specialist to just validate what we're up to meet the standard. But managing and communicating clear roles and responsibilities is super important while supporting a security-aware culture where everybody sees security as their responsibility in the context of their role. So the role is who performs a function, such as the firewall administrator. Responsibility is what that role must do, such as reviewing firewall rules on a quarterly basis. So the role has that responsibility. And from a culture perspective, we're talking about the shared values, beliefs, and behaviors that demonstrate security consciousness in daily work. And that comes down to an organization that empowers our employees from a security perspective through education, training, and clear definition of roles and responsibilities, where everyone takes ownership of security as their responsibility in the context of their role. And the information security manager has to foster that across the entire organization. They are the connector between the business and the technical. So that's where we can use RACI charts to define who's responsible, accountable, consulted, and informed to clarify everyone's involvement in the processes so nobody is guessing as to who is responsible for what.

So the information security manager also oversees creation and maintenance of key security documents, the written record. From a materials perspective, things like risk assessments, the reports that come after system configuration documents, incident logs, process flows, org charts, RACI matrices. And from a management perspective, assigning document owners, implementing version control, making sure we have update and approval processes in place, and then making sure that documentation is classified and protected relative to its sensitivity. For example, we'd see policy, standards, procedures, guidelines, network diagrams, architecture docs, training documents, incident response plans. The information security manager from a high level is going to have eyes on these processes to make sure these documents are created, that they exist, and that they are well-maintained. At the end of the day, documentation reduces mistakes, especially in stressful situations.

The security liaison acts as a connection point that ensures security efforts are aligned to business objectives. They act as a bridge between the central security function, the security team, and the other departments. They ensure security requirements are understood, integrated into the business processes, and gather feedback along the way to ensure that security and the business remain in alignment, and they build those ongoing working relationships across the enterprise. It'll vary by organization, but here are a few common examples of liaison and their function, their role. So IT audit, for example, will collaborate on compliance checks, control effectiveness testing, mitigation plans. We have IT, which partners on secure configurations, our baselines, patching, performance, system deployments. You have business unit managers that align security with business goals, that basically act as that interface to make sure that security remains in alignment with the business, as we need to be helping us to understand operational needs and to gather risk intelligence. Human resources. So HR will coordinate on background checks, security awareness training, policy enforcement, like acceptable use policy, very common as part of the onboarding process. The user gets that acceptable use policy that they must review and sign. HR can help us with all of this. Legal, who can advise on compliance obligations, any liability exposure, any contracts we might sign with new vendors. And all employees act as a first line of defense in a security-aware culture. They do need ongoing training. They need clear guidance on reporting procedures. So when they do see a concern, they know where to raise the flag. Procurement, who can help review technology acquisitions for alignment on security standards, compliance, and risk to ensure that anything new we're bringing into the organization in terms of technology aligns to the organization's standards and risk appetite. The compliance or privacy office, addressing any specific regulatory requirements that we might see with GDPR or HIPAA on the healthcare front. Training and education. So especially in larger enterprises, we'll see a dedicated training function whom can partner to develop and deliver effective awareness and role-based security training. Quality assurance, to integrate security testing into the overall QA process to make sure that security changes or changes that may affect security are well tested before they go to prod. So aligning incident response and business continuity and DR plans with cyber insurance policy requirements. Third-party management, to overseeing security practices of vendors and service providers. The project management office, ensuring security requirements and risk assessments are part of all projects.

So, here are a few tips on optimizing communication and accountability across roles and business units. In terms of communication gaps, you want to expect scenarios on the exam testing your ability to translate technical risks into business impact and vice versa. And remember here, the information security manager wears multiple hats. So, they have that technical background. They understand the technical lingo, but they're translating these concepts, these messages to a business audience. And clear escalation path. So knowing the importance of clear, documented procedures for escalating unresolved security issues and distributed accountability. So understanding how liaisons help embed security ownership and decision-making across different departments. So that's where something like a security steering committee can come into play because we have representation from across the business units. So we understand the accountability firsthand, who the business process owner is versus the data owner versus the control owner, for example. And just as accountability spans multiple departments, security responsibilities often span multiple departments. We want to apply segregation of duties principles wherever we can to prevent conflicts of interest. For example, we wouldn't want a developer deploying their own code to production without someone else reviewing it first, potentially having another person responsible for the approval before it goes to production, such as the business process owner, for example. And where segregation of duties is impractical, which happens quite a lot in smaller organizations where the headcount is limited, we want to implement compensating controls. So that means we might have increased monitoring and alerting. We might implement mandatory vacations or job rotations so we can spot any patterns of wrongdoing or mistakes. For example, increased monitoring and alerting. In a small organization, we might find that having an approval process where one person requests elevated access and somebody else approves that access might be impractical. And so as a compensating control, we simply turn up the logging and we add an alerting function. So when one person turns on their admin privileges, everybody else in IT gets an email notification. Built-in oversight. But compensating controls ensure operational security and they prevent audit failures because even though we have those limitations in a smaller organization, the audit function, especially in an external audit, they're going to expect that we've done something to close the gap. And know the role of the information security steering committee in ensuring the information security program meets the needs of the business. The core purpose of that steering committee is high-level governance to provide direction and ensure alignment. They give us that business perspective. It's going to be composed of senior stakeholders from key areas. So it'll have somebody from IT, but also likely legal, HR, risk, business operations, security, audit. You're going to have functions from across the organization. It requires input from other key departments. We're going to have some business process folks in there, but that steering committee owns the security strategy. They would approve typically major policy or standard changes. They ensure alignment of security with business objectives on an ongoing basis. And a structured approach is critical when we're thinking about incident and problem management. This is going to include key activities like systematic investigation of root causes of incidents and problems. Developing clear action plans with owners and due dates, tracking progress and reporting, providing updates to stakeholders until resolution is confirmed. And when controls fail, the information security manager will identify and prioritize the failures, deploy mitigating actions like system isolation, for example, escalate to senior management if there's a significant business impact. We may need to get an opinion from the top and potentially approval for our actions. And the information security manager won't necessarily have hands on all this, but they'll certainly have eyes on all this. There's certainly going to be oversight and serving as that bridge. I really think of an information security manager as an orchestrator that's connecting my technology, security, and business functions and developing that structured approach from scratch can seem like a lot, and that's where frameworks come into play. ITIL is great for guidance on general incident and problem management. NIST Special Publication 800-61 covers computer security incident handling, and COBIT as well, all offer structured process guidance that can be applied to issue and problem management to make developing that structured approach and getting that documented and communicated easier.

So let's talk vendor management. It's absolutely essential to oversee external vendors, whether they're hardware, software, cloud services, or consultants coming in providing services as part of our program management. The goal here is to ensure that risk introduced by vendors stays

Within the organization's risk appetite, making sure that the security our vendors practice when working with our organization and within their own organizations align to our appetite. So other key areas we'll want to verify would include financial stability. We want to make sure that when we choose a vendor for an important function that they are going to be around for a good long while. We want to establish service quality standards. So we want SLAs's and we'll put those into contracts and make sure they're appropriately worded and enforceable.

Staffing and expertise. We want to make sure that when we contract a services partner, for example, or maybe a managed security provider that they have the expertise on staff to fill those gaps that we don't have in house if that's what we're contracting for, that they adhere to our security policies. We'll want to check for right to audit clauses in our contracts to make sure that we include those or we have an acceptable alternative. For example, with your major cloud service providers, the Amazons, Azures, and Google Cloud Platforms of the world, you can't audit those platforms on demand, but you can go to their portal, click a little NDA signing, and download a SOCK 2 type2 report or get your hands on their ISO 271 documents for the given services you're working with. So, you can get that level of assurance from an external audit, even if it's not you that's ordering it. It's actually better in fact because that's going to be a very reliable form of assurance that you didn't have to pay for. And with your smaller vendors, uh, you can certainly go the route of asking them to share the last audit that they had conducted by an external vendor on their own behalf.

And overall security posture alignment. You know, at the end of the day, we want to make sure that the risk exposure of our vendors is not any greater than our own risk exposure. We don't want to weaken our security posture through a poor vendor choice. And security can't be an add-on. You're going to hear this frequently. You're going to see this frequently throughout the the CISM. Security can't be an add-on. It has to be embedded within standard IT processes. You know from the systems development life cycle where we see security going all the way back to the design phase change management configuration management release management service delivery. At the end of the day if we embed security from the beginning it helps us maintain control effectiveness, minimizes our vulnerabilities. It avoids gaps in production services or conflicting efforts where folks aren't organized and there's maybe an overlap where we then have a misalignment of effort, maybe wasted money because we've bought controls that are redundant in someplace. But essentially, this is what we'd call a shift left approach where we make sure that security is not an afterthought. It's integrated throughout the process because at the end of the day, that's going to be less expensive and less disruptive.

But the point of integrating security into core IT processes is to proactively embed security considerations throughout the IT life cycle. And that means incorporating requirements from the beginning. So for example, all the way back to the planning and requirements phase, we'll perform risk assessments. They might be informal. So for example, if we are planning and designing a new piece of software for a business function, we can bring the security function in. They can put eyes on our design and on our requirements to see if they have any concerns, if there are any new risks we're going to be bringing to the environment. So they can help us to address those before we begin to build. If we need to tweak a design, uh, we can do that quicker, easier, with less effort, and less cost early on right before we start the build. We want to avoid bolting on security at the end because at that point, it it's often less effective. It's certainly more expensive and it's going to take more work potentially from multiple groups. And that really applies regardless of the development methodology you're using. It could be waterfall, it could be agile, it could be scrum. This is going to be equally important and effective in all of them. This minimizes vulnerabilities and it ensures maintenance of effective controls rather than treating security as a separate add-on or a later step. Common mistake I see in organizations and something you're quite likely to be tested on repeatedly in the CISM exam.

So let's talk through a few of these integration points. So for example in DevOps and dev secc Ops we want to build a culture where we merge development and operations for speed and agility and that means we're going to embed security in our CI/CD process and that's where we see that that term dev sec ops that integrates security practices into that DevOps pipeline. We're shifting left with security with a goal of automating security testing and validation wherever we can to keep pace with rapid development cycles which in some organizations means multiple releases in a day. But security must be a checkpoint also in the change management process. The security function needs to be at the table on that change approval board to assess how proposed changes impact security posture. If there are new vulnerabilities or controls that are needed, risk analysis should inform the change approval decision. The challenge here is ensuring consistent application in decentralized organizations. The larger the organization, the more likely you're going to have a decentralized process for changes of various sorts. It may not just be related to business functions. It could be any number of those and consistent application across the entire organization is one of the greatest challenges in a large organization where it's decentralized for example by region out of necessity.

So in configuration management we know configurations are something we need to be very consistent with and misconfigurations are a leading cause of security breaches where we maybe don't have that automatically deployed configuration baseline. So that's where we want to integrate security into configuration management to ensure consistent enforcement. Consistency is everything. So this requires clear documented configuration standards, control baselines, hardening guides, and staff trained to make sure these are used and they are in place. The risk factor here, overwork teams, poor documentation. These can lead to insecure shortcuts. That's where automated configuration through CI/CD and other automation technologies can ensure consistency. In fact, in CI/CD, we we often see policybased security that's laying down that security baseline at the very beginning every time. So all of our VMs come off the shelf deployed the same way. Our application instances are absolutely consistent in their deployment. And again, when we have higher risk assets, there may be some add-ons in terms of additional controls, but that baseline being automated ensures it's consistent. And typically, that automation will also provide some autocorrection when we have shift and drift in our configurations to make sure that it's consistent throughout. It only takes one miss to open that door to a breach.

Release management. So this is the process that oversees the final stages of getting software or system changes into the live operational environment. And here we want to ensure that security testing is completed before new systems, applications or significant updates go into production. The key word there being before. We want to follow standardized procedures to minimize deployment risks and operational failures essentially. And that's again where automation is extremely common today and it's increasingly essential in modern release management. It's often delivered through that CI/CD pipeline. And we often see this automation delivered through tools like Jenkins, GitHub actions, Azure pipelines, Maven. If you're not involved directly in CI/CD, maybe you've heard of some of those tools, but that's very commonly how we do it. Kubernetes and Docker may factor in there.

Now I want to shift gears and cover some more foundational technologies. We're going to talk about cloud for a minute. Cloud networking really. So let's start with cloud deployment models. So cloud deployment models refer to how the cloud infrastructure is physically deployed. It determines who owns and operates the cloud infrastructure. There are four cloud deployment models you should be familiar with. There's the private cloud which is really your virtual machines and your hypervisors deployed in your data center. So this is going to give you all the control you need in legacy support scenarios. You know the the cloud is generally always up to date with some flexibility. But in a private cloud it's all you. So you have control over whatever you need there. The public cloud is where we can basically leverage our cloud providers data centers. We get out of the business of data center management, handing over some of that responsibility. And here we can easily scale. We're paying as we go, paying for what we use. We're going to have lower maintenance, lower skills requirements. And the level of skill really depends on the cloud service models we select, and we'll talk more about that in a moment. There's the community cloud, which is shared by a group. So you might see community cloud where it's a cloud shared by a consortium of insurance companies. It's going to be cost-effective because we have shared compute, shared resources, collaboration, some common needs. I honestly don't see community clouds come up much in the real world. Then there's the hybrid cloud where customer and cloud provider are sharing responsibility in some respect. Often we have a connection like a VPN or MLS network connectivity between our corporate data center and the public cloud like an AWS or Azure. That's going to give us flexibility in legacy compliance and scalability scenarios. If we'd like and greatest uh easily scaled and so forth, we can deploy into public cloud for those legacy scenarios where we're not ready to upgrade or we need certain control. We can leave those workloads in our corporate data center. So that's hybrid and you want to be familiar with the shared responsibility model. So depending on the mo the service model we deploy to in the public cloud the responsibility is going to shift. So for example on premises it's easy that's a private cloud the responsibility is 100% yours. The the organization owns it all. When we move into infrastructure as a service, which is really server virtualization, we're handing over management of the physical server, the storage, the networking, the data center, the data center staffing. It all belongs to the CSP. At that point, when we move into platform as a service where we're focused on application deployment, we're handing over even more responsibility to the cloud service provider. And certainly in that scenario where we're focused on modern applications that are going to deploy effectively into uh a paz environment, that's going to require a fair amount of skill from your development team. But in terms of managing infrastructure and middleware and the runtime, it's much less responsibility, much less for us to worry about. We're really just focused on applications and data. So if we've got a good development team and a good security crew to help us you turn the knobs on on the security settings in the paz services we're all set. And then if we move into software as a service, the CSP is taking on more responsibility still. If we think about software as a service like Office 365, uh HubSpot, any sort of software as a service as a consumer, the organization is really sharing responsibility for their applications and data. They're really just a user of the service. They do bear some responsibility for access management and potentially data backups and recovery.

So we talked about private cloud and then just to give you hybrid cloud from another perspective that's where hybrid cloud sits in the service models here and shared responsibility. So from a virtualization perspective, when we step into that hybrid scenario, which is exceedingly common today, we we're using server virtualization is where these concerns first surface. It's where we're dividing a physical server into multiple unique and isolated virtual servers using a hypervisor if that's HyperV or VMware for example. A couple of concerns we have here. One is VM escape. So the security concern here is where the attacker gains access to a VM and then they attack either the host machine that holds all the VMs or the hypervisor or any of the other VMs. So VM escape where the attacker gets access to that VM and goes beyond. Protection here would be ensuring patches are in place the hypervisor and VMs are always up to date which is going to be easy if you're in an IS scenario. It's not your responsibility anymore. Guest privileges are low that we've got server level redundancy uh which is configurable in most of your cloud service providers. Having hostbased intrusion detection and prevention in place can also be effective here. And then we have VM sprawl. This is where unmanaged VMs have been deployed onto your network. And because it doesn't know it's there, it may not be patched and protected and thus it will be more vulnerable to attack. And that can be even more problematic in the public cloud where just about anybody we give access to the controls can push a few buttons and deploy a VM which may not be fully patched by us because that's usually a configurable feature in the IAS world and it's also going to cost us money right we're paying for what we use there. So avoidance here means enforcing security policies and access control for adding VMs to the network as well as periodic scanning to identify new virtualization host that can be part of our monthly vulnerability scan.

From a network virtualization perspective we have uh virtual local area networks or VLANs which are a common approach to network segmentation that logically divides a layer 2 network. So here's a layer 2 switch. The segmentation is based on broadcast domains logically grouping switch ports based on communication needs. So for example, we create a VLAN for our client systems, a VLAN for servers or maybe even subsets of servers. We might put all of our database servers on their own VLAN. For example, uh we'll use a dedicated VLAN for our voiceover IP, our unified communications for example. And then the firewall. There's a common three interface firewall design that can provide some basic network segmentation separating your trusted networks and resources from those that are accessible from the internet. So for example, in a three-legged config, we'll see the external or untrusted interface that connects to the internet or some other untrusted external network. The internal or intranet interface which connects to the organization's main networks. This is where most of your business systems provide. We also call this the trusted sometimes. And then there's the DMZ where we connect uh the untrusted network that's housing our servers that are customerf facing like our web servers and application servers that have to accept those external connections from customers generally from the internet. So if we were to picture that we've got our trusted where we're going to have business applications used by employees uh basically protected and isolated from the public internet and our DMZ. We have our public facing servers and applications in the DMZ and then that external interface which points to the internet where our customers and other external parties will access. And you should be familiar with VPNs, virtual private networks, which create a secure encrypted connection over a less secure network like the internet providing a now private network. And there are a couple of modes of VPN we see commonly used. You'll see transport mode which encrypts only the payload to the IP packet leaving the original IP header intact. Transport mode is often used for clientto-sightVPNs for individual devices such as in work from home scenarios. For this mode, there's two tunnel types. There's the split tunnel where only client traffic destined for the private network goes through the VPN tunnel which is going to be less expensive for the organization, less bandwidth intensive. And then the full tunnel where all network traffic from the user's device is routed through the VPN tunnel regardless of its destination. That's going to give us more control over what's happening with the user's activity on that machine. If we're filtering internet browsing, for example, if we want to keep our users away from dangerous websites, dangerous services, we can use that full tunnel mode. And then there's a second mode called tunnel mode. So in this mode, IPS sec VPNs would encapsulate the entire IP packet and add a new header. Tunnel mode is typically used for sight to-sightVPNs like we would see in a hybrid cloud for example where we're using a VPN concentrator to connect to another VPN endpoint in the public cloud connecting our corporate data center to an AWS or an Azure one of those public cloud service providers. So to picture that for you. So transport mode is common for the client to sight and then when I'm talking about tunnel mode that's for your sightto-sight connectivity common in the hybrid cloud scenario.

Zero trust may come up in discussion. What we're talking about here is an approach to security architecture in which no entity is trusted by default. It's based on three principles. Assume breach, verify explicitly both users and devices, and least privilege access. Zero trust has largely replaced that legacy trust but verify approach where we'd set up a firewall and everything outside the firewall was untrusted and everything inside the firewall was trusted. So that's really been supplanted almost entirely by zero trust. And the network segmentation we talked about a moment ago with VLANs is a common element of a zerorust approach to networking. And zero trust is actually supported by defense and depth. That layered approach to security where we have multiple layers.

All right, that brings us to the end of section 3B2. Let's test our knowledge with a practice question. So, the best way to ensure that security settings on each platform are in compliance with information security policies and procedures is to implement vendor default settings, perform penetration testing, establish security baselines, or link policies to an independent standard. So there are a couple of options here I know are definitely not correct straight away. So implementing vendor default settings means we're not customizing security configuration to our organization. That's always going to be a no no. Performing penetration testing. So penetration testing you aims to exploit weaknesses. That's not going to be the most effective way to ensure that security settings on each platform are in compliance because the scope of that pen test may vary. The skill of that pen tester may vary. We need another way to go about it. Our options that remaining here are establishing security baselines or linking policies to an independent standard. So there's one clear correct answer here and that is establishing security baseline. Of that security baseline gives us best assurance that each platform meets minimum criteria. Hopefully, we can automate the implementation of those security baselines. Penetration testing can only be performed periodically, so it's not going to be as effective. Vendor defaults are a terrible idea because we're not customizing to the org. And while linking policies to an independent standard can give us some guidance, it's not going to give us assurance of compliance and alignment with our organization's standards and requirements.

Moving on to section 3B3, control testing and evaluation. We'll touch on control strength, control recommendations, and testing and modification. So after we implement information security controls, our next step is to evaluate their effectiveness. So the point of that is to ensure that the control keeps risk at an acceptable level in practice as we expected it would in theory. The key takeaway here is we manage risk. We don't eliminate it entirely. A control is reducing risk and leaving us some level of residual risk. So the ongoing evaluation ensures that that over time as our objectives change, as threats evolve, our system updates roll in that our controls remain effective. Our controls must adapt to the evolving environment. But the goal is to maintain cost effectiveness and alignment with business objectives while ensuring those controls are technically effective. And there are several common methods for evaluating controls. So one of those is periodic assessments. Just regularly checking if the controls are working as intended. We can do some ad hoc assessment internally. Audits whether those are internal or external. Getting some independent verification of control effectiveness. Continuous monitoring. So using our tools for nearrealtime checks, especially for technical controls to make sure they're effective on an ongoing basis or penetration testing, simulating real attacks to find hidden weaknesses in our controls in the live environment. And in smaller companies, this might mean bringing in external expertise for that test. In larger orgs, there may be a dedicated role with that skill set.

But control strength speaks to how well a control resists or reduces threats. And a key consideration is balancing inherent design strength with how easily a control can be bypassed in practice. So let's take a look at factors that influence the strength of our controls and how we measure that strength. So certainly answering that question, how do we determine the strength of a control? It may help to group our controls by type, like gathering the preventive controls together and comparing their relative performance to the threats they are designed to block. Detective controls and their ability to identify the latest emerging threats. We could also group by method or category. Maybe batch together our technical controls which would be part of a layered defense. Our administrative controls looking at the policies and procedures we have in place or the physical controls that protect the tangible aspects of our environment. Stronger enforcement though typically means stronger controls. So for example, MFA is stronger than password alone, right? We need to assess the difficulty to circumvent. So in the case of a cryptographic algorithm, we can go out and find industry data that gives us a lot of guidance on which algorithms are best. For example, we can look at the world of symmetric algorithms, bulk data encryption, and we see AES is the industry standard and AES 256, for example, is used at this time anyway to protect the US government's top secret data. But we look at the inherent strength of a control versus its practical strength. So some controls are strong by design like good encryption. However, practical strength can still be weak if the controls are complex or costly and result in workarounds because employees will work around controls that impede their productivity unnecessarily. And we can also look at our controls and their place in a layered approach because we want to combine multiple controls together to develop their collective strength. So we'll combine multiple layers of technical controls. But we have the combination of technical, administrative and physical controls that together provide a complete approach to securing the business and our services. And if one control fails, the others provide backup. But we have to balance the elements here. So we weigh the security benefit against cost, complexity, and impact on usability and operations because certainly just having no security in place means that we're going to maximize usability. So we have to add those controls to reduce the risk while not putting too much impact on usability. The goal is adequate security without excessive burden. So automated does not automatically mean a control is effective. Automated is nice but it's not a guarantee of efficacy. Manual does not automatically mean a control is weak. So, for example, an effective manual control would be trained guards doing random physical security rounds. They're adaptable, hard to predict. They complement technology like fences and locks and cameras. And ineffective automated control. If we force 30-day password changes without complexity rules, users are going to create weak patterns in their passwords. They're going to be frustrated. There's a poor cost benefit ratio here. So at the end of the day, real world performance and balance matter more than just the control type and its inherent strength.

So inherent strength refers to the fundamental robustness or effectiveness of a security control based purely on its design and implementation. It doesn't consider external factors like operational consistency or testing. It represents a baseline capability of a control to mitigate risks effectively. So the likelihood of effectiveness depends on the control environment for one. So a strong organizational culture emphasizing ethics, competence and accountability creates a foundation for effective controls because our users understand their importance and they are open to coexisting with those controls within reason. This includes management's commitment to internal controls and clear assignment of authority and responsibility and consistent implementation. Controls have to be applied uniformly across the organization to prevent gaps in security. So inconsistent application reduces reliability and effectiveness. Testing and monitoring. So regular audits, testing and monitoring using metrics like meanantime to detect and meanantime to respond help identify weaknesses and ensure that controls are functioning as we expect and alignment with business objectives. So controls should support the organization's goals ensuring they are relevant and cost-effective while meeting our compliance requirements and competence of our personnel. The skills and training of our employees are responsible for how effectively controls are implemented and monitored. And so having employees who are competent implement and monitor controls significantly influences their efficacy. If we have employees who don't understand the controls all that well, they're just following steps in a manual, they're more likely to make mistakes, right? Aren't they? And tools and technology. So effective use of upto-date technologies like intrusion detection or breach and attack simulation tools can enhance control performance and independence and objectivity are always important. So independent reviews by internal or external auditors provide an unbiased assessment of control effectiveness. And we think about bias being absent in external auditors but the same can be true with internal auditors. If we have a securityaware culture with executive support of an independent internal audit function who does not uh find themselves on the receiving end of consequences when they make a negative finding of their peers.

So let's talk about common techniques for evaluating control efficacy. So the two that come immediately to mind are penetration testing. So a attack simulation on our systems and applications attempting to exploit the weaknesses in our control. So identifying potentially unknown or underestimated vulnerabilities as well providing dynamic independent evaluation. There's continuous monitoring. So using automated tools for nearrealtime checks of technical controls that could include a vulnerability scanner for example which unlike penetration testing doesn't attempt to exploit a vulnerability. It simply finds those vulnerabilities. But automated tooling like a vulnerability scanner allows rapid detection of changes or failures in our controls. It enables quicker response so we can close the gap before it is proven problematic in practice.

So let's talk about key considerations in control selection. So when we look at our control types, we have preventive and detective. So one stops an attack, the other detects an attack and alerts. We have manual controls and automated control. So people tend to be the manual control automation. So technology tend to be our automated controls. We have formal and ad hoc. So formal controls are documented and ad hoc controls are informal and less wellmanaged. So our preference is going to be for preventive, automated and formal whenever that is possible. So our factors for selection would include effectiveness. Does it reduce risk? Compatibility. Does it fit existing systems and does it fit our layered defense without too much overlap? Compliance. Does it meet legal and policy needs? Organizational fit. Does it suit our culture and strategy? Does it allow our employees to be productivity? Is there organizational impact that affects daily work? Safety and reliability. Does it maintain safe operations or does it put human safety at risk? And measurement. How will success of a control be tracked? How can we be sure of its results?

Let's talk through the flow of the control recommendation process. So certainly it begins with risk assessment which then leads to the risk treatment discussion. So we start with those risk assessment results. We prioritize recommended controls whether they are technical controls or more procedural in nature policies uh procedures physical security. We conduct costbenefit analysis justify expense versus risk reduction. We want to involve the business units to ensure controls are practical and they're aligned with our business needs. So on the exam, make sure that you're familiar with the fact that recommendations generally hinge on the cost benefit aspect of this. You want to avoid controls that kill productivity. We have to find the right balance. So the answer is not always going to be the highest security.

So let's talk about control testing and modification. So why would I modify a control? Well, technology and operations change potentially weakening controls. So, we need periodic testing. So, in some industries, periodic testing is often mandatory like with public companies or in regulated industries. And periodic testing confirms procedures are followed and technical controls work correctly. And change management is important. So a formal process for all controlled changes whether they're policy based or the technical controls themselves. We need to run them through change management so everyone is aware and we have stakeholder approval and we need to analyze changes for any new vulnerabilities. So the security function certainly has to be involved and active in that testing process. We want to ensure that updated controls are resilient, they self-protect, they're failsafe and they are monitorable and we want to perform acceptance testing after changes. So when we put a new security control in place, we'd certainly want to allow for a fresh round of QA and user acceptance testing on applications to make sure that we're not impacting the business in any unexpected way.

So let's talk about the flow for updating our operational procedures. Here we'd want to use the change management process as well. So we can review and update the inputs, steps, approvals, and outputs of any procedures. Coordinate changes with administrators of any related processes or technology that'll be affected. Assess the workload impact. Train staff before roll out. Conduct walkthroughs with the staff after the roll out. and leverage frameworks like Kobit, NIST, ISO 271 to guide our organization in creating a structured process for updating our operational procedures. So some key takeaways here to remember for exam day. So testing frequency be aware of mandated intervals. For example, with PCIDSS or ISO 271 certification, there would be a periodic testing frequency that's built into the uh certification. So, change control modifying any control requires the formal change process and post incident expects scenarios on the exam that would require control updates based on root cause analysis after an incident.

All right, so that brings us to the end of this section. Let's test our knowledge uh with a practice question. So, which of the following is the most important reason to include an effective threat and vulnerability assessment in the change management process? Is it A to reduce the need for full periodic risk assessments? B to ensure that policies are changed to address new threats. C to ensure that information security is aware of changes or D to maintain regulatory compliance. So all plausible answers but here again we have to pick the most important reason. So there are a couple I can see right away I would check off. Though maintaining regulatory compliance is not the most important reason to include an effective threat and vulnerability assessment in the change management process. We need to do this for many more reasons than just regulatory compliance because regulatory doesn't tell us it has to be part of change management. Regulatory just tells us controls need to be in place to meet certain ends such as protecting data privacy. So, so B, ensuring that policies are changed to address new threats. Policies are higher level statements. They're a bit further up the chain than what we're working with here. So, reducing the need for periodic full risk assessment or ensuring that information security is aware of changes. So, including any threat and vulnerability assessment in the change management process definitely involves these two. The most important is to reduce the need for full periodic risk assessments. By assessing threats and vulnerabilities during the change management process, changes in risk can be determined and a risk assessment can be updated incrementally. This keeps the assessment current without the need to go to ground and to do a complete full reassessment. And let me just add a bit of additional explanation here to make sure that makes sense. So, if I was tuning my controls from day to day and not saying anything, maybe I'm the administrator of a network firewall and I'm changing rules as I see threats in the environment. If I keep tuning my firewall, it may be effective. It may be more effective because of those changes I've made, but I've now put potentially multiple changes in place without informing the rest of the organization, without checking to make sure there's no impact to the conduction of business. And so if that were to surface, then we're going to have to perform a complete full risk assessment because we don't know what changes have been introduced into the environment. So by ensuring that every change to controls goes through the change management process, we can update our latest assessment incrementally because we know what's changed in the environment over time.

So let's move on to 3B4 which is information security awareness and training. So we'll talk about training and education, developing our security awareness program and the importance of role-based training and we'll wrap with a talk about training and education metrics. How do we determine that our training is actually effective? So periodic security awareness training and education is meant to mitigate human risk. The problem is that most security incidents involve human error mistakes or a lack of understanding generally. The solution is to make sure we have a robust ongoing awareness and training program with the appropriate level of specificity for our employees. The goal is to embed that security consciousness into the daily tasks in the organizational culture. Set another way, it's to develop a security aware culture, a phrase you've heard before in this series.

So the principles of an effective program are recognizable. We want to connect policies and standards directly to individual job roles and daily tasks. So establishing clarity, ensuring employees understand existing policies, especially new or updated policies. Tailoring content in our training by role or department or both. For example, training end users generally on security awareness like fishing prevention for example but more targeted training for IT operations and management personnel. Consistency. The training has to be continuous starting from onboarding and it has to be recurring. So typically security awareness training will happen maybe two to four times a year for the more general security awareness sessions just to ensure we keep our users up to date. And the reach is important. It needs to include everyone with access to enterprise information. That includes our third party users, those working for our vendors and partners but with access to company data. And personnel tasked with implementing strategy need specific guidance on our critical success factors, the events or elements that must occur to achieve our key goal indicators. And the KGIs are the highle strategy goals and the KPIs, the key performance indicators are the metrics tracking performance and process success. Basically charting our success or lack thereof along the way which can also help us in any course correction. These provide the target the organization is aiming for and the indicators of progress and performance.

An effective awareness program focuses on tailoring content by role or department to ensure everyone understands how their actions can contribute to or jeopardize the organization security posture. We want to educate users on risk reducing behaviors. So common topics might include password security best practices, appropriate use of computing resources, safe email and web browsing habits, recognizing and reporting social engineering. In fact, I like to train my users in general security awareness training about the characteristics of social engineering so they're better able to recognize it. Relevant policy, standards, and procedures. So ideally you have a requirement in the organization that users for example read the acceptable use policy and they sign it. It doesn't hurt to reinforce it through your periodic security awareness training. Emerging threats. We know that the email channel is the number one delivery channel for ransomware attacks. So keeping employees up to date on the types of attacks they are likely to see. Understanding that no email filtering software is perfect will serve us well. We want to train users when and how to escalate suspicious activities because users are our first line of defense. And that's where establishing an open and accepting security culture. If you see something, say something. And if you think you've accidentally done something, potentially clicked on a malicious email or visited a bad website and think you're infected, bring it to us so we can help. We're here to advise, not to judge. And I think that sort of open dialogue where we leave room for users to make mistakes and seek help without retribution very important in developing that security aware culture.

So let's talk about considerations when you're developing and implementing your training program. You always want to consider your audience. The rolebased training you deliver to management functions is going to be different than you deliver to IT staff and different still from broader training that you might deliver to a larger enduser audience. The message needs to focus on policies, procedures, relevant events and updates role specific where we can. The outcome is to aim for policy compliance, behavior change, adoption of best practices. We want to reduce risk in user behavior and to choose appropriate delivery. So I I do love live events for the general security awareness training once a quarter, but when a user fails a fishing simulation, for example, that's a great opportunity to direct them in real time to a short computer-based training module to refresh their skills and their recognition of fishing messages. For certain department specific training. Um, a meeting might be more appropriate or we may put on demand training out on our internet. And culturally speaking, we want to align the content and the tone with the organizational structure and culture. And if we don't have a great open security culture, then let's make our training something that would be appropriate for an open security culture. And you want to use a variety of methods to raise employee awareness. So that computer-based training is nice for busy employees that need to train on their own schedule. Email reminders and tips we can often drive from that computer-based training. And published policies and procedures. It's a great idea that we keep those policies and procedures refreshed. I like to refresh policies at least once a year by best practice. And when we update an acceptable use policy, we need to communicate that out to our employee base and make sure they read, sign, and accept those changes. Sign NDAs where appropriate. Newsletters, web pages, videos, posters, login banners, you know, particularly when it comes to things like physical safety. Posters in the breakroom are a great idea. A newsletter to communicate out anything broadly company specific that's not related to the normal security training that we deliver. Visible enforcement of rules and that means communicating policies and enforcing those policies when users step out of line. For example, if our policy says computer equipment owned by the organization can only be used for company business, then we have some sort of tiered policy to reinforce to communicate to the user when they break the rules. That may begin with a verbal reprimand, for example, just a nice verbal reminder, and it might escalate from there if we see repeated unauthorized or negative behavior. Uh simulated incidents, a fishing test, fishing simulation should probably be happening every month in every organization and rewards for reporting suspicious activities. That see something, say something program can be supplemented with some little rewards, you know, maybe a gift card or something of that nature when somebody reports a significant activity and security responsibilities in job descriptions and performance reviews. As we're developing that security aware culture where everybody takes responsibility, building it into the job description is a great idea.

So role-based training is a critical component because it provides employees with context necessary for their specific role. So all personnel get the general security awareness training. Your executives leaders and managers get training on risk appetite and tolerance setting the the tone in terms of our security program ethical leadership program support within enterprise risk management. So our business leaders who are no doubt great business people may benefit from some leadership focused training on how to better address risk in our organization and how to develop a security aware culture organizationwide based on the tone they deliver from the top roles with elevated privileges. So safeguarding critical assets understanding heightened responsibilities and consequences. So this is going to be training common for our IT admins who will elevate their privilege when necessary for certain activities and maybe in other departments as well where they're working with sensitive information and sensitive operations. Physical security personnel, so those protecting physical assets, managing environmental factors for confidentiality, integrity, and availability and frequency. So some roles need more frequent updates due to high-risisk tasks or compliance. So that would certainly be true in the healthcare space with HIPPA or PCIDSS with folks in positions around credit card data and processing equipment. And our training program isn't complete without a systematic approach to measuring training effectiveness. So we want to make sure we track who receives training and there needs to be a metric for that. Ideally 100% of our employees get that general security awareness training and the essential role-based security training competence some sort of grading. We want to assess that our users understand. This tends to be easier with computer-based training that you can have a quiz at the end of each module to make sure that you can assess that they understood, they comprehended what they were reading or watching and send them back to repeat where they did not. It's going to be a little easier with a learning management system of some sort where we can create, deliver, track, report, monitor, uh, and and measure our compliance and support some level of continuous improvement. In fact, some of your LMS, your learning management systems give you a way to plug in training from third parties if you don't want to develop it yourself. But the goal is to verify effective delivery, identify improvements over time, and ensure ongoing compliance with company policies and any regulations. And a success indicator over time we should see in our metrics improving security behavior, fewer incidents, lower fishing clicks, quicker reporting.

All right, it brings us to the end of 3B4. Let's test our knowledge or the question. Which of the following is the best indicator that a security awareness training has been effective? Is it A employee sign to acknowledge the security policy? B more incidents are being reported. C no incidents have been reported in 3 months or D a majority of employees have completed training. And here again we have four good answers but we're asked for the best indicator. So let's eliminate a couple here. Uh there are a couple of obvious eliminations here. Obvious wrong answers. So employees signing to acknowledge the security policy has nothing to do with the efficacy of our training, their comprehension of what we've taught them. And likewise, a majority of employees have completed training. Again, no indicator that the training was effective, just that it was completed. So the options are B more incidents are being reported or C no incidents have been reported in 3 months. One of these is objectively better than the other. Which do you think it is? The answer is B. More incidents are being reported. That's likely an indicator that the staff is paying more attention to security. Now no recent security incident does not reflect awareness levels. We might just be getting lucky. It would actually require additional research to determine for sure.

That brings us to section 3B5, management of external services. So here we'll focus on our third party relationships, our service providers, outsourcing challenges, important clauses to put into our outsourcing contracts and managing access from third parties into our organizations resources like sensitive data. So third party relationships can provide obvious benefits filling skills gaps on our staff giving us additional capabilities but we have to manage the associated risks in alignment with stakeholder objectives. So we know that businesses are increasingly using external partners, public cloud providers, hosting providers, outsourced operations like we see the security operation center outsourced to a managed security service provider function quite often these days. And the risk there is it creates an extended supply chain that requires security and regulatory focus. So the goal is to balance third party benefits with risk management. So we're in alignment with the risk appetite of the organization and at the end of the day you can outsource the task but never outsource who has ultimate responsibility for security. Accountability remains with the organization.

So let's talk about challenges when managing external service providers and vendors. So certainly cultural differences impacting security practices can come into play. There may be technology incompatibilities. Maybe they're using a different set of tools and maintaining consistent security is going to be challenging for one reason or another. Uh misaligned security processes or baselines. Maybe their risk appetite is a bit different than ours and so we need to bring that into alignment. But weak or inconsistent capabilities in critical areas like incident response, business continuity planning and disaster recovery are all potential areas of risk we need to look out for as we are managing those third party relationships and selecting our vendors. So how must security engage with these external service providers and vendors? Well, we need to assess potential third party failures and their impact on the business. Need to plan to manage and mitigate these impacts to acceptable levels. Need to formalize the security manager's risk role through policies and standards. We need to have a close relationship with a bridge between the organization and that service provider from a security perspective. Need to mandate security involvement before establishing new thirdparty relationships. So we have to assess the security posture of that vendor before we allow them to be onboarded formally as a vendor and create a clear engagement model for security interaction with procurement and vendor management teams. So when dealing with thirdparty service providers, we have to consider a few things. You know, our core needs as an organization, key actions and complexity factors with this relationship. So in terms of core needs, know where your data is and who can access it. We need to secure assets everywhere and that includes when they're externally available. So security extends outside the company to every vendor in our supply chain. And there are key actions an organization needs to focus on when dealing with thirdparty service providers. So before that contract is finalized, we need to establish controls, assess the risk of the function, the

provider, the outsourcing itself, perform our due diligence to make sure we have alignment in terms of security posture and we'll include risk clauses in the contract as well. So we're going to protect the organization in every way we can.

So during the process, during that relationship, we're going to manage our day-to-day risks and reassess the situation anytime significant changes occur. So if we have a change in the process, we may need to reassess the security controls around that relationship and the levels of access. And when the relationship comes to a natural conclusion, we need to make sure we follow a proper offboarding procedure which would include returning any equipment or data or data destruction and then of course timely removal of their access.

And let's talk about the complexity factor. So certainly risk increases with criticality. So vendor risk has to stay within the organization's tolerance level. And we'll use contracts to help with that. Contracts bridge the gap. You specify the controls, the provider implements them. And in regulated industries, we may need specific compliance language in our contracts. But we need to make sure we have alignment not only with the organization's risk appetite and security posture, but also with regards to our regulatory compliance obligations. And then risk management's going to evolve as the business needs evolve and potentially impacts that relationship and necessary changes there that we have to reassess. And we always want to plan an exit strategy from the very beginning. We have to avoid vendor lock to make sure that if we need to separate from this vendor that we can do so in a timely way without business interruption.

So outsourcing comes with challenges that the organization has to focus on with regards to these third parties. So transparency issues for example, it's hard to see an external service provider's internal controls. It's one thing for them to tell us that they have controls in place, but we don't necessarily have the visibility to prove it. So we can put strong SLAs's in our contracts that specify required protection levels like ISO 271 or SOCK 2 compliance, right to audit clauses or ondemand reports like a sock 2 type 2 which would be common with a public cloud provider. clear incident response protocols and business continuity and disaster recovery requirements so we don't have an impact to our business if there's an impact to the vendor contracts have to align the provider's processes with the organization's regulatory needs for example if the organization is subject to GDPR if we have a data breach at the third party provider then they would need to report the incident to us in a timely manner considerations providers There's financial stability, cultural and ethical alignment, potential loss of internal skills. So, if we're outsourcing a function to a third party provider, any in-house skills we have in that area might atrophy, hidden cost or service limits that would affect our budget estimates, privacy laws, and crossber data transfer rules. We want to make sure we know where our thirdparty provider employees, their staff are located and that they are onshore. So there are definitely types of protected data that cannot be accessed by offshore personnel. Provider staff awareness. We need to make sure that the staff from the third parties working with our organization go through our security awareness training where necessary. And in addition to vendor self attestation and contractual SLAs's, asking for a vendor's last external audit or penetration test also provides assurance. There's nothing wrong with doing that. I do that as a matter of common practice.

So key takeaways here when dealing with third parties, remember at least these tips for the exam. Contracts using strong SLAs's, data protection clauses, and audit rights are going to be important. And again ask for that last external audit as a higher level of assurance regulation. Know your industry specific rules, your regulatory obligations so you can make sure you don't run a foul of those with your third party relationships. If you're in the financial services space or healthcare, you definitely are in a regulated industry. There are going to be some rules that apply to you and to vendors accessing your sensitive data. and plan for vendor failure or breach scenarios. Make sure you know how you're going to maintain business continuity if you have a failure at one of your third parties.

Next, we'll talk outsourcing contracts which are the foundation that ensure mutual understanding of roles and rights between the organization and service providers. It really serves as a framework for resolving issues with our vendors. So some key security provisions we'd expect to see in that contract would include confidentiality agreement or an NDA and that would include provisions on how data is handled, returned, destroyed, security controls. We might define appropriate controls with reference to sock reports or the ISO 27,000 standards. Network connectivity, specifying security mechanisms, firewalls, monitoring, VPN, right to audit, so defining scope, frequency, notice, cost. We might even specify unannounced audits for high-risisk vendors. Equally common is asking a vendor for their last external audit. So we can take a look at that and see if the scope is sufficient to answer our questions with your cloud service providers, your Amazon's, Azures and Google cloud platforms. Typically they offer ondemand reports like the sock 2 type2 or the ISO271. Incident response defining roles notification remediation and timelines for breaches. Indemnity ensuring compensation for provider failures. You do want to watch for liability caps, making sure that when a provider falls short that we can claw back some of the fees and some of the damage that may have been done to us. And choice of law. It's quite common that you'll specify the jurisdiction where any legal disputes will be settled. So if the organization is a Delaware corporation, then typically you would specify Delaware as your jurisdiction, for example. Other areas we might address in our contract clauses would include service specifications, data handling limits, access controls, ensuring lease privilege, for example, uh incident response or business continuity details, service quality or what we'd more commonly call quality of service, vendor employee NDAs, data ownership, and offboarding specifics.

And that brings us to the end of section 3B5. Let's test our knowledge with a practice question. Which of the following should be done first when making a decision to allow access to the organization's data center facility to a new external party? A risk assessment, the exposure factor, vendor due diligence or a contract language review. So which should be done first and first is the key word there. So there are two we can knock off right away. So a contract language review that's going to come further on in the process where we're digging into the details of the agreement. So at that point we've already done some vendor due diligence for sure and the exposure factor. So exposure factor is a phrase you'd hear when we're talking about risk assessment where we're dealing with a specific uh asset threat pair. So the focus of that is a little too detailed as is the focus of a contract language review. So we're thinking about allowing a vendor into our data center facility. So our focus here is more expansive. And our options remaining are a risk assessment makes good sense and vendor due diligence. So, which of these is the best answer? And there's an objective correct answer here. And the answer is a a risk assessment. The risk assessment identifies the risks involved in allowing access to an external third party and the required controls. All the other options on that list could actually be part of the risk assessment. And the risk assessment itself is an act of due diligence.

That brings us to section 3B6 where we're talking through information security program communications and reporting. So we'll touch on various aspects of program management evaluation review compliance monitoring performance measurement and reporting. And we'll touch on the plan do check act cycle. So let's start with communication and reporting responsibilities of the information security manager. So the purpose of program communication is to keep senior leaders, regulators and stakeholders informed. We want to make sure our senior leadership is aware of our progress in delivery of program objectives, any change in current risk status as well as any opportunities for improvement we've identified. The importance here is just keeping leaders informed to avoid any legal or financial liability due to unknown risks and to give them the information they need to make good decisions both financial and strategic. And the manager's role is to use reporting to fulfill business case promises, to show strategy success through relevant, measurable, actionable metrics, and to update on monitoring and emerging risks.

So when should the managers evaluate the current state of the existing security program? Well, as to the when, it's when we're entering a new org or the org needs a change and we want to assess the current security programs state. And the action here is to share our evaluation with the steering committee and shareholders to decide on needed changes. So essentially, if you're taking on that role of information security manager in a new organization, assessing the existing security program, going through this evaluation is going to be a great opportunity for you to familiarize yourself with the program in place and determine what deficiencies you see and any changes that are needed, which you can then communicate to your senior management. Great way to start your role and showing management you know what you're doing. And when you're evaluating the current state of the existing program, the information security manager needs to consider the strategy and roadmap. So checking for any documented strategy, roadmap or established risk criteria and impact thresholds that's been documented already. That's our starting point. We want to look at policy standards and procedures. verify they're current, complete, measurable, realistic and updated collectively. And then alignment and review. So confirming alignment with governance, organization initiatives, compliance, ensuring regular management reviews occur, and then having a look at the metrics, ensuring KPIs are defined and regularly reviewed.

Now one measure of a security program's maturity is how well it meets regulatory and internal compliance needs. So the level of compliance uh you know is really looking to see as management determines how much compliance the enterprise will undertake with relevant timelines and milestones for hitting those objectives. And then integration are compliance requirements clearly defined and integrated into policy standards, procedures and success metrics, but they need to be defined and integrated and documented. And then alignment of course, do the technical, operational and managerial components align with regulatory standards? And when we look at auditing and tracking, what do recent audits reveal about our compliance position? Are deficiencies tracked, reported, and resolved in a timely way? And our compliance management technologies leveraged for efficiency, not required, but helpful in progressing more quickly. So evaluating program management helps gauge the breadth of the program and the extent of management support. So ensuring thorough program documentation and accessible operating guidelines exist. Without documentation, there are going to be a lot of questions and high potential that when obligations are not met, when core operational tasks are overlooked, there's going to be a lot of fingerpointing. roles and responsibilities verifying clear definition and understanding especially at the executive level. We want to check if it's included in manager objectives so everybody knows who's responsible for what authority and oversight confirming accountability sufficient authority and visibility and formal steering committee guidance. But it's all about accountability. If we don't have clear accountability defined then nobody's accountable. administration. So checking for effective budgeting, financial, HR, and knowledge management, making sure we have those administrative resources in place and metrics and review, ensuring meaningful metrics are collected, relevant, measurable, actionable, and they're reported and management regularly reassesses effectiveness of the program and the metrics used to measure.

So the information security manager also must evaluate how effectively the program carries out day-to-day operations. From a day-to-day effectiveness perspective, we want to assess execution within the security team as well as across business units and make sure that security is integrated into technical and business standard operating procedures with clear accountability and documented procedures. We want to make sure that those standard operating procedures are documented for configuration and access management, system maintenance, event analysis, incident response. We want to make sure that tasks are logged and tracked as they're carried out and that separation of duties is enforced so we don't have one person with too much control across a process from end to end. and reporting. Ensuring effective operational, tactical and strategic metrics, reporting and clear escalation paths exist when those metrics indicate a problem.

So managing the technical environment ensures that security mechanisms and processes are appropriately implemented. So control implementation verifying correct implementation of security mechanisms and processes from a technical perspective checking for standards covering configuration whether that's network system or application and architecture that we have clear topology protocols and compartmentalization or segmentation laid out in our standards implementation and monitoring. So confirming continuous monitoring of key controls that there are failure notifications in place and separation of development test and production environments. And from a logging and life cycle management perspective, making sure we have reliable logging infrastructure in place and secure decommissioning processes to prevent data leakage.

And the information security manager must also assess whether the program's current financial, human, and technical resources are sufficient. This would be really important when you're stepping in to manage a program as a new information security manager. So checking to make sure the financial, human, technical resources are all at a level that will allow the program to be successful. And if not, we identify the gaps and we escalate those shortfalls to our senior management so we can request resources and justify where necessary. From a financial perspective, verifying we have a comprehensive budget linked to business goals and identifying any underfunding risks. From a human perspective, checking workload management, making sure that everybody is shouldering a manageable workload, that our employees have adequate skills to do the job competently, we have training resources available to them. We're going to make sure that we use delegation effectively to spread that workload and use automation wherever we can, such as in implementation of security control baselines as we discussed earlier in this session. And from a technical perspective confirming supporting technologies, sufficient and scalable capacity that we have life cycle planning in place for maintenance updates and replacement of aging equipment and other resources. The key takeaway here, program evaluation is like a security program health check. Any gaps or shortfalls should be escalated to senior management.

So let's talk about the plan do check act cycle. So information security management closely aligns with total quality management philosophies and we see this surfaced in the iterative four-step PDCA cycle. So it starts with plan. So design, plan and initiate the security program strategy policies objectives and risk management. And then the doing, execute and maintain the strategy by integrating it into routine organizational practices. And then in the check phase, monitor, audit and review program effectiveness and use metrics and performance indicators to gauge success. What do we say about our metrics? Relevant, measurable, actionable. And then act. Here we address findings from audits and risk assessments. and we create corrective, preventive, and continuous improvement actions. And then we're going to present recommendations and resource requests to management for decision. So if we look at PDCA visually, basically input from our stakeholders goes into that plan phase and reporting to stakeholders comes out of the check phase because as we're going to act, we want to first get appropriate approval and we might need additional resources.

Next, let's talk security reviews and audits. So standardized assessments provide trend and performance data. We have quite a few options here. But we want to look at the components of any given approach to understand its objective, its scope, its constraints, the approach and result. Common types of assessments we have control self assessments which would be focused on security controls, architecture reviews, spot checks where we might look at a very specific area of the environment. Audits are more formalized and generally going to be broader in their scope and that would test controls against objectives potentially against our policies or standards like CO or ISO and audits may be internal or external. In either case, they should be independent and unbiased. Then we leverage those findings to improve the program and gain management support for our efforts and our recommendations for improvement. And it always pays to maintain a good relationship with your auditors, especially that external auditor. Their feedback is very important. And when we have maybe a disagreement on that report, perhaps a finding for which the auditor doesn't appreciate that you have another compensating control in place, it pays to to be able to have a conversation with that auditor. And if there's a friendly relationship and some trust there, you can get the necessary adjustments on that report without a lot of trouble.

So compliance enforcement should be integrated early in the program to ensure clear accountability and to minimize rework and cost. Much like all aspects of security, we've talked about shifting left where we integrate into the full life cycle from the beginning. It just makes everything less disruptive, less laborious, and less costly. So there's policy compliance where we ensure policies define responsibilities, cover all systems. We have periodic reviews in place and formal riskbased exception processes. Standards compliance very similar. We want to make sure that standards operationalize policy. We use automation where possible. And we also have those formal riskbased exception processes. And how do we resolve non-compliance? We want to make sure that we track, prioritize, assign responsibility, and follow up. We address findings from monitoring from our audits, from our vulnerability scans in a timely fashion based on the risk they present. So when we have a vulnerability scan with those high severity findings, we want to address those quickly. For example, if validation of a compliance process like encrypting sensitive data before sending reveals we have a violation, perhaps Bit Locker is not enabled on a workstation, it's going to trigger corrective measures in our process.

So monitoring is how we ensure that our controls are operating as intended. There are a number of methods we can employ here, but continuous monitoring should be in place. So ongoing checks with real time or nearrealtime alerts so we can respond quickly to potential issues. Risk assessments. So regular vulnerability identification and remediation trend tracking. So penetration testing and scanning. We can perform scans internally or externally. And we want to track all vulnerabilities, but we want to pay special attention to repeating vulnerabilities, especially those that we believe were reported remediated in the previous scan and they've popped up again. We need to trace down the reason for the regression. Metrics and response, making sure we have escalation procedures and rapid response capability in place. It's not uncommon in organizations that are not terribly well organized that they put the monitoring in place and then from an operational perspective, it's basically ignored. The monitoring is sitting there with nobody at the controls.

So let's talk about key areas to measure. So risk and loss management, looking at our vulnerabilities, our incident metrics, looking at our risk, our annualized loss expectancy and what that trend looks like. Supporting organizational goals, making sure we have alignment between security and business goals and we have consensus of that alignment. compliance, adherence to compliance, resolution of any deviations, operational productivity, making sure we're using tools efficiently and employing automation where we can to maximize the consistency and the implementation of our controls and reducing manual effort. So cost effectiveness, making sure that that our TCO is in line with expectations, that we're using our budget as effectively as possible, that we have that cost benefit ratio within limits. Organizational awareness, training effectiveness, analyzing, identifying, and closing any gaps. technical security architecture, the effectiveness of our controls, making sure that we have metrics in place that demonstrate our controls are indeed as effective as we expected and management framework and resources. So measuring our process maturity and effective use of resources and finally operational performance. We can track our incident response and patch times and see the reports from our change controls. How many are successful? How many failed or resulted in impacts? We talk quite a lot about change management and change control being important. It's not often we mention the reality that even with that process in place, if the change control doesn't properly govern our change process, incorporating good reporting on the test results before implementation, we can have changes that cause problems and ongoing monitoring and communication.

And so the security manager has to ensure regular reliable communication of program status and emerging risks to the program stakeholders. So centralized monitoring a security operation center with defined severity and escalation procedures event analysis and response trained staff procedures trend analysis happening using relevant measurable and actionable metrics. Real time versus detective control. So real time controls give us rapid response capability. Detective controls give us more root cause after the fact. Management assurance providing summaries and actionable insights to our stakeholders. But the goal here is clear objectives, continuous monitoring and evaluation and effective communication. That's a robust security program. It manages risk. It meets compliance and it aligns with business goals and the information security manager is right in the center orchestrating all of this activity.

Let's put what we learned to the test with a practice question. So as an information security manager, you would like to lay down clearly defined roles and responsibilities. What is the most important benefit that you expect from this activity? Is it A ensure that all your team comply with policies? B your team is more accountable, C your team knows what to do and when or D everyone is clear about their responsibilities. So what is the most important benefit you would expect from clearly defined roles and responsibilities? All plausible answers. Two here we can definitely rule out. Ensuring that your team complies with policies is not a relevant benefit to laying out roles and responsibilities. Whatever their role and responsibility, we expect them to comply with policies. Not our goal here. D. Everyone is clear about their responsibilities. That is true. That is a benefit of this. It's not the most important. So, we have two very important top level benefits here. Your team knows what to do and when. Very important. or your team is accountable also very important. Which of these is the most important? The answer is B. Your team is more accountable. So well-defined roles and responsibilities provides clear visibility into who is responsible and accountable for a given function, control process or risk. Accountability cannot be transferred and it is a question we must always know the answer to.

All right, my friends. That's what I have for you for domain 3 part B. I hope you're getting value from this series. As always, if you have questions, drop them in the comments or reach out to me on LinkedIn. Expect the first installment of Domain 4 in just the next few days. And until next time, take care and stay safe.