Ahoy! and welcome to another episode of CISO Tradecraft -- the podcast that provides you with the information, knowledge, and wisdom to be a more effective cyber security leader. My name is G. Mark Hardy, and today we’re going to -- talk like a pirate. ARRR

As always, please follow us on LinkedIn, and make sure you subscribe so you can always get the latest updates.

On today’s episode we are going to talk about the 9 Cs of Cyber Security. Note these are not the 9 Seas that you might find today, the 19th of September, which happens to be the 20th annual International Talk like a Pirate Day. They are the nine words that begin with the letter C (but not the letter ARRR):

Controls,
Compliance,
Continuity,
Coverage,
Complexity,
Competency,
Communication,
Convenience,
Consistency.

Please note that this talk is inspired by an article by Mark Wojtasiak from Vectra, but we have modified the content to be more aligned with our thoughts at CISO Tradecraft.

Now before we go into the 9 Cs, it’s important to understand that the 9 Cs represent three equal groups of three. Be sure to look at the show notes which will link to our CISO Tradecraft website that shows a 9-box picture which should make this easier to understand. But if you're listening, imagine a three-by-three grid where each row corresponds to a different stakeholder. Each stakeholder is going to be concerned with different things, and by identifying three important priorities for each, we have our grid. Make sense? Okay, let's dig in.

The first row in our grid is the focus of Executive Leaders. First, this group of executives such as the CEO, CIO, and CISO ensure that the IT controls and objectives are working as desired. Next, these executives want attestations and audits to ensure that compliance is being achieved and the organization is not just paying lip service to those requirements. Thirdly, they also want business continuity. IT systems must be constantly available despite attacks from ransomware, hardware failures, and power outages.
The second row in our grid is the focus of Software Development shops. This group consists of Architects, Developers, Engineers, and Administrators. First, they need to ensure they understand the Coverage of their IT systems in asset inventories -- can we account for all hardware and software. Next, developers should be concerned with how Complexity in their environment can reduce security, as these tend to work at cross-purposes. Lastly, developers care about Competency of their teams to build software correctly; that competency is a key predictor of the end quality of what is ultimately produced.
The third and final row in our grid is the focus of Security Operations Centers. This group consists of Incident Handlers and Responders, Threat Intelligence Teams, and Business Information System Officers commonly known as BISOs. They need to provide clear communication that informs others what they need to do, they need processes and tools that enable convenience so as to reduce friction. Finally, they need to be consistent. No one wants a fire department that only shows up 25% of the time.

So now that we have a high-level overview of the 9 C’s let’s start going into detail on each one of them. We'll start with the focus of executive leaders. Again, that is controls, compliance, and continuity.

Controls- According to James Hall's book on Accounting Information Systems[i], General Computer Controls are "specific activities performed by persons or systems designed to ensure that business objectives are met." Three common control frameworks that we see inside of organizations today are COBIT, COSO, and ITIL.

COBIT®, which stands for The Control Objectives for Information Technology was built by the IT Governance Institute and the Information Systems Audit and Controls Organization, better known as ISACA®. COBIT® is primarily focused on IT compliance, audit issues, and IT service, which should not be a surprise given its roots from ISACA® which is an Audit and Controls organization. Overall, COBIT® 2019, the latest version, is based on the following six principles[ii] (note that the prior version, COBIT® 5[iii], had five):

Provide stakeholder value
Holistic approach
Dynamic governance system
Governance distinct from management
Tailored to enterprise needs
End-to-end governance system

COSO stands for The Committee of Sponsoring Organizations of the Treadway Commission. Their latest version is the 2017 Enterprise Risk Management - Integrated Framework, which is designed to address "enterprise risk management and the need for organizations to improve their approach to managing risk to meet the demands of an evolving business environment.[iv]" COSO states that internal controls are a PROCESS, effected by leadership, to provide reasonable assurance with respect to effectiveness, reliability, and compliance[v]. The framework consists of five interrelated principles[vi]:

Governance and culture
Strategy and objective-setting
Performance
Review and revision, and
Information, communication, and reporting

To support these principles, COSO defines internal controls as consisting of five interrelated components:

1. 1. Control environments,
  2. Risk Assessments,
  3. Control Activities,
  4. Information and Communication, and
  5. Monitoring Activities.
2. The third framework is ITIL®, which stands for Information Technology Infrastructure Library. First published in 1989 (the latest update is 2019/2020), ITIL® is managed and maintained by AXELOS, a joint venture between the Government of the United Kingdom and PeopleCert, which acquired AXELOS in 2021. According to their website[vii], "ITIL 4 is an adaptable framework for managing services within the digital era. Through our best practice modules, ITIL 4 helps to optimize digital technologies to co-create value with consumers, drive business strategy, and embrace digital transformation." (Talk about buzzword compliance). ITIL® 4 focuses on process and service management through service strategy, service design, service transition, service operation, and continual service improvement. What is interesting is that there is no third-party assessment of ITIL® compliance in an organization, only individual certification.
  At the end of the day an organization needs to pick one of these popular control frameworks and show controls are being followed. This isn’t just a best practice; it’s also required by Sarbanes Oxley. SOX has two sections that require control attestations that impact cyber. Section 302 requires corporate management, executives, and financial officers to perform quarterly assessments which:
  1. Evaluate the effectiveness of disclosure controls,
  2. Evaluate changes in internal controls over financial reporting,
  3. Disclose all known control deficiencies and weaknesses, and
  4. Disclose acts of fraud.
  Since financial services run on IT applications, cybersecurity is generally in scope for showing weaknesses and deficiencies. SOX Section 404 requires an annual assessment by both management and independent auditors. This requires organizations to:
  1. Evaluate design and operating effectiveness of internal controls over financial reporting,
  2. Disclose all known controls and significant deficiencies, and
  3. disclose acts of fraud.
  4. Once we understand the requirements for controls, we need to be Compliant. Compliance is the second C we are discussing today. Remember the CFO and CEO need to produce annual and quarterly reports to regulators such as the SEC. So, if you as a CISO can help them obtain a clean bill of health or fix previous audit findings, you help the business.
  A useful tool to consult in terms of compliance is a concept from the Institute of Internal Auditors known as the three lines model or three lines of defense[viii]. This model has as a foundation six principles:
  1. Governance
  2. Governing body roles
  3. Management and first- and second-line roles
  4. Third line roles
  5. Third line independence, and
  6. Creating and protecting value
  The first line of defense is the business and process owners who maintain internal controls. You can think of a software developer who should write secure software because there is an IT Control that says so. That developer is expected to run application security scans and vulnerability scans to find bugs in their code. They are also expected to fix these issues before releasing to production.
  
  The second line of defense are elements of an organization that focus on risk management and compliance. Your cyber team is a perfect example of this. If the developer doesn’t fix the application vulnerabilities before sending code to production, then the company is at risk. Cyber teams generally track and report vulnerability findings to the business units to ensure better compliance with IT controls.
  
  Finally, the third line of defense is internal audit. Internal audit might assess an IT control on secure software development and say we have an issue. The developers push out bad code with vulnerabilities. Cyber tells the developers to fix, yet we are observing trends that the total vulnerabilities are only increasing. This systemic risk is problematic, and we recommend management comply with the IT controls by making immediate fixes to this risky situation.
  
  Now, other than the observation that the ultimate line of defense (internal auditors) is defined by the Institute of Internal Auditors (no conflict of interest there), note that internal auditors can report directly to the board. Developers and CISOs typically cannot. One of the most powerful weapons in an auditor's toolbox is the "finding." The U.S. Code defines what represents a finding[ix] in the context of federal awards, to include:
  - Significant deficiencies and material weaknesses in internal control and significant instances of abuse
  - Material noncompliance with the provisions of Federal statutes or regulations
  - Known questioned costs, specifically identified by the auditor, greater than $25,000 for a type of compliance requirement
  Internal auditors have both a mandate from and access to the board to ensure that the organization meets compliance requirements. So, if you've been unsuccessful in getting funding for what you consider a critical security asset, maybe, just maybe, you casually point that out to the auditors so that it ends up in a finding. After all, findings get funded. Don't get caught, though, or you'll have some explaining to do to your boss who previously turned you down.
  1. Management cares a lot about Continuity. Remember, if the business is down, then it’s not making money, and it's probably losing money by the hour. If the business isn’t making money, then they can’t pay for the cyber department. So, among your goals as a cyber executive is to ensure the continuity of revenue-generation services. To start, you must identify what those activities are and find ways to protect the services by reducing the likelihood of vulnerabilities found in those systems. You also need to ensure regular backup activities are occurring, disaster recovery exercises are performed, Business Continuity Plans are tested, and tabletops are executed. Each of these activities has the potential to identify gaps which cause harm to the continuity that executives care about.
  How do you identify revenue-generating elements of the business? Ask. But do your homework first. If you're a publicly traded company, the annual report will often break out lines of business showing profit and loss for each. Even if it's losing money today, it still may be vital to the organization. Think, ahem, about your department -- you're probably not making a profit for the company in the security suite, but your services are definitely important. Look at the IT systems that support each line of business and assess their criticality to the success of that business component. In today's digitized workplace, the answer will almost always be "yes," but since you don't have unlimited resources, you need to rack and stack what has to be protected first. A Business Impact Analysis, or BIA, involves meeting with key executives throughout the organization, assessing the importance and value of IT-supported business processes, ranking them in the order in which they need to be assured, and then acting on that knowledge. [I thought we had done an episode on BIA, but I checked back and couldn’t find one. So, expect to learn more about that in a future episode.]
  
  Backups and disaster recovery exercises are a must in today's world of ransomware and surprise risks, but make sure that you're not just hand-waving and assuming that what you think is working really is working. Do what I call "core sampling" -- get with your team and dig way down until you reach some individual file from a particular date or can observe all logs collected for some arbitrary 5-minute period. It's not that that information is critical in and of itself, but your team's ability to get to that information quickly and accurately should increase your confidence that they could do the same thing when a true outage occurs.
  
  Lastly, tabletop exercises are a great way to ensure that your team (as well as others from around the organization, up to and including senior leadership) know what to do when certain circumstances occur. The advantage of tabletops is that they don't require much time and effort from the participants to go through emergency response procedures. The disadvantage of tabletops is that you risk groupthink when everyone thinks someone else took care of that "assumed" item. Companies have been caught flat-footed when the emergency diesel generator doesn't kick in because no one in the tabletop tests ever thought to check it for fuel, and the tank was empty. Things change, and there's nothing like a full-scale test where people have to physically go to or do the things they would in a true emergency. That's a reason why kids in school don't discuss what to do in a fire drill, they actually do what needs to be done -- get out of the building. Be careful here you don't have a paper tiger for a continuity plan -- it's too late when things start to come apart to realize you hadn't truly done your homework.
  
  Those are the three Cs for executives -- controls, compliance, and continuity. Now let's move on to developers.
  
  If you remember, the three Cs for developers are coverage, complexity, and competency.
  1. Developers need to care about Coverage. When we talk about coverage, we want to ensure that we know everything that is in our environment. That includes having a complete and up-to-date asset inventory, knowing our processes are free from security oversight, as well as ensuring that our security controls are deployed across all of our potential attack surfaces. "We've got your covered" is usually considered reassuring -- it's a statement that someone has thought of what needs to be protected.
  Specifically, our technical team members are the only ones who can generally tell if the IT asset inventory is correct. They are the ones who run the tools, update the agents (assuming we're not agentless), and push the reporting. If the scanning tools we use are missing hardware or software, then those gaps represent potential landing zones for enemy forces. The Center for Internet Security's Critical Controls start with these two imperatives. Essentially, if you don't know what you have, how can you secure it?
  
  Knowing our processes is key. For developers today, it's much more likely that they're using a DevOps continuous integration / continuous delivery, or CI/CD process, rather than the classic waterfall methodology. Agile is often an important part of what we do, and that continuous feedback loop between developer and customer helps to ensure that we cover requirements correctly (while being careful to avoid scope creep.) Throughout our development cycle, there are numerous places where security belongs -- the art we call DevSecOps. By putting all of our security processes into version control -- essentially automating the work and moving away from paper-based processes, we create a toolchain that automates our security functionality from pre-commit to commit to acceptance to production to operations. Doing this right ensures that security in our development environment is covered.
  
  Beyond just the development pipeline, we need to cover our production environment. Now that we've identified all hardware and software and secured our development pipeline, we need to ensure that our security tools are deployed effectively throughout the enterprise to provide protective coverage. We may know how many servers we have, but if we don't scan continuously to ensure that the defenses are running and up to date, we are effectively outsourcing that work to bad actors, who fundamentally charge higher billing rates than developers when they take down critical systems via ransomware.
  1. In his book Data and Goliath, Bruce Schnier wrote, "Complexity is the worst enemy of security, and our systems are getting more complex all the time.[x]" Complexity is inversely correlated to security. If there are two hundred settings that you need to configure properly to make containers secure, that’s a big deal. It becomes a bigger deal when the team only understands how to apply 150 of those settings. Essentially, your company is left with fifty opportunities for misconfiguration to be abused by bad actors. Therefore, when possible, focus your understanding on how to minimize complexity. For example, instead of running your own containers on premises with Kubernetes, try using Amazon Elastic Container Services. There’s a significant amount of configuration complexity decrease. In addition, using cloud-based services give us a lot of capabilities -- elastic scaling, load balancers, multiple regions and availability zones, and even resistance to DDoS attacks. That’s a lot of overhead to ensure in a high-availability application running on servers in your data center. Consider using AWS lambda where all of that is already handled as a service for our company. Remember that complexity makes security more difficult and generally increases the costs of maintenance. So only increase complexity when the business benefit exceeds the costs.
  From a business connectivity perspective, consider the complexity of relationships. Many years ago, data centers were self-contained with 3270 green screens (or punched card readers if you go back far enough) as input and fan-fold line printer generated paper as output. Essentially, the only connection that mattered was reliable electrical power.
  
  Today, we have to be aware of what's going on in our industry, our customers, our suppliers, consumers, service providers, and if we have them, joint ventures or partners.[xi] This complex web of competing demands stretches our existing strategies, and sometimes rends holes in our coverage. I would add to that awareness, complexity in our workforce. How did COVID-19 affect your coverage of endpoints, for example? Most work-from-home arrangements lost the benefit of the protection of the enterprise security bubble, with firewalls, scanners, and closely-manage endpoints. Just issuing a VPN credential to a developer working from home doesn't do much when junior sits down at mom's computer to play some online game and downloads who-knows-what. Consider standardizing your endpoints for manageability -- remove the complexity. When I was in the Navy, we had exactly two endpoint configurations from which to choose, even though the Navy-Marine Corps Intranet, or NMCI, was the largest intranet in the world at the time. Although frustrating when you have to explain to the admiral why his staff can't get fancier computers, the offsetting benefit is that when an emergency patch has to get pushed, you know it's going to "take" everywhere.
  1. Number six is Competency -- another crucial skill for developers. If your organization doesn’t have competent developers, then more vulnerabilities are going to emerge. So how do most other industries show competencies? They use a licensure and certification process. For example, teenagers in the United States must obtain a driver’s license before they are legally approved to drive on their own. Nearly all of us have been through the process -- get a manual when you get a learner's permit, go to a driving school to learn the basics, practice with your terrified parents, and after you reach the minimum age, try not to terrify the DMV employee in the passenger seat. In the UK, the Driver and Vehicle Standards Agency recommends a minimum of 47 hours of lessons before taking the driving test, which still has only a 52% pass rate on the first attempt[xii].
  Now ask yourself, is developing and deploying apps riskier than driving a car? If so, consider creating a Developer Driver’s License exam that identifies when developers are competent before your company gives them the SSH keys to your servers. Before your new developer sits for the exam you also need to provide the training that identifies the Rules of the Road. For example, ask:
  
  When a new application is purchased, what processes should be followed?
  
  When are third party vendor assessments needed?
  
  How does one document applications into asset inventory systems and Configuration Management Databases?
  
  If you can build the Driver’s Education Training equivalent for developer and measure competency via an exam, you can reduce the risk that comes from bad development and create a sense of accomplishment among your team.
  
  So, to summarize so far, for executives we have controls, compliance, and continuity, and for developers we have coverage, complexity, and competency. It's now time to move to the last three for our security operations center: clarity, context, and community.
  1. The seventh C is Communication. Let’s learn from a couple quotes on effective communication.
  [War story: Just this past week, Apple upgraded to iOS 16. We use iPhones exclusively as corporate-issued handsets, so I sent a single sentence message to my senior IT team member: "Please prepare and send an email to all who have an iPhone with steps on how to update the OS soonest. Thank you." To me, that seemed like clear communication. The next day I get a response, "People are slowly updating to 16.0 on their own and as the phone prompts them." After a second request where I point out "slowly" has not been our strategy for responding to exploitable security vulnerabilities, I get a long explanation of how Apple upgrades work, how he's never been questioned in his long career -- essentially the person spent five times as much time explaining why he will NOT do the task rather than just doing it. And today 80% of the devices are still not updated. At times like this I'm reminded of Strother Martin in Cool Hand Luke: "What we have here is failure to communicate." So, my lesson for everyone is even though you think your communications are crystal clear, they may not be perceived as such.]
  1. Convenience is our eighth C that we are going to talk about. How do we make something convenient? We do it by automating the routine and removing the time wasters. In terms of a SOC, we see technology in this space emerging with the use of Security Orchestration, Automation, and Response, or SOAR technologies. Convenience can come in a lot of ways. Have we created helpful playbooks that identify a process to follow? If so, we can save time during a crisis when we don’t have a minute to spare. Have we created simple processes that work via forms versus emails? It’s a lot easier to track how many forms have been submitted and filter on field data versus aggregating unstructured emails. One thing you might consider as a way to improve convenience are Chatbots. What if someone could ask a Chatbot a Frequently Asked Question and get a quick, automated, and accurate response? That convenience helps people, and it saves the SOC time. If you go that route, as new questions get asked, do you have a way to rank them by frequency and add them as new logic to the chatbot? If you do, your chatbot gets more useful and provides even greater convenience to the workforce. How great would it be to hear your colleagues saying it was so convenient to report an incident and see that it was handled in such a timely manner. Find ways to build that experience and you will become the partner the business wants.
  2. Last, but not least, is the 9th C of Consistency. Want to know how to create an audit finding? Try not being consistent. Auditors hate that and love to point out inconsistencies in systems. I’m sure there are auditors right now listening to this podcast smiling with joy saying, "yup, that’s me." Want to know how to pass every audit standard? Try passing the CARE Standard for cyber security. CARE is a Gartner acronym that means Consistent, Adequate, Reasonable and Effective. Auditors look at the Consistency of controls by performing tests to determine if the control is working the same way over time across the organization. Auditors also look for Adequacy to determine if you have satisfactory controls in line with business needs. Auditors ensure that your practices are Reasonable by identifying if there exist appropriate, fair, and moderate controls. Finally, auditors look at Effectiveness to ensure the controls are producing the desired or intended outcomes. So, in a nutshell, show Auditors that you CARE about cyber security.
  Okay, let's review. Our nine Cs are for executives, developers, and SOC teams. Executives should master controls, compliance, and continuity; developers should master coverage, complexity, and competency; and SOC teams should focus on clarity, communications, and consistency. If you paid careful attention, I think you would find lessons for security leaders in all nine boxes across the model. Essentially, don't conclude because boxes four through nine are not for executives that you don't need to master them -- all of this is important to being successful in your security leadership career.
  
  Well thanks again for listening to the CISO Tradecraft podcast as we discussed the 9 C’s. And for International Talk Like a Pirate Day, I do have a rrr-request: if you like our show, please take a few seconds to rate us five stars on your favorite podcast provider. Another CISO pointed out to me this past week that we came up first on Spotify when searching for C-I-S-O, and that's because those rankings are crowd-sourced. It's a great way to say thank you for the time and effort we put into our show, and I thank you in advance. This is your host G. Marrrrk Hardy, and please remember to stay safe out there as you continually practice your CISO Trrrradecraft.
  
  References
  https://www.gartner.com/en/articles/4-metrics-that-prove-your-cybersecurity-program-works?utm_medium=socialandutm_source=facebookandutm_campaign=SM_GB_YOY_GTR_SOC_SF1_SM-SWGandutm_content=andsf249612431=1andfbclid=IwAR1dnx-9BqaO8ahzs1HHcO2KAVWzYmY6FH-PmNoh1P4r0689unQuJ4CeQNk
  
  [i] Hall, James A. (1996). Accounting Information Systems. Cengage Learning, 754
  
  [ii] https://www.isaca.org/resources/news-and-trends/industry-news/2020/cobit-2019-and-cobit-5-comparison
  
  [iii] https://www.itgovernance.co.uk/cobit
  
  [iv] https://www.coso.org/SitePages/Enterprise-Risk-Management-Integrating-with-Strategy-and-Performance-2017.aspx
  
  [v] https://www.marquette.edu/riskunit/internalaudit/coso_model.shtml
  
  [vi] https://www.coso.org/Shared%20Documents/2017-COSO-ERM-Integrating-with-Strategy-and-Performance-Executive-Summary.pdf
  
  [vii] https://www.axelos.com/certifications/itil-service-management/what-is-itil
  
  [viii] https://www.theiia.org/globalassets/site/about-us/advocacy/three-lines-model-updated.pdf
  
  [ix] https://www.law.cornell.edu/cfr/text/2/200.516
  
  [x] https://www.goodreads.com/quotes/7441842-complexity-is-the-worst-enemy-of-security-and-our-systems
  
  [xi] https://www.pwc.com/gx/en/issues/reinventing-the-future/take-on-tomorrow/simplifying-cybersecurity.html
  
  [xii] https://www.moneyshake.com/shaking-news/car-how-tos/how-to-pass-your-uk-driving-test

#96 - The 9 Cs of Cyber

CISO Tradecraft®

#96 - The 9 Cs of Cyber