Software Defined Security

In the simplest terms, it's the difference between the clientserver-based model using an on-premises server, and a fully cloud-based model with no onpremises architecture beyond its internet point of presence and local access points.

The client-server model, when expanded out to the internet, required perimeterbased thinking about security; it required layered defenses, or defense in depth. It also trusted that a layered defense strategy did not have to distrust users, agents, or entities that were moving laterally within any given layer of the overall architecture.

This paradigm shift disrupts the comfort zone that security architects have had for several decades now. It recognizes that the sophisticated attackers of the present decade are outsmarting the defenders, over and over. Back in 2018, industry pundits and security systems and services providers were rallying to the cry of "defense in depth is dead!" as a way of signaling the need for a sea change of thought.* SDS is part of that sea change.

• As with any slogan, the market was quick to clarify: traditional defense in depth had no effective control over lateral movement within a layer, and had minimal, if any, defense against an insider threat. It's not layers per se, the pundits said, that were being objected to.

Shifting this enterprise to software defined

Consider a large-scale, globe-

security brings a number of important

spanning enterprise system

advantages to the organization:

consisting of 50 geographically dispersed operating locations, • It centralizes the control (or management) plane for all network

serving nearly 10,000 internal

segments, reducing overhead while users.

enabling enterprise wide changes to defensive infrastructure elements to be made rapidly. In today's cloud-based environments, most,

• It enables a greater shift to virtualized

if not all, their valuable information assets security appliances, which can reduce are in cloud-hosted storage, applications or eliminate dependence upon specific platforms, or data warehouses and data lakes, serviced and made available by hardware (or vendor) capabilities. scalable armies of virtual machines. Their workflows and business logic require a fairly • It enables security policies, from the most global to the most local, to shift to an onrobust microsegmentation of networks demand, highly agile and adaptable form.

and services at each location; they have to actively manage endpoints to stay secure. (

• It can eliminate the need for older

Just that microsegmentation alone could

converged protocols, like MPLS, by

mean that this enterprise needs hundreds, providing more flexible virtual overlays perhaps thousands of network devicesand network sharing capabilities.

firewalls, routers, and so forth. They've got an infrastructure of NIPS and NIDS in place.

• It changes the threat intelligence Each of those devices and systems needs to paradigm from reactive to predictive, be configured, managed, maintained, and by enabling the combination of machine listened to. Their SIEMs and their SOAR and human learning to anticipate threats. systems do this to a large degree.

SDS, properly implemented, can also provide a bridgehead to a more holistic approach to all-source risk management and mitigation.

This paradigm shift is shown conceptually in the figure, which highlights how each successive generation of systems security management and control concepts both relies on the functional foundations built by its predecessors, while enabling the organization to achieve new security capabilities. And it all starts with identity management and access control.

It's important to stress that the "traditional" componentlevel elements of systems haven't gone away.

Enterprises need to control access to their Layer 2 internet services at each of their locations, many of which may support the work of hundreds of employees as they collaborate (locally and remotely) with suppliers, vendors, customers, prospects, regulators, investors, or other stakeholders. Even if that local Wi-Fi mesh is replaced with complete reliance on the public switched mobile communications fabric, there's still the fundamental problem of identity management and access control*. Every user, human or nonhuman, and every device, software entity, or process used by or invoked in support of them, must be subject to the full IAM suite of control. This is the rock on which SDS must stand, before it can start to become holistic in its stewardship of the organization's information

You'll note that this is a powerful example of risk transference; how such a strategy delivers against each of the C/ANA+PS security needs would reveal how costeffective such a shift away from any onpremises infrastructure might be. Either way, there's still all of those endpoint devices to consider, secure, and manage.

Advocates for software-defined security point out that in non-cloud or non-virtual (traditional") computing environments, integration and operational use of these functions becomes complex and unwieldy. It becomes far too hard to enumerate every endpoint, every connection that is in use, every port or connection on the LANs that exist but are not in use, every unit of software, every data asset, and every user access attempt. It becomes even more challenging to keep that inventory, and its health and status with respect to updates and patches, consistent and current, day in and day out. It is in fact quite challenging to physically instrument every physical host and endpoint, let alone gather the data from

security needs.

them all.

By contrast, these advocates argue that in virtualized systems, all of this knowledge is available moment by moment to the hypervisor layer in each compute resource cluster or stack.

Bringing software-defined security into this environment is done by defining new virtual system types that contain all of the architectural elements needed for a security function (which may need one or many distinct virtual machines, their own virtual subnets, their own isolated virtual storage, and so forth). Once these templates are spawned and start executing), their security administrators can then use their privileges to start hooking the virtual security functions into other virtual systems.

In many situations, software-defined security is used to implement and control other virtualized services, such as firewalls (which can span from the network layer up through the application layer), intrusion detection and prevention systems, and vulnerability scanners. This can enable the SDS management function to perform workflow monitoring as well.

The SDS Revolution: Many Concepts Around a Core Set of Functions

From the largest software and cloud systems giants to the smallest security services provider, nearly every organization involved in the shift, the cloud is bringing new ideas, products, and services into the "SDS space" in the market.

Cato Networks and Proofpoint, for example, talk in terms of software defined perimeters, while Cisco Systems is working with software defined access. Microsoft has published a number of strategic plans that show how they are taking their own cloud migration ideas seriously; they intend to be the first cloudonly organization in the world, and SDS is a pivotal part of that strategy.

That last point is worth a closer look. This does not say that "perimeters are dead" several things are already or that layers within layers as a security clearly established as part of concept have become extinct. ZTAs are the superset of functions and known for their use of microsegmented ideas now being thought of as network strategies, along with the 1AM functions that make them workable and software-defined security:

securable. But this should not be mistaken as just a relabeling of defense in depth. For example, loT usage is growing in

• Identity management is absolutely vital to

importance for many organizations.

success of any security effort.

• Entities, not just users, must be the level at which identity is defined, authenticated, managed, and tracked.
• Defense has to shift to becoming more proactive, which means that defenders have to start learning as fast as attackers have been. Every member (human and nonhuman) of an organization's security team, and the organization itself, must take on this need for greater fluency and proficiency with cybersecurity, information assurance, and information asset protection.
• Systems and solutions must be agile, flexible, and responsive.

would suggest that highly localized segments be defined for each type, class, or use case of loT, with trusted agents acting as the brokers between an loT segment and other areas of the overall architecture. (loT devices in a warehouse or manufacturing area, for example, don't seem to categorically have a valid business case for accessing human resources or finance and accounting systems over the organization's federated systems. This means that no loT device should be able to get out onto the SSOguarded federated digital superhighways of the organization, so to speak.)

• Access management has to be pushed down to the lowest level asset; server-level or system-level access cannot be a part of a routine user business model anymore.
• Zero trust architecture concepts both enable SDS solutions and are required by them.

SDS and Assessment: Two Questions

Taken all together, the capabilities that softwaredefined security can bring to the organization can lead to a near real-time ability to detect compliance issues, such as workflows that are easy to escape from while in use, or data being copied or moved.

Regardless of whether the security assessment is conducted for formal compliance reasons or for informal, internal management understanding and decision making, such assessments still need to address two fundamental, intertwined questions:

The primary question is in some respects a special case of the third-party security assessment problem. Placing all of your organization's security capabilities and your compliance requirements into the (virtual) hands of an SDS installation requires a significant degree of trust. Maintaining that trust needs to consider that system as a mission-critical, high-value asset, and its software, data, operational use, and the outputs it produces must be protected accordingly. Selection of an SDS vendor, either for a system for in-house operation or as a managed security services vendor, must take your organization's assessment and compliance needs into consideration right from the start.

• Are the systems the organization depends upon operating as required to meet both compliance needs and the reality of today's threat environment?
• Are the SDS and other security processes we have put in place working correctly?