It is a fact that the digital landscape in most organizations, large or small, resembles the technological equivalent of a shanty town: a ramshackle collection of tech purchases (hardware, applications, cloud services…) that seemed like a good idea to someone at the time.
Perhaps there were some procurement processes in place (perhaps not), but you can almost guarantee that whatever security requirements were articulated either fell somewhat short, were disregarded or both.
When I first audited the security at companies, there were times I would be impressed (momentarily) when a huge organization would introduce me to an enterprise security architect. “Wow,” I would think, “they actually have a security architect.” My excitement would almost always be short-lived when I would latterly discover that even that “architect” had no idea who ran the overall enterprise security architecture. At one bank the architect told me, “I don’t know how many other security architects we have. It’s a lot. We all report into different parts of the company.”
For these and other reasons, it can be tempting to believe that security-by-design is a myth made up by idealists.
The truth is that security-by-design is the most economic, effective and desirable position for any enterprise to be in… if you can get there and if you can get your organization to look at the big picture. Unfortunately, the position most security professionals find themselves in is the digital equivalent of cleaning out restrooms:
“Can you just add security to this collection of things we already bought, without using much budget or interrupting business operations?”
The answer to that question should be no – but it is difficult to argue why the answer is no if the only other option is to leave the company.
How do you get an enterprise to at least commit to working toward a better security tomorrow?
As somebody who has successfully tackled this problem a few times (and failed on several occasions), my objective in this article is to share the three best tips I can offer for how to move any organization out of the technological slums and toward a more sanitary and engineered security-by-design future.
Tip 1) You need to be a true believer yourself.
Do you believe that optimal security can only be achieved when it is embedded from the cradle-to-the-grave for each technology or dataset of value an enterprise uses?
If you don’t believe this, then you need to address your misgivings.
Here is an example of why security-by-design works: consider the time when the Mirai DDoS attack caused the failure of several Internet of Things (IoT) companies and multi-million dollar costs for others. The attack leveraged one security omission: that the companies whose devices had been compromised had not understood that shipping a device with a default username and password would be a problem. Mirai was one example of a very simple security mistake at the outset resulting in a catastrophic business loss.
Mirai exemplifies how the omission of a security assessment that should only have cost a few hundred dollars resulted in the loss of millions.
Mirai is not an isolated example – every catastrophic cybersecurity failure can be traced back to problems earlier in the security-by-design lifecycle. You will find a further example below.
Tip 2) You need management to buy in to the idea that security-by-design provides commercial advantage.
If the executives at your enterprise believe that cybersecurity is an overhead – a business drag – then they need to have that mindset changed. Before you can get endorsement to move toward a security-by-design culture, management has to understand that effective cybersecurity actually improves profitability. Why? Because having effective cybersecurity makes a business more scalable, agile and less prone to interruption.
To make that case, use real-world examples. Here is an example from my own experience:
I was invited to help manage cybersecurity in two different multi-billion dollar healthcare organizations. One of them had reasonably effective security-by-design (including a global security architecture) and the other was in a state of near anarchy.
Although both companies were of similar size, one had a far higher security spend, a SIEM team 10-times the size of the other and was also suffering from frequent, major interruptions to business operations.
Which one do you think spent more on security? The company spending far more on security was the one being interrupted all the time – the one that did not have a security architecture.
What every non-security executive needs to understand is that the cost of security is not how much is spent on securing environments, it is also the cost of business interruptions, the sales impact from any brand-damaging data breach, potential regulatory fines and the lost opportunities if new technologies cannot be safely and rapidly scaled into use.
Tip 3) Manage expectations and understand priorities.
Moving from chaos to order is not something that happens overnight, and although it will ultimately make security less expensive AND more effective, for a time the security costs will be higher. That is because when transitioning an environment toward security-by-design, other existing security efforts still need to be sustained.
Delivering the maximum value as early as possible requires that the first security-by-design processes to get implemented are the ones that address the problems that are creating the most remediation costs and/or causing the most business interruption. These are not necessarily the processes at the beginning of the lifecycle.
A good tool to help identify these priorities are your SIEM metrics.
What any transition will do is to look at suggested point fixes to security and identify if there is a procedural root cause that if implemented, can prevent the problem from recurring. For example:
An organization identifies that it has (in the past) deployed highly confidential, business-critical systems into low security and vulnerable infrastructure. Instead of just moving the identified applications into better infrastructure, this would be identified as an opportunity to implement a change management process so that each time a new system is released, or an existing system is upgraded – the business value and confidentiality of the system is confirmed and checks are put in place to ensure the system is installed with the right security in an environment appropriate to the business value.
Once the process is ready, it can be piloted and then run on each of the highly confidential, business-critical systems. That will not only solve the immediate problem but also establish a process to guard against further systems deploying to substandard security infrastructure.
You can read about DevSecOps and its growing importance in an era of rampant cloud migrations here.
The bottom line: security-by-design is not the impossible utopia you may have thought it was.