How to Build Security Systems That Survive Change

TL;DR

Security systems survive change when architects plan for upgrades, revocation, strong partitions, and clearly defined roots of trust from the beginning. Cloud computing, mobile access, shifting regulations, and third-party application partnerships replace familiar boundaries with new risks, so security assumptions must be reassessed whenever the surrounding business or technical architecture changes.

Transcript

Go ahead, Benjun. Hi, everyone. I'm Ben Jun, Vi-VP of Techn... Uh, sorry, let's start over one more time. Sure, no problem. Take a, just take a moment, and then- Okay ... we'll start over again. Okay. I'm ear to ear. H-Hi, everyone. I'm Ben Jun, VP of Technology at Cryptography Research. My topic today is change management or building systems that ... Read More

Key Insights

• Security architecture is change management because systems must preserve required protections even when the surrounding business, infrastructure, clients, or regulatory environment changes. Designs based only on current operating assumptions can become vulnerable when those assumptions no longer describe how the application is deployed or used.
• Cloud computing delivers familiar functionality through a substantially different architecture. Renting virtualized resources by the hour can provide agility, scalability, infrastructure specialization, and fewer operational worries, but it also changes how organizations build, measure, and demonstrate security assurance.
• Identity and access management must evolve beyond assumptions about networks, nodes, and source subnets. Cloud deployment weakens the usefulness of location-based trust, requiring organizations to reconsider how identities are established and how access decisions remain dependable across infrastructure they do not physically control.
• Data security and compliance become harder when information and servers leave premises controlled by the organization. Auditors can no longer rely solely on inspecting a physically controlled server closet, so assurance must come from new architectural controls, defensible partitions, and clearly identified roots of trust.
• Mobile clients introduce risks through limited interfaces, intermittent connections, constrained bandwidth, gateway servers, missing devices, and attacks on phone state. A distracted user may also struggle to recognize phishing or other suspicious behavior when viewing a small interface under difficult conditions.
• Regulatory scope can expand as applications begin processing new kinds of information or supporting new business functions. Sensitive search logs, ancillary connections, coupons, money, payment cards, record availability, and privacy concerns can create obligations that were absent or unclear in the original application design.
• Third-party application partnerships blend data and command streams across services. Social-network APIs, gadgets, widgets, and third-party apps resemble single sign-on, but control rests partly with an outside platform, creating cross-site partitioning, authentication, request-forgery, and user-attention concerns.
• Security upgrades, keys, and revocation must be designed before widespread deployment. Once infrastructure gains users and operational inertia, flaws can become extremely difficult or effectively impossible to repair, as illustrated by insecure parking meters and mature technologies that organizations struggled to replace.

Questions & Answers

Q: How can security systems be designed to survive change?

Security systems can survive change by treating future modification as a core architectural requirement. Designers should establish durable partitions, identify the root of trust, provide mechanisms for security upgrades, and plan how keys can be replaced or revoked. They should also reassess security whenever infrastructure, clients, partners, business functions, or regulatory scope changes, because old assumptions may no longer hold.

Q: Why does cloud computing require a new security architecture?

Cloud computing provides similar application functionality through infrastructure rented by the hour, but removes many familiar physical and operational controls. Data and sensitive computation may reside on public resources rather than controlled premises. Organizations must therefore reconsider network-based identity, logical partitioning, audit evidence, privacy controls, roots of trust, and whether hardware security mechanisms such as HSMs or TPM instances should be virtualized.

Q: What mobile security risks arise from smartphone access?

Smartphones create security challenges because their browsers are thin, bandwidth can be limited, connections may be intermittent, and interfaces make warnings difficult to evaluate. Mobile gateways can mishandle cached credentials or cookies, while access control may depend on shims around the device. Phones can also be attacked through their state, lost, or used while the owner is distracted.

Q: How can mobile gateways expose private user data?

A mobile gateway can expose private information when it improperly caches authentication material or content. The transcript describes a Facebook incident whose exact cause was not published, but suggests that a phone gateway cached too many cookies and delivered pages intended for signed-in users to other people. The example shows how an intermediary introduced for mobile access can undermine session boundaries.

Q: Why can changing business functions expand regulatory scope?

A business change can bring an existing application into regulatory areas that its original designers did not anticipate. Handling payment cards may create PCI concerns, while coupons or money may bring Reg E into consideration. Sensitive search logs and ancillary connections may also be regulated ambiguously. Designers must consider both explicit requirements and the broader purpose behind protections for privacy and records.

Q: What security risks come from third-party application partnerships?

Third-party partnerships combine identities, data, commands, and applications across organizational boundaries. A social-network platform may control sign-on while outside applications access its APIs, and users may join without focusing on security. This arrangement creates concerns involving cross-site scripting, cross-site request forgery, authentication protocols, application partitioning, distracted users, and unintended access between applications of the same general type.

Q: Why is adding security after deployment difficult?

Adding security later requires changing infrastructure that may already be widely deployed and surrounded by operational inertia. Attackers often avoid pilot systems, waiting until a system is stable, valuable, and busy enough to conceal malicious activity. If upgrade paths, keys, and revocation were not designed well, correcting a flaw can require replacing deployed equipment or supporting insecure legacy technology for an extended period.

Q: What does the parking meter example show about security design?

The San Francisco parking meter example shows how a weakness can become extremely costly to correct after broad deployment. Security between the reader and card was inadequate, and the problem was found after most meters had been replaced. An attack could convince a meter to accept a thousand-dollar token. The lesson is to design secure update, key, and revocation mechanisms before rollout.

Summary & Key Takeaways

• Modern applications changed through cloud computing, mobile clients, evolving regulations, and third-party application partnerships. These shifts preserved useful functionality while altering the architecture, boundaries, identities, and controls on which security depended. Security teams must therefore reconsider how they establish trust, protect data, enforce access, demonstrate compliance, and separate applications.

• Cloud computing replaces locally controlled infrastructure with agile, scalable resources rented by the hour. Organizations may lose familiar physical and operational controls, while sensitive computation occurs on public resources. Architects must create logical partitions, reconsider identity decisions based on networks or nodes, and determine whether hardware-backed roots of trust should be virtualized.

• Security failures become difficult to repair after deployment creates technical and business inertia. Attackers often wait for systems to stabilize and attract valuable activity before striking. Update mechanisms must support security upgrades, while keys and revocation require careful initial design. Mobile gateways, blended application streams, and incomplete data restrictions create additional exposure.