A Sensible Cybersecurity Program - Part I

Building a cybersecurity program from the ground up is hard. Even harder is trying to change your current program because there's nothing more difficult than countering the "we've been doing things this way since forever" argument.

Putting aside the fact that this argument makes no sense in the modern world, changing the status quo is no small feat: it requires compelling arguments, facts, and a good dash of political savvy. In other words, you need the right team with the right skillset to effect change. It follows, then, that making things happen gets more difficult the closer you are to the bottom of the hierarchy. Not impossible, but very hard.

For the purposes of this series, let's assume that you have the political will to improve things, and that the necessary people are in place to support this endeavor. I realize this is probably the hardest thing to do, and we will discuss that in a different post. For now, please indulge us.

This series of articles will roughly follow the main functions from the NIST CSF 2.0 framework, and we'll share some ideas on how to achieve its main objectives. A word of caution, though: in cybersecurity one size does not fit all. That's why we are deliberately going to avoid the word "standard." Standards work really well for things like electrical outlets and screw sizes, but they tend to fall apart quickly when things vary wildly from organization to organization. If the answer to a question about a standard is "it depends", you're not looking at a standard.

Another thing to keep in mind as we go, is that we're using the CSF 2.0 as a guideline. We're not going to scrutinize every item, and we're not going to discuss every possible way to achieve the objectives of any given CSF category. The CSF, by design, doesn't tell you how you should do things, but rather what needs to happen. For example, it won't tell you how to do risk management, but it does tell you what an adequate risk management strategy looks like.

If the most important thing in comedy is timing, the most important thing in cybersecurity is attention to detail. My controversial, yet so bold mantra is that governance is 90% of cybersecurity. If you don't know what you are protecting, or why you need to protect certain things, you are not going to succeed. Which brings us to the first "Don't You Forget" point:

So, where do we start? The CSF can help us out here, so let's start from where the CSF starts: Governance.

According to my experience, if you fail this one, you'll fail everything else. The Govern function is the cornerstone of every cybersecurity program worth its salt. Without governance you're flying blind. Drifting aimlessly in an ocean of threats you can't make sense of, and lost in a maze of solutions to problems you may or may not have. Not having your governance under control has the undesirable side-effect of making any budget you have teleport to the pockets of any number of vendors who promise to fix every single problem you have.

CSF's Govern function is comprised of the following Categories:

1. Organizational Context
2. Risk Management Strategy
3. Roles, Responsibilities, and Authorities
4. Policy
5. Oversight
6. Cybersecurity Supply Chain Risk Management

These categories basically boil down to:

1. What cybersecurity rules and regulations apply to us?
2. What data do we need to protect?
3. Which systems affect the security of this data?
4. How do we measure all this?
5. How do we put that in writing?
6. Who is going to do it?
7. Who is going to make sure it's being done?

This is the genesis of a cybersecurity program. If you can't answer these questions, you can't have a functional program. No matter the size of your budget, the size of your team, or how many letters you have after your name on LinkedIn. No tool can make up for bad governance. You can approach these things in a number of ways, but it must be done.

Maybe an example is in order. Let's say you are a medium-sized business, and you sell tchotchkes retail on top of selling doodads wholesale. Suppose you are located in the US, but you sell your goods worldwide. You take orders on your website, but you also take orders through other B2B channels. Your goods are manufactured overseas, and most of your clients are overseas, too. There's a lot of importing and exporting happening.

Where do you even start? A good rule of thumb here is to consult with a lawyer first. Cybersecurity people most likely know about the usual suspects like ISO/IEC 27001:2022, the aforementioned NIST CSF, SOC 2 reports, and NIST 800-53. Maybe they know about PCI-DSS. It is not a given at all that they know about the Minimum Security Criteria – U.S. Exporters set forth by the US Customs and Border Protection for the Customs Trade Partnership Against Terrorism (CTPAT) program. The message here is this: don't assume that you know every cybersecurity requirement applicable to your business. Consult with the experts.

That's part of your organizational context, but that's not the whole story. You must include other cybersecurity obligations, including those that are contractual obligations and those that are technically "voluntary". For instance, you may find yourself in a position where people won't give you the time of day if you don't have a SOC 2 report or an ISO/IEC 27001 certificate, thus the scare quotes. We can argue about how businesses rely way too much on those two, but that's a topic for another time. For now, let's just roll with it.

Now that you know what kind of regulatory and compliance reporting obligations you have, it's time to figure out where to focus. In order to do that, first you need to know how things are done in your business. Understanding what daily business looks like is critical for that. You want to know what things you must protect for legal, regulatory, and business reasons. When possible, you don't want to find yourself out of compliance and exposed to fines, class-action suits, jail time, or bad reputation.

Suppose you have an internet-facing web application that handles the retail side of the your business. No need to drill down on the specifics quite yet: we're concerned about a very high-level data flow. Customers browse the website, add their favorite tchotchkes to the cart, and check out. You collect their name, address, email address, shipping and payment information. Perhaps you offer the option to create an account and save this information for future purchases.

What would need protecting here? Certainly the payment information needs to be handled in a PCI-DSS compliant fashion, lest you face the wrath of the card brands. It stands to reason that you want to protect the personal information of your customers, too. You might want to make sure your website is up and running, and ready to receive orders, otherwise, what's the point? You create a big bucket called "e-commerce - retail", and you start populating it with the information of all systems involved with this flow. Something like this:

+---------------+           +--------------+
|               |    PII    |              |
|   Customer    |---------->|   Web App    |
|               |  Payment  |              |
+---------------+           +--------------+
                                   ^        
                                   |        
                                   v        
+---------------+           +--------------+
|               |           |              |
|    Backend    |<--------->|  Database    |
|               |           |              |
+---------------+           +--------------+

We move to the B2B side of the house where you sell bulk doodads. Perhaps you have some Enterprise Resource Management (ERM) system running the show behind the scenes, and your corporate clients place their orders through a front-end that's only accessible to onboarded clients. You collect their regular information like legal name, tax ID, point of contact, who can place orders, who can change the delivery addresses (you don't want someone placing an order of doodads and changing the delivery address to their home), how they pay for it, and maybe other kind of information like how much credit you're extending this particular customer. You need to protect all this data, too. Not every wholesale purchase is paid for via payment cards, but, given that some are, this data is also subject to PCI-DSS. You would prefer it if this information didn't suddenly become public, and you don't want people messing with your ERM. You create a second big bucket called "e-commerce - wholesale", and you populate it with all the relevant systems.

+---------------+           +---------------+
|               |    PII    |               |
|   Customer    |---------->| ERM Front-end |
|               |  Payment  |               |
+---------------+           +---------------+
                                   ^         
                                   |         
                                   v         
+---------------+           +---------------+
|               |           |               |
|   Database    |<--------->| ERM Back-end  |
|               |           |               |
+---------------+           +---------------+

You keep doing that for every other part of the business: accounting, IT, legal, marketing, HR, customer service, etc. What's the data, where is it going, where is it passing through, where it is stored, and how it should be disposed of. Congratulations, you now have something resembling an inventory of critical assets.

Simple enough, right? You wish. These things get very messy very fast. Systems need to connect to each other, vendors need remote access to your assets, things are added and removed from the systems all the time, hardware needs replacing, software needs upgrading, dependencies depend on other dependencies, people will plug things into your network for no apparent reason, and so on. Your business is not static, therefore your technical infrastructure is not static, therefore your cybersecurity program cannot be static.

The secret here is, once again, governance. You must establish baselines and strict boundaries beforehand. What does that mean? I means that you need to think about your architecture from the very beginning. Okay, but what does that mean? It means that, once your "e-commerce - retail" process is established and running, it cannot deviate from the baseline without all sorts of alarms going off. If, for instance, you determine that the web application is a Node.js application running on a container on a Kubernetes cluster with a PostgreSQL on the backend, you don't want to see another runtime environment in there. You don't want to see unrelated services running anywhere. You definitely don't want to see a MariaDB. Or unexpected changes to configurations. Or changes to the list of users who can access the database directly. Or your sshd configuration changing. Or some CI/CD pipeline runner running when it shouldn't. You get the idea: you need to know yourself.

We will discuss some ways of implementing these things in future posts, but the takeaway here is that you absolutely must know what normal operations look like, and strictly enforce both technical and non-technical controls to make it really hard for people to mess things up. If your DevOps folks flat out refuse to change things in production without going through the proper channels, no matter who's asking, you're doing it right. But, if they do change things in production without going through the proper channels, alarms must sound. And, no. They can't control the alarm system.

The takeaways:

• Document all legal, regulatory, and industry requirements.
• Document all reporting obligations.
• Identify and document what must be protected.
• Document business processes.
• Establish and document your baselines.

One fella named LeBron James once said that "You don't practice until you get it right. You practice until you cannot get it wrong." Cybersecurity is no different: it's the art of making it really hard to get it wrong.

Tune in next week when we discuss risk management, policies, and oversight. See you then!