On Drawbridges and SecOps

Last night I gave a short (paid) talk over dinner at the Quality Chop House for a customer and prospect event held by Cohesive Networks – an app centric security company. It was interesting to compare notes with a group of London bank tech execs, and they had some amusing war stories. Anyway I talked about micro-services of course, and my theory that drawbridges are more important than moats. We also had fun talking about the cattle vs pets microservices distinction. While most cattle is somewhat disposable, not all of it is – think prize bulls… 

We all agreed that a key problem was domain knowledge. Too often the security people know about security, but not the rest of the stack. This has to change. SecOps know the business, the stack, and all the security goodness. Such people are hard to find. Similar situation obviously to DevOps.

It’s not just banks and enterprises that are ratcheting up their security investments. Seems like Cloud Native companies are also getting the memo – many have been remiss at securing assets behind the load balancing tier – they have not deperimiterised any more effectively than traditional enterprises = and so there is a lot of investment in that area at the moment. Related – Transport Layer Security (TLS), the successor to SSL for encryption, is making an impact, with Amazon releasing a new open source implementation, S2N earlier this week. Varnish Software CTO Per Buer told me earlier this week that his SF clients have all said TLS support is non-optional and has to be in place by year end…. 

The Cohesive pitch is that once the perimeter is breached, all other services are at risk. All apps should be individually secured at the network level.

Which brings me to to drawbridges. Generally when we think of security we think of fences, moats and high walls. These all play a role in security, but real security is granular control of who and what you let you in. A state of permanent siege is not a great way to get business done. Microservices need drawbridges as much as they need moats. Enterprises, cloud native companies and service providers should build all services as if they expect them to be exposed externally, just as you should write code so that it can be open sourced, with clean docs, clean interfaces and manageable granularity.

Anyway – here were my key takeaways.

• Shift testing left
• Develop all services as if they will be exposed to the cloud
•   same as you should develop all code so it could be open sourced
• Focus on drawbridges not moats
• Microservices as a forcing function for better security
• SOA underpins API Management, which will underpin Microservices
•   performance not just features – see Amazon S2N lib
• SOA as a style to manage internal and External access to resources
• SecOps is now a thing