10 immutable laws of security, 25 years later
Looking at "10 Immutable Laws of Security", which celebrated its 25th Year Anniversary a few weeks ago, and sharing some thoughts about the relevance of these laws today
Back in 2000, the Microsoft Security Response Center released an article titled "10 Immutable Laws of Security", describing what they believed were some fundamental truths about security, human behavior, and technology operations. Years later, they also released a V2 of this article, which remains relevant to this day.
In this piece, I am looking at the original write-up, which celebrated its 25th Year Anniversary a few weeks ago, and sharing some thoughts about the relevance of these laws today, exactly two and a half decades later. I think it’s valuable to take a closer look at these laws, not because of nostalgia, but to ground ourselves in fundamentals and to remind ourselves, for the thousandth time, that while trends, technologies, and marketing hype change, the fundamentals persist.
Introduction
Back in the early 2000s, Microsoft published a list that has stood the test of time: the 10 Immutable Laws of Security. These weren’t about software bugs or zero-days that could be patched, they were about foundational truths of computing and risk. As the Microsoft Security Response Center put it, many security issues don’t stem from product flaws; they stem from the nature of systems, people, and trust. We can’t "fix" these with code because they’re not bugs in the traditional sense - they’re properties of how computers and the people who use them work.
The disclaimer Microsoft offered still holds: don’t wait for a patch because fundamental security problems persist regardless of how many new features or detections get shipped. Running untrusted code, mishandling keys, weak identity practices, insider risk, the illusion of perfect tech - none of the issues Microsoft called out have gone away. And yet, twenty-five years later, our industry continues to hope for magic solutions, products, platforms, or compliance checklists that will “take care of security” only to realize that it is not how security works.
To me personally, the main thought behind these 10 immutable laws is that security is not just a technical problem, it’s a system-of-systems problem that involves people, assumptions, architecture, and incentives. With that out of the way, let’s dive in. In each section, I’ll provide a short snippet from Microsoft's article and my general thoughts on the topic. You can read the full version of their article by following the link to the original.
This issue is brought to you by… Chainguard.
How much do CVEs cost your business?
Managing CVEs are costly in a variety of different areas. To measure this cost, and the return on investment organizations can expect when utilizing outsourced solutions for CVE management, Chainguard interviewed several industry leaders and quantified the amount of money these organizations unlock in areas like cost savings, increased revenue, faster innovation, and decreased risk.
10 immutable laws of security, 25 years later
Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
“It's an unfortunate fact of computer science: when a computer program runs, it will do what it's programmed to do, even if it's programmed to be harmful. When you choose to run a program, you are making a decision to turn over control of your computer to it. Once a program is running, it can do anything, up to the limits of what you yourself can do on the computer… That's why it's important to never run, or even download, a program from an untrusted source—and by "source," I mean the person who wrote it, not the person who gave it to you. There's a nice analogy between running a program and eating a sandwich. If a stranger walked up to you and handed you a sandwich, would you eat it? Probably not. How about if your best friend gave you a sandwich? Maybe you would, maybe you wouldn't—it depends on whether she made it or found it lying in the street. Apply the same critical thought to a program that you would to a sandwich, and you'll usually be safe.” - 10 Immutable Laws of Security
It is both fascinating and scary to realize that this 25-year-old warning is even more relevant today than it was at the time when Microsoft published it. Gone are the days when we could even hope to enumerate what’s running and where. It’s not just EXE anymore; it’s a long list of different options:
A growing number of browser extensions that nobody has the ability to control as recently as half a year ago caused the Cyberheaven incident
A growing number of malicious VSCode extensions, some of which infect Windows with cryptominers
A growing number of SaaS plugins like Salesforce, Slack bots, and more that can be leveraged by attackers to achieve their goals
An explosion of AI agents able to execute tasks needed to achieve the objectives set out for them. LLM prompt injection, for example, is just another form of "convincing" software to execute attacker intentions.
Each of these examples introduce a new surface for untrusted code, and in each case, we are generally doing an okay job assessing the security of the platforms (Chrome, VSCode, Slack, Salesforce, etc.) but a terrible job controlling the growing number of plugins (extensions, integrations, bots, or agents) running on top of them. Moreover, a growing number of software supply chain attacks means that even trusted developers may unknowingly run malicious code. To borrow Microsoft’s analogy: it’s like buying a sandwich from a top restaurant you trust, only to get poisoned because the meat supplier, halfway across the country, maliciously tampered with the ingredients. You didn’t eat a stranger’s sandwich, but you still got burned because trust now extends deep into the supply chain.
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
“In the end, an operating system is just a series of ones and zeroes that, when interpreted by the processor, cause the computer to do certain things. Change the ones and zeroes, and it will do something different. Where are the ones and zeroes stored? Why, on the computer, right along with everything else! They're just files, and if other people who use the computer are permitted to change those files, it's "game over"...” - 10 Immutable Laws of Security
In today’s cloud-first world, the definition of “operating system” has expanded far beyond the physical machine. While traditional OS tampering still exists, attackers now more often try to subvert the control planes that manage fleets of virtual machines or containers. In cloud environments, compromise of the control plane or metadata APIs can often have the same effect as altering the OS directly: total takeover of workloads.
This law is more relevant than ever because modern infrastructure is built on layers of trust that are rarely verified. Infrastructure-as-code can accidentally propagate malicious changes at scale, CI/CD pipelines often have write access to system configurations, and misconfigured agents can be exploited to gain system-level privileges. Even endpoint agents meant to provide security (like EDRs) become targets - if an attacker disables or tampers with them, downstream telemetry and enforcement fail. Protecting the "OS" has become more complex and distributed, but doing it is as critical as before.
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore
“...Always make sure that a computer is physically protected in a way that's consistent with its value—and remember that the value of a computer includes not only the value of the hardware itself, but the value of the data on it, and the value of the access to your network that a bad guy could gain. At a minimum, business-critical computers like domain controllers, database servers, and print/file servers should always be in a locked room that only people charged with administration and maintenance can access. But you may want to consider protecting other computers as well, and potentially using additional protective measures…” - 10 Immutable Laws of Security
The meaning of this law and the context around it have evolved quite a bit since the start of the pandemic and the rise of hybrid work. Laptops today are scattered across homes, airports, and coworking spaces, and even though more and more companies are pushing for a return to office, from what I’ve seen, many employees bring their computers with them (though I am definitely biased working in tech).
I am seeing two schools of thought when it comes to this problem. One school of thought still treats laptops as critical assets to be protected: hardened with EDR, full-disk encryption, secure boot, MDM enforcement, and remote wipe capabilities. For this cohort of CISOs, physical access remains a serious risk. On the other hand, a growing number of security leaders treat endpoints as disposable and untrusted by default. These organizations shift critical controls up the stack, to the browser, SaaS layer, or secure access edge, and add identity controls/SSO/MFA all around. They assume laptops will be lost, stolen, or compromised, and instead focus on controlling access, isolating sessions, and making sure that nothing valuable is stored on the device. Both philosophies agree that once someone has unrestricted physical access to the computer, they get to own it; the divergence is in whether that matters.
Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more
“This is basically Law #1 in reverse… Although this scenario is a danger anytime you allow strangers to connect to your computer, websites are involved in the overwhelming majority of these cases. Many people who operate websites are too hospitable for their own good, and allow visitors to upload programs to the site and run them…If you run a website, you need to limit what visitors can do. You should only allow a program on your site if you wrote it yourself, or if you trust the developer who wrote it. But that may not be enough. If your website is one of several hosted on a shared server, you need to be extra careful.” - 10 Immutable Laws of Security
The fundamental truth of this law still holds: if an attacker can upload programs to your website, they can own it. However, unlike in 2000, many of the worst-case scenarios, like arbitrary file uploads or direct code execution on web servers, are now better mitigated. Modern web frameworks often come with built-in protections, and serverless architectures, alongside WAFs, reduce the likelihood of the kinds of breaches that were common two and a half decades ago. We’ve also made progress in dev hygiene, with security checkers and CI pipelines flagging unsafe patterns before they ship. All that said, while a lot of the problems of the past no longer apply, there are plenty of new risks that do.
Modern web threats stem less from a single attacker uploading malware and more from complex supply chain pathways: malicious open-source packages, poisoned build artifacts, vulnerable third-party SDKs, and unvalidated CI/CD workflows. In multi-tenant environments, one compromised tenant can still affect others if isolation boundaries aren’t strict, while in serverless platforms, poor permission scoping can allow attacker-controlled inputs to execute sensitive workflows. We've made progress hardening infrastructure, but the surface area has exploded beyond what it was twenty-five years ago.
Law #5: Weak passwords trump strong security
“The purpose of having a logon process is to establish who you are. Once the operating system knows who you are, it can grant or deny requests for system resources appropriately. If a bad guy learns your password, he can log on as you… Always use a password—it's amazing how many accounts have blank passwords. And choose a complex one. Don't use your dog's name, your anniversary date, or the name of the local football team. And don't use the word "password"! Pick a password that has a mix of upper- and lower-case letters, number, punctuation marks, and so forth. Make it as long as possible. And change it often… Finally, consider using something stronger than passwords to identify yourself to the system. Windows 2000, for instance, supports the use of smart cards, which significantly strengthens the identity checking the system can perform. You may also want to consider biometric products like fingerprint and retina scanners…” - 10 Immutable Laws of Security
I am quite sure that to those who, like myself, have spent less than two decades in security, reading this will feel very unsettling. Think about it: twenty-five years ago, Microsoft was asking people to set strong passwords and warning that the word "password” can’t be used as a password. Fast forward to today, and 46% of people are still more likely to choose an easy-to-remember password than a secure one, while the top five most common passwords are 123456, 123456789, 12345678, password (sorry, Microsoft), and qwerty123.
Some things have changed since the early 2000s. For example, as of 2024, Microsoft's recommendation to frequently change the password is no longer considered a best practice, and the narrative has generally shifted from “use strong passwords” to “go passwordless”. At the same time, much has remained the same: smart cards are still very much around (though we are now hoping we can get people to adopt passkeys), and “consider biometric products like fingerprint and retina scanners” continues to be good advice. The tl;dr is that weak passwords continue to trump strong security.
Law #6: A computer is only as secure as the administrator is trustworthy
“Every computer must have an administrator: someone who can install software, configure the operating system, add and manage user accounts, establish security policies, and handle all the other management tasks associated with keeping a computer up and running. By definition, these tasks require that he have control over the computer. This puts the administrator in a position of unequalled power... If you have an untrustworthy administrator, you have absolutely no security… When hiring a system administrator, recognize the position of trust that administrators occupy, and only hire people who warrant that trust. Call his references, and ask them about his previous work record, especially with regard to any security incidents at previous employers. If appropriate for your organization, you may also consider taking a step that banks and other security-conscious companies do, and require that your administrators pass a complete background check at hiring time, and at periodic intervals afterward. Whatever criteria you select, apply them across the board. Don't give anyone administrative privileges on your network unless they've been vetted – and this includes temporary employees and contractors, too.” - 10 Immutable Laws of Security
When Microsoft first published its immutable laws of security, it had to specifically call out background checks for system administrators as a security measure. Today, background checks that were once limited to “banks and other security-conscious companies” have become a common practice virtually everywhere. What hasn’t changed, however, is the assumption that trust, once granted, is permanent. Periodic re-screening of privileged users is still a largely theoretical concept since most organizations continue to assume that anyone who was trustworthy at the moment they got hired will remain that way indefinitely, even as personal circumstances and access levels evolve. It is not surprising that insider risk is at all times high.
As with everything else, we’ve been making some good progress overall, and fewer companies are using shared admin credentials now than they were before. And yet, that is still more common than most people realize. Another best practice that hasn’t been adopted as widely as we’d like is the separation of administrative and day-to-day accounts. Many administrators continue to use their privileged accounts for regular work like checking email and browsing the internet, dramatically increasing the risk of compromise. While solutions like privileged access management and just-in-time access exist, cultural inertia and convenience tend to override security hygiene.
The very definition of an “admin” has changed, too. In the past, access was managed centrally by the IT team, but today, more and more of it is being done by different business units. Administrative privileges are scattered all over - across cloud platforms, SaaS tools, CI/CD pipelines, and identity providers, and few organizations have a good grasp of who can do what in their environment. We are getting better at RBAC enforcement and audit logging, but gaining clear visibility into who actually holds effective administrative power at any moment remains hard, in part because most SaaS vendors simply don’t provide this level of controls.
Law #7: Encrypted data is only as secure as the decryption key
“Suppose you installed the biggest, strongest, most secure lock in the world on your front door, but you put the key under the front door mat. It wouldn't really matter how strong the lock is, would it? The critical factor would be the poor way the key was protected, because if a burglar could find it, he'd have everything he needed to open the lock. Encrypted data works the same way—no matter how strong the crypto algorithm is, the data is only as safe as the key that can decrypt it… Whenever possible, use offline storage for keys. If the key is a word or phrase, memorize it. If not, export it to a floppy disk, make a backup copy, and store the copies in separate, secure locations.” - 10 Immutable Laws of Security
The “floppy disk” comment aside (I bet nearly half of my readers need to google what a floppy disk even is), unsurprisingly, the law #7 also remains valid. While encryption is now widely adopted across storage, transit, and even memory in some cases, the hard part has always been the keys, not the math. Modern cloud platforms encrypt data by default, but if you store your keys or allow access to them in the same environment (e.g., via overly permissive IAM roles or exposed metadata APIs), an attacker can potentially decrypt the data after compromising the right credentials. What’s changed since this law was first written is the scale: keys are now everywhere, managed by cloud KMSs, embedded in CI/CD secrets, handled by SaaS tools, and even hardcoded into source code repositories. The entire category of secrets scanning and non-human identity tools has emerged to tackle this problem, and we’re just starting to scratch the surface.
Microsoft’s metaphor still holds: it doesn’t matter how secure the lock is if the key is under the doormat. Practices like hardcoding secrets, leaving access tokens in CI logs, or storing unprotected credentials in cloud storage remain pretty common. Ultimately, if key management isn’t treated as a first-class problem, encryption leads to a false sense of security (when the key leaks, the data might as well be plaintext). Post-quantum encryption continues to try securing data against future quantum computers, but its benefits are moot if today's keys are still mishandled or exposed through poor operational practices. At least for the time being, we keep getting breached because of mishandled secrets, and not because of supercomputers.
Law #8: An out of date virus scanner is only marginally better than no virus scanner at all
“Virus scanners work by comparing the data on your computer against a collection of virus "signatures". Each signature is characteristic of a particular virus, and when the scanner finds data in a file, email, or elsewhere that matches the signature, it concludes that it's found a virus. However, a virus scanner can only scan for the viruses it knows about. It's vital that you keep your virus scanner's signature file up to date, as new viruses are created every day… Virtually every maker of anti-virus software provides a way to get free updated signature files from their website. In fact, many have "push" services, in which they'll send notification every time a new signature file is released. Use these services. Also, keep the virus scanner itself—that is, the scanning software—updated as well. Virus writers periodically develop new techniques that require that the scanners change how they do their work.” - 10 Immutable Laws of Security
Twenty-five years ago, when Microsoft was working on its immutable laws, security was pretty much about securing the endpoints with an antivirus, and securing networks with firewalls (I know it’s an oversimplification, but not an unfair one). A lot has changed since then, and an average enterprise today has anywhere between 30 and 100 security tools, depending on which reports you choose to read. The reason why it matters is that while the law #8 specifically talks about virus scanners, it does very much apply to every single product in the company’s environment today.
I discussed this problem at length two years ago in a blog titled “Tools alone won't save us but if we have tools - why don't we at least use them?”. In that article, I explained the following:
“Most enterprise security teams have all the tools they need to successfully strengthen their environment. What’s lacking is the operationalization of these tools - making sure that they are properly configured, testing that they work as intended, and verifying that findings from each of the tools are being acted upon at scale. It’s too common to hear stories about companies paying a lot of money for a solution, say a data loss prevention (DLP) tool, only to realize that 30% of detections have been disabled, or security teams ignore their vulnerability reports because they don’t have enough resources to patch vulnerabilities and upgrade their infrastructure.
One of the first people who raised the topic of making the most of the tools security teams already have was Phil Venables, who wrote a great blog about security controls back in 2019. In 2022, Jeremiah Groisman posted a question on Twitter that sparked a solid discussion: “In your experience, when security controls should have stopped a breach, but didn’t… is it usually because the control is ineffective or was the control misconfigured/ignored?”. In March 2023, Phil Venables again published a post titled “Fighting Security Entropy”, putting forward the idea that “Adopting a control reliability engineering mindset by continuous control monitoring is essential to counter the inevitable decay of control effectiveness”. Two weeks later, David Spark, the producer of the CISO Series, Geoff Belknap, CISO, LinkedIn, and Kenneth Foster, VP of IT governance, risk, and compliance at FLEETCOR, had a great discussion around Jeremiah's tweet and this problem at large.”
When the security team is deploying a new tool, it’s the only time when the customer will benefit from everything the solution has to offer. From that point onward, the control quality will start to degrade: while the vendor will continue to ship new features, add more coverage, and launch new capabilities, a lot of it will be disabled by default and buried in marketing announcements, too deep for anyone to see. Security teams can barely find enough time to keep up with alerts, let alone to make sure that every product is configured to maximize its value. This was true 25 years ago with antivirus, and it is even more true today.
Law #9: Absolute anonymity isn't practical, in real life or on the Web
“All human interaction involves exchanging data of some kind. If someone weaves enough of that data together, they can identify you. Think about all the information that a person can glean in just a short conversation with you… It doesn't take long for someone to collect enough information to figure out who you are. If you crave absolute anonymity, your best bet is to live in a cave and shun all human contact… The same thing is true of the Internet. If you visit a website, the owner can, if he's sufficiently motivated, find out who you are. After all, the ones and zeroes that make up the Web session have to be able to find their way to the right place, and that place is your computer. There are a lot of measures you can take to disguise the bits, and the more of them you use, the more thoroughly the bits will be disguised… All of these make it more difficult to determine who you are, but none of them make it impossible… Does this mean that privacy on the Web is a lost cause? Not at all. What it means is that the best way to protect your privacy on the Internet is the same as the way you protect your privacy in normal life—through your behavior… But if it's complete and total anonymity you want, better start looking for that cave.” - 10 Immutable Laws of Security
When this law was written, privacy concerns were largely hypothetical for most users - social media hadn't yet taken over daily life (remember that Facebook started 4 years later), smartphones weren’t tracking everything (iPhone was first released 7 years after the immutable laws were published), and surveillance capitalism was still emerging. Since then, the world has embraced a trade many security enthusiasts didn’t predict: exchanging personal data for convenience, free services, and personalized content. Platforms like Facebook, Instagram, TikTok, and Google built entire economies around behavioral profiling, ad targeting, and data monetization. While tools for anonymity and privacy have improved (VPNs, Tor, encrypted messaging, browser hardening, etc.), they remain niche, often clunky, and used by a loud but tiny minority. For the vast majority of people, privacy has become a cost of benefiting from digital life.
I think Microsoft’s law #9 still stands, but with two important caveats. The first one is the simple fact that anonymity has been de-prioritized by both consumers and tech companies, at least in the US (it is different in Europe). The second is that it is no longer reasonable to tell people that they can protect their privacy online by simply “behaving” a certain way. The very moment people get out of their house, everything is being recorded - every step, every transaction, every interaction. Everything is logged, fed into data warehouses, and analyzed to provide more tailored shopping recommendations, to push tailored content, etc. Even as privacy regulations push for more control and transparency, they’re often undermined by complex consent flows, dark patterns, and weak enforcement. Few users truly understand how much data is collected or how it can be correlated across devices and services, but it looks like even fewer truly care.
Law #10: Technology is not a panacea
The last of the ten immutable laws of security is so important that I will provide it without shortening the way I did with the previous nine. It goes as follows.
“Technology can do some amazing things. Recent years have seen the development of ever-cheaper and more powerful hardware, software that harnesses the hardware to open new vistas for computer users, as well as advancements in cryptography and other sciences. It's tempting to believe that technology can deliver a risk-free world, if we just work hard enough. However, this is simply not realistic.
Perfect security requires a level of perfection that simply doesn't exist, and in fact isn't likely to ever exist. This is true for software as well as virtually all fields of human interest. Software development is an imperfect science, and all software has bugs. Some of them can be exploited to cause security breaches. That's just a fact of life. But even if software could be made perfect, it wouldn't solve the problem entirely. Most attacks involve, to one degree or another, some manipulation of human nature—this is usually referred to as social engineering. Raise the cost and difficulty of attacking security technology, and bad guys will respond by shifting their focus away from the technology and toward the human being at the console. It's vital that you understand your role in maintaining solid security, or you could become the chink in your own systems' armor.
The solution is to recognize two essential points. First, security consists of both technology and policy—that is, it's the combination of the technology and how it's used that ultimately determines how secure your systems are. Second, security is journey, not a destination—it isn't a problem that can be "solved" once and for all; it's a constant series of moves and countermoves between the good guys and the bad guys. The key is to ensure that you have good security awareness and exercise sound judgment. There are resources available to help you do this. The Microsoft Security website, for instance, has hundreds of white papers, best practices guides, checklists and tools, and we're developing more all the time. Combine great technology with sound judgment, and you'll have rock-solid security.” - 10 Immutable Laws of Security
It feels truly odd to read this and to realize that these words aren’t from some Black Hat talk which happened last year, or some thought leadership piece from an outspoken CISO; this is an excerpt from an article published 25 (!) years ago. These words make it perfectly clear that we knew perfectly well what we needed to do back in 2000, as well as we do today.
This law is the most enduring, and also the most ignored. Security vendors continue to promise that the next platform, the next AI detection model, the next agentic framework, or the next zero trust architecture will finally “solve” security, but the truth remains: technology can reduce risk, but it cannot eliminate it. Every new control introduces new complexity, new misconfigurations, and new blind spots, and every security failure ultimately exploits that complexity, whether it's an attacker chaining together subtle weaknesses or a team misusing the tool they thought would protect them. Perfect security is a fantasy because perfect software, perfect configuration, and perfect behavior don't exist. Just over half a year ago, I published a piece titled “There are only two sources of security issues: software bugs and configuration mistakes”. Add to that the problem of social engineering, which I didn’t cover in my blog, and we’ll get the unholy triad that is the cause of all breaches - the past, the present, and most definitely the future.
The problem is that many organizations still try to "buy" their way to security instead of building it into their culture, systems, and operations, hoping that technology can be the substitute for solid process, accountability, and awareness. I don’t know if it even needs to be said, but no product can compensate for poor access controls, lack of inventory, untrained staff, or broken response workflows. The most expensive XDR won't help if no one's watching the alerts, and the best IAM system won’t reduce risk if people are overpermissioned. The real work of security lies in setting boundaries, enforcing consequences, asking hard questions, and doing it every single day.
What has changed is that security has become a board-level issue, and yet the urge for silver bullets persists. AI is the latest candidate: vendors say it will stop threats, replace analysts, and close the talent gap. That may very well be true, but attackers also use AI, and the playing field is constantly moving, which means that the only durable advantage is not smarter tools, but more disciplined thinking. Security is not a product; it’s a practice. Technology helps, but judgment, process, and ownership still make the difference between a resilient organization and a breached one. That was the case twenty-five years ago, and I don’t doubt it will be the case another twenty-five years from now.
Closing thoughts
The main point of this piece is not that nothing has changed in the past 25 years, because a lot has. I have discussed at length why we have reasons to be optimistic about the future of cybersecurity. We have achieved a whole lot in the past three decades. For example,
The CISO role, which is only 29 years old, is now much more accepted and understood than it was even a decade ago.
Cybersecurity has become a board-level concern, which has also led to a growing number of security leaders getting a say and sometimes even positions at public and private boards.
We’ve done well establishing trusted networks for innovation sharing and collaboration - from Information Sharing and Analysis Centers (ISACs) and peer networks, there are now plenty of places for CISOs to connect and share knowledge.
We’ve seen the rise of bug bounties and responsible disclosure. A case in point is Microsoft itself: just 14 years ago, Microsoft executives said that the company would “not follow the lead of Mozilla and Google in paying researchers for reporting vulnerabilities”. Less than a decade and a half later, not only has Microsoft become a huge supporter of responsible disclosure, but it’s not easy to find a large company that would not be willing to participate in a bug bounty program.
In the past several years, we have started to see examples of incredibly effective international collaboration to bring down cybercrime gangs and ransomware groups. FBI, Interpol, the UK National Crime Agency, as well as the US Secret Service, along with law enforcement agencies across Canada, Germany, France, Romania, Lithuania, Sweden, Norway, Portugal, Spain, and Ireland, to name a few, have shown that effective cross-border collaboration makes it possible to go after bad actors.
Much more can be said about the progress we’ve made as an industry - progress that has to be talked about and celebrated. It is fascinating, however, that while the state of the industry is changing, the technologies are changing, the generations of security leaders are changing, and Microsoft’s logos are changing, the ten laws of cybersecurity defined two and a half decades ago, remain as relevant today as they were then. Some believe that that’s a sign that security is “broken,” but I don’t think so. I very much share the ideas of Stafford Beer, who observed that the purpose of a system is what it does, and that there is "no point in claiming that the purpose of a system is to do what it constantly fails to do". Security is what it is, and embracing this reality is the first step for us to navigate it effectively.
Microsoft’s logos keep changing, but their 10 laws of security are immutable. Image Source: Venture in Security.
First impression after re-reading the 10 "Immutable" Laws of Security:
- heavily skewed towards the endpoint - which was the reality at the era, for sure;
- heavily biased towards technology - even though it puts the user or owner front and center, it still maps concepts against technology (passwords, antivirus, device, OS, etc). It abstains from systemic approaches in favor of a technological bias;
- if the same team were to write the "immutable" laws of security today, it would be: the 100 Immutable Laws of Security.
In short, even though the laws remain "immutable", they are could be rebranded to certain extent just the "basic laws of the endpoint" - a limited subset of cybersecurity. The network, the apps, the internal and external attack surfaces, the identity and access, and any other segment of modern cybersecurity we can conceive will still be missing their own set of "immutable" laws.
Immutable over the decade has lost it's actionable, transformational power that we derived when we first read them. Yeah, weak user behavior on a device will make the security crumble. So what? Now we have systems that mitigate risks behind the weak link in any security system they didn't have in those days. Zero Trust is by large built with this premise in mind.
The power of revisiting these laws is precisely this: realizing its beauty at the time of inception, its limitations, and potentially deriving new concepts, tactics, or updated laws based on the concept the original ones manifest.
Thanks for reflecting through these, Ross.