Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

How should we perceive Security in the Cloud

Slides of topic talk considering cloud security

  • Identifiez-vous pour voir les commentaires

  • Soyez le premier à aimer ceci

How should we perceive Security in the Cloud

  1. 1. Capability based SecurityHow we should perceive security forthe CloudYasir A. KaramFeb 2012
  2. 2. Where Do We Come From? What Are We? Where Are We Going?
  3. 3. The answer is λ(and the Y combinator)
  4. 4. Functional Orientation of LifeTwo Facts about Mankind :- Man never made up lazy, He never evolved withoutfunctioning, Every part in Man’s body functions to reasonliving. Man’s life end with all functioning parts stop.- Man born in obliviousness from childhood to senility
  5. 5. Cloud Computing, The Lispy Way• First-class and higher-order functions• Pure functions• Recursion• Eager evaluation• Type systems Cloud Computing, The Scala Way• Has case classes and built-in support for pattern matching• Support for dynamic/multiple inheritance with Traits and Mixin’s• Polymorphic methods
  6. 6. What Are We?Groups and Fields can be defined in terms of:• Shared Community• Shared Tools• Shared Literature• Ecological Niche• Aggregation of Functions
  7. 7. We are a Shared CommunityBut is the community healthy?• Defensive stance (like Apple or Linux) – Minority, with some zealots, past-looking• Numbers holding steady(?)• But the world is consolidating on C++/Java – See http://www.norvig.com/Lisp-retro.html – C++/Java way out in front – Lisp comparable to Perl on Books, Usenet, URLs – But Lisp far behind in Job postings
  8. 8. We do share responsibility• Mastering life, we do contribute in delivering value to it• We do this through sharing accountability of how we perform• The role others play on behalf of us is key concern to undertake risk• Dependability and Delegation are same but difference lies in progression of trust relationship• Such progression is compromised through introspection
  9. 9. What is Computing relation to Distribution?• Computing main goal is to produce value through calculations of the mathematical problems inferring the world• Logic is the representation of inference• Problems are represented through abstracts• Problems are sliced through dissemination of Accountability and Responsibility• Sharing responsibility to deliver value is through dynamic scalable utilization of resources• Resources are first class functioning informative elements
  10. 10. What is Programming• The language in which abstracts can talk to each other• Languages should consulate context aware• This contextion mostly prevails domains• Concepts, Aspects, Subjects, Views are yet to convolve around objects because
  11. 11. Time Matters• Evolution problems take place in lifetime• Realtime is the lifetime we span during living• Time is nothing but a metaphoric• Pragmatic evolution is done through slicing problem over time – Time to Cognate (conceptualizing, intending, requiring) – Time to Represent (modeling, describing, formalizing/axiomatizing, composing, constructing, morphing) – Time to Reason/Rationalize (predicting, logical binding/inferring, early testing/evaluating) – Time to Resolve (result computing,• Life is a project with planned milestones• Life span is the parent of set of milestones in this master plan• Life ends on the edge of finding nearest solutions to a problem
  12. 12. What is Meta Life?• Since all is virtual then all driven with the metaphor• Meta-cognition = Recognition through conceptualization• Meta objects, meta models and meta languages are used to describe metacognition of the world
  13. 13. What Neptune can Solve Now?• More precise intentions and focus on Problems and how will they be solved• Assurance is no more a big problem, its now solved via Early and Late binding• No cost will be paid unless farthest goal is evaluated• Value based dispatching through introspective delegation (exchange of accountability)• Planned invocation through stages between Early and Late binding
  14. 14. Secured Composition with Neptune• Security in Distributed Computing Environments is of how to deliver assured Value agglomeration of Acting functions efforts• Effort is represented with Capability• Clouds desperately rely on refilling fuel dynamically on the fly• Clouds are made virtually to deliver value through resolving problems• Clouds do this through elastic resource acquisition (on-demand , as-you-go)• Cloud’s resources first class functions
  15. 15. Secured Composition with Neptune• Modeled actors in the cloud should not provide every specificity to each’n everything• Clouds should provide auto-focus• In fact clouds should stimulate actors to only focus on how to marinade ideas from life• Clouds dictates actors obliviousness• Neptune in somehow eliminate the burdens of internal chemical reactions from farthest objectives• Neptune’s systemized way to harness these through instantaneous temporal intentions• That’s why Neptune dictates continuous change and moreover running with time
  16. 16. New approach to Security fits more…• Cloud actors are oblivious, they no more care about non-functional layers in the play• Security is only one aspect among many others but could be of most importance• Design goals to this problem is to get different abstract understanding to what does secure composability mean• Secured composability mean assured delivery of value• Assured provisioning through consistent access authority• Privileged access through public keys are supported• Policy/rule based access to information• Delivery of value is how to resolve value to a function
  17. 17. Non-determinism is a principle characteristic to the cloud • Perfection through rich specifications (specifications are not programming). • Specifications how much expressiveness we provide to describe beauty of the world through models and languages • Better Specifications with Description Languages • Deterministic clauses through predicate logic • Recursive constraint based logic • Eager Predicting with Futures and Promises
  18. 18. Neptune now supports Capability based Security• Controlled stitching – Double stitching (multi-dimensional weaving) – Horizontal stitching through Aspectization – Diagonal stitching through Subjectizatgion – Dynamicity through core concepts – Dynamic auto-focusing through• Neptune showed how to sincere Resources• Constrained dispatching• Everything is a thread, composition based concurrency• Lazy evaluation, no energy will be dissipated on non value resolving invocations• Risk is the effect from delegating un-efficient actors partnering a joint venture• Either we accept risk or re-delegate it to other actors• All delegation process is done automatically via Transparency Invocation• New concepts can be Injected dynamically at runtime
  19. 19. Examples of Insecure Invocation• Interoperation goal is anticipated from Integrating (Gluey) Legacy and Modernized environments• Adapting immature domain levels that cant fulfill desired goals (Coherent Granularity through non rationalized concretization)• Poor contractual designs aspects• Failure to enforce runtime policy• Poor coordination of invocation actions with improper planning
  20. 20. Causes of Insecure Invocation• Presuming that an Information is First Class Object: – Improper vision of what information should be delivered, how to be delivered in which form should be delivered at what time to whom. – Non-formalisms of runtime requirements which answers the questions above
  21. 21. Domain Driven Design PatternsCreator:- Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes.- Simply "Creator pattern is responsible for creating an object of class".Information Expert- Used to determine where to delegate responsibilities.- Responsibilities include methods, computed fields and so on.- Information Expert will lead to placing the responsibility on the class with the most information required to fulfill it.Controller- Assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use-case scenario.- Responsible for receiving or handling a system event.- It is defined as the first object beyond the UI layer that receives and coordinates ("controls") a system operation.
  22. 22. PatternsLow Coupling : An evaluative pattern, which dictates how to assign responsibilities to support:- low dependency between classes; low impact in a class of changes in other classes; high reuse potential;High Cohesion An evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable.- High cohesion is generally used in support of Low Coupling.- Responsibilities of a given element are strongly related and highly focused.- Low cohesion is a situation in which a given element has too many unrelated responsibilities.- Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and adverse to change.[4]Polymorphism- Responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens.
  23. 23. PatternsPure Fabrication- A class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion,- This kind of class is called "Service" in DDDIndirection- Supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object.Protected Variations- The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.
  24. 24. Dependency Injection patternConstructor InjectionSetter InjectionInterface InjectionConstructor versusSetter InjectionService Locator vsDependency InjectionSeparatingConfiguration from Use
  25. 25. Resource Preserving with Garbage Collection• What is Garbage Collection? – Finding garbage and reclaiming memory allocated to it.• Why Garbage Collection? – the heap space occupied by an un-referenced object can be recycled and made available for subsequent new objects• When is the Garbage Collection process invoked? – When the total memory allocated to a Java program exceeds some threshold.• Is a running program affected by garbage collection? – Yes, the program suspends during garbage collection.
  26. 26. Dataflow Programming Drastically different way of looking at computation Von Neumann imperative language style: program counter is king Complete control system embedded inside code Dataflow language: movement of data the priority Scheduling responsibility of the system, not the programmer
  27. 27. Contributing Paradigms• Role based programming – Object role modeling• Language based programming• Logic Programming – Constrained Logic Programming• Concept Programming – Concept Oriented Programming• Intention Programming – Intention oriented programming and modeling• Aspect oriented programming• Subject oriented programming• Feature oriented programming and feature driven design• Problem driven modeling• Requirement driven design and engineering• Dynamic meta-programming• Others…
  28. 28. We Have a Set of Shared Tools• Interactive RAD• Shared concurrency• Garbage Collection• Everything is an Object• Higher-order Functions• Emacs• Dynamic polymorphism• Lisp Machines• Macros, Meta-Programming• Custom Small Languages• Generic Functions, Informal Interfaces• Mostly Functional Programming
  29. 29. First-class Design Patterns• Design Patterns are: – Descriptions of what experienced designers know – Hints/reminders for choosing classes and methods – Higher-order abstractions for program organization – To discuss, weigh and record design tradeoffs – To avoid limitations of implementation language• Lisp is the best host for first class patterns
  30. 30. Applying Lisp to Design Patterns16 of 23 GOF patterns are either invisible or simpler:• First-class types (6): Abstract-Factory, Flyweight, Factory-Method, State, Proxy, Chain-Of-Responsibility• First-class functions (4.5): Command, Strategy, Template-Method, Visitor, Iterator, Decorator• Macros (1.5): Interpreter, Iterator• Method Combination (2): Mediator, Observer• Multimethods (1): Builder• Modules (1): Facade
  31. 31. Constructing and Deconstructing Programs into PatternsConstruction Grammar’s What’s X doing Y? construction
  32. 32. Adaptable, Teachable Systems: Interfaces vs. Performance• Black Box: – Input/Output spec. I O – Can’t talk about performance• Open Implementation: T – Performance tweaking, T I O – Designer picks good tweaks• Adaptive Software: T – Performance feedback, F I O – Feedback informs tweaks F
  33. 33. Adaptable, Teachable Systems: Decomposing Into the Right Components• Aspect-Oriented Programming – Deal with one aspect at a time (performance, parallelism, replication, etc.) – http://www.parc.xerox.com/aop• Subject-Oriented Programming – A subject is a collection of classes – http://www.research.ibm.com/sop• Intentional Programming – Don’t bother with syntax; express intentions – http://www.research.microsoft.com/research/ip/
  34. 34. Self-verifying and Repairing Systems• Model Checking, other Formal Methods – Formally prove properties of program – Helps with concurrency, etc.• Model-Based Reasoning – Say what there is, not how to do things with it – Separate reasoning engines for the what – Adaptive to changes in environment, system
  35. 35. Conclusions• Lisp has always allowed us to imagine the abstractions we want, and then build a program with them (see On Lisp)• Now it is time to imagine the program development and use system we really want, and then evolve all our programs starting with it• Even if the resulting system is not in Lisp, its users will essentially be Lisp Programmers