My last post focused on the challenges and the potential of SDN (Software Defined Networking) and SDCI (Software Defined Computing Infrastructures) for improving Information Security. APIs are being used to control more devices from a central point, bringing agility to networks, virtual systems, storage, and other elements of the computing infrastructure that meet the demands of the business.
If businesses are becoming more agile, IT also must become more agile however. SDCI is mandatory to support the changes in business. However, that is not only a technical challenge and it is not only about new security challenges and opportunities. It is about governance, guidelines, processes, and organisation.
Unfortunately, as of now, the network infrastructure, network security, storage and virtualization people do not communicate well; not to mention the Exchange, Windows Server, UNIX, SAP etc. people… This is a challenge for both security (no consistency) and “quality of service”. It will take too long to make changes to a virtualized environment when it takes five weeks for the firewall team make a change. This is far from “agile”.
We first saw this problem with Cloud, where we were suddenly more concerned by security within contracts to make sure that anyone doing the setup of our virtual infrastructure could be held to account. The implementation and ideas were much the same as with our on-premise controls, we just wanted assurance that it was happening when we couldn’t see it. Splitting the policies and management from the coding and administration work starts to solve this problem – SDN/SDCI requires the same split. This is the future of the IT organisation, but who, then, is “in charge” of SDCI, who defines the controls and who governs?
Clearly a co-ordinated IT function can continue to control the infrastructure and services, but this needs a clear split between control plane and data plane. Defining the controls is a Security function, as is the overall governance, but conversely these need to be tightly coupled, if not automated on implementation to enable the required agility of system feedback and control improvement. This starts to make Security much more of a business function sitting across silos.
This brings siloed IT organisations to the fore, facing threats from a lack of communication between departments and a lack of network insight/intelligence. SDCI fits across the silos, drawing on the infrastructure beneath it, but not allowing it to prevent continuous communication. The implications for further development of security tools are practically endless. The challenge of doing this fast and with strong governance lies in the organisational siloes. These problems also limit efficiency of organisations. For both, we need to move away from siloes. As with most areas of security, the opportunity for attack is not far behind, and more likely way ahead.
Good governance brings with it the ability to create good guidelines for management and use. Good guidelines across all the siloes need to come from a function, which sits across all of them. In SDCI this will rest with IT functions. Where IT looks to be splitting, Security will become a broader discipline, taking in more legal and commercial aspects, but more focus in each area will be required. This gives the ability, if well organised and defined, for Security to be the enabler of better communications.
At another level of abstraction keeping all the siloes exactly in step will be (practically speaking) impossible, at least in the short term. The larger the organisation, the more disparity there will be between siloes as people naturally work at different speeds. SDCI changes the skills requirements for each silo, so that people with different skills who are currently in different departments, could tomorrow end up in the same one, working together and defining responsibilities. Keeping processes exactly in step might be impossible, but keeping them uniform across an organisation is not, if good governance and guidelines exist to start with. This can keep your organisation on track in the short-term until it adjusts to change over the longer term.
SDNs/SDCI might provide an option to create smaller virtual environments that are easier to control, but clearly the SDCI control layer is increasing the attack surface. Creating a “vertical” instead of a “horizontal” split can remove IT-function siloes whilst retaining business-function siloes. Creating units per business entity that are managed consistently from an IT perspective, covering all areas of SDCI, could be the better approach. This is not necessarily the Holy Grail, but an interesting option to bring IT and Security into line with the business – something we have been looking to do for some time. SDCI and Cloud are great business enablers: a sharing of infrastructure which could lead to the deconstruction of silos within the IT organisation, better business visibility, more business control over IT.
Without changes to the IT organisation, it is doubtful whether SDCI will take off, at least in the short term. We are likely to see failed SDN projects before long, costing a lot of money for little return – just because they are too limited in reach, focusing only on the network part and not the entire infrastructure. SDCI requires a different approach to policies, and the new shape of security within the IT organisation as a whole needs to reflect this. I expect this to be a longer journey, but something that IT organisations need to be thinking about now to adapt in good time.