Security and Compliance

Adding security to a solution late in the design and development lifecycle often results in costly re-work and usability sacrifices that detract from the solution's capability and user experience. Designing solutions to be secure at the outset helps to ensure an appropriate balance of usability, interoperability, resilience and security for the final solution.

Secure by design is the principle that the design, development and delivery practices of a project must include security and compliance practices delivered by a skilled and experience team. Security design principles, such as those that follow, guide the architectural thinking practices.

The design process needs to start with the use of enterprise design thinking to focus on the required user outcomes for risk, compliance and security stakeholders, both internal and external to an organization. The external stakeholders include customer, governments, and regulators. The internal stakeholders include those managing risk, compliance, and security.

The design process continues with architectural thinking to define the architecture characteristics, architectural decision, functional architecture and cloud deployment model. Definition of characteristics, such as resilience, performance and scalability, are then completed for the security services.

After definition of the requirements and architecture, engineering of the security functionality and infrastructure can take place including following the Secure by default principle.

IBM has a long-standing approach to security and privacy by design used in the development of products. The published IBM Redpaper on Security in Development: The IBM Secure Engineering Framework is useful to review.

Where users or software with a system have excessive privileges there is a risk of misuse, either accidentally or deliberately. Threat actors may compromise the privileged accounts of internal users and use the rights to traverse the network and systems.

Least privilege is the principle that states that the system should give users or software the minimum capabilities needed to carry out their intended task. The system should implement this from the highest level in an application down to an individual connection between two software components.

To implement the principle of least privilege, you must understand the assets in your dynamic IT environment. Privileged access isn't just a people problem; you need to know what applications have access to what data. The process of discovery, classification, and risk assessment is continuous. Bring together risk data from your digital assets to uncover new business level risk insights to help you establish the right policies.

A user or software may have a secure context at the point of initial identification and authentication for a session, but a treat actor may compromise the active session and used it to further compromise a system.

Continuous verification is the principle that a user or software must be constantly verified to evaluate whether they still have a secure context. The intent of continuous verification is to find security issues and vulnerabilities as early as possible and ideally threat actors do.

Continuous verification confirms that entities are who, or what, they claim to be using challenges such as a second factor authentication request. A workload may require updating to support continuous verification of users and software using solutions using a Zero Trust Network Architecture (ZTNA). Organizations focused on delivering best-in class user experiences hesitate to disrupt the user with unnecessary requests; however, this level of identity assurance is critical for zero trust.

A threat actor may already have breached an organization. If an organization only looks for threats at the external boundary and not for threats that have used an valid mechanism to bypass the boundary control, they may not discover a breach for a long time.

Assume breach is the principle that an organization assumes a breach has taken place by a threat actor. The intent is to detect a threat as early as possible even if a compromise has bypassed

The approach requires threat management should add proactive internal detection, look for early warning signs, threat hunting, and use of proven runbooks. Detection and response must be tightly integrated with the insights and enforcement layers, sharing context and dynamically adjusting access control policies in response to identified threats.

An information system will have vulnerabilities in the software, firmware, and hardware. Configurations and software will change, and new vulnerabilities will appear. If one layer of defense is vulnerable, the system needs to remain secure.

Defense in depth is the principle that a system has multiple layers of defense so that if one layer fails, another layer remains in place to protect the sensitive data in the system. Using a layered approach to a security strategy ensures that an organization can stop an attacker at a subsequent layer when one layer of defense is breached.

The enterprise security strategy and architecture must include measures that offer protection across the subsequent layers of the traditional network computing model. Generally, an organization needs to plan security from the most basic (system level security) through the most complex (transmission level security).

An organization’s attack surface is the sum of vulnerabilities, pathways or methods—sometimes called attack vectors—that threat actors can use to gain unauthorized access to the network or sensitive data, or to carry out a cyberattack. As organizations increasingly adopt cloud services and hybrid (on-premises/work-from-home) work models, their networks and associated attack surfaces are becoming larger and more complex by the day.

Minimize attack surface is the principle that a system should reduce the scope for attack vectors so that it reduces the possible ways in which a threat actor can gain access. Security experts divide the attack surface into three sub-surfaces: The digital attack surface, the physical attack surface, and the social engineering attack surface.

1. The digital attack surface potentially exposes the organization’s cloud and on-premises infrastructure to any threat actor with an internet connection. Common attack vectors include network access, software vulnerabilities, enablement of unused resources, shadow IT and out of data software.

2. The physical attack surface exposes assets and information typically accessible only to users with authorized access to the organization’s physical office or endpoint devices. This includes attacks by malicious insiders, device theft, and “baiting” - an attack in which threat actors leave malware-infected USB drives in public places with the hope of tricking users into plugging the devices into their computers and unintentionally downloading malware.

3. The social engineering attack surface manipulates people into sharing information they shouldn’t share, downloading software they shouldn’t download, visiting websites they shouldn’t visit, sending money to criminals, or making other mistakes that compromise their personal or organizational assets or security.

An organization should assess the risk to the sensitive data being processes by the system examining each of these attack surfaces.

Users could have access to highly sensitive data that enables a bypass of controls, such as encryption keys, or have the rights to perform highly privileged actions, such transfer large sums of money. Even when a system monitors users, they may abuse their rights resulting in catastrophic business consequences.

Separation of duties is the principle that users with powerful access to data or actions require more than one user to complete the action. It provides an organization the ability to divide administrative functions across individuals without overlapping responsibilities, so that one user doesn't hold unlimited authority.

With activities such as managing encryption keys, the organization will require encryption key administrators to manage different parts of a key so that no single administrator has knowledge of the whole key. With business transactions, the application may require a person requesting a transaction to have one or more approvers for it to complete.

For some industries, a regulator may require separation of duties for powerful functions as a part of regulatory guidance. Separation of duties helps businesses comply with government regulations and simplifies the management of authorities.

Products or services contain many different points of configuration and there is a desire to make then as easy to use as possible. As a result, the product has an insecure security configuration such as network ports open or allowing easy to remember passwords.

Secure by default is the principle that an organization received products or services configured in a secure state out of the box. The products are setup to protect against the most prevalent threats and vulnerabilities without end-users having to take additional steps to secure them.

A system may be securely configured at the start, but a developer can subsequently make a change that modifies the configuration or a threat actor makes a change through a vulnerability that compromises the system.

Continuous compliance is the principle that the security configuration of the system is constantly checked, starting with the system development through to the ongoing running system. The intent of continuous compliance is to find security issues and vulnerabilities before threat actors do.

Ideally compliance checks are all automated and covers all security configurations including the cloud platform, the container platform, middleware and compute images such as virtual servers and containers. With compute images, a better approach may be to use Infrastructure as Code (IaC) to replace the whole image regularly.

Shared responsibilities for the delivery of security and compliance in a hybrid cloud environment depends on the service models, compute platforms, and cloud service providers used by the workload or application. A security architect must document and communicate the responsibilities covering the design, build and run of the security services. Without clarity, gaps may exist in the security of the solution.

Each dimension has a different impact on shared responsibilities:

• Cloud service model - The NIST definition of cloud computing the different scope of responsibilities depending on the cloud service model, such as IaaS, PaaS, SaaS or distributed cloud. Security services are part of the shared responsibilities. For example, the shared responsibilities for IBM Cloud include identity and access management, and security and regulation compliance. The shared responsibilities for these categories vary depending on the cloud service model.

• Compute platform - The hosting of a workload may be one or more compute platforms, such as bare metals servers, virtual servers, container platforms and serverless. Each compute platform has a different set of shared responsibilities. For example, bare metal servers require the owner of the workload to be responsible for all the security controls on the platform except for the physical hardware and network integration.

• Cloud service provider - The responsibilities also change depending on the cloud service provider. For example, the kubernetes platform from each cloud service provider are different (unless you are using Red Hat OpenShift) as each consists of a different set of curated open source packages.

So why should a security architect care about the differences in service ownership? The team providing security operations may have predefined security services to support the running of the service. The security services may be a part of the cloud platform or may be on-premises requiring extensive integration.

For example, an internal security operations team may use a different technology from a global systems integrator (GSI) such as IBM Consulting. For the internal security team their security control plane hosting the security services may be on-premises, whereas the GSI may be using cloud security services provided by another cloud service provider.

For the Software-as-a-Service (SaaS) cloud service model, only application security administration is available to the consumer of the cloud service. Security is normally built-in to the application as a part of the service with limited scope to control the security configuration. In this case the SaaS provider holds most of the security operations responsibilities.

Without documented responsibilities, there might not be owners assigned to design, build and run security components that are a dependency to the running of the workload. Understanding shared responsibilities for the security services enables the solution architecture to meet the operational needs and avoids a rework of the solution at a later stage in the project.

Security services in a hybrid cloud architecture use different cloud service models, compute platforms and cloud service providers. These services need an agreed control plane architecture to give consistent management and oversight of security and compliance.

With an enterprise that has on-premises data center workloads, the control plane may reside in an on-premises data center to be resilient to a failure of a cloud service provider. However, an on-premises security service won't necessarily have the ability to fully manage the cloud platform. Therefore, architect a control plane architecture to report security status and identify risks across the different cloud service providers.

With born-in-the-cloud organizations, hosting of the control plane could be another cloud, hosted in a point-of-presense (POP), or hosted in a co-lo data center. The security control plane may need to be available, even if a failure in a cloud service provider has occurred.

As a security architect, it's important to document and agree an architectural decision to ensure alignment on the security control plane architecture across an organization. Make this decision early on in the project to ensure the solution meets the strategy of the organization.

Security isn't primarily about deploying security capabilities, it's about protection of business data and processes from threats. Use a systematic approach to trace the data flows through the system to identify the security controls to protect data in transit, at rest and in use.

Architects must identify sensitive data for protection by starting with a system context diagram to identify the system boundary and external interactions that initiate the data flows through the system. Internal data flows of the application are then examined using a diagram to described the functional components, such as a component diagram.

As architects move onto the implementation, they examine the data flows between the components deployed onto the cloud infrastructure using a cloud architecture diagram. IBM has created a technical diagram design language that enables a design that's independent of a cloud service provider.

To identify the threats to these data flows, use threat modeling both for the workload functional components and the infrastructure for the workload.

Together these techniques and artifacts offer a repeatable and consistent approach to architectural thinking for security and compliance.

When processing the most sensitive data, consider another layer of protection by using confidential computing and homomorphic encryption.

A system needs to meet many different control requirements and the list can get long and difficult to manage. Instead of working with many individual requirements, work with processes, services or capabilities that group the requirements into delivery capabilities. For example, identity lifecycle management or unauthorised component detection are potential delivery capabilities.

Follow these steps to more effectively to manage compliance:

1. Create a single compliance framework with traceability back to the original sources.
2. Map the requirements in the compliance framework to a set of delivery capabilities
3. Ensure compliant capabilities at all stages of design, build, test and operation.
4. Continue to comply to requirements in production.

The security architect must ensure the security capabilities have associated Service Level Oobjectives (SLOs), responsibilities agreements and so on.

There is often a need to ensure data from one client, line of business or environment doesn't leak to another. Separation needs to take place for the running of the workload and storage of data. It could be as simple as a different table in a database or separate physical servers.

Hybrid cloud offers many options to enforce separation of data processing. Separation should take place between:

1. Workloads or applications - for example, accounting vs human resources
2. Environments - for example, development, test and production
3. Clients - for example, customer A vs Customer B
4. Location - for example, United Kingdom vs United States

There are many different options for segregation within a hybrid cloud environment that offer different capabilities and assurance:

1. Enterprise Account
2. Cloud Account
3. Resource Group
4. Virtual Private Cloud
5. Execution domain - for example, a container or server image
6. Project
7. Key Management Domain
8. Physical devices

The organizational policies must define what type of separation is appropriate for the workload that's processing the data. For example, the policy may require that the hosting of the production customer data must not be in a non-production environment. The minimum level of separation needed is a different cloud account as that's where the management of identity and access is taking place.

Related to the topic of data separation is that of data sovereignty. Certain countries are imposing constraints on where the processing and access of data can take place. The "Addressing Regulations and Driving Innovation with Sovereign Cloud blog post" provides a discussion on a hierarchy of the needs for data sovereignty.

Threat modeling is often thought of as a technique to identify and validate the security controls for data flowing through a system.

However, threat modeling has a second purpose - to identify threats for monitoring in a threat monitoring system. The security architect must work to identify a prioritized list of threats. Then define the required threat detection use cases for the threat detection capability. Implement and test the detection use cases with incident response runbooks to enable effective response to threats.

Ensure documented traceability between the threats, threat detection use cases and incident response runbooks to ensure complete design and delivery for the project.

With on-premises data centers of the past, security operations teams completed activities in a matter of days or hours and didn't require stringent service levels. With Infrastructure as Code (IaC) automation, the loss of a centralized security service such as secrets or certificate management, has an immediate impact on the availability of an application. Therefore, security services require service levels and an architecture to meet the availability requirements.

Define for each security capability or service:

1. Hours of service
2. Incident, problem and change response times
3. Skills and experience of operations staff
4. Detailed tested procedures to match the service requirements
5. Automation to match the service requirements

If the internal security operations team can't meet the demands of a cloud native workload, consider whether a managed security services provider is appropriate.

If you think about it, many security services today need resiliency and service levels that are at least as good as the workload they support.

Old ways of working meant that security was an afterthought making security configuration and patching difficult to complete as it wasn't early into the development lifecycle. With DevOps working practices, the security build standards need to be:

1. Included into the development and test environments.
2. Be consistent from initial development to full production.
3. Be continuously tested for ongoing compliance.

The build processes must prevent insecure deployment of a workload at all stages of development and operation to ensure security isn't an afterthought.