The Future of Electronic Content Management (in a De-perimeterised Environment)

The Future of Electronic Content Management(in a De-perimeterised Environment) Presentation at Fronde 131 Queen St, Auckland Prof. Clark Thomborson 2nd May 2007

Outline • What is Enterprise Content Management? • Requirements: • NZ government’s advice to agencies, • Jericho Forum’s “commandments” and position papers. • The Future of ECM

Communication Security 101(within a single hierarchy) • Anyone can send information to their manager. • Downwards email traffic is trusted: • it is a security risk; • it is not allowed by default; • it should be filtered, audited, … King, President, Chief Justice, Pope, or … Peons, illegal immigrants, felons, excommunicants, or … • Definition: Trustworthiness (an assurance) implies that trust(a risk-aware basis for a decision) is well-placed. • We cannot act unless we trust!

Intracorporate Communication • Hierarchical communication is very inefficient. • The King is a performance bottleneck. • We want all our employees to share information freely – but without information overload! • Contemporary ECM systems provide virtual “meeting spaces”, “notice boards”, and other information sharing opportunities within the corporate perimeter.

Emperor Intercorporate Communication Q: How do we handle email between hierarchies? Answers: • Merge/Federate • Subsume • Bridge Company X Agency Y • Who will be the Emperor = King(X+Y)? • Note: a federation is similar to a merger, where the constitution of the system is its Emperor. The peers agree to abide by the constitution. • Merging isn’t enough to solve the problem, until there is one empire.

Email across Hierarchies Q: How do we manage email between hierarchies? Agency X Answers: • Merge • Subsume • Bridge Company Y

Bridges Q: How do we communicate between empires? Answer: Bridge! Company X Agency Y • Bridging connection: trusted in both directions. • The person forming the bridge has a separate “persona” who is a low-privilege member of the other corporation. • Bridges are a nightmare for security analysts! • Employees will use hotmail, instant messaging, blogs, USB devices, ...

Bridging Trust: B2B e-commerce • Use case: employee C of X purchasing supplies through employee V of Y. • Employee C creates a hotmail account for a “purchasing” persona. • Purchaser C doesn’t know any irrelevant information. Company X Company Y Employee V C, acting as an employee C, acting as a purchaser • Most workflow systems have rigid personae definitions (= role assignments). • Current IT systems offer very little decision-support, security, or governance for bridges. Important future work!

Communication Security 201(within a single peerage) • Information flows upwards by default (“privileged”). • Downward information flows are “trusted” (filtered, audited, etc.) Peers, Group members, Citizens of an ideal democracy, … Facilitator, Moderator, Democratic Leader, … • Most businesses have some peerages within their hierarchy: partnerships, job-shares, shareholder votes, ...

What is an ECM system? • ECMs build (and advertise) bridges to • Facilitate intra-enterprise communication, • Facilitate intra-federation communication, and possibly • Facilitate inter-federation communication • Bridges are extremely important for performance, but they create security risks. • Every bridge to an external organisation should be subject to managerial oversight. • The “rules of the bridge” must be defined before a bridge can be used safely. Perhaps a contract should be signed? • Employees need guidance and technical support, when forming and using external bridges.

2. ECM Specifications • My suggestions. • The Jericho Forum’s commandments and white papers. • NZ government’s “advice to agencies”.

My Suggested Requirements • The primary emphasis is on functionality. • Employees need decision support for the formation and maintenance of hierarchical, bridging, and peering trust relationships with other systems and individuals. • Security must be “designed into” the system. • Data Security: integrity and availability. • Confidentiality is less important. • Process Security: accountability. • Prevention is not appropriate, because this will impede important communications and actions. • Security Governance: • Standard specifications, auditable for assurance. • Mass-market implementation (not bespoke!)

The Jericho Forum: Structure • User members are large corporations and a few governmental agencies, who • Own the Forum; • Vote on the deliverables; • Run the Board of Managers. • Vendor members • Have no votes; • Participate fully in discussions. • We now have 12 vendor members, and want more. • Academic members • Offer our expertise in exchange for information of interest. (Academics trade in ideas, not $$.)

Jericho’s De-perimeterized Security • Observation: we drill holes through all our firewalls! • A corporate perimeter defines a quality-of-service (QoS) boundary, not a security boundary. • We are hardening our platforms, and our data objects, so that we can take advantage of the high connectivity and low cost of the internet. • We can make trustworthy connections on an untrusted network, if we have a way to identify trustworthy communication partners. • Our systems should use open standards, to allow interoperability, integration, and assurance.

Some Members of Jericho http://www.jerichoforum.org/

Jericho’s Position Paper on EIP&C • Enterprise Information Protection & Control requirements: • Key escrow and key management; • User identity and the management of users outside your domain; • End-point security must be assessed before access is allowed; • Data should be classified, typically by the originator, including temporal conditions (destruction, release); • Auditing of rights information; segregation of duties. • “Current EIP&C solutions are proprietary, limiting their applications by enterprise domain, operating system family or to specific applications.”

Jericho’s Challenges for EIP&C • We want a standard client interface/software, • because it is undesirable and unlikely that any corporation can mandate that another company install and manage their preferred EIP&C solution. • We want a standard set of agreed EIP&C classifications. • We want an open, inherently secure protocol for consumers of EIP&C protected data to communicate with the server or enterprise which controls the data’s EIP&C attributes.

New Zealand’s Principles for DRM and TC in e-Government • Last year, the New Zealand Parliament adopted a set of principles and policies for the use of trusted computing and DRM in its operations. • http://www.e.govt.nz/policy/tc-and-drm/principles-policies-06/tc-drm-0906.pdf

New Zealand’s First Principlefor TC/DRM in e-Government • “For as long as it has any business or statutory requirements to do so, government must be able to: • use the information it owns/holds; • provide access to its information to others, when they are entitled to access it.” • Other sovereign governments, and all corporations, will require a similar assurance. • Key control is a primary vulnerability in ECM/DRM. • To mitigate this vulnerability, I would advise governmental agencies and corporations to separate their key-management systems from their DRM/ECM systems. • System interfaces should conform to an open standard, so that there can be secondary vendors and a feasible transition plan to a secondary vendor.

NZ e-Government Principle #2 • “Government use of trusted computing and digital rights management technologies must not compromise the privacy rights accorded to individuals • who use government systems, or • about whom the government holds information.” • This principle may be infeasible: too expensive to implement in each jurisdiction. • Can a standardised TC/DRM/ECM technology support our diverse privacy requirements? • Can a privacy-preserving TC/DRM/ECM satisfy our diverse requirements for law enforcement and national security?

NZ e-Government Principle #3 • “The use of trusted computing and digital rights management technologies must not endanger the integrity of government-held information, or the privacy of personal information, by • permitting information to enter or leave government systems, or • be amended while within them, • without prior government awareness and explicit consent.” • All sovereign governments, and all corporations, have similar requirements for high integrity, for confidentiality at the perimeter, and for assuring their “customers” that they will respect privacy.

NZ e-Government Principle #4 • “The security of government systems and information must not be undermined by use of trusted computing and digital rights management technologies.” • A supporting policy: “Agencies will reject the use of TC/DRM mechanisms, and information encumbered with externally imposed digital restrictions, unless they are able to satisfy themselves that the communications and information are free of harmful content, such as worms and viruses.” • Implication: when a document crosses a “bridge”, it must come under the full control of its current possessor. • Access rights must be enforced by contract and by statute. • If someone else holds the decryption keys, then the possessor cannot effectively scan for malware!

3. The Future of ECM • Microsoft’s SharePoint 2007 has excellent support for bridges within a single enterprise or federation. • It has little support for secure inter-enterprise communication. • Groove is a very promising “bolt-on”. Does it use open standards, or is it creating bridges within a single empire or federation? • GoogleApps is another promising approach. • There must be others... • Must we choose an empire? • Who will pay the cost of developing standards for interoperability? • Who will pay the cost of assuring that each empire abides by “our” standards? • By analogy: the UN is expensive. Would we be better off if “gunboat diplomacy” were managing all relationships between empires? It would certainly be cheaper...

Trustworthy Bridges • Employees must be able to make trustworthy bridges to any trustworthy external organisation. • Bridges must be subject to managerial oversight. • Employees must be given guidance. • There should be whitelists of corporations and bridge technologies, as well as some blacklists. • Managers will require decision support from “reputation management systems” in order to maintain whitelists and blacklists. • The ECM system must interoperate with reputation systems, workflow systems, customer relationship management systems, human resource management systems, key management systems, and many other systems. • Standardized interfaces are essential! • Will we have supplier-driven standards, or will the customers band together to express their own requirements?

Auditable (Governable) ECM • We should require all our prospective communication partners to produce audit certificates for their platforms and systems. • We should enforce this requirement with contractual agreements on the use of “bridges”. • Systems that should be audited (partial listing) • Cryptographic Key Management Systems, for completeness: do we have keys for all our encrypted and signed documents? • Cryptographic KMS, for destructions: a key cannot be deleted from the KMS until it has been revoked in all zones of control which might be caching it or relying on it. • Identity Management Systems, for completeness of role-records and signing authorities in ECM and workflow systems. • ECM systems, for completeness of document receipts: no documents can be created or destroyed without an audit trail.

The Future of Electronic Content Management (in a De-perimeterised Environment)