- Everyone Knows What "Cybersecurity" Means
- We Can Measure How Secure Our Systems Are
- The Primary Goal of Cybersecurity Is Security
- Cybersecurity Is About Obvious Risks
- Sharing More Cyber Threat Intel Will Make Things Better
- What Matters to You Matters to Everyone Else
- Product X Will Make You Secure
- Macs Are Safer Than PCs, Linux Is Safer Than Windows
- Open Source Software Is More Secure Than Closed Source Software
- Technology X Will Make You Secure
- Process X Will Make You Secure
- Faerie Dust Can Make Old Ideas Magically Revolutionary
- Passwords Should Be Changed Often
- Believe and Fear Every Hacking Demo You See
- Cyber Offense Is Easier Than Defense
- Operational Technology (OT) Is Not Vulnerable
- Breaking Systems Is the Best Way to Establish Yourself
- Because You Can, You Should
- Better Security Means Worse Privacy
- Further Reading
Process X Will Make You Secure
DevSecOps.48 Security Chaos Engineering.49 SAFe Agile.50 If products and technologies are not the answer to security, could a process or discipline be the solution? Let’s see why not.
Modified security behavior intuitively feels promising. As an abstract concept, better processes supporting security can be applied to many situations. We achieve many benefits when we change our lifestyle by giving up smoking or starting to exercise.
Historically, some processes have been shown to reduce defects in code, but because of their overhead in time and personnel training, they have not been widely adopted. Code produced for (as an example) the Space Shuttle and nuclear power plant control were almost defect-free. The 1986 Capability Maturity Model (CMM) was a methodology to describe the formality and optimization of software development processes. Even though the People Capability Maturity Model was developed nine years later, it is much less known. Most code producers are interested in fast and cheap, and the processes shown to reduce defects are not known for those qualities. Unfortunately, the computing-using public and too many vendors have coalesced around the idea of “Yes, it’s buggy and unsafe, but we get it quickly and cheaply!”
Improving our development and security processes is strongly encouraged! Well-validated methods are great, and we should consider them, especially in large corporate environments where the benefits accumulate with scale. But did you know that no formal research studies (to date) have proven definitively that Agile or DevSecOps or any other recent framework is measurably better than the alternatives? That does not mean we should not use them. It simply means we should understand their limitations. Many things influence security, so it is not easy to show that a particular process is the cause of improvement. Sometimes, the simple act of enthusiastically doing something new will make it seem better. Robust processes are within our control as we develop and deploy systems. There are, unfortunately, a lot of things that influence security that are out of our control. We cannot control whether an attacker tries to launch a denial of service attack against our website. Amazing processes cannot eliminate supply chain attacks.
Remember that enterprises are the combination of infrastructure, personnel, threats, resources, time, and funding (at the least). Some approaches will work better than others for different mixes of these factors. Do not believe that a Harvard Business School study, popular book, or conference seminar about someone else’s experience will translate seamlessly into your own!
One myth is that someone can buy a process solution from a vendor: That is not true. In the best case, there are open source tools available that can help in the practice of the discipline. Netflix, for example, has released Chaos Monkey (and many other tools) on GitHub to help support chaos engineering.51 Further, it has published papers to help you measure the benefits and costs of chaos engineering.52