Your security strategy need to be NIMBLE, ELASTIC and FLEXIBLE or you will not be able to deal with the inevitable security incidents that will arise despite your best laid plans and designs. No environment stays static over time - and therefore no threat model is a constant model. Any security architecture, and the processes that run it, need to be a fluid model - not a static picture. Even the most comprehensive security architecture has “holes” - because if there were no “holes” in the architecture there would be no data flows. Data flows are what make business happen - so for the business to operate, the security architecture must – by design - contain "holes" for data to flow. Security incidents can and will come from anywhere - and usually, when they are very effective in causing damage, bad actors are penetrating from a vector that we thought we had covered in our security strategy.
What does it mean to be "nimble" in security operations?
Because we need to design our security architectures with the proper "holes" in the design, when incidents do occur we need to be able to detect them quickly, assess them accurately, and act on verifiable intelligence effectively with speed - but we need to do all of this without breaking the data flows that run the business.
This is where the ability to be “nimble” comes into play. When we can work with our security mitigation controls to the point where we can assess threats and contain them quickly and reliably, and then partner with advanced IT solutions (i.e. redundant data pathing, intelligent workflow manipulation, etc.) to agilely keep the environment safe and operational, we can be sure that our security designs are running at peak performance.
How do we design for “elasticity” in security architecture?
In today's data environments, it's not enough to just be able to scale up in processing or scale out in storage - we need to be able to work with diverse and movable workflows, hybrid compute environments, interactive data flows, and dynamic compute resources. This is a massive change from the "stationary and static" environments we are used to designing security for in the past - and today’s IT trends are only going to continue to enable these elastic compute environments. Amazon AWS is designed to expand and contract on demand for "just in time" compute resourcing, and Microsoft Azure is designed to allow us to write our applications once and deploy for full scale up, scale out, on demand wherever and whenever we need them. Our “new normal” is going to becoming more and more elastic over time.
Because of this “new normal”, our security designs, processes, and toolsets need to be able to scale up and out with these deployment models. Any current solutions that are 'limited" in scaling up or scaling out with the ever-changing "compute boundaries" of the business need to be examined for future elasticity.
How is “flexibility” different from “elasticity” for security design?
It's one thing to be able to scale - it's another thing to be able to MOVE. Security incidents can and will come from any direction and source - so if all we can do is expand and contract in place, we are still going to be an easy target! The new IT capabilities today allow us to move workloads, adjust data flows, and manipulate environments at a moment’s notice – if we design them with flexibility in mind. The best way to avoid a fight is to not have to have the fight at all! One of the primary marketing trends we’ve seen in the past few years have been around combatting APT threats. These solutions are based on the premise of “You are inevitably going to be penetrated.” I don't disagree with that assertion - but I think we need to do better as an industry moving forward and not "design for defeat".
Business should not have to run extra resources just to catch bad actors – that’s not where a business should have to use its valuable revenues. What we need to be able to do is actively and accurately detect issues as they come up and nimbly avoid them so that business is not interrupted! If we design properly moving forward - the most nimble and flexible architectures will be the most difficult to compromise. As the old joke goes - "I don't have to be faster than the bear chasing us - I just need to be faster than the OTHER guys he's chasing too!"
So how do we achieve Nimble & Elastic Flexibility?
These are not easy design goals to achieve - and they are certainly not achieved via just deploying security tools, mitigations, and security architectures in a vacuum. It is vitally important for the security architecture team to be involved in IT design from the beginning of the design cycles, and work with the IT Team to establish these core principles of nimble, elastic and flexible. Then we can design a security architecture that can protect, move, modify, and adjust to the threats that will come from many (unexpected) directions.
If we use the principles of “nimble, elastic, and flexible” from the start of the design process, we can create environments that are far more safe and resilient, thus allowing for expansion, new tech adoption, growth and safety for the business over time.
Like this article? Join the conversation on LinkedIn: Rigidity is Detrimental to your Security Architecture: The Principle of Nimble & Elastic Flexibility
About the Author
Elliot Lewis | President and Chief Architect Follow @ElliotDLewis
Elliot is a thought leader with over 25 years in executive management. He's served as a leading Cybersecurity research analyst; Chief Security Architect at the office of the CTO at Dell; Director of Strategic Services, Security, and Identity at Cisco Systems; Chief Information Security Officer (CISO) of Merrill Lynch; and Senior Security Architect, Security Center of Excellence for Microsoft.