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):

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.

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.

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

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:

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:

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:

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:

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.

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.

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.

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.

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.

[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.]

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