Triple R’s of Security
What are the “3 R’s of Security”? A quick Google on that topic will result in a fair few decent explanations of what that can mean. The TL;DR is basically, rotate (credentials), repair (vulnerabilities) and repave (services and servers to a known good state). This approach is gaining popularity mainly due devops deployment models. Or “secdevops”. Or is it “devsecops”? Containerization and highly automated “code to prod” pipelines make it a lot easier to get stuff into production, iterate and go again. So how does security play into this?
Left-Shifting
Well I want to back track a little, and tackle the age old issue of why security is generally applied as a post live issue. Security practitioners, often evangelise on the “left shifting” of security. Getting security higher up the production line, earlier in the software design life cycle and less as an audit/afterthought/pen testing exercise. Why isn’t this really happening? Well anecdotally, just look at the audit, pen testing and testing contractor rates. They’re high and growing. Sure, lots of dev teams and organisations are incorporating security architecture practices earlier in the dev cycle, but many find this too slow, expensive or inhibitive. Many simply ship insecure software and assume external auditors will find the issues.
This I would say has resulted in variations of R3. Dev as normal and simply flatten and rebuild in production in order to either prevent vulnerabilities being exploited, or recover from them faster. Is this the approach many organisations are applying to newer architectures such as micro-services, server-less and IoT?
IoT, Microservices and Server-less
There are not many mature design patterns or vendors for things like micro-services security or even IoT security. Yes, there are some interesting ideas, but the likes of Forrester, Gartner and other industry analysts, don’t to my knowledge, describe security for these areas as a known market size, or a level of repeatable maturity. So what are the options? These architectures ship with out security? Well, being a security guy, I would hope not. So, what is the next best approach? Maybe the triple R model is the next best thing. Assume you’re going to breached – which CISO’s should be doing anyway – and focus on a remediation plan.
The triple R approach does assume a few things though. The main one, is that you have a known-safe place. Whether that is focused on images, virtual machines or new credentials, there needs to be a position which you can rollback or forward to, that is believed to be more secure than the version before. That safe place, also needs to evolve. There is no point in that safe place being unable to deliver the services needed to keep end users happy.
Options, Options, Options…
The main benefit of the triple R approach, is you have options – either as a response to a breach or vulnerability exposure, or as a preventative shortcut. It can bring other more pragmatic issues however. If we’re referring to things like IoT security – how can devices, in the field and potentially aware from Internet connectivity – be hooked, rebuilt and re-keyed? Can this be done in a hot-swappable model too, without interruptions to service? If you need to rebuild a smart meter, you can’t possibly interrupt electricity supply to the property whilst that completes.
So the R3 model is certainly a powerful tool in the security architecture kit bag. Is is suitable for all scenarios? Probably not. Is it a good “get out of jail” card in environments with highly optimized devops-esque process? Absolutely.