Security Basics are Essential (and not Basic) – Part I

I wish I could claim ownership of the idea that “Security Basics are Essential” but I have to thank my friend Simon PG Edwards who asked me to give a talk on the topic at an upcoming conference (coming up very soon now - and I’m told that if you ask very nicely there may be one or two spots still available). Appropriately primed, I spent some time unpacking the concept, and in doing so have gained a great deal of insight about how we do security today, and why it just might be completely wrong. 

I’ll be presenting the entire paper at the conference, but I’d like to put out a teaser here (which I’ll break up into a few parts); I’ll push the last part out after the conference closes. For this first installment, I’d like to explore the term “Security Basics” - a term which I think has pejorative connotations associated with it, almost implying that this is what beginners do, not “us pros” (whomever we are). In fact, nothing could be further from the truth, and my firm belief is that if you get the basics (or, as I prefer to call it, the foundation) of security right, you are well on the way to building out a robust security plan and culture. 

When we think about the foundational pillars of cybersecurity, it can be quite daunting, because there are lots of different ways we can explore that concept. Are we talking about “security basics” for individuals? For corporations? For the SOC? The concept changes depending on the audience. Similarly, one could be referring to the key defensive technologies every company should be using, the best practices and strategies one needs to adopt, and the governance, risk acceptance and compliance “basics” that form the basis of a successful security program. Put this way, we can see that the topic of “security basics” is both multi-faceted and broad. 

If I were to unpack the topic fully, I would probably want to break out “security basics” using a number of well known taxonomies (such as “People, Process, Technology”, but there are many). However, for the purposes of brevity, in this article, I will focus on best practices (the things you simply have to do) and the key defensive technologies you need to accomplish adherence to best practice. Given that best practices seem so common sense, let’s start there.

Best Practices

The value of best practices is that they are generally fairly universal, and they (usually) stand the test of time. 

When we think of Cybersecurity Best Practices, one might come up with a list that looks a bit like this. Oh, and don’t send me hate mail about me missing your pet product (please), but do put major omissions in the comments!

• Adopt a security framework. Such as ISO 27001, or the NIST 800-171 Cybersecurity Framework. 
• Regular - and active - risk assessments. Red Teaming (but done right - see Part II!).
• Robust access control and identity management. This goes further than just establishing “who are you, and what can you access” - it requires a solid understanding (and roll out) of the principle of least privileges. 
• Employee Training and Awareness. As anyone who has run a Red Team knows, the quickest way into a network is through a person. 
• Encryption. Needs to be strong, and in use for data at rest and in motion. 
• Robust Network Security. Whether you have adopted a true Zero Trust architecture or not, segmenting your network, controlling ingress and egress traffic, and detecting malicious traffic (including East/West traffic) is critical. That means firewalls, segmentation, Network Access Control (NAC), and IDS/IDP deployment. 
• Endpoint protection. EDR is a must for today’s threat environment. 
• An Efficient Patch strategy to ensure that clients and servers are secure. 
• Configuration management, to ensure that clients and servers are secure. 
• Backups and Disaster Recovery. Because sooner or later, you're going to wish you had that backup... 
• Incident Response Planning. The worst possible time to ask "now what?" is during a breach. I've been in the room and watched people do precisely the wrong thing when under pressure. I long for the day I can tell that story, but it's going to be a while.
• Third Party Risk Management. In today's environment, your partners make up a large part of your risk. Knowing the risks your accepting from them is critical.
• Log management and internal threat detection. This usually requires a SIEM, or equivalent. 

That might not feel too bad, it all makes sense. Let’s unpack those outcomes into products. It’ll start feeling more familiar any minute now…

Key Defensive Technologies

As we consider the best practices that we expect a “good” company to adhere to, we immediately consider how this adherence can be established using technology - after all, any time we can bake security into the system, we’re ahead of relying on humans who are notably bad at reliable policy compliance. 

At a minimum from a product perspective we would expect:

• Firewalls: Controlling access to the “internals” of the network is a must do. As such, most modern architectures require the deployment of firewalls and associated firewall rules.
• Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS): Whereas a firewall makes allow/deny decisions on traffic, an IDS/IPS solution goes deeper and attempts to detect malicious traffic both inbound to and already inside the network.
• Antivirus/Anti-malware Software: The workhorse for endpoint and server protection, deploying reliable Anti-malware software is critical.
• Virtual Private Networks (VPNs): If the internal network is appropriately segmented from the Internet, a company will need to leverage a VPN for internal network access.
• Data Loss Prevention (DLP) Solutions: DLP solutions help prevent the unauthorized disclosure of sensitive information by monitoring, detecting, and blocking data transfers.
• Security Information and Event Management (SIEM): SIEM tools collect and analyze security event data in real-time to provide a comprehensive view of an organization's security posture. This should also include robust audit trail protection, so actions can be traced back to causes.
• Multi-Factor Authentication (MFA): MFA requires users to provide two or more verification factors to access an account, enhancing security beyond just a password. And it needs to be everywhere.
• Encryption and Key Management: Data must be secure both when in motion and when at rest. While access control is part of any solution, this typically also requires encryption. Similarly, APIs and internet/external network connections should also be encrypted, and all associated keys and certificates managed and rotated on a regular basis.
• Secure Web Gateways (SWG) and/or SASE: SWGs filter and monitor web traffic to protect against malicious websites, malware, and other web-based threats.
• Anti-phishing Countermeasures: This could mean filtering of email at the network edge, but should also include user awareness training and Inbox-based protection
• Patch and Vulnerability Management: New vulnerabilities are discovered in software all the time. Companies need a robust and efficient Patch Management strategy that is driven by a good understanding of threats (hence, vulnerability management).
• Endpoint Detection and Response (EDR): EDR solutions monitor and respond to advanced threats targeting endpoints, such as laptops, desktops, and servers.

The keen reader will notice that there’s actually a mismatch between the standards up above (best practices) and my off-the-cuff list of tools you probably should be using. That’s intentional, at least in part, just to keep the “what” (the best practices) separate from the “how”. There’s a few different ways to accomplish things, and so the list of actual products required will vary a little bit depending on how one operationalizes a particular best practice. 

As can be seen, best practice and key technologies form a pretty intimidating list of “things you need to do” for defenders. Are all necessary? What are the implications of focusing on one at the expense of another? Must we really do it all? If only there were a way to know...

I’m From the Government, and I’m here to Help

It turns out that one of the best places to get a grasp of what the “basics” of cybersecurity look like - the lowest acceptable bar, if you will - is the Federal Government, if you happen to be in the USA. Even if you aren’t, the US Government has published some pretty interesting standards and guidelines about what the basics of Cybersecurity are.

One set of rules that I want to point out is the Federal Financial Institutions Examination Council (FFIEC). This Council, in its own words: “is a formal interagency body empowered to prescribe uniform principles, standards, and report forms for the federal examination of financial institutions by the Board of Governors of the Federal Reserve System (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC), and the Consumer Financial Protection Bureau (CFPB), and to make recommendations to promote uniformity in the supervision of financial institutions.” As such, Federal Financial Institutions are accountable for their adherence to these rules - and they quite helpfully cover Cybersecurity.

The FFIEC publishes a handy “Examination Handbook” for security, which can be found here. Thumbing through its virtual pages, you will very quickly get an idea of what the security basics mean, at least in the Government. Clocking in at 96 pages, the document is also notable that it is dated 2016 and yet still contains a set of operating principles that are valid almost a decade later. Another related source of regulations can be found on the FINRA website. Once again, these “basics” provide a pretty robust roadmap for cybersecurity within an organization.

Finally, and perhaps most importantly, there are the NIST 800-171 guidelines. These guidelines are designed for organizations that handle “Controlled Unclassified Information”, but they provide an outstanding reference for what the “blocking and tackling” of cybersecurity really is. While adherence is onerous, if an enterprise actually followed these guidelines rigorously, it would be a pretty hard target to attack. These all form part of a larger constellation of advice - the recently published NIST CSF 2.0 is another outstanding resource for defenders. This document broadens the idea of the basics into 5 main functions, built on a foundation of governance:

• Identify: Understand the cybersecurity risks that the organization faces.
• Protect: Put measures into place to protect the organization from cybersecurity risks.
• Detect: Find and analyze potential cybersecurity attacks and breaches.
• Respond: Take action to contain and recover from cybersecurity incidents.
• Recover: Restore the organization's systems and data to a secure state after a cybersecurity incident.

They say a picture is worth a thousand words, so the NIST CSF looks a bit like this:

Within each of these areas, the expectation is that the organization has a plan and technical resources to action such a plan. It’s also notable that CSF 2.0 has enhanced focus on governance and supply chains (and their impact on cybersecurity stance). If we want to go international, there’s also the perfectly respectable ISO 27000-family of standards, which fit quite well with the ideas mentioned above. 

The fact that all these documents have been produced by a committee highlights one of the most surprising things about security basics: they actually form a pretty stable foundation, and usually don’t change overnight. 

I’d argue that this is because most of these standards are outcome focused rather than technique focused. For example, we might be told that administrator events need to be logged in a tamper proof manner so that certain changes can be tracked. That’s good advice - it only becomes dated when the technique for accomplishing this is defined. 

This kind of “first principles” view of security is helpful, as we tend to think of security as an area that changes rapidly. In some ways that’s actually true. That OpenSSH server you were running yesterday looked to be secure. Today, it’s vulnerable to a brand new 0-day. As such, one can argue that cybersecurity is a game for people who have plenty of “fast twitch” muscle. On the other hand, the basic principles that security is built upon haven’t changed in a long time. Be aware of the assets you’re exposing to the Internet. Mindfully practice least privilege, and make sure your IAM is in place. Nothing here is new, and it’s all good advice.

The perfect illustration of the unchanging nature of the threat is ransomware. Surely that’s a new evolution? Actually far from it. Ransomware was one of the first cybersecurity threats that hit the headlines, when in 1989 the now-infamous AIDS Trojan Disk was mailed out to an unsuspecting public. While the distribution method was different back then, the basic threat was absolutely the same as the ones we face today. We may feel like we’ve come a long way, but thirty five years later, we’re arguably in the same place. “Don’t run untrusted code” is as valid today as it was then. 

Collectively, these documents represent just a few of the raft of regulators that the CISO needs to pay attention to. While we’ve come a long way from the early days of the Internet where at times it was impossible to actually comply with regulations from different organizations because they were contradictory, the breadth and depth of today's compliance requirements is eye watering. It’s good advice, but the side effects of taking all the medicine can lead to burnout and exhaustion. Security basics are obvious. Security basics are absolutely essential. And, on reflection, Security basics have grown to be a major burden on cash and talent strapped cybersecurity teams.  Thinking through the implications of that is where we'll start in Part II.

Closing Thoughts

So far, we’ve explored the concepts of “Security Basics” a bit, and then used this idea as a springboard to get us into some of the better-known cybersecurity frameworks and standards that exist. My approach has been breadth first, as there are lots of different standards around to consider. Looking at the standards, we’ve examined a list of just the very simplest countermeasures a medium-sized organization is going to need to put in place. That list is long, expensive, and hard to complete exhaustively.

This sets us up very nicely for the topic I’d like to cover in Part II: that’s the challenge that these "basics of cybersecurity" pose, when viewed en masse. Individually, each is sensible. Who wouldn’t want a firewall, right? But collectively they can become a pressing burden; when combined with strict compliance needs in highly-regulated industries, the guidance can move from being a light to show us the way to a rod with which we’re going to be beaten when something inevitably goes wrong. Security basics are essential. But doing them all is a mammoth task, and as we shall see, compliance doesn’t quite equal security. 

I’ll see you in Part II.