Jericho Commandments, Future Trends, & Positioning

1. Jericho Commandments,Future Trends,& Positioning

2. Fundamentals 1. The scope and level of protection must be specific and appropriate to the asset at risk • So as to add flexibility to meet new business requirements and increase speed of deployment • Central protection decreasing in effectiveness • Boundary firewalls might protect the network, but individual systems and data need their own protection 2. Security mechanisms must be simple, scalable and easy to manage • Unnecessary complexity is a threat to good security • Small things will need to interoperate with large things • Must support chunking/lumping

3. Surviving in a hostile world 3. Devices and applications must communicate using open, secure protocols • Assume eavesdropping, overlooking, injection • Security CIA requirements should be built in to protocols, not add-on • Encrypted encapsulation doesn’t solve everything 4. All devices must be capable of maintaining their security policy on an untrusted network • must be capable of surviving on the raw Internet • “Security policy” = CIA status

4. The need for trust 5. All people, processes, technology must have declared and transparent levels of trust for the transaction • Clarity of expectation • No surprises • Trust level may vary by location, transaction 6. Mutual trust assurance level must be determinable • Devices and users must be capable of appropriate levels of (mutual) authentication for accessing systems and data

5. The need for mutual authentication 7. Authentication must interoperate / exchange outside of your locus of control • Must be capable of trusting an organisation, which can authenticate individuals or groups – no need to create separate identities • Only need one instance of person / system / identity, but can also support multiple instances

6. Finally, access to data 8. Access to data should be controlled by security attributes of the data itself • Could be held within the data (DRM) or could be in separate system • Could be implemented by encryption • Some data may have “public, non-confidential” attributes 9. By default, data must be appropriately secured both in storage and in transit • Removing default is conscious act • “Appropriate” also allows some data to not need securing, must not enforce high security for everything 10. Assume context at your peril

7. 11. Deperimeterisation is inevitable • It will happen in your corporate lifetime • Therefore you need to plan for it • Therefore you need a roadmap • And JF has generic roadmap

8. TransactionalCapability • Public information – view only • Restricted information – view only • through to • High value information • High value transaction • Trust level • Untrusted • Trust the protocol • Trust the person/process • Trust the environment • Full trust • RiskLevel • No Risk • Low Risk • Medium Risk • High Risk

9. Security Protocols Secure Insecure Point Solution Use with Care! e.g. AD Authentication Use and Recommend e.g. SMTP/TLS AS2 (EDI/HTTPS) HTTPS, WPA2 Use only with additional security (force disuse of ‘security’ features) e.g. SMTP, FTP (use TFTP), TELNET, VoIP, … Stop/Retire (Now!) e.g. NTLM Authentication Closed/Proprietary Open

10. Buy, Hold and Sell

11. Corporate Roadmap

12. Desired Future State Work Types Needs Principles Strategy White Papers Patterns Use Cases Guidelines Standards Solutions Vendors Customers Customers Workflow Vendors Standards and Solutions