X-UNITY

Parkerian Hexad

Parkerian Hexad - Wikipedia, the free encyclopedia

The CIA triad in my mind has always been too simplistic and taken without much thought by students and professionals. I mean sure, it's easy to understand and adds a basic structure to decompose problems by, but it is so rudimentary and broken. When you have to tack on authentication, non-repudiation, risk management, and other categories the basics of the CIA approach just break down and make the core model unstable and unusable.

I like that the Parkerian Hexad is different. Sure at the core it has problems with non-overlapping categories and atomicity. What I do like is that it is something different and Parker is at least trying. I get the distinct feeling that everyone else has just given up and accepts CIA as the token system that works alright.

I really only wanted to write about this as a note to myself since I've always had a problem with the CIA-mindset. In school no one -ever- talks about Parker, probably because they don't know or care about his work. I get that a lot of people in the security industry may not like him, and he may or may not be crazy. Who knows. I'm fascinated by the fact that there are other models out there being explored.

Graphs

Investigating the prior research that has been conducted with graphs and security policy modeling, or more generally, graphs and security research, even further abstracted graph-based languages.

Keywords/ main reseach areas:

• Vulnerabilty/violation
• Attack graph
• Transformation, morphism
• State-based approach
• Policy anaylsis
• Code analysis
• modeling interconnection networks
  

Darmaillacq, "Security policy testing using vulnerability exploit chaining", ICSTW'08.

• Short paper (2 pages)
• Looks like they just made up their security requirements (policy statements), and encoded them arbitrarily, but I don't know, perhaps this is standardized.
• "test purpose" - "a sequence of events, of which occurrence during a test execution guarantees deliverance of a verdict (pass or fail)." -- doesn't handle NFRs, but enables their policy statements to be encoded in a graph that can be traversed. If you get to a specific sink node then you know that a violation has occurred.
• Combines this research with an attack graph

Bahati, Bauer, "Adapting to Run-time changes in policies driving autonomic management", ICAS 2008

• Has a strange reinforcement learning approach
• I really only pulled this paper as an example for the use of state transition diagrams as graphs in security research.
  
• They express the policy, then generate states that would satisfy the policy, then have violation states, then generate the graph, and see if the states are reachable. Its from an execution standpoint though, I think, not a design/architecture view.
  

Ahn, Xu, Zhang, "Systematic Policy Analysis for High-assurance Services in SELinux", 2008 IEEE Workshop on Policies for Distributed Systems and Networks

• Probably the most relevant paper to what we're doing although its targeted to SELinux/OS specific work.
• Interesting because they have XML policy representation and an architecture that automatically translates it into graph language
• They have a visual representation for violations too, this paper needs a more thurough read-through

Zhao, Ma, Liu, Hi, Huang, "A Graph Transformation based Approach for Runtime Constrained Evoluation of Service-Oritend Architectures", 2009 Parallel, Distributed and Networked-based Processing

• "Dynamic software architectures [4] are those architectures that modify their architecture and enact the modifcations during the system's execution. This behavior is most commonly know as run-time evoluation or dynamism. Graph-based dyamical reconfguration of architectures [12, 17, 20] provides both a formal basis and a graphical representation that is the usualy way architecture are represented."
• Their graph as a service with different ports and a "channel" that connects the ports. It's pretty easy to visualize the system. The whole system has a formal backing.
• SOA Evoluation gets pretty messy though, There are productions and morphisms that make the graph (even a simple example) ... well, complicated. It almost doesn't seem as if their graph is even showing the entire architecure, just a subset. The whole transformation based approach doesn't seem the exact right fit for what we are attempting to do.

Duan, Feng, Wang, Zhang, Yew, "Detecting and eliminating potential violation of sequential consistency for concurrent C/C++ programs" 2009 international symp. on code generation and optimization

• This is the paper that led me down the path of looking for graphs and violation analysis, although the paper itself didn't really give me much to go on itself.
• They have graphs that model executable code and some examples that detect race conditions

Shih, Tan, "Fault-tolerant maximal local-connectivity on the bubble sort graphs", 2009 sixth international conference on information technolgy: new generations

• Similar to the last paper this one didn't really specifically apply to our work but I'm including it for an idea
• "Interconnection network is usually modeled as a graph, in which vertices and edges correspond to processor and communication links, respectively."

Najumudheen, Mall, Samanta, "A Dependence Graph-based Test coverage analysis technique for Object-oritented programs", 2009 Sixth International Conference on Information Technology: New Generations"

• Call Based Object Oritented System Dependence Graph (COSDG)
• "COSDG is a directed, connected multigraph G = (V,E), consisting of a set of V of vertices and set E of edges. A vertex represents one of three categories: statement, entry, and parameter vertices. An edge represents control, data dependency, parameter dependency, method call dependency, summary, class, and inheritance." - We wouldn't need all of that but I like that they can isolate their descriptions of a system down to these fine-grained details.
• Of course their reseach is more based on code coverage for testing but it could easily be adapted to explain the architecture of a system.
  

Wermelinger, Lopes, Fiadeiro, "A graph based architectural (re)configuration language", ESEC/FSE 2001.

• I only pulled this paper because it had reconfiguration and graph in it, I'm not sure if it has anything to do with security or policy modeling.
• This paper is about CommUnity but after just glancing through it I can't exactly figure out what the paper is adding. It seems to be an update of an earlier publication they had on reconfiguration and how existing approaches didn't correclty model reconfiguraiton. It doesn't exactly look like they're extending unity but instead just trying to use it in a new novel way perhaps.
  
• "algebraic graph rewriting" -- similar to a calculus graph rewriting approach?
  

Survivability

Jianming 2008 - A Survivable Scheme for Critical Information Systems

• Need/motivation: "Potential threats include failures (usually generated internally) due to software design errors, hardware degeneration, human errors, or corrupted data, hardware malfunctions, software flaws, environmental hazards, malicious and accidental (generally are externally generated events) human acts"
• "In [9], a rigorous definition of survivability was presented. The survivability specification is a six-tuple, {S, E, D, V, T, P} where: S represents the specification set, E represents the service value factors, D represents the reachable environmental states, V represents relative service values, T and P represent the set of valid transitions and service probabilities. This definition is an engineering definition of survivability."
• "Survivability focuses whether services of the whole system can survive in malicious environment but not the individual components" -- services here are not WS services, but instead functional
• (1) Resistance and Recognition, (2) Recovery (checkpointing), (3) Adaptation (reconfiguraiton)
• [9] Knight, Strunk, Sullivan, "Towards a rigorous definition of information system survivability", IEEE DISCEX 2003

Saridakis, "Surviving Errors in Component-Based Software", 2005 EUROMICRO-SEAA

• In the introduction they have a pretty good breakdown of the main challenges that survivable systems must address
  
• "However, fault tolerance techniques are based on some form of redundancy (e.g. service replication, data replication, state checkpoints, message logging, etc.) which makes them costly. This cost as system complexity (e.g. managing a replica group or taking checkpoints), resource consumption (e.g. additional hosts are needed to execute the service replicas and additional memory to store the replicated data, the checkpoints and the logs), and time penalty during system execution (e.g. delays in service delivery due to the time overhead in replica synchronizing or in saving checkpoints and logs on the stable storage).
• Their paper is a about a concept known as "graceful degradation", basically a slow step down in functionality that reduces the overall performance of a system but still keeps it online. While this is not the exact same concept as a delta-federation, it is still related to some degree.
  
• Also "Dependable systems" - "the capability of a system to outlast runtime errors and fulfill its mission"
• "In other cases (e.g. [11]), mainly inspired from military and avionics domains, survivability describes the capability of a system to adjust its execution so ... can provide functionality despite damages .. due to errors"
• Paper is on an optimistic graceful degradation approach. Identificaiton, isolation, adaption, repair. Optimisic maps errors to replacement functionality designed to fix, I think.
• [11] Knight, Strunk, Sullivan, "Towards a rigorous definition of information system survivability", IEEE DISCEX 2003

Krings, "Design for Survivability: A Tradeoff Space" CSIIRW 2008

• Survivability vs. Adaptation
• "In [3, 19] survivability was described in terms of Resistance, Recognition, Recover, and Adaptation. Adaptation implemented the mechanism to adapt the system to knowledge gained in the prior three phases. Adaptation, in general, also encompases movements in the tradeoff space.
• [3] Ellison, Fisher, Linger, Lipson, Longstaff, Mead "Survivable Network Systems: An emerging discipline" Technical Report CMU
• [19] Mead, Ellison, Linger, Longstaff, McHugh, "Survivable Network Analysis Method", Technical Report CMU

Knight, Strunk, Sullivan, "Towards a Rigorous Definition of Information System Survivability", DARPA Information Survivability Conference and Expo 2003

• Several definitions from different sources
• Survivability: "the capability of..." , "a property of..." , ".. is measured by the probability...", "...qualified by specifying the range", "... the degree to which...",
  
• Later definition "Survivability is the ability of a network computing system to provide essential services in the presence of attacks and failures, and recover full services in a timely manner"
• Faults, are masked or unmasked. Fault avoidacnce may be used and this is not (according to them) an aspect of survivabiltiy.
  
• They claim "survivabitliy is a measurable system characteristic" -- I am not sure about this.
  
• Example is from miltary C2 (command and control), not very specific in details but its generalized and can be adaptive, different modes of operation and different needs.
  
• {S, E, D, V, T, P}
  
• V is user-defiend and ranked, user's perceived service value
  
• 
  
• 
  

Survivability

Breakdown
- What: System, Infrastructure, Communication, Mission
- Domain: MANETS, Business processes, Data Warehouse, Emergency Management
- Design: Patch Management, Protocol, System Architecture, Network defenses
- Metrics: QoS, Intrusion Detection, Attack statistics,
- Mechanism: Load Balancing, Redundancy, Recovery process, Checkpointing, Reconfiguration
- Approach: Centralized, Decentralized

Roundtable discussion from 2000

http://www2.computer.org/portal/web/csdl/abs/html/mags/so/2000/05/s5026.htm

• 
  

IEEE Security & Privacy

Journal: IEEE Security & Privacy

Found this journal yesterday and started to look through it for some interesting articles. They've got two sections that would have articles every once and awhile for "Emerging Standards" and "Building Security In" that seemed interesting.

Anderson, A., "Web services policies," Security & Privacy, IEEE , vol.4, no.3, pp.84-87, May-June 2006
URL: http://www.ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1637390&isnumber=34312

• In the Emerging Standards section
• They decompose a policy across different layers that build on each other: service-interface-binding, domain-binding, policy, assertion (or predicate), vocabulary
• They have something called a policy envelope
• For each layer they have defined they associate one or more different standards specifications that attempt to resolve the problem the layer addresses (all taken from Oasis or W3C)
• Many are XML based (in fact, I think the ones they investigate might -all- be XML)
  
• Details some of the problems with standardizations and policies, ws-desc failed to gain sufficient support and XACML standardization was blocked due to disagreements in the policy committee
• Several standards cross cut their layer stratification XACML is in 3 layers for example
• They bring up the issue of "if every service can shoose among increasing number of policy options, the probability of any two services having compatible policies diminishes"
• Also introduces the issue of a domain, wherein a particular domain might need a different mechanism to express their policies

Gupta, Suvajit; Winstead, Joel, "Using Attack Graphs to Design Systems," Security & Privacy, IEEE , vol.5, no.4, pp.80-83, July-Aug. 2007
URL: http://www.ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4288052&isnumber=4288029

• Was really only looking at this to see if there was any intersting background references to look that would establish a base for linking security (policies) and graph based modeling

Ninghui Li; JiWon Byun; Bertino, E., "A Critique of the ANSI Standard on Role-Based Access Control," Security & Privacy, IEEE , vol.5, no.6, pp.41-49, Nov.-Dec. 2007
URL: http://www.ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4402445&isnumber=4402432
and
Ferraiolo, D.; Kuhn, R.; Sandhu, R., "RBAC Standard Rationale: Comments on "A Critique of the ANSI Standard on Role-Based Access Control"," Security & Privacy, IEEE , vol.5, no.6, pp.51-53, Nov.-Dec. 2007
URL: http://www.ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4402447&isnumber=4402432

• I was hoping this paper would show the specification language (if there was one) but it seems more focused on the formal specification of the standard. Lots of details about flaws in the standard.

Landau, S., "Security and Privacy Landscape in Emerging Technologies," Security & Privacy, IEEE , vol.6, no.4, pp.74-77, July-Aug. 2008
URL: http://www.ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4588236&isnumber=4588217

• Investigates the domains of industrail control systems (SCADA) and emergency management
• Market pressure and deregulation have moved existing closed loop systems to decentralized web based interconnected systems where security is now hard to control
  
• They talk as if NIST 800-53 is a standard, I never really thought of it as such as it seemed more like a documentation of available options
  
• Their references to emergency management standards groups are the Oasis Emergency Mgmt TC, Homeland Security's FEMA, and the Emergency Interoparability Consortium's EDXL

From BuildSecurityIn

https://buildsecurityin.us-cert.gov/daisy/bsi/articles/tools/modeling/698-BSI.html

Security policy model is a traditional name for the combination of the

• specification of the security policy—normally constraints (or properties)
• specification of the behavior of the system—normally a high-level specification of the design¹
• argument showing the consistency of the two—normally this means showing that a software system always stays within security constraints

This need to show consistency has been already been mentioned. In the early days (1960s, 70s, and 80s), this was often written about in terms of formal proofs. In the 1980s the concept of levels of assurance mapped to different kinds of evidence for this consistency. The legacy of this work is seen in today’s Common Criteria. However, borrowing in part from experience in safety, this concept has been generalized to one of an assurance case, which in part tries to address its own uncertainty and is intended to provide grounds for justified confidence and decision making by stakeholders.

One example of tool use is Praxis’s use of Z/Eves to formally state security policy and show the consistency of the system’s high-level design with it, using mathematical logic [Hall 2002].

Hmm...

MODSEC

Workshop on Modeling Security (MODSEC)
http://www.comp.lancs.ac.uk/modsec/

Looked like there was only one paper on policies. Might be worth looking at though.

Tejeddine Mouelhi, Franck Fleurey, Benoit Baudry and Yves Le Traon. Mutating DAC And MAC Security Policies: A Generic Metamodel Based Approach

Review: Security Policies and the Software Developer

Security Policies and the Software Developer
Found in: IEEE Security and Privacy
By Denis Verdon
Issue Date:July 2006
pp. 42-49

I found this by searching for "baseline security policy" on computer.org digital library, it was about halfway down the second page of results.

Link: http://www2.computer.org/portal/web/csdl/abs/html/mags/sp/2006/04/j4042.htm

This is a pretty high level article (not terribly in-depth) but glancing through it I saw it had some nice information categorized.

Different Policy Types (across all kinds of different domains) - Even though they are all "policies" they each mean and contain totally different things, and I think it would help our work a lot if we clearly state which types of policies we address:

• Corporate security policy
• Acceptable use policy
• Privacy policy
• Email policy
• Information (systems) security policy
• Network security policy
• Secure application development policy
• Incident management policy
• Data classification policy
• Policy exemption process

Some of these are likely unrelated to our work, but each probably has different standards and mechanisms of expression.

"To meet the research needs, public communities of interest or working groups usually sprout up, acting as clearing houses for knowledge on threats and countermeasures." they then claims there are 3 distinct groups that do research in these areas:

• "de facto bodies, often evolved from loose communities of interest, such as SANS (www.sans.org);
  
• government-sponsored bodies, such as US-CERT;
  
• and not-for-profit or non-governmental organizations and standards bodies, such as the International Standards Organization, the IEEE, or the Center for Internet Security (www.cisecurity.org)"

Not that this classification really gets us anywhere, but I like that someone else has already stratified the areas that we would likely need to look towards. The article then goes on to look at standards that are prevalent (again I think this document is from a legal-protection viewpoint so its not totally helpful but still worth looking into).

Some of the groups they briefly review (although some of these are just best practices documents, but still, maybe that is who we should turn to for developing the baseline):

• Build Security In (BSI, https://buildsecurityin.us-cert.gov)
• The Open Web Application Security Project (www.owasp.org/documentation)
• Microsoft Developer Network (MSDN; http://msdn.microsoft.com/security)
• Sun Developer Network's Reference on Java Security (http://developers/sun.com/ techtopics/security/javasecurity/reference/techart/ index.html#2)

Baseline motivation

I had taken some notes down on my iPhone the other day that I'm going to try and transcribe and expand upon here.


Why establish a baseline (either from the policy viewpoint or the delta federation?):

• Vast amount of specifications, increasing in number at an increasing rate, with lots of overlapping information
• Certain specifications gain popularity and are adhered to while others exhibiting the same properties are specified and never used.
• By determining the common features throughout a minimum baseline of information can be established.
  
• The baseline can then be used to determine a universal mapping between expression languages (for example the differences web services specified with WSDL or REST would become meaningless assuming an appropriate mapping could be establish with sufficient coverage across all baseline entities).
• As new technologies for expression are developed they can easily be incorporated within any system using the baseline approach.

Context-Based Matching and Ranking of Web Services for Composition
Found in: IEEE Transactions on Services Computing
By Aviv Segev , Eran Toch
Accepted to July 2009 Issue (not yet published)

• They have heavy use of a baseline concept in their paper, not quite the same as ours though
  
• Theirs is a "baseline method" to classify WS information
• They bring up the issue of the view of a domain, for them its the local view whereas our deltafederation would have more of a global/shared/collaborative view
• Intro also brings up the difference between exploratory composition and automatic compositions. Their research is to benefit the exploratory compositions of WS which is helpful because eventually a human guides the development of the final composition.
• They "assume each web service is described using a textual description, which is part of the meta-data within UDDI registries, and a WSDL document describing the syntactic properties of the service interface" - this seems to be a pretty standard and easy to understand statement
• To them, their baseline method is "a simple reflection (identity function) of the original bag of tokens , extracted from the service descriptoins to a bag of tokens representing sets of words". Not quite sure what that means.
  
• "Service analysis leads to the construction of the baseline" -- that could mean the entire baseline or the baseline of a specific service...
• "often WS providers do not include tags in their service descriptions [13]"
• The rest of this paper seems to be going into heavy Information Retrival analysis of the WS descriptions (inverse document frequency, term frequency, etc.). Its almost like they're building up the math for a search engine of WS.
• A lot of the context mapping in their process would be accomplished by a human in our case, I think. This type of reseach certainly enhances any toolkit tasked with that type of responsability though, but ultimately the work would require a human (I'd think).
  

Paper review: A graph-based formalism for RBAC

Koch, M., Mancini, L. V., and Parisi-Presicce, F. 2002. A graph-based formalism for RBAC. ACM Trans. Inf. Syst. Secur. 5, 3 (Aug. 2002), 332-365. DOI= http://doi.acm.org/10.1145/545186.545191

http://portal.acm.org/citation.cfm?id=545186.545191
http://doi.acm.org/10.1145/545186.545191

• 2002, so its not -very- recent
• They list reasons/motivations for the formalism early on. (1) prove properties of a given specification (2) compare different AC models (3) predict system behavior by combining diff. policies
• Formalizes RBAC using a graph transformation language [Rozenberg 1997]
• Provides static and dynamic consistency conditions, and has an executable specification with existing tools
• "A graph represents a state of a system... state changes are specified by graph transformation rules... a rule is given by a graph morphism" -- The CPP does not really have states or state changes, its a static analysis so I'm guessing an approach like this isn't a great match.
• Just thinking here: one approach if we continue down the use of our own langague is to use transformations to build up the system 1 policy at a time. Each transformation would have to ensure the system was in compliance. Oh there are so many different options like that though. Would the graph notate the policy, or the system, or both? Would transformations show the evolution of the system as components are added/removed, the change in state as it executes, the change in policies? Or would there even need to be graph transformations? Too many questions, more background research is needed.
• "The left hand side of the rule add to role contains additionally a dashed edge between the u and the r node. This dashed edge represents a negative application condition"
  
• "The nodes of the rule add to role do not carry labels. This representation for a rule is intended as a pattern for a whole set of rules" -- this seems pretty beneficial, the ability for the language to have patterns which can be applied to specific instanciations

• Edge Labels, absence of labels
• Edge (connected line or dashed line)
  
• Node names, shapes, filled or open, colors
  
• Transformations, rules, actions, activations
  

Reasoning with semantics-aware access control policies for geospatial web services

Ashraful Alam, Ganesh Subbiah, Bhavani M. Thuraisingham, Latifur Khan: Reasoning with semantics-aware access control policies for geospatial web services. SWS 2006: 69-76

Paper available here.

Reasons for looking at this paper:

• How they specify their security policies
• Semantics-aware ACP - a new type of policy? Can the CPP express it?
• Sill looking for baseline, and papers that everyone in security references

Notes from paper:

• Incremental policy buildup, reuse of "security blocks"
• "Distinguishes between two major types of security most prevalent in WS... the first kind deals with general authorization procedures of WS users and subsequent security criteria... the second kind involves organizational protection of data from intruders or clients without access privileges."
• "Not all data housed by the geospatial agencies are considered public in nature. For instance, the data might contain critical information about people, exposure of which would jeopardize their privacy. The problem is exacerbated in a data integration environment because of a lack of coherent security framework. If the trend towards on-the-fly data integration continues, Web services providers would very soon perform complicated services that require embedding or combining geospatial data with other kinds of data."
• "In a very complex policy setting with hundreds of rules with intricate hierarchy of privileges, the reasoning engine will boost the security tremendously by suggesting potential security vulnerabilities in the policy repository."
• 
  

Referenced papers for security background

• Security whitepaper from Microsoft and IBM about web services security model. [1]
• Web Service Policy Language (WSPL) [6]
• GeoXACML [7] access control language for geo spatial web services
• Semantic languages Rei [9], KAoS [10], Ponder [11].
• OWL-S / DAML
• 
  

Paper review: Modeling and Enforcement of Business Policies on Process Models with Maestro

Ivan Markovic, Sukesh Jain, Mahmoud El-Gayyar, Armin B. Cremers, Nenad Stojanovic: Modeling and Enforcement of Business Policies on Process Models with Maestro. ESWC 2009: 873-877

SpringerLink

• Seems to delegate the actual modeling of the business policies to "WSML Flight", another language.
• The contribution of this paper is just a graphical viewer of the output of the Flight module, it seems. It is built on top of the Maestro framework.
• Something about a Policy Recommender, that can somehow recommend policies to specific business processes based on an ontology framework.
• Example is based on separation of duty in a financial industry.
  

Paper review: Contract driven cross-organizational business processes

Ustun Yildiz, Olivera Marjanovic, and Claude Godart, Contract driven cross-organizational business processes, in Proceedings of the Second International Conference on Information Management and Business, IMB (V. Khandelwal and M. S. Raisinghani, eds.), (Australia), pp. 120–130, Australian Computer Society, 2006.

Online PDF available here.

• They have a term "cross-organizational" that really seems to similarly refer to our concept of a Community of Interest (I think).
• From abstract: process monitoring and coordination mechanism, generic contract model, event-driven infrastructure
• Interesting keywords: Cross-organizational Collaboration, E-contracting, Complex Event Processing
  
• Again, this paper is from a business perspective, (like the banking industry example Emmerich used). "interconnected in order to satisfy the mutual benefits of their owners". It is not mission directed, per se.
  
• Cross organizational relationship is defined via a business contract (not sure if this is formalized or not) which is specified independently of the execution details.
• "The contract defines in advance the business constraints that the business partners are supposed to respect when they collaborate". -- so very similar to the idea I had for the contract layer of information in the delta-federation.
• They're using some sort of middleware (Complex Event Processing - CEP) to formalize event-driven applications. It has constraints, parties, operations, metrics, dates, objects.
• Seems to bring in concepts from deontic logic (permission, obligation, prohibition), comparisons (equal, less than, greater than, etc.), and aggregation.
• And then the paper stops, hard to see a specific addition. I guess they borrow the language, and put a middlware between the two interacting partners to monitor. That may be all they do.